In bgp_srv6l3vpn tests, check_ping checks reachability. However, this
function have a bug and if we set expect_connected to True, check will
pass even if all ping packets are lost. This commit fixes this issue.
Signed-off-by: Ryoga Saito <ryoga.saito@linecorp.com>
The `bgp_srv6l3vpn_to_bgp_vrf2` topotest tests the SRv6 IPv4 L3VPN
functionality. It applies the appropriate configuration in `bgpd` and
`zebra`, and then checks that the RIB is updated correctly.
The topotest expects to find the AS-Path in the RIB, which is only
present if the `bgp send-extra-data zebra` option is enabled in the
`bgpd` configuration.
Currently, the `bgp send-extra-data zebra` option is not set in the
`bgpd` configuration, which always causes the topotest to fail.
This commit fixes the `bgp_srv6l3vpn_to_bgp_vrf2` topotest by enabling
the `bgp send-extra-data zebra` option for both routers `r1` and `r2`.
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
add a test dedicated to confederation. it also take into
account the support of AS memberwith same id that the
confederation id.
Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>
Previous commit changes the order of srv6 locator parameters. So, this
PR reflect the previous changes.
Signed-off-by: Ryoga Saito <ryoga.saito@linecorp.com>
This commit adds a basic test for sharpd traffic control PoC, which will check
interface TC info from iproute2 `tc` cli.
Signed-off-by: Siger Yang <siger.yang@outlook.com>
This is for run_and_expect_type and run_and_expect topotests method.
Some contributions unintentionally get merged with very low values, that leads
to CI failures, let's guard this a bit.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Ensure that the minimum time spent run and expecting is
5 seconds. Heavy load is not a reason to fail a test.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
isis_lfa_topo1 topotests regularly fails at step 24. The test expects
that the BFD session between rt1 and rt2 comes down after shutting the
link between rt1 and rt2.
Since the BFD is multihop, the BFD can get back through rt3.
Set the BFD type to single-hop.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
We already have a global knob for graceful-shutdown, but it's handy having
per neighbor knob as well.
Especially when a single neighbor needs to be restarted/shutdown gracefuly.
We can do this route-maps, but this is a faster/cleaner way doing the same
for an operator.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
This test ensures that the command `behavior usid` works properly.
When the `behavior usid` command is set, a flag is added to the locator
to indicate that the locator is a uSID locator. This test verifies that
the locator works correctly when you set / unset the `behavior usid`
command.
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
Automated new scenarios to multicast pimv6
static rp test suite. Added new folder
multicast_pim6_static_rp_topo1 for pimv6
static_rp automation.
Signed-off-by: Kuldeep Kashyap <kashyapk@vmware.com>
When zebra receives routes from upper level protocols it decodes the
zapi message and places the routes on the metaQ for processing. Suppose
we have a route A that is already installed by some routing protocol.
And there is a route B that has a nexthop that will be recursively
resolved through A. Imagine if a route replace operation for A is
going to happen from an upper level protocol at about the same time
the route B is going to be installed into zebra. If these routes
are received, and decoded, at about the same time there exists a
chance that the metaQ will contain both of them at the same time.
If the order of installation is [ B, A ]. B will be resolved
correctly through A and installed, A will be processed and
re-installed into the FIB. If the nexthops have changed for
A then the owner of B should be notified about the change( and B
can do the correct action here and decide to withdraw or re-install ).
Now imagine if the order of routes received for processing on the
metaQ is [ A, B ]. A will be received, processed and sent to the
dataplane for reinstall. B will then be pulled off the metaQ and
fail the install since A is in a `not Installed` state.
Let's loosen the restriction in nexthop resolution for B such
that if the route we are dependent on is a route replace operation
allow the resolution to suceed. This requires zebra to track a new
route state( ROUTE_ENTRY_ROUTE_REPLACING ) that can be looked at
during nexthop resolution. I believe this is ok because A is
a route replace operation, which could result in this:
-route install failed, in which case B should be nht'ing and
will receive the nht failure and the upper level protocol should
remove B.
-route install succeeded, no nexthop changes. In this case
allowing the resolution for B is ok, NHT will not notify the upper
level protocol so no action is needed.
-route install succeeded, nexthops changes. In this case
allowing the resolution for B is ok, NHT will notify the upper
level protocol and it can decide to reinstall B or not based
upon it's own algorithm.
This set of events was found by the bgp_distance_change topotest(s).
Effectively the tests were looking for the bug ( A, B order in the metaQ )
as the `correct` state. When under very heavy load, the A, B ordering
caused A to just be installed and fully resolved in the dataplane before
B is gotten to( which is entirely possible ).
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Column headers in BGP routes table are not aligned with data when
RPKI status is available. This was fixed to insert a space at the
beginning of the header and at the beginning of lines that do not
have RPKI status.
This fix requires that several testing templates be adjusted to
match the new output.
Signed-off-by: Wayne Morrison <wmorrison@netgate.com>
Add a switchover test that consists in:
- Setting up ISIS BFD between rt1 and rt2
- The no link-detect setting on rt1 eth-rt2 is still present so that
zebra does not take account linkdown events on this interface.
- Shutting down rt1 eth-rt2 from the switch side
- Wait for BFD to comes down
Check that the switchover between primary and backup happens before the
SPF re-computation.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Add a switchover test that consists in clearing the rt2 neighbor on rt1.
Check that the switchover between primary and backup happens before the
SPF re-computation.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Add a switchover test that consists in:
- Setting no link-detect on rt1 eth-rt2 so that zebra does not take
account linkdown events on this interface.
- Shutting down rt1 eth-rt2 from the switch side
- Wait for the hello timer expiration
Check that the switchover between primary and backup happens before the
SPF re-computation.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Add a switchover test that consists in shutting down an interface.
Check that the switchover between primary and backup happens before the
SPF re-computation.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Add a switchover test that consists in:
- Setting up ISIS BFD between rt5 and rt6
- Setting no link-detect on rt6 eth-rt5 so that zebra does not take
account linkdown events on this interface.
- Shutting down rt6 eth-rt5 from the switch side
Check that the switchover between primary and backup happens before the
SPF re-computation.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Add a switchover test that consists in shutting down an interface.
Check that the switchover between primary and backup happens before the
SPF re-computation.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Also, make sure we check if the advertisement table changed using FROM peer,
not TO peer.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
This commit extends the `bgp_srv6l3vpn_to_bgp_vrf3` topotest by adding
two tests:
* prevent bgpd from exporting routes from a VRF to the VPN RIB
(`no sid vpn per-vrf export`);
* enable bgpd to export routes from a VRF to the VPN RIB
(`sid vpn per-vrf export auto`).
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
This commit adds a new topotest to verify the functionality of SRv6
locators with custom bits length parameters.
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
This commit adds a new topotest which tests SRv6 L3VPN for IPv4 and
IPv6 address families using a single SID.
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
This commit adds a new test case to the
test_zebra_seg6local_route topotest. The new test case performs two
operations:
* try to install a seg6local route with an End.DT46 action
* verify that the route is created correctly
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
When bgp is using `bgp suppress-fib-pending` and the end
operator is using network statements, bgp was not sending
the network'ed prefix'es to it's peers. Fix this.
Also update the test cases for bgp_suppress_fib to test
this new corner case( I am sure that there are going to
be others that will need to be added ).
Fixes: #12112
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Currently, if `bgp max-med on-startup` is configured, after BGP session
is established for the first time, a timer for the specified time is
started. When the timer is expired, an UPDATE message should be sent to
reflect changes in the routes' MED value. The problem is that the routes
are being suppressed because based on the attributes they look like they
have not changed. However, in the case of max-med, the value is copied
to the packet directly from `bgp->maxmed_value`, not from the
attributes. Thus, changes in this case cannot be detected by comparing
attributes.
With this fix, avoid route suppressing when the `max-med on-startup`
timer expires and initiates an UPDATE.
Signed-off-by: Alexander Chernavin <achernavin@netgate.com>
Updating topojson script's assert messages,
which will help in better debugging, when
test will fail.
Signed-off-by: Kuldeep Kashyap <kashyapk@vmware.com>
The bgp_gr_restart_retain_routes test is looking for specific output
that does not include the routes nexthop id:
def _bgp_check_kernel_retained_routes():
output = (
r2.cmd("ip route show 172.16.255.1/32 proto bgp dev r2-eth0")
.replace("\n", "")
.rstrip()
)
expected = "172.16.255.1 via 192.168.255.1 metric 20"
diff = topotest.get_textdiff(
output, expected, "Actual IP Routing Table", "Expected IP RoutingTable"
)
if diff:
return False
return True
While the output includes nexthop group id's now:
root@r2:# ip route show 172.16.255.1 proto bgp dev r2-eth0
172.16.255.1 nhid 8 via 192.168.255.1 metric 20
Let's just mark r2 as not to use nexthop groups for installation
and this test issue will go away.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
In order to minimize the changes of test files, this PR adds `func-bits`
parameters on the SRv6 locator definition.
Signed-off-by: Ryoga Saito <ryoga.saito@linecorp.com>
The issue fixed in the previous commit now correctly triggers a failure:
("assertion (list_add(&head, &itm[j]) == &itm[j]) failed")
Turns out the "shitty" hash function was not shitty enough.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
We might disable sending unconfig/shutdown notifications when
Graceful-Restart is enabled and negotiated.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
When primary global v6 unicast address is configured on an
unnumbered interface, BGP does not re-advertise updates out
with the new global v6 address as the nexthop
Signed-off-by: Pdoijode <pdoijode@nvidia.com>
Before it worked only when configured initially via CLI. Later, when we
receive a new route, that should match a decent MED, we just skip it, because
MED mismatch is not recalculated.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
When redistributing connected addresses, the address family has
to be figured out. The calculation was not done, the next-hop
address length was not set, and as consequence, the nexthop
is displayed like if it was an ipv6 address, which is wrong for
ipv4 addresses.
Calculate the family for connected addresses.
Change the topotests accordingly.
Fixes: ("7226bc40d606") bgpd: ignore NEXT_HOP for MP_REACH_NLRI
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This test ensures that MPLS VPN routes can be installed into a
gre interface with route-map l3vpn next-hop encapsulation command
set. On the other hand, if this command is not set, incoming bgp
routes are not considered as valid.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
- double the size of each new chunk request from zebra
- use bitfields to track label allocations in a chunk
- When allocating:
- skip chunks with no free labels
- search biggest chunks first
- start search in chunk where last search ended
- Improve API documentation in comments (bgp_lp_get() and callback)
- Tweak formatting of "show bgp labelpool chunks"
- Add test features (compiled conditionally on BGP_LABELPOOL_ENABLE_TESTS)
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
Whn using as-override, we should be able to deny outgoing updates from
being propogated when `neighbor soo` is configured.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
To prove that this works. Modify a test that uses mpls to
turn on mpls for the interfaces that need mpls via the
new mpls command.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This test is sometimes failing when it looks at the
v6 routes in the fib. Since the step before is
ensuring that v3 ospf has just converged let's
give it a bit of time to find and see if things
have had a chance to install the routes too.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This test directory takes almost 7 minutes to complete splitting
this up into 3 test files drops it down to just over 3 minutes.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Enhanced few exsiting PIM APIs to support both
IPv4 and IPv6 configuration. Added few new APIs
for PIMv6. Tested all existing tests with new
API changes.
Signed-off-by: Kuldeep Kashyap <kashyapk@vmware.com>
This tests checks that there are no errors when receiving BFD
packets over the various linux vrf interfaces. For example, if
an incoming packet is received by the wrong socket, a VRF
mismatch error would occur, and BFD flapping would be observed.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
I rarely get this failure:
@classname: bgp_snmp_mplsl3vpn.test_bgp_snmp_mplsvpn
@name: test_pe1_converge_evpn
@time: 44.875
@message: AssertionError: BGP SNMP does not seem to be running
assert False
+ where False = <bound method SnmpTester.test_oid of <lib.snmptest.SnmpTester object at 0x7fa8562eb4f0>>('bgpVersion', '10')
+ where <bound method SnmpTester.test_oid of <lib.snmptest.SnmpTester object at 0x7fa8562eb4f0>> = <lib.snmptest.SnmpTester object at 0x7fa8562eb4f0>.test_oid
"Wait for protocol convergence"
tgen = get_topogen()
r1 = tgen.gears["r1"]
r1_snmp = SnmpTester(r1, "10.1.1.1", "public", "2c")
assertmsg = "BGP SNMP does not seem to be running"
> assert r1_snmp.test_oid("bgpVersion", "10"), assertmsg
E AssertionError: BGP SNMP does not seem to be running
E assert False
E + where False = <bound method SnmpTester.test_oid of <lib.snmptest.SnmpTester object at 0x7fa8562eb4f0>>('bgpVersion', '10')
E + where <bound method SnmpTester.test_oid of <lib.snmptest.SnmpTester object at 0x7fa8562eb4f0>> = <lib.snmptest.SnmpTester object at 0x7fa8562eb4f0>.test_oid
Under heavy system load a quick test before BGP can fully come up can result in a failed
test. Add some extra time for snmp to come up properly.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This test checks that when retain functionality is disabled,
some prefixes are removed from the BGP ipv4 vpn RIB.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
- ignore parent from daemonize valgrind files these allocations will be
checked in the child.
- check for memleaks at end of module/file not just after tests.
Signed-off-by: Christian Hopps <chopps@labn.net>
API to verify static route was checking whether
router is installed with expected nexthop. In
this particular scenario we has same route as
Connected and Static both. In heavy loaded
system static routes was taking time to get
installed and API was doing the verification
on Connected route instead Static route.
Enhanced scripts to check only static routes.
Issue: https://github.com/FRRouting/frr/issues/11563
Signed-off-by: Kuldeep Kashyap <kashyapk@vmware.com>
When there is change in route-map policy associated with default-originate, changes does not reflect.
When route-map associated with default-originate is deleted, default route doesn't get withdrawn
Update message is not being sent when only route-map is removed from the default-originate config.
SNT counter gets incremented on change of every policy associated with default-originate
Route-map with multiple match clauses causes inconsistencies with default-originate.
Default-originate behaviour on BGP-attributes
Signed-off-by: ARShreenidhi <rshreenidhi@vmware.com>
