summaryrefslogtreecommitdiff
path: root/zebra/rt_netlink.h
AgeCommit message (Collapse)Author
2023-09-04zebra: support route replace semantics in FPMRafael Zalamena
Set `NLM_F_REPLACE` instead of adding and removing the same route for an update. Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
2023-07-05zebra: Rename vrf_lookup_by_tableid to zebra_vrf_lookup..Donald Sharp
Rename the vrf_lookup_by_id function to zebra_vrf_lookup_by_id and move to zebra_vrf.c where it nominally belongs, as that we need zebra specific data to find this vrf_id and as such it does not belong in vrf.c Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-02-17Merge pull request #12780 from opensourcerouting/spdx-license-idDonald Sharp
*: convert to SPDX License identifiers
2023-02-13zebra: Bug fixes in fdb read for flooded traffic and remote fdb cleanup upon ↵Sharath Ramamurthy
vni removal This patch addresses following issues, - When the VLAN-VNI mapping is configured via a map and not using individual VXLAN interfaces, upon removal of a VNI ensure that the remote FDB entries are uninstalled correctly. - When VNI configuration is performed using VLAN-VNI mapping (i.e., without individual VXLAN interfaces) and flooded traffic is handled via multicast, the multicast group corresponding to the VNI needs to be explicitly read from the bridge FDB. This is relevant in the case of netlink interface to the kernel and for the scenario where a new VNI is provisioned or comes up. Signed-off-by: Sharath Ramamurthy <sramamurthy@nvidia.com>
2023-02-13zebra: multiple vlan aware bridge datastructure changes and vxlan device ↵Sharath Ramamurthy
iftype derivation from netlink This change set introduces data structure changes required for multiple vlan aware bridge functionality. A new structure zebra_l2_bridge_if encapsulates the vlan to access_bd association of the bridge. A vlan_table hash_table is used to record each instance of the vlan to access_bd of the bridge via zebra_l2_bridge_vlan structure. vxlan iftype derivation: netlink attribute IFLA_VXLAN_COLLECT_METADATA is used to derive the iftype of the vxlan device. If the attribute is present, then the vxlan interface is treated as single vxlan device, otherwise it would default to traditional vxlan device. zebra_vxlan_check_readd_vtep, zebra_vxlan_dp_network_mac_add/del is modified to be vni aware. mac_fdb_read_for_bridge - is modified to be (vlan, bridge) aware Signed-off-by: Sharath Ramamurthy <sramamurthy@nvidia.com>
2023-02-09*: auto-convert to SPDX License IDsDavid Lamparter
Done with a combination of regex'ing and banging my head against a wall. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2023-01-24zebra_fpm: Add support for other protocols in fpm:netlinkSpoorthi K
fpm:netlink format doesn't indicate the protocol information in routes of BGP, OSPF and other protocols. Routes of those protocols just indicate protocol as zebra. The below route is actually BGP route but 'proto': 11 indicates that it is zebra. {'attrs': [('RTA_DST', 'dummy'), ('RTA_PRIORITY', 0), ('RTA_GATEWAY', 'dummy'), ('RTA_OIF', 2)], 'dst_len': 32, 'family': 2, 'flags': 0, 'header': {'flags': 1025, 'length': 60, 'pid': 3160253895, 'sequence_number': 0, 'type': 24}, 'proto': 11, 'scope': 0, 'src_len': 0, 'table': 254, 'tos': 0, 'type': 1} with this change it is now seen with 'proto': 186 indicates that it is BGP. {'attrs': [('RTA_DST', 'dummy'), ('RTA_PRIORITY', 0), ('RTA_GATEWAY', 'dummy'), ('RTA_OIF', 2)], 'dst_len': 32, 'family': 2, 'flags': 0, 'header': {'flags': 1025, 'length': 60, 'pid': 3160253895, 'sequence_number': 0, 'type': 24}, 'proto': 186, 'scope': 0, 'src_len': 0, 'table': 254, 'tos': 0, 'type': 1} Signed-off-by: Spoorthi K <spk@redhat.com>
2023-01-18Merge pull request #12604 from donaldsharp/distance_metric_offload_fixesRuss White
Distance/metric offload fixes
2023-01-05zebra: Set metric appropriately on route offload to asicDonald Sharp
When FRR receives a route from the kernel about the route offload success/failure. The metric being reported is not going to be correct since we may not know it appropriately at this point in time. If we can set the metric to something appropriate. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-25fpm: Send NH message to FPM even if the local kernel doesn't support itYutaro Hayakawa
netlink_route_multipath_msg_encode checks whether the local kernel supports NextHop Netlink message and doesn't send the message if the local kernel doesn't have support. This is also applied to the FPM since kernel dataplane and FPM shares the same code. However, for the FPM, it's not necessary to have this limit. This commit adds extra check if netlink_route_multipath_msg_encode is called from the FPM and bypass kernel support check if it is from the FPM. Signed-off-by: Yutaro Hayakawa <yutaro.hayakawa@isovalent.com>
2022-12-12zebra: Add ctx to netlink message parsingDonald Sharp
Add the initial step of passing in a dplane context to reading route netlink messages. This code will be run in two contexts: a) The normal pthread for reading netlink messages from the kernel b) The dplane_fpm_nl pthread. The goal of this commit is too just allow a) to work b) will be filled in in the future. Effectively everything should still be working as it should pre this change. We will just possibly allow the passing of the context around( but not used ) Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-03-09zebra: add support for protodown reason codeStephen Worley
Add support for setting the protodown reason code. https://github.com/torvalds/linux/commit/829eb208e80d6db95c0201cb8fa00c2f9ad87faf These patches handle all our netlink code for setting the reason. For protodown reason we only set `frr` as the reason externally but internally we have more descriptive reasoning available via `show interface IFNAME`. The kernel only provides a bitwidth of 32 that all userspace programs have to share so this makes the most sense. Since this is new functionality, it needs to be added to the dplane pthread instead. So these patches, also move the protodown setting we were doing before into the dplane pthread. For this, we abstract it a bit more to make it a general interface LINK update dplane API. This API can be expanded to support gernal link creation/updating when/if someone ever adds that code. We also move a more common entrypoint for evpn-mh and from zapi clients like vrrpd. They both call common code now to set our internal flags for protodown and protodown reason. Also add debugging code for dumping netlink packets with protodown/protodown_reason. Signed-off-by: Stephen Worley <sworley@nvidia.com>
2022-02-10zebra: add netlink debugs for ip rulesTrey Aspelund
Adds functions to parse + decode netlink rules. Adds RTM_NEWRULE + RTM_DELRULE to "debug zebra kernel". Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
2021-07-19zebra: use more constMark Stapp
Use const in many more evpn apis, especially for macaddr, ipaddr arguments. Signed-off-by: Mark Stapp <mjs@voltanet.io>
2020-12-14Merge pull request #7162 from opensourcerouting/zebra-human-netlinkStephen Worley
zebra: human readable netlink dumps
2020-11-27zebra: dplane FPM handle LSP install/update/deleteDuncan Eastoe
Export netlink_lsp_msg_encoder() and use it to encode and send netlink messages concerning LSP updates to connected FPMs. Signed-off-by: Duncan Eastoe <duncan.eastoe@att.com>
2020-09-23zebra: human readable netlink dumpsRafael Zalamena
Add new compile option to enable human readable netlink dumps with `debug zebra kernel msgdump`. Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
2020-08-10zebra: netlink message batchingJakub Urbańczyk
Integrate existing functions with batching infrastructure. Signed-off-by: Jakub Urbańczyk <xthaid@gmail.com>
2020-08-07lib, zebra: Add SR-TE policy infrastructure to zebraSebastien Merle
For the sake of Segment Routing (SR) and Traffic Engineering (TE) Policies there's a need for additional infrastructure within zebra. The infrastructure in this PR is supposed to manage such policies in terms of installing binding SIDs and LSPs. Also it is capable of managing MPLS labels using the label manager, keeping track of nexthops (for resolving labels) and notifying interested parties about changes of a policy/LSP state. Further it enables a route map mechanism for BGP and SR-TE colors such that learned BGP routes can be mapped onto SR-TE Policies. This PR does not introduce any usable features by now, it is just infrastructure for other upcoming PRs which will introduce 'pathd', a new SR-TE daemon. Co-authored-by: Renato Westphal <renato@opensourcerouting.org> Co-authored-by: GalaxyGorilla <sascha@netdef.org> Signed-off-by: Sebastien Merle <sebastien@netdef.org>
2020-06-13zebra: check for buffer boundaryJakub Urbańczyk
* Move code encoding Netlink messages to separate functions * Add buffer bounds checking while creating Nelink messages Signed-off-by: Jakub Urbańczyk <xthaid@gmail.com>
2020-05-13zebra: format files to make polychaeta happyRafael Zalamena
Use clang-format to make code match what polychaeta wants for formatting. Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
2020-05-05fpm: add toggle to enable/disable next hop groupsRafael Zalamena
If you haven't migrated your FPM server to use next hop groups, it is possible that you want to disable this feature. This commit implements a toggle to enable/disable next hop groups usage (even if your Linux kernel is not using it). Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
2020-05-05fpm: add next hop group supportRafael Zalamena
Add support for the new kernel messages: `RTM_NEWNEXTHOP` and `RTM_DELNEXTHOP`. Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
2020-04-22zebra: Expose vrf lookup by table id out of rt_netlink.cDonald Sharp
The function rt_netlink.c is using to lookup the vrf by passed in table id. I'm also going to pretend that this function is not so awful to run when we have a large number of routes incoming. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2020-04-14zebra: data plane FPM add support RMAC VNIRafael Zalamena
Store VNI information in the data plane context so we can use it to build the FPM netlink update with that information later. Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
2020-04-14zebra: adapt and export rmac netlink functionsRafael Zalamena
Those functions are going to be used by the new data plane plugin for netlink FPM. Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
2020-04-14zebra: export netlink function and change returnRafael Zalamena
Instead of retuning always `0`, lets return the amount of used bytes for the message. This will be used by the new FPM interface to know how many bytes we must reserve for the output buffer. Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
2019-10-25zebra: Add functionality to parse RTM_NEWNEXTHOP and RTM_DELNEXTHOP messagesStephen Worley
Add the functionality to parse new nexthop group messages from the kernel and insert them into the appropriate hash tables. Parsing is done at startup between interface and interface address lookup. Add functionality to parse changes to nexthops we already have. Add functionality to parse delete nexthop messages from the kernel and remove them from our table. Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
2019-03-25add cplusplus guards to all zebra headersEmanuele Di Pascale
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
2019-01-23Merge pull request #3508 from chiragshah6/evpn_dev2Russ White
zebra: EVPN remote entry delete check local entry presence
2019-01-22zebra: openbsd LSP update codeMark Stapp
Finish the LSP update code for the async dataplane for the openbsd platform. Remove synch apis now that we've converted to the async code path. Signed-off-by: Mark Stapp <mjs@voltanet.io>
2019-01-22zebra: infra for LSP updates using dplaneMark Stapp
Adding infra to zebra dplane to support LSP updates. Add kernel api for LSP updates that uses a dataplane context; add stub apis for netlink, bsd, and 'null' kernel paths. Add version of netlink mpls update code that takes a dplane context struct instead of a zebra lsp struct. Signed-off-by: Mark Stapp <mjs@voltanet.io>
2018-12-31zebra: evpn remote delete fetch local entryChirag Shah
An EVPN type-2 entry is in freeze state during remote update, remote VTEP can send typ-2 withdraw update, upon receiving an entry delete (withdraw), first check kernel has in local reachable state. Upon unfreeze use the local entry to advertise to peers. Fetch is for both MAC and IP, delete can come for only MAC or MAC-IP combined route. The specific entry fetch only required request flag to be set, dump flag is not required. Testing Done: Simulate two VTEPs to do M1, IP1 mobility sequence, freeze MAC during remote MAC update, subsequently send withdraw type-2 route from origintating VTEP. This results in read apis to invoke for local reachable entry. Zebra updates its cache and upon unfreeze originates type-2. Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
2018-09-05zebra: add RTPROT_FABRICD route type 197Christian Franke
Add an iproute2 route type for fabricd Signed-off-by: Christian Franke <chris@opensourcerouting.org>
2018-05-27Merge pull request #2283 from donaldsharp/ignore_some_moreRuss White
zebra: netlink cleanups
2018-05-26tools, zebra: Use different protocol value for our staticsDonald Sharp
The re-use of RTPROT_STATIC has caused too many collisions where other legitimate route sources are causing us to believe we are the originator of the route. Modify the code so that if another protocol inserts RTPROT_STATIC we will assume it's a Kernel Route. Fixes: #2293 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2018-05-24zebra: Remove unnecessary function parameterDonald Sharp
The snl variable is no longer needed to be passed around, so remove it from the calling path. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2018-04-27zebra: Add PBR and SHARP handlingDonald Sharp
We are missing some handling of PBR and SHARP protocols for netlink operations w/ the linux kernel. Additionally add a bread crumb for new developers( or existing ) to know to fixup the rt_netlink.c when we start handling new route types to hand to the kernel. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2017-11-27sharpd: Add Super Happy Advanced Routing ProtocolDonald Sharp
Add a daemon that will allow us to test the zapi as well as test route install/removal times from the kernel. The current commands are: install route <starting ip address> nexthop <nexthop> (1-1000000) This command starts installing at <starting ip address>/32 (1-100000) routes that it auto-increments by 1 Installation start time is noted in the log and finish time is noted as well. remove routes <starting ip address> (1-1000000) This command removes routes at <starting ip address>/32 and removes (1-100000) routes created by the install route command. This code can be considered experimental and *is not* something that should be run in a production environment. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2017-10-27zebra: Move clear_nhlfe_installed to calling functionsDonald Sharp
The function clear_nhlfe_installed is to be called when we get a install failure of some sort for a lsp change. Since an install failure can happen in both linux and openBSD moving the function call northbound is a good idea. I've also added it to the kernel_del_lsp for completeness on failure as well, even though neither linux or openBSD currently can fail a uninstall. This still leaves the hole where if we have multiple nhlfes and have an install failure we are not quite doing the right thing by just blanketly calling clear_nhlfe_installed. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2017-10-05*: Add some documentation about how to handle new daemonsDonald Sharp
Add some breadcrumbs for when we add a new routing daemon so things `just work`. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2017-07-17*: reindentreindent-master-afterwhitespace / reindent
indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-12zebra: MAC and Neighbor (ARP/ND) handlingvivek
Implement handling of MACs and Neighbors (ARP/ND entries) in zebra: - MAC and Neighbor database handlers - Read MACs and Neighbors from the kernel, when needed and create entries in zebra's MAC and Neighbor databases. - Handle add/update/delete notifications from the kernel for MACs and Neighbors and update zebra's database appropriately - Inform locally learnt MACs and Neighbors to client - Handle MACIP add/delete from client and install appriporiate entries into the kernel - Since Neighbor entries will be installed on an SVI, implement the needed mappings NOTE: kernel interface is only implemented for Linux/netlink Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
2017-06-13Merge remote-tracking branch 'frr/master' into pull-624David Lamparter
2017-06-08zebra: In which RTPROT_BABEL is hardDonald Sharp
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2017-06-08zebra: For older distributions RTPROT_BABEL might not be definedDonald Sharp
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2017-06-08tools, zebra: Fix netlink notification of who owns the routesDonald Sharp
For NHRP, EIGRP and LDP( This is for consistency as opposed to correctness ) assign some new values to routes to be installed into the kernel so we can know who owns them later. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2017-05-25zebra: Store commonly used values instead of regeneratingDonald Sharp
the ipv4_ll address used for 5549 routes does not need to be figured out every single time that we attempt to install/remove a route of that type. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2017-05-15*: make consistent & update GPLv2 file headersDavid Lamparter
The FSF's address changed, and we had a mixture of comment styles for the GPL file header. (The style with * at the beginning won out with 580 to 141 in existing files.) Note: I've intentionally left intact other "variations" of the copyright header, e.g. whether it says "Zebra", "Quagga", "FRR", or nothing. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-04-20Add source of route as protocol string in ip route pushed into kernelDinesh G Dutt
Ticket: CM-14313 Reviewed By: Testing Done: bgpmin, ospfmin, bgp_kitchen_sink_test 'ip route show' displays all routes as belonging to protocol zebra. The user has to run an additional command (in vtysh) to get the actual source of a route (bgp/ospf/static etc.). This patch addresses that by pushing the appropriate protocol string into the protocol field of the netlink route update message. Now you can see routes with the correct origin as well as filter on them (ip route show proto ospf). 'ospf' is used for both IPv4 and IPv6 routes, even though the OSPF version is different in both cases. Sample output (old): 9.9.12.13 via 69.254.2.38 dev swp3.2 proto zebra metric 20 9.9.13.3 proto zebra metric 20 nexthop via 69.254.2.30 dev swp1.2 weight 1 nexthop via 69.254.2.34 dev swp2.2 weight 1 nexthop via 69.254.2.38 dev swp3.2 weight 1 Sample output (new): 9.9.12.13 via 69.254.2.38 dev swp3.2 proto bgp metric 20 9.9.13.3 proto bgp metric 20 nexthop via 69.254.2.30 dev swp1.2 weight 1 nexthop via 69.254.2.34 dev swp2.2 weight 1 nexthop via 69.254.2.38 dev swp3.2 weight 1