Donald Sharp [Mon, 28 Oct 2024 21:51:04 +0000 (17:51 -0400)]
bgpd: Remove call into event_master_free_unused
This call was originally put into place to help reduce
memory problems associated with bgp having a bajillion
events under load and then we would have a bunch of events
ready to be used on the unused list. In the meantime
code was put into place that limited the depth of the
unused list to 10 elements. This call has now become
unnecessary. Let's just remove it.
Donatas Abraitis [Thu, 31 Oct 2024 08:47:48 +0000 (10:47 +0200)]
zebra: Add missing new line for help string
```
-A, --asic-offload FRR is interacting with an asic underneath the linux kernel
--v6-with-v4-nexthops Underlying dataplane supports v6 routes with v4 nexthops -s, --nl-bufsize Set netlink receive buffer size
```
Fixes: 1f5611c06d1c243b42279748788f0627793ead9c ("zebra: Allow zebra cli to accept v6 routes with v4 nexthops") Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Donatas Abraitis [Wed, 30 Oct 2024 12:15:36 +0000 (14:15 +0200)]
doc: Create html_context before setting READTHEDOCS
Traceback (most recent call last):
File "/home/docs/checkouts/readthedocs.org/user_builds/frrouting/envs/latest/lib/python3.11/site-packages/sphinx/config.py", line 529, in eval_config_file
exec(code, namespace) # NoQA: S102
^^^^^^^^^^^^^^^^^^^^^
File "/home/docs/checkouts/readthedocs.org/user_builds/frrouting/checkouts/latest/doc/user/conf.py", line 77, in <module>
html_context["READTHEDOCS"] = True
^^^^^^^^^^^^
NameError: name 'html_context' is not defined
Nathan Bahr [Mon, 28 Oct 2024 18:55:49 +0000 (18:55 +0000)]
zebra: Add ability to import alternate tables into the MRIB
Expanded the cli command to include an mrib flag for importing to
the main table MRIB instead of the main table URIB.
Piped through specifying the safi through the import table functions
rather than hardcoding to SAFI_UNICAST.
Import still only import routes from the URIB subtable, only added the
ability to import into the main table MRIB.
Liam Brady [Tue, 29 Oct 2024 12:50:17 +0000 (08:50 -0400)]
tests: respect RLIMIT_CORE hard limit
In the case that the RLIMIT_CORE hard limit cannot
be raised on a system, do not fail due to an exception.
Instead, attempt to increase the soft limit to as large
a value as possible (e.g. to the set hard limit).
Donald Sharp [Sat, 26 Oct 2024 01:56:14 +0000 (21:56 -0400)]
zebra: When installing a mroute, allow it to flow
Currently the mroute code was not allowing the mroute
to be sent to the dataplane. This leaves us with a
situation where the routes being installed where never
being set as installed and additionally nht against
the mrib would not work if the route came into existence
after the nexthop tracking was asked for.
Turns out all the pieces where there to let this work.
Modify the code to pass it to the dplane and to send
it back up as having worked.
Donald Sharp [Fri, 25 Oct 2024 21:17:53 +0000 (17:17 -0400)]
bgpd: bestpath failure when you have a singlepath not in holddown
When you have multiple paths to a particular route and a single
path changes. In addition of the other paths are either in
hold down or not established or really just not selected you
could end up with a situation where the bestpath choosen
was a path that was in hold down.
Modify the code such that when there is nothing worse
in bestpath selection for the choosen path, but were
unable to do any sorting, just put the path on the top
of the list and declare it the winner. Else just
do the original and put it at the end.
Signed-off-by: Chirag Shah <chirag@nvidia.com> Signed-off-by: Donald Sharp <sharpd@nvidia.com>
pimd: allow resolving bsr via directly connected secondary address
This only matters to single hop nodes that are adjacent to the bsr. More common
with IPv6 where LL address is used in PIM as the primary address. If the BSR IP
happens to be an address on the same interface, the receiving pim router
rejects the BSR address because it expects the BSR IP to resolve via the LL address
even if we have a connected route for the same BSR IP subnet. Effectively, we want to
allow rpf to be resolved via secondary IPs with connected routes on the same interface,
and not limit them to primary addresses.
Louis Scalbert [Thu, 24 Oct 2024 15:18:55 +0000 (17:18 +0200)]
tests: fix bgp_bmp_vrf race condition
The bgp_bmp_vrf topotest is randomly failing with similar messages:
> 2024-10-24 16:59:03,037 ERROR: topo: test failed at "bgp_bmp.test_bgp_bmp/test_bmp_bgp_unicast": Checking the updated prefixes has failed ! Generated JSON diff error report:
>
> $->pre-policy->update: expected has key '172.31.0.15/32' which is not present in output
It is particularly unsuccessful when run with valgrind:
bgp_bmp_vrf is configuring a BMP policy on r1 and then some static BGP
prefixes on r2. If for some reasons, the BGP UPDATE arrives to r1 before
the BMP configuration is operational, the UPDATE is not sent to the BMP
server and the test fails.
Pre-configure the BMP policies at startup to avoid this race condition.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Louis Scalbert [Thu, 24 Oct 2024 13:35:35 +0000 (15:35 +0200)]
tests: fix bgp_bmp race condition
The bgp_bmp topotest is randomly failing with similar messages:
> 2024-10-24 16:59:03,037 ERROR: topo: test failed at "bgp_bmp.test_bgp_bmp/test_bmp_bgp_unicast": Checking the updated prefixes has failed ! Generated JSON diff error report:
>
> $->pre-policy->update: expected has key '172.31.0.15/32' which is not present in output
It is particularly unsuccessful when run with valgrind:
bgp_bmp is configuring a BMP policy on r1 and then some static BGP
prefixes on r2. If for some reasons, the BGP UPDATE arrives to r1 before
the BMP configuration is operational, the UPDATE is not sent to the BMP
server and the test fails.
Pre-configure the BMP policies at startup to avoid this race condition.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
We encounter an MPLS entry where the nexthop is the prefix itself:
> 18 BGP 172.16.0.1 -
Actually, when using the "network" command, a bnc context is used, but
it is filled by using the prefix itself instead of the nexthop for other
BGP updates. Consequently, when picking up the original nexthop for
label allocation, the function behaves incorrectly. Instead ensure that
the nexthop type of bnc->nexthop is not a nexthop_ifindex; otherwise
fallback to the per vrf label.
Donald Sharp [Thu, 24 Oct 2024 21:44:31 +0000 (17:44 -0400)]
bgpd: Fix wrong pthread event cancelling
0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=130719886083648) at ./nptl/pthread_kill.c:44
1 __pthread_kill_internal (signo=6, threadid=130719886083648) at ./nptl/pthread_kill.c:78
2 __GI___pthread_kill (threadid=130719886083648, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
3 0x000076e399e42476 in __GI_raise (sig=6) at ../sysdeps/posix/raise.c:26
4 0x000076e39a34f950 in core_handler (signo=6, siginfo=0x76e3985fca30, context=0x76e3985fc900) at lib/sigevent.c:258
5 <signal handler called>
6 __pthread_kill_implementation (no_tid=0, signo=6, threadid=130719886083648) at ./nptl/pthread_kill.c:44
7 __pthread_kill_internal (signo=6, threadid=130719886083648) at ./nptl/pthread_kill.c:78
8 __GI___pthread_kill (threadid=130719886083648, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
9 0x000076e399e42476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
10 0x000076e399e287f3 in __GI_abort () at ./stdlib/abort.c:79
11 0x000076e39a39874b in _zlog_assert_failed (xref=0x76e39a46cca0 <_xref.27>, extra=0x0) at lib/zlog.c:789
12 0x000076e39a369dde in cancel_event_helper (m=0x5eda32df5e40, arg=0x5eda33afeed0, flags=1) at lib/event.c:1428
13 0x000076e39a369ef6 in event_cancel_event_ready (m=0x5eda32df5e40, arg=0x5eda33afeed0) at lib/event.c:1470
14 0x00005eda0a94a5b3 in bgp_stop (connection=0x5eda33afeed0) at bgpd/bgp_fsm.c:1355
15 0x00005eda0a94b4ae in bgp_stop_with_notify (connection=0x5eda33afeed0, code=8 '\b', sub_code=0 '\000') at bgpd/bgp_fsm.c:1610
16 0x00005eda0a979498 in bgp_packet_add (connection=0x5eda33afeed0, peer=0x5eda33b11800, s=0x76e3880daf90) at bgpd/bgp_packet.c:152
17 0x00005eda0a97a80f in bgp_keepalive_send (peer=0x5eda33b11800) at bgpd/bgp_packet.c:639
18 0x00005eda0a9511fd in peer_process (hb=0x5eda33c9ab80, arg=0x76e3985ffaf0) at bgpd/bgp_keepalives.c:111
19 0x000076e39a2cd8e6 in hash_iterate (hash=0x76e388000be0, func=0x5eda0a95105e <peer_process>, arg=0x76e3985ffaf0) at lib/hash.c:252
20 0x00005eda0a951679 in bgp_keepalives_start (arg=0x5eda3306af80) at bgpd/bgp_keepalives.c:214
21 0x000076e39a2c9932 in frr_pthread_inner (arg=0x5eda3306af80) at lib/frr_pthread.c:180
22 0x000076e399e94ac3 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
23 0x000076e399f26850 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
(gdb) f 12
12 0x000076e39a369dde in cancel_event_helper (m=0x5eda32df5e40, arg=0x5eda33afeed0, flags=1) at lib/event.c:1428
1428 assert(m->owner == pthread_self());
In this decode the attempt to cancel the connection's events from
the wrong thread is causing the crash. Modify the code to create an
event on the bm->master to cancel the events for the connection.
Donald Sharp [Thu, 24 Oct 2024 18:17:51 +0000 (14:17 -0400)]
bgpd: Fix deadlock in bgp_keepalive and master pthreads
(gdb) bt
0 futex_wait (private=0, expected=2, futex_word=0x5c438e9a98d8) at ../sysdeps/nptl/futex-internal.h:146
1 __GI___lll_lock_wait (futex=futex@entry=0x5c438e9a98d8, private=0) at ./nptl/lowlevellock.c:49
2 0x00007af16d698002 in lll_mutex_lock_optimized (mutex=0x5c438e9a98d8) at ./nptl/pthread_mutex_lock.c:48
3 ___pthread_mutex_lock (mutex=0x5c438e9a98d8) at ./nptl/pthread_mutex_lock.c:93
4 0x00005c4369c17e70 in _frr_mtx_lock (mutex=0x5c438e9a98d8, func=0x5c4369dc2750 <__func__.265> "bgp_notify_send_internal") at ./lib/frr_pthread.h:258
5 0x00005c4369c1a07a in bgp_notify_send_internal (connection=0x5c438e9a98c0, code=8 '\b', sub_code=0 '\000', data=0x0, datalen=0, use_curr=true) at bgpd/bgp_packet.c:928
6 0x00005c4369c1a707 in bgp_notify_send (connection=0x5c438e9a98c0, code=8 '\b', sub_code=0 '\000') at bgpd/bgp_packet.c:1069
7 0x00005c4369bea422 in bgp_stop_with_notify (connection=0x5c438e9a98c0, code=8 '\b', sub_code=0 '\000') at bgpd/bgp_fsm.c:1597
8 0x00005c4369c18480 in bgp_packet_add (connection=0x5c438e9a98c0, peer=0x5c438e9b6010, s=0x7af15c06bf70) at bgpd/bgp_packet.c:151
9 0x00005c4369c19816 in bgp_keepalive_send (peer=0x5c438e9b6010) at bgpd/bgp_packet.c:639
10 0x00005c4369bf01fd in peer_process (hb=0x5c438ed05520, arg=0x7af16bdffaf0) at bgpd/bgp_keepalives.c:111
11 0x00007af16dacd8e6 in hash_iterate (hash=0x7af15c000be0, func=0x5c4369bf005e <peer_process>, arg=0x7af16bdffaf0) at lib/hash.c:252
12 0x00005c4369bf0679 in bgp_keepalives_start (arg=0x5c438e0db110) at bgpd/bgp_keepalives.c:214
13 0x00007af16dac9932 in frr_pthread_inner (arg=0x5c438e0db110) at lib/frr_pthread.c:180
14 0x00007af16d694ac3 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
15 0x00007af16d726850 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
(gdb)
The bgp keepalive pthread gets deadlocked with itself and consequently
the bgp master pthread gets locked when it attempts to lock
the peerhash_mtx, since it is also locked by the keepalive_pthread
The keepalive pthread is locking the peerhash_mtx in
bgp_keepalives_start. Next the connection->io_mtx mutex in
bgp_keepalives_send is locked and then when it notices a problem it invokes
bgp_stop_with_notify which relocks the same mutex ( and of course
the relock causes it to get stuck on itself ). This generates a
deadlock condition.
Modify the code to only hold the connection->io_mtx as short as
possible.
Donald Sharp [Thu, 24 Oct 2024 15:27:24 +0000 (11:27 -0400)]
bgpd: Store aspath count after aspath has changed
When running bestpath on a very large number of ecmp.
BGP ends up calling aspath_count a very very large number
of times, which results in ~15% cpu runtime in aspath_count_hops.
Modify the aspath to keep track of it's own count. This results
in the function now taking up ~1.5% of the cpu runtime. Enough
for the moment to be ignored.
Donald Sharp [Wed, 23 Oct 2024 17:16:29 +0000 (13:16 -0400)]
bgpd: Do not call evpn_overlay_free no matter what
bgp_update is a very expensive call. Calling evpn_overlay_free
even when we have no evpn data to free is not trivial. Let's
limit the call into this function until we actually have data to
free.
Louis Scalbert [Tue, 22 Oct 2024 16:08:13 +0000 (18:08 +0200)]
bgpd: fix uninitialized labels
Fix uninitialized labels that cause multiple valgrind issues.
> ==3729602== Use of uninitialised value of size 8
> ==3729602== at 0x492B493: hash_get (hash.c:140)
> ==3729602== by 0x2629D2: bgp_labels_intern (bgp_label.c:98)
> ==3729602== by 0x2E6C92: bgp_adj_out_set_subgroup (bgp_updgrp_adv.c:622)
> ==3729602== by 0x2A6810: subgroup_process_announce_selected (bgp_route.c:3340)
> ==3729602== by 0x2E5FF6: group_announce_route_walkcb (bgp_updgrp_adv.c:260)
> ==3729602== by 0x2E3E28: update_group_walkcb (bgp_updgrp.c:1759)
> ==3729602== by 0x492B9A0: hash_walk (hash.c:270)
> ==3729602== by 0x2E498C: update_group_af_walk (bgp_updgrp.c:2090)
> ==3729602== by 0x2E7C0D: group_announce_route (bgp_updgrp_adv.c:1119)
> ==3729602== by 0x2A796E: bgp_process_main_one (bgp_route.c:3865)
> ==3729602== by 0x2A808A: bgp_process_wq (bgp_route.c:3991)
> ==3729602== by 0x49CC7CF: work_queue_run (workqueue.c:282)
> ==3729602== by 0x49BBF25: event_call (event.c:2019)
> ==3729602== by 0x49413CA: frr_run (libfrr.c:1238)
> ==3729602== by 0x1FD1D3: main (bgp_main.c:555)
> ==2604268== Use of uninitialised value of size 8
> ==2604268== at 0x4943016: hash_get (hash.c:159)
> ==2604268== by 0x26EFC1: bgp_labels_intern (bgp_label.c:97)
> ==2604268== by 0x28077B: leak_update (bgp_mplsvpn.c:1298)
> ==2604268== by 0x2824A3: vpn_leak_from_vrf_update (bgp_mplsvpn.c:1932)
> ==2604268== by 0x2C281C: bgp_static_update (bgp_route.c:6974)
> ==2604268== by 0x2C366F: bgp_static_set (bgp_route.c:7263)
> ==2604268== by 0x2C435B: bgp_network_magic (bgp_route.c:7556)
> ==2604268== by 0x2ACF09: bgp_network (bgp_route_clippy.c:86)
> ==2604268== by 0x4914EE7: cmd_execute_command_real (command.c:1003)
> ==2604268== by 0x4915060: cmd_execute_command (command.c:1062)
> ==2604268== by 0x4915610: cmd_execute (command.c:1228)
> ==2604268== by 0x49E7C32: vty_command (vty.c:625)
> ==2604268== by 0x49E9B56: vty_execute (vty.c:1388)
> ==2604268== by 0x49EC331: vtysh_read (vty.c:2400)
> ==2604268== by 0x49E06F1: event_call (event.c:2001)
> ==2604268== by 0x495AB8B: frr_run (libfrr.c:1238)
> ==2604268== by 0x200C4B: main (bgp_main.c:555)
Fixes: ddb5b4880b ("bgpd: vpn-vrf route leaking") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Shbinging [Tue, 22 Oct 2024 06:48:33 +0000 (06:48 +0000)]
ospfd:fix syntax of some no commands
Fix syntax of the following no commands:
1. `no area virtual link A.B.C.D hello-interval <NUM>`, `<NUM>` can be omitted.
2. `no area nssa default-information-originate metric <NUM>`, `<NUM>` can be omitted.
3. `no area nssa range cost <NUM>`, `<NUM>` can be omitted.
4. `no area default cost <NUM>`, `<NUM>` can be omitted.
5. `no ospf write-multiplier <NUM>`, `<NUM>` can be omitted.
6. `no default-information originate metric <NUM>`, `<NUM>` can be omitted.
7. `no distance <NUM>`, `<NUM>` can be omitted.
baozhen-H3C [Tue, 22 Oct 2024 07:59:39 +0000 (15:59 +0800)]
isisd: The command "'show isis vrf all summary json" has no output.
When input 'show isis vrf all summary', output is as follow:
sonic# show isis vrf all summary
vrf : default
Process Id : 55
System Id : 0000.0000.0006
Symbolic name : RouterA
Up time : 4d01h52m ago
Number of areas : 1
Area 10:
Net: 10.0000.0000.0006.00
IS_name: RouterA
TX counters per PDU type:
L1 IIH: 365003
L1 LSP: 20468
L1 PSNP: 8
LSP RXMT: 0
RX counters per PDU type:
L1 IIH: 361577
L2 IIH: 434
L1 LSP: 10492
L1 CSNP: 114260
Level-1:
LSP0 regenerated: 4840
LSPs purged: 0
SPF:
minimum interval : 1
IPv4 route computation:
last run elapsed : 00:01:02 ago
last run duration : 327 usec
run count : 12053
However, json display is null.
Donatas Abraitis [Thu, 17 Oct 2024 08:11:50 +0000 (11:11 +0300)]
bgpd: Handle non-transitive extended communities for link-bandwidth
If we received a non-transitive extended community (in this case it was
extended link-bandwidth), we treated it as unknown because we didn't check for
the transitive flag correctly.
Shbinging [Tue, 22 Oct 2024 05:34:26 +0000 (05:34 +0000)]
ospfd:fix the bug that the empty area was not free after no area range command was executed
When we use the no area X.X.X.X range A.B.C.D/M command, if the area no longer has an interface to which it belongs, then the area should be deleted from the LSDB. This processing logic is consistent with instructions such as no network area and no area authentication.
projects / mirror / frr.git / log