A redistribute cmd can have a route-map attached to it and adding the
match source-protocol to that route-map means BGP to filter which
protocol routes to accept among the bunch of routes zebra is sending.
Fixing this since this wasnt implemented earlier.
Ticket :#4119692
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
Add the abilty to track how much time is spent in routemaps.
Example of the new output:
eva# show route-map
ZEBRA:
route-map: FOO Invoked: 1000000 (323 milliseconds total) Optimization: enabled Processed Change: false
deny, sequence 10 Invoked 1000000 (320 milliseconds total)
Match clauses:
Set clauses:
Call clause:
Action:
Exit routemap
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Add a basic topology that allows the testing of BGP and zebra
at scale. I built this to help me find and fix problems with
a large number of bgp peers. Since I plan to keep using this
and as I understand it there are future plans to take this
higher, I would like to add this as a test that people can invoke
with this command:
sudo -E python3 -m pytest -s -vv --topology-only
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
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>
