Donatas Abraitis [Tue, 25 Mar 2025 15:35:41 +0000 (17:35 +0200)]
tests: Check if routes are marked as stale and retained with N-bit for GR
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>
Donald Sharp [Tue, 25 Mar 2025 14:43:14 +0000 (10:43 -0400)]
bgpd: Delay processing MetaQ in some events
If the number of peers that are being handled on
the peer connection fifo is greater than 10, that
means we have some network event going on. Let's
allow the packet processing to continue instead
of running the metaQ. This has advantages because
everything else in BGP is only run after the metaQ
is run. This includes best path processing,
installation of the route into zebra as well as
telling our peers about this change. Why does
this matter? It matters because if we are receiving
the same route multiple times we limit best path processing
to much fewer times and consequently we also limit
the number of times we send the route update out and
we install the route much fewer times as well.
Prior to this patch, with 512 peers and 5k routes.
CPU time for bgpd was 3:10, zebra was 3:28. After
the patch CPU time for bgpd was 0:55 and zebra was
0:25.
Here are the prior `show event cpu`:
Event statistics for bgpd:
Showing statistics for pthread default
--------------------------------------
CPU (user+system): Real (wall-clock):
Active Runtime(ms) Invoked Avg uSec Max uSecs Avg uSec Max uSecs CPU_Warn Wall_Warn Starv_Warn Type Event
0 20.749 33144 0 395 1 396 0 0 0 T (bgp_generate_updgrp_packets)
0 9936.199 1818 5465 43588 5466 43589 0 0 0 E bgp_handle_route_announcements_to_zebra
0 0.220 84 2 20 3 20 0 0 0 T update_subgroup_merge_check_thread_cb
0 0.058 2 29 43 29 43 0 0 0 E zclient_connect
0 17297.733 466 37119 67428 37124 67429 0 0 0 W zclient_flush_data
1 0.134 7 19 40 20 42 0 0 0 R vtysh_accept
0 151.396 1067 141 1181 142 1189 0 0 0 R vtysh_read
0 0.297 1030 0 14 0 14 0 0 0 T (bgp_routeadv_timer)
0 0.001 1 1 1 2 2 0 0 0 T bgp_sync_label_manager
2 9.374 544 17 261 17 262 0 0 0 R bgp_accept
0 0.001 1 1 1 2 2 0 0 0 T bgp_startup_timer_expire
0 0.012 1 12 12 13 13 0 0 0 E frr_config_read_in
0 0.308 1 308 308 309 309 0 0 0 T subgroup_coalesce_timer
0 4.027 105 38 77 39 78 0 0 0 T (bgp_start_timer)
0 112206.442 1818 61719 84726 61727 84736 0 0 0 TE work_queue_run
0 0.345 1 345 345 346 346 0 0 0 T bgp_config_finish
0 0.710 620 1 6 1 9 0 0 0 W bgp_connect_check
2 39.420 8283 4 110 5 111 0 0 0 R zclient_read
0 0.052 1 52 52 578 578 0 0 0 T bgp_start_label_manager
0 0.452 87 5 90 5 90 0 0 0 T bgp_announce_route_timer_expired
0 185.837 3088 60 537 92 21705 0 0 0 E bgp_event
0 48719.671 4346 11210 78292 11215 78317 0 0 0 E bgp_process_packet
Showing statistics for pthread BGP I/O thread
---------------------------------------------
CPU (user+system): Real (wall-clock):
Active Runtime(ms) Invoked Avg uSec Max uSecs Avg uSec Max uSecs CPU_Warn Wall_Warn Starv_Warn Type Event
0 321.915 28597 11 86 11 265 0 0 0 W bgp_process_writes
515 115.586 26954 4 121 4 128 0 0 0 R bgp_process_reads
Event statistics for zebra:
Showing statistics for pthread default
--------------------------------------
CPU (user+system): Real (wall-clock):
Active Runtime(ms) Invoked Avg uSec Max uSecs Avg uSec Max uSecs CPU_Warn Wall_Warn Starv_Warn Type Event
0 0.109 2 54 62 55 63 0 0 0 T timer_walk_start
1 0.550 11 50 100 50 100 0 0 0 R vtysh_accept
0 112848.163 4441 25410 405489 25413 410127 0 0 0 E zserv_process_messages
0 0.007 1 7 7 7 7 0 0 0 E frr_config_read_in
0 0.005 1 5 5 5 5 0 0 0 T rib_sweep_route
1 573.589 4789 119 1567 120 1568 0 0 0 T wheel_timer_thread
347 30.848 97 318 1367 318 1366 0 0 0 T zebra_nhg_timer
0 0.005 1 5 5 6 6 0 0 0 T zebra_evpn_mh_startup_delay_exp_cb
0 5.404 521 10 38 10 70 0 0 0 T timer_walk_continue
1 1.669 9 185 219 186 219 0 0 0 R zserv_accept
1 0.174 18 9 53 10 53 0 0 0 R msg_conn_read
0 3.028 520 5 47 6 47 0 0 0 T if_zebra_speed_update
0 0.324 274 1 5 1 6 0 0 0 W msg_conn_write
1 24.661 2124 11 359 12 359 0 0 0 R kernel_read
0 73683.333 2964 24859 143223 24861 143239 0 0 0 TE work_queue_run
1 46.649 6789 6 424 7 424 0 0 0 R rtadv_read
0 52.661 85 619 2087 620 2088 0 0 0 R vtysh_read
0 42.660 18 2370 21694 2373 21695 0 0 0 E msg_conn_proc_msgs
0 0.034 1 34 34 35 35 0 0 0 E msg_client_connect_timer
0 2786.938 2300 1211 29456 1219 29555 0 0 0 E rib_process_dplane_results
Showing statistics for pthread Zebra dplane thread
--------------------------------------------------
CPU (user+system): Real (wall-clock):
Active Runtime(ms) Invoked Avg uSec Max uSecs Avg uSec Max uSecs CPU_Warn Wall_Warn Starv_Warn Type Event
0 4875.670 200371 24 770 24 776 0 0 0 E dplane_thread_loop
0 0.059 1 59 59 76 76 0 0 0 E dplane_incoming_request
1 9.640 722 13 4510 15 5343 0 0 0 R dplane_incoming_read
Here are the post `show event cpu` results:
Event statistics for bgpd:
Showing statistics for pthread default
--------------------------------------
CPU (user+system): Real (wall-clock):
Active Runtime(ms) Invoked Avg uSec Max uSecs Avg uSec Max uSecs CPU_Warn Wall_Warn Starv_Warn Type Event
0 21297.497 3565 5974 57912 5981 57913 0 0 0 E bgp_process_packet
0 149.742 1068 140 1109 140 1110 0 0 0 R vtysh_read
0 0.013 1 13 13 14 14 0 0 0 E frr_config_read_in
0 0.459 86 5 104 5 105 0 0 0 T bgp_announce_route_timer_expired
0 0.139 81 1 20 2 21 0 0 0 T update_subgroup_merge_check_thread_cb
0 405.889 291687 1 179 1 450 0 0 0 T (bgp_generate_updgrp_packets)
0 0.682 618 1 6 1 9 0 0 0 W bgp_connect_check
0 3.888 103 37 81 38 82 0 0 0 T (bgp_start_timer)
0 0.074 1 74 74 458 458 0 0 0 T bgp_start_label_manager
0 0.000 1 0 0 1 1 0 0 0 T bgp_sync_label_manager
0 0.121 3 40 54 100 141 0 0 0 E bgp_process_conn_error
0 0.060 2 30 49 30 50 0 0 0 E zclient_connect
0 0.354 1 354 354 355 355 0 0 0 T bgp_config_finish
0 0.283 1 283 283 284 284 0 0 0 T subgroup_coalesce_timer
0 29365.962 1805 16269 99445 16273 99454 0 0 0 TE work_queue_run
0 185.532 3097 59 497 94 26107 0 0 0 E bgp_event
1 0.290 8 36 151 37 158 0 0 0 R vtysh_accept
2 9.462 548 17 320 17 322 0 0 0 R bgp_accept
2 40.219 8283 4 128 5 128 0 0 0 R zclient_read
0 0.322 1031 0 4 0 5 0 0 0 T (bgp_routeadv_timer)
0 356.812 637 560 3007 560 3007 0 0 0 E bgp_handle_route_announcements_to_zebra
Showing statistics for pthread BGP I/O thread
---------------------------------------------
CPU (user+system): Real (wall-clock):
Active Runtime(ms) Invoked Avg uSec Max uSecs Avg uSec Max uSecs CPU_Warn Wall_Warn Starv_Warn Type Event
515 62.965 14335 4 103 5 181 0 0 0 R bgp_process_reads
0 1986.041 219813 9 213 9 315 0 0 0 W bgp_process_writes
Event statistics for zebra:
Showing statistics for pthread default
--------------------------------------
CPU (user+system): Real (wall-clock):
Active Runtime(ms) Invoked Avg uSec Max uSecs Avg uSec Max uSecs CPU_Warn Wall_Warn Starv_Warn Type Event
0 0.006 1 6 6 7 7 0 0 0 E frr_config_read_in
0 3673.365 2044 1797 259281 1800 261342 0 0 0 E zserv_process_messages
1 651.846 8041 81 1090 82 1233 0 0 0 T wheel_timer_thread
0 38.184 18 2121 21345 2122 21346 0 0 0 E msg_conn_proc_msgs
1 0.651 12 54 112 55 112 0 0 0 R vtysh_accept
0 0.102 2 51 55 51 56 0 0 0 T timer_walk_start
0 202.721 1577 128 29172 141 29226 0 0 0 E rib_process_dplane_results
1 41.650 6645 6 140 6 140 0 0 0 R rtadv_read
1 22.518 1969 11 106 12 154 0 0 0 R kernel_read
0 4.265 48 88 1465 89 1466 0 0 0 R vtysh_read
0 6099.851 650 9384 28313 9390 28314 0 0 0 TE work_queue_run
0 5.104 521 9 30 10 31 0 0 0 T timer_walk_continue
0 3.078 520 5 53 6 55 0 0 0 T if_zebra_speed_update
0 0.005 1 5 5 5 5 0 0 0 T rib_sweep_route
0 0.034 1 34 34 35 35 0 0 0 E msg_client_connect_timer
1 1.641 9 182 214 183 215 0 0 0 R zserv_accept
0 0.358 274 1 6 2 6 0 0 0 W msg_conn_write
1 0.159 18 8 54 9 54 0 0 0 R msg_conn_read
Showing statistics for pthread Zebra dplane thread
--------------------------------------------------
CPU (user+system): Real (wall-clock):
Active Runtime(ms) Invoked Avg uSec Max uSecs Avg uSec Max uSecs CPU_Warn Wall_Warn Starv_Warn Type Event
0 301.404 7280 41 1878 41 1878 0 0 0 E dplane_thread_loop
0 0.048 1 48 48 49 49 0 0 0 E dplane_incoming_request
1 9.558 727 13 4659 14 5420 0 0 0 R dplane_incoming_read
Donald Sharp [Mon, 24 Mar 2025 18:11:35 +0000 (14:11 -0400)]
zebra: Limit reading packets when MetaQ is full
Currently Zebra is just reading packets off the zapi
wire and stacking them up for processing in zebra
in the future. When there is significant churn
in the network the size of zebra can grow without
bounds due to the MetaQ sizing constraints. This
ends up showing by the number of nexthops in the
system. Reducing the number of packets serviced
to limit the metaQ size to the packets to process
allieviates this problem.
Donald Sharp [Fri, 21 Mar 2025 11:48:50 +0000 (07:48 -0400)]
bgpd: Modify bgp to handle packet events in a FIFO
Current behavor of BGP is to have a event per connection. Given
that on startup of BGP with a high number of neighbors you end
up with 2 * # of peers events that are being processed. Additionally
once BGP has selected the connection this still only comes down
to 512 events. This number of events is swamping the event system
and in addition delaying any other work from being done in BGP at
all because the the 512 events are always going to take precedence
over everything else. The other main events are the handling
of the metaQ(1 event), update group events( 1 per update group )
and the zebra batching event. These are being swamped.
Modify the BGP code to have a FIFO of connections. As new data
comes in to read, place the connection on the end of the FIFO.
Have the bgp_process_packet handle up to 100 packets spread
across the individual peers where each peer/connection is limited
to the original quanta. During testing I noticed that withdrawal
events at very very large scale are taking up to 40 seconds to process
so I added a check for yielding to further limit the number of packets
being processed.
This change also allow for BGP to be interactive again on scale
setups on initial convergence. Prior to this change any vtysh
command entered would be delayed by 10's of seconds in my setup
while BGP was doing other work.
Donald Sharp [Fri, 21 Mar 2025 14:47:14 +0000 (10:47 -0400)]
tests: Expand hold timer to 60 seconds for high_ecmp
The hold timer is 5/20. At load with a very very
large number of routes, the tests are experiencing
some issues with this. Let's just give ourselves
some headroom associated with the receiving
of packets
Shbinging [Fri, 21 Mar 2025 02:57:28 +0000 (02:57 +0000)]
babeld: fix hello packets not sent with configured hello timer
Same issue occurring as previously addressed in https://github.com/FRRouting/frr/pull/9092. The root cause is: "Sending a Hello message before restarting the hello timer to avoid session flaps in case of larger hello interval configurations."
Mark Stapp [Mon, 24 Mar 2025 20:53:32 +0000 (16:53 -0400)]
bgpd: fix handling of configured RTs for l2vni, l3vni
Test for existing explicit config as part of validation of
route-target configuration: allow explicit config of generic/
default AS+VNI, for example, instead of rejecting it.
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.
zmw12306 [Mon, 24 Mar 2025 19:32:18 +0000 (15:32 -0400)]
babeld: Hop Count must not be 0.
According to RFC 8966:
Hop Count The maximum number of times that this TLV may be forwarded, plus 1. This MUST NOT be 0. Signed-off-by: zmw12306 <zmw12306@gmail.com>
Donald Sharp [Mon, 24 Mar 2025 12:07:02 +0000 (08:07 -0400)]
eigrpd: Cleanup memory issues on shutdown
a) EIGRP was having issues with the prefix created as part
of the topology destination. Make this just a part of the
topology data structure instead of allocating it.
b) EIGRP was not freeing up any memory associated with
the network table. Free it.
c) EIGRP was confusing zebra shutdown as part of the deletion
of the last eigrp data structure. This was inappropriate it
should be part of the `I'm just shutting down`.
d) The QOBJ was not being properly freed, free it.
Donald Sharp [Mon, 24 Mar 2025 01:16:56 +0000 (21:16 -0400)]
eigrpd: Convert the eiflist to a typesafe hash
The eigrp->eiflist is a linked list and should just
be a hash instead. The full conversion to a hash
like functionality is goingto wait until the connected
eigrp data structure is created.
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>
Christian Hopps [Mon, 24 Mar 2025 05:07:28 +0000 (05:07 +0000)]
tests: add another directory to search path for pylint
Some IDEs (e.g., emacs+lsp) run pylint from the root directory and so
we need to add `tests/topotests` so that `lib` and `munet` are found
by pylint when used in imports
Donald Sharp [Sun, 23 Mar 2025 21:48:02 +0000 (17:48 -0400)]
tests: high_ecmp creates 2 update groups
The high_ecmp test was creating 2 update groups, where
513 of the neighbors are in 1 and the remaining is in
another. They should just all be in 1 update group.
Modify the test creation such that interfaces r1-eth514
and r2-eth514 have v4 and v6 addresses.
Signed-off-by: Donald Sharp <donaldsharp72@gmail.com>
staticd: Fix crash that occurs when modifying an SRv6 SID
When the user modifies an SRv6 SID and then removes all SIDs, staticd
crashes:
```
2025/03/23 08:37:22.691860 STATIC: lib/memory.c:74: mt_count_free(): assertion (mt->n_alloc) failed
STATIC: Received signal 6 at 1742715442 (si_addr 0x8200007cf0); aborting...
STATIC: zlog_signal+0x390 fcc704a844b8ffffd7450390 /usr/lib/frr/libfrr.so.0 (mapped at 0xfcc704800000)
STATIC: core_handler+0x1f8 fcc704b79990ffffd7450590 /usr/lib/frr/libfrr.so.0 (mapped at 0xfcc704800000)
STATIC: ---- signal ----
STATIC: ? fcc705c008f8ffffd74507a0 linux-vdso.so.1 (mapped at 0xfcc705c00000)
STATIC: pthread_key_delete+0x1a0 fcc70458f1f0ffffd7451a00 /lib/aarch64-linux-gnu/libc.so.6 (mapped at 0xfcc704510000)
STATIC: raise+0x1c fcc70454a67cffffd7451ad0 /lib/aarch64-linux-gnu/libc.so.6 (mapped at 0xfcc704510000)
STATIC: abort+0xe4 fcc704537130ffffd7451af0 /lib/aarch64-linux-gnu/libc.so.6 (mapped at 0xfcc704510000)
STATIC: _zlog_assert_failed+0x3c4 fcc704c407c8ffffd7451c40 /usr/lib/frr/libfrr.so.0 (mapped at 0xfcc704800000)
STATIC: mt_count_free+0x12c fcc704a93c74ffffd7451dc0 /usr/lib/frr/libfrr.so.0 (mapped at 0xfcc704800000)
STATIC: qfree+0x28 fcc704a93fa0ffffd7451e70 /usr/lib/frr/libfrr.so.0 (mapped at 0xfcc704800000)
STATIC: static_srv6_sid_free+0x1c adc1df8fa544ffffd7451e90 /usr/lib/frr/staticd (mapped at 0xadc1df8a0000)
STATIC: delete_static_srv6_sid+0x14 adc1df8faafcffffd7451eb0 /usr/lib/frr/staticd (mapped at 0xadc1df8a0000)
STATIC: list_delete_all_node+0x104 fcc704a60eecffffd7451ed0 /usr/lib/frr/libfrr.so.0 (mapped at 0xfcc704800000)
STATIC: list_delete+0x8c fcc704a61054ffffd7451f00 /usr/lib/frr/libfrr.so.0 (mapped at 0xfcc704800000)
STATIC: static_srv6_cleanup+0x20 adc1df8fabdcffffd7451f20 /usr/lib/frr/staticd (mapped at 0xadc1df8a0000)
STATIC: sigint+0x40 adc1df8be544ffffd7451f30 /usr/lib/frr/staticd (mapped at 0xadc1df8a0000)
STATIC: frr_sigevent_process+0x148 fcc704b79460ffffd7451f40 /usr/lib/frr/libfrr.so.0 (mapped at 0xfcc704800000)
STATIC: event_fetch+0x1c4 fcc704bc0834ffffd7451f60 /usr/lib/frr/libfrr.so.0 (mapped at 0xfcc704800000)
STATIC: frr_run+0x650 fcc704a5d230ffffd7452080 /usr/lib/frr/libfrr.so.0 (mapped at 0xfcc704800000)
STATIC: main+0x1d0 adc1df8be75cffffd7452270 /usr/lib/frr/staticd (mapped at 0xadc1df8a0000)
STATIC: __libc_init_first+0x7c fcc7045373fcffffd74522b0 /lib/aarch64-linux-gnu/libc.so.6 (mapped at 0xfcc704510000)
STATIC: __libc_start_main+0x98 fcc7045374ccffffd74523c0 /lib/aarch64-linux-gnu/libc.so.6 (mapped at 0xfcc704510000)
STATIC: _start+0x30 adc1df8be0f0ffffd7452420 /usr/lib/frr/staticd (mapped at 0xadc1df8a0000)
```
Tracking this down, the crash occurs because every time we modify a
SID, staticd executes some callbacks to modify the SID and finally it
calls `apply_finish`, which re-adds the SID to the list `srv6_sids`.
This leads to having the same SID multiple times in the `srv6_sids`
list. When we delete all SIDs, staticd attempts to deallocate the same
SID multiple times, which leads to the crash.
This commit fixes the issue by moving the code that adds the SID to the
list from the `apply_finish` callback to the `create` callback.
This ensures that the SID is inserted into the list only once, when it
is created. For all subsequent modifications, the SID is modified but
not added to the list.
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.
Donald Sharp [Wed, 12 Mar 2025 16:37:21 +0000 (12:37 -0400)]
bgpd: Tie in more clear events to clear code
The `clear bgp *` and the interface down events
cause a global clearing of data from the bgp rib.
Let's tie those into the clear peer code such
that we can take advantage of the reduced load
in these cases too.
Mark Stapp [Wed, 12 Mar 2025 13:55:53 +0000 (09:55 -0400)]
bgpd: Allow batch clear to do partial work and continue later
Modify the batch clear code to be able to stop after processing
some of the work and to pick back up again. This will allow
the very expensive nature of the batch clearing to be spread out
and allow bgp to continue to be responsive.
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.
projects / matthieu / frr.git / log