summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-04-01Merge pull request #18517 from opensourcerouting/fix/backport_18498_10.1stable/10.1Russ White
bgpd: Retain the routes if we do a clear with N-bit set for Graceful-Restart (backport)
2025-03-27tests: Check if routes are marked as stale and retained with N-bit for GRDonatas Abraitis
Related-to: b7c657d4e065f310fcf6454abae1a963c208c3b8 ("bgpd: Retain the routes if we do a clear with N-bit set for Graceful-Restart") Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2025-03-26bgpd: Retain the routes if we do a clear with N-bit set for Graceful-RestartDonatas Abraitis
On receiving side we already did the job correctly, but the peer which initiates the clear does not retain the other's routes. This commit fixes that. Fixes: 20170775da3a3c5d41aba714d0c1d5a29b0da61c ("bgpd: Activate Graceful-Restart when receiving CEASE/HOLDTIME notifications") Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2025-03-25Merge pull request #18490 from ↵Donald Sharp
opensourcerouting/fix/backport_9a26a56c5188fd1c95e244932bc17f97b9051935_10.1 bgpd: Fix holdtime not working properly when busy
2025-03-25bgpd: Fix holdtime not working properly when busyDonald Sharp
Commit: cc9f21da2218d95567eff1501482ce58e6600f54 Modified the bgp_fsm code to dissallow the extension of the hold time when the system is under extremely heavy load. This was a attempt to remove the return code but it was too aggressive and messed up this bit of code. Put the behavior back that was introduced in: d0874d195d0127009a7d9c06920c52c95319eff9 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-03-23Merge pull request #18465 from ↵Donald Sharp
opensourcerouting/fix/backport_4ee47bfc83e1977458a6049c653019d6b7576320_10.1 bgpd: fix `set evpn gateway-ip ipv[46]` route-map
2025-03-23bgpd: fix `set evpn gateway-ip ipv[46]` route-mapTuetuopay
The `route_set_evpn_gateway_ip` function copies `gw_ip->ip.addr` in the route's gateway ip. In a nutshell, this skips the `ipa_type` field, writing the actual IP in the IP type. This later rightfully trips asserts about unknown IP types. The following route-map... ``` route-map test permit 10 set evpn gateway-ip ipv4 1.1.1.1 ``` ...will make the following gateway IP in the route: ``` (gdb) p/x a1->evpn_overlay->gw_ip $11 = {ipa_type = 0x1010101, ip = {addr = 0x0, addrbytes = { 0x0 <repeats 16 times>}, _v4_addr = {s_addr = 0x0}, _v6_addr = { __in6_u = {__u6_addr8 = {0x0 <repeats 16 times>}, __u6_addr16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, __u6_addr32 = {0x0, 0x0, 0x0, 0x0}}}}} ``` We do indeed see the IP Address in the `ipa_type` field. Fix by starting the memcpy at the root of `struct ipaddr` instead of skipping the `ipa_type` field. Fixes: d0a4ee6010a ("bgpd: Add "set evpn gateway-ip" clause for route-map") Signed-off-by: Tuetuopay <tuetuopay@me.com> (cherry picked from commit 0b0e7015971a788c14dd1dc9b5bac8cb66175c29)
2025-03-22Merge pull request #18457 from FRRouting/mergify/bp/stable/10.1/pr-18108Donald Sharp
zebra: Do not flush an existing vni configuration trying to remove wrong vni (backport #18108)
2025-03-22zebra: Do not flush an existing vni configuration trying to remove wrong vnimergify/bp/stable/10.1/pr-18108Donatas Abraitis
Before: ``` pc.donatas.net(config)# do sh run | include vni vni 1 pc.donatas.net(config)# no vni 2 pc.donatas.net(config)# do sh run | include vni pc.donatas.net(config)# ``` Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org> (cherry picked from commit 44fe3981ee388f7c60ab2635309bce34774116e1)
2025-03-19Merge pull request #18424 from FRRouting/mergify/bp/stable/10.1/pr-18393Jafar Al-Gharaibeh
ospf6d: Disable and delete OSPFv3 areas that no longer have interfaces or configuration. (backport #18393)
2025-03-19 ospf6d: Disable and delete OSPFv3 areas that no longer have interfaces or ↵Acee Lindem
configuration. This fix will delete an OSPFv3 area when all the interfaces and configuration (ranges, NSSA ranges, stub area, NSSA area, filter-list, import-list and export-list) have been removed. The changes provides a general solution to https://github.com/FRRouting/frr/issues/18324. Signed-off-by: Acee Lindem <acee@lindem.com> (cherry picked from commit 04994891fe164b4d5a2819d3bc90e5346f94dc53)
2025-03-17FRR Release 10.1.3frr-10.1.3docker/10.1.3Jafar Al-Gharaibeh
Changelog: bgpd Allow bfd to work if peer known but interface address not yet Apply route-map for aggregate before attribute comparison Do not start bgp session if bgp identifier is not set Don't reuse nexthop variable in loop/switch Fix a bug in peer_allowas_in_set() Fix add label support to evpn ad routes Fix bfd with update-source in peer-group Fix bgp orf prefix-list json prefix Fix crash in bgp_labelpool Fix crash in displaying json orf prefix-list Fix crash upon bgp network import-check command Fix deadlock in bgp_keepalive and master pthreads Fix for local interface mac cache issue in 'bgp mac hash' table Fix incorrect json in bgp_show_table_rd Fix memory leak in bgp_aggregate_install() Fix route-distinguisher in vrf leak json cmd Fix vty output of evpn route-target as4 Fix wrong pthread event cancelling Remove dmed check not required in bestpath selection Reset bgp session only if it was a real bfd down event Update source address for bfd session Use igpmetric in bgp_aigp_metric_total() When bgp notices a change to shared_network inform bfd of it When removing the prefix list drop the pointer With suppress-fib-pending ensure withdrawal is sent Revert: Handle addpath capability using dynamic capabilities Revert: Reinstall aggregated routes if using route-maps and it was changed fpm Guard against garbage in unused address bytes isisd Allow full `no` form for `domain-password` and `area-password` Correct edge insertion into ted Show correct level information for `show isis interface detail json` lib Crash handlers must be allowed on threads Fix false context information for srv6 route Guard against padding garbage in zapi read mgmtd Prevent use after free nhrpd Fix do not consider incomplete l2 entry pbrd Initialize structs used in hash_lookup pimd During prefix-list update, behave as pim_upstream_notjoined state (conformance issue) Fix dr election race on startup Fix for data packet loss when fhr is lhr and rp Fix for fhr mroute taking longer to age out Fix pim vrf support (send register/register stop in vrf) Fix pim6 mld vrf support (use recvmsg() pktinfo) tools Add missing rpki keyword to vrf in frr-reload Fix frr-reload for ebgp-multihop ttl reconfiguration. zebra Evpn svd hash avoid double free Fix resetting valid flags for nhg dependents Guard against junk in nexthop->rmap_src Include resolving nexthops in nhg hash Signed-off-by: Jafar Al-Gharaibeh <jafar@atcorp.com>
2025-03-17Merge pull request #18403 from FRRouting/mergify/bp/stable/10.1/pr-18387Donald Sharp
bgpd: Fixed crash upon bgp network import-check command (backport #18387)
2025-03-15bgpd: Fixed crash upon bgp network import-check commandManpreet Kaur
BT: ``` 3 <signal handler called> 4 0x00005616837546fc in bgp_static_update (bgp=bgp@entry=0x5616865eac50, p=0x561686639e40, bgp_static=0x561686639f50, afi=afi@entry=AFI_IP6, safi=safi@entry=SAFI_UNICAST) at ../bgpd/bgp_route.c:7232 5 0x0000561683754ad0 in bgp_static_add (bgp=0x5616865eac50) at ../bgpd/bgp_table.h:413 6 0x0000561683785e2e in no_bgp_network_import_check (self=<optimized out>, vty=0x5616865e04c0, argc=<optimized out>, argv=<optimized out>) at ../bgpd/bgp_vty.c:4609 7 0x00007fdbcc294820 in cmd_execute_command_real (vline=vline@entry=0x561686663000, ``` The program encountered a SEG FAULT when attempting to access pi->extra->vrfleak->bgp_orig because pi->extra->vrfleak was NULL. ``` (gdb) p pi->extra->vrfleak $1 = (struct bgp_path_info_extra_vrfleak *) 0x0 (gdb) p pi->extra->vrfleak->bgp_orig Cannot access memory at address 0x8 ``` Added NOT NULL check on pi->extra->vrfleak before accessing pi->extra->vrfleak->bgp_orig to prevent the segmentation fault. Signed-off-by: Manpreet Kaur <manpreetk@nvidia.com> (cherry picked from commit bc1008b970541c090e36fc1d50c720df822fcb99)
2025-03-12Merge pull request #18373 from donaldsharp/backport_missing_frr_config_to_10.1Jafar Al-Gharaibeh
Backport missing frr config to 10.1
2025-03-12tests: Add an ability to specify daemon params with unified configDonatas Abraitis
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2025-03-12tests: detect all daemons correctly when using frr.confJafar Al-Gharaibeh
Signed-off-by: Jafar Al-Gharaibeh <jafar@atcorp.com>
2025-03-12tests: Convert self.unified_config to booleanDonatas Abraitis
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2025-03-06Merge pull request #18334 from FRRouting/mergify/bp/stable/10.1/pr-18315Donald Sharp
pimd: Fix PIM6 MLD VRF support (use recvmsg() pktinfo) (backport #18315)
2025-03-06pimd: Fix PIM6 MLD VRF support (use recvmsg() pktinfo)Martin Buck
When receiving MLD messages, prefer pktinfo over msghdr.msg_name for determining the source interface. The latter is just the VRF master interface in case of VRF and we need the true interface the packet was received on instead. Signed-off-by: Martin Buck <mb-tmp-tvguho.pbz@gromit.dyndns.org> (cherry picked from commit 374c8dc4dbc8a560036fecdfb3213f690099b869)
2025-03-04Merge pull request #18298 from FRRouting/mergify/bp/stable/10.1/pr-18294Russ White
isisd: Correct edge insertion into TED (backport #18294)
2025-03-03Merge pull request #18281 from FRRouting/mergify/bp/stable/10.1/pr-18264Donald Sharp
mgmtd: Prevent use after free (backport #18264)
2025-03-03isisd: Correct edge insertion into TEDOlivier Dugeon
Edges are not correctly linked to Vertices during LSP processing. In function lsp_to_edge_cb(), once edge created or updated from the LSP TLVs, the code try to link the edge to destination vertices. In case the revert edge is not found, the code try to found a destination vertex to link to. But, the sys_id used for this operation corresponds to the source vertex. As a result, the edge is attached as source and destination of the vertex. When Traffic Engineering is stopped, TED is deleted which result into a double free of the edge attributes. This cause a crash when attempt to free extended admin groupi the second time. This patch removed wrong code which link twice the edge to the source vertex. Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com> (cherry picked from commit 605fc1dd6404b6ed51691c647568939adde4962a)
2025-02-27mgmtd: Prevent use after freeDonald Sharp
ci is picking up this use after free on occasion: ERROR: AddressSanitizer: attempting to call malloc_usable_size() for pointer which is not owned: 0x6030001d94a0 0 0x7fab994b7f04 in __interceptor_malloc_usable_size ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:119 1 0x7fab994264f6 in __sanitizer::BufferedStackTrace::Unwind(unsigned long, unsigned long, void*, bool, unsigned int) ../../../../src/libsanitizer/sanitizer_common/sanitizer_stacktrace.h:131 2 0x7fab994264f6 in __asan::asan_malloc_usable_size(void const*, unsigned long, unsigned long) ../../../../src/libsanitizer/asan/asan_allocator.cpp:1058 3 0x7fab99039bcf in mt_count_free lib/memory.c:78 4 0x7fab99039bcf in qfree lib/memory.c:130 5 0x7fab98ff971a in hash_clean lib/hash.c:290 6 0x56110cdb0e7f in mgmt_txn_hash_destroy mgmtd/mgmt_txn.c:1881 7 0x56110cdb0e7f in mgmt_txn_destroy mgmtd/mgmt_txn.c:2013 8 0x56110cd8e5de in mgmt_terminate mgmtd/mgmt.c:91 9 0x56110cd8e003 in sigint mgmtd/mgmt_main.c:90 10 0x7fab990bf4b0 in frr_sigevent_process lib/sigevent.c:117 11 0x7fab990ea7a1 in event_fetch lib/event.c:1740 12 0x7fab9901a24e in frr_run lib/libfrr.c:1245 13 0x56110cd8e21f in main mgmtd/mgmt_main.c:290 14 0x7fab98af9249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 15 0x7fab98af9304 in __libc_start_main_impl ../csu/libc-start.c:360 16 0x56110cd8dd30 in _start (/usr/lib/frr/mgmtd+0x3ad30) 0x6030001d94a0 is located 0 bytes inside of 24-byte region [0x6030001d94a0,0x6030001d94b8) freed by thread T0 here: 0 0x7fab994b76a8 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:52 1 0x7fab99039bf0 in qfree lib/memory.c:131 2 0x7fab98ff93e1 in hash_release lib/hash.c:227 3 0x56110cdaabdc in mgmt_txn_unlock mgmtd/mgmt_txn.c:1931 4 0x56110cdab049 in mgmt_txn_delete mgmtd/mgmt_txn.c:1841 5 0x56110cdab0ce in mgmt_txn_hash_free mgmtd/mgmt_txn.c:1864 6 0x7fab98ff970b in hash_clean lib/hash.c:288 7 0x56110cdb0e7f in mgmt_txn_hash_destroy mgmtd/mgmt_txn.c:1881 8 0x56110cdb0e7f in mgmt_txn_destroy mgmtd/mgmt_txn.c:2013 9 0x56110cd8e5de in mgmt_terminate mgmtd/mgmt.c:91 10 0x56110cd8e003 in sigint mgmtd/mgmt_main.c:90 11 0x7fab990bf4b0 in frr_sigevent_process lib/sigevent.c:117 12 0x7fab990ea7a1 in event_fetch lib/event.c:1740 13 0x7fab9901a24e in frr_run lib/libfrr.c:1245 14 0x56110cd8e21f in main mgmtd/mgmt_main.c:290 15 0x7fab98af9249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 previously allocated by thread T0 here: 0 0x7fab994b83b7 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77 1 0x7fab990392fd in qcalloc lib/memory.c:106 2 0x7fab98ff8b4f in hash_get lib/hash.c:156 3 0x56110cdb13ae in mgmt_txn_create_new mgmtd/mgmt_txn.c:1825 4 0x56110cdb3b4d in mgmt_txn_notify_be_adapter_conn mgmtd/mgmt_txn.c:2212 5 0x56110cd91178 in mgmt_be_adapter_conn_init mgmtd/mgmt_be_adapter.c:842 6 0x7fab990ec6de in event_call lib/event.c:2019 7 0x7fab9901a243 in frr_run lib/libfrr.c:1246 8 0x56110cd8e21f in main mgmtd/mgmt_main.c:290 9 0x7fab98af9249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 The only time that mgmt_txn_hash_free is called is in hash_clean. There are other places that mgmt_txn_unlock/delete are called and hash_release should be called. Let's just notice when mgmtd is being called from the hash_clean and not call hash_release (since we know it is being released already) Signed-off-by: Donald Sharp <sharpd@nvidia.com> (cherry picked from commit 62f35c7bdb2a6364dd03ab120e7bb685dd317c24)
2025-02-25Merge pull request #18250 from FRRouting/mergify/bp/stable/10.1/pr-18216Donald Sharp
pimd: Fix PIM VRF support (send register/register stop in VRF) (backport #18216)
2025-02-24pimd: Fix PIM VRF support (send register/register stop in VRF)Martin Buck
In 946195391406269003275850e1a4d550ea8db38b and 8ebcc02328c6b63ecf85e44fdfbf3365be27c127, transmission of PIM register and register stop messages was changed to use a separate socket. However, that socket is not bound to a possible VRF, so the messages were sent in the default VRF instead. Call vrf_bind() once after socket creation and when the VRF is ready to ensure transmission in the correct VRF. vrf_bind() handles the non-VRF case (i.e. VRF_DEFAULT) automatically, so it may be called unconditionally. Signed-off-by: Martin Buck <mb-tmp-tvguho.pbz@gromit.dyndns.org> (cherry picked from commit 5a01011e0d2db538a8ba523904bd4f08b786edfb)
2025-02-22Merge pull request #18229 from FRRouting/mergify/bp/stable/10.1/pr-18210Donald Sharp
bgpd: remove dmed check not required in bestpath selection (backport #18210)
2025-02-21bgpd: remove dmed check not required in bestpath selectionDonald Sharp
As part of the upstream master commit (f3575f61c7 bgpd: Sort the bgp_path_inf) the snippet of the code for dmed check condition left out, which leads to an issue of selecting incorrect bestpath. As an example: During the bestpath selection local route looses to another path due to dmed condition being hit. The snippet of the logs: 2025/02/20 03:06:20.131441 BGP: [JW7VP-K1YVV] [2]:[0]:[48]:[00:92:00:00:00:10](VRF default): Comparing path 27.0.0.7 flags Valid with path Static announcement flags Selected Valid Attr Changed Unsorted 2025/02/20 03:06:20.131445 BGP: [SYTDR-QV6X9] [2]:[0]:[48]:[00:92:00:00:00:10]: path 27.0.0.7 loses to path Static announcement as ES 03:44:38:39:ff:ff:02:00:00:01 is same and local 2025/02/20 03:06:20.131452 BGP: [JW7VP-K1YVV] [2]:[0]:[48]:[00:92:00:00:00:10](VRF default): Comparing path 27.0.0.8 flags Valid with path Static announcement flags Selected Valid Attr Changed Unsorted 2025/02/20 03:06:20.131456 BGP: [SYTDR-QV6X9] [2]:[0]:[48]:[00:92:00:00:00:10]: path 27.0.0.8 loses to path Static announcement as ES 03:44:38:39:ff:ff:02:00:00:01 is same and local 2025/02/20 03:06:20.131458 BGP: [WEWEC-8SE72] [2]:[0]:[48]:[00:92:00:00:00:10](VRF default): path Static announcement is the bestpath from AS 0 <<<< static is best 2025/02/20 03:06:20.131463 BGP: [Z3A78-GM3G5] bgp_best_selection: [2]:[0]:[48]:[00:92:00:00:00:10](VRF default) pi 27.0.0.7 dmed 2025/02/20 03:06:20.131467 BGP: [Z3A78-GM3G5] bgp_best_selection: [2]:[0]:[48]:[00:92:00:00:00:10](VRF default) pi 27.0.0.8 dmed 2025/02/20 03:06:20.131471 BGP: [N6CTF-2RSKS] [2]:[0]:[48]:[00:92:00:00:00:10](VRF default): After path selection, newbest is path 27.0.0.7 oldbest was Static announce Signed-off-by: Donald Sharp <sharpd@nvidia.com> (cherry picked from commit 83ad94694bc061e1ff5f43db42cba46320e0df73)
2025-02-20Merge pull request #18209 from FRRouting/mergify/bp/stable/10.1/pr-17666Donald Sharp
pimd: During prefix-list update, behave as PIM_UPSTREAM_NOTJOINED sta… (backport #17666)
2025-02-20Merge pull request #18205 from FRRouting/mergify/bp/stable/10.1/pr-14227Donald Sharp
pimd: Fix for data packet loss when FHR is LHR and RP (backport #14227)
2025-02-20pimd: During prefix-list update, behave as PIM_UPSTREAM_NOTJOINED state ↵Rajesh Varatharaj
(conformance issue) Issue: If there are any changes to the prefix list, we perform a re-lookup to map the correct RP for the group. Even if the S,G entry is PIM_UPSTREAM_NOTJOINED and in FHR, In the case of IGMPv3, an S,G entry can be created with no joins. this is not necessary. https://www.rfc-editor.org/rfc/rfc4601#section-4.5.7 says no op in case of NOTJOINED Solution: To solve this issue, Stop RP mapping when the state is NOTJOINED Ticket: #3496931 Signed-off-by: Rajesh Varatharaj <rvaratharaj@nvidia.com> (cherry picked from commit 51f26d17da288af44a8a0e536dbe317a7e678514)
2025-02-20pimd: Fix for data packet loss when FHR is LHR and RPRajesh Varatharaj
Topology: A single router is acting as the First Hop Router (FHR), Last Hop Router (LHR), and RP. RC and Issue: When an upstream S,G is in join state, it sends a register message to the RP. If the RP has the receiver, it sends a register stop message and switches to the shortest path. When the register stop message is processed, it removes pimreg, moves to prune, and starts the reg stop timer. When the reg stop timer expires, PIM changes S,G state to Join Pending and sends out a NULL register message to RP. RP receives it and fails to send Reg stop because SPT is not set at that point. The problem is when the register stop timer pops and state is in Join Pending. According to https://www.rfc-editor.org/rfc/rfc4601#section-4.4.1, we need to put back the pimreg reg tunnel into the S,G mroute. This causes data to be sent to the control plane and subsequently interrupts the line rate. Fix: If the router is FHR and RP to the group, ignore SPT status and send out a register stop message back to the DR (in this context, the same router). Ticket: #3506780 Signed-off-by: Donald Sharp <sharpd@nvidia.com> Signed-off-by: Rajesh Varatharaj <rvaratharaj@nvidia.com> (cherry picked from commit 8280257cc99e071c205e469399f2fb41671b30eb)
2025-02-19Merge pull request #18201 from ↵Jafar Al-Gharaibeh
FRRouting/revert-18156-mergify/bp/stable/10.1/pr-18121 Revert "bgpd: release manual vpn label on instance deletion (backport #18121)"
2025-02-19Revert "bgpd: release manual vpn label on instance deletion (backport #18121)"Donald Sharp
2025-02-18Merge pull request #18145 from FRRouting/mergify/bp/stable/10.1/pr-18079Russ White
bgpd: Fix crash in bgp_labelpool (backport #18079)
2025-02-18Merge pull request #18156 from FRRouting/mergify/bp/stable/10.1/pr-18121Russ White
bgpd: release manual vpn label on instance deletion (backport #18121)
2025-02-16Merge pull request #18185 from FRRouting/mergify/bp/stable/10.1/pr-18109Donald Sharp
bgpd: fix vty output of evpn route-target AS4 (backport #18109)
2025-02-15bgpd: fix vty output of evpn route-target AS4Mark Stapp
evpn route-targets are decoded in ... multiple places; at least two have a bug where the AS4 form doesn't have its AS decoded. Signed-off-by: Mark Stapp <mjs@cisco.com> (cherry picked from commit 9943a08720ccbed87cd6938791066a0de94a92c6)
2025-02-15Merge pull request #18175 from cscarpitta/fix/backport_srv6_route_dump_for_10.1Donald Sharp
lib: fix false context information for SRv6 route (backport #18023 for 10.1)
2025-02-15Merge pull request #18168 from FRRouting/mergify/bp/stable/10.1/pr-18160Donald Sharp
bgpd: When removing the prefix list drop the pointer (backport #18160)
2025-02-14lib: fix false context information for SRv6 routePhilippe Guibert
The seg6local route dumped by 'show ipv6 route' makes think that the USP flavor is supported, whereas it is not the case. This information is a context information, and for End, the context information should be empty. > # show ipv6 route > [..] > I>* fc00:0:4::/128 [115/0] is directly connected, sr0, seg6local End USP, weight 1, 00:49:01 Fix this by suppressing the USP information from the output. Fixes: e496b4203055 ("bgpd: prefix-sid srv6 l3vpn service tlv") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2025-02-14bgpd: When removing the prefix list drop the pointerDonald Sharp
We are very very rarely seeing this crash: 0 0x7f36ba48e389 in prefix_list_apply_ext lib/plist.c:789 1 0x55eff3fa4126 in subgroup_announce_check bgpd/bgp_route.c:2334 2 0x55eff3fa858e in subgroup_process_announce_selected bgpd/bgp_route.c:3440 3 0x55eff4016488 in subgroup_announce_table bgpd/bgp_updgrp_adv.c:808 4 0x55eff401664e in subgroup_announce_route bgpd/bgp_updgrp_adv.c:861 5 0x55eff40111df in peer_af_announce_route bgpd/bgp_updgrp.c:2223 6 0x55eff3f884cb in bgp_announce_route_timer_expired bgpd/bgp_route.c:5892 7 0x7f36ba4ec239 in event_call lib/event.c:2019 8 0x7f36ba41a22a in frr_run lib/libfrr.c:1295 9 0x55eff3e668b7 in main bgpd/bgp_main.c:557 10 0x7f36b9e2d249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 11 0x7f36b9e2d304 in __libc_start_main_impl ../csu/libc-start.c:360 12 0x55eff3e64a30 in _start (/home/ci/cibuild.1407/frr-source/bgpd/.libs/bgpd+0x2fda30) 0x608000037038 is located 24 bytes inside of 88-byte region [0x608000037020,0x608000037078) freed by thread T0 here: 0 0x7f36ba8b76a8 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:52 1 0x7f36ba439bd7 in qfree lib/memory.c:131 2 0x7f36ba48d3a3 in prefix_list_free lib/plist.c:156 3 0x7f36ba48d3a3 in prefix_list_delete lib/plist.c:247 4 0x7f36ba48fbef in prefix_bgp_orf_remove_all lib/plist.c:1516 5 0x55eff3f679c4 in bgp_route_refresh_receive bgpd/bgp_packet.c:2841 6 0x55eff3f70bab in bgp_process_packet bgpd/bgp_packet.c:4069 7 0x7f36ba4ec239 in event_call lib/event.c:2019 8 0x7f36ba41a22a in frr_run lib/libfrr.c:1295 9 0x55eff3e668b7 in main bgpd/bgp_main.c:557 10 0x7f36b9e2d249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 previously allocated by thread T0 here: 0 0x7f36ba8b83b7 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77 1 0x7f36ba4392e4 in qcalloc lib/memory.c:106 2 0x7f36ba48d0de in prefix_list_new lib/plist.c:150 3 0x7f36ba48d0de in prefix_list_insert lib/plist.c:186 4 0x7f36ba48d0de in prefix_list_get lib/plist.c:204 5 0x7f36ba48f9df in prefix_bgp_orf_set lib/plist.c:1479 6 0x55eff3f67ba6 in bgp_route_refresh_receive bgpd/bgp_packet.c:2920 7 0x55eff3f70bab in bgp_process_packet bgpd/bgp_packet.c:4069 8 0x7f36ba4ec239 in event_call lib/event.c:2019 9 0x7f36ba41a22a in frr_run lib/libfrr.c:1295 10 0x55eff3e668b7 in main bgpd/bgp_main.c:557 11 0x7f36b9e2d249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Let's just stop trying to save the pointer around in the peer->orf_plist data structure. There are other design problems but at least lets stop the crash from possibly happening. Fixes: #18138 Signed-off-by: Donald Sharp <sharpd@nvidia.com> (cherry picked from commit 3d43d7b78971520854903c11b6aec23754fdca34)
2025-02-13bgpd: release manual vpn label on instance deletionLouis Scalbert
When a BGP instance with a manually assigned VPN label is deleted, the label is not released from the Zebra label registry. As a result, reapplying a configuration with the same manual label leads to VPN prefix export failures. For example, with the following configuration: > router bgp 65000 vrf BLUE > address-family ipv4 unicast > label vpn export <int> Release zebra label registry on unconfiguration. Fixes: d162d5f6f5 ("bgpd: fix hardset l3vpn label available in mpls pool") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com> (cherry picked from commit d6363625c35a99933bf60c9cf0b79627b468c9f7) # Conflicts: # bgpd/bgpd.c
2025-02-13bgpd: Fix crash in bgp_labelpoolDonald Sharp
The bgp labelpool code is grabbing the vpn policy data structure. This vpn_policy has a pointer to the bgp data structure. If a item placed on the bgp label pool workqueue happens to sit there for the microsecond or so and the operator issues a `no router bgp...` command that corresponds to the vpn_policy bgp pointer, when the workqueue is run it will crash because the bgp pointer is now freed and something else owns it. Modify the labelpool code to store the vrf id associated with the request on the workqueue. When you wake up if the vrf id still has a bgp pointer allow the request to continue, else drop it. Signed-off-by: Donald Sharp <sharpd@nvidia.com> (cherry picked from commit 14eac319e8ae9314f5270f871106a70c4986c60c)
2025-02-13Merge pull request #18135 from FRRouting/mergify/bp/stable/10.1/pr-18120Donald Sharp
bgpd: fix incorrect JSON in bgp_show_table_rd (backport #18120)
2025-02-13Merge pull request #18137 from opensourcerouting/fix/backport_bgp_bfd_10.1Donald Sharp
bgp/bfd backports for stable/10.1
2025-02-12bgpd: fix bfd with update-source in peer-groupLouis Scalbert
Fix BFD session not created when the peer is in update-group with the update-source option. Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2025-02-12bgpd: When bgp notices a change to shared_network inform bfd of itDonald Sharp
When bgp is started up and reads the config in *before* it has received interface addresses from zebra, shared_network can be set to false in this case. Later on once bgp attempts to reconnect it will refigure out the shared_network again( because it has received the data from zebra now ). In this case tell bfd about it. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-02-12bgpd: Allow bfd to work if peer known but interface address not yetDonald Sharp
If bgp is coming up and bgp has not received the interface address yet but bgp has knowledge about a bfd peering, allow it to set the peering data appropriately. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-02-12bgpd: Update source address for BFD sessionDonatas Abraitis
If BFD is down, we should try to detect the source automatically from the given interface. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>