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>
this commit containes 2 testcases that covers
1. Default originate behaviour on restarting the BGP daemon and FRR router
2. Default Originate behaviour on shut no-shutting the interface
Signed-off-by: ARShreenidhi <rshreenidhi@vmware.com>
Issue was reported by Donald, we were hitting
with key not found error and execution was
stopped, which is fixed by this PR.
Signed-off-by: Kuldeep Kashyap <kashyapk@vmware.com>
The bgp_conditional_advertisement topotest runs all the test cases in
the same function. It is not easy to debug it because the pytest
"--pause" argument does not make breaks between test cases.
Dispatch the test-cases into functions to benefit from the "--pause"
feature.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Before this patch we can enable 'ip ospf bfd' via '[no] ip ospf bfd profile ...' commads.
After patch '[no] ip ospf bfd profile ...' actual only if 'ip ospf bfd' is set.
Signed-off-by: Dmitrii Turlupov <dturlupov@factor-ts.ru>
Just adding a support for peer-groups, because now it's not possible to
configure BGP role for peer-groups.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
A SR policy matches a BGP nexthop based on the IP address of
the nexthop and the color of the route (color may be assigned
to routes using a route-map).
The order of events (BGP route arrival, route-map definition,
policy and candidate-path definition) should not affect the
matching/mapping.
These changes add tests for:
- removing/adding BGP route after policy and routemap are
defined and held constant
- changing route map color to be different from policy color,
and then changing back to match
after each change, the policy should be observed to be in effect
unchanged from before, i.e., the route's nexthops should reflect
the matching SR policy.
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
In topotests, we also want to check for role mismatch cases. However, if
we are testing the sender of a role mismatch notification, sometimes it
can have non-deterministic behavior (probably due to a configuration
change). Thus, there is an assumption that the recipient of
notifications will more consistently display the reason why the session
was terminated in the first place.
Signed-off-by: Eugene Bogomazov <eb@qrator.net>
I have a test failure:
r1.vtysh_cmd(
"sharp install seg6local-routes {} nexthop-seg6local dum0 {} 1".format(
dest, context
)
)
test_func = partial(
check,
r1,
dest,
manifest["out"],
)
success, result = topotest.run_and_expect(test_func, None, count=5, wait=1)
> assert result is None, "Failed"
E AssertionError: Failed
E assert Generated JSON diff error report:
E
E > $: d2 has the following element at index 0 which is not present in d1:
E
E {
E "prefix": "1::1/128",
E "protocol": "sharp",
E "selected": true,...
E
The test output for 1::1/128:
{
"1::1/128":[
{
"prefix":"1::1/128",
"prefixLen":128,
"protocol":"sharp",
"vrfId":0,
"vrfName":"default",
"selected":true,
"destSelected":true,
"distance":150,
"metric":0,
"queued":true,
"table":254,
"internalStatus":8,
Notice that it is still queued after 5 seconds. Under extremely heavy system load
this is not long enough for convergence. Also the zebra.log shows thread starvation
as well as long running tasks
2022/06/17 15:30:02 ZEBRA: [PHJDC-499N2][EC 100663314] STARVATION: task dplane_incoming_request (55b3ce0fea8b) ran for 6369ms (cpu time 0ms)
2022/06/17 15:30:02 ZEBRA: [T83RR-8SM5G] zebra 8.4-dev starting: vty@2601
2022/06/17 15:30:02 ZEBRA: [YZRX4-ZXG0C][EC 100663315] Thread Starvation: {(thread *)0x55b3ce6c15b0 arg=0x0 timer r=-6.375 rib_sweep_route() &zrouter.sweeper from zebra/main.c:447} was scheduled to pop greater than 4s ago
Increasing the time to 25 seconds to give it a chance.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
In the previous version, the time.sleep function was included to wait
for the moment when the routes were sent to all routers. Changed this
function to topotest.run_and_expect for more deterministic behavior.
Signed-off-by: Eugene Bogomazov <eb@qrator.net>
1. Removed the step from hello test case with hello
timer of 65535. This test works in some platforms
and does not work in others, affecting stability.
Signed-off-by: nguggarigoud <nguggarigoud@vmware.com>
this PR contains the basic bgp default originate.
Details of the testcase is available in respective script files
Signed-off-by: ARShreenidhi <rshreenidhi@vmware.com>
RFC9234 is a way to establish correct connection roles (Customer/
Provider, Peer or with RS) between bgp speakers. This patch:
- Add a new configuration/terminal option to set the appropriate local
role;
- Add a mechanism for checking used roles, implemented by exchanging
the corresponding capabilities in OPEN messages;
- Add strict mode to force other party to use this feature;
- Add basic support for a new transitive optional bgp attribute - OTC
(Only to Customer);
- Add logic for default setting OTC attribute and filtering routes with
this attribute by the edge speakers, if the appropriate conditions are
met;
- Add two test stands to check role negotiation and route filtering
during role usage.
Signed-off-by: Eugene Bogomazov <eb@qrator.net>
