summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
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: 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)
2025-02-04tests: Check if OAD peers can exchange non-transitive extended communitiesDonatas Abraitis
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org> (cherry picked from commit de90b70e65ac7750540a7a9d353d3b3bf4df6fe2)
2025-02-04bgpd: Send non-transitive extended communities from/to OAD peersDonatas Abraitis
draft-uttaro-idr-bgp-oad says: Extended communities which are non-transitive across an AS boundary MAY be advertised over an EBGP-OAD session if allowed by explicit policy configuration. If allowed, all the members of the OAD SHOULD be configured to use the same criteria. For example, the Origin Validation State Extended Community, defined as non-transitive in [RFC8097], can be advertised to peers in the same OAD. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org> (cherry picked from commit f2759c46ceda2a5f13b40213381baf71997b6b87) # Conflicts: # bgpd/bgp_route.c
2025-02-04Merge pull request #17996 from FRRouting/mergify/bp/stable/10.0/pr-17991Russ White
zebra: fix evpn svd hash avoid double free (backport #17991)
2025-02-04Merge pull request #17999 from FRRouting/mergify/bp/stable/10.0/pr-17992Jafar Al-Gharaibeh
bgpd: fix route-distinguisher in vrf leak json cmd (backport #17992)
2025-02-04bgpd: fix route-distinguisher in vrf leak json cmdChirag Shah
For auto configured value RD value comes as NULL, switching back to original change will ensure to cover for both auto and user configured RD value in JSON. tor-11# show bgp vrf blue ipv4 unicast route-leak json { "vrf":"blue", "afiSafi":"ipv4Unicast", "importFromVrfs":[ "purple" ], "importRts":"10.10.3.11:6", "exportToVrfs":[ "purple" ], "routeDistinguisher":"(null)", <<<<< "exportRts":"10.10.3.11:10" } Signed-off-by: Chirag Shah <chirag@nvidia.com> (cherry picked from commit 892704d07f5286464728720648ad392b485a9966)
2025-02-04zebra: evpn svd hash avoid double freeChirag Shah
Upon zebra shutdown hash_clean_and_free is called where user free function is passed, The free function should not call hash_release which lead to double free of hash bucket. Fix: The fix is to avoid calling hash_release from free function if its called from hash_clean_and_free path. 10 0x00007f0422b7df1f in free () from /lib/x86_64-linux-gnu/libc.so.6 11 0x00007f0422edd779 in qfree (mt=0x7f0423047ca0 <MTYPE_HASH_BUCKET>, ptr=0x55fc8bc81980) at ../lib/memory.c:130 12 0x00007f0422eb97e2 in hash_clean (hash=0x55fc8b979a60, free_func=0x55fc8a529478 <svd_nh_del_terminate>) at ../lib/hash.c:290 13 0x00007f0422eb98a1 in hash_clean_and_free (hash=0x55fc8a675920 <svd_nh_table>, free_func=0x55fc8a529478 <svd_nh_del_terminate>) at ../lib/hash.c:305 14 0x000055fc8a5323a5 in zebra_vxlan_terminate () at ../zebra/zebra_vxlan.c:6099 15 0x000055fc8a4c9227 in zebra_router_terminate () at ../zebra/zebra_router.c:276 16 0x000055fc8a4413b3 in zebra_finalize (dummy=0x7fffb881c1d0) at ../zebra/main.c:269 17 0x00007f0422f44387 in event_call (thread=0x7fffb881c1d0) at ../lib/event.c:2011 18 0x00007f0422ecb6fa in frr_run (master=0x55fc8b733cb0) at ../lib/libfrr.c:1243 19 0x000055fc8a441987 in main (argc=14, argv=0x7fffb881c4a8) at ../zebra/main.c:584 Signed-off-by: Chirag Shah <chirag@nvidia.com> (cherry picked from commit 1d4f5b9b19588d77d3eaf06440c26a8c974831a3)
2025-02-02Merge pull request #17973 from FRRouting/mergify/bp/stable/10.0/pr-17971Donatas Abraitis
bgpd: With suppress-fib-pending ensure withdrawal is sent (backport #17971)
2025-02-01bgpd: With suppress-fib-pending ensure withdrawal is sentDonald Sharp
When you have suppress-fib-pending turned on it is possible to end up in a situation where the prefix is not withdrawn from downstream peers. Here is the timing that I believe is happening: a) have 2 paths to a peer. b) receive a withdrawal from 1 path, set BGP_NODE_FIB_INSTALL_PENDING and send the route install to zebra. c) receive a withdrawal from the other path. d) At this point we have a dest->flags set BGP_NODE_FIB_INSTALL_PENDING old_select the path_info going away, new_select is NULL e) A bit further down we call group_announce_route() which calls the code to see if we should advertise the path. It sees the BGP_NODE_FIB_INSTALL_PENDING flag and says, nope. f) the route is sent to zebra to withdraw, which unsets the BGP_NODE_FIB_INSTALL_PENDING. g) This function winds up and deletes the path_info. Dest now has no path infos. h) BGP receives the route install(from step b) and unsets the BGP_NODE_FIB_INSTALL_PENDING flag i) BGP receives the route removed from zebra (from step f) and unsets the flag again. We know if there is no new_select, let's go ahead and just unset the PENDING flag to allow the withdrawal to go out at the time when the second withdrawal is received. Signed-off-by: Donald Sharp <sharpd@nvidia.com> (cherry picked from commit 4e8eda74ec7d30ba84e7f53f077f4b896728505a)
2025-01-29Merge pull request #17951 from FRRouting/mergify/bp/stable/10.0/pr-17946Donatas Abraitis
tools: Fix frr-reload for ebgp-multihop TTL reconfiguration. (backport #17946)
2025-01-29tools: Fix frr-reload for ebgp-multihop TTL reconfiguration.Nobuhiro MIKI
In ebgp-multihop, there is a difference in reload behavior when TTL is unspecified (meaning default 255) and when 255 is explicitly specified. For example, when reloading with 'neighbor <neighbor> ebgp-multihop 255' in the config, the following difference is created. This commit fixes that. Lines To Delete =============== router bgp 65001 no neighbor 10.0.0.4 ebgp-multihop exit Lines To Add ============ router bgp 65001 neighbor 10.0.0.4 ebgp-multihop 255 exit The commit 767aaa3a8048 is not sufficient and frr-reload needs to be fixed to handle both unspecified and specified cases. Signed-off-by: Nobuhiro MIKI <nob@bobuhiro11.net> (cherry picked from commit 594e917656da5502b302309aed3cf596df24713f)
2025-01-28Merge pull request #17940 from ↵Donald Sharp
opensourcerouting/fix/revert_4338e21aa2feba57ea7004c36362e5d8186340b8_10.0 Revert "bgpd: Handle Addpath capability using dynamic capabilities" (backport)
2025-01-28Revert "bgpd: Handle Addpath capability using dynamic capabilities"Donatas Abraitis
This reverts commit 05cf9d03b345393b8d63ffe9345c42debd8362b6. TL;DR; Handling BGP AddPath capability is not trivial (possible) dynamically. When the sender is AddPath-capable and sends NLRIs encoded with AddPath ID, and at the same time the receiver sends AddPath capability "disable-addpath-rx" (flag update) via dynamic capabilities, both peers are out of sync about the AddPath state. The receiver thinks already he's not AddPath-capable anymore, hence it tries to parse NLRIs as non-AddPath, while they are actually encoded as AddPath. AddPath capability itself does not provide (in RFC) any mechanism on backward compatible way to handle NLRIs if they come mixed (AddPath + non-AddPath). This explains why we have failures in our CI periodically. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2025-01-22Merge pull request #17893 from FRRouting/mergify/bp/stable/10.0/pr-17888Donatas Abraitis
bgpd: Fix for local interface MAC cache issue in 'bgp mac hash' table (backport #17888)
2025-01-21bgpd: Fix for local interface MAC cache issue in 'bgp mac hash' tableKrishnasamy R
Issue: During FRR restart, we fail to add some of the local interface's MAC to the 'bgp mac hash'. Not having local MAC in the hash table can cause lookup issues while receiving EVPN RT-2. Currently, we have code to add local MAC(bgp_mac_add_mac_entry) while handling interface add/up events in BGP(bgp_ifp_up/bgp_ifp_create). But the code 'bgp_mac_add_mac_entry' in bgp_ifp_create is not getting invoked as it is placed under a specific check(vrf->bgp link check). Fix: We can skip this check 'vrf->bgp link existence' as the tenant VRF might not have BGP instance but still we want to cache the tenant VRF local MACs. So keeping this check in bgp_ifp_create inline with bgp_ifp_up. Ticket: #4204154 Signed-off-by: Krishnasamy R <krishnasamyr@nvidia.com> (cherry picked from commit 016528364e686fb3b23a688707bd6ae6c5ea5f41)
2025-01-10Merge pull request #17835 from FRRouting/mergify/bp/stable/10.0/pr-17813Donald Sharp
bgpd: use igpmetric in bgp_aigp_metric_total() (backport #17813)
2025-01-10bgpd: use igpmetric in bgp_aigp_metric_total()Enke Chen
Use igpmetric from bgp_path_info in bgp_igp_metric_total() to be consistent with all other cases, e.g., as in bgp_path_info_cmp(). Signed-off-by: Enke Chen <enchen@paloaltonetworks.com> (cherry picked from commit b89e66a3bcd5644278f34ec5899b071066e102a1)
2025-01-10Merge pull request #17817 from FRRouting/mergify/bp/stable/10.0/pr-17807Donatas Abraitis
bgpd: fix crash in displaying json orf prefix-list (backport #17807)
2025-01-09bgpd: fix crash in displaying json orf prefix-listLouis Scalbert
bgpd crashes when there is several entries in the prefix-list. No backtrace is provided because the issue was catched from a code review. Fixes: 856ca177c4 ("Added json formating support to show-...-neighbors-... bgp commands.") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com> (cherry picked from commit 8ccf60921b85893d301186a0f8156fb702da379f)
2025-01-09bgpd: fix bgp orf prefix-list json prefixLouis Scalbert
0x<address>FX was displayed instead of the prefix. Fixes: b219dda129 ("lib: Convert usage of strings to %pFX and %pRN") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com> (cherry picked from commit b7e843d7e8afe57d3815dbb44e30307654e73711)