This change adds a topotest to test various case of OSPF multi-instance
origination including cases where the criteria route is from another
instance of OSPF, as well as the same OSPF instance (where a default
should not be originated).
Signed-off-by: Acee Lindem <acee@lindem.com>
When building for big-endian architectures, this is failing because of
long long / int casting issues, let's use a separate integer to get the
results.
This is especially important when building the Docker images for multiple arches.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Test embedded RP features:
- Embedded RP itself
- Embedded RP group list filtering
- Embedded RP limit
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
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>
Test Scenario:
RouterA and RouterB are in the same routing domain and have configured a P2P link. RouterA is configured with "is-type level-1" while RouterB is configured with "is-type level-1-2". They establish a level-1 UP neighborship. In this scenario, we expect that when RouterB's configuration is switched to "is-type level-2-only", the neighborship status on both RouterA and RouterB would be non-UP. However, RouterB still shows the neighbor as UP.
Upon receiving a P2P Hello packet, the function "process_p2p_hello" is invoked. According to the ISO/IEC 10589 protocol specification, section 8.2.5.2 a) and tables 5 and 7, if the "iih->circ_type" of the neighbor's hello packet does not match one's own "circuit->is_type," we may choose to take no action.
When establishing a neighborship for the first time, the neighbor's status can remain in the "Initializing" state. However, if the neighborship has already been established and one's own "circuit->is_type" changes, the neighbor's UP status cannot be reset. Therefore, when processing P2P Hello packets, we should be cognizant of changes in our own link adjacency type.
Topotest has identified a core issue during testing.
(gdb) bt
"#0 0xb7efe579 in __kernel_vsyscall ()
\#1 0xb79f62f7 in ?? ()
\#2 0xbf981dd0 in ?? ()
\#3 <signal handler called>
\#4 0xb79f7722 in ?? ()
\#5 0xb7ed8634 in _DYNAMIC () from /home/z15467/isis_core/usr/lib/i386-linux-gnu/frr/libfrr.so.0.0.0
\#6 0x0001003c in ?? ()
\#7 0x00010000 in ?? ()
\#8 0xb7df3322 in _frr_mtx_lock (mutex=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>) at ../lib/frr_pthread.h:255
\#9 event_timer_remain_msec (thread=0x10000) at ../lib/event.c:734
\#10 event_timer_remain_msec (thread=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>) at ../lib/event.c:727
\#11 0x004fb4aa in _send_hello_sched (circuit=<optimized out>, threadp=0x2189de0, level=1, delay=<optimized out>) at ../isisd/isis_pdu.c:2116
\#12 0x004e8dbc in isis_circuit_up (circuit=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>) at ../isisd/isis_circuit.c:734
\#13 0x004ea8f7 in isis_csm_state_change (event=<optimized out>, circuit=<optimized out>, arg=<optimized out>) at ../isisd/isis_csm.c:98
\#14 0x004ea23f in isis_circuit_circ_type_set (circuit=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>,
circ_type=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>) at ../isisd/isis_circuit.c:1578
\#15 0x0053aefa in lib_interface_isis_network_type_modify (args=<optimized out>) at ../isisd/isis_nb_config.c:4190
\#16 0xb7dbcc8d in nb_callback_modify (errmsg_len=8192, errmsg=0xbf982afc "", resource=0x2186220, dnode=<optimized out>, event=NB_EV_APPLY, nb_node=0x1fafe70, context=<optimized out>)
at ../lib/northbound.c:1550
\#17 nb_callback_configuration (context=<optimized out>, event=NB_EV_APPLY, change=<optimized out>, errmsg=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>,
errmsg_len=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>) at ../lib/northbound.c:1900
\#18 0xb7dbd646 in nb_transaction_process (errmsg_len=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>,
errmsg=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>, transaction=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>,
event=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>) at ../lib/northbound.c:2028
\#19 nb_candidate_commit_apply (transaction=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>,
save_transaction=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>,
transaction_id=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>, errmsg=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>,
errmsg_len=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>) at ../lib/northbound.c:1368
\#20 0xb7dbdd68 in nb_candidate_commit (context=..., candidate=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>,
save_transaction=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>,
comment=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>, transaction_id=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>,
errmsg=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>, errmsg_len=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>)
at ../lib/northbound.c:1401
\#21 0xb7dc0cff in nb_cli_classic_commit (vty=vty@entry=0x21d6940) at ../lib/northbound_cli.c:57
\#22 0xb7dc0f46 in nb_cli_apply_changes_internal (vty=vty@entry=0x21d6940, xpath_base=xpath_base@entry=0xbf986b7c "/frr-interface:lib/interface[name='r5-eth0']", clear_pending=clear_pending@entry=false)
at ../lib/northbound_cli.c:184
\#23 0xb7dc130b in nb_cli_apply_changes (vty=<optimized out>, xpath_base_fmt=<optimized out>) at ../lib/northbound_cli.c:240
\#24 0x00542c1d in isis_network_magic (self=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>, argc=<optimized out>,
argv=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>, no=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>,
vty=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>) at ../isisd/isis_cli.c:3101
\#25 isis_network (self=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>, vty=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>,
argc=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>, argv=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>)
at ./isisd/isis_cli_clippy.c:5499
\#26 0xb7d6d8f1 in cmd_execute_command_real (vline=vline@entry=0x219afa0, vty=vty@entry=0x21d6940, cmd=cmd@entry=0x0,
up_level=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>) at ../lib/command.c:1003
\#27 0xb7d6d9e0 in cmd_execute_command (vline=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>,
vty=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>, cmd=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>,
vtysh=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>) at ../lib/command.c:1061
\#28 0xb7d6dc60 in cmd_execute (vty=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>,
cmd=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>, matched=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>,
vtysh=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>) at ../lib/command.c:1228
\#29 0xb7dfb58a in vty_command (vty=vty@entry=0x21d6940, buf=0x21e0ff0 ' ' <repeats 12 times>, "isis network point-to-point") at ../lib/vty.c:625
\#30 0xb7dfc560 in vty_execute (vty=vty@entry=0x21d6940) at ../lib/vty.c:1388
\#31 0xb7dfdc8d in vtysh_read (thread=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>) at ../lib/vty.c:2400
\#32 0xb7df4d47 in event_call (thread=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>) at ../lib/event.c:2019
\#33 0xb7d9a831 in frr_run (master=<optimized out>) at ../lib/libfrr.c:1232
\#34 0x004e4758 in main (argc=7, argv=0xbf989a24, envp=0xbf989a44) at ../isisd/isis_main.c:354
(gdb) f 9
\#9 event_timer_remain_msec (thread=0x10000) at ../lib/event.c:734
734 ../lib/event.c: No such file or directory.
(gdb) p pthread
No symbol "pthread" in current context.
(gdb) p thread
$1 = (struct event *) 0x10000
When LAN links and P2P links share the` circuit->u` of a neighbor, if one link is no longer in use and the union is not cleared, the other link is unable to pass the non-empty check, resulting in accessing an invalid pointer. Unfortunately, for non-DIS devices in LAN links, `circuit->u.bc.run_dr_elect[x]` is essentially always 1, but in `isis_circuit_down()`,` circuit->u.bc.run_dr_elect[x] `will not be cleared because `circuit->u.bc.is_dr[x]` is always 0. Consequently, when switching to a P2P link, `isis_circuit_circ_type_set()` does not reset the link in a non-C_STATE_UP state, leading to subsequent accesses of `circuit->u.p2p.t_send_p2p_hello` resulting in a non-empty yet invalid address.
I believe that in `isis_circuit_down()`, the LAN link should unconditionally clear `circuit->u.bc.run_dr_elect[x]`.
Signed-off-by: zhou-run <zhou.run@h3c.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>
In this topotest, the route reflector advertises a route with the
aigp attribute to its client, some with the nexthop unchanged and
some with the nexthp changed. Different aigp values are sent to
the clients depending on the nexthop setting.
Signed-off-by: Enke Chen <enchen@paloaltonetworks.com>
a local logger masks the global logger and prevents errors from being
gracefully handled within topotest.py
Signed-off-by: Liam Brady <lbrady@labn.net>
Move the various destinations handling into lib/memory.c, include
"normal" logging as target, and make `ACTIVEATEXIT` properly non-error
as it was intended to be.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Add a new topotest for getting the aigp from the "igp-metric"
for a redistributed route (ospf route in the test).
Signed-off-by: Enke Chen <enchen@paloaltonetworks.com>
Update IS-IS fuzz test to match corrected output after change in the
display of IPv4 mapped IPv6 address.
The update was performed using wuschl [1] like this:
$ wuschl rebuild tests/isisd/test_fuzz_isis_tlv
$ gzip -9 tests/isisd/test_fuzz_isis_tlv_tests.h
[1] https://pypi.org/project/wuschl/
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Fix and adjust the topotest post the fix for route selection with
AIGP.
When there are multiple IGP domains (OSPF in this case), the nexthop
for a BGP route with the AIGP attribute must be resolved in its own
IGP domain.
The changes in r2/bgpd.conf and r3/bgpd.conf are needed as incorrect
IGP metrics are received from NHT for the recursive nexthops. Once
the issue is resolved, the changes can be reverted.
Signed-off-by: Enke Chen <enchen@paloaltonetworks.com>
AS 65000 | AS 65001
|
RR |
| |
R1 --- | --- R2
|
When r1 peer is an iBGP route reflector client of rr and r2 peer is a
eBGP neighbor of rr, and all three routers shares the same network, r2
receives announcements coming from r1 with a IPv6 link-local nexthop
from rr. This is incorrect as r2 should send traffic to r1 without
involving rr.
Do not send an IPv6 link-local nexthop if the originating peer is a
route-reflector client.
Link: https://github.com/FRRouting/frr/pull/16219#issuecomment-2397425505
Link: https://github.com/FRRouting/frr/pull/17037#discussion_r1792529683
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Add test to check BMP in VRF.
Note that the following configuration works with interface r1-eth0
towards 192.0.2.10 (BMP collector) in the default VRF but not in vrf1.
> router bgp 65501 vrf vrf1
> bmp targets bmp1
> bmp connect 192.0.2.10 port 1789 min-retry 100 max-retry 10000
Also, for some reasons, the test works even without "bgpd: bmp loc-rib
peer up/down for vrfs" commit.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Unset enforce-first-as on r3 of bgp_route_server_client to enable the
reception of routes on this router.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Rework bgp_route_server_client in a more standard form in order to
facilitate the next commut changes. Cosmetic change.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Mgmtd makes use of libyang's internal ietf-yang-library module to add
support for said module to FRR management. Previously, mgmtd was loading
this module explicitly; however, that required that libyang's
`ietf-yang-library.yang` module definition file be co-located with FRR's
yang files so that it (and ietf-datastore.yang) would be found when
searched for by libyang using FRRs search path. This isn't always the
case depending on how the user compiles and installs libyang so mgmtd
was failing to run in some cases.
Instead of doing it the above way we simply tell libyang to load it's
internal version of ietf-yang-library when we initialize the libyang
context.
This required adding a boolean to a couple of the init functions which
is why so many files are touched (although all the changes are minimal).
Signed-off-by: Christian Hopps <chopps@labn.net>
It's replaced and simplified by c3fd1e9520c619babb3004cea6df622ca67b0dfa.
JSON topo is just horrible to debug.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Currently bgp multipath has these properties:
a) mp_info may or may not be on a single path, based
upon path perturbations in the past.
b) mp_info->count started counting at 0( meaning 1 ). As that the
bestpath path_info was never included in the count
c) The first mp_info in the list held the multipath data associated
with the multipath. As such if you were at any other node that data
was not filled in.
d) As such the mp_info's that are not first on the list basically
were just pointers to the corresponding bgp_path_info that was in
the multipath.
e) On bestpath calculation, a linklist(struct linklist *) of bgp_path_info's was
created.
f) This linklist was passed in to a comparison function that took the
old mpinfo list and compared it item by item to the linklist and
doing magic to figure out how to create a new mp_info list.
g) the old mp_info and the link list had to be memory managed and
freed up.
h) BGP_PATH_MULTIPATH is only set on non bestpath nodes in the
multipath.
This is really complicated. Let's change the algorithm to this:
a) When running bestpath, mark a bgp_path_info node that could be in the ecmp path as
BGP_PATH_MULTIPATH_NEW.
b) When running multipath, just walk the list of bgp_path_info's and if
it has BGP_PATH_MULTIPATH_NEW on it, decide if it is in BGP_MULTIPATH.
If we run out of space to put in the ecmp, clear the flag on the rest.
c) Clean up the counting of sometimes adding 1 to the mpath count.
d) Only allocate a mpath_info node for the bestpath. Clean it up
when done with it.
e) remove the unneeded list management associated with the linklist and
the mp_list.
This greatly simplifies multipath computation for bgp and reduces memory
load for large scale deployments.
2 full feeds in work_queue_run prior:
0 56367.471 1123 50193 493695 50362 493791 0 0 0 TE work_queue_run
BGP multipath info : 1941844 48 110780992 1941844 110780992
2 full feeds in work_queue_run after change:
1 52924.931 1296 40837 465968 41025 487390 0 0 1 TE work_queue_run
BGP multipath info : 970860 32 38836880 970866 38837120
Aproximately 4 seconds of saved cpu time for convergence and ~75 mb
smaller run time.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
With AutoRP discovery running by default, that adds a new
IGMP group that needs to be accounted for in IGMP output.
For pim.py
The clear IGMP interfaces function is in a broken state. It was
already ignoring any errors and returned true always, but with
the addition of the AutoRP discovery group, you could end up
with a different group order in the json which would cause a key
error making the test fail. For now I just added a check to
avoid the key error.
Signed-off-by: Nathan Bahr <nbahr@atcorp.com>
With AutoRP discovery running by default, that adds a new
IGMP group that needs to be accounted for in IGMP output.
For multicast_pim_sm_topo3:
Ignore the total group number as it is unnecessary for the test.
Signed-off-by: Nathan Bahr <nbahr@atcorp.com>
Uses hardcoded sample AutoRP packets injected in to test
message parsing and proper application of AutoRP learned
RP info. Tests mix of AutoRP and static RP's.
Signed-off-by: Nathan Bahr <nbahr@atcorp.com>
Range is wrong. We want values 1 and 2 but we only test 1.
> >>> for i in range(1, 2):
> ... print(i)
> ...
> 1
Fixes: abd2a1ff3f ("tests: Test some basic kernel <-> zebra interactions")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
There are no tests that ensured that turning off then on
v4 and v6 forwarding actually worked. This does so.
This was found via looking at the code coverage.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
None of the bgp dump code was even tested. Add a bit
of basic stuff that it at least generates a dump file.
This can be extended at a future time.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
In ospf_multi_vrf_bgp_route_leak, the admin distance for the
redistributed ospf route should be 110, and should remain as 110 after
it's imported into another vrf, and then downloaded to zebra.
Signed-off-by: Enke Chen <enchen@paloaltonetworks.com>
Apparently logger.warn is being deprecated. So let's
switch over to logger.warning. Clearly it's better
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
If the developer pass way too low timers, we end up with most likely false-positive
situations for random tests under a high load of the system.
It would be better to fallback to the minimum default values for such a cases.
E.g.:
```
WARNING: topo: Waiting time is too small (count=1, wait=0.5), using default values (count=20, wait=3)
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
No need to do 'no set as-path exclude' to replace the current rule by
another. The code is supposed to support the replacement.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Check that the following does not cause a crash:
> route-map r2 permit 6
> set as-path exclude 65555
> set as-path exclude as-path-access-list NON-EXISTING
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
This allows retrying functions to possibly change their logging level
for diagnostics.
In order to maintain backward compatibility with this longstanding
function we catch the specific exception of it not being handled by the
retrying function and call again w/o the argument.
Signed-off-by: Christian Hopps <chopps@labn.net>
Enabe/fix using a munet.yaml config file for topology configuration.
Easier test writing.
This also uses the standard `frrinit.sh` to launch and teardown
FRR, so we actually test what most users use.
Signed-off-by: Christian Hopps <chopps@labn.net>
When trying to track down a MTYPE_TMP memory leak
it's harder to search for it when you happen to
have some usage of ttable_dump. Let's just give
it it's own memory type so that we can avoid
confusion in the future.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Fully check the NHRP convergence after setting nhs1 down. Otherwise the
ping may pass because the previous shortcut is still present.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
After setting down nhs1, the test is checking that nhc1 routing table
matches routes in nhc1/nhrp_route.json. It is incorrect because it
checks that the NHRP route to nhs1 is still present but it should have
disappeared.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
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>
