Flexalgo mpls frrbot #1
Open
Conversation
This file contains hidden or 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
The spftree has a new property called algorithm which is id used to identify the algorithm that separates it in the same IGP network. This is used in Flex-Algo. In other cases than Flex-Algo, the algorithm id is always zero. Signed-off-by: Hiroki Shirokura <hiroki.shirokura@linecorp.com> Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
The information in prefix-sid has a new property called algorithm id. This is used to identify the algorithm that separates it in the same IGP network. This is used in Flex-Algo.In all other cases, the algorithm id is basically 0. Signed-off-by: Hiroki Shirokura <hiroki.shirokura@linecorp.com> Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
The information in prefix-sid has a new property called algorithm id. This is used to identify the algorithm that separates it in the same IGP network. This is used in Flex-Algo.In all other cases, the algorithm id is basically 0. Signed-off-by: Hiroki Shirokura <hiroki.shirokura@linecorp.com> Signed-off-by: Eric Kinzie <ekinzie@labn.net> Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Before this commit, SR_ALGORITHM_COUNT was set to 2, and each was hardcoded with router capability tlv. When Flex-Algo is supported, SR-Algorithm may be variably supported up to 256. Signed-off-by: Hiroki Shirokura <hiroki.shirokura@linecorp.com> Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
isis_tlvs_add_extended_ip_reach adds IS-IS Extended IP reachability to the LSP. In this case, if the pcfg argument is not NULL, you can add IGP Prefix-SID as its sub tlv. Before this commit, only one Prefix-SID can be added. After this commit, the argument is not a single pointer but an array of pointers, and multiple Prefix-SIDs can be added. This feature is necessary because Flex-Algo requires multiple Prefix-SIDs for each Algorithm. Signed-off-by: Hiroki Shirokura <hiroki.shirokura@linecorp.com> Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Prefix-SID nexthops and backup nexthops are stored respectively in isis_route_info->nexthops and isis_route_info->backup->nexthops. With Flex-Algo, there are multiple Prefix-SIDs for a single prefix in different algorithms. Each of these Prefix-SIDs performs SPF calculation with a separate contract and sets a nexthops, so it is necessary to store a different set nexthops for each Prefix-SID. Add a nexthops and backup nethops list into the Prefix-SID isis_sr_psid_info struct and use these lists instead of the when needed After this commit, the nexthops for each Prefix-SID is not taken from route_info, but the nexthop set inside the Prefix-SID is taken. This works for backup nexthops as well. Signed-off-by: Hiroki Shirokura <hiroki.shirokura@linecorp.com> Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Before this commit, there was only one sr psid info included in route_info. In fact, in RFC8667, Algorithm ID, which is a property of Prefix-SID, has 8 bits of information. That is, each Prefix can hold up to 256 Prefix-SIDs. This commit implements it. The previously implemented single Prefix-SID will be continued as Algorithm 0. Signed-off-by: Hiroki Shirokura <hiroki.shirokura@linecorp.com> Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Many of the enum definitions defined in isis_tlvs.h are often extended at the end. The c/c++ allows commas at the end of a list. This commit simplifies the patching of later extensions. Signed-off-by: Hiroki Shirokura <hiroki.shirokura@linecorp.com> Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
SR Algorithms are independent of specific IGPs such as IS-IS and OSPF. This commit adds lib/sr to aggregate IGP agnostic functions and constants. Signed-off-by: Hiroki Shirokura <hiroki.shirokura@linecorp.com> Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com> Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Basically in frrouting source code principle, the log string should not be a complicated abstraction or streamlined for grep. But for log format for the "TLV size does not match ..." can be unified, which makes development easier. > $ grep "TLV size does not match expected size for" isisd/isis_tlvs.c > "TLV size does not match expected size for Administrative Group!\n"); > "TLV size does not match expected size for Local IPv6 address!\n"); > ...(snip)... > "TLV size does not match expected size for Adjacency SID!\n"); > "TLV size does not match expected size for Adjacency SID!\n"); > "TLV size does not match expected size for Adjacency SID!\n"); > "TLV size does not match expected size for LAN-Adjacency SID!\n"); > "TLV size does not match expected size for LAN-Adjacency SID!\n"); > "TLV size does not match expected size for LAN-Adjacency SID!\n"); > > $ grep "TLV size does not match expected size for" isisd/isis_tlvs.c | wc -l > 25 Signed-off-by: Hiroki Shirokura <hiroki.shirokura@linecorp.com> Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
IS-IS Extensions for Segment Routing (RFC8667) defines a variable length SR-Algorithm Sub-TLV (of the router capability TLV) that includes a list of supported SR algorithms. Each algorithm number is one octet. Only two algorithms were defined at the time 8667 was written: SPF (0) and Strict SPF (1). draft-ietf-lsr-flex-algo-18 reserves the range of algorithm numbers from 128 to 255 for Flex-Algo definitions. As a result, the SR-Algorithm Sub-TLV may now, in practice, hold more than two algorithm identifiers. The internal "struct ls_node", defined in link_state.h, has storage space for only two algorithm IDs. Extend this array to 256 entries. Adjust ls_node comparison logic, etc., to accommodate the longer array. Note that the Router Capability TLV allows a maximum of 250 octets for sub-TLVs and that this is not sufficient to hold a list of all possible algorithm IDs. These changes do not account for that limitation. Signed-off-by: Eric Kinzie <ekinzie@labn.net> Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Add the ability to configure a Segment-Routing prefix SID for a given algorithm. For example: > segment-routing prefix 10.10.10.10/32 algorithm 128 index 100 Signed-off-by: Hiroki Shirokura <hiroki.shirokura@linecorp.com> Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Add the ability to configure a Segment-Routing prefix SID for a given algorithm. For example: > segment-routing prefix 10.10.10.10/32 algorithm 128 index 100 Signed-off-by: Hiroki Shirokura <hiroki.shirokura@linecorp.com> Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Add a function to copy a bitfield_t structure. Signed-off-by: Hiroki Shirokura <hiroki.shirokura@linecorp.com> Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Add a library to deal with Flexible Algorithm that will be common to IS-IS and OSPF. The functions enables to deal with: - Affinity-maps - Extended Admin Group (RFC7308) - Flex-Algo structures that contains the flex-algo configurations Signed-off-by: Hiroki Shirokura <hiroki.shirokura@linecorp.com> Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Define the IS-IS flex-algo structure in yang, the CLI configuration commands and the skeletons of frontend and backend functions that are called by the CLI code. Signed-off-by: Hiroki Shirokura <hiroki.shirokura@linecorp.com> Signed-off-by: Eric Kinzie <ekinzie@labn.net> Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Add a function to returns a human readable string of the metric types that are defined in yang. Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Adds basic functionality to Flex-Algo for IS-IS wrapping lib/flex_algo. The configuration interface will be added in the next commit. Signed-off-by: Hiroki Shirokura <hiroki.shirokura@linecorp.com> Signed-off-by: Eric Kinzie <ekinzie@labn.net> Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Add the backend functions for the flex-algo configuration. Signed-off-by: Hiroki Shirokura <hiroki.shirokura@linecorp.com> Signed-off-by: Eric Kinzie <ekinzie@labn.net> Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
f1abeb0 to
cdcdf50
Compare
Add the frontend functions for the flex-algo configuration. Signed-off-by: Hiroki Shirokura <hiroki.shirokura@linecorp.com> Signed-off-by: Eric Kinzie <ekinzie@labn.net> Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
e990c80 to
20dbdd2
Compare
Deal with the packing and unpacking of following Flex-Algo
(Sub-)-Sub-TLVs:
- Router Capability (already defined TLV 242)
- List of the Flex-Algo Definitions (Sub-TLV 26)
- Exclude admin group (Sub-Sub-TLV 1)
- Include-any admin group (Sub-Sub-TLV 2)
- Include-all admin group (Sub-Sub-TLV 3)
- Flags (for prefix-metric) (Sub-Sub-TLV 4)
- Extended IS Reachability (already defined TLV 22)
- Application-Specific Link Attributes (Sub-TLV 16)
(to enable the Flex-Algo flag on a link)
- Admin-group (Sub-Sub-TLV 3)
- Extended Admin-group (Sub-Sub-TLV 14)
Not that:
- Admin-group deals with affinities.
- List of SR Algorithm (Sub-TLV 19) within Router Capability (TLV 242)
are already set in a previous commit.
Signed-off-by: Hiroki Shirokura <hiroki.shirokura@linecorp.com>
Signed-off-by: Eric Kinzie <ekinzie@labn.net>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
20dbdd2 to
a85f482
Compare
Take into account the flex-algo affinity constraints to compute the SPF tree. Signed-off-by: Hiroki Shirokura <hiroki.shirokura@linecorp.com> Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
a85f482 to
9222664
Compare
Create a temporary "merge" route table that contains the routing information from all algorithms and install the merge route table into the FIB. Signed-off-by: Hiroki Shirokura <hiroki.shirokura@linecorp.com> Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
louis-6wind
added a commit
that referenced
this pull request
Apr 14, 2025
> ==238132==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 160 byte(s) in 1 object(s) allocated from: > #0 0x7fd79f0b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7fd79ea6f8dd in qcalloc lib/memory.c:105 > #2 0x5586b26995f9 in bgp_pbr_match_entry_alloc_intern bgpd/bgp_pbr.c:1155 > #3 0x7fd79ea17d79 in hash_get lib/hash.c:147 > FRRouting#4 0x5586b26a551d in bgp_pbr_policyroute_add_to_zebra_unit bgpd/bgp_pbr.c:2522 > FRRouting#5 0x5586b26a6436 in bgp_pbr_policyroute_add_to_zebra bgpd/bgp_pbr.c:2672 > FRRouting#6 0x5586b26a8089 in bgp_pbr_handle_entry bgpd/bgp_pbr.c:2876 > FRRouting#7 0x5586b26a8912 in bgp_pbr_update_entry bgpd/bgp_pbr.c:2939 > FRRouting#8 0x5586b2829472 in bgp_zebra_announce bgpd/bgp_zebra.c:1618 > FRRouting#9 0x5586b282ab4b in bgp_zebra_announce_table bgpd/bgp_zebra.c:1766 > FRRouting#10 0x5586b2824b99 in bgp_zebra_tm_connect bgpd/bgp_zebra.c:1091 > FRRouting#11 0x7fd79eb7798e in event_call lib/event.c:2011 > FRRouting#12 0x7fd79ea42ff1 in frr_run lib/libfrr.c:1216 > FRRouting#13 0x5586b2503a15 in main bgpd/bgp_main.c:545 > FRRouting#14 0x7fd79e429d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Fixes: d114b0d ("bgpd: inject policy route entry from bgp into zebra pbr entries.") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
louis-6wind
added a commit
that referenced
this pull request
Apr 14, 2025
> Direct leak of 1144 byte(s) in 13 object(s) allocated from: > #0 0x7f3eedeb4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7f3eed86f8dd in qcalloc lib/memory.c:105 > #2 0x55b32d236faf in bgp_pbr_match_alloc_intern bgpd/bgp_pbr.c:1074 > #3 0x7f3eed817d79 in hash_get lib/hash.c:147 > FRRouting#4 0x55b32d242d9a in bgp_pbr_policyroute_add_to_zebra_unit bgpd/bgp_pbr.c:2486 > FRRouting#5 0x55b32d244436 in bgp_pbr_policyroute_add_to_zebra bgpd/bgp_pbr.c:2672 > FRRouting#6 0x55b32d245a05 in bgp_pbr_handle_entry bgpd/bgp_pbr.c:2843 > FRRouting#7 0x55b32d246912 in bgp_pbr_update_entry bgpd/bgp_pbr.c:2939 > FRRouting#8 0x55b32d3c7472 in bgp_zebra_announce bgpd/bgp_zebra.c:1618 > FRRouting#9 0x55b32d26e5e7 in bgp_process_main_one bgpd/bgp_route.c:3691 > FRRouting#10 0x55b32d26f77d in process_subq_other_route bgpd/bgp_route.c:3856 > FRRouting#11 0x55b32d2701ff in process_subq bgpd/bgp_route.c:3955 > FRRouting#12 0x55b32d27029f in meta_queue_process bgpd/bgp_route.c:3980 > FRRouting#13 0x7f3eed99fdd8 in work_queue_run lib/workqueue.c:282 > FRRouting#14 0x7f3eed97798e in event_call lib/event.c:2011 > FRRouting#15 0x7f3eed842ff1 in frr_run lib/libfrr.c:1216 > FRRouting#16 0x55b32d0a1a15 in main bgpd/bgp_main.c:545 > FRRouting#17 0x7f3eed229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Fixes: d114b0d ("bgpd: inject policy route entry from bgp into zebra pbr entries.") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
louis-6wind
added a commit
that referenced
this pull request
Apr 14, 2025
Note that bgp_pbr_policyroute_add_from_zebra() and bgp_pbr_policyroute_remove_from_zebra() are only called from bgp_pbr_handle_entry(). > ==966967==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 40 byte(s) in 1 object(s) allocated from: > #0 0x7fd447ab4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7fd44746f8dd in qcalloc lib/memory.c:105 > #2 0x7fd44744401a in list_new lib/linklist.c:49 > #3 0x560f8c094490 in bgp_pbr_handle_entry bgpd/bgp_pbr.c:2818 > FRRouting#4 0x560f8c095993 in bgp_pbr_update_entry bgpd/bgp_pbr.c:2941 > FRRouting#5 0x560f8c2164f3 in bgp_zebra_announce bgpd/bgp_zebra.c:1618 > FRRouting#6 0x560f8c0bd668 in bgp_process_main_one bgpd/bgp_route.c:3691 > FRRouting#7 0x560f8c0be7fe in process_subq_other_route bgpd/bgp_route.c:3856 > FRRouting#8 0x560f8c0bf280 in process_subq bgpd/bgp_route.c:3955 > FRRouting#9 0x560f8c0bf320 in meta_queue_process bgpd/bgp_route.c:3980 > FRRouting#10 0x7fd44759fdfc in work_queue_run lib/workqueue.c:282 > FRRouting#11 0x7fd4475779b2 in event_call lib/event.c:2011 > FRRouting#12 0x7fd447442ff1 in frr_run lib/libfrr.c:1216 > FRRouting#13 0x560f8bef0a15 in main bgpd/bgp_main.c:545 > FRRouting#14 0x7fd446e29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > > Direct leak of 40 byte(s) in 1 object(s) allocated from: > #0 0x7fd447ab4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7fd44746f8dd in qcalloc lib/memory.c:105 > #2 0x7fd44744401a in list_new lib/linklist.c:49 > #3 0x560f8c09439d in bgp_pbr_handle_entry bgpd/bgp_pbr.c:2812 > FRRouting#4 0x560f8c095993 in bgp_pbr_update_entry bgpd/bgp_pbr.c:2941 > FRRouting#5 0x560f8c2164f3 in bgp_zebra_announce bgpd/bgp_zebra.c:1618 > FRRouting#6 0x560f8c0bd668 in bgp_process_main_one bgpd/bgp_route.c:3691 > FRRouting#7 0x560f8c0be7fe in process_subq_other_route bgpd/bgp_route.c:3856 > FRRouting#8 0x560f8c0bf280 in process_subq bgpd/bgp_route.c:3955 > FRRouting#9 0x560f8c0bf320 in meta_queue_process bgpd/bgp_route.c:3980 > FRRouting#10 0x7fd44759fdfc in work_queue_run lib/workqueue.c:282 > FRRouting#11 0x7fd4475779b2 in event_call lib/event.c:2011 > FRRouting#12 0x7fd447442ff1 in frr_run lib/libfrr.c:1216 > FRRouting#13 0x560f8bef0a15 in main bgpd/bgp_main.c:545 > FRRouting#14 0x7fd446e29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > > Direct leak of 4 byte(s) in 1 object(s) allocated from: > #0 0x7fd447ab4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7fd44746f8dd in qcalloc lib/memory.c:105 > #2 0x560f8c080cec in bgp_pbr_extract_enumerate_unary bgpd/bgp_pbr.c:362 > #3 0x560f8c080f7e in bgp_pbr_extract_enumerate bgpd/bgp_pbr.c:400 > FRRouting#4 0x560f8c094530 in bgp_pbr_handle_entry bgpd/bgp_pbr.c:2819 > FRRouting#5 0x560f8c095993 in bgp_pbr_update_entry bgpd/bgp_pbr.c:2941 > FRRouting#6 0x560f8c2164f3 in bgp_zebra_announce bgpd/bgp_zebra.c:1618 > FRRouting#7 0x560f8c0bd668 in bgp_process_main_one bgpd/bgp_route.c:3691 > FRRouting#8 0x560f8c0be7fe in process_subq_other_route bgpd/bgp_route.c:3856 > FRRouting#9 0x560f8c0bf280 in process_subq bgpd/bgp_route.c:3955 > FRRouting#10 0x560f8c0bf320 in meta_queue_process bgpd/bgp_route.c:3980 > FRRouting#11 0x7fd44759fdfc in work_queue_run lib/workqueue.c:282 > FRRouting#12 0x7fd4475779b2 in event_call lib/event.c:2011 > FRRouting#13 0x7fd447442ff1 in frr_run lib/libfrr.c:1216 > FRRouting#14 0x560f8bef0a15 in main bgpd/bgp_main.c:545 > FRRouting#15 0x7fd446e29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > > Direct leak of 4 byte(s) in 1 object(s) allocated from: > #0 0x7fd447ab4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7fd44746f8dd in qcalloc lib/memory.c:105 > #2 0x560f8c080cec in bgp_pbr_extract_enumerate_unary bgpd/bgp_pbr.c:362 > #3 0x560f8c080f7e in bgp_pbr_extract_enumerate bgpd/bgp_pbr.c:400 > FRRouting#4 0x560f8c09443d in bgp_pbr_handle_entry bgpd/bgp_pbr.c:2813 > FRRouting#5 0x560f8c095993 in bgp_pbr_update_entry bgpd/bgp_pbr.c:2941 > FRRouting#6 0x560f8c2164f3 in bgp_zebra_announce bgpd/bgp_zebra.c:1618 > FRRouting#7 0x560f8c0bd668 in bgp_process_main_one bgpd/bgp_route.c:3691 > FRRouting#8 0x560f8c0be7fe in process_subq_other_route bgpd/bgp_route.c:3856 > FRRouting#9 0x560f8c0bf280 in process_subq bgpd/bgp_route.c:3955 > FRRouting#10 0x560f8c0bf320 in meta_queue_process bgpd/bgp_route.c:3980 > FRRouting#11 0x7fd44759fdfc in work_queue_run lib/workqueue.c:282 > FRRouting#12 0x7fd4475779b2 in event_call lib/event.c:2011 > FRRouting#13 0x7fd447442ff1 in frr_run lib/libfrr.c:1216 > FRRouting#14 0x560f8bef0a15 in main bgpd/bgp_main.c:545 > FRRouting#15 0x7fd446e29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
louis-6wind
added a commit
that referenced
this pull request
Apr 14, 2025
Seen with bfd_vrf_topo1 on Ubuntu 22.04 hwe. Do not call ns_delete() from zebra_vrf_delete(), which calls zebra_ns_delete(). - If a netns is removed from the system, vrf_delete()->zebra_vrf_delete() is called before calling ns_delete() (see zebra_ns_notify.c). - If zebra is terminating, zebra_ns_final_shutdown() will call zebra_vrf_delete(). > ==616172==ERROR: AddressSanitizer: heap-use-after-free on address 0x6160000ae3a4 at pc 0x556cdc178d8f bp 0x7ffe4f41ace0 sp 0x7ffe4f41acd0 > READ of size 4 at 0x6160000ae3a4 thread T0 > #0 0x556cdc178d8e in ctx_info_from_zns zebra/zebra_dplane.c:3394 > #1 0x556cdc178f55 in dplane_ctx_ns_init zebra/zebra_dplane.c:3410 > #2 0x556cdc17b829 in dplane_ctx_nexthop_init zebra/zebra_dplane.c:3759 > #3 0x556cdc18095f in dplane_nexthop_update_internal zebra/zebra_dplane.c:4566 > FRRouting#4 0x556cdc1813f1 in dplane_nexthop_delete zebra/zebra_dplane.c:4793 > FRRouting#5 0x556cdc229234 in zebra_nhg_uninstall_kernel zebra/zebra_nhg.c:3484 > FRRouting#6 0x556cdc21f8fe in zebra_nhg_decrement_ref zebra/zebra_nhg.c:1804 > FRRouting#7 0x556cdc24b05a in route_entry_update_nhe zebra/zebra_rib.c:456 > FRRouting#8 0x556cdc255083 in rib_re_nhg_free zebra/zebra_rib.c:2633 > FRRouting#9 0x556cdc25e3bb in rib_unlink zebra/zebra_rib.c:4049 > FRRouting#10 0x556cdc24c9b0 in zebra_rtable_node_cleanup zebra/zebra_rib.c:903 > FRRouting#11 0x7fb25c173144 in route_node_free lib/table.c:75 > FRRouting#12 0x7fb25c17337f in route_table_free lib/table.c:111 > FRRouting#13 0x7fb25c172fe4 in route_table_finish lib/table.c:46 > FRRouting#14 0x556cdc266f62 in zebra_router_free_table zebra/zebra_router.c:191 > FRRouting#15 0x556cdc2673ef in zebra_router_terminate zebra/zebra_router.c:243 > FRRouting#16 0x556cdc10638b in zebra_finalize zebra/main.c:240 > FRRouting#17 0x7fb25c18e012 in event_call lib/event.c:2019 > FRRouting#18 0x7fb25c04afc6 in frr_run lib/libfrr.c:1247 > FRRouting#19 0x556cdc106deb in main zebra/main.c:543 > FRRouting#20 0x7fb25ba29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > FRRouting#21 0x7fb25ba29e3f in __libc_start_main_impl ../csu/libc-start.c:392 > FRRouting#22 0x556cdc0c7ed4 in _start (/usr/lib/frr/zebra+0x192ed4) > > 0x6160000ae3a4 is located 36 bytes inside of 592-byte region [0x6160000ae380,0x6160000ae5d0) > freed by thread T0 here: > #0 0x7fb25c6b4537 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:127 > #1 0x7fb25c0790e3 in qfree lib/memory.c:131 > #2 0x556cdc22d9c9 in zebra_ns_delete zebra/zebra_ns.c:261 > #3 0x7fb25c0ac400 in ns_delete lib/netns_linux.c:319 > FRRouting#4 0x556cdc28026a in zebra_vrf_delete zebra/zebra_vrf.c:343 > FRRouting#5 0x7fb25c197443 in vrf_delete lib/vrf.c:282 > FRRouting#6 0x7fb25c1987e8 in vrf_terminate_single lib/vrf.c:601 > FRRouting#7 0x7fb25c197a7a in vrf_iterate lib/vrf.c:394 > FRRouting#8 0x7fb25c198834 in vrf_terminate lib/vrf.c:609 > FRRouting#9 0x556cdc106345 in zebra_finalize zebra/main.c:223 > FRRouting#10 0x7fb25c18e012 in event_call lib/event.c:2019 > FRRouting#11 0x7fb25c04afc6 in frr_run lib/libfrr.c:1247 > FRRouting#12 0x556cdc106deb in main zebra/main.c:543 > FRRouting#13 0x7fb25ba29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > > previously allocated by thread T0 here: > #0 0x7fb25c6b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7fb25c078f91 in qcalloc lib/memory.c:106 > #2 0x556cdc22d6a1 in zebra_ns_new zebra/zebra_ns.c:231 > #3 0x556cdc22e30b in zebra_ns_init zebra/zebra_ns.c:429 > FRRouting#4 0x556cdc106cec in main zebra/main.c:480 > FRRouting#5 0x7fb25ba29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > > SUMMARY: AddressSanitizer: heap-use-after-free zebra/zebra_dplane.c:3394 in ctx_info_from_zns Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
louis-6wind
added a commit
that referenced
this pull request
Apr 16, 2025
Seen with isis_srv6_topo1 topotest. > ==178793==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 56 byte(s) in 1 object(s) allocated from: > #0 0x7f3f63cb4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7f3f6366f8dd in qcalloc lib/memory.c:105 > #2 0x561b810c62b7 in isis_srv6_sid_alloc isisd/isis_srv6.c:243 > #3 0x561b8111f944 in isis_zebra_srv6_sid_notify isisd/isis_zebra.c:1534 > FRRouting#4 0x7f3f637df9d7 in zclient_read lib/zclient.c:4845 > FRRouting#5 0x7f3f637779b2 in event_call lib/event.c:2011 > FRRouting#6 0x7f3f63642ff1 in frr_run lib/libfrr.c:1216 > FRRouting#7 0x561b81018bf2 in main isisd/isis_main.c:360 > FRRouting#8 0x7f3f63029d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Fixes: 0af0f46 ("isisd: Receive SRv6 SIDs notifications from zebra") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
louis-6wind
added a commit
that referenced
this pull request
Apr 22, 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)
louis-6wind
pushed a commit
that referenced
this pull request
May 12, 2025
A heap use after free when enabling bmp mirror on a non connected BMP target. > Apr 22 14:06:49 vRR-DUT systemd[1]: Started bfdd. > Apr 22 14:06:51 vRR-DUT bgpd[1522]: [VTCF0-ZHP6C] bmp: missing TX OPEN message for peer Static announcement > Apr 22 14:06:51 vRR-DUT bgpd[1522]: [K3RM9-4A4HY] bmp: missing RX OPEN message for peer Static announcement > Apr 22 14:06:52 vRR-DUT bgpd[1522]: ================================================================= > Apr 22 14:06:52 vRR-DUT bgpd[1522]: ==1522==ERROR: AddressSanitizer: heap-use-after-free on address 0x60f0000321d0 at pc 0x7fe7f11c548e bp 0x7fff49f80d40 sp 0x7fff49f80d30 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: READ of size 8 at 0x60f0000321d0 thread T0 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: #0 0x7fe7f11c548d in typesafe_list_add /build/make-pkg/output/_packages/cp-routing/src/lib/typesafe.h:161 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: #1 0x7fe7f11c9347 in bmp_mirrorq_add_tail /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_bmp.c:116 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: #2 0x7fe7f11d030f in bmp_mirror_packet /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_bmp.c:867 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: #3 0x55c756de3e20 in hook_call_bgp_packet_dump /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_packet.c:55 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: FRRouting#4 0x55c756dfd5ea in bgp_process_packet /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_packet.c:3699 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: FRRouting#5 0x7fe7f5375237 in event_call (/lib/x86_64-linux-gnu/libfrr.so.0+0x375237) > Apr 22 14:06:52 vRR-DUT bgpd[1522]: FRRouting#6 0x7fe7f5242ecf in frr_run (/lib/x86_64-linux-gnu/libfrr.so.0+0x242ecf) > Apr 22 14:06:52 vRR-DUT bgpd[1522]: FRRouting#7 0x55c756c71804 in main /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_main.c:545 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: FRRouting#8 0x7fe7f4c29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: FRRouting#9 0x7fe7f4c29e3f in __libc_start_main_impl ../csu/libc-start.c:392 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: FRRouting#10 0x55c756c6e384 in _start (/usr/bin/bgpd+0x272384) > Apr 22 14:06:52 vRR-DUT bgpd[1522]: 0x60f0000321d0 is located 0 bytes inside of 162-byte region [0x60f0000321d0,0x60f000032272) > Apr 22 14:06:52 vRR-DUT bgpd[1522]: freed by thread T0 here: > Apr 22 14:06:52 vRR-DUT bgpd[1522]: #0 0x7fe7f58b4537 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:127 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: #1 0x7fe7f526f918 in qfree (/lib/x86_64-linux-gnu/libfrr.so.0+0x26f918) > Apr 22 14:06:52 vRR-DUT bgpd[1522]: #2 0x7fe7f11d057b in bmp_mirror_packet /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_bmp.c:875 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: #3 0x55c756de3e20 in hook_call_bgp_packet_dump /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_packet.c:55 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: FRRouting#4 0x55c756dfd5ea in bgp_process_packet /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_packet.c:3699 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: FRRouting#5 0x7fe7f5375237 in event_call (/lib/x86_64-linux-gnu/libfrr.so.0+0x375237) > Apr 22 14:06:52 vRR-DUT bgpd[1522]: FRRouting#6 0x7fe7f5242ecf in frr_run (/lib/x86_64-linux-gnu/libfrr.so.0+0x242ecf) > Apr 22 14:06:52 vRR-DUT bgpd[1522]: FRRouting#7 0x55c756c71804 in main /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_main.c:545 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: FRRouting#8 0x7fe7f4c29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: previously allocated by thread T0 here: > Apr 22 14:06:52 vRR-DUT bgpd[1522]: #0 0x7fe7f58b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: #1 0x7fe7f526f7c6 in qcalloc (/lib/x86_64-linux-gnu/libfrr.so.0+0x26f7c6) > Apr 22 14:06:52 vRR-DUT bgpd[1522]: #2 0x7fe7f11cfd38 in bmp_mirror_packet /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_bmp.c:835 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: #3 0x55c756de3e20 in hook_call_bgp_packet_dump /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_packet.c:55 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: FRRouting#4 0x55c756dfd5ea in bgp_process_packet /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_packet.c:3699 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: FRRouting#5 0x7fe7f5375237 in event_call (/lib/x86_64-linux-gnu/libfrr.so.0+0x375237) > Apr 22 14:06:52 vRR-DUT bgpd[1522]: FRRouting#6 0x7fe7f5242ecf in frr_run (/lib/x86_64-linux-gnu/libfrr.so.0+0x242ecf) > Apr 22 14:06:52 vRR-DUT bgpd[1522]: FRRouting#7 0x55c756c71804 in main /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_main.c:545 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: FRRouting#8 0x7fe7f4c29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: SUMMARY: AddressSanitizer: heap-use-after-free /build/make-pkg/output/_packages/cp-routing/src/lib/typesafe.h:161 in typesafe_list_add > Apr 22 14:06:52 vRR-DUT bgpd[1522]: Shadow bytes around the buggy address: > Apr 22 14:06:52 vRR-DUT bgpd[1522]: 0x0c1e7fffe3e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: 0x0c1e7fffe3f0: 00 00 00 00 00 00 fa fa fa fa fa fa fa fa 00 00 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: 0x0c1e7fffe400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: 0x0c1e7fffe410: 00 00 00 00 fa fa fa fa fa fa fa fa 00 00 00 00 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: 0x0c1e7fffe420: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: =>0x0c1e7fffe430: 00 fa fa fa fa fa fa fa fa fa[fd]fd fd fd fd fd > Apr 22 14:06:52 vRR-DUT bgpd[1522]: 0x0c1e7fffe440: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fa > Apr 22 14:06:52 vRR-DUT bgpd[1522]: 0x0c1e7fffe450: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > Apr 22 14:06:52 vRR-DUT bgpd[1522]: 0x0c1e7fffe460: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > Apr 22 14:06:52 vRR-DUT bgpd[1522]: 0x0c1e7fffe470: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > Apr 22 14:06:52 vRR-DUT bgpd[1522]: 0x0c1e7fffe480: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > Apr 22 14:06:52 vRR-DUT bgpd[1522]: Shadow byte legend (one shadow byte represents 8 application bytes): > Apr 22 14:06:52 vRR-DUT bgpd[1522]: Addressable: 00 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: Partially addressable: 01 02 03 04 05 06 07 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: Heap left redzone: fa > Apr 22 14:06:52 vRR-DUT bgpd[1522]: Freed heap region: fd > Apr 22 14:06:52 vRR-DUT bgpd[1522]: Stack left redzone: f1 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: Stack mid redzone: f2 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: Stack right redzone: f3 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: Stack after return: f5 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: Stack use after scope: f8 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: Global redzone: f9 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: Global init order: f6 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: Poisoned by user: f7 > Apr 22 14:06:52 vRR-DUT bgpd[1522]: Container overflow: fc > Apr 22 14:06:52 vRR-DUT bgpd[1522]: Array cookie: ac > Apr 22 14:06:52 vRR-DUT bgpd[1522]: Intra object redzone: bb > Apr 22 14:06:52 vRR-DUT bgpd[1522]: ASan internal: fe > Apr 22 14:06:52 vRR-DUT bgpd[1522]: Left alloca redzone: ca > Apr 22 14:06:52 vRR-DUT bgpd[1522]: Right alloca redzone: cb > Apr 22 14:06:52 vRR-DUT bgpd[1522]: Shadow gap: cc > Apr 22 14:06:52 vRR-DUT bgpd[1522]: ==1522==ABORTING > Apr 22 14:06:52 vRR-DUT yams[449]: CONFIG: [{'name': 'ttyS0'}] > Apr 22 14:06:52 vRR-DUT zebra[652]: [GE156-FS0MJ][EC 100663299] stream_read_try: read failed on fd 50: Connection reset by peer > Apr 22 14:06:52 vRR-DUT systemd[1]: bgpd.service: Main process exited, code=exited, status=1/FAILURE > Apr 22 14:06:52 vRR-DUT zebra[652]: [GE156-FS0MJ][EC 100663299] stream_read_try: read failed on fd 39: Connection reset by peer > Apr 22 14:06:52 vRR-DUT systemd[1]: bgpd.service: Failed with result 'exit-code'. > Apr 22 14:06:52 vRR-DUT zebra[652]: [N5M5Y-J5BPG][EC 4043309121] Client 'bgp' (session id 0) encountered an error and is shutting down. > Apr 22 14:06:52 vRR-DUT systemd[1]: bgpd.service: Consumed 2.361s CPU time. > Apr 22 14:06:52 vRR-DUT zebra[652]: [N5M5Y-J5BPG][EC 4043309121] Client 'bgp' (session id 1) encountered an error and is shutting down. > Apr 22 14:06:52 vRR-DUT zebra[652]: [JPSA8-5KYEA] client 39 disconnected 0 bgp routes removed from the rib > Apr 22 14:06:52 vRR-DUT zebra[652]: [S929C-NZR3N] client 39 disconnected 0 bgp nhgs removed from the rib > Apr 22 14:06:52 vRR-DUT zebra[652]: [KQB7H-NPVW9] /build/make-pkg/output/_packages/cp-routing/src/zebra/zebra_ptm.c:1285 failed to find process pid registration > Apr 22 14:06:52 vRR-DUT zebra[652]: [JPSA8-5KYEA] client 50 disconnected 0 bgp routes removed from the rib > Apr 22 14:06:52 vRR-DUT zebra[652]: [S929C-NZR3N] client 50 disconnected 0 bgp nhgs removed from the rib > Do not enqueue item in the mirror queue if no reference count has been found in the connection list. Fixes: b1ebe54 ("bgpd: bmp, handle imported bgp instances in bmp_mirror") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
vjardin
pushed a commit
that referenced
this pull request
May 18, 2025
Issue:
When we have bgp peer-group, and prefix are advertised to the
peers in it correctly, it still shows Not advertised to any peer
Fix:
1)Rearranged code, to show 1st non peer-group advertised state
2)Then show peer-group peers
Testing:
router bgp 1001
no bgp ebgp-requires-policy
read-quanta 1
timers bgp 5 60
neighbor nbr_grp1 peer-group
neighbor nbr_grp1 remote-as external
neighbor nbr_grp2 peer-group
neighbor nbr_grp2 remote-as external
neighbor nbr_grp3 peer-group
neighbor nbr_grp3 remote-as external
neighbor 2001:db8:2:252::2 peer-group nbr_grp1
neighbor 2001:db8:2:254::2 peer-group nbr_grp1
neighbor 2001:db8:2:255::2 peer-group nbr_grp1
neighbor 2001:db8:2:253::2 peer-group nbr_grp2
neighbor 2001:db8:3:1::2 peer-group nbr_grp2
neighbor 2001:db8:3:2::2 peer-group nbr_grp3
neighbor 2001:db8:3:3::2 peer-group nbr_grp3
neighbor 2001:db8:3:4::2 peer-group nbr_grp3
neighbor 2001:db8:1:1::2 remote-as external
!
address-family ipv6 unicast
redistribute sharp
neighbor nbr_grp1 activate
neighbor nbr_grp2 activate
neighbor nbr_grp3 activate
neighbor 2001:db8:1:1::2 activate
exit-address-family
exit
!
end
sh bgp ipv6 unicast
BGP table version is 1, local router ID is 192.168.1.1, vrf id 0
Default local pref 100, local AS 1001
Status codes: s suppressed, d damped, h history, u unsorted, * valid, > best, = multipath,
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
*> 2100:cafe::/128 2001:db8::1 0 32768 ?
Displayed 1 routes and 1 total paths
r1# sh bgp ipv6 unicast 2100:cafe::/128
BGP routing table entry for 2100:cafe::/128, version 1
Paths: (1 available, best #1, table default)
Advertised to non peer-group peers:
2001:db8:1:1::2
Advertised to peer-group nbr_grp1 peers:
2001:db8:2:252::2 2001:db8:2:254::2 2001:db8:2:255::2
Advertised to peer-group nbr_grp2 peers:
2001:db8:2:253::2 2001:db8:3:1::2
Advertised to peer-group nbr_grp3 peers:
2001:db8:3:2::2 2001:db8:3:3::2 2001:db8:3:4::2
Local
2001:db8::1 from :: (192.168.1.1)
Origin incomplete, metric 0, weight 32768, valid, sourced, best (First path received)
Last update: Sat Apr 5 20:29:31 2025
1# sh bgp ipv6 unicast 2100:cafe::/128 json
{
"prefix":"2100:cafe::/128",
"version":1,
"advertisedTo":{
"2001:db8:1:1::2":{
"hostname":"r2"
},
"2001:db8:2:252::2":{
"hostname":"r2"
},
"2001:db8:2:254::2":{
"hostname":"r2"
},
"2001:db8:2:255::2":{
"hostname":"r2"
},
"2001:db8:2:253::2":{
"hostname":"r2"
},
"2001:db8:3:1::2":{
"hostname":"r2"
},
"2001:db8:3:2::2":{
"hostname":"r2"
},
"2001:db8:3:3::2":{
"hostname":"r2"
},
"2001:db8:3:4::2":{
"hostname":"r2"
}
},
"paths":[
{
"aspath":{
"string":"Local",
"segments":[
],
"length":0
},
"origin":"incomplete",
"metric":0,
"weight":32768,
"valid":true,
"version":1,
"sourced":true,
"bestpath":{
"overall":true,
"selectionReason":"First path received"
},
"lastUpdate":{
"epoch":1743884971,
"string":"Sat Apr 5 20:29:31 2025"
},
"fibInstalled":true,
"nexthops":[
{
"ip":"2001:db8::1",
"hostname":"r1",
"afi":"ipv6",
"scope":"global",
"linkLocalOnly":false,
"length":16,
"metric":0,
"accessible":true,
"used":true
}
],
"peer":{
"peerId":"::",
"routerId":"192.168.1.1"
}
}
]
}
r1#
Signed-off-by: Soumya Roy <souroy@nvidia.com>
vjardin
pushed a commit
that referenced
this pull request
May 18, 2025
Currently peer group name is not displayed in show bgp vty output and also in json output. This fix adds those information in show bgp command test: BGP routing table entry for 192.168.251.0/30, version 1 Paths: (1 available, best #1, table default) Advertised to peers: 192.168.255.3 192.168.251.2 192.168.252.2 r1-eth0 Local 0.0.0.0 from 0.0.0.0 (192.168.255.1) Origin incomplete, metric 0, weight 32768, valid, sourced, best (First path received) Last update: Tue Apr 29 17:28:02 2025 BGP advertisement output json: { "prefix":"192.168.251.0/30", "version":1, "advertisedTo":{ "192.168.255.3":{ "hostname":"r3", "peerGroup":"PG" }, "192.168.251.2":{ "hostname":"r2", "peerGroup":"PG2" }, "192.168.252.2":{ "hostname":"r4", "peerGroup":"PG2" }, "r1-eth0":{ "hostname":"r2" } }, "paths":[ { "aspath":{ "string":"Local", "segments":[ ], "length":0 }, "origin":"incomplete", "metric":0, "weight":32768, "valid":true, "version":1, "sourced":true, "bestpath":{ "overall":true, "selectionReason":"First path received" }, "lastUpdate":{ "epoch":1744926043, "string":"Thu Apr 17 21:40:43 2025" }, "fibInstalled":true, "nexthops":[ { "ip":"0.0.0.0", "hostname":"r1", "afi":"ipv4", "metric":0, "accessible":true, "used":true } ], "peer":{ "peerId":"0.0.0.0", "routerId":"192.168.255.1" } } ] } Signed-off-by: Soumya Roy <souroy@nvidia.com>
vjardin
pushed a commit
that referenced
this pull request
May 18, 2025
The following crash has been seen: > #0 raise (sig=<optimized out>) at ../sysdeps/unix/sysv/linux/raise.c:51 > #1 0x00007f48a576db78 in core_handler (signo=11, siginfo=0x7ffeee4f2b30, context=0x7ffeee4f2a00) at lib/sigevent.c:262 > #2 <signal handler called> > #3 0x000055aded0d793a in isis_spf_process_lsp (spftree=0x55adee945120, lsp=0x55adee971800, cost=3, depth=1, root_sysid=0x55adee9451ac "", parent=0x55adee9474c0) at isisd/isis_spf.c:887 > FRRouting#4 0x000055aded0d9bd1 in isis_spf_loop (spftree=0x55adee945120, root_sysid=0x55adee9451ac "") at isisd/isis_spf.c:1679 > FRRouting#5 0x000055aded0d9fd1 in isis_run_spf (spftree=0x55adee945120) at isisd/isis_spf.c:1798 > FRRouting#6 0x000055aded0bad65 in isis_spf_run_neighbors (spftree=0x55adee962220) at isisd/isis_lfa.c:1259 > FRRouting#7 0x000055aded0bd896 in isis_spf_run_lfa (area=0x55adee95e200, spftree=0x55adee962220) at isisd/isis_lfa.c:2291 > FRRouting#8 0x000055aded0da0f2 in isis_run_spf_with_protection (area=0x55adee95e200, spftree=0x55adee962220) at isisd/isis_spf.c:1817 > FRRouting#9 0x000055aded0da350 in isis_run_spf_cb (thread=0x7ffeee4f3330) at isisd/isis_spf.c:1870 > FRRouting#10 0x00007f48a5786dcc in thread_call (thread=0x7ffeee4f3330) at lib/thread.c:2002 > FRRouting#11 0x00007f48a57213ee in frr_run (master=0x55adee6cdb40) at lib/libfrr.c:1196 > FRRouting#12 0x000055aded0acda2 in main (argc=2, argv=0x7ffeee4f3548, envp=0x7ffeee4f3560) at isisd/isis_main.c:273 It is caused by an attempt to access lsp->tlvs in isis_spf_process_lsp() label lspfragloop when lsp is NULL. isis_spf_process_lsp() checks that the lsp pointer is not NULL at the function beginning but af8ac8f ("isisd: send/receive LSPs with new parser") has introduced some lsp->tlvs accesses after the lspfragloop label without checking that lsp is not NULL. The crash has been seen in the following situation: - ISIS is configured to import routes from BGP - ISIS classic LFA is enabled on all ISIS interfaces - BGP receives routes from an exabgp peers - exabgp is stopped in the middle while sending new prefixes The same situation without LFA does not trigger the bug. However, it seems that the crash can potentially happen without LFA. Fixes: af8ac8f ("isisd: send/receive LSPs with new parser") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
louis-6wind
added a commit
that referenced
this pull request
Jul 2, 2025
Seen with bfd_vrf_topo1, and bgp_evpn_rt5 on Ubuntu 22.04 hwe. Do not call ns_delete() from zebra_vrf_delete(), which calls zebra_ns_delete(). - If a netns is removed from the system, vrf_delete()->zebra_vrf_delete() is called before calling ns_delete() (see zebra_ns_notify.c). - If zebra is terminating, zebra_ns_final_shutdown() will call zebra_vrf_delete(). > ==616172==ERROR: AddressSanitizer: heap-use-after-free on address 0x6160000ae3a4 at pc 0x556cdc178d8f bp 0x7ffe4f41ace0 sp 0x7ffe4f41acd0 > READ of size 4 at 0x6160000ae3a4 thread T0 > #0 0x556cdc178d8e in ctx_info_from_zns zebra/zebra_dplane.c:3394 > #1 0x556cdc178f55 in dplane_ctx_ns_init zebra/zebra_dplane.c:3410 > #2 0x556cdc17b829 in dplane_ctx_nexthop_init zebra/zebra_dplane.c:3759 > #3 0x556cdc18095f in dplane_nexthop_update_internal zebra/zebra_dplane.c:4566 > FRRouting#4 0x556cdc1813f1 in dplane_nexthop_delete zebra/zebra_dplane.c:4793 > FRRouting#5 0x556cdc229234 in zebra_nhg_uninstall_kernel zebra/zebra_nhg.c:3484 > FRRouting#6 0x556cdc21f8fe in zebra_nhg_decrement_ref zebra/zebra_nhg.c:1804 > FRRouting#7 0x556cdc24b05a in route_entry_update_nhe zebra/zebra_rib.c:456 > FRRouting#8 0x556cdc255083 in rib_re_nhg_free zebra/zebra_rib.c:2633 > FRRouting#9 0x556cdc25e3bb in rib_unlink zebra/zebra_rib.c:4049 > FRRouting#10 0x556cdc24c9b0 in zebra_rtable_node_cleanup zebra/zebra_rib.c:903 > FRRouting#11 0x7fb25c173144 in route_node_free lib/table.c:75 > FRRouting#12 0x7fb25c17337f in route_table_free lib/table.c:111 > FRRouting#13 0x7fb25c172fe4 in route_table_finish lib/table.c:46 > FRRouting#14 0x556cdc266f62 in zebra_router_free_table zebra/zebra_router.c:191 > FRRouting#15 0x556cdc2673ef in zebra_router_terminate zebra/zebra_router.c:243 > FRRouting#16 0x556cdc10638b in zebra_finalize zebra/main.c:240 > FRRouting#17 0x7fb25c18e012 in event_call lib/event.c:2019 > FRRouting#18 0x7fb25c04afc6 in frr_run lib/libfrr.c:1247 > FRRouting#19 0x556cdc106deb in main zebra/main.c:543 > FRRouting#20 0x7fb25ba29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > FRRouting#21 0x7fb25ba29e3f in __libc_start_main_impl ../csu/libc-start.c:392 > FRRouting#22 0x556cdc0c7ed4 in _start (/usr/lib/frr/zebra+0x192ed4) > > 0x6160000ae3a4 is located 36 bytes inside of 592-byte region [0x6160000ae380,0x6160000ae5d0) > freed by thread T0 here: > #0 0x7fb25c6b4537 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:127 > #1 0x7fb25c0790e3 in qfree lib/memory.c:131 > #2 0x556cdc22d9c9 in zebra_ns_delete zebra/zebra_ns.c:261 > #3 0x7fb25c0ac400 in ns_delete lib/netns_linux.c:319 > FRRouting#4 0x556cdc28026a in zebra_vrf_delete zebra/zebra_vrf.c:343 > FRRouting#5 0x7fb25c197443 in vrf_delete lib/vrf.c:282 > FRRouting#6 0x7fb25c1987e8 in vrf_terminate_single lib/vrf.c:601 > FRRouting#7 0x7fb25c197a7a in vrf_iterate lib/vrf.c:394 > FRRouting#8 0x7fb25c198834 in vrf_terminate lib/vrf.c:609 > FRRouting#9 0x556cdc106345 in zebra_finalize zebra/main.c:223 > FRRouting#10 0x7fb25c18e012 in event_call lib/event.c:2019 > FRRouting#11 0x7fb25c04afc6 in frr_run lib/libfrr.c:1247 > FRRouting#12 0x556cdc106deb in main zebra/main.c:543 > FRRouting#13 0x7fb25ba29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > > previously allocated by thread T0 here: > #0 0x7fb25c6b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7fb25c078f91 in qcalloc lib/memory.c:106 > #2 0x556cdc22d6a1 in zebra_ns_new zebra/zebra_ns.c:231 > #3 0x556cdc22e30b in zebra_ns_init zebra/zebra_ns.c:429 > FRRouting#4 0x556cdc106cec in main zebra/main.c:480 > FRRouting#5 0x7fb25ba29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > > SUMMARY: AddressSanitizer: heap-use-after-free zebra/zebra_dplane.c:3394 in ctx_info_from_zns Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com> Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
louis-6wind
pushed a commit
that referenced
this pull request
Jul 2, 2025
A crash is detected on an invalid memory access to the 0x0 address zone. > #0 __pthread_kill_implementation (no_tid=0, signo=11, threadid=130889386464320) > at ./nptl/pthread_kill.c:44 > #1 __pthread_kill_internal (signo=11, threadid=130889386464320) at ./nptl/pthread_kill.c:78 > #2 __GI___pthread_kill (threadid=130889386464320, signo=signo@entry=11) at ./nptl/pthread_kill.c:89 > #3 0x0000770b0f042476 in __GI_raise (sig=11) at ../sysdeps/posix/raise.c:26 > FRRouting#4 0x0000770b0f507846 in core_handler (signo=11, siginfo=0x7ffd4f7ec9f0, context=0x7ffd4f7ec8c0) > at /build/make-pkg/output/_packages/cp-routing/src/lib/sigevent.c:262 > FRRouting#5 <signal handler called> > FRRouting#6 __memmove_evex_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:339 > FRRouting#7 0x0000770b0f50bb54 in sockunion_set (su=0x7ffd4f7ed7b0, family=2, addr=0x0, bytes=4) > at /build/make-pkg/output/_packages/cp-routing/src/lib/sockunion.c:500 > FRRouting#8 0x00005f75d5430817 in nhrp_cie_pull (zb=0x5f75f262c4d0, hdr=0x5f75f2627dd8, nbma=0x7ffd4f7ed6d0, > proto=0x7ffd4f7ed7b0) at /build/make-pkg/output/_packages/cp-routing/src/nhrpd/nhrp_packet.c:180 > FRRouting#9 0x00005f75d5434652 in nhrp_peer_forward (p=0x5f75f2605f30, pp=0x7ffd4f7ed8c0) > at /build/make-pkg/output/_packages/cp-routing/src/nhrpd/nhrp_peer.c:1050 > FRRouting#10 0x00005f75d54356cb in nhrp_peer_recv (p=0x5f75f2605f30, zb=0x5f75f2627da0) > at /build/make-pkg/output/_packages/cp-routing/src/nhrpd/nhrp_peer.c:1341 > FRRouting#11 0x00005f75d5430d8e in nhrp_packet_recvraw (t=0x7ffd4f7ede80) > at /build/make-pkg/output/_packages/cp-routing/src/nhrpd/nhrp_packet.c:332 > FRRouting#12 0x0000770b0f521188 in thread_call (thread=0x7ffd4f7ede80) > at /build/make-pkg/output/_packages/cp-routing/src/lib/thread.c:1825 > FRRouting#13 0x0000770b0f4b7737 in frr_run (master=0x5f75f2440570) > at /build/make-pkg/output/_packages/cp-routing/src/lib/libfrr.c:1155 > FRRouting#14 0x00005f75d542d2b4 in main (argc=3, argv=0x7ffd4f7ee0b8) > at /build/make-pkg/output/_packages/cp-routing/src/nhrpd/nhrp_main.c:317 The incoming nhrp packet is too short, and the call to sockunion_set() uses a 0x0 memory zone, because the whole nhrp packet has been parsed, and the zbuf length used was 0. Fix this by detecting the zbuf remaining length before calling sockunion_set. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
louis-6wind
pushed a commit
that referenced
this pull request
Jul 2, 2025
issue detected by Address Sanitizer Error :
Address Sanitizer Error detected in /tmp_topotests/bgp_listen_l3vrf.test_bgp_listen_l3vrf/r1.asan.bgpd.6703
=================================================================
==6703==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 56 byte(s) in 1 object(s) allocated from:
#0 0x7f34c28b83b7 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77
#1 0x7f34c241b45a in qcalloc lib/memory.c:111
#2 0x7f34c247b1da in prefix_new lib/prefix.c:1192
#3 0x55e0992e2041 in peer_group_listen_range_add bgpd/bgpd.c:3258
FRRouting#4 0x55e099282694 in bgp_listen_range bgpd/bgp_vty.c:4848
FRRouting#5 0x7f34c2397bc0 in cmd_execute_command_real lib/command.c:1011
FRRouting#6 0x7f34c2397edf in cmd_execute_command lib/command.c:1070
FRRouting#7 0x7f34c239840b in cmd_execute lib/command.c:1236
FRRouting#8 0x7f34c24e204e in vty_command lib/vty.c:626
FRRouting#9 0x7f34c24e259b in vty_execute lib/vty.c:1389
FRRouting#10 0x7f34c24e5f97 in vtysh_read lib/vty.c:2408
FRRouting#11 0x7f34c24d2958 in event_call lib/event.c:2005
FRRouting#12 0x7f34c23fc4e0 in frr_run lib/libfrr.c:1247
FRRouting#13 0x55e0990949ff in main bgpd/bgp_main.c:565
FRRouting#14 0x7f34c1e2c249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
SUMMARY: AddressSanitizer: 56 byte(s) leaked in 1 allocation(s).
***********************************************************************************
Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>
louis-6wind
pushed a commit
that referenced
this pull request
Jul 16, 2025
The sub sub tlv options of the srv6 prefix sid option is partially visible hen compiling with enable-bgp-vnc, but not in json neither in other parts of the code. > # show bgp ipv6 vpn > [..] > *> 2001:db9:10::/64 ::@8< 0 32768 ? > UN=:: EC{99:99} label=3 sid=fc05:0:5:cece:2345:: sid_structure=[32,16,32,0] type=bgp, subtype=5 > # show bgp ipv6 vpn detail json > [..] > ,"2001:db9:10::/64": [{"aspath":{"string":"Local","segments":[],"length":0},"nhVrfName":"vrf10","nhVrfId":8, > "announceNexthopSelf":true,"origin":"incomplete","metric":0,"weight":32768,"valid":true,"version":1,"sourced":true, > "local":true,"bestpath":{"overall":true,"selectionReason":"First path received"},"extendedCommunity":{"string":"RT:99:99"}, > "originatorId":"5.5.5.5","remoteLabel":3," id":"fc05:0:5:cece:2345::", > "lastUpdate":{"epoch":1751440457,"string":"Wed Jul 2 09:14:17 2025"}, > "nexthops":[{"ip":"::","hostname":"rt5","afi":"ipv6","scope":"global", > "linkLocalOnly":false,"length":16,"metric":0,"accessible":true,"used":true}], > "peer":{"peerId":"::","routerId":"5.5.5.5"}}] Add json attributes to display the attribute values in a remoteSidStructure entry. Display the attribute values in a show command with detailed information. > rt5# show bgp ipv6 vpn 2001:db9:10::/64 > BGP routing table entry for 5:10:2001:db9:10::/64, version 2 > not allocated > Paths: (1 available, best #1) > Advertised to peers: > fc00:0:1::1 > Local > :: from :: (5.5.5.5) vrf vrf10(8) announce-nh-self > Origin incomplete, metric 0, weight 32768, valid, sourced, local, best (First path received) > Extended Community: RT:99:99 > Originator: 5.5.5.5 > Remote label: 3 > Remote SID: fc05:0:5:cece:2345::, sid structure=[32 16 32 0 0 0] > Last update: Wed Jul 2 09:53:59 2025 > rt5# show bgp ipv6 vpn detail json > [..] > "remoteSid":"fc05:0:5:cece:2345::", > "remoteSidStructure":{ > "locatorBlockLen":32, > "locatorNodeLen":16, > "functionLen":32, > "argumentLen":0, > "transpositionLen":0, > "transpositionOffset":0 > }, Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
louis-6wind
pushed a commit
that referenced
this pull request
Jul 16, 2025
Memory leak happens when modifying srv6 configuration. Some sid notifications events will flush a valid srv6 context. > Direct leak of 736 byte(s) in 2 object(s) allocated from: > #0 0x7c112c0fd340 in calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77 > #1 0x7c112bc3595e in qcalloc lib/memory.c:111 > #2 0x7c112bc4d37e in srv6_locator_alloc lib/srv6.c:227 > #3 0x5f9fa87e7acf in bgp_zebra_srv6_sid_notify bgpd/bgp_zebra.c:3662 > FRRouting#4 0x7c112bd32d12 in zclient_read lib/zclient.c:4804 > FRRouting#5 0x7c112bcfaa90 in event_call lib/event.c:2005 > FRRouting#6 0x7c112bc118a7 in frr_run lib/libfrr.c:1252 > FRRouting#7 0x5f9fa85674b4 in main bgpd/bgp_main.c:565 > FRRouting#8 0x7c112b42a1c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > FRRouting#9 0x7c112b42a28a in __libc_start_main_impl ../csu/libc-start.c:360 > FRRouting#10 0x5f9fa856cbd4 in _start (/usr/lib/frr/bgpd+0x2d5bd4) (BuildId: 16288c5292cf235ab5251a93b7dbae5874c3f4bc) > > Indirect leak of 80 byte(s) in 2 object(s) allocated from: > #0 0x7c112c0fd340 in calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77 > #1 0x7c112bc3595e in qcalloc lib/memory.c:111 > #2 0x7c112bc4d396 in srv6_locator_alloc lib/srv6.c:229 > #3 0x5f9fa87e7acf in bgp_zebra_srv6_sid_notify bgpd/bgp_zebra.c:3662 > FRRouting#4 0x7c112bd32d12 in zclient_read lib/zclient.c:4804 > FRRouting#5 0x7c112bcfaa90 in event_call lib/event.c:2005 > FRRouting#6 0x7c112bc118a7 in frr_run lib/libfrr.c:1252 > FRRouting#7 0x5f9fa85674b4 in main bgpd/bgp_main.c:565 > FRRouting#8 0x7c112b42a1c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > FRRouting#9 0x7c112b42a28a in __libc_start_main_impl ../csu/libc-start.c:360 > FRRouting#10 0x5f9fa856cbd4 in _start (/usr/lib/frr/bgpd+0x2d5bd4) (BuildId: 16288c5292cf235ab5251a93b7dbae5874c3f4bc) Fixes: 7a2e64e ("bgpd: Receive SRv6 SIDs notification from zebra") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
louis-6wind
pushed a commit
that referenced
this pull request
Jul 16, 2025
When SRv6 locator is modified for configuration, a memory leak is observed. > ==26714==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 1104 byte(s) in 3 object(s) allocated from: > #0 0x7fb232cb83b7 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77 > #1 0x7fb232822b79 in qcalloc lib/memory.c:111 > #2 0x7fb23283a8b6 in srv6_locator_alloc lib/srv6.c:227 > #3 0x56347cdd4b57 in bgp_zebra_srv6_sid_notify bgpd/bgp_zebra.c:3661 > FRRouting#4 0x7fb23290d03e in zclient_read lib/zclient.c:4804 > FRRouting#5 0x7fb2328da6a0 in event_call lib/event.c:2005 > FRRouting#6 0x7fb232800791 in frr_run lib/libfrr.c:1252 > FRRouting#7 0x56347cb929ff in main bgpd/bgp_main.c:565 > FRRouting#8 0x7fb23222c249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
louis-6wind
pushed a commit
that referenced
this pull request
Sep 23, 2025
The `match->rule_str` may is NULL, like: ``` ip prefix-list plist1 deny any route-map rm1 deny 10 match evpn default-route ``` The stack: ``` #0 __strcmp_sse42 () at ../sysdeps/x86_64/multiarch/strcmp-sse4_2.S:173 #1 0x00007ffff7e5a7ea in route_map_pentry_process_dependency ( bucket=0x5555561fb270, data=0x7fffffff96e0) at ../lib/routemap.c:2466 #2 0x00007ffff7de983d in hash_iterate (hash=0x555556208e50, func=0x7ffff7e5a6f3 <route_map_pentry_process_dependency>, arg=0x7fffffff96e0) at ../lib/hash.c:252 #3 0x00007ffff7e5a99d in route_map_notify_pentry_dependencies ( affected_name=0x5555561fb720 "plist1", pentry=0x555556201040, event=RMAP_EVENT_PLIST_ADDED) at ../lib/routemap.c:2513 FRRouting#4 0x00007ffff7e4a275 in prefix_list_entry_update_finish (ple=0x555556201040) at ../lib/plist.c:697 FRRouting#5 0x00007ffff7de38c9 in lib_prefix_list_entry_apply_finish (args=0x7fffffff97b0) at ../lib/filter_nb.c:1233 FRRouting#6 0x00007ffff7e3228a in nb_callback_apply_finish (context=0x555556204970, nb_node=0x555555b51860, dnode=0x5555561e47b0, errmsg=0x7fffffff9d00 "", errmsg_len=8192) at ../lib/northbound.c:1772 ``` Signed-off-by: anlan_cs <anlan_cs@126.com>
louis-6wind
pushed a commit
that referenced
this pull request
Oct 29, 2025
Problem 1:
1. when s_client->gr_instance_count > 0 the code removed info
from gr_info_queue and returned without freeing it.
Fix:
We now free info on that early return, so that leak is closed.
Problem 2. During shutdown of zebra, stale clients are scheduled for deletion
in META_QUEUE_GR. But before the META_QUEUE_GR is processed, zebra shuts down
as a result there's a leak
Fix:
Implemented synchronous free on shutdown path.
Leak in both cases:
Indirect leak of 72 byte(s) in 1 object(s) allocated from:
#0 0x7f48922b83b7 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77
#1 0x7f4891e23c0d in qcalloc lib/memory.c:111
#2 0x55602360e3ac in zebra_gr_client_info_create zebra/zebra_gr.c:101
#3 0x55602360e3ac in zread_client_capabilities zebra/zebra_gr.c:359
FRRouting#4 0x5560235f2ead in zserv_handle_commands zebra/zapi_msg.c:4226
FRRouting#5 0x556023719ef1 in zserv_process_messages zebra/zserv.c:561
FRRouting#6 0x7f4891edbc17 in event_call lib/event.c:2009
FRRouting#7 0x7f4891e017d9 in frr_run lib/libfrr.c:1252
FRRouting#8 0x5560235a63eb in main zebra/main.c:552
FRRouting#9 0x7f489190c249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
Signed-off-by: Pooja Jagadeesh Doijode <pdoijode@nvidia.com>
louis-6wind
pushed a commit
that referenced
this pull request
Oct 29, 2025
bgp_flowspec.test_bgp_flowspec_topo started to fail (crash) after this.
Let's revert it for now.
It's freed a bit above already:
hash_release(bpm->entry_hash, bpme);
bgp_pbr_match_entry_free(bpme);
ERROR: AddressSanitizer: attempting to call malloc_usable_size() for pointer which is not owned: 0x60e00009f8a0
#0 0x7f27d6cb7f04 in __interceptor_malloc_usable_size ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:119
#1 0x7f27d6c264f6 in __sanitizer::BufferedStackTrace::Unwind(unsigned long, unsigned long, void*, bool, unsigned int) ../../../../src/libsanitizer/sanitizer_common/sanitizer_stacktrace.h:131
#2 0x7f27d6c264f6 in __asan::asan_malloc_usable_size(void const*, unsigned long, unsigned long) ../../../../src/libsanitizer/asan/asan_allocator.cpp:1058
#3 0x7f27d68254df in mt_count_free lib/memory.c:83
FRRouting#4 0x7f27d68254df in qfree lib/memory.c:135
FRRouting#5 0x5637d57b04a2 in bgp_pbr_match_entry_free bgpd/bgp_pbr.c:977
FRRouting#6 0x5637d57b04a2 in bgp_pbr_flush_entry bgpd/bgp_pbr.c:1737
FRRouting#7 0x5637d57b40be in bgp_pbr_policyroute_remove_from_zebra_unit bgpd/bgp_pbr.c:1980
FRRouting#8 0x5637d57bb7c0 in bgp_pbr_policyroute_remove_from_zebra bgpd/bgp_pbr.c:2144
FRRouting#9 0x5637d57bb7c0 in bgp_pbr_handle_entry bgpd/bgp_pbr.c:2781
FRRouting#10 0x5637d57bb7c0 in bgp_pbr_update_entry bgpd/bgp_pbr.c:2905
FRRouting#11 0x5637d58d23e1 in bgp_zebra_withdraw_actual bgpd/bgp_zebra.c:1733
FRRouting#12 0x5637d57ccc9e in bgp_cleanup_table bgpd/bgp_route.c:7300
FRRouting#13 0x5637d57e27d2 in bgp_cleanup_routes bgpd/bgp_route.c:7318
FRRouting#14 0x5637d5911b91 in bgp_delete bgpd/bgpd.c:4370
FRRouting#15 0x5637d56961b4 in bgp_exit bgpd/bgp_main.c:212
FRRouting#16 0x5637d56961b4 in sigint bgpd/bgp_main.c:162
FRRouting#17 0x7f27d68af501 in frr_sigevent_process lib/sigevent.c:117
FRRouting#18 0x7f27d68db77a in event_fetch lib/event.c:1742
FRRouting#19 0x7f27d68027e4 in frr_run lib/libfrr.c:1251
FRRouting#20 0x5637d5697c55 in main bgpd/bgp_main.c:569
FRRouting#21 0x7f27d630c249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
FRRouting#22 0x7f27d630c304 in __libc_start_main_impl ../csu/libc-start.c:360
FRRouting#23 0x5637d5695ac0 in _start (/usr/lib/frr/bgpd+0x2cfac0)
0x60e00009f8a0 is located 0 bytes inside of 160-byte region [0x60e00009f8a0,0x60e00009f940)
freed by thread T0 here:
#0 0x7f27d6cb76a8 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:52
#1 0x7f27d6825500 in qfree lib/memory.c:136
#2 0x5637d57b0366 in bgp_pbr_match_entry_free bgpd/bgp_pbr.c:977
#3 0x5637d57b0366 in bgp_pbr_flush_entry bgpd/bgp_pbr.c:1715
FRRouting#4 0x5637d57b40be in bgp_pbr_policyroute_remove_from_zebra_unit bgpd/bgp_pbr.c:1980
FRRouting#5 0x5637d57bb7c0 in bgp_pbr_policyroute_remove_from_zebra bgpd/bgp_pbr.c:2144
FRRouting#6 0x5637d57bb7c0 in bgp_pbr_handle_entry bgpd/bgp_pbr.c:2781
FRRouting#7 0x5637d57bb7c0 in bgp_pbr_update_entry bgpd/bgp_pbr.c:2905
FRRouting#8 0x5637d58d23e1 in bgp_zebra_withdraw_actual bgpd/bgp_zebra.c:1733
FRRouting#9 0x5637d57ccc9e in bgp_cleanup_table bgpd/bgp_route.c:7300
FRRouting#10 0x5637d57e27d2 in bgp_cleanup_routes bgpd/bgp_route.c:7318
FRRouting#11 0x5637d5911b91 in bgp_delete bgpd/bgpd.c:4370
FRRouting#12 0x5637d56961b4 in bgp_exit bgpd/bgp_main.c:212
FRRouting#13 0x5637d56961b4 in sigint bgpd/bgp_main.c:162
FRRouting#14 0x7f27d68af501 in frr_sigevent_process lib/sigevent.c:117
FRRouting#15 0x7f27d68db77a in event_fetch lib/event.c:1742
FRRouting#16 0x7f27d68027e4 in frr_run lib/libfrr.c:1251
FRRouting#17 0x5637d5697c55 in main bgpd/bgp_main.c:569
FRRouting#18 0x7f27d630c249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
This reverts commit d0df550.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
louis-6wind
pushed a commit
that referenced
this pull request
Oct 29, 2025
This commit addresses a leak where temporary memory allocated
earlier by the `prefix_copy` function for AF_FLOWSPEC prefixes
was not being freed. To ensure proper memory management, we now
release this temporary memory by calling `prefix_flowspec_ptr_free`.
The ASan leak log for reference:
```
***********************************************************************************
Address Sanitizer Error detected in bgp_flowspec.test_bgp_flowspec_topo/r1.asan.bgpd.11539
=================================================================
==11539==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 56 byte(s) in 2 object(s) allocated from:
#0 0x7feaa956ad28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7feaa8f670da in qcalloc lib/memory.c:105
#2 0x7feaa8fac1d4 in prefix_copy lib/prefix.c:346
#3 0x7feaa8ff43e8 in route_node_get lib/table.c:274
FRRouting#4 0x56247cc798c0 in bgp_node_get bgpd/bgp_table.h:236
FRRouting#5 0x56247cc798c0 in bgp_afi_node_get bgpd/bgp_route.c:145
FRRouting#6 0x56247cc92622 in bgp_update bgpd/bgp_route.c:4188
FRRouting#7 0x56247ce55b21 in bgp_nlri_parse_flowspec bgpd/bgp_flowspec.c:193
FRRouting#8 0x56247cc4cdd8 in bgp_nlri_parse bgpd/bgp_packet.c:350
FRRouting#9 0x56247cc4f37c in bgp_update_receive bgpd/bgp_packet.c:2153
FRRouting#10 0x56247cc591e2 in bgp_process_packet bgpd/bgp_packet.c:3214
FRRouting#11 0x7feaa9005b99 in event_call lib/event.c:1979
FRRouting#12 0x7feaa8f4a379 in frr_run lib/libfrr.c:1213
FRRouting#13 0x56247cb51b21 in main bgpd/bgp_main.c:510
FRRouting#14 0x7feaa7f8dc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
SUMMARY: AddressSanitizer: 56 byte(s) leaked in 2 allocation(s).
***********************************************************************************
```
Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
(cherry picked from commit a7fe30e)
Conflicts:
bgpd/bgp_table.c
lib/prefix.c
lib/prefix.h
lib/table.c
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
louis-6wind
pushed a commit
that referenced
this pull request
Oct 29, 2025
Upon examining this Indirect leak:
Indirect leak of 160 byte(s) in 4 object(s) allocated from:
#0 0x7fe4f40b83b7 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77
#1 0x7fe4f3c24c1d in qcalloc lib/memory.c:111
#2 0x7fe4f3c03441 in list_new lib/linklist.c:49
#3 0x564c81d076f9 in ospf_spf_vertex_copy ospfd/ospf_spf.c:335
FRRouting#4 0x564c81d0bff2 in ospf_spf_copy ospfd/ospf_spf.c:378
FRRouting#5 0x564c81d158e8 in ospf_ti_lfa_generate_p_space ospfd/ospf_ti_lfa.c:787
FRRouting#6 0x564c81d162f5 in ospf_ti_lfa_generate_p_spaces ospfd/ospf_ti_lfa.c:923
FRRouting#7 0x564c81d16532 in ospf_ti_lfa_compute ospfd/ospf_ti_lfa.c:1101
FRRouting#8 0x564c81d0e942 in ospf_spf_calculate_area ospfd/ospf_spf.c:1811
FRRouting#9 0x564c81d0eaa6 in ospf_spf_calculate_areas ospfd/ospf_spf.c:1840
FRRouting#10 0x564c81d0eda2 in ospf_spf_calculate_schedule_worker ospfd/ospf_spf.c:1871
FRRouting#11 0x7fe4f3cdd7c3 in event_call lib/event.c:2009
FRRouting#12 0x7fe4f3c027e9 in frr_run lib/libfrr.c:1252
FRRouting#13 0x564c81c95191 in main ospfd/ospf_main.c:307
FRRouting#14 0x7fe4f370c249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
It was noticed that the vertex has another list that is not being
cleanedup. Let's allow this to happen.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
louis-6wind
pushed a commit
that referenced
this pull request
Oct 29, 2025
…ists Traditionally BGP does wCMP only when the Link-Bandwidth extended community exists, but since we have Next-Next Hop Nodes characteristic, it's useful to allow doing wCMP by using NHC attribute as well. It was discussed a bit about this feature at BalticNOG 2025, and people are interested having this. E.g.: r1# show ip bgp 10.0.0.1/32 BGP routing table entry for 10.0.0.1/32, version 7 Paths: (2 available, best #1, table default) Advertised to peers: 10.255.0.2 10.255.16.6 65002 65003 10.255.0.2 from 10.255.0.2 (10.255.0.2) Origin IGP, valid, external, multipath, best (Older Path) Last update: Sat Sep 27 18:26:39 2025 Characteristics: Next-next Hop Nodes: 10.255.0.3 10.255.0.4 10.255.0.5 BGPID: 10.255.0.3 65006 65007 10.255.16.6 from 10.255.16.6 (10.255.0.6) Origin IGP, valid, external, multipath Last update: Sat Sep 27 18:26:45 2025 Characteristics: Next-next Hop Nodes: 10.255.0.7 10.255.0.8 r1# Here we can see that 10.255.0.2 has 3 nodes behind for 10.0.0.1/32, while 10.255.16.6 has 2, so the weight is adjusted accordingly to distribute the traffic proportionally. r1# show ip route 10.0.0.1/32 Routing entry for 10.0.0.1/32 Known via "bgp", distance 20, metric 0, best Last update 00:01:10 ago * 10.255.16.6, via r1-eth1, weight 169 * 10.255.0.2, via r1-eth0, weight 254 munet> r1 shi ip route show 10.0.0.1 10.0.0.1 nhid 22 proto bgp metric 20 nexthop via 10.255.0.2 dev r1-eth0 weight 254 nexthop via 10.255.16.6 dev r1-eth1 weight 169 Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
louis-6wind
pushed a commit
that referenced
this pull request
Oct 29, 2025
We can do this now in gdb: (rr) walk_bgp_table table Walking BGP table at 0x55bd95ec5b70 AFI: 3, SAFI: 5 Version: 0 (Two-level table: RD -> Routes) === RD: 10.0.0.21:2 === === Dest #1: 0x55bd961a0130 === Prefix: [5]:[0]:[32]:10.1.1.1 dest->flags: 0x1 PROCESS_SCHEDULED --- Path #1 --- bgp_path_info: 0x55bd961a04b0 peer: 0x55bd95ebdfd0 (Static announcement) type: 10, sub_type: 1 (STATIC) flags: 0x80010 VALID UNSORTED uptime: 764569, lock: 1 attr: 0x55bd961a0380 (nexthop: 120.0.0.3) extra: 0x55bd960ac720 [has labels] [has evpn] next: 0x0, prev: 0x0 === RD: 10.0.0.33:1 === === Dest #2: 0x55bd95eb41e0 === Prefix: [5]:[0]:[32]:10.1.1.1 dest->flags: 0x0 --- Path #1 --- bgp_path_info: 0x55bd95ea2a20 peer: 0x55bd95ed56a0 (10.0.0.18) type: 10, sub_type: 0 (NORMAL) flags: 0x418 SELECTED VALID COUNTED uptime: 764568, lock: 2 attr: 0x55bd956aa3b0 (nexthop: 120.0.0.1) extra: 0x55bd960a5d60 [has labels] [has evpn] next: 0x0, prev: 0x0 === Dest #3: 0x55bd960aa4b0 === Prefix: [5]:[0]:[128]:10:0:0:0:0:0:0:1 dest->flags: 0x0 --- Path #1 --- bgp_path_info: 0x55bd960ad190 peer: 0x55bd95ed56a0 (10.0.0.18) type: 10, sub_type: 0 (NORMAL) flags: 0x418 SELECTED VALID COUNTED uptime: 764569, lock: 2 attr: 0x55bd960ad2e0 (nexthop: 120.0.0.1) extra: 0x55bd960aa540 [has labels] [has evpn] next: 0x0, prev: 0x0 === RD: 10.0.0.37:2 === === Dest FRRouting#4: 0x55bd960ad930 === Prefix: [5]:[0]:[32]:20.1.1.1 dest->flags: 0x0 --- Path #1 --- bgp_path_info: 0x55bd960a97b0 peer: 0x55bd95ed56a0 (10.0.0.18) type: 10, sub_type: 0 (NORMAL) flags: 0x418 SELECTED VALID COUNTED uptime: 764568, lock: 2 attr: 0x55bd960a93b0 (nexthop: 120.0.0.1) extra: 0x55bd960a6b30 [has labels] [has evpn] next: 0x0, prev: 0x0 --Type <RET> for more, q to quit, c to continue without paging-- === RD: 10.0.0.41:3 === === Dest FRRouting#5: 0x55bd960a9c30 === Prefix: [5]:[0]:[32]:30.1.1.1 dest->flags: 0x0 --- Path #1 --- bgp_path_info: 0x55bd960a9e10 peer: 0x55bd95ed56a0 (10.0.0.18) type: 10, sub_type: 0 (NORMAL) flags: 0x418 SELECTED VALID COUNTED uptime: 764568, lock: 2 attr: 0x55bd960a9cc0 (nexthop: 120.0.0.1) extra: 0x55bd960a9eb0 [has labels] [has evpn] next: 0x0, prev: 0x0 === Summary === Total destinations with paths: 5 Total paths: 5 Or: (rr) walk_bgp_table table Walking BGP table at 0x55bd95ee53b0 AFI: 2, SAFI: 1 Version: 1 === Dest #1: 0x55bd960ad4a0 === Prefix: IPv6:10:0:0:0:0:0:0:1/128 dest->flags: 0x1 PROCESS_SCHEDULED --- Path #1 --- bgp_path_info: 0x55bd960a5eb0 peer: 0x55bd95ef92c0 (fd00:0:0:5::2) type: 10, sub_type: 0 (NORMAL) flags: 0x80400 COUNTED UNSORTED uptime: 764569, lock: 1 attr: 0x55bd9619fb20 (nexthop: 0.0.0.0) extra: 0x55bd95ef31d0 next: 0x55bd960abe30, prev: 0x0 --- Path #2 --- bgp_path_info: 0x55bd960abe30 peer: 0x55bd95ed56a0 (10.0.0.18) type: 10, sub_type: 5 (IMPORTED) flags: 0x4018 SELECTED VALID ANNC_NH_SELF uptime: 764569, lock: 1 attr: 0x55bd960ad530 (nexthop: 120.0.0.1) extra: 0x55bd960abed0 [has labels] [has vrfleak] next: 0x0, prev: 0x55bd960a5eb0 === Summary === Total destinations with paths: 1 Total paths: 2 People might find this useful. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
louis-6wind
pushed a commit
that referenced
this pull request
Oct 29, 2025
On one interface without any mld/pim/igmp configuration, set the command: `ip igmp require-router-alert` or `ipv6 mld require-router-alert`. It will crash for empty `pim_ifp`. ``` #0 0x000055cd72861d40 in lib_interface_gmp_require_router_alert_modify (args=0x7ffec1894e70) at ../pimd/pim_nb_config.c:4768 #1 0x00007f5cdcda137b in nb_callback_modify (context=0x55cd74647a10, nb_node=0x55cd7441c970, event=NB_EV_APPLY, dnode=0x55cd74646350, resource=0x55cd746470c8, errmsg=0x7ffec1895460 "", errmsg_len=8192) at ../lib/northbound.c:1598 #2 0x00007f5cdcda20b7 in nb_callback_configuration (context=0x55cd74647a10, event=NB_EV_APPLY, change=0x55cd74647090, errmsg=0x7ffec1895460 "", errmsg_len=8192) at ../lib/northbound.c:1962 #3 0x00007f5cdcda261f in nb_transaction_process (event=NB_EV_APPLY, transaction=0x55cd74647a10, errmsg=0x7ffec1895460 "", errmsg_len=8192) at ../lib/northbound.c:2091 FRRouting#4 0x00007f5cdcda0cee in nb_candidate_commit_apply (transaction=0x55cd74647a10, save_transaction=true, transaction_id=0x0, errmsg=0x7ffec1895460 "", errmsg_len=8192) at ../lib/northbound.c:1409 FRRouting#5 0x00007f5cdcda0e76 in nb_candidate_commit (context=..., candidate=0x55cd7439d960, save_transaction=true, comment=0x0, transaction_id=0x0, errmsg=0x7ffec1895460 "", errmsg_len=8192) at ../lib/northbound.c:1449 FRRouting#6 0x00007f5cdcda78aa in nb_cli_classic_commit (vty=0x55cd74639b60) at ../lib/northbound_cli.c:57 FRRouting#7 0x00007f5cdcda7ea5 in nb_cli_apply_changes_internal (vty=0x55cd74639b60, xpath_base=0x7ffec18994f0 "/frr-interface:lib/interface[name='xx']/frr-gmp:gmp/address-family[address-family='frr-routing:ipv4']", clear_pending=false) at ../lib/northbound_cli.c:195 FRRouting#8 0x00007f5cdcda8196 in _nb_cli_apply_changes (vty=0x55cd74639b60, xpath_base=0x7ffec1899940 "./frr-gmp:gmp/address-family[address-family='frr-routing:ipv4']", clear_pending=false) at ../lib/northbound_cli.c:251 ``` Signed-off-by: anlan_cs <anlan_cs@126.com>
louis-6wind
pushed a commit
that referenced
this pull request
Nov 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>
louis-6wind
pushed a commit
that referenced
this pull request
Nov 12, 2025
Before: tor-21# show bgp l2vpn evpn route rd 144.1.1.2:6 EVPN type-1 prefix: [1]:[EthTag]:[ESI]:[IPlen]:[VTEP-IP]:[Frag-id] EVPN type-2 prefix: [2]:[EthTag]:[MAClen]:[MAC] EVPN type-3 prefix: [3]:[EthTag]:[IPlen]:[OrigIP] EVPN type-4 prefix: [4]:[ESI]:[IPlen]:[OrigIP] EVPN type-5 prefix: [5]:[EthTag]:[IPlen]:[IP] BGP routing table entry for 144.1.1.2:6:[5]:[0]:[24]:[50.1.110.0] Paths: (2 available, best #1) Advertised to peers: leaf-21(swp1) leaf-22(swp2) Route [5]:[0]:[24]:[50.1.110.0] VNI 104001 651004 652000 651001 660000 0.0.0.0(leaf-21) from leaf-21(swp1) (6.0.0.26) Origin incomplete, valid, external, multipath, bestpath-from-AS 651004, best (Router ID) Extended Community: RT:4640:104001 ET:8 Rmac:00:00:10:00:01:08 Last update: Mon Sep 29 04:06:01 2025 Route [5]:[0]:[24]:[50.1.110.0] VNI 104001 651004 652000 651001 660000 0.0.0.0(leaf-22) from leaf-22(swp2) (6.0.0.27) Origin incomplete, valid, external, multipath Extended Community: RT:4640:104001 ET:8 Rmac:00:00:10:00:01:08 Last update: Mon Sep 29 04:06:01 2025 After: tor-21# show bgp l2vpn evpn route rd 144.1.1.2:6 EVPN type-1 prefix: [1]:[EthTag]:[ESI]:[IPlen]:[VTEP-IP]:[Frag-id] EVPN type-2 prefix: [2]:[EthTag]:[MAClen]:[MAC] EVPN type-3 prefix: [3]:[EthTag]:[IPlen]:[OrigIP] EVPN type-4 prefix: [4]:[ESI]:[IPlen]:[OrigIP] EVPN type-5 prefix: [5]:[EthTag]:[IPlen]:[IP] BGP routing table entry for 144.1.1.2:6:[5]:[0]:[24]:[50.1.110.0] Paths: (2 available, best #1) Advertised to peers: leaf-21(swp1) leaf-22(swp2) Route [5]:[0]:[24]:[50.1.110.0] VNI 104001 651004 652000 651001 660000 2006:27:27::1(leaf-21) from leaf-21(swp1) (6.0.0.26) Origin incomplete, valid, external, multipath, bestpath-from-AS 651004, best (Router ID) Extended Community: RT:4640:104001 ET:8 Rmac:00:00:10:00:01:08 Last update: Mon Sep 29 00:36:28 2025 Route [5]:[0]:[24]:[50.1.110.0] VNI 104001 651004 652000 651001 660000 2006:27:27::1(leaf-22) from leaf-22(swp2) (6.0.0.27) Origin incomplete, valid, external, multipath Extended Community: RT:4640:104001 ET:8 Rmac:00:00:10:00:01:08 Last update: Mon Sep 29 00:36:28 2025 Signed-off-by: Chirag Shah <chirag@nvidia.com>
louis-6wind
pushed a commit
that referenced
this pull request
Nov 25, 2025
When we have something like:
```
*> 10.0.8.0/25 10.113.78.2 0 100 0 (65506 65507) 800 ?
* i 10.113.78.2 0 100 0 (65506 65507) 800 ?
* 10.113.19.2 0 900 800 ?
*> 10.0.8.128/25 10.113.78.2 0 100 0 (65506 65507) 800 ?
* i 10.113.78.2 0 100 0 (65506 65507) 800 ?
* 10.113.19.2 0 900 800 ?
```
And then create an aggregate with as-set, we had:
```
*> 10.0.8.0/24 0.0.0.0 0 32768 {800,900,65506,65507} ?
```
Which is bad (confederation AS is included into AS-SET).
With the fix:
r1 aggregates 10.0.8.0/24
=========================
```
munet> r1 shi vtysh -c 'show bgp ipv4 10.0.8.0/24'
BGP routing table entry for 10.0.8.0/24, version 25
Paths: (1 available, best #1, table default)
Advertised to peers:
10.113.13.2 10.113.16.2 10.113.19.2
[65506,65507] {800,900}, (aggregated by 100 10.113.0.1)
0.0.0.0 from 0.0.0.0 (10.113.0.1)
Origin incomplete, metric 0, weight 32768, valid, aggregated, local, best (First path received)
Last update: Wed Nov 19 10:18:41 2025
```
r3 is a confederation member
============================
```
munet> r3 shi vtysh -c 'show bgp ipv4 10.0.8.0/24'
BGP routing table entry for 10.0.8.0/24, version 22
Paths: (1 available, best #1, table default)
Advertised to peers:
10.113.36.2 10.113.113.2
[65506,65507] {800,900}, (aggregated by 100 10.113.0.1)
10.113.13.1 from 10.113.13.1 (10.113.0.1)
Origin incomplete, metric 0, localpref 100, valid, confed-internal, best (First path received)
Last update: Wed Nov 19 10:18:42 2025
```
r13 is outside the confederation and it should receive the path without confederations
======================================================================================
```
munet> r13 shi vtysh -c 'show bgp ipv4 10.0.8.0/24'
BGP routing table entry for 10.0.8.0/24, version 21
Paths: (1 available, best #1, table default)
Advertised to peers:
10.113.113.1
100 {800,900}, (aggregated by 100 10.113.0.1)
10.113.113.1 from 10.113.113.1 (10.113.0.3)
Origin incomplete, valid, external, best (First path received)
Last update: Wed Nov 19 10:18:42 2025
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
louis-6wind
pushed a commit
that referenced
this pull request
Dec 8, 2025
The transposed SID value is not visible from the VPN paths. > r1# show bgp ipv4 vpn 10.0.0.0/24 > BGP routing table entry for 65001:20:10.0.0.0/24, version 3 > not allocated > Paths: (1 available, best #1) > Advertised to peers: > 2001:db8:12::2 > Local > 0.0.0.0 from 0.0.0.0 (192.0.2.1) vrf Vrf20(7) announce-nh-self > Origin incomplete, metric 0, weight 32768, valid, sourced, local, best (First path received) > Extended Community: RT:0:20 > Originator: 192.0.2.1 > Remote label: 16 > Remote SID: 2004:db8:1:1::, sid structure=[40 24 16 0 16 64] > Last update: Wed Nov 26 10:36:13 2025 Add a json field named remoteTransposedSid in json part. > r1# show bgp ipv4 vpn 10.0.0.0/24 json > "originatorId":"192.0.2.1", > "remoteLabel":16, > "remoteTransposedSid":"2004:db8:1:1:1::", > "remoteSid":"2004:db8:1:1::", > "remoteSidStructure":{ > "locatorBlockLen":40, > "locatorNodeLen":24, > "functionLen":16, > "argumentLen":0, > "transpositionLen":16, > "transpositionOffset":64 > }, Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
louis-6wind
pushed a commit
that referenced
this pull request
Dec 8, 2025
When neighbor graceful-shutdown is configured, GSHUT community and LOCAL_PREF=0 should apply to all routes advertised to that neighbor, including locally originated routes (network command, redistribute). Previously, GSHUT only applied to received routes from that neighbor. This fix ensures originated routes also get GSHUT treatment. When bgp neighbor GSHUT is done, advertise routes recivied from this neighbor with GSHUT attribute. 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>
louis-6wind
pushed a commit
that referenced
this pull request
Dec 17, 2025
The transposed SID value is not visible from the VPN paths. > r1# show bgp ipv4 vpn 10.0.0.0/24 > BGP routing table entry for 65001:20:10.0.0.0/24, version 3 > not allocated > Paths: (1 available, best #1) > Advertised to peers: > 2001:db8:12::2 > Local > 0.0.0.0 from 0.0.0.0 (192.0.2.1) vrf Vrf20(7) announce-nh-self > Origin incomplete, metric 0, weight 32768, valid, sourced, local, best (First path received) > Extended Community: RT:0:20 > Originator: 192.0.2.1 > Remote label: 16 > Remote SID: 2004:db8:1:1::, sid structure=[40 24 16 0 16 64] > Last update: Wed Nov 26 10:36:13 2025 Add a json field named remoteTransposedSid in json part. > r1# show bgp ipv4 vpn 10.0.0.0/24 json > "originatorId":"192.0.2.1", > "remoteLabel":16, > "remoteTransposedSid":"2004:db8:1:1:1::", > "remoteSid":"2004:db8:1:1::", > "remoteSidStructure":{ > "locatorBlockLen":40, > "locatorNodeLen":24, > "functionLen":16, > "argumentLen":0, > "transpositionLen":16, > "transpositionOffset":64 > }, Signed-off-by: Philippe Guibert <philippe.guibert@6wind.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.