Philippe Guibert [Fri, 21 Mar 2025 14:49:47 +0000 (15:49 +0100)]
topotests: fix invalidate exported vpn prefixes on srv6l3vpn vrf3 setup
When srv6 is disabled due to misconfiguration, exported VPN prefixes
are invalidated, except for the ones that have their nexthop modified
with the 'nexthop vpn export' command. The previous commit also
invalidates those vpn prefixes.
Apply the changes to the test by not considering some prefixes as
selected. Enforce the expected route count.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Philippe Guibert [Thu, 20 Mar 2025 22:15:30 +0000 (23:15 +0100)]
bgpd: fix check validity of a VPN SRv6 route with modified nexthop
When exporting a VPN SRv6 route, the path may not be considered valid if
the nexthop is not valid. This is the case when the 'nexthop vpn export'
command is used. The below example illustrates that the VPN path to
2001:1::/64 is not selected, as the expected nexthop to find in vrf10 is
the one configured:
Actually, to check the nexthop validity, only the source path in the VRF
has the correct nexthop. Fix this by reusing the source path information
instead of the current one.
Philippe Guibert [Thu, 20 Mar 2025 15:11:59 +0000 (16:11 +0100)]
bgpd: fix do not export VPN prefix when no SID available on the VRF
When detaching the locator from the main BGP instance, the used SIDs
and locators are removed from the srv6 per-afi or per-vrf contects.
Under those conditions, it is not possible to attempt to export new
VPN updates. Do invalidate the nexthop for leaking.
Restrict the control for exported VPN prefixes and not for unicast
imported prefixes.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Philippe Guibert [Fri, 14 Mar 2025 20:09:29 +0000 (21:09 +0100)]
bgpd: fix do not use srv6 SID for NHT when SID is ours
The resulting VPN prefix of a BGP route from a L3VPN in an srv6 setup
is not advertised to remote devices.
> r1# show bgp ipv6 vpn
> BGP table version is 2, local router ID is 1.1.1.1, vrf id 0
> Default local pref 100, local AS 65500
> Status codes: s suppressed, d damped, h history, u unsorted, * valid, > best, = multipath,
> i internal, r RIB-failure, S Stale, R Removed
> Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
> Origin codes: i - IGP, e - EGP, ? - incomplete
> RPKI validation codes: V valid, I invalid, N Not found
>
> Network Next Hop Metric LocPrf Weight Path
> Route Distinguisher: 1:10
> 2011:1::/64 2001:1::2@6< 0 100 0 i
> UN=2001:1::2 EC{99:99} label=4096 sid=2001:db8:1:1:: sid_structure=[40,24,8,0] type=bgp, subtype=5
What happens is that the SID of this BGP update is used as nexthop.
Consequently, the prefix is not valid because of nexthop unreachable.
obviously the locator prefix is not reachable in that L3VRF, and the
real nexthop 2001:1::2 should be used.
> r1# show bgp vrf vrf10 nexthop detail
> Current BGP nexthop cache:
> 2001:db8:1:1:100:: invalid, #paths 1
> Last update: Fri Mar 14 21:18:59 2025
> Paths:
> 2/3 2011:1::/64 RD 1:10 VRF default flags 0x4000
Fix this by considering the SID of a given BGP update, only if the SID
is not ours.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Philippe Guibert [Fri, 14 Mar 2025 20:11:32 +0000 (21:11 +0100)]
topotests: bgp_srv6l3vpn_to_bgp_vrf, add redistribute BGP update in l3vpn
Add a BGP update in CE1 for redistribution. The expectation is that this
BGP update will be leaked to the L3VPN. Reversely, if the locator is
unset, the L3VPN prefix will be invalidated.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Donald Sharp [Fri, 21 Mar 2025 22:08:25 +0000 (18:08 -0400)]
tests: Change up start order of bmp tests
Currently the tests appear to do this:
a) Start the neighbors
b) Start the bmp server connection
c) Look for the neighbors up
d) Look for the neighbor up messages in the bmp log
This is not great from a testing perspective in that
even though we started a) first it may not happen
until after b) happens. Or even worse if it is
partially up ( 1 of the 2 peers ) then the dump
will have the neighbor connecting after parts
of the table. This doesn't work too well because
the SEQ number is something that is kept and compared
to to make sure only new data is being looked at.
Let's modify the startup configuration to start
the bmp server first and then have a delayopen
on the bgp neighbor statements so that the bmp
peering can come up first.
Soumya Roy [Fri, 14 Mar 2025 22:01:51 +0000 (22:01 +0000)]
zebra: reduce memory usage by streams when redistributing routes
This commit undo 8c9b007a0c7efb2e9afc2eac936ba9dd971c6707
stream lib has been modified to expand the stream if needed
Now for zapi route encode, we use expandable stream
Soumya Roy [Fri, 14 Mar 2025 21:56:48 +0000 (21:56 +0000)]
zebra: zebra crash for zapi stream
Issue:
If static route is created with a BGP route as nexthop, which
recursively resolves over 512 ECMP v6 nexthops, zapi nexthop encode
fails, as there is not enough memory allocated for stream. This causes
assert/core dump in zebra. Right now we allocate fixed memory
of ZEBRA_MAX_PACKET_SIZ size.
Fix:
1)Dynamically calculate required memory size for the stream
2)try to optimize memory usage
Testing:
No crash happens anymore with the fix
zebra: zebra crash for zapi stream
Issue:
If static route is created with a BGP route as nexthop, which
recursively resolves over 512 ECMP v6 nexthops, zapi nexthop encode
fails, as there is not enough memory allocated for stream. This causes
assert/core dump in zebra. Right now we allocate fixed memory
of ZEBRA_MAX_PACKET_SIZ size.
Fix:
1)Dynamically calculate required memory size for the stream
2)try to optimize memory usage
Testing:
No crash happens anymore with the fix
r1#
r1# sharp install routes 2100:cafe:: nexthop 2001:db8::1 1000
r1#
Soumya Roy [Fri, 14 Mar 2025 21:44:39 +0000 (21:44 +0000)]
lib: Add support for stream buffer to expand
Issue:
Currently, during encode time, if required memory is
more than available space in stream buffer, stream buffer
can't be expanded. This fix introduces new apis to support
stream buffer expansion.
Testing:
Tested with zebra nexthop encoding with 512 nexthops, which triggers
this new code changes, it works fine. Without fix, for same trigger
it asserts.
Tuetuopay [Mon, 17 Mar 2025 14:08:15 +0000 (15:08 +0100)]
bgpd: fix evpn attributes being dropped on input
All assignments of the EVPN attributes (ESI and Gateway IP) are gated
behind the peer being set up for inbound soft-reconfiguration.
There are no actual reasons for this limitation, so let's perform the
EVPN attribute assignment no matter what when soft reconfiguration is
not enabled.
Fixes: 6e076ba5231 ("bgpd: Fix for ain->attr corruption during path update") Signed-off-by: Tuetuopay <tuetuopay@me.com>
Donald Sharp [Wed, 19 Mar 2025 20:50:11 +0000 (16:50 -0400)]
bgpd: Fix leaked memory when showing some bgp routes
The two memory leaks:
==387155== 744 (48 direct, 696 indirect) bytes in 1 blocks are definitely lost in loss record 222 of 262
==387155== at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==387155== by 0x4C1B982: json_object_new_object (in /usr/lib/x86_64-linux-gnu/libjson-c.so.5.1.0)
==387155== by 0x2E4146: peer_adj_routes (bgp_route.c:15245)
==387155== by 0x2E4F1A: show_ip_bgp_instance_neighbor_advertised_route_magic (bgp_route.c:15549)
==387155== by 0x2B982B: show_ip_bgp_instance_neighbor_advertised_route (bgp_route_clippy.c:722)
==387155== by 0x4915E6F: cmd_execute_command_real (command.c:1003)
==387155== by 0x4915FE8: cmd_execute_command (command.c:1062)
==387155== by 0x4916598: cmd_execute (command.c:1228)
==387155== by 0x49EB858: vty_command (vty.c:626)
==387155== by 0x49ED77C: vty_execute (vty.c:1389)
==387155== by 0x49EFFA7: vtysh_read (vty.c:2408)
==387155== by 0x49E4156: event_call (event.c:2019)
==387155== by 0x4958ABD: frr_run (libfrr.c:1247)
==387155== by 0x206A68: main (bgp_main.c:557)
==387155==
==387155== 2,976 (192 direct, 2,784 indirect) bytes in 4 blocks are definitely lost in loss record 240 of 262
==387155== at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==387155== by 0x4C1B982: json_object_new_object (in /usr/lib/x86_64-linux-gnu/libjson-c.so.5.1.0)
==387155== by 0x2E45CA: peer_adj_routes (bgp_route.c:15325)
==387155== by 0x2E4F1A: show_ip_bgp_instance_neighbor_advertised_route_magic (bgp_route.c:15549)
==387155== by 0x2B982B: show_ip_bgp_instance_neighbor_advertised_route (bgp_route_clippy.c:722)
==387155== by 0x4915E6F: cmd_execute_command_real (command.c:1003)
==387155== by 0x4915FE8: cmd_execute_command (command.c:1062)
==387155== by 0x4916598: cmd_execute (command.c:1228)
==387155== by 0x49EB858: vty_command (vty.c:626)
==387155== by 0x49ED77C: vty_execute (vty.c:1389)
==387155== by 0x49EFFA7: vtysh_read (vty.c:2408)
==387155== by 0x49E4156: event_call (event.c:2019)
==387155== by 0x4958ABD: frr_run (libfrr.c:1247)
==387155== by 0x206A68: main (bgp_main.c:557)
For the 1st one, if the operator issues a advertised-routes command, the
json_ar variable was never being freed.
For the 2nd one, if the operator issued a command where the
output_count_per_rd is 0, we need to free the json_routes value.
Donald Sharp [Wed, 19 Mar 2025 19:20:31 +0000 (15:20 -0400)]
tests: Ensure that the daemon has connected to zebra
On daemon startup, ensure that the daemon is there and
connected to zebra. There are some exceptions,
pathd is srte. pim6d and pimd are the same at the
moment and finally smnptrapd.
This should help the startup of using a unified
config in the topotests.
Donald Sharp [Wed, 19 Mar 2025 16:22:04 +0000 (12:22 -0400)]
zebra: Allow fpm_listener to reject all routes
Now usage of `-r -f` with fpm_listener now causes all
routes to be rejected.
r1# sharp install routes 10.0.0.0 nexthop 192.168.44.5 5
r1# show ip route
Codes: K - kernel route, C - connected, L - local, S - static,
R - RIP, O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
F - PBR, f - OpenFabric, t - Table-Direct,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
IPv4 unicast VRF default:
D>o 10.0.0.0/32 [150/0] via 192.168.44.5, r1-eth0, weight 1, 00:00:02
D>o 10.0.0.1/32 [150/0] via 192.168.44.5, r1-eth0, weight 1, 00:00:02
D>o 10.0.0.2/32 [150/0] via 192.168.44.5, r1-eth0, weight 1, 00:00:02
D>o 10.0.0.3/32 [150/0] via 192.168.44.5, r1-eth0, weight 1, 00:00:02
D>o 10.0.0.4/32 [150/0] via 192.168.44.5, r1-eth0, weight 1, 00:00:02
C>* 192.168.44.0/24 is directly connected, r1-eth0, weight 1, 00:00:37
L>* 192.168.44.1/32 is directly connected, r1-eth0, weight 1, 00:00:37
r1#
Nathan Bahr [Wed, 19 Mar 2025 16:07:37 +0000 (16:07 +0000)]
lib: Create VRF if needed
When creating a control plane protocol through NB, create the vrf
if needed instead of only looking up and asserting if it doesn't
exist yet.
Fixes 18429.
Martin Winter [Wed, 19 Mar 2025 12:40:53 +0000 (13:40 +0100)]
redhat: Make sure zeromq is always disabled
Fix issue where zeromq is getting enabled if build system has the libs
installed. For RPMs, we want it always based on intended config options.
(and currently the zeromq is not part of the packages)
Signed-off-by: Martin Winter <mwinter@opensourcerouting.org>
Martin Winter [Wed, 19 Mar 2025 06:21:37 +0000 (07:21 +0100)]
redhat: Make docs and rpki optional for RPM package build
Adding options to disable docs and rpki during the build. By
default they are always built. RPKI sub-package will not be built
(and not available) if built without the RPKI support.
Signed-off-by: Martin Winter <mwinter@opensourcerouting.org>
Rajasekar Raja [Tue, 11 Mar 2025 19:15:32 +0000 (12:15 -0700)]
zebra: Fix reinstalling nexthops in NHGs upon interface flaps
Trigger:
Imagine a route utilizing an NHG with six nexthops (Intf swp1-swp6).
If interfaces swp1-swp4 flaps, the NHG remains the same but now only
references two nexthops (swp5-6) instead of all six. This behavior
occurs due to how NHGs with recursive nexthops are managed within Zebra.
In the scenario below, NHG 370 has all six nexthops installed in the
kernel. However, Zebra maintains a list of recursive NHGs that NHG 370
references i.e., Depends: (371), (372), (373) which are not directly
installed in the kernel.
- When an interface comes up, its nexthop and corresponding dependents
are installed.
- These dependents (counterparts to 371-373) are non-recursive and
are installed as well.
- However, when attempting to install the recursive ones in
zebra_nhg_install_kernel(), they resolve to the already installed
counterparts, resulting in a NO-OP.
Fixing this by iterating all dependents of the recursively resolved
NHGs and reinstalling them.
Trigger: Flap swp1 to swp4
Before Fix:
root@leaf-11:mgmt:/var/home/cumulus# ip route show | grep 6.0.0.5
6.0.0.5 nhid 370 proto bgp metric 20
ip -d next show
id 337 via 2000:1:0:1:0:f:0:9 dev swp6 scope link proto zebra
id 339 via 2000:1:0:1:0:e:0:9 dev swp5 scope link proto zebra
id 341 via 2000:1:0:1:0:8:0:8 dev swp4 scope link proto zebra
id 343 via 2000:1:0:1:0:7:0:8 dev swp3 scope link proto zebra
id 346 via 2000:1:0:1:0:1:0:7 dev swp2 scope link proto zebra
id 348 via 2000:1:0:1::7 dev swp1 scope link proto zebra
id 370 group 346/348/341/343/337/339 scope global proto zebra
After Trigger:
root@leaf-11:mgmt:/var/home/cumulus# ip route show | grep 6.0.0.5
6.0.0.5 nhid 370 proto bgp metric 20
root@leaf-11:mgmt:/var/home/cumulus# ip -d next show
id 337 via 2000:1:0:1:0:f:0:9 dev swp6 scope link proto zebra
id 339 via 2000:1:0:1:0:e:0:9 dev swp5 scope link proto zebra
id 370 group 337/339 scope global proto zebra
After Fix:
root@leaf-11:mgmt:/var/home/cumulus# ip route show | grep 6.0.0.5
6.0.0.5 nhid 432 proto bgp metric 20
ip -d next show
id 432 group 395/397/400/402/405/407 scope global proto zebra
After Trigger
root@leaf-11:mgmt:/var/home/cumulus# ip route show | grep 6.0.0.5
6.0.0.5 nhid 432 proto bgp metric 20
root@leaf-11:mgmt:/var/home/cumulus# ip -d next show
id 432 group 395/397/400/402/405/407 scope global proto zebra
Ticket :#
Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com> Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Loïc Sang [Tue, 18 Mar 2025 16:39:03 +0000 (17:39 +0100)]
bgpd: fix "delete in progress" flag on default instance
Since 4d0e7a4 ("bgpd: VRF-Lite fix default BGP delete"), upon deletion
of the default instance, it is marked as hidden and the "deletion
in progress" flag is set. When the instance is restored, some routes
are not installed due to the presence of this flag.
Tuetuopay [Fri, 14 Mar 2025 19:21:53 +0000 (20:21 +0100)]
tests: add route-map evpn set gateway-ip topotest
This test does not actually look at the route since the gateway-ip is
not exposed in vtysh output. However, this ensures such a route-map does
not crash bgpd.
Shbinging [Tue, 18 Mar 2025 02:35:16 +0000 (10:35 +0800)]
babled: set wired/wireless internal only when wired/wireless status changes
As stated in doc, interface's attributes such noninterfering/interfering are reset when the wired/wireless status of an interface is changed. If wired/wireless status is not changed, such as wired->wired, we should not reset internal attributes.
Donatas Abraitis [Thu, 27 Feb 2025 14:08:21 +0000 (16:08 +0200)]
bgpd: Do not keep stale paths in Adj-RIB-Out if not addpath aware
```
munet> r1 shi vtysh -c 'show ip bgp update advertised-routes'
update group 1, subgroup 1
BGP table version is 5, local router ID is 192.168.137.1
Status codes: s suppressed, d damped, h history, u unsorted, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0/24 192.168.137.201 10 0 65200 65444 i
*> 10.0.0.0/24 192.168.137.100 10 0 65100 65444 65444 i
*> 10.65.10.0/24 192.168.137.100 0 10 0 65100 i
*> 10.200.2.0/24 192.168.137.202 0 10 0 65200 i
```
Announce one more 10.0.0.0/24 via 65200 and we have TWO paths 10.0.0.0/24 in adj-rib-out:
```
munet> r1 shi vtysh -c 'show ip bgp update advertised-routes'
update group 1, subgroup 1
BGP table version is 6, local router ID is 192.168.137.1
Status codes: s suppressed, d damped, h history, u unsorted, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0/24 192.168.137.201 10 0 65200 65444 i
*> 10.0.0.0/24 192.168.137.100 10 0 65100 65444 65444 i
*> 10.0.0.0/24 192.168.137.201 10 0 65200 65444 i
*> 10.65.10.0/24 192.168.137.100 0 10 0 65100 i
*> 10.200.2.0/24 192.168.137.202 0 10 0 65200 i
```
Stop announcing 10.0.0.0/24 via 65200 and we still have TWO paths for 10.0.0.0/24...
```
munet> r1 shi vtysh -c 'show ip bgp update advertised-routes'
update group 1, subgroup 1
BGP table version is 7, local router ID is 192.168.137.1
Status codes: s suppressed, d damped, h history, u unsorted, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0/24 192.168.137.201 10 0 65200 65444 i
*> 10.0.0.0/24 192.168.137.100 10 0 65100 65444 65444 i
*> 10.0.0.0/24 192.168.137.201 10 0 65200 65444 i
*> 10.65.10.0/24 192.168.137.100 0 10 0 65100 i
*> 10.200.2.0/24 192.168.137.202 0 10 0 65200 i
```
Why do we need to keep old paths in adj-rib-out if we don't have e.g. AddPaths enabled?
Shouldn't it be like here? (only one 10.0.0.0/24 in adj-rib-out for this update-group instead of multiple (stale from previous announcements))
```
munet> r1 shi vtysh -c 'show ip bgp update advertised-routes'
update group 1, subgroup 1
BGP table version is 6, local router ID is 192.168.137.1
Status codes: s suppressed, d damped, h history, u unsorted, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0/24 192.168.137.201 10 0 65200 65444 i
*> 10.0.0.0/24 192.168.137.201 10 0 65200 65444 i
*> 10.65.10.0/24 192.168.137.100 0 10 0 65100 i
*> 10.200.2.0/24 192.168.137.202 0 10 0 65200 i
```
Tuetuopay [Fri, 14 Mar 2025 19:21:46 +0000 (20:21 +0100)]
bgpd: fix `set evpn gateway-ip ipv[46]` route-map
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:
Dmytro Shytyi [Mon, 10 Mar 2025 13:59:34 +0000 (14:59 +0100)]
bgpd: align peer_unconfigure with gracefull-restart
When configured Graceful-Restart, skipping unconfig notification,
similarly as it is done in 95098d9611e79d43b578400bb76dc7a76aa8cab9
("bgpd: Do not send Deconfig/Shutdown message when restarting")
bgpd: fix radv interface disabled when bgp instance removed
If a peer uses radv for an interface, and bgp instance is removed,
then the radv service is not disabled on the interface.
Fix this by doing the same at BGP unconfiguration. Like it has been
done when a peer is unconfigured, call the radv unregistration before
deleting the peer.
Fixes: b3a3290e2303 ("bgpd: turn off RAs when numbered peers are deleted") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com> Signed-off-by: Dmytro Shytyi <dmytro.shytyi@6wind.com>
echken [Mon, 17 Mar 2025 03:43:19 +0000 (03:43 +0000)]
fix(vrrp): display vrrp version by default
Make the VRRP version information always visible in the running
configuration output, regardless of whether it's the default value
(version 3) or not.
When using frr-reload.py to apply configuration changes, VRRP instances
were being unnecessarily reinitialized even when no actual configuration
changes were made. This occurred because:
The cli_show_vrrp function in vrrpd/vrrp_vty.c does not display the VRRP
version in the show running-config output when it's the default value
(version 3).
Configuration files often explicitly specify vrrp X version 3 even
though it's the default.
When frr-reload.py compares the explicit configuration with the running
configuration, it detects a difference and generates commands to remove
and recreate the VRRP instance.
This patch modifies the cli_show_vrrp function to unconditionally
display the VRRP version, regardless of whether it's the default value
or the show_defaults parameter is set. By making the version information
explicit in all cases, we ensure consistent configuration comparison in
frr-reload.py, preventing unnecessary VRRP reinitialization and
associated network disruptions.
Christian Hopps [Sat, 15 Mar 2025 04:09:29 +0000 (04:09 +0000)]
tests: deal with configure overridden timestamp prec in unit test
Previously if you configured a different timestamp precision then
`make check` would fail as the non-default config is generated and
fails test_cli config file comparison.
Donald Sharp [Fri, 14 Mar 2025 18:50:59 +0000 (14:50 -0400)]
bgpd: Remove unnecessary stream_new/stream_copies in bgp_open_make
The call into bgp_open_capability can return that it wrote more
than BGP_OPEN_NON_EXT_OPT_LEN bytes, in that case the open
part needs to be written again with ext_opt_params set to
true to allow extended parameters to be written thus keeping
the len < 255 bytes. The code to do this was first creating
a new stream and then copying into it the stream, trying
to call bgp_open_capability() and if it succeeded recopying
the tmp stream back onto the original.
Let's change this around such that we save the current spot
in the stream of where we are writing and if the change does
not work reset the pointer and try again with the correct
parameter. This removes the stream and multiple copies and
eventual free of the temporary stream.
Acee Lindem [Fri, 14 Mar 2025 16:02:28 +0000 (16:02 +0000)]
ospf6d: Disable and delete OSPFv3 areas that no longer have interfaces or 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.
Manpreet Kaur [Thu, 13 Mar 2025 11:14:24 +0000 (04:14 -0700)]
bgpd: Fixed crash upon bgp network import-check command
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.
projects / mirror / frr.git / log