summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-04-01Merge pull request #18518 from opensourcerouting/fix/backport_18498_10.0stable/10.0Russ 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 #18491 from ↵Donald Sharp
opensourcerouting/fix/backport_9a26a56c5188fd1c95e244932bc17f97b9051935_10.0 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 #18466 from ↵Donald Sharp
opensourcerouting/fix/backport_4ee47bfc83e1977458a6049c653019d6b7576320_10.0 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 #18458 from FRRouting/mergify/bp/stable/10.0/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.0/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 #18425 from FRRouting/mergify/bp/stable/10.0/pr-18393Donald Sharp
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-17Merge pull request #18405 from FRRouting/mergify/bp/stable/10.0/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-03Merge pull request #18297 from FRRouting/mergify/bp/stable/10.0/pr-18294Donald Sharp
isisd: Correct edge insertion into TED (backport #18294)
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-19Merge pull request #18199 from ↵Jafar Al-Gharaibeh
FRRouting/revert-18157-mergify/bp/stable/10.0/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 #18157 from FRRouting/mergify/bp/stable/10.0/pr-18121Russ White
bgpd: release manual vpn label on instance deletion (backport #18121)
2025-02-16Merge pull request #18186 from FRRouting/mergify/bp/stable/10.0/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 #18174 from cscarpitta/fix/backport_srv6_route_dump_for_10.0Donald Sharp
lib: fix false context information for SRv6 route (backport #18023 for 10.0)
2025-02-15Merge pull request #18169 from FRRouting/mergify/bp/stable/10.0/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-13Merge pull request #18153 from opensourcerouting/fix/backport_bgp_bfd_10.0Donald Sharp
bgp/bfd backports for stable/10.0
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 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-13bgpd: 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-13bgpd: 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-13bgpd: 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>
2025-02-13bgpd: Reset BGP session only if it was a real BFD DOWN eventDonatas Abraitis
Without this patch we always see a double-reset, e.g.: ``` 2024/11/04 12:42:43.010 BGP: [VQY9X-CQZKG] bgp_peer_bfd_update_source: address [0.0.0.0->172.18.0.3] to [172.18.0.2->172.18.0.3] 2024/11/04 12:42:43.010 BGP: [X8BD9-8RKN4] bgp_peer_bfd_update_source: interface none to eth0 2024/11/04 12:42:43.010 BFD: [MSVDW-Y8Z5Q] ptm-del-dest: deregister peer [mhop:no peer:172.18.0.3 local:0.0.0.0 vrf:default cbit:0x00 minimum-ttl:255] 2024/11/04 12:42:43.010 BFD: [NYF5K-SE3NS] ptm-del-session: [mhop:no peer:172.18.0.3 local:0.0.0.0 vrf:default] refcount=0 2024/11/04 12:42:43.010 BFD: [NW21R-MRYNT] session-delete: mhop:no peer:172.18.0.3 local:0.0.0.0 vrf:default 2024/11/04 12:42:43.010 BGP: [P3D3N-3277A] 172.18.0.3 [FSM] Timer (routeadv timer expire) 2024/11/04 12:42:43.010 BFD: [YA0Q5-C0BPV] control-packet: no session found [mhop:no peer:172.18.0.3 local:172.18.0.2 port:11] 2024/11/04 12:42:43.010 BFD: [MSVDW-Y8Z5Q] ptm-add-dest: register peer [mhop:no peer:172.18.0.3 local:172.18.0.2 vrf:default cbit:0x00 minimum-ttl:255] 2024/11/04 12:42:43.011 BFD: [PSB4R-8T1TJ] session-new: mhop:no peer:172.18.0.3 local:172.18.0.2 vrf:default ifname:eth0 2024/11/04 12:42:43.011 BGP: [Q4BCV-6FHZ5] zclient_bfd_session_update: 172.18.0.2/32 -> 172.18.0.3/32 (interface eth0) VRF default(0) (CPI bit no): Down 2024/11/04 12:42:43.011 BGP: [MKVHZ-7MS3V] bfd_session_status_update: neighbor 172.18.0.3 vrf default(0) bfd state Up -> Down 2024/11/04 12:42:43.011 BGP: [HZN6M-XRM1G] %NOTIFICATION: sent to neighbor 172.18.0.3 6/10 (Cease/BFD Down) 0 bytes 2024/11/04 12:42:43.011 BGP: [QFMSE-NPSNN] zclient_bfd_session_update: sessions updated: 1 2024/11/04 12:42:43.011 BGP: [ZWCSR-M7FG9] 172.18.0.3 [FSM] BGP_Stop (Established->Clearing), fd 22 ``` Reset is due to the source address change. With this patch, we reset the session only if it's a _REAL_ BFD down event, which means we trigger session reset if BFD session is established earlier than BGP. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2025-02-13Merge pull request #18136 from FRRouting/mergify/bp/stable/10.0/pr-18120Donald Sharp
bgpd: fix incorrect JSON in bgp_show_table_rd (backport #18120)
2025-02-12bgpd: fix incorrect json in bgp_show_table_rdLouis Scalbert
In bgp_show_table_rd(), the is_last argument is determined using the expression "next == NULL" to check if the RD table is the last one. This helps ensure proper JSON formatting. However, if next is not NULL but is no longer associated with a BGP table, the JSON output becomes malformed. Updates the condition to also verify the existence of the next bgp_dest table. Fixes: 1ae44dfcba ("bgpd: unify 'show bgp' with RD with normal unicast bgp show") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com> (cherry picked from commit cf0269649cdd09b8d3f2dd8815caf6ecf9cdeef9)
2025-02-12Merge pull request #18091 from FRRouting/mergify/bp/stable/10.0/pr-17935Donald Sharp
zebra: include resolving nexthops in nhg hash (backport #17935)
2025-02-11Merge pull request #18104 from FRRouting/mergify/bp/stable/10.0/pr-18060Jafar Al-Gharaibeh
lib: crash handlers must be allowed on threads (backport #18060)
2025-02-11Merge pull request #18086 from FRRouting/mergify/bp/stable/10.0/pr-17901Jafar Al-Gharaibeh
lib: actually hash all 16 bytes of IPv6 addresses, not just 4 (backport #17901)
2025-02-11lib: crash handlers must be allowed on threadsDavid Lamparter
Blocking all signals on non-main threads is not the way to go, at least the handlers for SIGSEGV, SIGBUS, SIGILL, SIGABRT and SIGFPE need to run so we get backtraces. Otherwise the process just exits. Signed-off-by: David Lamparter <equinox@opensourcerouting.org> (cherry picked from commit 13a6ac5b4ca8fc08b348f64de64a787982f24250)
2025-02-11lib: clean up nexthop hashing messDavid Lamparter
We were hashing 4 bytes of the address. Even for IPv6 addresses. Oops. The reason this was done was to try to make it faster, but made a complex maze out of everything. Time for a refactor. Signed-off-by: David Lamparter <equinox@opensourcerouting.org> (cherry picked from commit 001fcfa1dd9f7dc2639b4f5c7a52ab59cc425452)
2025-02-11lib: guard against padding garbage in ZAPI readDavid Lamparter
When reading in a nexthop from ZAPI, only set the fields that actually have meaning. While it shouldn't happen to begin with, we can otherwise carry padding garbage into the unused leftover union bytes. Signed-off-by: David Lamparter <equinox@opensourcerouting.org> (cherry picked from commit 4a0e1419a69d07496c7adfb744beecd00e1efef2)
2025-02-11zebra: guard against junk in nexthop->rmap_srcDavid Lamparter
rmap_src wasn't initialized, so for IPv4 the unused 12 bytes would contain whatever junk is on the stack on function entry. Also move the IPv4 parse before the IPv6 parse so if it's successful we can be sure the other bytes haven't been touched. Signed-off-by: David Lamparter <equinox@opensourcerouting.org> (cherry picked from commit b666ee510eb480da50476b1bbc84bdf8365df95c)
2025-02-11pbrd: initialize structs used in hash_lookupDavid Lamparter
Doesn't seem to break anything but really poor style to pass potentially uninitialized data to hash_lookup. Signed-off-by: David Lamparter <equinox@opensourcerouting.org> (cherry picked from commit c88589f5e9351654c04322eb395003297656989d)
2025-02-11bgpd: don't reuse nexthop variable in loop/switchDavid Lamparter
While the loop is currently exited in all cases after using nexthop, it is a footgun to have "nh" around to be reused in another iteration of the loop. This would leave nexthop with partial data from the previous use. Make it local where needed instead. Signed-off-by: David Lamparter <equinox@opensourcerouting.org> (cherry picked from commit ce7f5b21221f0b3557d1f4a40793230d8bc4cf02)
2025-02-11tests: Add a test that shows the v6 recursive nexthop problemDonald Sharp
Currently FRR does not handle v6 recurisive resolution properly when the route being recursed through changes and the most significant bits of the route are not changed. Signed-off-by: Donald Sharp <sharpd@nvidia.com> (cherry picked from commit 73ab6a46c51db91df297774221053ab8fc4d12ae)
2025-02-11zebra: include resolving nexthops in nhg hashMark Stapp
Ensure that the nhg hash comparison function includes all nexthops, including recursive-resolving nexthops. Signed-off-by: Mark Stapp <mjs@cisco.com> (cherry picked from commit cb7cf73992847cfd4af796085bf14f2fdc4fa8db)
2025-02-05Merge pull request #18017 from ↵Russ White
opensourcerouting/fix/backport_739f2b566a8217acce84d4c21aaf033314f535bb_10.0 bgpd: Do not start BGP session if BGP identifier is not set (backport)
2025-02-05bgpd: Do not start BGP session if BGP identifier is not setDonatas Abraitis
If we have IPv6-only network and no IPv4 addresses at all, then by default 0.0.0.0 is created which is treated as malformed according to RFC 6286. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2025-02-05Merge pull request #18024 from ↵Mark Stapp
opensourcerouting/fix/revert_a73b0f88c7715bfcf5dc8ffd46d2fd0bbc9a8aff Fix 10.0 branch
2025-02-05Revert "tests: Check if OAD peers can exchange non-transitive extended ↵Donatas Abraitis
communities" This reverts commit fa438172d868b0da4c99cd972356dc8ed9f1f016.
2025-02-05Revert "bgpd: Send non-transitive extended communities from/to OAD peers"Donatas Abraitis
This reverts commit a73b0f88c7715bfcf5dc8ffd46d2fd0bbc9a8aff.
2025-02-04Merge pull request #18012 from FRRouting/mergify/bp/stable/10.0/pr-17896Russ White
bgpd: Send non-transitive extended communities from/to OAD peers (backport #17896)