Modified nhrp_topo topotest to test for newly added resolution
request retry feature. Changes to the topotest include adding a spoke to the
existing nhrp_topo topotest so that a topology with two spokes and hub
can be used to create shortcuts and test the sending/resending of
resolution requests and responses between spoke and hub. The resolution
request retry feature was tested by blocking incoming resolution requests on a
receiving nodes to stop the creation of a successful shortcut - which
then triggered the sending spoke to retry sending resolution requests
Signed-off-by: Joshua Muthii <jmuthii@labn.net>
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).
Signed-off-by: Liam Brady <lbrady@labn.net>
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:
> python3 -m pytest -vvss --valgrind-leak-kinds=all --valgrind-extra --valgrind-memleaks bgp_bmp_vrf
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>
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:
> python3 -m pytest -vvss --valgrind-leak-kinds=all --valgrind-extra --valgrind-memleaks bgp_bmp
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>
The BGP BMP VRF topotest is difficult to debug. It does not say which
prefix is not received by BGP or BMP when it fails.
Rework the test to convert the actual BMP logs to JSON and compare the
BGP table and BMP server logs output to expected reference JSON files.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
The BGP BMP topotest is difficult to debug. It does not say which prefix
is not received by BGP or BMP when it fails.
Rework the test to convert the actual BMP logs to JSON and compare the
BGP table and BMP server logs output to expected reference JSON files.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
WARNING: topo: Waiting time is too small
(count=10, wait=0.5), using default values (count=20, wait=3)
Supress warning by inscreasing wait time.
Signed-off-by: Loïc Sang <loic.sang@6wind.com>
When a prefix is imported using the "network" command under a vrf, which
is a connected prefix, and in the context of label allocation per
nexthop:
..
>router bgp 1 vrf vrf1
> address-family ipv4 unicast
> redistribute static
> network 172.16.0.1/32 <--- connected network
> network 192.168.106.0/29
> label vpn export auto
> label vpn export allocation-mode per-nexthop
..
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.
Update topotests.
Signed-off-by: Loïc Sang <loic.sang@6wind.com>
bmpserver infinitely loops after the clients has closed the TCP session.
In this situation, recv() returns empty data.
Detect session close immediately.
Fixes: 875511c466 ("topotests: add basic bmp collector")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
In this topotest, the route reflector advertises a route with the
aigp attribute to its client, some with the nexthop unchanged and
some with the nexthp changed. Different aigp values are sent to
the clients depending on the nexthop setting.
Signed-off-by: Enke Chen <enchen@paloaltonetworks.com>
a local logger masks the global logger and prevents errors from being
gracefully handled within topotest.py
Signed-off-by: Liam Brady <lbrady@labn.net>
Move the various destinations handling into lib/memory.c, include
"normal" logging as target, and make `ACTIVEATEXIT` properly non-error
as it was intended to be.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Add a new topotest for getting the aigp from the "igp-metric"
for a redistributed route (ospf route in the test).
Signed-off-by: Enke Chen <enchen@paloaltonetworks.com>
Update IS-IS fuzz test to match corrected output after change in the
display of IPv4 mapped IPv6 address.
The update was performed using wuschl [1] like this:
$ wuschl rebuild tests/isisd/test_fuzz_isis_tlv
$ gzip -9 tests/isisd/test_fuzz_isis_tlv_tests.h
[1] https://pypi.org/project/wuschl/
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Fix and adjust the topotest post the fix for route selection with
AIGP.
When there are multiple IGP domains (OSPF in this case), the nexthop
for a BGP route with the AIGP attribute must be resolved in its own
IGP domain.
The changes in r2/bgpd.conf and r3/bgpd.conf are needed as incorrect
IGP metrics are received from NHT for the recursive nexthops. Once
the issue is resolved, the changes can be reverted.
Signed-off-by: Enke Chen <enchen@paloaltonetworks.com>
AS 65000 | AS 65001
|
RR |
| |
R1 --- | --- R2
|
When r1 peer is an iBGP route reflector client of rr and r2 peer is a
eBGP neighbor of rr, and all three routers shares the same network, r2
receives announcements coming from r1 with a IPv6 link-local nexthop
from rr. This is incorrect as r2 should send traffic to r1 without
involving rr.
Do not send an IPv6 link-local nexthop if the originating peer is a
route-reflector client.
Link: https://github.com/FRRouting/frr/pull/16219#issuecomment-2397425505
Link: https://github.com/FRRouting/frr/pull/17037#discussion_r1792529683
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Add test to check BMP in VRF.
Note that the following configuration works with interface r1-eth0
towards 192.0.2.10 (BMP collector) in the default VRF but not in vrf1.
> router bgp 65501 vrf vrf1
> bmp targets bmp1
> bmp connect 192.0.2.10 port 1789 min-retry 100 max-retry 10000
Also, for some reasons, the test works even without "bgpd: bmp loc-rib
peer up/down for vrfs" commit.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Unset enforce-first-as on r3 of bgp_route_server_client to enable the
reception of routes on this router.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Rework bgp_route_server_client in a more standard form in order to
facilitate the next commut changes. Cosmetic change.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Mgmtd makes use of libyang's internal ietf-yang-library module to add
support for said module to FRR management. Previously, mgmtd was loading
this module explicitly; however, that required that libyang's
`ietf-yang-library.yang` module definition file be co-located with FRR's
yang files so that it (and ietf-datastore.yang) would be found when
searched for by libyang using FRRs search path. This isn't always the
case depending on how the user compiles and installs libyang so mgmtd
was failing to run in some cases.
Instead of doing it the above way we simply tell libyang to load it's
internal version of ietf-yang-library when we initialize the libyang
context.
This required adding a boolean to a couple of the init functions which
is why so many files are touched (although all the changes are minimal).
Signed-off-by: Christian Hopps <chopps@labn.net>
It's replaced and simplified by c3fd1e9520c619babb3004cea6df622ca67b0dfa.
JSON topo is just horrible to debug.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Currently bgp multipath has these properties:
a) mp_info may or may not be on a single path, based
upon path perturbations in the past.
b) mp_info->count started counting at 0( meaning 1 ). As that the
bestpath path_info was never included in the count
c) The first mp_info in the list held the multipath data associated
with the multipath. As such if you were at any other node that data
was not filled in.
d) As such the mp_info's that are not first on the list basically
were just pointers to the corresponding bgp_path_info that was in
the multipath.
e) On bestpath calculation, a linklist(struct linklist *) of bgp_path_info's was
created.
f) This linklist was passed in to a comparison function that took the
old mpinfo list and compared it item by item to the linklist and
doing magic to figure out how to create a new mp_info list.
g) the old mp_info and the link list had to be memory managed and
freed up.
h) BGP_PATH_MULTIPATH is only set on non bestpath nodes in the
multipath.
This is really complicated. Let's change the algorithm to this:
a) When running bestpath, mark a bgp_path_info node that could be in the ecmp path as
BGP_PATH_MULTIPATH_NEW.
b) When running multipath, just walk the list of bgp_path_info's and if
it has BGP_PATH_MULTIPATH_NEW on it, decide if it is in BGP_MULTIPATH.
If we run out of space to put in the ecmp, clear the flag on the rest.
c) Clean up the counting of sometimes adding 1 to the mpath count.
d) Only allocate a mpath_info node for the bestpath. Clean it up
when done with it.
e) remove the unneeded list management associated with the linklist and
the mp_list.
This greatly simplifies multipath computation for bgp and reduces memory
load for large scale deployments.
2 full feeds in work_queue_run prior:
0 56367.471 1123 50193 493695 50362 493791 0 0 0 TE work_queue_run
BGP multipath info : 1941844 48 110780992 1941844 110780992
2 full feeds in work_queue_run after change:
1 52924.931 1296 40837 465968 41025 487390 0 0 1 TE work_queue_run
BGP multipath info : 970860 32 38836880 970866 38837120
Aproximately 4 seconds of saved cpu time for convergence and ~75 mb
smaller run time.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
With AutoRP discovery running by default, that adds a new
IGMP group that needs to be accounted for in IGMP output.
For pim.py
The clear IGMP interfaces function is in a broken state. It was
already ignoring any errors and returned true always, but with
the addition of the AutoRP discovery group, you could end up
with a different group order in the json which would cause a key
error making the test fail. For now I just added a check to
avoid the key error.
Signed-off-by: Nathan Bahr <nbahr@atcorp.com>
With AutoRP discovery running by default, that adds a new
IGMP group that needs to be accounted for in IGMP output.
For multicast_pim_sm_topo3:
Ignore the total group number as it is unnecessary for the test.
Signed-off-by: Nathan Bahr <nbahr@atcorp.com>
Uses hardcoded sample AutoRP packets injected in to test
message parsing and proper application of AutoRP learned
RP info. Tests mix of AutoRP and static RP's.
Signed-off-by: Nathan Bahr <nbahr@atcorp.com>
Range is wrong. We want values 1 and 2 but we only test 1.
> >>> for i in range(1, 2):
> ... print(i)
> ...
> 1
Fixes: abd2a1ff3f ("tests: Test some basic kernel <-> zebra interactions")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
There are no tests that ensured that turning off then on
v4 and v6 forwarding actually worked. This does so.
This was found via looking at the code coverage.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
