summaryrefslogtreecommitdiffstats
path: root/zebra (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Merge pull request #17814 from donaldsharp/nhg_removal_in_some_situationsDonatas Abraitis13 days1-2/+13
|\
| * zebra: Uninstall NHG in some situationsDonald Sharp2025-01-101-2/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If you have this series of events: a) Decision to install a NHG is made in zebra, enqueue to DPLANE b) Changes to NHG are made and we remove it in the master pthread Since this NHG is not marked as installed it is not removed but the NHG data structure is deleted c) DPLANE installs the NHG In the end the NHG stays installed but ZEBRA has lost track of it. Modify the removal code to check to see if the NHG is queued. There are 2 cases: a) NHG is kept around for a bit before being deleted. In this case just see that the NHG is Queued and keep it around too. b) NHG is not kept around and we are just removing it. In this case check to see if it is queued and send another deletion event. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* | lib: introduce global -w option for VRF netns backendIgor Ryzhov2025-01-151-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Current -n option is only for zebra and mgmtd. All other daemons receive the VRF backend configuration from zebra upon connection to it. This leads to a potential race condition - daemons need to know the backend before they start reading their config, but they can be not connected to zebra yet at this point. As the VRF backend cannot change during runtime, let's introduce a new global -w option for setting netns backend, to make sure that all daemons know their VRF backend immediately after start. The reason for introducing a new option instead of making -n global is that ospfd already uses -n for another purposes. Signed-off-by: Igor Ryzhov <idryzhov@gmail.com>
* | lib, zebra: move ns context intialization to zebraIgor Ryzhov2025-01-151-0/+8
| | | | | | | | | | | | | | | | | | vrf->ns_ctxt is only ever used in zebra, so move its initialization to zebra's callback. Ideally this pointer shouldn't even be a part of library's vrf struct, and moved to zebra-specific struct, but this is the first step. Signed-off-by: Igor Ryzhov <idryzhov@gmail.com>
* | lib: remove VRF_BACKEND_UNKNOWNIgor Ryzhov2025-01-151-2/+0
| | | | | | | | | | | | | | | | The backend type cannot be unknown. It is configured to VRF_LITE by default in zebra anyway, so just init to VRF_LITE in the lib and remove the UNKNOWN type. Signed-off-by: Igor Ryzhov <idryzhov@gmail.com>
* | Merge pull request #17799 from LabNConsulting/chopps/backend-yang-modelDonald Sharp2025-01-151-0/+1
|\ \ | | | | | | mgmtd backend yang model (depends on #17796)
| * | lib: northbound/mgmtd: add backend model supportChristian Hopps2025-01-141-0/+1
| | | | | | | | | | | | Signed-off-by: Christian Hopps <chopps@labn.net>
* | | Merge pull request #17859 from donaldsharp/active_routes_are_activeDonatas Abraitis2025-01-151-1/+14
|\ \ \ | |/ / |/| | Active routes are active
| * | zebra: On Nexthop install failure don't set Installation failedDonald Sharp2025-01-141-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently FRR when installing a nexthop group, the installation can fail. The assumption with the code was that the current nexthop group was not already installed. This leaves a problem state where if the users of the nexthop group are removed, the nexthop group will be removed possibly leaving a orphaned nexthop group in the data plane. FRR on a nexthop group installation does not actually know the status of the nexthop group in the kernel. It's possible that a earlier version of the nexthop group is left in play. It's possible that there is no nexthop group in the kernel at all. Leaving the Installed flag alone allows upon Zebra removing the nexthop group when it is removed from zebra. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
| * | zebra: Nexthops need to be ACTIVE in some casesDonald Sharp2025-01-141-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently if you have an interface down event, Zebra sets the nexthop(s) as !ACTIVE that use it. On interface up events the singleton nexthops are not being set as ACTIVE. Due to timing events it is sometimes possible to end up with a route that is using a singleton Change singleton nexthops to set the nexthop to ACTIVE. This will allow the nexthop to be reinstalled appropriately as well. I was able to easily reproduce this using sharpd since it does not attempt to reinstall the routes when a interface goes up/down. Before: D>* 10.0.0.0/32 [150/0] via 192.168.102.34, dummy2, weight 1, 00:00:01 sharpd@eva ~/frr5 (master)> sudo ip link set dummy2 down ; sudo ip link set dummy2 up D> 10.0.0.0/32 [150/0] (350) via 192.168.102.34, dummy2 inactive, weight 1, 00:00:10 After code change: D>* 10.0.0.0/32 [150/0] (73) via 192.168.102.34, dummy2, weight 1, 00:00:14 sharpd@eva ~/frr5 (master)> sudo ip link set dummy2 down ; sudo ip link set dummy2 up D>* 10.0.0.0/32 [150/0] (73) via 192.168.102.34, dummy2, weight 1, 00:00:21 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* | | Merge pull request #17796 from LabNConsulting/chopps/datastore-notificationsDonald Sharp2025-01-142-13/+22
|\ \ \ | | | | | | | | operational-state (datastore) change notifications
| * | | lib: if: track oper-state inlineChristian Hopps2025-01-142-13/+20
| | | | | | | | | | | | | | | | Signed-off-by: Christian Hopps <chopps@labn.net>
| * | | lib: vrf: track oper-state inlineChristian Hopps2025-01-141-0/+2
| |/ / | | | | | | | | | Signed-off-by: Christian Hopps <chopps@labn.net>
* | | Merge pull request #17581 from mjstapp/fix_fpm_netlinkDonald Sharp2025-01-148-159/+507
|\ \ \ | |/ / |/| | zebra: avoid race between FPM pthread and zebra main pthread in netlink encode/decode
| * | zebra: improve an rnode debugMark Stapp2024-12-051-2/+2
| | | | | | | | | | | | | | | | | | | | | Improve a debug when we create a new rib_dest by calling the debug after setting up the dest. Signed-off-by: Mark Stapp <mjs@cisco.com>
| * | zebra: remove thread-unsafe debug from netlink nhg encoderMark Stapp2024-12-051-2/+1
| | | | | | | | | | | | | | | | | | Remove use of vrf name, which isn't thread-safe. Signed-off-by: Mark Stapp <mjs@cisco.com>
| * | zebra: remove thread-unsafe debugs from netlink route encodeMark Stapp2024-12-051-27/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | The netlink route message encode function accessed and used zebra vrfs to produce debug output. That's not thread-safe, and that encode code needs to run in (at least) the dplane pthread and the FPM plugin pthread. Signed-off-by: Mark Stapp <mjs@cisco.com>
| * | zebra: remove unused dplane route apiMark Stapp2024-12-052-24/+0
| | | | | | | | | | | | | | | | | | | | | Remove a route api that's no longer used after refactoring the netlink and FPM code. Signed-off-by: Mark Stapp <mjs@cisco.com>
| * | zebra: refactor netlink route message parsingMark Stapp2024-12-056-104/+397
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Separate core netlink route message parsing into a new api that uses a dplane ctx to hold the parsed attribute data. Use the new api in two paths: the normal netlink update message parsing path, and in the FPM plugin, which also uses netlink encoding. The FPM route-notificatin code runs in its own pthread, and only needs a subset of the route info that zebra ordinarily develops. This change stops that pthread from accessing zebra's internal data, such as vrfs and ifps, that are not thread-safe. Signed-off-by: Mark Stapp <mjs@cisco.com>
| * | zebra: add more dataplane route apisMark Stapp2024-12-042-0/+91
| | | | | | | | | | | | | | | | | | | | | Add several additional route attribute data and accessors to the dplane module. Signed-off-by: Mark Stapp <mjs@cisco.com>
* | | zebra: Optimize invoking nhg compare funcRajasekar Raja2025-01-101-2/+2
| |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In some cases, the old_re nhe and the newnhe is same and there is no point in comparing them both since they are the same. Skip comparing in such cases. Ex: 2025/01/09 23:49:27.489020 ZEBRA: [W4Z4R-NTSMD] zebra_nhg_rib_find_nhe: => nhe 0x555f611d30c0 (44[38/39/45]) 2025/01/09 23:49:27.489021 ZEBRA: [ZH3FQ-TE9NV] zebra_nhg_rib_compare_old_nhe: 0.0.0.0/0 new id: 44 old id: 44 2025/01/09 23:49:27.489021 ZEBRA: [YB8HE-Z86GN] zebra_nhg_rib_compare_old_nhe: 0.0.0.0/0 NEW 0x555f611d30c0 (44[38/39/45]) 2025/01/09 23:49:27.489023 ZEBRA: [ZSB1Z-XM2V3] 0.0.0.0/0: NH 20.1.1.9[0] vrf default(0) wgt 1, with flags 2025/01/09 23:49:27.489024 ZEBRA: [ZSB1Z-XM2V3] 0.0.0.0/0: NH 30.1.2.9[0] vrf default(0) wgt 1, with flags 2025/01/09 23:49:27.489025 ZEBRA: [ZSB1Z-XM2V3] 0.0.0.0/0: NH 20.1.1.2[4] vrf default(0) wgt 1, with flags ACTIVE 2025/01/09 23:49:27.489026 ZEBRA: [ZM3BX-HPETZ] zebra_nhg_rib_compare_old_nhe: 0.0.0.0/0 OLD 0x555f611d30c0 (44[38/39/45]) 2025/01/09 23:49:27.489027 ZEBRA: [ZSB1Z-XM2V3] 0.0.0.0/0: NH 20.1.1.9[0] vrf default(0) wgt 1, with flags 2025/01/09 23:49:27.489028 ZEBRA: [ZSB1Z-XM2V3] 0.0.0.0/0: NH 30.1.2.9[0] vrf default(0) wgt 1, with flags 2025/01/09 23:49:27.489028 ZEBRA: [ZSB1Z-XM2V3] 0.0.0.0/0: NH 20.1.1.2[4] vrf default(0) wgt 1, with flags ACTIVE Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
* | zebra: Fix leaked nheDonald Sharp2025-01-091-5/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During route processing in zebra, Zebra will create a nexthop group that matches the nexthops passed down from the routing protocol. Then Zebra will look to see if it can re-use a nhe from a previous version of the route entry( say a interface goes down ). If Zebra decides to re-use an nhe it was just dropping the route entry created. Which led to nexthop group's that had a refcount of 0 and in some cases these nexthop groups were installed into the kernel. Add a bit of code to see if the returned entry is not being used and it has no reference count and if so, properly dispose of it. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* | Merge pull request #17474 from sougata-github-nvidia/rib_ip_protocol_cleanupRuss White2025-01-072-19/+5
|\ \ | | | | | | zebra: Fix ip protocol route-map issue.
| * | zebra: Fix ip protocol route-map issue.Sougata Barik2025-01-062-19/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "ip/ipv6 protocol any route-map <route map>" cli is setting wrong route type ( ZEBRA_ROUTE_MAX ), It should set route type ZEBRA_ROUTE_ALL. Ticket: #4101560 Signed-off-by: Sougata Barik <sougatab@nvidia.com>
* | | Merge pull request #17752 from raja-rajasekar/rajasekarr/comp_issueJafar Al-Gharaibeh2025-01-061-111/+9
|\ \ \ | | | | | | | | zebra: fix dpdk compilation error
| * | | zebra: fix dpdk compilation errorRajasekar Raja2025-01-031-111/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixing compilation error in a switch statement case Fixes :aa4786642c9a65c282d0fd5247a35b0f14fa1c3c Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
* | | | Merge pull request #17737 from chiragshah6/fdev7Donatas Abraitis2025-01-031-5/+8
|\ \ \ \ | |/ / / |/| | | zebra:check DAD freeze action before notifying bgp
| * | | zebra:check DAD freeze action before notifying bgpChirag Shah2024-12-301-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If Duplicate Address Detection action is freeze (permanent or definite time means not warn only mode) then locally duplicate detected MAC delete notification is not require to inform, instead ask BGP to sync previous remote MAC entry. In freeze case local MAC event is not known to BGP, instead BGP is pointing to remote VTEP for the MAC. Ticket: #3652383 Issue: 3652383 Signed-off-by: Chirag Shah <chirag@nvidia.com>
* | | | zebra: Fix resetting valid flags for NHG dependentsDonald Sharp2024-12-301-7/+15
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Upon if_down, we don't reset the valid flag for dependents and unset the INSTALLED flag. So when its time for the NHG to be deleted (routes dereferenced), zebra deletes it since refcnt goes to 0, but stale NHG remains in kernel. Ticket :#4200788 Signed-off-by: Donald Sharp <sharpd@nvidia.com> Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
* | | zebra: Remove tests for `srv6_locator_alloc` failureCarmine Scarpitta2024-12-221-4/+0
| | | | | | | | | | | | | | | | | | | | | `srv6_locator_alloc` can never fail. Let's remove the tests for allocation failure. Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
* | | Merge pull request #17544 from anlancs/zebra/fix-plug-interfaceRuss White2024-12-173-2/+4
|\ \ \ | | | | | | | | zebra: fix wrong nexthop status for kernel routes
| * | | zebra: check kernel routes when interface becomes upanlan_cs2024-12-171-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Just like `link down`, check all kernel routes when interface become up. And, they maybe will be selected as the best one by zebra. Signed-off-by: anlan_cs <anlan_cs@126.com>
| * | | zebra: don't uninstall kernel routesanlan_cs2024-12-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After the nexthop check is fixed, zebra will wrongly uninstall the kernel routes with inactive nexthop. This commit would skip the uninstallation for kernel routes. Signed-off-by: anlan_cs <anlan_cs@126.com>
| * | | zebra: fix wrong nexthop checkanlan_cs2024-12-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The kernel routes are wrongly selected even the nexthop interface is linkdown. Use `ip link set dev <interface> down` on the other box to set the box's nexthop interface linkdown. The kernel routes will be kept as `linkdown`, but are still with active nexthop in `zebra`. Add three changes/commits for kernel routes in this PR: 1) The active nexthop should be the operative interface. 2) Don't uninstall the kernel routes from `zebra` even no active nexthops. (It doesn't affect the kernel routes' deletion from kernel netlink messages.) 3) Update the kernel routes when the nexthop interface becomes up. Before: (during nexthop interface is linkdown) ``` K>* 3.3.3.3/32 [0/0] via 88.88.88.1, enp2s0, weight 1, 00:00:14 ``` After: (during nexthop interface is linkdown, with all three changes) ``` K 3.3.3.3/32 [0/0] via 88.88.88.1, enp2s0 inactive, weight 1, 00:00:07 ``` This commit is 1st change: Improve the judgment for "active" nexthop to be more accurate, the active nexthop should be the operative interface. Signed-off-by: anlan_cs <anlan_cs@126.com>
* | | | Merge pull request #17252 from nabahr/mcast-modeRafael Zalamena2024-12-168-389/+165
|\ \ \ \ | | | | | | | | | | Fix PIMD RPF lookup mode and nexthop tracking
| * | | | zebra: Improve multicast safi route show commandsNathan Bahr2024-12-121-186/+139
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add `mrib` flag to existing "show ip route" commands which then use the multicast safi rather than the unicast safi. Updated the vty output to include the AFI and SAFI string when printing the table. Deprecate `show ip rpf` command, aliased to `show ip route mrib`. Removed `show ip rpf A.B.C.D`. Signed-off-by: Nathan Bahr <nbahr@atcorp.com>
| * | | | zebra,yang: Completely remove multicast mode from zebraNathan Bahr2024-12-125-128/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Multicast mode belongs in PIM, so removing it completely from zebra. Modified `show (ip|ipv6) rpf ADDRESS` to always lookup from SAFI_MULTICAST. This means this command is now specific to the multicast table and does not necessarily reflect the PIM RPF lookup, but that should be implemented in PIM instead. Signed-off-by: Nathan Bahr <nbahr@atcorp.com>
| * | | | zebra,pimd,lib: Modify ZEBRA_NEXTHOP_LOOKUP_MRIBNathan Bahr2024-12-123-77/+26
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Modified ZEBRA_NEXTHOP_LOOKUP_MRIB to include the SAFI from which to do the lookup. This generalizes the API away from MRIB specifically and allows the user to decide how it should do lookups. Rename ZEBRA_NEXTHOP_LOOKUP_MRIB to ZEBRA_NEXTHOP_LOOKUP now that it is more generalized. This change is in preperation to remove multicast lookup mode completely from zebra. Signed-off-by: Nathan Bahr <nbahr@atcorp.com>
* / / / zebra: Give a bit more data about zclient connection on errorsDonald Sharp2024-12-131-6/+5
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | When debugging a crash I noticed that sometimes we talked about a zclient connection in relation to the fd associated with it and sometimes we did not. Let's just always give the data associated with the fd. It will make it a bit easier for me to follow the transitions. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* | | Merge pull request #17638 from donaldsharp/zebra_metaq_stuffDonatas Abraitis2024-12-121-14/+4
|\ \ \ | | | | | | | | zebra: Remove tests for allocation failure
| * | | zebra: Remove tests for allocation failureDonald Sharp2024-12-111-14/+4
| | | | | | | | | | | | | | | | | | | | | | | | This cannot happen. No need to test Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* | | | zebra: Fix another ships in the night issue with WFIDonald Sharp2024-12-091-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Effectively When bgp would send a route update down to zebra and immediately after that a asic update from the kernel was read. Zebra would choose the asic update and drop the bgp update leaving us in a state where bgp was not used as the true source. Modify the code so that in rib_multipath_nhe we notice that we have an unprocessed route update from bgp. And if so just drop this kernel update about an older version of the route since it is no longer needed. Ticket: 2722533 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* | | | zebra: Reduce memory usage of streams for encoding packetsDonald Sharp2024-12-094-23/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For those packets that we are not sending 16k of data, but something far less than 256 bytes. Reduce those stream sizes we allocate to something much more reasonable. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* | | | zebra: Reset MAC's remote sequence number appropriatelyvivek2024-12-092-0/+3
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a MAC gets deleted but associated neighbors remain, the MAC is kept in the zebra MAC database as an internal ("auto") entry. When this happens, reset the MAC's remote sequence number. This ensures that when the host with the MAC later comes up behind a remote VTEP, the local switch accepts the MAC and installs it into the bridge FDB and we don't end up in a situation where remote MACs are not installed into the bridge FDB. This fix is a corollary of CM-22753 and is this time done for local MACs upon delete. Note: Commit is marked Cumulus-only because I need to evalute more comprehensive changes before upstreaming it. Ticket: CM-29581 Reviewed By: As above Testing Done: 1. Multiple rounds of manual testing 2. Two rounds of evpn-smoke, 1 round of precommit Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Acked-by: Chirag Shah <chirag@cumulusnetworks.com> Acked-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
* | | Merge pull request #17589 from anlancs/master_upDonatas Abraitis2024-12-071-3/+1
|\ \ \ | | | | | | | | zebra: use macro for one check
| * | | zebra: use macro for one checkanlan_cs2024-12-051-3/+1
| | | | | | | | | | | | | | | | Signed-off-by: anlan_cs <anlan_cs@126.com>
* | | | zebra: add deprecation notice for no-op netns commandIgor Ryzhov2024-12-071-0/+3
|/ / / | | | | | | | | | Signed-off-by: Igor Ryzhov <idryzhov@gmail.com>
* | / zebra: separate zebra ZAPI server open and acceptMark Stapp2024-12-033-5/+45
| |/ |/| | | | | | | | | | | | | Separate zebra's ZAPI server socket handling into two phases: an early phase that opens the socket, and a later phase that starts listening for client connections. Signed-off-by: Mark Stapp <mjs@cisco.com>
* | Merge pull request #17519 from chiragshah6/evpn_dev4Mark Stapp2024-11-262-5/+4
|\ \ | | | | | | zebra: EVPN fix code style in vlan vni map debugs
| * | zebra: EVPN fix code style in vlan vni map debugsChirag Shah2024-11-262-5/+4
| | | | | | | | | | | | | | | | | | | | | Fix up couple of style issues missed in PR 17483 Signed-off-by: Chirag Shah <chirag@nvidia.com>