summaryrefslogtreecommitdiffstats
path: root/zebra (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* | | zebra: fix evpn mh bond member proto reinstallChirag Shah2024-06-201-3/+12
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In case of EVPN MH bond, a member port going in protodown state due to external reason (one case being linkflap), frr updates the state correctly but upon manually clearing external reason trigger FRR to reinstate protodown without any reason code. Fix is to ensure if the protodown reason was external and new state is to have protodown 'off' then do no reinstate protodown. Ticket: #3947432 Testing: switch:#ip link show swp1 4: swp1: <NO-CARRIER,BROADCAST,MULTICAST,SLAVE,UP> mtu 9216 qdisc pfifo_fast master bond1 state DOWN mode DEFAULT group default qlen 1000 link/ether 1c:34:da:2c:aa:68 brd ff:ff:ff:ff:ff:ff protodown on protodown_reason <linkflap> switch:#ip link set swp1 protodown off protodown_reason linkflap off switch:#ip link show swp1 4: swp1: <NO-CARRIER,BROADCAST,MULTICAST,SLAVE,UP> mtu 9216 qdisc pfifo_fast master bond1 state DOWN mode DEFAULT group default qlen 1000 link/ether 1c:34:da:2c:aa:68 brd ff:ff:ff:ff:ff:ff Signed-off-by: Chirag Shah <chirag@nvidia.com>
* | Merge pull request #16224 from donaldsharp/zebra_dplane_event_loop_starvationDonatas Abraitis2024-06-191-0/+5
|\ \ | | | | | | zebra: Prevent starvation in dplane_thread_loop
| * | zebra: Prevent starvation in dplane_thread_loopDonald Sharp2024-06-141-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When removing a large number of routes, the linux kernel can take the cpu for an extended amount of time, leaving a situation where FRR detects a starvation event. r1# sharp install routes 10.0.0.0 nexthop 192.168.44.33 1000000 repeat 10 2024-06-14 12:55:49.365 [NTFY] sharpd: [M7Q4P-46WDR] vty[5]@# sharp install routes 10.0.0.0 nexthop 192.168.44.33 1000000 repeat 10 2024-06-14 12:55:49.365 [DEBG] sharpd: [YP4TQ-01TYK] Inserting 1000000 routes 2024-06-14 12:55:57.256 [DEBG] sharpd: [TPHKD-3NYSB] Installed All Items 7.890085 2024-06-14 12:55:57.256 [DEBG] sharpd: [YJ486-NX5R1] Removing 1000000 routes 2024-06-14 12:56:07.802 [WARN] zebra: [QH9AB-Y4XMZ][EC 100663314] STARVATION: task dplane_thread_loop (634377bc8f9e) ran for 7078ms (cpu time 220ms) 2024-06-14 12:56:25.039 [DEBG] sharpd: [WTN53-GK9Y5] Removed all Items 27.783668 2024-06-14 12:56:25.039 [DEBG] sharpd: [YP4TQ-01TYK] Inserting 1000000 routes 2024-06-14 12:56:32.783 [DEBG] sharpd: [TPHKD-3NYSB] Installed All Items 7.743524 2024-06-14 12:56:32.783 [DEBG] sharpd: [YJ486-NX5R1] Removing 1000000 routes 2024-06-14 12:56:41.447 [WARN] zebra: [QH9AB-Y4XMZ][EC 100663314] STARVATION: task dplane_thread_loop (634377bc8f9e) ran for 5175ms (cpu time 179ms) Let's modify the loop in dplane_thread_loop such that after a provider has been run, check to see if the event should yield, if so, stop and reschedule this for the future. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* | | Merge pull request #15604 from cscarpitta/srv6-sid-managerRuss White2024-06-187-47/+3055
|\ \ \ | | | | | | | | Add support for SRv6 SID Manager
| * | | zebra, lib: add locator name in sid notify messagesPhilippe Guibert2024-06-173-5/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the near future, some daemons may only register SIDs. This may be the case for the pathd daemon when creating SRv6 binding SIDs. When a locator is getting deleted at ZEBRA level, the daemon may have an easy way to find out the SIds to unregister to. This commit proposes to add the locator name to the SID_SRV6_NOTIFY message whenever possible. Only case when an allocation failure happens, the locator will not be present. In all other places, the notify API at procol levels has the locator name extra-parameter. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com> Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
| * | | zebra: fix sid allocation should be different with 2 isis instancesPhilippe Guibert2024-06-131-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With 2 ISIS SRv6 instances, the second ISIS instance always gets the same End SID as the first one. > router isis 1 > segment-routing srv6 > locator loc1 > exit > exit > router isis 2 > segment-routing srv6 > locator loc2 > end > segment-routing > srv6 > locators > locator loc1 > prefix 2001::1/64 > exit > locator loc2 > prefix 3001::1/64 > output: > 2024/06/11 17:30:15 ISIS: [N6PCR-FQ5ZA] SRv6 locator (locator loc1, prefix 2001::1/64) set for IS-IS area 1 > 2024/06/11 17:30:15 ISIS: [V4RBG-TYW5S] Requesting SRv6 SIDs for IS-IS area 1 > 2024/06/11 17:30:15 ISIS: [ZRHYM-6RMYK] isis_zebra_srv6_sid_notify: received SRv6 SID notify: ctx End USP sid_value 2001::1 sid_func 0 note ZAPI_SRV6_SID_ALLOCATED > [..] > 2024/06/11 17:36:49 ISIS: [N6PCR-FQ5ZA] SRv6 locator (locator loc2, prefix 3001::1/64) set for IS-IS area 2 > 2024/06/11 17:36:49 ISIS: [V4RBG-TYW5S] Requesting SRv6 SIDs for IS-IS area 2 > 2024/06/11 17:36:49 ISIS: [ZRHYM-6RMYK] isis_zebra_srv6_sid_notify: received SRv6 SID notify: ctx End USP sid_value 2001::1 sid_func 0 note ZAPI_SRV6_SID_ALLOCATED Actually, at the second request, ZEBRA always gives an existing dynamic SID of the first available locator, because the locator name is never checked. > 2024/06/11 17:36:49 ZEBRA: [XMBTQ-GE6EY] get_srv6_sid: received SRv6 SID alloc request: SID ctx End USP ((null)), mode=dynamic > 2024/06/11 17:36:49 ZEBRA: [R61Q3-QWR23] get_srv6_sid_dynamic: returning existing SID End USP 2001::1 > 2024/06/11 17:36:49 ZEBRA: [J1GMY-B6CAK] srv6_manager_get_sid_internal: got existing SRv6 SID for ctx End USP: sid_value=2001::1 (func=0) (proto=9, instance=0, sessionId=0), notify client Fix this by checking the locator of the existing SID. Fixes: b771bf8ce687 ("zebra: Add functions to alloc/release SRv6 SIDs") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
| * | | zebra: fix display explicit sid refusedPhilippe Guibert2024-06-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | > 2024/06/07 15:09:43 ZEBRA: [MZYPC-GBDGR] srv6_manager_get_sid_internal: getting SRv6 SID for ctx End.DT4 vrf vrf1, sid_value=1003::4, locator_name= > [..] > 2024/06/07 15:09:43 ZEBRA: [QGJBT-YJ11W] zsend_srv6_sid_notify: notifying ZEBRA_SRV6_SID_NOTIFY ctx End.DT4 vrf vrf2, sid (null) note ZAPI_SRV6_SID_FAIL_ALLOC (proto=30, instance=0, sessionId=0) Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
| * | | zebra: fix display srv6 address only for explicit-sidPhilippe Guibert2024-06-131-2/+2
| | | | | | | | | | | | | | | | Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
| * | | zebra: Notify all daemons about locator deleteCarmine Scarpitta2024-06-131-23/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, when a locator is deleted in zebra, zebra notifies only the zclient that owns the locator. With the introduction of SID Manager, the locator is no longer owned by any client. Instead, the locator is owned by Zebra, and clients can allocate and release SIDs from the locator using the ZAPI ZEBRA_SRV6_MANAGER_GET_SID and ZEBRA_SRV6_MANAGER_RELEASE_SID. Therefore, when a locator is removed in Zebra, we need to notify all daemons so that they can release/uninstall the SIDs allocated by that locator. Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
| * | | zebra: Notify daemons about SIDsCarmine Scarpitta2024-06-133-0/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Send asynchronous notifications to zclients when an SRv6 SID is allocated/released and when a SID alloc/release operation fails. Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
| * | | zebra: Alloc/Release SIDs to daemons upon requestCarmine Scarpitta2024-06-133-0/+254
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previous commits introduced two new ZAPI operations, `ZEBRA_SRV6_MANAGER_GET_SRV6_SID` and `ZEBRA_SRV6_MANAGER_RELEASE_SRV6_SID`. These operations allow a daemon to interact with the SRv6 SID Manager to get and release an SRv6 SID, respectively. This commit extends the SID Manager by adding logic to process the requests `ZEBRA_SRV6_MANAGER_GET_SRV6_SID` and `ZEBRA_SRV6_MANAGER_RELEASE_SRV6_SID`, and allocate/release SIDs to requesting daemons. Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
| * | | zebra: Add functions to alloc/release SRv6 SIDsCarmine Scarpitta2024-06-135-1/+1290
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add functions to allocate/release SRv6 SIDs. SIDs can be allocated either explicitly (allocate a specific SID) or dynamically (allocate any available SID). Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
| * | | zebra: Repond to `GET_LOCATOR` ZAPI requestCarmine Scarpitta2024-06-134-0/+77
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The previous commits introduced a new operation, `ZEBRA_SRV6_MANAGER_GET_LOCATOR`, allowing a daemon to request information about a specific SRv6 locator from the SRv6 SID Manager. This commit extends the SID Manager to respond to a `ZEBRA_SRV6_MANAGER_GET_LOCATOR` request and provide the requested locator information. Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
| * | | zebra: Add support for SRv6 SIDsCarmine Scarpitta2024-06-132-0/+203
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a data structure to represent an SRv6 SID context and the related management functions (allocate/free). Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
| * | | zebra: CLI to specify format of an SRv6 locatorCarmine Scarpitta2024-06-134-13/+345
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add the CLI to choose the SID format of a locator. When the SID format of a locator is changed, the SIDs allocated from that locator might no longer be valid (for example, because the new format might involve a different SID allocation schema). In such a case, it is necessary to notify all the zclients so that they can withdraw/uninstall the old SIDs that use the previous format and allocate/install/advertise the new SIDs based on the new format. Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
| * | | zebra: Add support for SRv6 SID blocksCarmine Scarpitta2024-06-133-2/+271
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An SRv6 block is an IPv6 prefix from which SIDs are allocated. This commit adds support for SRv6 SID blocks. Specifically, it adds a data structure to store information about an SRv6 block (e.g., its occupancy status, which SIDs have been allocated and which are available, which SID format is used for that block, etc.). It also adds some functions to manage the block (allocate / free / lookup). These functions will be used in the next commits to support the allocation of SIDs from a block in the SID Manager. Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
| * | | zebra: CLI to override default SID format configCarmine Scarpitta2024-06-133-53/+411
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Add CLI commands to support overriding default configuration of the SID format. Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
| * | | lib: Add CLI nodes to support SRv6 SID formatCarmine Scarpitta2024-06-132-19/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Add CLI commands to support overriding default configuration of the SID format. Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
| * | | zebra: Add support for SRv6 SID formatsCarmine Scarpitta2024-06-133-16/+180
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add functionalities to manage SRv6 SID formats (register / unregister / lookup) and create two SID formats upon SRv6 Manager initialization: `uncompressed-f4024` and `usid-f3216`. In future commits, we will add the CLI to allow the user to choose between the two formats. Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
* | | zebra: Set the weight for non-recursive next-hopDonatas Abraitis2024-06-181-0/+6
| | | | | | | | | | | | | | | | | | | | | If using weighted ECMP, the weight for non-recursive next-hop should be inherited from recursive next-hop. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
* | | zebra: Use built in data structure counterDonald Sharp2024-06-133-22/+25
|/ / | | | | | | | | | | | | | | | | | | Instead of keeping a counter that is independent of the queue's data structure. Just use the queue's built-in counter. Ensure that it's pthread safe by keeping it wrapped inside the mutex for adding/deleting to the queue. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* | Merge pull request #16093 from louis-6wind/fix-show-route-memoryDonatas Abraitis2024-06-101-61/+38
|\ \ | | | | | | zebra: fix Out Of Memory issue when displaying large route tables in JSON
| * | zebra: fix show route memory consumptionLouis Scalbert2024-06-071-10/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When displaying a route table in JSON, a table JSON object is storing all the prefix JSON objects containing the prefix information. This results in excessive memory allocation for JSON objects, potentially leading to an out-of-memory error on the machine with large routing tables. To Fix the memory consumption issue for the "show ip[v6] route [vrf XX] json" command, display the prefixes one by one and free the memory of each JSON object after it has been displayed. Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
| * | zebra: fix show route vrf all memory consumptionLouis Scalbert2024-06-071-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 0e2fc3d67f ("vtysh, zebra: Fix malformed json output for multiple vrfs in command 'show ip route vrf all json'") has been reverted in the previous commit. Although the fix was correct, it was consuming too muca memory when displaying large route tables. A root JSON object was storing all the JSON objects containing the route tables, each containing their respective prefixes in JSON objects. This resulted in excessive memory allocation for JSON objects, potentially leading to an out-of-memory error on the machine. To Fix the memory consumption issue for the "show ip[v6] route vrf all json" command, display the tables one by one and free the memory of each JSON object after it has been displayed. Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
| * | Revert "vtysh, zebra: Fix malformed json output for multiple vrfs in command ↵Louis Scalbert2024-06-071-52/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 'show ip route vrf all json'" This reverts commit 0e2fc3d67f1d358896a764373f41cb59c095eda9. This fix was correct but not optimal for memory consumption at scale. Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
* | | Merge pull request #15900 from mikemallin/v6-vtep-lib-upstreamDonald Sharp2024-06-072-32/+51
|\ \ \ | |_|/ |/| | lib, bgpd, tests, zebra: prefix_sg changes for V6 VTEP
| * | bgpd, lib, zebra: Extend ES_VTEP_LIST_STR_SZ to support IPv6 addressesMike RE Mallin2024-05-311-1/+1
| | | | | | | | | | | | Signed-off-by: Mike RE Mallin <mremallin@gmail.com>
| * | lib, zebra: Update prefix_sg structure for IPv6 group supportMike RE Mallin2024-05-311-31/+50
| | | | | | | | | | | | Signed-off-by: Mike RE Mallin <mremallin@gmail.com>
* | | Merge pull request #16151 from pguibert6WIND/srv6_fix_source_addressDonald Sharp2024-06-061-1/+11
|\ \ \ | | | | | | | | zebra: display srv6 encapsulation source-address when configured
| * | | zebra: display srv6 encapsulation source-address when configuredPhilippe Guibert2024-06-041-1/+11
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | The 'show running-config' does not display the ipv6 source address when a locator is not configured. Fix this by systematically displaying the ipv6 source address. Fixes: 6a0956169b31 ("zebra: Add encap source address to SRv6 config write function") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
* | / zebra: fix incoming FPM message length validationMark Stapp2024-06-051-8/+8
| |/ |/| | | | | | | | | | | Validate incoming message length against correct (struct rtmsg) len, not top-level netlink message header size. Signed-off-by: Mark Stapp <mjs@cisco.com>
* | zebra: fix compilation with GCC14Georgi Valkov2024-06-041-6/+9
|/ | | | | | | | | | | | | | | | | | | | | | | Fixes: zebra/zebra_netns_notify.c: In function 'zebra_ns_ready_read': zebra/zebra_netns_notify.c:266:40: error: implicit declaration of function 'basename' [-Wimplicit-function-declaration] 266 | if (strmatch(VRF_DEFAULT_NAME, basename(netnspath))) { | ^~~~~~~~ Fixed by including libgen.h, then since basename may modify its parameter, allocate a copy on the stack, using strdupa, and pass the temporary string to basename. According to the man page for basename: With glibc, one gets the POSIX version of basename() when <libgen.h> is included, and the GNU version otherwise. The POSIX version of basename may modify the contents of path, so we should to pass a copy when calling this function. [1] https://man7.org/linux/man-pages/man3/basename.3.html Signed-off-by: Georgi Valkov <gvalkov@gmail.com>
* Merge pull request #15082 from louis-6wind/fix-iff-lower-upIgor Ryzhov2024-05-281-1/+1
|\ | | | | lib: take into account the Linux IFF_LOWER_UP flag
| * zebra: fix fpm_listener compilationLouis Scalbert2024-04-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I don't know why it appears only now. > ../sdist/zebra/fpm_listener.c:420:8: error: comparison of integers of different signs: 'int' and 'size_t' (aka 'unsigned long') [-Werror,-Wsign-compare] > if (!RTNH_OK(rtnh, len)) { > ^~~~~~~~~~~~~~~~~~ > ../sdist/include/linux/rtnetlink.h:437:31: note: expanded from macro 'RTNH_OK' > ((int)(rtnh)->rtnh_len) <= (len)) len is set with RTA_PAYLOAD and should be an integer. > len = RTA_PAYLOAD(mpath_rtattr); > #define RTA_PAYLOAD(rta) ((int)((rta)->rta_len) - RTA_LENGTH(0)) Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
* | Merge pull request #16032 from Pdoijode/pdoijode/zebra-rt-deny-fixRuss White2024-05-211-3/+2
|\ \ | | | | | | zebra: Deny the routes if ip protocol CLI refers to an undefined rmap
| * | zebra: Deny the routes if ip protocol CLI refers to an undefined rmapPooja Jagadeesh Doijode2024-05-201-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently zebra does not deny the routes if `ip protocol <proto> route-map FOO` commmand is configured with reference to an undefined route-map (FOO in this case). However, on FRR restart, in zebra_route_map_check() routes get denied if route-map name is available but the route-map is not defined. This change was introduced in fd303a4ba14c762550db972317e1e88528768005. Fix: When `ip protocol <proto> route-map FOO` CLI is configured with reference to an undefined route-map FOO, let the processing in ip_protocol_rm_add() and ip_protocol_rm_del() go through so that zebra can deny the routes instead of simply returning. This will result in consistent behavior. Testing Done: Before fix: ``` spine-1# configure spine-1(config)# ip protocol bgp route-map rmap7 root@spine-1:mgmt:/var/home/cumulus# vtysh -c "show run" | grep rmap7 ip protocol bgp route-map rmap7 root@spine-1:mgmt:/var/home/cumulus# spine-1(config)# do show ip route Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP, T - Table, A - Babel, D - SHARP, F - PBR, f - OpenFabric, Z - FRR, > - selected route, * - FIB route, q - queued, r - rejected, b - backup t - trapped, o - offload failure C>* 27.0.0.1/32 is directly connected, lo, 02:27:45 B>* 27.0.0.3/32 [20/0] via fe80::202:ff:fe00:21, downlink_1, weight 1, 02:27:35 B>* 27.0.0.4/32 [20/0] via fe80::202:ff:fe00:29, downlink_2, weight 1, 02:27:40 B>* 27.0.0.5/32 [20/0] via fe80::202:ff:fe00:31, downlink_3, weight 1, 02:27:40 B>* 27.0.0.6/32 [20/0] via fe80::202:ff:fe00:39, downlink_4, weight 1, 02:27:40 ``` After fix: ``` spine-1(config)# ip protocol bgp route-map route-map67 spine-1(config)# do show ip route Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP, T - Table, A - Babel, D - SHARP, F - PBR, f - OpenFabric, Z - FRR, > - selected route, * - FIB route, q - queued, r - rejected, b - backup t - trapped, o - offload failure C>* 27.0.0.1/32 is directly connected, lo, 00:35:03 B 27.0.0.3/32 [20/0] via fe80::202:ff:fe00:21, downlink_1 inactive, weight 1, 00:34:58 B 27.0.0.4/32 [20/0] via fe80::202:ff:fe00:29, downlink_2 inactive, weight 1, 00:34:57 B 27.0.0.5/32 [20/0] via fe80::202:ff:fe00:31, downlink_3 inactive, weight 1, 00:34:57 B 27.0.0.6/32 [20/0] via fe80::202:ff:fe00:39, downlink_4 inactive, weight 1, 00:34:58 spine-1(config)# root@spine-1:mgmt:/var/home/cumulus# ip route show root@spine-1:mgmt:/var/home/cumulus# ``` Signed-off-by: Pooja Jagadeesh Doijode <pdoijode@nvidia.com>
* | | Merge pull request #15980 from donaldsharp/agentx_updateDonatas Abraitis2024-05-201-0/+2
|\ \ \ | | | | | | | | *: Modify agentx to be allowed to be called
| * | | *: Modify agentx to be allowed to be calledDonald Sharp2024-05-101-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If you had a situation where an operator turned on ospfd with snmp but not ospf6d and agentx was configured then you get into a situation where ospf6d would complain that the config for agentx did not exist. Let's modify the code to allow this situation to happen. Fixes: #15896 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* | | | Merge pull request #16019 from anlancs/ldpd/fix-cmd-1Donatas Abraitis2024-05-182-4/+13
|\ \ \ \ | | | | | | | | | | zebra: fix mpls command
| * | | | zebra: fix mpls commandanlan_cs2024-05-162-4/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Configured with "mpls label bind 1.1.1.1/32 explicit-null", the running configuration is: ``` ! mpls label bind 1.1.1.1/32 IPv4 Explicit Null ! ``` After this commit, the running configuration is: ``` ! mpls label bind 1.1.1.1/32 explicit-null ! ``` And add the support for the "no" form: ``` anlan(config)# mpls label bind 1.1.1.1/32 explicit-null anlan(config)# no mpls label bind 1.1.1.1/32 explicit-null ``` Signed-off-by: anlan_cs <anlan_cs@tom.com>
* | | | | Merge pull request #16009 from anlancs/zebra/fix-fpm-nlDonatas Abraitis2024-05-181-1/+1
|\ \ \ \ \ | |_|_|/ / |/| | | | zebra: fix wrong fpm packet header
| * | | | zebra: fix wrong fpm packet headeranlan_cs2024-05-141-1/+1
| | | | | | | | | | | | | | | | | | | | Signed-off-by: anlan_cs <anlan_cs@tom.com>
* | | | | Merge pull request #16001 from EasyNetDev/dpdk->=22.11-API-fixDonald Sharp2024-05-172-14/+19
|\ \ \ \ \ | | | | | | | | | | | | zebra: Update Zebra DPDK >=22.11 API
| * | | | | zebra: Update Zebra for DPDK >=22.11 APIEasyNetDev2024-05-162-14/+19
| |/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Starting from version DPDK 22.11 we have API changes: The rte_driver and rte_device objects are now opaque and must be manipulated through added accessors. We need to update Zebra DPDK sources to DPDK version >=22.11 * Fix clang-format Signed-off-by: EasyNet <devel@easynet.dev>
* | / / / zebra, lib: move nexthop display helper to lib folderPhilippe Guibert2024-05-151-329/+18
| |/ / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The zebra_nexthop_vty_helper() and zebra_nexthop_json_helper() functions could be very helpful to display nexthop information from whatever daemon. Move the core function in the nexthop_vty_helper() and the nexthop_json_helper() function. The zebra API call remains unchanged. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
* | | | Merge pull request #16008 from mjstapp/show_routemap_sourceRuss White2024-05-154-50/+119
|\ \ \ \ | |/ / / |/| | | zebra: include route source set by route-map in show output
| * | | zebra: include route source set by route-map in show outputMark Stapp2024-05-144-50/+119
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Include the prefix source address when set by a route-map in show output for routes, in various formats. Add some debugs when encoding netlink route messages with a source address. Signed-off-by: Mark Stapp <mjs@cisco.com>
* | | | Merge pull request #15968 from donaldsharp/parse_attr_problemsDonatas Abraitis2024-05-112-58/+169
|\ \ \ \ | |_|/ / |/| | | Parse attr problems
| * | | zebra: Ensure multipath encodes vxlan right for fpm usageDonald Sharp2024-05-091-19/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The fpm code path for the dplane_fpm_nl module was improperly encoding the multipath nexthop data for vxlan type routes. Move this into the embedded nexthop encoding where it belongs. This change makes it so that the usage of `-M dplane_fpm_nl` is now producing the same netlink messages that `-M fpm` produces when using vxlan based nexthops. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
| * | | zebra: Move fpm check to inside of netlink_route_nexthop_encapDonald Sharp2024-05-091-13/+13
| | | | | | | | | | | | | | | | Signed-off-by: Donald Sharp <sharpd@nvidia.com>