tests: stop using fifos in bgp...multipath_relax #1
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
Signed-off-by: Christian Hopps <[email protected]>
- also good for testing infra features Signed-off-by: Christian Hopps <[email protected]>
Signed-off-by: Christian Hopps <[email protected]>
Signed-off-by: Christian Hopps <[email protected]>
- format with black in emacs - wrap text at 88 (black) - find the project pylint file Signed-off-by: Christian Hopps <[email protected]>
Signed-off-by: Christian Hopps <[email protected]>
Signed-off-by: Christian Hopps <[email protected]>
Signed-off-by: Christian Hopps <[email protected]>
Signed-off-by: Christian Hopps <[email protected]>
Signed-off-by: Christian Hopps <[email protected]>
Signed-off-by: Christian Hopps <[email protected]>
Signed-off-by: Christian Hopps <[email protected]>
Signed-off-by: Christian Hopps <[email protected]>
Signed-off-by: Christian Hopps <[email protected]>
Signed-off-by: Christian Hopps <[email protected]>
Signed-off-by: Christian Hopps <[email protected]>
Signed-off-by: Christian Hopps <[email protected]>
- Decrease igmp query interval to fix pim test run times Signed-off-by: Christian Hopps <[email protected]>
Signed-off-by: Christian Hopps <[email protected]>
Signed-off-by: Christian Hopps <[email protected]>
Signed-off-by: Christian Hopps <[email protected]>
We already, reasonably, require python3 elsewhere. Do so here, and reap some benefit. Signed-off-by: Christian Hopps <[email protected]>
Signed-off-by: Christian Hopps <[email protected]>
Signed-off-by: Christian Hopps <[email protected]>
Fix CI Failure test_ospf_type5_summary_tc45_p0 Problem Statement: ================== Summarised LSA is not flushed in OSPFv2 in below scenario: 1. Configure summary-address in ospfv2 2. redistribute static and connected. 3. Check the LSAs are received on neighbor. 4. Now remove all OSPFv2 configs, so neighbor will still have the summarised LSA. 5. Configure router ospf with redistribute static and connected. 6. Check the DB, summarised LSA is present although the configuration is not present. 7. Now configure the summary-address and remove the configuration after sometime. 8. The summarised LSA will be still present. RCA: ================== When self originated LSA is received from the neighbor and that LSA is summarised one, the LSA is refreshed but a flag is not set due to which it was not able to remove it later. Fix: ================== Set the originated flag when refreshing summarised LSA. Signed-off-by: Mobashshera Rasool <[email protected]>
- The PIM tests do not need kernel routes to help them bind joins and sources to specific interfaces. They should do that themselves directly. Also do not change system wide "rp_filter" sysctl away from the value required by everyone else. Signed-off-by: Christian Hopps <[email protected]>
Signed-off-by: Martin Winter <[email protected]>
In particular, the fixed 2 second sleep here was not long enough. Switch to standard run_and_expect polling to make test more robust. Signed-off-by: Christian Hopps <[email protected]>
Signed-off-by: Christian Hopps <[email protected]>
New generic script uses a new default node specific log dir to avoid collisions when running in parallel. Signed-off-by: Christian Hopps <[email protected]>
choppsv1
pushed a commit
that referenced
this pull request
Aug 24, 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 <[email protected]>
choppsv1
pushed a commit
that referenced
this pull request
Aug 24, 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 > #4 0x7c112bd32d12 in zclient_read lib/zclient.c:4804 > #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 > #4 0x7c112bd32d12 in zclient_read lib/zclient.c:4804 > #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 <[email protected]>
choppsv1
pushed a commit
that referenced
this pull request
Aug 24, 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 > #4 0x7fb23290d03e in zclient_read lib/zclient.c:4804 > #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 <[email protected]>
choppsv1
pushed a commit
that referenced
this pull request
Aug 24, 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 #4 0x00007ffff7e4a275 in prefix_list_entry_update_finish (ple=0x555556201040) at ../lib/plist.c:697 #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 <[email protected]>
louberger
pushed a commit
that referenced
this pull request
Sep 10, 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 #4 0x00007ffff7e4a275 in prefix_list_entry_update_finish (ple=0x555556201040) at ../lib/plist.c:697 #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 <[email protected]> (cherry picked from commit fa67f51)
louberger
pushed a commit
that referenced
this pull request
Sep 10, 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 #4 0x00007ffff7e4a275 in prefix_list_entry_update_finish (ple=0x555556201040) at ../lib/plist.c:697 #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 <[email protected]> (cherry picked from commit fa67f51)
louberger
pushed a commit
that referenced
this pull request
Sep 10, 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 #4 0x00007ffff7e4a275 in prefix_list_entry_update_finish (ple=0x555556201040) at ../lib/plist.c:697 #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 <[email protected]> (cherry picked from commit fa67f51)
louberger
pushed a commit
that referenced
this pull request
Sep 10, 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 #4 0x00007ffff7e4a275 in prefix_list_entry_update_finish (ple=0x555556201040) at ../lib/plist.c:697 #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 <[email protected]> (cherry picked from commit fa67f51)
louberger
pushed a commit
that referenced
this pull request
Sep 10, 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 #4 0x00007ffff7e4a275 in prefix_list_entry_update_finish (ple=0x555556201040) at ../lib/plist.c:697 #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 <[email protected]> (cherry picked from commit fa67f51)
louberger
pushed a commit
that referenced
this pull request
Sep 25, 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
#4 0x5560235f2ead in zserv_handle_commands zebra/zapi_msg.c:4226
#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 <[email protected]>
louberger
pushed a commit
that referenced
this pull request
Sep 30, 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
#4 0x7f27d68254df in qfree lib/memory.c:135
#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
#4 0x5637d57b40be in bgp_pbr_policyroute_remove_from_zebra_unit bgpd/bgp_pbr.c:1980
#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 <[email protected]>
louberger
pushed a commit
that referenced
this pull request
Oct 2, 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
#4 0x56247cc798c0 in bgp_node_get bgpd/bgp_table.h:236
#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 <[email protected]>
(cherry picked from commit a7fe30e)
Conflicts:
bgpd/bgp_table.c
lib/prefix.c
lib/prefix.h
lib/table.c
Signed-off-by: Louis Scalbert <[email protected]>
Signed-off-by: Philippe Guibert <[email protected]>
louberger
pushed a commit
that referenced
this pull request
Oct 7, 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
#4 0x564c81d0bff2 in ospf_spf_copy ospfd/ospf_spf.c:378
#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 <[email protected]>
louberger
pushed a commit
that referenced
this pull request
Oct 14, 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 <[email protected]>
louberger
pushed a commit
that referenced
this pull request
Oct 14, 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 #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 #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 <[email protected]>
louberger
pushed a commit
that referenced
this pull request
Oct 15, 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 #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 #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 <[email protected]>
louberger
pushed a commit
that referenced
this pull request
Oct 31, 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 <[email protected]>
louberger
pushed a commit
that referenced
this pull request
Nov 1, 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 <[email protected]> (cherry picked from commit ee2b227)
louberger
pushed a commit
that referenced
this pull request
Nov 1, 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 <[email protected]> (cherry picked from commit ee2b227)
louberger
pushed a commit
that referenced
this pull request
Nov 1, 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 <[email protected]> (cherry picked from commit ee2b227)
louberger
pushed a commit
that referenced
this pull request
Nov 7, 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 #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 #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 <[email protected]> (cherry picked from commit 7491c07)
louberger
pushed a commit
that referenced
this pull request
Nov 7, 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 <[email protected]> (cherry picked from commit ee2b227)
louberger
pushed a commit
that referenced
this pull request
Nov 11, 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 <[email protected]>
louberger
pushed a commit
that referenced
this pull request
Nov 19, 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 <[email protected]>
louberger
pushed a commit
that referenced
this pull request
Dec 4, 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 <[email protected]>
louberger
pushed a commit
that referenced
this pull request
Dec 4, 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 <[email protected]>
choppsv1
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 <[email protected]>
choppsv1
pushed a commit
that referenced
this pull request
Jan 7, 2026
Error:
ERROR: AddressSanitizer: heap-use-after-free on address 0x6070000ef8a0 at pc 0x555df66ba094 bp 0x7ffc13d67240 sp 0x7ffc13d67238
READ of size 4 at 0x6070000ef8a0 thread T0
#0 0x555df66ba093 in zebra_gr_delete_stale_route_table_afi zebra/zebra_gr.c:514
#1 0x7fd33d6db06e in event_call lib/event.c:2013
#2 0x7fd33d5fffa1 in frr_run lib/libfrr.c:1257
#3 0x555df66531ec in main zebra/main.c:552
#4 0x7fd33d10c249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
#5 0x7fd33d10c304 in __libc_start_main_impl ../csu/libc-start.c:360
FRRouting#6 0x555df6626b40 in _start (/usr/lib/frr/zebra+0x1a1b40)
0x6070000ef8a0 is located 0 bytes inside of 72-byte region [0x6070000ef8a0,0x6070000ef8e8)
freed by thread T0 here:
#0 0x7fd33dab76a8 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:52
#1 0x7fd33d622cd5 in qfree lib/memory.c:136
#2 0x555df66b9e5f in zebra_gr_client_info_delete zebra/zebra_gr.c:130
#3 0x555df66bc66f in zread_client_capabilities zebra/zebra_gr.c:355
#4 0x555df66a025c in zserv_handle_commands zebra/zapi_msg.c:4228
#5 0x555df67cde33 in zserv_process_messages zebra/zserv.c:565
FRRouting#6 0x7fd33d6db06e in event_call lib/event.c:2013
FRRouting#7 0x7fd33d5fffa1 in frr_run lib/libfrr.c:1257
FRRouting#8 0x555df66531ec in main zebra/main.c:552
FRRouting#9 0x7fd33d10c249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
previously allocated by thread T0 here:
#0 0x7fd33dab83b7 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77
#1 0x7fd33d6223e2 in qcalloc lib/memory.c:111
#2 0x555df66bbace in zebra_gr_client_info_create zebra/zebra_gr.c:101
#3 0x555df66bbace in zread_client_capabilities zebra/zebra_gr.c:360
#4 0x555df66a025c in zserv_handle_commands zebra/zapi_msg.c:4228
#5 0x555df67cde33 in zserv_process_messages zebra/zserv.c:565
FRRouting#6 0x7fd33d6db06e in event_call lib/event.c:2013
FRRouting#7 0x7fd33d5fffa1 in frr_run lib/libfrr.c:1257
FRRouting#8 0x555df66531ec in main zebra/main.c:552
FRRouting#9 0x7fd33d10c249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
Signed-off-by: Pooja Jagadeesh Doijode <[email protected]>
choppsv1
pushed a commit
that referenced
this pull request
Jan 12, 2026
When using the 'sid vpn per-vrf export explicit' command, there is no control to know if the sid func part is corretly encoded in the BGP update. If the func part is over the 20 bit value, then there is missing information, and summing up the label and the sid info is not enough. For instance, the value cece:2222 has to be encoded in the 32 bit func part. > segment-routing > srv6 > locators > locator loc1 > prefix fc00:0:5::/48 block-len 32 node-len 16 func-bits 32 > ! > ! > ! > ! > router bgp 5 vrf vrf10 > address-family ipv6 unicast > sid vpn export explicit fc00:0:5:cece:2222:: > [..] But BGP does not know how to encode the whole SID information. > rt5# show bgp ipv6 vpn 2001:db9:10::/64 > BGP routing table entry for 5:10:2001:db9:10::/64, version 1 > not allocated > Paths: (1 available, best #1) > Advertised to peers: > fc00:0:1::1 > Local > :: from :: (5.5.5.5) vrf vrf10(7) 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: 0 > Remote SID: fc00:0:5:: > Last update: Mon Jun 30 17:15:50 2025 In the case, the function bit length of the locator is over 20 bits, consider encoding the SID in the prefix SID TLV, and do not use the label value. > rt1# show bgp ipv6 vpn 2001:db9:10::/64 > BGP routing table entry for 5:10:2001:db9:10::/64, version 1 > not allocated > Paths: (1 available, best #1) > Advertised to peers: > fc00:0:5::1 fc00:0:6::1 > 5 > fc00:0:5::1 (metric 20) from fc00:0:5::1 (5.5.5.5) > Origin incomplete, metric 0, valid, external, best (First path received) > Extended Community: RT:99:99 > Remote label: 3 > Remote SID: fc00:0:5:cece:2222:: > Last update: Mon Jun 30 17:00:05 2025 Signed-off-by: Philippe Guibert <[email protected]>
choppsv1
pushed a commit
that referenced
this pull request
Jan 17, 2026
The following crash happens, when moving from level-2 to level-1 an isis flex-algorithm configuration > warning: 44 ./nptl/pthread_kill.c: No such file or directory > [Current thread is 1 (Thread 0x7108d4cb2980 (LWP 1023))] > (gdb) bt > #0 __pthread_kill_implementation (no_tid=0, signo=11, > threadid=<optimized out>) at ./nptl/pthread_kill.c:44 > #1 __pthread_kill_internal (signo=11, threadid=<optimized out>) > at ./nptl/pthread_kill.c:78 > #2 __GI___pthread_kill (threadid=<optimized out>, signo=signo@entry=11) > at ./nptl/pthread_kill.c:89 > #3 0x00007108d3e4527e in __GI_raise (sig=11) at ../sysdeps/posix/raise.c:26 > #4 0x00007108d4b44926 in core_handler (signo=11, siginfo=0x7ffe7c10fb30, > context=0x7ffe7c10fa00) > at /build/make-pkg/output/_packages/cp-routing/src/lib/sigevent.c:248 > #5 <signal handler called> > FRRouting#6 0x00005b5d803bf07b in isis_spf_invalidate_routes (tree=0x0) > at /build/make-pkg/output/_packages/cp-routing/src/isisd/isis_spf.c:2118 > FRRouting#7 0x00005b5d803fb23e in isis_area_invalidate_routes (area=0x5b5db8d5be40, > levels=1) > at /build/make-pkg/output/_packages/cp-routing/src/isisd/isisd.c:3152 > FRRouting#8 0x00005b5d803bf280 in isis_run_spf_cb (thread=0x7ffe7c110180) > at /build/make-pkg/output/_packages/cp-routing/src/isisd/isis_spf.c:2165 > FRRouting#9 0x00007108d4b5ff7f in event_call (thread=0x7ffe7c110180) > at /build/make-pkg/output/_packages/cp-routing/src/lib/event.c:2011 > FRRouting#10 0x00007108d4adb761 in frr_run (master=0x5b5db7f7ca40) > at /build/make-pkg/output/_packages/cp-routing/src/lib/libfrr.c:1219 > FRRouting#11 0x00005b5d8038333a in main (argc=5, argv=0x7ffe7c1103d8, > --Type <RET> for more, q to quit, c to continue without paging-- > envp=0x7ffe7c110408) > at /build/make-pkg/output/_packages/cp-routing/src/isisd/isis_main.c:360 > (gdb) Fix this by adding protection before invalidating all routes. Signed-off-by: Philippe Guibert <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
While this works correctly if everything is set up correctly, it fails
very badly if anything is off. Particularly, writing into a fifo that
has no reader on it will hang indefinitely, making it quite annoying to
debug.
Open a proper unix pipe and pass it down instead. Will still fail in
the same situation, but it will fail in a way that is much easier to
understand and address.
(Brought to you by hours of debugging that could've been spent better
elsewhere :/)
Signed-off-by: David Lamparter [email protected]