summaryrefslogtreecommitdiff
path: root/zebra
AgeCommit message (Collapse)Author
2025-02-12Merge pull request #18090 from FRRouting/mergify/bp/stable/10.1/pr-17935Donald Sharp
zebra: include resolving nexthops in nhg hash (backport #17935)
2025-02-11zebra: include resolving nexthops in nhg hashMark Stapp
Ensure that the nhg hash comparison function includes all nexthops, including recursive-resolving nexthops. Signed-off-by: Mark Stapp <mjs@cisco.com> (cherry picked from commit cb7cf73992847cfd4af796085bf14f2fdc4fa8db)
2025-02-11zebra: guard against junk in nexthop->rmap_srcDavid Lamparter
rmap_src wasn't initialized, so for IPv4 the unused 12 bytes would contain whatever junk is on the stack on function entry. Also move the IPv4 parse before the IPv6 parse so if it's successful we can be sure the other bytes haven't been touched. Signed-off-by: David Lamparter <equinox@opensourcerouting.org> (cherry picked from commit b666ee510eb480da50476b1bbc84bdf8365df95c)
2025-02-04zebra: evpn svd hash avoid double freeChirag Shah
Upon zebra shutdown hash_clean_and_free is called where user free function is passed, The free function should not call hash_release which lead to double free of hash bucket. Fix: The fix is to avoid calling hash_release from free function if its called from hash_clean_and_free path. 10 0x00007f0422b7df1f in free () from /lib/x86_64-linux-gnu/libc.so.6 11 0x00007f0422edd779 in qfree (mt=0x7f0423047ca0 <MTYPE_HASH_BUCKET>, ptr=0x55fc8bc81980) at ../lib/memory.c:130 12 0x00007f0422eb97e2 in hash_clean (hash=0x55fc8b979a60, free_func=0x55fc8a529478 <svd_nh_del_terminate>) at ../lib/hash.c:290 13 0x00007f0422eb98a1 in hash_clean_and_free (hash=0x55fc8a675920 <svd_nh_table>, free_func=0x55fc8a529478 <svd_nh_del_terminate>) at ../lib/hash.c:305 14 0x000055fc8a5323a5 in zebra_vxlan_terminate () at ../zebra/zebra_vxlan.c:6099 15 0x000055fc8a4c9227 in zebra_router_terminate () at ../zebra/zebra_router.c:276 16 0x000055fc8a4413b3 in zebra_finalize (dummy=0x7fffb881c1d0) at ../zebra/main.c:269 17 0x00007f0422f44387 in event_call (thread=0x7fffb881c1d0) at ../lib/event.c:2011 18 0x00007f0422ecb6fa in frr_run (master=0x55fc8b733cb0) at ../lib/libfrr.c:1243 19 0x000055fc8a441987 in main (argc=14, argv=0x7fffb881c4a8) at ../zebra/main.c:584 Signed-off-by: Chirag Shah <chirag@nvidia.com> (cherry picked from commit 1d4f5b9b19588d77d3eaf06440c26a8c974831a3)
2025-01-24bgpd: Fix wrong pthread event cancellingDonald Sharp
0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=130719886083648) at ./nptl/pthread_kill.c:44 1 __pthread_kill_internal (signo=6, threadid=130719886083648) at ./nptl/pthread_kill.c:78 2 __GI___pthread_kill (threadid=130719886083648, signo=signo@entry=6) at ./nptl/pthread_kill.c:89 3 0x000076e399e42476 in __GI_raise (sig=6) at ../sysdeps/posix/raise.c:26 4 0x000076e39a34f950 in core_handler (signo=6, siginfo=0x76e3985fca30, context=0x76e3985fc900) at lib/sigevent.c:258 5 <signal handler called> 6 __pthread_kill_implementation (no_tid=0, signo=6, threadid=130719886083648) at ./nptl/pthread_kill.c:44 7 __pthread_kill_internal (signo=6, threadid=130719886083648) at ./nptl/pthread_kill.c:78 8 __GI___pthread_kill (threadid=130719886083648, signo=signo@entry=6) at ./nptl/pthread_kill.c:89 9 0x000076e399e42476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 10 0x000076e399e287f3 in __GI_abort () at ./stdlib/abort.c:79 11 0x000076e39a39874b in _zlog_assert_failed (xref=0x76e39a46cca0 <_xref.27>, extra=0x0) at lib/zlog.c:789 12 0x000076e39a369dde in cancel_event_helper (m=0x5eda32df5e40, arg=0x5eda33afeed0, flags=1) at lib/event.c:1428 13 0x000076e39a369ef6 in event_cancel_event_ready (m=0x5eda32df5e40, arg=0x5eda33afeed0) at lib/event.c:1470 14 0x00005eda0a94a5b3 in bgp_stop (connection=0x5eda33afeed0) at bgpd/bgp_fsm.c:1355 15 0x00005eda0a94b4ae in bgp_stop_with_notify (connection=0x5eda33afeed0, code=8 '\b', sub_code=0 '\000') at bgpd/bgp_fsm.c:1610 16 0x00005eda0a979498 in bgp_packet_add (connection=0x5eda33afeed0, peer=0x5eda33b11800, s=0x76e3880daf90) at bgpd/bgp_packet.c:152 17 0x00005eda0a97a80f in bgp_keepalive_send (peer=0x5eda33b11800) at bgpd/bgp_packet.c:639 18 0x00005eda0a9511fd in peer_process (hb=0x5eda33c9ab80, arg=0x76e3985ffaf0) at bgpd/bgp_keepalives.c:111 19 0x000076e39a2cd8e6 in hash_iterate (hash=0x76e388000be0, func=0x5eda0a95105e <peer_process>, arg=0x76e3985ffaf0) at lib/hash.c:252 20 0x00005eda0a951679 in bgp_keepalives_start (arg=0x5eda3306af80) at bgpd/bgp_keepalives.c:214 21 0x000076e39a2c9932 in frr_pthread_inner (arg=0x5eda3306af80) at lib/frr_pthread.c:180 22 0x000076e399e94ac3 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442 23 0x000076e399f26850 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 (gdb) f 12 12 0x000076e39a369dde in cancel_event_helper (m=0x5eda32df5e40, arg=0x5eda33afeed0, flags=1) at lib/event.c:1428 1428 assert(m->owner == pthread_self()); In this decode the attempt to cancel the connection's events from the wrong thread is causing the crash. Modify the code to create an event on the bm->master to cancel the events for the connection. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2024-12-31zebra: Fix resetting valid flags for NHG dependentsDonald Sharp
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> (cherry picked from commit 54ec9f38884fb63e045732537c4c1f4a94608987)
2024-12-03zebra: separate zebra ZAPI server open and acceptMark Stapp
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> (cherry picked from commit 506097a1b96974c261411edd25330ceaf90fa3db)
2024-10-31zebra: Add missing new line for help stringDonatas Abraitis
``` -A, --asic-offload FRR is interacting with an asic underneath the linux kernel --v6-with-v4-nexthops Underlying dataplane supports v6 routes with v4 nexthops -s, --nl-bufsize Set netlink receive buffer size ``` Fixes: 1f5611c06d1c243b42279748788f0627793ead9c ("zebra: Allow zebra cli to accept v6 routes with v4 nexthops") Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org> (cherry picked from commit 25ae643996d338b8230fb15a9064843fe85de224)
2024-10-27lib, zebra: Keep `zebra on-rib-process script` in frr.confDonatas Abraitis
After the change: ``` $ grep on-rib-process /etc/frr/frr.conf zebra on-rib-process script script4 $ systemctl restart frr $ vtysh -c 'show run' | grep on-rib-process zebra on-rib-process script script4 ``` Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org> (cherry picked from commit 1fe1f8d87c4ab46ae18536a2418c05ae5fd95185)
2024-10-18Merge pull request #17130 from FRRouting/mergify/bp/stable/10.1/pr-17116Donatas Abraitis
zebra: unlock node only after operation in zebra_free_rnh() (backport #17116)
2024-10-16zebra: fix heap-use-after free on ns shutdownPhilippe Guibert
The following ASAN issue has been observed: > ERROR: AddressSanitizer: heap-use-after-free on address 0x6160000acba4 at pc 0x55910c5694d0 bp 0x7ffe3a8ac850 sp 0x7ffe3a8ac840 > READ of size 4 at 0x6160000acba4 thread T0 > #0 0x55910c5694cf in ctx_info_from_zns zebra/zebra_dplane.c:3315 > #1 0x55910c569696 in dplane_ctx_ns_init zebra/zebra_dplane.c:3331 > #2 0x55910c56bf61 in dplane_ctx_nexthop_init zebra/zebra_dplane.c:3680 > #3 0x55910c5711ca in dplane_nexthop_update_internal zebra/zebra_dplane.c:4490 > #4 0x55910c571c5c in dplane_nexthop_delete zebra/zebra_dplane.c:4717 > #5 0x55910c61e90e in zebra_nhg_uninstall_kernel zebra/zebra_nhg.c:3413 > #6 0x55910c615d8a in zebra_nhg_decrement_ref zebra/zebra_nhg.c:1919 > #7 0x55910c6404db in route_entry_update_nhe zebra/zebra_rib.c:454 > #8 0x55910c64c904 in rib_re_nhg_free zebra/zebra_rib.c:2822 > #9 0x55910c655be2 in rib_unlink zebra/zebra_rib.c:4212 > #10 0x55910c6430f9 in zebra_rtable_node_cleanup zebra/zebra_rib.c:968 > #11 0x7f26f275b8a9 in route_node_free lib/table.c:75 > #12 0x7f26f275bae4 in route_table_free lib/table.c:111 > #13 0x7f26f275b749 in route_table_finish lib/table.c:46 > #14 0x55910c65db17 in zebra_router_free_table zebra/zebra_router.c:191 > #15 0x55910c65dfb5 in zebra_router_terminate zebra/zebra_router.c:244 > #16 0x55910c4f40db in zebra_finalize zebra/main.c:249 > #17 0x7f26f2777108 in event_call lib/event.c:2011 > #18 0x7f26f264180e in frr_run lib/libfrr.c:1212 > #19 0x55910c4f49cb in main zebra/main.c:531 > #20 0x7f26f2029d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > #21 0x7f26f2029e3f in __libc_start_main_impl ../csu/libc-start.c:392 > #22 0x55910c4b0114 in _start (/usr/lib/frr/zebra+0x1ae114) It happens with FRR using the kernel. During shutdown, the namespace identifier is attempted to be obtained by zebra, in an attempt to prepare zebra dataplane nexthop messages. Fix this by accessing the ns structure. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com> (cherry picked from commit 7ae70eb5ef48e565427b416e22a1ccbed1e96120)
2024-10-16zebra: unlock node only after operation in zebra_free_rnh()Enke Chen
Move route_unlock_node() after rnh_list_del(). Signed-off-by: Enke Chen <enchen@paloaltonetworks.com> (cherry picked from commit 5b6ff51b8ae7f8c7348cea4de9543956f32641a7)
2024-10-04zebra: Fix crash during reconnectIgor Zhukov
fpm_enqueue_rmac_table expects an fpm_rmac_arg* as its argument. The issue can be reproduced by dropping the TCP session using: ss -K dst 127.0.0.1 dport = 2620 I used Fedora 40 and frr 9.1.2 and I got the gdb backtrace: (gdb) bt 0 0x00007fdd7d6997ea in fpm_enqueue_rmac_table (bucket=0x2134dd0, arg=0x2132b60) at zebra/dplane_fpm_nl.c:1217 1 0x00007fdd7dd1560d in hash_iterate (hash=0x21335f0, func=0x7fdd7d6997a0 <fpm_enqueue_rmac_table>, arg=0x2132b60) at lib/hash.c:252 2 0x00007fdd7dd1560d in hash_iterate (hash=0x1e5bf10, func=func@entry=0x7fdd7d698900 <fpm_enqueue_l3vni_table>, arg=arg@entry=0x7ffed983bef0) at lib/hash.c:252 3 0x00007fdd7d698b5c in fpm_rmac_send (t=<optimized out>) at zebra/dplane_fpm_nl.c:1262 4 0x00007fdd7dd6ce22 in event_call (thread=thread@entry=0x7ffed983c010) at lib/event.c:1970 5 0x00007fdd7dd20758 in frr_run (master=0x1d27f10) at lib/libfrr.c:1213 6 0x0000000000425588 in main (argc=10, argv=0x7ffed983c2e8) at zebra/main.c:492 Signed-off-by: Igor Zhukov <fsb4000@yandex.ru> (cherry picked from commit a3877e4444dc3a1253135d3b9479935fc9a966f8)
2024-09-25zebra: Add missing proto translationsDonald Sharp
Add missing isis and eigrp proto translations. Signed-off-by: Donald Sharp <sharpd@nvidia.com> (cherry picked from commit f53dde0e5921aafae0a00d993257ea7423b5ee97)
2024-09-25zebra: Correctly report metricsDonald Sharp
Report the routes metric in IPFORWARDMETRIC1 and return -1 for the other metrics as required by the IP-FORWARD-MIB. inetCidrRouteMetric2 OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "An alternate routing metric for this route. The semantics of this metric are determined by the routing- protocol specified in the route's inetCidrRouteProto value. If this metric is not used, its value should be set to -1." DEFVAL { -1 } ::= { inetCidrRouteEntry 13 } I've included metric2 but it's the same for all of them. Signed-off-by: Donald Sharp <sharpd@nvidia.com> (cherry picked from commit e41ae0acc1940b568def5018efad3df019023f85)
2024-09-25zebra: Let's use memset instead of walking bytes and setting to 0Donald Sharp
Signed-off-by: Donald Sharp <sharpd@nvidia.com> (cherry picked from commit 659cd66427ac8a6fe705b4a319245b7c88f80c05)
2024-09-25zebra: Fix snmp walk of zebra ribDonald Sharp
The snmp walk of the zebra rib was skipping entries because in_addr_cmp was replaced with a prefix_cmp which worked slightly differently causing parts of the zebra rib tree to be skipped. Signed-off-by: Donald Sharp <sharpd@nvidia.com> (cherry picked from commit ecd9d441b082e3f24139eb96915b18fc17996c08)
2024-08-23zebra: Mimic GNU basename() API for non-glibc library e.g. muslKhem Raj
musl only provides POSIX version of basename and it has also removed providing it via string.h header [1] which now results in compile errors with newer compilers e.g. clang-18 [1] https://git.musl-libc.org/cgit/musl/commit/?id=725e17ed6dff4d0cd22487bb64470881e86a92e7 Signed-off-by: Khem Raj <raj.khem@gmail.com> (cherry picked from commit 0ef71391f0fb15039550a09c218977fa3e1abaf1)
2024-08-12zebra: Ensure non-equal id's are not same nhg'sDonald Sharp
The function zebra_nhg_hash_equal is only used as a hash function for storage of NHG's and retrieval. If you have say two nhg's: 31 (25/26) 32 (25/26) This function would return them as being equal. Which of course leads to the problem when you attempt to hash_release 32 but release 31 from the hash. Then later when you attempt to do hash comparisons 32 has actually been freed leaving to use after free situations and shit goes down hill fast. This hash is only used as part of the hash comparison function for nexthop group storage. Since this is so let's always return the 31/32 nhg's are not equal at all. We possibly have a different problem where we are creating 31 and 32 ( when 31 should have just been used instead of 32 ) but we need to prevent any type of hash release problem at all. This supercedes any other issue( that should be tracked down on it's own ). Since you can have use after free situation that leads to a crash -vs- some possible nexthop group duplication which is very minor in comparison. Signed-off-by: Donald Sharp <sharpd@nvidia.com> (cherry picked from commit 5a1b61aeba1b83825e1656a047aab35be0c1db55)
2024-07-23zebra: Properly note that a nhg's nexthop has gone downDonald Sharp
Current code when a link is set down is to just mark the nexthop group as not properly setup. Leaving situations where when an interface goes down and show output is entered we see incorrect state. This is true for anything that would be checking those flags at that point in time. Modify the interface down nexthop group code to notice the nexthops appropriately ( and I mean set the appropriate flags ) and to allow a `show ip route` command to actually display what is going on with the nexthops. eva# show ip route 1.0.0.0 Routing entry for 1.0.0.0/32 Known via "sharp", distance 150, metric 0, best Last update 00:00:06 ago * 192.168.44.33, via dummy1, weight 1 * 192.168.45.33, via dummy2, weight 1 sharpd@eva:~/frr1$ sudo ip link set dummy2 down eva# show ip route 1.0.0.0 Routing entry for 1.0.0.0/32 Known via "sharp", distance 150, metric 0, best Last update 00:00:12 ago * 192.168.44.33, via dummy1, weight 1 192.168.45.33, via dummy2 inactive, weight 1 Notice now that the 1.0.0.0/32 route now correctly displays the route for the nexthop group entry. Signed-off-by: Donald Sharp <sharpd@nvidia.com> (cherry picked from commit 266b0619942edd8d838235e14dc0cb71a772f585)
2024-07-14zebra: Fix to avoid two Vrfs with same table idsRajasekar Raja
During internal testing, when the following sequence is followed, two non default vrfs end up pointing to the same table-id - Initially vrf201 has table id 1002 - ip link add dev vrf202 type vrf table 1002 - ip link set dev vrf202 up - ip link set dev <intrerface> master vrf202 This will ideally lead to zebra exit since this is a misconfiguration as expected. However if we perform a restart frr.service at this point, we end up having two vrfs pointing to same table-id and bad things can happen. This is because in the interface_vrf_change, we incorrectly check for vrf_lookup_by_id() to evaluate if there is a misconfig. This works well for a non restart case but not for the startup case. root@mlx-3700-20:mgmt:/var/log/frr# sudo vtysh -c "sh vrf" vrf mgmt id 37 table 1001 vrf vrf201 id 46 table 1002 vrf vrf202 id 59 table 1002 >>>> Fix: in all cases of misconfiguration, exit zebra as expected. Ticket :#3970414 Signed-off-by: Donald Sharp <sharpd@nvidia.com> Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com> (cherry picked from commit c77e15710d6a3a9be71f41a9ce608f06b2795dfb)
2024-06-25Merge pull request #16284 from FRRouting/mergify/bp/dev/10.1/pr-16261Donatas Abraitis
zebra: clear evpn dup-addr return error-msg when there is no vni (backport #16261)
2024-06-25Merge pull request #16239 from FRRouting/mergify/bp/dev/10.1/pr-16224Donatas Abraitis
zebra: Prevent starvation in dplane_thread_loop (backport #16224)
2024-06-25zebra: clear evpn dup-addr return error-msg when there is no vniSindhu Parvathi Gopinathan
clear evpn dup-addr cli returns error-msg for below conditions, - If evpn is not enabled & - If there is no VNI exists. supported command: ``` clear evpn dup-addr vni <vni-id> ``` Ticket: #3495573 Testing: bharat# clear evpn dup-addr vni all Error type: validation Error description: % EVPN not enabled bharat# clear evpn dup-addr vni 20 Error type: validation Error description: % VNI 20 does not exist Signed-off-by: Sindhu Parvathi Gopinathan's <sgopinathan@nvidia.com> Signed-off-by: Chirag Shah <chirag@nvidia.com> (cherry picked from commit 56c16ee529b546058c8d1fabbb701d8ed2fded75)
2024-06-21zebra: fix evpn mh bond member proto reinstallChirag Shah
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> (cherry picked from commit e4d843b438ae7cbae89ae47af0754fb1db153c6c)
2024-06-19zebra: Prevent starvation in dplane_thread_loopDonald Sharp
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> (cherry picked from commit 6faad863f30d29157e4c675ad956e3ccd38991a7)
2024-06-10Merge pull request #16093 from louis-6wind/fix-show-route-memoryDonatas Abraitis
zebra: fix Out Of Memory issue when displaying large route tables in JSON
2024-06-07Merge pull request #15900 from mikemallin/v6-vtep-lib-upstreamDonald Sharp
lib, bgpd, tests, zebra: prefix_sg changes for V6 VTEP
2024-06-07zebra: fix show route memory consumptionLouis Scalbert
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>
2024-06-07zebra: fix show route vrf all memory consumptionLouis Scalbert
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>
2024-06-07Revert "vtysh, zebra: Fix malformed json output for multiple vrfs in command ↵Louis Scalbert
'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>
2024-06-06Merge pull request #16151 from pguibert6WIND/srv6_fix_source_addressDonald Sharp
zebra: display srv6 encapsulation source-address when configured
2024-06-05zebra: fix incoming FPM message length validationMark Stapp
Validate incoming message length against correct (struct rtmsg) len, not top-level netlink message header size. Signed-off-by: Mark Stapp <mjs@cisco.com>
2024-06-04zebra: fix compilation with GCC14Georgi Valkov
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>
2024-06-04zebra: display srv6 encapsulation source-address when configuredPhilippe Guibert
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>
2024-05-31bgpd, lib, zebra: Extend ES_VTEP_LIST_STR_SZ to support IPv6 addressesMike RE Mallin
Signed-off-by: Mike RE Mallin <mremallin@gmail.com>
2024-05-31lib, zebra: Update prefix_sg structure for IPv6 group supportMike RE Mallin
Signed-off-by: Mike RE Mallin <mremallin@gmail.com>
2024-05-29Merge pull request #15082 from louis-6wind/fix-iff-lower-upIgor Ryzhov
lib: take into account the Linux IFF_LOWER_UP flag
2024-05-21Merge pull request #16032 from Pdoijode/pdoijode/zebra-rt-deny-fixRuss White
zebra: Deny the routes if ip protocol CLI refers to an undefined rmap
2024-05-20zebra: Deny the routes if ip protocol CLI refers to an undefined rmapPooja Jagadeesh Doijode
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>
2024-05-20Merge pull request #15980 from donaldsharp/agentx_updateDonatas Abraitis
*: Modify agentx to be allowed to be called
2024-05-18Merge pull request #16019 from anlancs/ldpd/fix-cmd-1Donatas Abraitis
zebra: fix mpls command
2024-05-18Merge pull request #16009 from anlancs/zebra/fix-fpm-nlDonatas Abraitis
zebra: fix wrong fpm packet header
2024-05-17Merge pull request #16001 from EasyNetDev/dpdk->=22.11-API-fixDonald Sharp
zebra: Update Zebra DPDK >=22.11 API
2024-05-16zebra: fix mpls commandanlan_cs
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>
2024-05-16zebra: Update Zebra for DPDK >=22.11 APIEasyNetDev
* 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>
2024-05-15zebra, lib: move nexthop display helper to lib folderPhilippe Guibert
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>
2024-05-15Merge pull request #16008 from mjstapp/show_routemap_sourceRuss White
zebra: include route source set by route-map in show output
2024-05-14zebra: fix wrong fpm packet headeranlan_cs
Signed-off-by: anlan_cs <anlan_cs@tom.com>
2024-05-14zebra: include route source set by route-map in show outputMark Stapp
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>