Donald Sharp [Thu, 29 Aug 2024 15:29:55 +0000 (11:29 -0400)]
zebra: Allow for initial deny of installation of nhe's
Currently the FRR code will receive both kernel and
connected routes that do not actually have an underlying
nexthop group at all. Zebra turns around and creates
a `matching` nexthop hash entry and installs it.
For connected routes, this will create 2 singleton
nexthops in the dplane per interface (v4 and v6).
For kernel routes it would just create 1 singleton
nexthop that might be used or not.
This is bad because the dplane has a limited amount
of space available for nexthop entries and if you
happen to have a large number of interfaces then
all of a sudden you have 2x(# of interfaces) singleton
nexthops.
Let's modify the code to delay creation of these singleton
nexthops until they have been used by something else in the
system.
Donald Sharp [Thu, 29 Aug 2024 22:10:30 +0000 (18:10 -0400)]
zebra: Convince SA that the ng will always be valid
There is a code path that could theoretically get you
to a point where the ng->nexthop is a NULL value.
Let's just make sure the SA system believes that
cannot happen anymore.
Donald Sharp [Thu, 29 Aug 2024 19:06:31 +0000 (15:06 -0400)]
zebra: Allow blackhole singleton nexthops to be v6
A blackhole nexthop, according to the linux kernel,
can be v4 or v6. A v4 blackhole nexthop cannot be
used on a v6 route, but a v6 blackhole nexthop can
be used with a v4 route. Convert all blackhole
singleton nexthops to v6 and just use that.
Possibly reducing the number of active nexthops by 1.
Donald Sharp [Thu, 29 Aug 2024 18:49:36 +0000 (14:49 -0400)]
zebra: Display afi of the nexthop hash entry
Let's display the afi of the nexthop hash entry. Right
now it is impossible to tell the difference between v4 or
v6 nexthops, especially since it is important for the kernel.
Donald Sharp [Wed, 28 Aug 2024 19:10:04 +0000 (15:10 -0400)]
tests: ospf_netns_vrf should give more time for coming up
Test fails:
test_func = partial(
topotest.router_json_cmp,
router,
"show ip ospf vrf {0}-ospf-cust1 json".format(rname),
expected,
)
_, diff = topotest.run_and_expect(test_func, None, count=10, wait=0.5)
assertmsg = '"{}" JSON output mismatches'.format(rname)
> assert diff is None, assertmsg
E AssertionError: "r1" JSON output mismatches
E assert Generated JSON diff error report:
E
E > $->r1-ospf-cust1->areas->0.0.0.0->nbrFullAdjacentCounter: output has element with value '1' but in expected it has value '2'
Support bundle has this data:
r1# show ip ospf vrf all neighbor
% 2024/08/28 14:55:54.763
VRF Name: r1-ospf-cust1
Neighbor ID Pri State Up Time Dead Time Address Interface RXmtL RqstL DBsmL
10.0.255.3 1 Full/DR 10.547s 39.456s 10.0.3.1 r1-eth1:10.0.3.2 0 0 0
10.0.255.2 1 Full/Backup 0.543s 38.378s 10.0.3.3 r1-eth1:10.0.3.2 1 0 0
So immediately after the test fails this test, the neighbor comes up.
Let's give the test a bit more time for failure to not happen
Donald Sharp [Wed, 28 Aug 2024 16:05:41 +0000 (12:05 -0400)]
doc: Update topotest doc to include iptables is needed
The nhrp tests skip tests that do not have iptables installed.
As such we have ended up with a situation where the nrhp test
is now failing locally for me because I have iptables installed
and if the CI system had iptables installed it would have detected
the problem as well.
Let's document that iptables is needed to do testing.
Donald Sharp [Tue, 27 Aug 2024 21:08:38 +0000 (17:08 -0400)]
tests: Fix bgp_default_originate_topo1_3
This test was killing bgp on r1 and r2
and then immediately testing that the
default route transitioned. Unfortunately
the test was written that under load the
system might be in a bad state. Let's
modify the code to check for a bgp version
change and then that the bgp state has
come back up
The output buffer vty->obuf is a linked list where
each element is of 4KB.
Currently, when a huge sh command like <show ip route json>
is executed on a large scale, all the vty_outs are
processed and the entire data is accumulated.
After the entire vty execution, vtysh_flush proceeses
and puts this data in the socket (131KB at a time).
Problem here is the memory spike for such heavy duty
show commands.
The fix here is to chunkify the output on VTY shell by
flushing it intermediately for every 128 KB of output
accumulated and free the memory allocated for the buffer data.
This way, we achieve ~25-30% reduction in the memory spike.
Fixes: #16498
Note: This is a continuation of MR #16498
Signed-off-by: Srujana <skanchisamud@nvidia.com> Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
Igor Ryzhov [Tue, 26 Mar 2024 14:54:54 +0000 (16:54 +0200)]
lib: rework debug init
The debug library allows to register a `debug_set_all` callback which
should enable all debugs in a daemon. This callback is implemented
exactly the same in each daemon. Instead of duplicating the code, rework
the lib to allow registration of each debug type, and implement the
common code only once in the lib.
Donald Sharp [Thu, 15 Aug 2024 20:02:55 +0000 (16:02 -0400)]
tests: Add some tests to show new behavior works as expected
a) A noprefix address by itself should not create a connected route.
This was pre-existing.
b) A noprefix address with a corresponding route should result in a
connected route. This is how NetworkManager appears to work.
This is new behavior, so a new test.
c) A route is added to the system from someone else.
This is new behavior, so a new test.
Donald Sharp [Wed, 26 Jun 2024 17:21:38 +0000 (13:21 -0400)]
zebra: Prevent accidental re memory leak in odd case
There exists a path in rib_add_multipath where if a decision
is made to not use the passed in re, we just drop the memory
instead of freeing it. Let's free it.
Donald Sharp [Fri, 7 Jun 2024 17:50:07 +0000 (13:50 -0400)]
zebra: Handle kernel routes appropriately
Current code intentionally ignores kernel routes. Modify
zebra to allow these routes to be read in on linux. Also
modify zebra to look to see if a route should be treated
as a connected and mark it as such.
Additionally this should properly handle some of the issues
being seen with NOPREFIXROUTE.
tests: Fix frequent ospfv3 basic functionality test failure
The dead timer is set to 4 seconds, while the hello interval is set to 6535.
This test will only pass of the platform is fast enough for ospfv3 to
converge in 4 seconds. These timers were already tested multiple time earlier.
This test should just make sure that the boundary value 65535 is configurable,
Other changes in this commit:
- add sequence numbers to the dead intervals tests to make it easier to
track test faliures.
- swap the config order in one test to match order with all other tests.
Donald Sharp [Wed, 21 Aug 2024 19:44:12 +0000 (15:44 -0400)]
tests: Allow convergence before adding multicast routes
Current code adds a new vlan interface, sets up ospf and
pim on it and immediately starts shoving data down the pipes.
This of course has the fun thing where the IGP and pim do not
always come up in a nice neat manner and the test is looking
for state from a nice neat come up, even though pim is `working`
correctly it is not correct for what the test wants.
Modify the code to ensure that ospf is up and has propagated
the route where it is needed as well as that pim neighbors have
properly come up, then initiate the multicast streams and igmp
reports.
Louis Scalbert [Mon, 26 Aug 2024 08:23:12 +0000 (10:23 +0200)]
bgpd: fix labels static-analyser
Fix static-analyser warnings with BGP labels:
> $ scan-build make -j12
> bgpd/bgp_updgrp_packet.c:819:10: warning: Access to field 'extra' results in a dereference of a null pointer (loaded from variable 'path') [core.NullDereference]
> ? &path->extra->labels->label[0]
> ^~~~~~~~~
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Corey Siltala [Fri, 23 Aug 2024 18:04:26 +0000 (18:04 +0000)]
pimd: Fix crash in pimd
ifp->info is not always set in PIM. So add a guard here to stop
it from crashing when addresses are added to a non-PIM enabled interface
and PIM zebra debugging is enabled.
Philippe Guibert [Thu, 22 Aug 2024 14:53:55 +0000 (16:53 +0200)]
bgpd: add json support for BGP L3NHG values
Some json attributes are missing for L3NHG values.
> PE1# show bgp vrf all detail
> [..]
> Instance vrf-purple:
> BGP table version is 1, local router ID is 27.3.0.85, vrf id 7
> Default local pref 100, local AS 65000
> BGP routing table entry for fe80::4620:ff:feff:ff01/128, version 1
> Paths: (1 available, best #1, vrf vrf-purple)
> Not advertised to any peer
> Imported from 10.30.30.30:5:[2]:[0]:[48]:[44:20:00:ff:ff:01]:[128]:[fe80::4620:ff:feff:ff01], VNI 4000 Local
> ::ffff:a1e:1e1e (metric 20) from 10.30.30.30 (10.30.30.30) announce-nh-self
> Origin IGP, localpref 100, valid, internal, best (First path received)
> Extended Community: RT:65000:4000 ET:8
> Last update: Thu Aug 22 18:23:38 2024
>
> Displayed 1 routes and 1 total paths
Khem Raj [Fri, 15 Mar 2024 21:34:06 +0000 (14:34 -0700)]
zebra: Mimic GNU basename() API for non-glibc library e.g. musl
musl only provides POSIX version of basename and it has also removed
providing it via string.h header [1] which now results in compile errors
with newer compilers e.g. clang-18
tools, ospfclient: add a config option to skip installing python scripts
The new config option --disable-python-runtime allows make install to proceed
without installing any of the python scripts. When installing from deb/rpm
packages those are bundled as frr-pythontools, which is independent from the
frr binaries and can already be skipped. I.e, this PR gives the option to skip
those scripts when building/installing from sources too.
Donald Sharp [Tue, 20 Aug 2024 14:53:34 +0000 (10:53 -0400)]
zebra: Create Singleton nhg's without weights
Currently FRR when it has two nexthop groups:
A
nexthop 1 weight 5
nexthop 2 weight 6
nexthop 3 weight 7
B
nexthop 1 weight 3
nexthop 2 weight 4
nexthop 3 weight 5
We end up with 5 singleton nexthops and two groups:
id 69 via 192.168.119.1 dev enp13s0 scope link proto 194
id 70 via 192.168.119.2 dev enp13s0 scope link proto 194
id 71 via 192.168.119.3 dev enp13s0 scope link proto 194
id 127 via 192.168.119.1 dev enp13s0 scope link proto 194
id 128 via 192.168.119.2 dev enp13s0 scope link proto 194
id 181818168 group 69,182/70,218/71,255 proto 194
id 181818169 group 71,255/127,127/128,170 proto 194
This is not a desirable state to be in. If you have a
link flapping in the network and weights are changing
rapidly you end up with a large number of singleton
nexthops that are being used by the nexthop groups.
This fills up asic space and clutters the table.
Additionally singleton nexthops cannot have any weight
and the fact that you attempt to create a singleton
nexthop with different weights means nothing to the
linux kernel( or any asic dplane ). Let's modify
the code to always create the singleton nexthops
without a weight and then just creating the
NHG's that use the singletons with the appropriate
weight.
id 22 via 192.168.119.1 dev enp13s0 scope link proto 194
id 24 via 192.168.119.2 dev enp13s0 scope link proto 194
id 28 via 192.168.119.3 dev enp13s0 scope link proto 194
id 181818168 group 22,182/24,218/28,255 proto 194
id 181818169 group 22,153/24,204/28,255 proto 194
Donald Sharp [Tue, 20 Aug 2024 12:28:17 +0000 (08:28 -0400)]
lib, zebra: Modify nexthop_cmp to allow you to use weight or not
Currently nexthop weight is a discriminator on whether or not
a nexthop matches. There is a need to no use the weight as
part of this comparison function so let's add a boolean to
allow us to say use this or not.
Christian Hopps [Thu, 22 Aug 2024 01:05:48 +0000 (21:05 -0400)]
tests: update munet to 0.14.10
Changes:
- mutini: handle possible missed zombie cleanup leading to test hangs
- mutini: also we avoid logging in the signal handler which was causing
an exception.
Donald Sharp [Thu, 22 Feb 2024 20:53:45 +0000 (15:53 -0500)]
zebra, tests: Connected and Local routes should have a weight of 1
All routes received by zebra from upper level protocols have a weight
of 1. Let's just make everything extremely consistent in our code.
Lot's of tests needed to be fixed up to make this work.
Donald Sharp [Thu, 22 Feb 2024 21:20:37 +0000 (16:20 -0500)]
zebra: Ensure we cannot send invalid range to kernel
The linux kernel adds 1 upon receipt of a weight, if you
send a 255 it gets unhappy. Let's Limit range to 254 as
that kernel does not like sending of 255.
Dmytro Shytyi [Thu, 8 Aug 2024 13:42:40 +0000 (15:42 +0200)]
topotest: test_bgp_snmp_bgpv4v2_notification
This test checks the bgp crash on rt2 when 2 commands
launched consequently:
T0: rr, config -> router bgp 65004 -> neighbor 192.168.12.2 password 8888
T1: rt2, snmpwalk -v 2c -c public 127.0.0.1 .1.3.6.1.4.1.7336.4.2.1
T2: test if rt2 bgp is crashed.
projects / mirror / frr.git / log