*: PBR - netlink interaction and basic definitions #1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Handle the return value of argv_find_and_parse_afi() to avoid passing along bad values. Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
…ian-file debianpkg: Add missing frr-dbg.lintian-overrides to Makefile
bgpd: fix some coverity scan issues
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya<mitesh@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.comy>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
donaldsharp
pushed a commit
that referenced
this pull request
Jan 3, 2025
When bgp neighbor GSHUT is done, advertise routes recivied from this neighbor with GSHUT attribute. Ticket: #3948080 Testing: mlx-4600ca1-01(config-router)# neighbor 210.2.0.2 graceful-shutdown logs: 2024/06/18 00:11:34 BGP: [MS8ZT-QEXJ8] u2:s4 210.2.0.2 announcing routes 2024/06/18 00:11:35 BGP: [TN0HX-6G1RR] u1:s3 send UPDATE w/ attr: nexthop 0.0.0.0, origin ?, localpref 0, community graceful-shutdown, path 201 200 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 20.10.10.2/32 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.0.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.1.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.2.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.3.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.4.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.5.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.6.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.3.1.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [WEV7K-2GAQ5] u1:s3 send UPDATE len 96 (max message len: 65535) numpfx 9 2024/06/18 00:11:35 BGP: [MBFVT-8GSC6] u1:s3 210.2.0.2 send UPDATE w/ nexthop 210.2.0.1 2024/06/18 00:11:35 BGP: [TN0HX-6G1RR] u1:s3 send UPDATE w/ attr: nexthop 0.0.0.0, localpref 0, metric 0, community graceful-shutdown, path 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 133.133.133.133/32 IPv4 unicast mlx-4600ca1-01(config-router)#no neighbor 210.2.0.2 graceful-shutdown logs: 024/06/18 00:12:59 BGP: [MS8ZT-QEXJ8] u2:s6 210.2.0.2 announcing routes 2024/06/18 00:13:00 BGP: [TN0HX-6G1RR] u1:s5 send UPDATE w/ attr: nexthop 0.0.0.0, origin ?, path 201 200 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 20.10.10.2/32 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.0.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.1.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.2.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.3.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.4.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.5.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.6.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.3.1.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [WEV7K-2GAQ5] u1:s5 send UPDATE len 89 (max message len: 65535) numpfx 9 2024/06/18 00:13:00 BGP: [MBFVT-8GSC6] u1:s5 210.2.0.2 send UPDATE w/ nexthop 210.2.0.1 2024/06/18 00:13:00 BGP: [TN0HX-6G1RR] u1:s5 send UPDATE w/ attr: nexthop 0.0.0.0, metric 0, path 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 133.133.133.133/32 IPv4 unicast 2024/06/18 00:13:00 BGP: [WEV7K-2GAQ5] u1:s5 send UPDATE len 56 (max message len: 65535) numpfx 1 default route: n2# show ip bgp 0.0.0.0/0 BGP routing table entry for 0.0.0.0/0, version 70 Paths: (1 available, best #1, table default) Advertised to non peer-group peers: mlx-4600ca1-01(210.2.0.1) n3(210.3.1.3) n3(2210:210:3:1::3) 201 100 210.2.0.1 (mlx-4600ca1-01) from mlx-4600ca1-01(210.2.0.1) (20.0.0.1) Origin IGP, metric 0, localpref 0, valid, external, bestpath-from-AS 201, best (First path received) Community: graceful-shutdown Last update: Wed Jun 26 20:20:29 2024 Signed-off-by: Vijayalaxmi Basavaraj <vbasavaraj@nvidia.com>
donaldsharp
pushed a commit
that referenced
this pull request
Jan 6, 2025
Global BGP configuration knob like 'bgp graceful-shutdown' is not rendered properly via frr-reload script. when the config line is rendered if happened to be post router bgp config lines, frr end up rendering bgp gr-shut under bgp instance config though global config knob is set. Two fixes: 1) Move bgp global config line at the beginning of pending config lines to add. 2) Skip adding bgp global config line in second pass of frr-reload script run. The second fix is required to avoid following scenario: 2022-08-30 20:40:53,397 DEBUG: Running Frr Config (Pass #0) ['bgp graceful-shutdown\n', 'router bgp 65564\n timers bgp 3 9\n', 'router bgp 65564\n bgp deterministic-med\n', 2022-08-30 20:40:54,042 DEBUG: Running Frr Config (Pass #1) 'vrf mgmt\n', 'router bgp 65564 vrf sym_1\n address-family l2vpn evpn\n', 'bgp graceful-shutdown\n', <<<<<<< reapp %Failed: per-vrf graceful-shutdown config not permitted with global graceful-shutdown line 97: Failure to communicate[13] to bgpd, line: bgp graceful-shutdown [8816|bgpd] Configuration file[/etc/frr/frr.conf] processing failure: 13 Ticket: #3187405 Testing Done: Add and remove 'bgp graceful-shutdown' config in frr.conf and perform frr-reload. Signed-off-by: Chirag Shah <chirag@nvidia.com>
donaldsharp
pushed a commit
that referenced
this pull request
Jan 6, 2025
route-map match condition on evpn default-route does not have proper check that its truly type-5 before checking prefixlen being 0. In absence of the fix, the set condition applied to all evpn routes as evpn prefix is type union so just checking for prefixlen 0 is not sufficient. Ticket:#3227895 Issue:3227895 Testing Done: Apply ingress route-map policy: route-map POLICY_OUT_SS permit 10 match evpn default-route set metric 6666 Default route contains metric only to default route: BGP routing table entry for 144.1.1.6:4:[5]:[0]:[0.0.0.0/0]/352 Paths: (2 available, best #1) Advertised to non peer-group peers: leaf-21(swp1) leaf-22(swp2) Route [5]:[0]:[0]:[0.0.0.0] VNI 104002 651004 652000 651001 660000 6.0.0.1 from leaf-21(swp1) (6.0.0.26) Origin IGP, metric 6666, valid, external, bestpath-from-AS 651004, best (Router ID) Extended Community: RT:4640:104002 ET:8 Rmac:00:02:00:00:00:04 Last update: Fri Oct 7 20:25:39 2022 Route [5]:[0]:[0]:[0.0.0.0] VNI 104002 651004 652000 651001 660000 6.0.0.1 from leaf-22(swp2) (6.0.0.27) Origin IGP, metric 6666, valid, external Extended Community: RT:4640:104002 ET:8 Rmac:00:02:00:00:00:04 Last update: Fri Oct 7 20:25:39 2022 Signed-off-by: Chirag Shah <chirag@nvidia.com>
donaldsharp
pushed a commit
that referenced
this pull request
Jan 6, 2025
…n 12 LTTng support Issue: FRR currently utilizes LTTng version 2.10, which has been updated to version 2.13.5-1. This update needs a change in the library, requiring an update on the FRR side to make LTTng working. Fix: Updated the LTTng library dependency from liblttng-ust.so.0 to liblttng-ust-fork.so.1 to align with the new version requirements. UT: unit testing to confirm LTTng's operational status with the new library: - System: Linux mlx-2410ba1-02 6.1.0-cl-1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.38-4+cl5.9.0u1 (2023-08-11) x86_64 GNU/Linux - Test Command: /usr/lib/frr/frr_babeltrace.py /var/log/lttng-traces/frr-local-zebra-onboot/ /usr/lib/frr/frr_babeltrace.py /var/log/lttng-traces/frr-local-onboot/ - Results: Confirmed successful interface updates and address additions, indicating LTTng is functioning as expected with the updated library. Ticket: #3735825 Signed-off-by: Rajesh Varatharaj <rvaratharaj@nvidia.com>
donaldsharp
pushed a commit
that referenced
this pull request
Jan 6, 2025
When bgp neighbor GSHUT is done, advertise routes recivied from this neighbor with GSHUT attribute. Ticket: #3948080 Testing: mlx-4600ca1-01(config-router)# neighbor 210.2.0.2 graceful-shutdown logs: 2024/06/18 00:11:34 BGP: [MS8ZT-QEXJ8] u2:s4 210.2.0.2 announcing routes 2024/06/18 00:11:35 BGP: [TN0HX-6G1RR] u1:s3 send UPDATE w/ attr: nexthop 0.0.0.0, origin ?, localpref 0, community graceful-shutdown, path 201 200 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 20.10.10.2/32 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.0.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.1.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.2.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.3.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.4.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.5.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.6.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.3.1.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [WEV7K-2GAQ5] u1:s3 send UPDATE len 96 (max message len: 65535) numpfx 9 2024/06/18 00:11:35 BGP: [MBFVT-8GSC6] u1:s3 210.2.0.2 send UPDATE w/ nexthop 210.2.0.1 2024/06/18 00:11:35 BGP: [TN0HX-6G1RR] u1:s3 send UPDATE w/ attr: nexthop 0.0.0.0, localpref 0, metric 0, community graceful-shutdown, path 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 133.133.133.133/32 IPv4 unicast mlx-4600ca1-01(config-router)#no neighbor 210.2.0.2 graceful-shutdown logs: 024/06/18 00:12:59 BGP: [MS8ZT-QEXJ8] u2:s6 210.2.0.2 announcing routes 2024/06/18 00:13:00 BGP: [TN0HX-6G1RR] u1:s5 send UPDATE w/ attr: nexthop 0.0.0.0, origin ?, path 201 200 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 20.10.10.2/32 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.0.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.1.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.2.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.3.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.4.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.5.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.6.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.3.1.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [WEV7K-2GAQ5] u1:s5 send UPDATE len 89 (max message len: 65535) numpfx 9 2024/06/18 00:13:00 BGP: [MBFVT-8GSC6] u1:s5 210.2.0.2 send UPDATE w/ nexthop 210.2.0.1 2024/06/18 00:13:00 BGP: [TN0HX-6G1RR] u1:s5 send UPDATE w/ attr: nexthop 0.0.0.0, metric 0, path 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 133.133.133.133/32 IPv4 unicast 2024/06/18 00:13:00 BGP: [WEV7K-2GAQ5] u1:s5 send UPDATE len 56 (max message len: 65535) numpfx 1 default route: n2# show ip bgp 0.0.0.0/0 BGP routing table entry for 0.0.0.0/0, version 70 Paths: (1 available, best #1, table default) Advertised to non peer-group peers: mlx-4600ca1-01(210.2.0.1) n3(210.3.1.3) n3(2210:210:3:1::3) 201 100 210.2.0.1 (mlx-4600ca1-01) from mlx-4600ca1-01(210.2.0.1) (20.0.0.1) Origin IGP, metric 0, localpref 0, valid, external, bestpath-from-AS 201, best (First path received) Community: graceful-shutdown Last update: Wed Jun 26 20:20:29 2024 Signed-off-by: Vijayalaxmi Basavaraj <vbasavaraj@nvidia.com>
donaldsharp
pushed a commit
that referenced
this pull request
Jan 9, 2025
…utes detail` If we have a route-map that sets some attributes e.g. community or large-community, and the route-map is applied for outgoing direction, everything is fine, but we missed the point that `advertised-routes detail` was not using the applied attributes to display and instead it uses what is received from the peer (original). Let's fix this, and use what's already applied (advertise attributes), and we can now see: ``` route-map r3 permit 10 match ip address prefix-list p1 set community 65001:65002 set extcommunity bandwidth 100 set large-community 65001:65002:65003 exit ! ... address-family ipv4 unicast neighbor 192.168.2.3 route-map r3 out exit-address-family ... ``` The output: ``` r2# show bgp ipv4 neighbors 192.168.2.3 advertised-routes detail BGP table version is 1, local router ID is 192.168.2.2, vrf id 0 Default local pref 100, local AS 65002 BGP routing table entry for 10.10.10.1/32, version 1 Paths: (1 available, best #1, table default) Advertised to non peer-group peers: 192.168.1.1 192.168.2.3 65001 0.0.0.0 from 192.168.1.1 (192.168.1.1) Origin IGP, valid, external, best (First path received) Community: 65001:65002 Extended Community: LB:65002:12500000 (100.000 Mbps) Large Community: 65001:65002:65003 Last update: Thu Dec 19 17:00:40 2024 ``` Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
donaldsharp
pushed a commit
that referenced
this pull request
Jan 9, 2025
The following ASAN error can be seen. > ERROR: AddressSanitizer: attempting to call malloc_usable_size() for pointer which is not owned: 0x608000036c20 > #0 0x7f3d7a4b5425 in __interceptor_malloc_usable_size ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:198 > #1 0x7f3d7a426a16 in __sanitizer::BufferedStackTrace::Unwind(unsigned long, unsigned long, void*, bool, unsigned int) ../../../../src/libsanitizer/sanitizer_common > /sanitizer_stacktrace.h:122 > #2 0x7f3d7a426a16 in __asan::asan_malloc_usable_size(void const*, unsigned long, unsigned long) ../../../../src/libsanitizer/asan/asan_allocator.cpp:1074 > #3 0x7f3d7a03f330 in mt_count_free lib/memory.c:78 > #4 0x7f3d7a03f330 in qfree lib/memory.c:130 > #5 0x7f3d76ccf89b in bmp_peer_status_changed bgpd/bgp_bmp.c:982 > #6 0x560ae2aa6a94 in hook_call_peer_status_changed bgpd/bgp_fsm.c:47 > #7 0x560ae2aa6a94 in bgp_fsm_change_status bgpd/bgp_fsm.c:1287 > #8 0x560ae2c4f2e5 in peer_delete bgpd/bgpd.c:2777 > #9 0x560ae2c58d24 in bgp_delete bgpd/bgpd.c:4140 > #10 0x560ae2bbb47e in no_router_bgp bgpd/bgp_vty.c:1764 > #11 0x7f3d79fb74ed in cmd_execute_command_real lib/command.c:1003 > #12 0x7f3d79fb78a3 in cmd_execute_command lib/command.c:1062 > #13 0x7f3d79fb7e03 in cmd_execute lib/command.c:1228 > #14 0x7f3d7a107b53 in vty_command lib/vty.c:625 > #15 0x7f3d7a109902 in vty_execute lib/vty.c:1388 > #16 0x7f3d7a10cc32 in vtysh_read lib/vty.c:2400 > #17 0x7f3d7a0f848b in event_call lib/event.c:2019 > #18 0x7f3d7a01e627 in frr_run lib/libfrr.c:1232 > #19 0x560ae29e0037 in main bgpd/bgp_main.c:555 > #20 0x7f3d79a29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > #21 0x7f3d79a29e3f in __libc_start_main_impl ../csu/libc-start.c:392 > #22 0x560ae29e4ef4 in _start (/usr/lib/frr/bgpd+0x2eeef4) > > 0x608000036c20 is located 0 bytes inside of 81-byte region [0x608000036c20,0x608000036c71) > freed by thread T0 here: > #0 0x7f3d7a4b4537 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:127 > #1 0x7f3d76ccf85f in bmp_peer_status_changed bgpd/bgp_bmp.c:981 > #2 0x560ae2aa6a94 in hook_call_peer_status_changed bgpd/bgp_fsm.c:47 > #3 0x560ae2aa6a94 in bgp_fsm_change_status bgpd/bgp_fsm.c:1287 > #4 0x560ae2c4f2e5 in peer_delete bgpd/bgpd.c:2777 > #5 0x560ae2c58d24 in bgp_delete bgpd/bgpd.c:4140 > #6 0x560ae2bbb47e in no_router_bgp bgpd/bgp_vty.c:1764 > #7 0x7f3d79fb74ed in cmd_execute_command_real lib/command.c:1003 > #8 0x7f3d79fb78a3 in cmd_execute_command lib/command.c:1062 > #9 0x7f3d79fb7e03 in cmd_execute lib/command.c:1228 > #10 0x7f3d7a107b53 in vty_command lib/vty.c:625 > #11 0x7f3d7a109902 in vty_execute lib/vty.c:1388 > #12 0x7f3d7a10cc32 in vtysh_read lib/vty.c:2400 > #13 0x7f3d7a0f848b in event_call lib/event.c:2019 > #14 0x7f3d7a01e627 in frr_run lib/libfrr.c:1232 > #15 0x560ae29e0037 in main bgpd/bgp_main.c:555 > #16 0x7f3d79a29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > > previously allocated by thread T0 here: > #0 0x7f3d7a4b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145 > #1 0x7f3d7a03f0e9 in qmalloc lib/memory.c:101 > #2 0x7f3d76cd0166 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2194 > #3 0x7f3d76cd0166 in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2236 > #4 0x7f3d76cd29b8 in bmp_vrf_state_changed bgpd/bgp_bmp.c:3479 > #5 0x560ae2c45b34 in hook_call_bgp_instance_state bgpd/bgpd.c:88 > #6 0x560ae2c4d158 in bgp_instance_up bgpd/bgpd.c:3936 > #7 0x560ae29e5ed1 in bgp_vrf_enable bgpd/bgp_main.c:299 > #8 0x7f3d7a0ff8b1 in vrf_enable lib/vrf.c:286 > #9 0x7f3d7a0ff8b1 in vrf_enable lib/vrf.c:275 > #10 0x7f3d7a12ab66 in zclient_vrf_add lib/zclient.c:2561 > #11 0x7f3d7a12eb43 in zclient_read lib/zclient.c:4624 > #12 0x7f3d7a0f848b in event_call lib/event.c:2019 > #13 0x7f3d7a01e627 in frr_run lib/libfrr.c:1232 > #14 0x560ae29e0037 in main bgpd/bgp_main.c:555 > #15 0x7f3d79a29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
donaldsharp
pushed a commit
that referenced
this pull request
Jan 9, 2025
The following memory leak can be observed when turning off and on the BGP vrf interface. > ==706056==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 78 byte(s) in 1 object(s) allocated from: > #0 0x7fbf5f6b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145 > #1 0x7fbf5f0771f8 in qmalloc lib/memory.c:101 > #2 0x7fbf5bdde610 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2042 > #3 0x7fbf5bdde8aa in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2079 > #4 0x7fbf5bdeaa1c in bmp_vrf_itf_state_changed bgpd/bgp_bmp.c:3204 > #5 0x562740f0d83f in hook_call_bgp_vrf_status_changed bgpd/bgp_zebra.c:64 > #6 0x562740f0ee28 in bgp_ifp_up bgpd/bgp_zebra.c:234 > #7 0x7fbf5f01c193 in hook_call_if_up lib/if.c:57 > #8 0x7fbf5f01d09a in if_up_via_zapi lib/if.c:203 > #9 0x7fbf5f1d6f54 in zclient_interface_up lib/zclient.c:2671 > #10 0x7fbf5f1e3e5a in zclient_read lib/zclient.c:4624 > #11 0x7fbf5f18078d in event_call lib/event.c:1996 > #12 0x7fbf5f048933 in frr_run lib/libfrr.c:1232 > #13 0x562740c0cae1 in main bgpd/bgp_main.c:557 > #14 0x7fbf5ea29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > > Direct leak of 78 byte(s) in 1 object(s) allocated from: > #0 0x7fbf5f6b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145 > #1 0x7fbf5f0771f8 in qmalloc lib/memory.c:101 > #2 0x7fbf5bdde610 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2042 > #3 0x7fbf5bdde8aa in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2079 > #4 0x7fbf5bdd4839 in bmp_send_peerup_vrf bgpd/bgp_bmp.c:627 > #5 0x7fbf5bddb0d3 in bmp_wrfill bgpd/bgp_bmp.c:1590 > #6 0x7fbf5f10841f in pullwr_run lib/pullwr.c:197 > #7 0x7fbf5f18078d in event_call lib/event.c:1996 > #8 0x7fbf5f048933 in frr_run lib/libfrr.c:1232 > #9 0x562740c0cae1 in main bgpd/bgp_main.c:557 > #10 0x7fbf5ea29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Fix this by freeing the previous open_tx and open_rx contexts before setting up the new one. Also at deletion of peer, free the open_rx context. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
donaldsharp
pushed a commit
that referenced
this pull request
Jan 13, 2025
Global BGP configuration knob like 'bgp graceful-shutdown' is not rendered properly via frr-reload script. when the config line is rendered if happened to be post router bgp config lines, frr end up rendering bgp gr-shut under bgp instance config though global config knob is set. Two fixes: 1) Move bgp global config line at the beginning of pending config lines to add. 2) Skip adding bgp global config line in second pass of frr-reload script run. The second fix is required to avoid following scenario: 2022-08-30 20:40:53,397 DEBUG: Running Frr Config (Pass #0) ['bgp graceful-shutdown\n', 'router bgp 65564\n timers bgp 3 9\n', 'router bgp 65564\n bgp deterministic-med\n', 2022-08-30 20:40:54,042 DEBUG: Running Frr Config (Pass #1) 'vrf mgmt\n', 'router bgp 65564 vrf sym_1\n address-family l2vpn evpn\n', 'bgp graceful-shutdown\n', <<<<<<< reapp %Failed: per-vrf graceful-shutdown config not permitted with global graceful-shutdown line 97: Failure to communicate[13] to bgpd, line: bgp graceful-shutdown [8816|bgpd] Configuration file[/etc/frr/frr.conf] processing failure: 13 Ticket: #3187405 Testing Done: Add and remove 'bgp graceful-shutdown' config in frr.conf and perform frr-reload. Signed-off-by: Chirag Shah <chirag@nvidia.com>
donaldsharp
pushed a commit
that referenced
this pull request
Jan 13, 2025
route-map match condition on evpn default-route does not have proper check that its truly type-5 before checking prefixlen being 0. In absence of the fix, the set condition applied to all evpn routes as evpn prefix is type union so just checking for prefixlen 0 is not sufficient. Ticket:#3227895 Issue:3227895 Testing Done: Apply ingress route-map policy: route-map POLICY_OUT_SS permit 10 match evpn default-route set metric 6666 Default route contains metric only to default route: BGP routing table entry for 144.1.1.6:4:[5]:[0]:[0.0.0.0/0]/352 Paths: (2 available, best #1) Advertised to non peer-group peers: leaf-21(swp1) leaf-22(swp2) Route [5]:[0]:[0]:[0.0.0.0] VNI 104002 651004 652000 651001 660000 6.0.0.1 from leaf-21(swp1) (6.0.0.26) Origin IGP, metric 6666, valid, external, bestpath-from-AS 651004, best (Router ID) Extended Community: RT:4640:104002 ET:8 Rmac:00:02:00:00:00:04 Last update: Fri Oct 7 20:25:39 2022 Route [5]:[0]:[0]:[0.0.0.0] VNI 104002 651004 652000 651001 660000 6.0.0.1 from leaf-22(swp2) (6.0.0.27) Origin IGP, metric 6666, valid, external Extended Community: RT:4640:104002 ET:8 Rmac:00:02:00:00:00:04 Last update: Fri Oct 7 20:25:39 2022 Signed-off-by: Chirag Shah <chirag@nvidia.com>
donaldsharp
pushed a commit
that referenced
this pull request
Jan 13, 2025
…n 12 LTTng support Issue: FRR currently utilizes LTTng version 2.10, which has been updated to version 2.13.5-1. This update needs a change in the library, requiring an update on the FRR side to make LTTng working. Fix: Updated the LTTng library dependency from liblttng-ust.so.0 to liblttng-ust-fork.so.1 to align with the new version requirements. UT: unit testing to confirm LTTng's operational status with the new library: - System: Linux mlx-2410ba1-02 6.1.0-cl-1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.38-4+cl5.9.0u1 (2023-08-11) x86_64 GNU/Linux - Test Command: /usr/lib/frr/frr_babeltrace.py /var/log/lttng-traces/frr-local-zebra-onboot/ /usr/lib/frr/frr_babeltrace.py /var/log/lttng-traces/frr-local-onboot/ - Results: Confirmed successful interface updates and address additions, indicating LTTng is functioning as expected with the updated library. Ticket: #3735825 Signed-off-by: Rajesh Varatharaj <rvaratharaj@nvidia.com>
donaldsharp
pushed a commit
that referenced
this pull request
Jan 13, 2025
When bgp neighbor GSHUT is done, advertise routes recivied from this neighbor with GSHUT attribute. Ticket: #3948080 Testing: mlx-4600ca1-01(config-router)# neighbor 210.2.0.2 graceful-shutdown logs: 2024/06/18 00:11:34 BGP: [MS8ZT-QEXJ8] u2:s4 210.2.0.2 announcing routes 2024/06/18 00:11:35 BGP: [TN0HX-6G1RR] u1:s3 send UPDATE w/ attr: nexthop 0.0.0.0, origin ?, localpref 0, community graceful-shutdown, path 201 200 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 20.10.10.2/32 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.0.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.1.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.2.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.3.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.4.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.5.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.6.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.3.1.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [WEV7K-2GAQ5] u1:s3 send UPDATE len 96 (max message len: 65535) numpfx 9 2024/06/18 00:11:35 BGP: [MBFVT-8GSC6] u1:s3 210.2.0.2 send UPDATE w/ nexthop 210.2.0.1 2024/06/18 00:11:35 BGP: [TN0HX-6G1RR] u1:s3 send UPDATE w/ attr: nexthop 0.0.0.0, localpref 0, metric 0, community graceful-shutdown, path 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 133.133.133.133/32 IPv4 unicast mlx-4600ca1-01(config-router)#no neighbor 210.2.0.2 graceful-shutdown logs: 024/06/18 00:12:59 BGP: [MS8ZT-QEXJ8] u2:s6 210.2.0.2 announcing routes 2024/06/18 00:13:00 BGP: [TN0HX-6G1RR] u1:s5 send UPDATE w/ attr: nexthop 0.0.0.0, origin ?, path 201 200 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 20.10.10.2/32 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.0.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.1.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.2.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.3.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.4.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.5.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.6.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.3.1.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [WEV7K-2GAQ5] u1:s5 send UPDATE len 89 (max message len: 65535) numpfx 9 2024/06/18 00:13:00 BGP: [MBFVT-8GSC6] u1:s5 210.2.0.2 send UPDATE w/ nexthop 210.2.0.1 2024/06/18 00:13:00 BGP: [TN0HX-6G1RR] u1:s5 send UPDATE w/ attr: nexthop 0.0.0.0, metric 0, path 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 133.133.133.133/32 IPv4 unicast 2024/06/18 00:13:00 BGP: [WEV7K-2GAQ5] u1:s5 send UPDATE len 56 (max message len: 65535) numpfx 1 default route: n2# show ip bgp 0.0.0.0/0 BGP routing table entry for 0.0.0.0/0, version 70 Paths: (1 available, best #1, table default) Advertised to non peer-group peers: mlx-4600ca1-01(210.2.0.1) n3(210.3.1.3) n3(2210:210:3:1::3) 201 100 210.2.0.1 (mlx-4600ca1-01) from mlx-4600ca1-01(210.2.0.1) (20.0.0.1) Origin IGP, metric 0, localpref 0, valid, external, bestpath-from-AS 201, best (First path received) Community: graceful-shutdown Last update: Wed Jun 26 20:20:29 2024 Signed-off-by: Vijayalaxmi Basavaraj <vbasavaraj@nvidia.com>
donaldsharp
pushed a commit
that referenced
this pull request
Jan 14, 2025
The following memory leak is observed when running bgp_bmp test. > ==614841==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 81 byte(s) in 1 object(s) allocated from: > #0 0x7f0e9f2b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145 > #1 0x7f0e9ec771f8 in qmalloc lib/memory.c:101 > #2 0x7f0e9e5a2f89 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2211 > #3 0x7f0e9e5a31a8 in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2247 > #4 0x7f0e9e5b0325 in bmp_bgp_attribute_updated_instance bgpd/bgp_bmp.c:3476 > #5 0x7f0e9e5b0661 in bmp_bgp_attribute_updated bgpd/bgp_bmp.c:3526 > #6 0x7f0e9e5b08ae in bmp_routerid_update bgpd/bgp_bmp.c:3547 > #7 0x55cdc4bcbd88 in hook_call_bgp_routerid_update bgpd/bgpd.c:89 > #8 0x55cdc4bccf0b in bgp_router_id_set bgpd/bgpd.c:305 > #9 0x55cdc4bcd87d in bgp_router_id_zebra_bump bgpd/bgpd.c:393 > #10 0x55cdc4ba87d5 in bgp_router_id_update bgpd/bgp_zebra.c:99 > #11 0x7f0e9ede3f0b in zclient_read lib/zclient.c:4626 > #12 0x7f0e9ed8074d in event_call lib/event.c:1996 > #13 0x7f0e9ec48933 in frr_run lib/libfrr.c:1232 > #14 0x55cdc48a9a27 in main bgpd/bgp_main.c:555 > #15 0x7f0e9e629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > > Direct leak of 81 byte(s) in 1 object(s) allocated from: > #0 0x7f0e9f2b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145 > #1 0x7f0e9ec771f8 in qmalloc lib/memory.c:101 > #2 0x7f0e9e5a2ed8 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2207 > #3 0x7f0e9e5a31a8 in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2247 > #4 0x7f0e9e5b0325 in bmp_bgp_attribute_updated_instance bgpd/bgp_bmp.c:3476 > #5 0x7f0e9e5b0661 in bmp_bgp_attribute_updated bgpd/bgp_bmp.c:3526 > #6 0x7f0e9e5b08ae in bmp_routerid_update bgpd/bgp_bmp.c:3547 > #7 0x55cdc4bcbd88 in hook_call_bgp_routerid_update bgpd/bgpd.c:89 > #8 0x55cdc4bccf0b in bgp_router_id_set bgpd/bgpd.c:305 > #9 0x55cdc4bcd87d in bgp_router_id_zebra_bump bgpd/bgpd.c:393 > #10 0x55cdc4ba87d5 in bgp_router_id_update bgpd/bgp_zebra.c:99 > #11 0x7f0e9ede3f0b in zclient_read lib/zclient.c:4626 > #12 0x7f0e9ed8074d in event_call lib/event.c:1996 > #13 0x7f0e9ec48933 in frr_run lib/libfrr.c:1232 > #14 0x55cdc48a9a27 in main bgpd/bgp_main.c:555 > #15 0x7f0e9e629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > > Direct leak of 64 byte(s) in 1 object(s) allocated from: > #0 0x7f0e9f2b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7f0e9ec77235 in qcalloc lib/memory.c:106 > #2 0x7f0e9e5a498d in bmp_imported_bgp_get bgpd/bgp_bmp.c:2441 > #3 0x7f0e9e5acbed in bmp_import_vrf_magic bgpd/bgp_bmp.c:2855 > #4 0x7f0e9e5a7f97 in bmp_import_vrf bgpd/bgp_bmp_clippy.c:147 > #5 0x7f0e9ebb1178 in cmd_execute_command_real lib/command.c:1003 > #6 0x7f0e9ebb1505 in cmd_execute_command lib/command.c:1062 > #7 0x7f0e9ebb21d7 in cmd_execute lib/command.c:1228 > #8 0x7f0e9ed90bf0 in vty_command lib/vty.c:626 > #9 0x7f0e9ed95ad5 in vty_execute lib/vty.c:1389 > #10 0x7f0e9ed9c01e in vtysh_read lib/vty.c:2408 > #11 0x7f0e9ed8074d in event_call lib/event.c:1996 > #12 0x7f0e9ec48933 in frr_run lib/libfrr.c:1232 > #13 0x55cdc48a9a27 in main bgpd/bgp_main.c:555 > #14 0x7f0e9e629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > > Direct leak of 6 byte(s) in 1 object(s) allocated from: > #0 0x7f0e9f25b9a7 in __interceptor_strdup ../../../../src/libsanitizer/asan/asan_interceptors.cpp:454 > #1 0x7f0e9ec772fa in qstrdup lib/memory.c:118 > #2 0x55cdc4b57d54 in af_rd_vpn_export_magic bgpd/bgp_vty.c:9814 > #3 0x55cdc4b288d7 in af_rd_vpn_export bgpd/bgp_vty_clippy.c:3493 > #4 0x7f0e9ebb1178 in cmd_execute_command_real lib/command.c:1003 > #5 0x7f0e9ebb1505 in cmd_execute_command lib/command.c:1062 > #6 0x7f0e9ebb21d7 in cmd_execute lib/command.c:1228 > #7 0x7f0e9ed90bf0 in vty_command lib/vty.c:626 > #8 0x7f0e9ed95ad5 in vty_execute lib/vty.c:1389 > #9 0x7f0e9ed9c01e in vtysh_read lib/vty.c:2408 > #10 0x7f0e9ed8074d in event_call lib/event.c:1996 > #11 0x7f0e9ec48933 in frr_run lib/libfrr.c:1232 > #12 0x55cdc48a9a27 in main bgpd/bgp_main.c:555 > #13 0x7f0e9e629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > > Indirect leak of 5 byte(s) in 1 object(s) allocated from: > #0 0x7f0e9f25b9a7 in __interceptor_strdup ../../../../src/libsanitizer/asan/asan_interceptors.cpp:454 > #1 0x7f0e9ec772fa in qstrdup lib/memory.c:118 > #2 0x7f0e9e5a49ae in bmp_imported_bgp_get bgpd/bgp_bmp.c:2443 > #3 0x7f0e9e5acbed in bmp_import_vrf_magic bgpd/bgp_bmp.c:2855 > #4 0x7f0e9e5a7f97 in bmp_import_vrf bgpd/bgp_bmp_clippy.c:147 > #5 0x7f0e9ebb1178 in cmd_execute_command_real lib/command.c:1003 > #6 0x7f0e9ebb1505 in cmd_execute_command lib/command.c:1062 > #7 0x7f0e9ebb21d7 in cmd_execute lib/command.c:1228 > #8 0x7f0e9ed90bf0 in vty_command lib/vty.c:626 > #9 0x7f0e9ed95ad5 in vty_execute lib/vty.c:1389 > #10 0x7f0e9ed9c01e in vtysh_read lib/vty.c:2408 > #11 0x7f0e9ed8074d in event_call lib/event.c:1996 > #12 0x7f0e9ec48933 in frr_run lib/libfrr.c:1232 > #13 0x55cdc48a9a27 in main bgpd/bgp_main.c:555 > #14 0x7f0e9e629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > > SUMMARY: AddressSanitizer: 237 byte(s) leaked in 5 allocation(s). Fix this by freeing the missing memory block that helps building the open message to send to remote bmp collector. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
donaldsharp
pushed a commit
that referenced
this pull request
Jan 14, 2025
> ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f73891cb146 bp 0x7ffca86584c0 sp 0x7ffca8658490 T0) > ==837617==The signal is caused by a READ memory access. > ==837617==Hint: address points to the zero page. > #0 0x7f73891cb146 in bmp_targets_const_next bgpd/bgp_bmp.c:149 > #1 0x7f73891cb1a5 in bmp_targets_next bgpd/bgp_bmp.c:149 > #2 0x7f73891e875a in _bmp_vrf_state_changed_internal bgpd/bgp_bmp.c:3520 > #3 0x7f73891e8922 in bmp_vrf_itf_state_changed bgpd/bgp_bmp.c:3566 > #4 0x55e511af8d1b in hook_call_bgp_vrf_status_changed bgpd/bgp_zebra.c:64 > #5 0x55e511afa304 in bgp_ifp_up bgpd/bgp_zebra.c:234 > #6 0x7f738981c193 in hook_call_if_up lib/if.c:57 > #7 0x7f738981d09a in if_up_via_zapi lib/if.c:203 > #8 0x7f73899d6f54 in zclient_interface_up lib/zclient.c:2671 > #9 0x7f73899e3e5a in zclient_read lib/zclient.c:4624 > #10 0x7f738998078d in event_call lib/event.c:1996 > #11 0x7f7389848933 in frr_run lib/libfrr.c:1232 > #12 0x55e5117f7ae1 in main bgpd/bgp_main.c:557 > #13 0x7f7389229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > #14 0x7f7389229e3f in __libc_start_main_impl ../csu/libc-start.c:392 > #15 0x55e5117f4234 in _start (/usr/lib/frr/bgpd+0x2ec234) Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
donaldsharp
pushed a commit
that referenced
this pull request
Jan 24, 2025
…links When a neighbor connection is disconnected, it may trigger LSP re-generation as a timer task, but this process may be delayed. As a result, the list of neighbors in area->adjacency_list may be inconsistent with the neighbors in lsp->tlvs->oldstyle_reach/extended_reach. For example, the area->adjacency_list may lack certain neighbors even though they are present in the LSP. When computing SPF, the call to isis_spf_build_adj_list() generates the spftree->sadj_list, which reflects the real neighbors in the area->adjacency_list. However, in the case of LAN links, spftree->sadj_list may include additional pseudo neighbors. The pre-loading of tents through the call to isis_spf_preload_tent involves two steps: 1. isis_spf_process_lsp() is called to generate real neighbor vertices based on the root LSP and pseudo LSP. 2. isis_spf_add_local() is called to add corresponding next hops to the vertex->Adj_N list for the real neighbor vertices. In the case of LAN links, the absence of corresponding real neighbors in the spftree->sadj_list prevents the execution of the second step. Consequently, the vertex->Adj_N list for the real neighbor vertices lacks corresponding next hops. This leads to a null pointer access when isis_lfa_compute() is called to calculate LFA. As for P2P links, since there are no pseudo neighbors, only the second step is executed, which does not create real neighbor vertices and therefore does not encounter this issue. The backtrace is as follows: (gdb) bt #0 0x00007fd065277fe1 in raise () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x00007fd065398972 in core_handler (signo=11, siginfo=0x7ffc5c0636b0, context=0x7ffc5c063580) at ../lib/sigevent.c:261 #2 <signal handler called> #3 0x00005564d82f8408 in isis_lfa_compute (area=0x5564d8b143f0, circuit=0x5564d8b21d10, spftree=0x5564d8b06bf0, resource=0x7ffc5c064410) at ../isisd/isis_lfa.c:2134 #4 0x00005564d82f8d78 in isis_spf_run_lfa (area=0x5564d8b143f0, spftree=0x5564d8b06bf0) at ../isisd/isis_lfa.c:2344 #5 0x00005564d8315964 in isis_run_spf_with_protection (area=0x5564d8b143f0, spftree=0x5564d8b06bf0) at ../isisd/isis_spf.c:1827 #6 0x00005564d8315c15 in isis_run_spf_cb (thread=0x7ffc5c064590) at ../isisd/isis_spf.c:1889 #7 0x00007fd0653b1f04 in thread_call (thread=0x7ffc5c064590) at ../lib/thread.c:1990 #8 0x00007fd06534a97b in frr_run (master=0x5564d88103c0) at ../lib/libfrr.c:1198 #9 0x00005564d82e7d5d in main (argc=5, argv=0x7ffc5c0647b8, envp=0x7ffc5c0647e8) at ../isisd/isis_main.c:273 (gdb) f 3 #3 0x00005564d82f8408 in isis_lfa_compute (area=0x5564d8b143f0, circuit=0x5564d8b21d10, spftree=0x5564d8b06bf0, resource=0x7ffc5c064410) at ../isisd/isis_lfa.c:2134 2134 ../isisd/isis_lfa.c: No such file or directory. (gdb) p vadj_primary $1 = (struct isis_vertex_adj *) 0x0 (gdb) p vertex->Adj_N->head $2 = (struct listnode *) 0x0 (gdb) p (struct isis_vertex *)spftree->paths->l.list->head->next->next->next->next->data $8 = (struct isis_vertex *) 0x5564d8b5b240 (gdb) p $8->type $9 = VTYPE_NONPSEUDO_TE_IS (gdb) p $8->N.id $10 = "\000\000\000\000\000\002" (gdb) p $8->Adj_N->count $11 = 0 (gdb) p (struct isis_vertex *)spftree->paths->l.list->head->next->next->next->next->next->data $12 = (struct isis_vertex *) 0x5564d8b73dd0 (gdb) p $12->type $13 = VTYPE_NONPSEUDO_TE_IS (gdb) p $12->N.id $14 = "\000\000\000\000\000\003" (gdb) p $12->Adj_N->count $15 = 0 (gdb) p area->adjacency_list->count $16 = 0 The backtrace provided above pertains to version 8.5.4, but it seems that the same issue exists in the code of the master branch as well. The scenario where a vertex has no next hop is normal. For example, the "clear isis neighbor" command invokes isis_vertex_adj_del() to delete the next hop of a vertex. Upon reviewing all the instances where the vertex->Adj_N list is used, I found that only isis_lfa_compute() lacks a null check. Therefore, I believe that modifying this part will be sufficient. Additionally, the vertex->parents list for IP vertices is guaranteed not to be empty. Test scenario: Setting up LFA for LAN links and executing the "clear isis neighbor" command easily reproduces the issue. Signed-off-by: zhou-run <zhou.run@h3c.com> (cherry picked from commit a970bb5)
donaldsharp
pushed a commit
that referenced
this pull request
Jan 24, 2025
… the fragmented LSP 1. When the root IS regenerates an LSP, it calls lsp_build() -> lsp_clear_data() to free the TLV memory of the first fragment and all other fragments. If the number of fragments in the regenerated LSP decreases or if no fragmentation is needed, the extra LSP fragments are not immediately deleted. Instead, lsp_seqno_update() -> lsp_purge() is called to set the remaining time to zero and start aging, while also notifying other IS nodes to age these fragments. lsp_purge() usually does not reset lsp->hdr.seqno to zero because the LSP might recover during the aging process. 2. When other IS nodes receive an LSP, they always call process_lsp() -> isis_unpack_tlvs() to allocate TLV memory for the LSP. This does not differentiate whether the received LSP has a remaining lifetime of zero. Therefore, it is rare for an LSP of a non-root IS to have empty TLVs. Of course, if an LSP with a remaining time of zero and already corrupted is received, lsp_update() -> lsp_purge() will be called to free the TLV memory of the LSP, but this scenario is rare. 3. In LFA calculations, neighbors of the root IS are traversed, and each neighbor is taken as a new root to compute the neighbor SPT. During this process, the old root IS will serve as a neighbor of the new root IS, triggering a call to isis_spf_process_lsp() to parse the LSP of the old root IS and obtain its IP vertices and neighboring IS vertices. However, isis_spf_process_lsp() only checks whether the TLVs in the first fragment of the LSP exist, and does not check the TLVs in the fragmented LSP. If the TLV memory of the fragmented LSP of the old root IS has been freed, it can lead to a null pointer access, causing the current crash. Additionally, for the base SPT, there are only two places where the LSP of the root IS is parsed: 1. When obtaining the UP neighbors of the root IS via spf_adj_list_parse_lsp(). 2. When preloading the IP vertices of the root IS via isis_lsp_iterate_ip_reach(). Both of these checks ensure that frag->tlvs is not null, and they do not subsequently call isis_spf_process_lsp() to parse the root IS's LSP. It is very rare for non-root IS LSPs to have empty TLVs unless they are corrupted LSPs awaiting deletion. If it happens, a crash will occur. The backtrace is as follows: (gdb) bt #0 0x00007f3097281fe1 in raise () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x00007f30973a2972 in core_handler (signo=11, siginfo=0x7ffce66c2870, context=0x7ffce66c2740) at ../lib/sigevent.c:261 #2 <signal handler called> #3 0x000055dfa805512b in isis_spf_process_lsp (spftree=0x55dfa950eee0, lsp=0x55dfa94cb590, cost=10, depth=1, root_sysid=0x55dfa950ef6c "", parent=0x55dfa952fca0) at ../isisd/isis_spf.c:898 #4 0x000055dfa805743b in isis_spf_loop (spftree=0x55dfa950eee0, root_sysid=0x55dfa950ef6c "") at ../isisd/isis_spf.c:1688 #5 0x000055dfa805784f in isis_run_spf (spftree=0x55dfa950eee0) at ../isisd/isis_spf.c:1808 #6 0x000055dfa8037ff5 in isis_spf_run_neighbors (spftree=0x55dfa9474440) at ../isisd/isis_lfa.c:1259 #7 0x000055dfa803ac17 in isis_spf_run_lfa (area=0x55dfa9477510, spftree=0x55dfa9474440) at ../isisd/isis_lfa.c:2300 #8 0x000055dfa8057964 in isis_run_spf_with_protection (area=0x55dfa9477510, spftree=0x55dfa9474440) at ../isisd/isis_spf.c:1827 #9 0x000055dfa8057c15 in isis_run_spf_cb (thread=0x7ffce66c38e0) at ../isisd/isis_spf.c:1889 #10 0x00007f30973bbf04 in thread_call (thread=0x7ffce66c38e0) at ../lib/thread.c:1990 #11 0x00007f309735497b in frr_run (master=0x55dfa91733c0) at ../lib/libfrr.c:1198 #12 0x000055dfa8029d5d in main (argc=5, argv=0x7ffce66c3b08, envp=0x7ffce66c3b38) at ../isisd/isis_main.c:273 (gdb) f 3 #3 0x000055dfa805512b in isis_spf_process_lsp (spftree=0x55dfa950eee0, lsp=0x55dfa94cb590, cost=10, depth=1, root_sysid=0x55dfa950ef6c "", parent=0x55dfa952fca0) at ../isisd/isis_spf.c:898 898 ../isisd/isis_spf.c: No such file or directory. (gdb) p te_neighs $1 = (struct isis_item_list *) 0x120 (gdb) p lsp->tlvs $2 = (struct isis_tlvs *) 0x0 (gdb) p lsp->hdr $3 = {pdu_len = 27, rem_lifetime = 0, lsp_id = "\000\000\000\000\000\001\000\001", seqno = 4, checksum = 59918, lsp_bits = 1 '\001'} The backtrace provided above pertains to version 8.5.4, but it seems that the same issue exists in the code of the master branch as well. I have reviewed the process for calculating the SPT based on the LSP, and isis_spf_process_lsp() is the only function that does not check whether the TLVs in the fragments are empty. Therefore, I believe that modifying this function alone should be sufficient. If the TLVs of the current fragment are already empty, we do not need to continue processing subsequent fragments. This is consistent with the behavior where we do not process fragments if the TLVs of the first fragment are empty. Of course, one could argue that lsp_purge() should still retain the TLV memory, freeing it and then reallocating it if needed. However, this is a debatable point because in some scenarios, it is permissible for the LSP to have empty TLVs. For example, after receiving an SNP (Sequence Number PDU) message, an empty LSP (with lsp->hdr.seqno = 0) might be created by calling lsp_new. If the corresponding LSP message is discarded due to domain or area authentication failure, the TLV memory wouldn't be allocated. Test scenario: In an LFA network, importing a sufficient number of static routes to cause LSP fragmentation, and then rolling back the imported static routes so that the LSP is no longer fragmented, can easily result in this issue. Signed-off-by: zhou-run <zhou.run@h3c.com> (cherry picked from commit e905177)
donaldsharp
pushed a commit
that referenced
this pull request
Jan 24, 2025
Fix the following crash when pim options are (un)configured on an non-existent interface. > r1(config)# int fgljdsf > r1(config-if)# no ip pim unicast-bsm > vtysh: error reading from pimd: Connection reset by peer (104)Warning: closing connection to pimd because of an I/O error! > #0 raise (sig=<optimized out>) at ../sysdeps/unix/sysv/linux/raise.c:50 > #1 0x00007f70c8f32249 in core_handler (signo=11, siginfo=0x7fffff88e4f0, context=0x7fffff88e3c0) at lib/sigevent.c:258 > #2 <signal handler called> > #3 0x0000556cfdd9b16d in lib_interface_pim_address_family_unicast_bsm_modify (args=0x7fffff88f130) at pimd/pim_nb_config.c:1910 > #4 0x00007f70c8efdcb5 in nb_callback_modify (context=0x556d00032b60, nb_node=0x556cffeeb9b0, event=NB_EV_APPLY, dnode=0x556d00031670, resource=0x556d00032b48, errmsg=0x7fffff88f710 "", errmsg_len=8192) > at lib/northbound.c:1538 > #5 0x00007f70c8efe949 in nb_callback_configuration (context=0x556d00032b60, event=NB_EV_APPLY, change=0x556d00032b10, errmsg=0x7fffff88f710 "", errmsg_len=8192) at lib/northbound.c:1888 > #6 0x00007f70c8efee82 in nb_transaction_process (event=NB_EV_APPLY, transaction=0x556d00032b60, errmsg=0x7fffff88f710 "", errmsg_len=8192) at lib/northbound.c:2016 > #7 0x00007f70c8efd658 in nb_candidate_commit_apply (transaction=0x556d00032b60, save_transaction=true, transaction_id=0x0, errmsg=0x7fffff88f710 "", errmsg_len=8192) at lib/northbound.c:1356 > #8 0x00007f70c8efd78e in nb_candidate_commit (context=..., candidate=0x556cffeb0e80, save_transaction=true, comment=0x0, transaction_id=0x0, errmsg=0x7fffff88f710 "", errmsg_len=8192) at lib/northbound.c:1389 > #9 0x00007f70c8f03e58 in nb_cli_classic_commit (vty=0x556d00025a80) at lib/northbound_cli.c:51 > #10 0x00007f70c8f043f8 in nb_cli_apply_changes_internal (vty=0x556d00025a80, > xpath_base=0x7fffff893bb0 "/frr-interface:lib/interface[name='fgljdsf']/frr-pim:pim/address-family[address-family='frr-routing:ipv4']", clear_pending=false) at lib/northbound_cli.c:178 > #11 0x00007f70c8f0475d in nb_cli_apply_changes (vty=0x556d00025a80, xpath_base_fmt=0x556cfdde9fe0 "./frr-pim:pim/address-family[address-family='%s']") at lib/northbound_cli.c:234 > #12 0x0000556cfdd8298f in pim_process_no_unicast_bsm_cmd (vty=0x556d00025a80) at pimd/pim_cmd_common.c:3493 > #13 0x0000556cfddcf782 in no_ip_pim_ucast_bsm (self=0x556cfde40b20 <no_ip_pim_ucast_bsm_cmd>, vty=0x556d00025a80, argc=4, argv=0x556d00031500) at pimd/pim_cmd.c:4950 > #14 0x00007f70c8e942f0 in cmd_execute_command_real (vline=0x556d00032070, vty=0x556d00025a80, cmd=0x0, up_level=0) at lib/command.c:1002 > #15 0x00007f70c8e94451 in cmd_execute_command (vline=0x556d00032070, vty=0x556d00025a80, cmd=0x0, vtysh=0) at lib/command.c:1061 > #16 0x00007f70c8e9499f in cmd_execute (vty=0x556d00025a80, cmd=0x556d00030320 "no ip pim unicast-bsm", matched=0x0, vtysh=0) at lib/command.c:1227 > #17 0x00007f70c8f51e44 in vty_command (vty=0x556d00025a80, buf=0x556d00030320 "no ip pim unicast-bsm") at lib/vty.c:616 > #18 0x00007f70c8f53bdd in vty_execute (vty=0x556d00025a80) at lib/vty.c:1379 > #19 0x00007f70c8f55d59 in vtysh_read (thread=0x7fffff896600) at lib/vty.c:2374 > #20 0x00007f70c8f4b209 in event_call (thread=0x7fffff896600) at lib/event.c:2011 > #21 0x00007f70c8ed109e in frr_run (master=0x556cffdb4ea0) at lib/libfrr.c:1217 > #22 0x0000556cfdddec12 in main (argc=2, argv=0x7fffff896828, envp=0x7fffff896840) at pimd/pim_main.c:165 > (gdb) f 3 > #3 0x0000556cfdd9b16d in lib_interface_pim_address_family_unicast_bsm_modify (args=0x7fffff88f130) at pimd/pim_nb_config.c:1910 > 1910 pim_ifp->ucast_bsm_accept = > (gdb) list > 1905 case NB_EV_ABORT: > 1906 break; > 1907 case NB_EV_APPLY: > 1908 ifp = nb_running_get_entry(args->dnode, NULL, true); > 1909 pim_ifp = ifp->info; > 1910 pim_ifp->ucast_bsm_accept = > 1911 yang_dnode_get_bool(args->dnode, NULL); > 1912 > 1913 break; > 1914 } > (gdb) p pim_ifp > $1 = (struct pim_interface *) 0x0 Fixes: 3bb513c ("lib: adapt to version 2 of libyang") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com> (cherry picked from commit 6952bea)
donaldsharp
pushed a commit
that referenced
this pull request
Jan 24, 2025
When 'no rpki' is requested and the rtrlib RPKI object was freed, bgpd is crashing. RPKI is configured in VRF red. > ip l set red down > ip l del red > printf 'conf\n vrf red\n no rpki' | vtysh > Core was generated by `/usr/bin/bgpd -A 127.0.0.1 -M snmp -M rpki -M bmp'. > Program terminated with signal SIGSEGV, Segmentation fault. > #0 __pthread_kill_implementation (no_tid=0, signo=11, threadid=140411103615424) at ./nptl/pthread_kill.c:44 > 44 ./nptl/pthread_kill.c: No such file or directory. > [Current thread is 1 (Thread 0x7fb401f419c0 (LWP 190226))] > (gdb) bt > #0 __pthread_kill_implementation (no_tid=0, signo=11, threadid=140411103615424) at ./nptl/pthread_kill.c:44 > #1 __pthread_kill_internal (signo=11, threadid=140411103615424) at ./nptl/pthread_kill.c:78 > #2 __GI___pthread_kill (threadid=140411103615424, signo=signo@entry=11) at ./nptl/pthread_kill.c:89 > #3 0x00007fb4021ad476 in __GI_raise (sig=11) at ../sysdeps/posix/raise.c:26 > #4 0x00007fb4025ce22b in core_handler (signo=11, siginfo=0x7fff831b2d70, context=0x7fff831b2c40) at lib/sigevent.c:248 > #5 <signal handler called> > #6 rtr_mgr_remove_group (config=0x55fe8789f750, preference=11) at /build/make-pkg/output/source/DIST_RTRLIB/rtrlib/rtrlib/rtr_mgr.c:607 > #7 0x00007fb40145f518 in rpki_delete_all_cache_nodes (rpki_vrf=0x55fe8789f4f0) at bgpd/bgp_rpki.c:442 > #8 0x00007fb401463098 in no_rpki_magic (self=0x7fb40146bba0 <no_rpki_cmd>, vty=0x55fe877f5130, argc=2, argv=0x55fe877fccd0) at bgpd/bgp_rpki.c:1732 > #9 0x00007fb40145c09a in no_rpki (self=0x7fb40146bba0 <no_rpki_cmd>, vty=0x55fe877f5130, argc=2, argv=0x55fe877fccd0) at ./bgpd/bgp_rpki_clippy.c:37 > #10 0x00007fb402527abc in cmd_execute_command_real (vline=0x55fe877fd150, vty=0x55fe877f5130, cmd=0x0, up_level=0) at lib/command.c:984 > #11 0x00007fb402527c35 in cmd_execute_command (vline=0x55fe877fd150, vty=0x55fe877f5130, cmd=0x0, vtysh=0) at lib/command.c:1043 > #12 0x00007fb4025281e5 in cmd_execute (vty=0x55fe877f5130, cmd=0x55fe877fb8c0 "no rpki\n", matched=0x0, vtysh=0) at lib/command.c:1209 > #13 0x00007fb4025f0aed in vty_command (vty=0x55fe877f5130, buf=0x55fe877fb8c0 "no rpki\n") at lib/vty.c:615 > #14 0x00007fb4025f2a11 in vty_execute (vty=0x55fe877f5130) at lib/vty.c:1378 > #15 0x00007fb4025f513d in vtysh_read (thread=0x7fff831b5fa0) at lib/vty.c:2373 > #16 0x00007fb4025e9611 in event_call (thread=0x7fff831b5fa0) at lib/event.c:2011 > #17 0x00007fb402566976 in frr_run (master=0x55fe871a14a0) at lib/libfrr.c:1212 > #18 0x000055fe857829fa in main (argc=9, argv=0x7fff831b6218) at bgpd/bgp_main.c:549 Fixes: 8156765 ("bgpd: Add `no rpki` command") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com> (cherry picked from commit 4e053d6)
donaldsharp
pushed a commit
that referenced
this pull request
Jan 24, 2025
Fix crash when flex-algo is configured and mpls-te is disabled. > interface eth0 > ip router isis 1 > ! > router isis 1 > flex-algo 129 > dataplane sr-mpls > advertise-definition > #0 __pthread_kill_implementation (no_tid=0, signo=11, threadid=140486233631168) at ./nptl/pthread_kill.c:44 > #1 __pthread_kill_internal (signo=11, threadid=140486233631168) at ./nptl/pthread_kill.c:78 > #2 __GI___pthread_kill (threadid=140486233631168, signo=signo@entry=11) at ./nptl/pthread_kill.c:89 > #3 0x00007fc5802e9476 in __GI_raise (sig=11) at ../sysdeps/posix/raise.c:26 > #4 0x00007fc58076021f in core_handler (signo=11, siginfo=0x7ffd38d42470, context=0x7ffd38d42340) at lib/sigevent.c:248 > #5 <signal handler called> > #6 0x000055c527f798c9 in isis_link_params_update_asla (circuit=0x55c52aaed3c0, ifp=0x55c52a1044e0) at isisd/isis_te.c:176 > #7 0x000055c527fb29da in isis_instance_flex_algo_create (args=0x7ffd38d43120) at isisd/isis_nb_config.c:2875 > #8 0x00007fc58072655b in nb_callback_create (context=0x55c52ab1d2f0, nb_node=0x55c529f72950, event=NB_EV_APPLY, dnode=0x55c52ab06230, resource=0x55c52ab189f8, errmsg=0x7ffd38d43750 "", > errmsg_len=8192) at lib/northbound.c:1262 > #9 0x00007fc580727625 in nb_callback_configuration (context=0x55c52ab1d2f0, event=NB_EV_APPLY, change=0x55c52ab189c0, errmsg=0x7ffd38d43750 "", errmsg_len=8192) at lib/northbound.c:1662 > #10 0x00007fc580727c39 in nb_transaction_process (event=NB_EV_APPLY, transaction=0x55c52ab1d2f0, errmsg=0x7ffd38d43750 "", errmsg_len=8192) at lib/northbound.c:1794 > #11 0x00007fc580725f77 in nb_candidate_commit_apply (transaction=0x55c52ab1d2f0, save_transaction=true, transaction_id=0x0, errmsg=0x7ffd38d43750 "", errmsg_len=8192) > at lib/northbound.c:1131 > #12 0x00007fc5807260d1 in nb_candidate_commit (context=..., candidate=0x55c529f0a730, save_transaction=true, comment=0x0, transaction_id=0x0, errmsg=0x7ffd38d43750 "", errmsg_len=8192) > at lib/northbound.c:1164 > #13 0x00007fc58072d220 in nb_cli_classic_commit (vty=0x55c52a0fc6b0) at lib/northbound_cli.c:51 > #14 0x00007fc58072d839 in nb_cli_apply_changes_internal (vty=0x55c52a0fc6b0, > xpath_base=0x7ffd38d477f0 "/frr-isisd:isis/instance[area-tag='1'][vrf='default']/flex-algos/flex-algo[flex-algo='129']", clear_pending=false) at lib/northbound_cli.c:178 > #15 0x00007fc58072dbcf in nb_cli_apply_changes (vty=0x55c52a0fc6b0, xpath_base_fmt=0x55c528014de0 "./flex-algos/flex-algo[flex-algo='%ld']") at lib/northbound_cli.c:234 > #16 0x000055c527fd3403 in flex_algo_magic (self=0x55c52804f1a0 <flex_algo_cmd>, vty=0x55c52a0fc6b0, argc=2, argv=0x55c52ab00ec0, algorithm=129, algorithm_str=0x55c52ab120d0 "129") > at isisd/isis_cli.c:3752 > #17 0x000055c527fc97cb in flex_algo (self=0x55c52804f1a0 <flex_algo_cmd>, vty=0x55c52a0fc6b0, argc=2, argv=0x55c52ab00ec0) at ./isisd/isis_cli_clippy.c:6445 > #18 0x00007fc5806b9abc in cmd_execute_command_real (vline=0x55c52aaf78f0, vty=0x55c52a0fc6b0, cmd=0x0, up_level=0) at lib/command.c:984 > #19 0x00007fc5806b9c35 in cmd_execute_command (vline=0x55c52aaf78f0, vty=0x55c52a0fc6b0, cmd=0x0, vtysh=0) at lib/command.c:1043 > #20 0x00007fc5806ba1e5 in cmd_execute (vty=0x55c52a0fc6b0, cmd=0x55c52aae6bd0 "flex-algo 129\n", matched=0x0, vtysh=0) at lib/command.c:1209 > #21 0x00007fc580782ae1 in vty_command (vty=0x55c52a0fc6b0, buf=0x55c52aae6bd0 "flex-algo 129\n") at lib/vty.c:615 > #22 0x00007fc580784a05 in vty_execute (vty=0x55c52a0fc6b0) at lib/vty.c:1378 > #23 0x00007fc580787131 in vtysh_read (thread=0x7ffd38d4ab10) at lib/vty.c:2373 > #24 0x00007fc58077b605 in event_call (thread=0x7ffd38d4ab10) at lib/event.c:2011 > #25 0x00007fc5806f8976 in frr_run (master=0x55c529df9b30) at lib/libfrr.c:1212 > #26 0x000055c527f301bc in main (argc=5, argv=0x7ffd38d4ad58, envp=0x7ffd38d4ad88) at isisd/isis_main.c:350 > (gdb) f 6 > #6 0x000055c527f798c9 in isis_link_params_update_asla (circuit=0x55c52aaed3c0, ifp=0x55c52a1044e0) at isisd/isis_te.c:176 > 176 list_delete_all_node(ext->aslas); > (gdb) p ext > $1 = (struct isis_ext_subtlvs *) 0x0 Fixes: ae27101 ("isisd: fix building asla at first flex-algo config") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com> (cherry picked from commit cd81d28)
donaldsharp
pushed a commit
that referenced
this pull request
Jan 24, 2025
Fix a crash when modifying a route-map with set as-path exclude without as-path-access-list: > router(config)# route-map routemaptest deny 1 > router(config-route-map)# set as-path exclude 33 34 35 > router(config-route-map)# set as-path exclude as-path-access-list test > #0 raise (sig=<optimized out>) at ../sysdeps/unix/sysv/linux/raise.c:50 > #1 0x00007fb3959327de in core_handler (signo=11, siginfo=0x7ffd122da530, context=0x7ffd122da400) at lib/sigevent.c:258 > #2 <signal handler called> > #3 0x000055ab2762a1bd in as_list_list_del (h=0x55ab27897680 <as_exclude_list_orphan>, item=0x55ab28204e20) at ./bgpd/bgp_aspath.h:77 > #4 0x000055ab2762d1a8 in as_exclude_remove_orphan (ase=0x55ab28204e20) at bgpd/bgp_aspath.c:1574 > #5 0x000055ab27550538 in route_aspath_exclude_free (rule=0x55ab28204e20) at bgpd/bgp_routemap.c:2366 > #6 0x00007fb39591f00c in route_map_rule_delete (list=0x55ab28203498, rule=0x55ab28204170) at lib/routemap.c:1357 > #7 0x00007fb39591f87c in route_map_add_set (index=0x55ab28203460, set_name=0x55ab276ad2aa "as-path exclude", set_arg=0x55ab281e4f70 "as-path-access-list test") at lib/routemap.c:1674 > #8 0x00007fb39591d3f3 in generic_set_add (index=0x55ab28203460, command=0x55ab276ad2aa "as-path exclude", arg=0x55ab281e4f70 "as-path-access-list test", errmsg=0x7ffd122db870 "", > errmsg_len=8192) at lib/routemap.c:533 > #9 0x000055ab2755e78e in lib_route_map_entry_set_action_rmap_set_action_exclude_as_path_modify (args=0x7ffd122db290) at bgpd/bgp_routemap_nb_config.c:2427 > #10 0x00007fb3958fe417 in nb_callback_modify (context=0x55ab28205aa0, nb_node=0x55ab27cb31e0, event=NB_EV_APPLY, dnode=0x55ab28202690, resource=0x55ab27c32148, errmsg=0x7ffd122db870 "", > errmsg_len=8192) at lib/northbound.c:1538 > #11 0x00007fb3958ff0ab in nb_callback_configuration (context=0x55ab28205aa0, event=NB_EV_APPLY, change=0x55ab27c32110, errmsg=0x7ffd122db870 "", errmsg_len=8192) at lib/northbound.c:1888 > #12 0x00007fb3958ff5e4 in nb_transaction_process (event=NB_EV_APPLY, transaction=0x55ab28205aa0, errmsg=0x7ffd122db870 "", errmsg_len=8192) at lib/northbound.c:2016 > #13 0x00007fb3958fddba in nb_candidate_commit_apply (transaction=0x55ab28205aa0, save_transaction=true, transaction_id=0x0, errmsg=0x7ffd122db870 "", errmsg_len=8192) > at lib/northbound.c:1356 > #14 0x00007fb3958fdef0 in nb_candidate_commit (context=..., candidate=0x55ab27c2c9a0, save_transaction=true, comment=0x0, transaction_id=0x0, errmsg=0x7ffd122db870 "", errmsg_len=8192) > at lib/northbound.c:1389 > #15 0x00007fb3959045ba in nb_cli_classic_commit (vty=0x55ab281f6680) at lib/northbound_cli.c:57 > #16 0x00007fb395904b5a in nb_cli_apply_changes_internal (vty=0x55ab281f6680, xpath_base=0x7ffd122dfd10 "/frr-route-map:lib/route-map[name='routemaptest']/entry[sequence='1']", > clear_pending=false) at lib/northbound_cli.c:184 > #17 0x00007fb395904ebf in nb_cli_apply_changes (vty=0x55ab281f6680, xpath_base_fmt=0x0) at lib/northbound_cli.c:240 > --Type <RET> for more, q to quit, c to continue without paging-- > #18 0x000055ab27557d2e in set_aspath_exclude_access_list_magic (self=0x55ab2775c300 <set_aspath_exclude_access_list_cmd>, vty=0x55ab281f6680, argc=5, argv=0x55ab28204c80, > as_path_filter_name=0x55ab28202040 "test") at bgpd/bgp_routemap.c:6397 > #19 0x000055ab2754bdea in set_aspath_exclude_access_list (self=0x55ab2775c300 <set_aspath_exclude_access_list_cmd>, vty=0x55ab281f6680, argc=5, argv=0x55ab28204c80) > at ./bgpd/bgp_routemap_clippy.c:856 > #20 0x00007fb39589435d in cmd_execute_command_real (vline=0x55ab281e61f0, vty=0x55ab281f6680, cmd=0x0, up_level=0) at lib/command.c:1003 > #21 0x00007fb3958944be in cmd_execute_command (vline=0x55ab281e61f0, vty=0x55ab281f6680, cmd=0x0, vtysh=0) at lib/command.c:1062 > #22 0x00007fb395894a0c in cmd_execute (vty=0x55ab281f6680, cmd=0x55ab28200f20 "set as-path exclude as-path-access-list test", matched=0x0, vtysh=0) at lib/command.c:1228 > #23 0x00007fb39595242c in vty_command (vty=0x55ab281f6680, buf=0x55ab28200f20 "set as-path exclude as-path-access-list test") at lib/vty.c:625 > #24 0x00007fb3959541c5 in vty_execute (vty=0x55ab281f6680) at lib/vty.c:1388 > #25 0x00007fb3959563db in vtysh_read (thread=0x7ffd122e2bb0) at lib/vty.c:2400 > #26 0x00007fb39594b785 in event_call (thread=0x7ffd122e2bb0) at lib/event.c:1996 > #27 0x00007fb3958d1365 in frr_run (master=0x55ab27b56d70) at lib/libfrr.c:1231 > #28 0x000055ab2747f1cc in main (argc=3, argv=0x7ffd122e2e08) at bgpd/bgp_main.c:555 Fixes: 094dcc3 ("bgpd: fix "bgp as-pah access-list" with "set aspath exclude" set/unset issues") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
donaldsharp
pushed a commit
that referenced
this pull request
Jan 24, 2025
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 7ae70eb)
donaldsharp
pushed a commit
that referenced
this pull request
Jan 24, 2025
Fix the display of the local label in show bgp. > r1# show bgp ipv4 labeled-unicast 172.16.2.2/32 > BGP routing table entry for 172.16.2.2/32, version 2 > Local label: 16 <---- MISSING > Paths: (1 available, best #1, table default, vrf (null)) > Advertised to non peer-group peers: > 192.168.1.2 > 65501 > 192.168.1.2 from 192.168.1.2 (172.16.2.2) > Origin IGP, metric 0, valid, external, best (First path received) > Remote label: 3 > Last update: Fri Oct 25 17:55:45 2024 Fixes: 67f67ba ("bgpd: Drop label_ntop/label_pton functions") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com> (cherry picked from commit e7b3276)
donaldsharp
pushed a commit
that referenced
this pull request
Jan 24, 2025
Some bgp evpn memory contexts are not freed at the end of the bgp process. > ================================================================= > ==1208677==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 96 byte(s) in 2 object(s) allocated from: > #0 0x7f93ad4b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7f93ace77233 in qcalloc lib/memory.c:106 > #2 0x563bb68f4df1 in process_type5_route bgpd/bgp_evpn.c:5084 > #3 0x563bb68fb663 in bgp_nlri_parse_evpn bgpd/bgp_evpn.c:6302 > #4 0x563bb69ea2a9 in bgp_nlri_parse bgpd/bgp_packet.c:347 > #5 0x563bb69f7716 in bgp_update_receive bgpd/bgp_packet.c:2482 > #6 0x563bb6a04d3b in bgp_process_packet bgpd/bgp_packet.c:4091 > #7 0x7f93acf8082d in event_call lib/event.c:1996 > #8 0x7f93ace48931 in frr_run lib/libfrr.c:1232 > #9 0x563bb6880ae1 in main bgpd/bgp_main.c:557 > #10 0x7f93ac829d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, the bgp evpn context may noy be used if adj rib in is unused. This may lead to memory leaks. Fix this by freeing the context in those corner cases. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
donaldsharp
pushed a commit
that referenced
this pull request
Jan 24, 2025
When running the bgp_evpn_rt5 setup with unified config, memory leak about a non deleted BGP instance happens. > root@ubuntu2204hwe:~/frr/tests/topotests/bgp_evpn_rt5# cat /tmp/topotests/bgp_evpn_rt5.test_bgp_evpn/r1.asan.bgpd.1164105 > > ================================================================= > ==1164105==ERROR: LeakSanitizer: detected memory leaks > > Indirect leak of 12496 byte(s) in 1 object(s) allocated from: > #0 0x7f358eeb4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7f358e877233 in qcalloc lib/memory.c:106 > #2 0x55d06c95680a in bgp_create bgpd/bgpd.c:3405 > #3 0x55d06c95a7b3 in bgp_get bgpd/bgpd.c:3805 > #4 0x55d06c87a9b5 in bgp_get_vty bgpd/bgp_vty.c:603 > #5 0x55d06c68dc71 in bgp_evpn_local_l3vni_add bgpd/bgp_evpn.c:7032 > #6 0x55d06c92989b in bgp_zebra_process_local_l3vni bgpd/bgp_zebra.c:3204 > #7 0x7f358e9e3feb in zclient_read lib/zclient.c:4626 > #8 0x7f358e98082d in event_call lib/event.c:1996 > #9 0x7f358e848931 in frr_run lib/libfrr.c:1232 > #10 0x55d06c60eae1 in main bgpd/bgp_main.c:557 > #11 0x7f358e229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, a BGP VRF Instance is created in auto mode when creating the global BGP instance for the L3 VNI. And again, an other BGP VRF instance is created. Fix this by ensuring that a non existing BGP instance is not present. If it is present, and with auto mode or in hidden mode, then override the AS value. Fixes: f153b9a ("bgpd: Ignore auto created VRF BGP instances") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
donaldsharp
pushed a commit
that referenced
this pull request
Jan 29, 2025
When aggregate is used, the suppressed information is not displayed in the json attributes of a given path. To illustrate, the dump of the 192.168.2.1/32 path in the bgp_aggregate_address_topo1 topotest: > # show bgp ipv4 > [..] > s> 192.168.2.1/32 10.0.0.2 0 65001 i > > # show bgp ipv4 detail > [..] > BGP routing table entry for 192.168.2.1/32, version 17 > Paths: (1 available, best #1, table default, vrf (null), Advertisements suppressed by an aggregate.) > Not advertised to any peer > 65001 <---- missing suppressed flag > 10.0.0.2 from 10.0.0.2 (10.254.254.3) > Origin IGP, valid, external, best (First path received) > Last update: Fri Jan 24 13:11:41 2025 > > # show bgp ipv4 detail json > [..] > ,"192.168.2.1/32": [{"aspath":{"string":"65001","segments":[{"type":"as-sequence","list":[65001]}],"length":1},"origin":"IGP","valid":true,"version":17, > "bestpath":{"overall":true,"selectionReason":"First path received"}, <---- missing suppressed flag > "lastUpdate":{"epoch":1737720700,"string":"Fri Jan 24 13:11:40 2025\n"}, > "nexthops":[{"ip":"10.0.0.2","afi":"ipv4","metric":0,"accessible":true,"used":true}], > "peer":{"peerId":"10.0.0.2","routerId":"10.254.254.3","type":"external"}}] Fix this by adding the json information. > # show bgp ipv4 detail > [..] > BGP routing table entry for 192.168.2.1/32, version 17 > Paths: (1 available, best #1, table default, vrf (null), Advertisements suppressed by an aggregate.) > Not advertised to any peer > 65001, (suppressed) > 10.0.0.2 from 10.0.0.2 (10.254.254.3) > Origin IGP, valid, external, best (First path received) > Last update: Fri Jan 24 13:11:41 2025 > > # show bgp ipv4 detail json > [..] > ,"192.168.2.1/32": [{"aspath":{"string":"65001","segments":[{"type":"as-sequence","list":[65001]}],"length":1},"suppressed":true,"origin":"IGP","valid":true,"version":17, > "bestpath":{"overall":true,"selectionReason":"First path received"}, > "lastUpdate":{"epoch":1737720991,"string":"Fri Jan 24 13:16:31 2025"}, > "nexthops":[{"ip":"10.0.0.2","afi":"ipv4","metric":0,"accessible":true,"used":true}],"peer":{"peerId":"10.0.0.2","routerId":"10.254.254.3","type":"external"}}] Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
donaldsharp
pushed a commit
that referenced
this pull request
Feb 4, 2025
When staticd receives a `ZAPI_SRV6_SID_RELEASED` notification from SRv6
SID Manager, it tries to unset the validity flag of `sid`. But since
the `sid` variable is NULL, we get a NULL pointer dereference.
```
=================================================================
==13815==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000060 (pc 0xc14b813d9eac bp 0xffffcb135a40 sp 0xffffcb135a40 T0)
==13815==The signal is caused by a READ memory access.
==13815==Hint: address points to the zero page.
#0 0xc14b813d9eac in static_zebra_srv6_sid_notify staticd/static_zebra.c:1172
#1 0xe44e7aa2c194 in zclient_read lib/zclient.c:4746
#2 0xe44e7a9b69d8 in event_call lib/event.c:1984
#3 0xe44e7a85ac28 in frr_run lib/libfrr.c:1246
#4 0xc14b813ccf98 in main staticd/static_main.c:193
#5 0xe44e7a4773f8 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
#6 0xe44e7a4774c8 in __libc_start_main_impl ../csu/libc-start.c:392
#7 0xc14b813cc92c in _start (/usr/lib/frr/staticd+0x1c92c)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV staticd/static_zebra.c:1172 in static_zebra_srv6_sid_notify
==13815==ABORTING
```
This commit fixes the problem by doing a SID lookup first. If the SID
can't be found, we log an error and return. If the SID is found, we go
ahead and unset the validity flag.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
donaldsharp
pushed a commit
that referenced
this pull request
Feb 5, 2025
…n 12 LTTng support Issue: FRR currently utilizes LTTng version 2.10, which has been updated to version 2.13.5-1. This update needs a change in the library, requiring an update on the FRR side to make LTTng working. Fix: Updated the LTTng library dependency from liblttng-ust.so.0 to liblttng-ust-fork.so.1 to align with the new version requirements. UT: unit testing to confirm LTTng's operational status with the new library: - System: Linux mlx-2410ba1-02 6.1.0-cl-1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.38-4+cl5.9.0u1 (2023-08-11) x86_64 GNU/Linux - Test Command: /usr/lib/frr/frr_babeltrace.py /var/log/lttng-traces/frr-local-zebra-onboot/ /usr/lib/frr/frr_babeltrace.py /var/log/lttng-traces/frr-local-onboot/ - Results: Confirmed successful interface updates and address additions, indicating LTTng is functioning as expected with the updated library. Ticket: #3735825 Signed-off-by: Rajesh Varatharaj <rvaratharaj@nvidia.com>
donaldsharp
pushed a commit
that referenced
this pull request
Feb 5, 2025
When bgp neighbor GSHUT is done, advertise routes recivied from this neighbor with GSHUT attribute. Ticket: #3948080 Testing: mlx-4600ca1-01(config-router)# neighbor 210.2.0.2 graceful-shutdown logs: 2024/06/18 00:11:34 BGP: [MS8ZT-QEXJ8] u2:s4 210.2.0.2 announcing routes 2024/06/18 00:11:35 BGP: [TN0HX-6G1RR] u1:s3 send UPDATE w/ attr: nexthop 0.0.0.0, origin ?, localpref 0, community graceful-shutdown, path 201 200 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 20.10.10.2/32 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.0.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.1.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.2.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.3.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.4.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.5.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.6.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.3.1.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [WEV7K-2GAQ5] u1:s3 send UPDATE len 96 (max message len: 65535) numpfx 9 2024/06/18 00:11:35 BGP: [MBFVT-8GSC6] u1:s3 210.2.0.2 send UPDATE w/ nexthop 210.2.0.1 2024/06/18 00:11:35 BGP: [TN0HX-6G1RR] u1:s3 send UPDATE w/ attr: nexthop 0.0.0.0, localpref 0, metric 0, community graceful-shutdown, path 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 133.133.133.133/32 IPv4 unicast mlx-4600ca1-01(config-router)#no neighbor 210.2.0.2 graceful-shutdown logs: 024/06/18 00:12:59 BGP: [MS8ZT-QEXJ8] u2:s6 210.2.0.2 announcing routes 2024/06/18 00:13:00 BGP: [TN0HX-6G1RR] u1:s5 send UPDATE w/ attr: nexthop 0.0.0.0, origin ?, path 201 200 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 20.10.10.2/32 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.0.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.1.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.2.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.3.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.4.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.5.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.6.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.3.1.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [WEV7K-2GAQ5] u1:s5 send UPDATE len 89 (max message len: 65535) numpfx 9 2024/06/18 00:13:00 BGP: [MBFVT-8GSC6] u1:s5 210.2.0.2 send UPDATE w/ nexthop 210.2.0.1 2024/06/18 00:13:00 BGP: [TN0HX-6G1RR] u1:s5 send UPDATE w/ attr: nexthop 0.0.0.0, metric 0, path 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 133.133.133.133/32 IPv4 unicast 2024/06/18 00:13:00 BGP: [WEV7K-2GAQ5] u1:s5 send UPDATE len 56 (max message len: 65535) numpfx 1 default route: n2# show ip bgp 0.0.0.0/0 BGP routing table entry for 0.0.0.0/0, version 70 Paths: (1 available, best #1, table default) Advertised to non peer-group peers: mlx-4600ca1-01(210.2.0.1) n3(210.3.1.3) n3(2210:210:3:1::3) 201 100 210.2.0.1 (mlx-4600ca1-01) from mlx-4600ca1-01(210.2.0.1) (20.0.0.1) Origin IGP, metric 0, localpref 0, valid, external, bestpath-from-AS 201, best (First path received) Community: graceful-shutdown Last update: Wed Jun 26 20:20:29 2024 Signed-off-by: Vijayalaxmi Basavaraj <vbasavaraj@nvidia.com>
donaldsharp
pushed a commit
that referenced
this pull request
Feb 21, 2025
Enhance the commands "show bgp ipv4/ipv6 unicast" detail and non detail
outputs when 'bgp nhg-per-origin' is configured.
Testing:
switch# sh bgp ipv4 unicast
BGP table version is 218, local router ID is 6.0.0.6, vrf id 0
Default local pref 100, local AS 65011
Status codes: s suppressed, d damped, h history, u unsorted, * valid, > best, = multipath, + multipath nhg
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 6.0.0.7/32 220.10.0.65(spine11)
0 65201 65012 ?
*+ 220.10.0.81(spine11)
0 65201 65012 ?
*+ 220.10.0.97(spine11)
0 65201 65012 ?
*+ 220.11.0.65(spine12)
0 65201 65012 ?
*+ 220.11.0.81(spine12)
0 65201 65012 ?
*+ 220.11.0.97(spine12)
0 65201 65012 ?
*> 77.0.0.0/32 220.10.0.65(spine11)
0 65201 65012 ?
*+ 220.10.0.81(spine11)
0 65201 65012 ?
*+ 220.10.0.97(spine11)
0 65201 65012 ?
*+ 220.11.0.65(spine12)
0 65201 65012 ?
*+ 220.11.0.81(spine12)
0 65201 65012 ?
*+ 220.11.0.97(spine12)
mlx-3700-68# show bgp ipv4 unicast 77.0.0.0/32
BGP routing table entry for 77.0.0.0/32, version 150 SoO:6.0.0.7, multipath soo nhg:70328887
Paths: (6 available, best #1, table default)
Advertised to non peer-group peers:
spine11(220.10.0.65) spine11(220.10.0.81) spine11(220.10.0.97) spine12(220.11.0.65) spine12(220.11.0.81) spine12(220.11.0.97)
65201 65012
220.11.0.65 (spine12) from spine12(220.11.0.65) (6.0.0.11)
Origin incomplete, valid, external, multipath soo nhg, bestpath-from-AS 65201, best (Older Path)
Extended Community: SoO:6.0.0.7:1234
Last update: Mon Oct 7 09:48:36 2024
65201 65012
220.10.0.65 (spine11) from spine11(220.10.0.65) (6.0.0.10)
Origin incomplete, valid, external, multipath soo nhg
Extended Community: SoO:6.0.0.7:1234
Last update: Mon Oct 7 09:48:36 2024
65201 65012
220.10.0.81 (spine11) from spine11(220.10.0.81) (6.0.0.10)
Origin incomplete, valid, external, multipath soo nhg
Extended Community: SoO:6.0.0.7:1234
Last update: Mon Oct 7 09:48:36 2024
65201 65012
220.10.0.97 (spine11) from spine11(220.10.0.97) (6.0.0.10)
Origin incomplete, valid, external, multipath soo nhg
Extended Community: SoO:6.0.0.7:1234
Last update: Mon Oct 7 09:48:36 2024
65201 65012
220.11.0.81 (spine12) from spine12(220.11.0.81) (6.0.0.11)
Origin incomplete, valid, external, multipath soo nhg
Extended Community: SoO:6.0.0.7:1234
Last update: Mon Oct 7 09:48:36 2024
65201 65012
220.11.0.97 (spine12) from spine12(220.11.0.97) (6.0.0.11)
Origin incomplete, valid, external, multipath soo nhg
Extended Community: SoO:6.0.0.7:1234
Last update: Mon Oct 7 09:48:36 2024
mlx-3700-68#
Ticket: #3951671
Signed-off-by: Karthikeya Venkat Muppalla <kmuppalla@nvidia.com>
donaldsharp
pushed a commit
that referenced
this pull request
Feb 21, 2025
Enhance the commands "show bgp ipv4/ipv6 unicast" detail and non detail
outputs when 'bgp nhg-per-origin' is configured.
Testing:
switch# sh bgp ipv4 unicast
BGP table version is 218, local router ID is 6.0.0.6, vrf id 0
Default local pref 100, local AS 65011
Status codes: s suppressed, d damped, h history, u unsorted, * valid, > best, = multipath, + multipath nhg
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 6.0.0.7/32 220.10.0.65(spine11)
0 65201 65012 ?
*+ 220.10.0.81(spine11)
0 65201 65012 ?
*+ 220.10.0.97(spine11)
0 65201 65012 ?
*+ 220.11.0.65(spine12)
0 65201 65012 ?
*+ 220.11.0.81(spine12)
0 65201 65012 ?
*+ 220.11.0.97(spine12)
0 65201 65012 ?
*> 77.0.0.0/32 220.10.0.65(spine11)
0 65201 65012 ?
*+ 220.10.0.81(spine11)
0 65201 65012 ?
*+ 220.10.0.97(spine11)
0 65201 65012 ?
*+ 220.11.0.65(spine12)
0 65201 65012 ?
*+ 220.11.0.81(spine12)
0 65201 65012 ?
*+ 220.11.0.97(spine12)
mlx-3700-68# show bgp ipv4 unicast 77.0.0.0/32
BGP routing table entry for 77.0.0.0/32, version 150 SoO:6.0.0.7, multipath soo nhg:70328887
Paths: (6 available, best #1, table default)
Advertised to non peer-group peers:
spine11(220.10.0.65) spine11(220.10.0.81) spine11(220.10.0.97) spine12(220.11.0.65) spine12(220.11.0.81) spine12(220.11.0.97)
65201 65012
220.11.0.65 (spine12) from spine12(220.11.0.65) (6.0.0.11)
Origin incomplete, valid, external, multipath soo nhg, bestpath-from-AS 65201, best (Older Path)
Extended Community: SoO:6.0.0.7:1234
Last update: Mon Oct 7 09:48:36 2024
65201 65012
220.10.0.65 (spine11) from spine11(220.10.0.65) (6.0.0.10)
Origin incomplete, valid, external, multipath soo nhg
Extended Community: SoO:6.0.0.7:1234
Last update: Mon Oct 7 09:48:36 2024
65201 65012
220.10.0.81 (spine11) from spine11(220.10.0.81) (6.0.0.10)
Origin incomplete, valid, external, multipath soo nhg
Extended Community: SoO:6.0.0.7:1234
Last update: Mon Oct 7 09:48:36 2024
65201 65012
220.10.0.97 (spine11) from spine11(220.10.0.97) (6.0.0.10)
Origin incomplete, valid, external, multipath soo nhg
Extended Community: SoO:6.0.0.7:1234
Last update: Mon Oct 7 09:48:36 2024
65201 65012
220.11.0.81 (spine12) from spine12(220.11.0.81) (6.0.0.11)
Origin incomplete, valid, external, multipath soo nhg
Extended Community: SoO:6.0.0.7:1234
Last update: Mon Oct 7 09:48:36 2024
65201 65012
220.11.0.97 (spine12) from spine12(220.11.0.97) (6.0.0.11)
Origin incomplete, valid, external, multipath soo nhg
Extended Community: SoO:6.0.0.7:1234
Last update: Mon Oct 7 09:48:36 2024
mlx-3700-68#
Ticket: #3951671
Signed-off-by: Karthikeya Venkat Muppalla <kmuppalla@nvidia.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.