Add a new test case that re-add the deleted SIDs and verifies that all
SIDs are added back to the RIB.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
Add a new test case that deletes a SID and verifies that only this
SID has been removed from the RIB.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
Add a topotest to verify the newly introduced CLI to support
steering of IPv4 traffic over an SRv6 SID list.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
The fpm_testing_topo1 didn't turn on the fpm_listener
sending the routes back to zebra to set the asic offload.
Modify the test to tell the fpm_listener to set the offloaded
flag and reflect the route back to the dplane_fpm_nl.c code.
Also modify zebra to expect a response to the underlying fpm listener.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Currently FRR does not handle v6 recurisive resolution properly
when the route being recursed through changes and the most
significant bits of the route are not changed.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The "static_simple" test has code for testing IPv6 routes, but it wasn't
even being run (duh.) Enable it, and also test IPv6 dst-src routes.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The staticd YANG conversion completely f*cked up dst-src routes.
Stupidly enough, the correct thing is much simpler as seen by the amount
of deletes in this commit.
This does, unfortunately, involve a rather annoying YANG edge case with
what should reasonably be an optional leaf as part of a list key, which
is not possible. It uses `::/0` as unconditional filler instead, since
that is semantically correct.
The `test_yang_mgmt` topotest needed to be adjusted after this to add
`src-prefix='::/0'`.
Fixes: 88fa5104a0 ("staticd : Configuration northbound implementation")
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Add a test that check that the detailed command of show bgp advertised
neighbors 10.125.0.2 displays the locpref value.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Add a test that checks that the BGP route to 192.168.0.1 has all the
necessary json outputs. This route is chosen because it is a suppressed
route.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This reverts commit 05cf9d03b3.
TL;DR; Handling BGP AddPath capability is not trivial (possible) dynamically.
When the sender is AddPath-capable and sends NLRIs encoded with AddPath ID,
and at the same time the receiver sends AddPath capability "disable-addpath-rx"
(flag update) via dynamic capabilities, both peers are out of sync about the
AddPath state. The receiver thinks already he's not AddPath-capable anymore,
hence it tries to parse NLRIs as non-AddPath, while they are actually encoded
as AddPath.
AddPath capability itself does not provide (in RFC) any mechanism on backward
compatible way to handle NLRIs if they come mixed (AddPath + non-AddPath).
This explains why we have failures in our CI periodically.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
In this topotests, R1 is configured with an l3vni, while R2 is
configured with an l2vni. Update R2 config to match R1 config.
Signed-off-by: Loïc SANG <loic.sang@6wind.com>
OSPF topotest to test OSPF next-hop pruning on installation
into zebra routing table. Also fix multicast_pim_dr_nondr_test
topotest which had a duplicate OSPF route in the results.
Signed-off-by: Acee Lindem <acee@lindem.com>
X
There is no connectivity by using the proposed srv6 path.
> From Carmine:
> This seg6-route tells rt1 to steer packets destined to fc00:0:9::1 over this path: rt1->rt2->-rt6.
> This path is not correct. Since we are installing this seg6-route on rt1,
> it means that a packet matching this seg6-route has already reached rt1.
> So rt1 should not be part of the path.
> The correct path should be rt2->rt6.
Fix this by changing the proposed seg6 route. Also, the ping test should
be swapped, because invalidating the RT1 locator does not have any
impacts on the built SRv6 path.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When not configuring a route distinguisher, neither route-target,
the derived rd settings differ if config load applies with frr.conf
or not. For instance, the forged rd with frr.conf:
> # show bgp l2vpn evpn json
> "192.168.101.41:3":{
> "rd":"192.168.101.41:3",
and without:
> "192.168.101.41:2":{
> "rd":"192.168.101.41:2",
The defined rts also are impacted. Temporay fix this by using an
hardset configuration for all route distinguisher and route target
of the setups.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Add a test that ensures that the 'match evpn vni' command works with bgp
evpn rt5 updates.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Add a test to control the json values of the incoming BGP update
received by an unnumbered BGP.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Drop redundant function (duplicate), and reset counters for r2 instead of r1.
We check received capabilities on r2, hence we need to flush the counters on r2 too.
Fixes: d1cfd73060 ("tests: Check if ENHE capability can be handled dynamically")
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
