Rename router variables in nhrp_redundancy to match the actual name.
Cosmetic change to help debugging.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
The expected prefix should be 5.5.5.0/24 otherwise the hosts behind NHRP
client 1 nhc1 (aka. r5) are not reachable via NHRP.
The issue was not seen in the FRR official CI because the tests were
skipped because iptables were missing in CI machines.
It solves the 16690 issue.
Fixes: https://github.com/FRRouting/frr/issues/16690
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Recent commits moved the default retries to 60, but
the higher ecmp counts were over-riding to 40. Let's
make it 80.
Noticed this when I went looking at failures on 386 platforms
in our ci. Route scale is timing out when deleting routes.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Test fails:
test_func = partial(
topotest.router_json_cmp,
router,
"show ip ospf vrf {0}-ospf-cust1 json".format(rname),
expected,
)
_, diff = topotest.run_and_expect(test_func, None, count=10, wait=0.5)
assertmsg = '"{}" JSON output mismatches'.format(rname)
> assert diff is None, assertmsg
E AssertionError: "r1" JSON output mismatches
E assert Generated JSON diff error report:
E
E > $->r1-ospf-cust1->areas->0.0.0.0->nbrFullAdjacentCounter: output has element with value '1' but in expected it has value '2'
/home/sharpd/frr2/tests/topotests/ospf_netns_vrf/test_ospf_netns_vrf.py:239: AssertionError
Support bundle has this data:
r1# show ip ospf vrf all neighbor
% 2024/08/28 14:55:54.763
VRF Name: r1-ospf-cust1
Neighbor ID Pri State Up Time Dead Time Address Interface RXmtL RqstL DBsmL
10.0.255.3 1 Full/DR 10.547s 39.456s 10.0.3.1 r1-eth1:10.0.3.2 0 0 0
10.0.255.2 1 Full/Backup 0.543s 38.378s 10.0.3.3 r1-eth1:10.0.3.2 1 0 0
So immediately after the test fails this test, the neighbor comes up.
Let's give the test a bit more time for failure to not happen
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Giving only 5 seconds to pass bgp data to peers on a heavily
loaded system is a recipe for not having fun. Add more time.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This test was killing bgp on r1 and r2
and then immediately testing that the
default route transitioned. Unfortunately
the test was written that under load the
system might be in a bad state. Let's
modify the code to check for a bgp version
change and then that the bgp state has
come back up
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Implement common code for debug config output and remove daemon-specific
code that is duplicated everywhere.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
The debug library allows to register a `debug_set_all` callback which
should enable all debugs in a daemon. This callback is implemented
exactly the same in each daemon. Instead of duplicating the code, rework
the lib to allow registration of each debug type, and implement the
common code only once in the lib.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
a) A noprefix address by itself should not create a connected route.
This was pre-existing.
b) A noprefix address with a corresponding route should result in a
connected route. This is how NetworkManager appears to work.
This is new behavior, so a new test.
c) A route is added to the system from someone else.
This is new behavior, so a new test.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The dead timer is set to 4 seconds, while the hello interval is set to 6535.
This test will only pass of the platform is fast enough for ospfv3 to
converge in 4 seconds. These timers were already tested multiple time earlier.
This test should just make sure that the boundary value 65535 is configurable,
Other changes in this commit:
- add sequence numbers to the dead intervals tests to make it easier to
track test faliures.
- swap the config order in one test to match order with all other tests.
Signed-off-by: Jafar Al-Gharaibeh <jafar@atcorp.com>
Current code adds a new vlan interface, sets up ospf and
pim on it and immediately starts shoving data down the pipes.
This of course has the fun thing where the IGP and pim do not
always come up in a nice neat manner and the test is looking
for state from a nice neat come up, even though pim is `working`
correctly it is not correct for what the test wants.
Modify the code to ensure that ospf is up and has propagated
the route where it is needed as well as that pim neighbors have
properly come up, then initiate the multicast streams and igmp
reports.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Changes:
- mutini: handle possible missed zombie cleanup leading to test hangs
- mutini: also we avoid logging in the signal handler which was causing
an exception.
Signed-off-by: Christian Hopps <chopps@labn.net>
All routes received by zebra from upper level protocols have a weight
of 1. Let's just make everything extremely consistent in our code.
Lot's of tests needed to be fixed up to make this work.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This test checks the bgp crash on rt2 when 2 commands
launched consequently:
T0: rr, config -> router bgp 65004 -> neighbor 192.168.12.2 password 8888
T1: rt2, snmpwalk -v 2c -c public 127.0.0.1 .1.3.6.1.4.1.7336.4.2.1
T2: test if rt2 bgp is crashed.
Signed-off-by: Dmytro Shytyi <dmytro.shytyi@6wind.com>
Copied the existing "join-group" test and modified to test
static groups instead. Functionally the same but without IGMP
reports.
Signed-off-by: Nathan Bahr <nbahr@atcorp.com>
Upstream CI is frequently running into a situation where
the routes are not being installed. These routes
start at the beginning and suddenly in the middle
they start working properly.
D 1.0.15.183/32 [150/0] via 192.168.0.1, r1-eth0 inactive, weight 1, 00:10:17
via 192.168.1.1, r1-eth1 inactive, weight 1, 00:10:17
D 1.0.15.184/32 [150/0] via 192.168.0.1, r1-eth0 inactive, weight 1, 00:10:17
via 192.168.1.1, r1-eth1 inactive, weight 1, 00:10:17
D 1.0.15.185/32 [150/0] via 192.168.0.1, r1-eth0 inactive, weight 1, 00:10:17
via 192.168.1.1, r1-eth1 inactive, weight 1, 00:10:17
D>* 1.0.15.186/32 [150/0] via 192.168.0.1, r1-eth0, weight 1, 00:10:17
* via 192.168.1.1, r1-eth1, weight 1, 00:10:17
D>* 1.0.15.187/32 [150/0] via 192.168.0.1, r1-eth0, weight 1, 00:10:17
* via 192.168.1.1, r1-eth1, weight 1, 00:10:17
D>* 1.0.15.188/32 [150/0] via 192.168.0.1, r1-eth0, weight 1, 00:10:17
Turning on some debugs showed that the failed installed routes are
trying to be matched against the default route. Thus implying
all the connected routes for the test are not yet successfully
installed. Let's modify the test(s) on startup to just ensure
that the connected routes are installed correctly. I am no
longer seeing the problem after this change.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The all_protocol_startup topotest needs to allow for some delay
between configuring nexthop-groups and their installation. Add
some wait periods in a couple of nhg test cases.
Signed-off-by: Mark Stapp <mjs@cisco.com>
Vtysh has been improved to startup very quickly this exposed a race in this
test, where the `clear ip rip...` command ran before the test client that
handles it had finished connecting to mgmtd. Add a retried check for the test
client being connected before issuing the `clear ip rip ...` test command.
Signed-off-by: Christian Hopps <chopps@labn.net>
Add some timers to make convergence happan as fast as possible
when a connection fails on the intial attempt.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Add some timers to make the convergence happen as fast as possible
when a connection fails on the initial attempt.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When running bfd_bgp_cbit_topo3 and an intial connection
goes wrong, try to connect again as fast as possible as
that the timer is 2 minutes otherwise and the test will
never come back from it.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This test is frequently failing in the upstream CI. Most
log failures are stating that we expected something like
1 million routes but we have 900k+. Looks like the system
is just loaded a bit more than expected. Let's give these
tests a bit more time to complete.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Store a parsed and built graph of the CLI nodes in vtysh, rather than
parsing and building that graph every time vtysh starts up.
This provides a 3x to 5x reduction in vtysh startup overhead:
`vtysh -c 'configure' -c 'interface lo' -c 'do show version'`
- before: 92.9M cycles, 1114 samples
- after: 16.5M cycles, 330 samples
This improvement is particularly visible for users scripting `vtysh -c`
calls, which notably includes topotests.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Modify existing MSDP topology to use test SA filtering:
- Add new multicast host (so we get two sources for same group)
- Test group only filtering
- Test source / group filtering
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
So the test script is making changes to a vpn configuration by
changing something fundamental about the vpn. This is causing
a window where routes we are interested in are:
present ( from pre-change ) then
withdrawn ( the test change causes this ) then
present ( with the new data )
The test code was trying to test for this by checking
to see if the prefix was there, but due to timing issues
it's not always there when we look for it.
Modify the test to get the vpn table version prior to
the change( as that it should not be moving around ) and
then change the test for the prefix to look for a version
that is later than the vpn's table version. Then we know
that it is *after* everything has stabilized again.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
So the test script is making changes to a vpn configuration by
changing something fundamental about the vpn. This is causing
a window where routes we are interested in are:
present ( from pre-change ) then
withdrawn ( the test change causes this ) then
present ( with the new data )
The test code was trying to test for this by checking
to see if the prefix was there, but due to timing issues
it's not always there when we look for it.
Modify the test to get the vpn table version prior to
the change( as that it should not be moving around ) and
then change the test for the prefix to look for a version
that is later than the vpn's table version. Then we know
that it is *after* everything has stabilized again.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
a) Make timers more aggressive for this test
b) Double run_and_expect time for one sub test.
These two changes cause this test to pass regularly for
me when this test used to fail regularly for me.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Under some circumstances it might happen that the session is quickly UP in the
middle of `clear bgp ...` and `shutdown`. That leads to session be UP, and
the stale routes being cleared quickly.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
These failing tests are hard to track down. Added numbering to each assert
to easily tell where the test fails.
Signed-off-by: Nathan Bahr <nbahr@atcorp.com>
When enabling "mpls ldp-sync" under "router ospf" ospfd configures
SET_FLAG(ldp_sync_info->flags, LDP_SYNC_FLAG_IF_CONFIG) so internally knowing
that the ldp-sync feature is enabled. However the flag is not cleared when
turning of the feature using "nompls ldp-sync"!
https://github.com/FRRouting/frr/issues/16375
Signed-off-by: Christian Breunig <christian@breunig.cc>
The bgp_duplicate_nexthop test installs routes with nexthop's
flags set to both DUPLICATE and FIB: this should not happen.
The DUPLICATE flag of a nexthop indicates this nexthop is already
used in the same nexthop-group, and there is no need to install it
twice in the system; having the FIB flag set indicates that the
nexthop is installed in the system. This is why both flags should
not be set on the same nexthop.
This case happens at installation time, but can also happen
at update time.
- Fix this by not setting the FIB flag value when the DUPLICATE
flag is present.
- Modify the bgp_duplicate_test to check that the FIB flag is not
present on duplicated nexthops.
- Modify the bgp_peer_type_multipath_relax test.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
During the bgp_peer_type_multipath_relax_test, the test does not
check the 'duplicate' flag value of the duplicate nexthop.
Fix this by adding the duplicate value in the expected json files.
Fixes: ee88563ac2 ("bgpd: Add 'bgp bestpath peer-type multipath-relax'")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
1. The lsp_update_data() function will check for the presence of the ISIS_TLV_DYNAMIC_HOSTNAME in the LSP, and then call isis_dynhn_insert() to add a hostname entry corresponding to the LSP ID. However, when the ISIS_TLV_DYNAMIC_HOSTNAME is not present in the LSP, the hostname entry corresponding to the LSP ID should also be deleted.
2. The command “show isis neighbor” invokes isis_adj_name() to display the System ID or hostname, but it does not check the area->dynhostname flag.
3. When the LSP expires and is removed, the corresponding hostname entry should also be deleted.
4. The TLV for LSP fragmentation will not contain the hostname and should be skipped.
Signed-off-by: zhou-run <zhou.run@h3c.com>
Since the displayed header of "show ip rip" and "show ipv6 ripng" are changed,
we should update tests of ripd and ripngd.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
In some cases (large scale) it's desired to avoid changing configurations, but
let the BGP to automatically handle ASN changes.
`auto` means the peering can be iBGP or eBGP. It will be automatically detected
and adjusted from the OPEN message.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Current code when a link is set down is to just mark the
nexthop group as not properly setup. Leaving situations
where when an interface goes down and show output is
entered we see incorrect state. This is true for anything
that would be checking those flags at that point in time.
Modify the interface down nexthop group code to notice the
nexthops appropriately ( and I mean set the appropriate flags )
and to allow a `show ip route` command to actually display
what is going on with the nexthops.
eva# show ip route 1.0.0.0
Routing entry for 1.0.0.0/32
Known via "sharp", distance 150, metric 0, best
Last update 00:00:06 ago
* 192.168.44.33, via dummy1, weight 1
* 192.168.45.33, via dummy2, weight 1
sharpd@eva:~/frr1$ sudo ip link set dummy2 down
eva# show ip route 1.0.0.0
Routing entry for 1.0.0.0/32
Known via "sharp", distance 150, metric 0, best
Last update 00:00:12 ago
* 192.168.44.33, via dummy1, weight 1
192.168.45.33, via dummy2 inactive, weight 1
Notice now that the 1.0.0.0/32 route now correctly
displays the route for the nexthop group entry.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Add a new start option "-K" to libfrr to denote a graceful start,
and use it in zebra and bgpd.
zebra will use this option to denote a planned FRR graceful restart
(supporting only bgpd currently) to wait for a route sync completion
from bgpd before cleaning up old stale routes from the FIB. An optional
timer provides an upper-bounds for this cleanup.
bgpd will use this option to denote either a planned FRR graceful
restart or a bgpd-only graceful restart, and this will drive the BGP
GR restarting router procedures.
Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
The current OSPF neighbor retransmission operates on a single per-neighbor
periodic timer that sends all LSAs on the list when it expires.
Additionally, since it skips the first retransmission of received LSAs so
that at least the retransmission interval (resulting in a delay of between
the retransmission interval and twice the interval. In environments where
the links are lossy on P2MP networks with "delay-reflood" configured (which
relies on neighbor retransmission in partial meshs), the implementation
is sub-optimal (to say the least).
This commit reimplements OSPF neighbor retransmission as follows:
1. A new data structure making use the application managed
typesafe.h doubly linked list implements an OSPF LSA
list where each node includes a timestamp.
2. The existing neighbor LS retransmission LSDB data structure
is augmented with a pointer to the list node on the LSA
list to faciliate O(1) removal when the LSA is acknowledged.
3. The neighbor LS retransmission timer is set to the expiration
timer of the LSA at the top of the list.
4. When the timer expires, LSAs are retransmitted that within
the window of the current time and a small delta (50 milli-secs
default). The LSAs that are retransmited are given an updated
retransmission time and moved to the end of the LSA list.
5. Configuration is added to set the "retransmission-window" to a
value other than 50 milliseconds.
6. Neighbor and interface LSA retransmission counters are added
to provide insight into the lossiness of the links. However,
these will increment quickly on non-fully meshed P2MP networks
with "delay-reflood" configured.
7. Added a topotest to exercise the implementation on a non-fully
meshed P2MP network with "delay-reflood" configured. The
alternative was to use existing mechanisms to instroduce loss
but these seem less determistic in a topotest.
Signed-off-by: Acee Lindem <acee@lindem.com>
The atomlist test consists of a sequence of (MT) sub-tests, from which
counters are collected and verified. TSAN doesn't know that these
counters are synchronized by way of the sub-test starting and finishing,
so it complains. Just use atomics to get rid of the warning.
(This is solely an issue with the test, not the atomlist code. There
are no warnings from that.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
TSAN warns about leaving the second thread dangling. Doesn't really
matter, but just add a pthread_join to get rid of the warning.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
seqlock_bump() used to return the value before bumping, but that's
unhelpful if you were to actually need it. I had changed it to return
the value after, but the update to the test got lost at some point.
The return value is not in fact used anywhere in FRR, so while it is
a bug, it has zero impact.
NB: yes, test_seqlock is not run, which sounds wrong. The problem here
is that (a) the test itself uses sleeps and is timing sensitive, which
would raise false positives. And (b), the test is meaningless if
executed once. It needs to be run millions of times under various
conditions (e.g. load) to catch rare races, and it needs to be run on
machines with "odd" memory models (in this case I used BE ppc32 and
ppc64 systems as test platforms.)
Fixes: 6046b690b5 ("lib/seqlock: avoid syscalls in no-waiter cases")
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The command "show isis topology" calls print_sys_hostname() to display the system ID or hostname, but it does not check the area->dynhostname flag.
Signed-off-by: zhou-run <zhou.run@h3c.com>
Add a topotest that ensures that when addpath is enabled and two
paths with same nexthop are received, they are sent to ZEBRA which
detects 'duplicate nexthop'.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Some tests may want to use the json facility of iproute2 to
dump some results.
Add an internal API in lib/topotest.py that tells whether iproute2
is json capable or not.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Taking over this development from https://github.com/FRRouting/frr/pull/14788
This commit addresses 4 issues found in the previous PR
1) FRR would accept messages from a spoke without authentication when FRR NHRP had auth configured.
2) The error indication was not being sent in network byte order
3) The debug print in nhrp_connection_authorized was not correctly printing the received password
4) The addresses portion of the mandatory part of the error indication was invalid on the wire (confirmed in wireshark)
Signed-off-by: Dave LeRoy <dleroy@labn.net>
Co-authored-by: Volodymyr Huti <volodymyr.huti@gmail.com>
The isis_tilfa_topo1 topotest is comprehensive and contains a large
amount of reference data. One problem is that, when changes occur,
updating this reference data can be difficult.
To address this problem, this commit introduces a method to
automatically regenerate the reference data by setting the `REGEN_DATA`
environment variable.
Usage:
$ REGEN_DATA=true python3 ./test_isis_tilfa_topo1.py
When `REGEN_DATA` is set, the topotest regenerates reference data
from the current run instead of comparing against existing reference
data. Note that regenerated data must be manually verified for
correctness.
This commit also simplifies the reference data by replacing all diff
files with complete JSON snapshots.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
In this topotest, steps 10-15 were added to test the IS-IS switchover
functionality. In short, two cases were tested: switchover after a
link down event and switchover after a BFD down event. Both cases
were tested in sequence on the same router, rt6. This involved the
following steps:
- Setting the SPF delay timer to 15 seconds
- Shutting down the eth-rt5 interface from the switch side
- Testing the post-switchover RIB and LIB (triggered by the link down
event)
- Testing the post-SPF RIB and LIB
- Bringing the eth-rt5 interface back up
- Configuring a BFD session between rt6 and rt5
- Shutting down the eth-rt5 interface from the switch side once again
- Testing the post-switchover RIB and LIB (triggered by the BFD down
event)
- Testing the post-SPF RIB and LIB
Since the time window to test the post-switchover RIB and LIB was too
narrow (10 seconds), these tests were having sporadic failures.
To resolve this problem, we can simplify the switchover test as follows:
- Setting the SPF delay timer to 60 seconds (not 15)
- Disabling "link-detect" on rt6's eth-rt5 interface
- Shutting down the eth-rt5 interface from the switch side
- On rt6, testing the post-switchover RIB and LIB (triggered by the
BFD down event)
- On rt5, testing the post-switchover RIB and LIB (triggered by the
link down event)
Notice how we can test both post-link-down and post-BFD-down switchover
cases simultaneously by having different "link-detect" configurations
on rt5 and rt6. Additionally, by using a larger SPF delay timer, the
time window to test the post-switchover RIB and LIB is much larger
and less prone to sporadic failures.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
There are 3 tests with OSPF, IS-IS, BGP and MPLS configured:
1. Check the status of BGP session
between North and South == Established
2. Check the connectivity with "ping South -I North"
3. Check the label on the West.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: Dmytro Shytyi <dmytro.shytyi@6wind.com>
Check that "show ip route vrf XXX json" and the JSON at key "XXX" of
"show ip route vrf all json" gives the same output.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
- `darr_free_free` to `darr_free` each element prior to `darr_free`
the array.
- `darr_free_func` to call `func` on each element prior to `darr_free`
the array.
Signed-off-by: Christian Hopps <chopps@labn.net>
Topotest relevant changes:
- add support for `timeout` arg to `cmd_*()`
- handle invalid regexp in CLI commands
- fix long interface name support
Full munet changelog:
munet: 0.14.9: add support for `timeout` arg to `cmd_*()`
munet: 0.14.8: cleanup the cleanup (kill) on launch options
munet: 0.14.7: allow multiple extra commands for shell console init
munet: 0.14.6:
- qemu: gather gcda files where munet can find them
- handle invalid regexp in CLI commands
munet: 0.14.5:
- (podman) pull missing images for containers
- fix long interface name support
- add another router example
munet: 0.14.4: mutest: add color to PASS/FAIL indicators on tty consoles
munet: 0.14.3: Add hostnet node that runs it's commands in the host network namespace.
munet: 0.14.2:
- always fail mutest tests on bad json inputs
- improve ssh-remote for common use-case of connecting to host connected devices
- fix ready-cmd for python v3.11+
munet: 0.14.1: Improved host interface support.
Signed-off-by: Christian Hopps <chopps@labn.net>
The test is done on r2. A BGP update is received on r2, and is
filtered on r2. The RIB of r2 does not have the BGP update stored,
but the ADJ-RIB-IN is yet present. To demonstrate this, if the
inbound route-map is removed, then the BGP update should be copied
from the the ADJ-RIB-IN and added to the RIB with the label
value.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
This test ensures that when r1 changes the label value, then
the new value is automatically propagated to remote peer.
This demonstrates that the ADJ-RIB-OUT to r2 has been correctly
updated.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Only output requested information to stdout so it can be
filtered and captured in shell variables etc...
Signed-off-by: Christian Hopps <chopps@labn.net>
Contains 2 testcases. The first does a basic configuration/connectivity.
The second testcase initiates a shortcut through the primary NHS,
verifies shortcut routes are installed. Primary NHS interface brought
down and verify that the shortcut is not impacted. Finally verify that
after the shortcut expires, it is able to be re-established via a backup
NHS.
Signed-off-by: dleroy <dleroy@labn.net>
Locally this test would occassionally fail for me
because the connected route the sharp route being
installed has not fully come up yet due to heavy
load and start up slowness. Add a bit of code
to look for the problem and make sure it doesn't
happen.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The IPv4 directly connected route prefix exists in both the root LSP and the root's neighbor LSP:
1. When generating vertices for directly connected route prefixes with a metric of 0 based on the root LSP, the isis_spf_preload_tent_ip_reach_cb function only generates vertices of type VTYPE_IPREACH_INTERNAL without distinguishing between area->oldmetric and area->newmetric.
2. When generating vertices for the directly connected route prefix based on the neighbor LSP, the isis_spf_process_lsp function will generate vertices of type VTYPE_IPREACH_INTERNAL and VTYPE_IPREACH_TE based on area->oldmetric and area->newmetric, where the vertex metric is the sum of the metric from the root IS to the neighbor IS and from the neighbor IS to the root IS, respectively.
If area->newmetric=1, the same directly connected route prefix will have both VTYPE_IPREACH_INTERNAL vertices with a metric of 0 and VTYPE_IPREACH_TE vertices with a non-zero metric. During route generation, the isis_spf_loop function will prioritize selecting VTYPE_IPREACH_TE vertices, leading to incorrect metrics for the directly connected routes.
Signed-off-by: zhou-run <166502045+zhou-run@users.noreply.github.com>
fix frrbot styling issues found.
1）fix frrbot styling issues found.
2）Roll back the modifications to TE.
Signed-off-by: zhou-run <166502045+zhou-run@users.noreply.github.com>
Maintain code factorization and avoid duplicating code.
Maintain code factorization and avoid duplicating code.
Signed-off-by: zhou-run <166502045+zhou-run@users.noreply.github.com>
isisd: fix frrbot styling issues found
fix frrbot styling issues found
Signed-off-by: zhou-run <166502045+zhou-run@users.noreply.github.com>
isisd: fix frrbot styling issues found
fix frrbot styling issues found
Signed-off-by: zhou-run <166502045+zhou-run@users.noreply.github.com>
isisd: Resolve compilation issues.
Resolve compilation issues.
Signed-off-by: zhou-run <166502045+zhou-run@users.noreply.github.com>
isisd: Resolve compilation issues.
Resolve compilation issues.
Signed-off-by: zhou-run <166502045+zhou-run@users.noreply.github.com>
isisd: fix frrbot styling issues found
fix frrbot styling issues found
Signed-off-by: zhou-run <166502045+zhou-run@users.noreply.github.com>
isisd: fix frrbot styling issues found
fix frrbot styling issues found
Signed-off-by: zhou-run <166502045+zhou-run@users.noreply.github.com>
isisd: Resolve compilation issues.
Resolve compilation issues.
Signed-off-by: zhou-run <166502045+zhou-run@users.noreply.github.com>
"show isis database [detail] json" returns invalid or incorrect JSON
that is difficult to parse.
Fix key with '-' characters, add booleans and null data when possible.
Deprecate the old format.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Current command (bundled two into one) is absolutely wrong.
When you configure TCP session with the source, the command thinks, that
it's a SSH session with a username.
It's much better to split this into two separate commands where it's much
easier to do the changes in the future (if more options comes in).
Yes, this is a breaking change, but there is no other proper way to overcome
this.
Bonus note how it looks, which also can lead to crashes (due to port 0x0):
```
(gdb) p *cache->tr_config.ssh_config
$11 = {host = 0x5555562f9cd0 "1.1.1.1", port = 0, bindaddr = 0x0,
username = 0x55555629ad00 "",
server_hostkey_path = 0x7ffff53667a0 <rpki_create_socket> "Uf\017\357\300H\211\345AWAVAUATSH\201", <incomplete sequence \354\230>, client_privkey_path = 0x0,
data = 0x0, new_socket = 0x51, connect_timeout = 4143762592,
password = 0x7ffff6fccca0 <main_arena+96> "\300\"0VUU"}
(gdb) p *cache->tr_config.tcp_config
$12 = {host = 0x5555562f9cd0 "1.1.1.1", port = 0x0, bindaddr = 0x0,
data = 0x55555629ad00, new_socket = 0x7ffff53667a0 <rpki_create_socket>,
connect_timeout = 0}
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Leaked route from the l3VRF are installed with the loopback as the
nexthop interface instead of the real interface.
> B>* 10.0.0.0/30 [20/0] is directly connected, lo (vrf default), weight 1, 00:21:01
Routing of packet from a L3VRF to the default L3VRF destined to a leak
prefix fails because of the default routing rules on Linux.
> 0: from all lookup local
> 1000: from all lookup [l3mdev-table]
> 32766: from all lookup main
> 32767: from all lookup default
When the packet is received in the loopback interface, the local rules
are checked without match, then the l3mdev-table says to route to the
loopback. A routing loop occurs (TTL is decreasing).
> 12:26:27.928748 ens37 In IP (tos 0x0, ttl 64, id 26402, offset 0, flags [DF], proto ICMP (1), length 84)
> 10.0.0.2 > 10.0.1.2: ICMP echo request, id 47463, seq 1, length 64
> 12:26:27.928784 red Out IP (tos 0x0, ttl 63, id 26402, offset 0, flags [DF], proto ICMP (1), length 84)
> 10.0.0.2 > 10.0.1.2: ICMP echo request, id 47463, seq 1, length 64
> 12:26:27.928797 ens38 Out IP (tos 0x0, ttl 63, id 26402, offset 0, flags [DF], proto ICMP (1), length 84)
> 10.0.0.2 > 10.0.1.2: ICMP echo request, id 47463, seq 1, length 64
Do not set the lo interface as a nexthop interface. Keep the real
interface where possible.
Fixes: db7cf73a33 ("bgpd: fix interface on leaks from redistribute connected")
Fixes: 067fbab4e4 ("bgpd: fix interface on leaks from network statement")
Fixes: 8a02d9fe1e ("bgpd: Set nh ifindex to VRF's interface, not the real")
Fixes: https://github.com/FRRouting/frr/issues/15909
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
`make check` should run w/o installing FRR first. Thus we need to embed
the yang modules otherwise mgmtd unit-test fails.
Signed-off-by: Christian Hopps <chopps@labn.net>
add some match in route map rules
add some set unset bgp access path list
add another prefix for better tests discrimination
update expected results
Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>
- Add separate get, get-config, get-state operations to query command, as
well as switching default output to JSON.
- Add an `--xml` to change the output format.
- move printss to logging.debug so output is a machine parseable result.
Signed-off-by: Christian Hopps <chopps@labn.net>
Similarly to recently fixed 'show ip[v6] prefix-list ...' - PR#15750,
json output is not valid for 'show ip[v6] access-list ... json' commands,
as it goes through all the running daemons and for each one it calls
'filter_show' creating a new json object. To aggreagate the output
and create a valid json that can later be parsed, the commands were
moved to vtysh and formatted accordingly
Signed-off-by: Piotr Suchy <piotrsuchy@proton.me>
So far, this test only convered redundant paths to one ABR, now it checks
redundant paths to redundant ABRs, covering both cases. Useful as a
regression test for #15777.
Signed-off-by: Martin Buck <mb-tmp-tvguho.pbz@gromit.dyndns.org>
It's just annoying when the linter tells to apply the formatting for the code
you didn't touch.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
When testing SNMP service on FRR, the following error message may
appear on some distros.
> # snmpwalk -v2c -c public .1.3.6 1.1.1.1 <OID>
> Bad operator (INTEGER): At line 73 in /usr/share/snmp/mibs/ietf/SNMPv2-PDU
> [..then result ..]
>
The error message is due to the /etc/snmp/snmp.conf file. By default, this
file is used by both snmp server and client side. The net-snmp MIB parsing
routing loads MIBS, to bind oids with the naming scheme used by the MIBS.
> # cat /etc/frr/snmp.conf
> [snmp]
> mibs +ALL
>
A potential fix would consist in modifying the SNMPv2-PDU.mib file: the
problem is known on ubuntu distros, as the snmp-mibs-downloader package
has not updated the SNMPv2-PDU.mib file.
The choice is done to not modify the original distro where the test is run
on. Fix the topotests by ignoring the 'SNMPv2-PDU line 73" error message, and
keep the other error messages that may happen, for instance, when an
unknown oid name value is requested.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Before the patch-set, ce1 was sending an IPv6 Link-local as global and
link-local nexthop to pe1.
Set bgp_vrf_leaking_5549_routes in accordance with the previous fixes.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Add bgp_nexthop_mp_ipv4_6 topotest to test to nexhop value with
MP-BGP IPv4 and IPv6 on IPv4 peering. The test has route-reflector,
route-server, iBGP and eBGP peers.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
- by using symlinks in the rundir (/tmp) into the source/build directory
we avoid needing to copy the *.gcda stat files into the source/build dir.
Signed-off-by: Christian Hopps <chopps@labn.net>
When a BFD down notification is received and the C-bit is set in both
directions, any ongoing graceful restart should be aborted and stale
routes removed from the RIB.
This commit updates the `bfd_bgp_cbit_topo3` topotest accordingly to
fix the expected outcomes in the `test_bfd_loss_intermediate` test.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
This commit adds the capabiity to filter OSPF neighbors using a
prefix-list with rules matching the neighbor's IP source address.
Configuration, filtering, immediate neighbor pruning, topo-tests,
and documentation are included. The command is:
ip ospf neighbor-filter <prefix-list> [A.B.C.D]
Signed-off-by: Acee Lindem <acee@lindem.com>
The Support bundle generation was/is failing in both
our upstream ci and locally. This cleans up the failures
that I am seeing such that tests now continue to run
instead of aborting the test run.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
In topotest, a given interface has only the ignore routes bit turned
on for IPv6 only, whereas topotest is expected to turn it on for all
address families.
> # show interface
> Interface r2-r3-eth2 is up, line protocol is up
> [..]
> flags: <UP,BROADCAST,RUNNING,MULTICAST>
> Ignore all v6 routes with linkdown
> Type: Ethernet
> [..]
This is because the only the 'default' ipv6 ignore sysctl is set to
1. Set also the /proc/sys/net/conf/<family>/default/ignore_routes_with_linkdown
flag, to have same behaviour for ipv4 and ipv6.
Fixes: 4958158787 ("tests: micronet: update infra")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This extends non-broadcast support to point-to-multipoint networks.
Neighbors will be explicitly configured and polled in lieu of multicast
dicovery. Toptotests and documentation updates are included.
Additionally, the ospf neighbor commands have been greatly simplified taking
advantage of DEFPY() capabilities.
The AllOSPFRouters (224.0.0.5) is still joined for non-broadcast networks
since it is joined for NBMA networks. It seems this could be removed but
it should done be in a separate commit.
Signed-off-by: Acee Lindem <acee@lindem.com>
This topotest covers the PR-15574's coverage
where a change is not to delete neighbors when
the associated peer-group's remote-as is removed.
Ticket: #3828243
Testing:
test_bgp_peer-group.py::test_bgp_peer_group
---------------------------------------------------------------------------- live log call -----------------------------------------------------------------------------
2024-03-29 18:12:22,608 INFO: r1: checking if daemons are running
2024-03-29 18:12:22,802 INFO: r2: checking if daemons are running
2024-03-29 18:12:22,911 INFO: r3: checking if daemons are running
2024-03-29 18:12:23,015 INFO: topo: Remove bgp peer-group PG1 remote-as neighbor should be retained
2024-03-29 18:12:25,605 INFO: topo: Re-add bgp peer-group PG1 remote-as neighbor should be established
----------------------------------------------------------- generated xml file: /tmp/topotests/topotests.xml -----------------------------------------------------------
========================================================================== 2 passed in 17.63s ==========================================================================
Signed-off-by: Chirag Shah <chirag@nvidia.com>
Add a new flag BGP_PATH_UNSORTED to keep track
of sorted -vs- unsorted path_info's. Add some
ability to the system to understand when that
flag is set.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
lib: don't define a `fallthrough` in c++ to avoid conflict with protobuf c++
check: add link libs required by some versions of grpc++ or it's dependent
linked libs
tests: don't fail the test due to known at exit memleaks
Signed-off-by: Christian Hopps <chopps@labn.net>
Apparently test_bgp_peer_type_multipath_relax.py does
no really need to run a `setup_vrfs` script. Looking
at the other configuration for this test there are
no vrf's in the frr configuration. So let's remove it
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Ensure that the fpm module connects to the specified listener
and then ensure that 10k routes from sharpd are installed
into the system and then are removed.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
