zhou-run [Mon, 17 Jun 2024 08:45:09 +0000 (16:45 +0800)]
isisd: After the router switches IS-IS type several times, the neighbor adjacency cannot be established.
1. Router A is configured with "is-type level-1-2", while Router B is configured with "is-type level-1". Only level 1 neighbor entries are present on Router A.
2. After configuring Router B with "is-type level-2-only", both level 1 and level 2 neighbor entries exist on Router A. The state of these entries is UP, and the level 1 neighbor entry is currently aging.
3. Before the level 1 neighbor entry on Router A ages out, configuring Router B with "is-type level-1", both level 1 and level 2 neighbor entries exist on Router A. The level 2 neighbor entry is UP and will age out normally. However, the level 1 neighbor entry remains in the Initializing state, preventing the establishment of level 1 neighbor adjacency between Router A and Router B.
When the adjacency type of the link is switched in function isis_circuit_is_type_set, the function circuit_resign_level() is called to delete the old level's circuit->u.bc.lan_neighs linked list. If the old level is not level-1-2, the function circuit_commence_level() is called to create a new level's circuit->u.bc.lan_neighs linked list, but neither of these functions handle the circuit->u.bc.adjdb linked list. This leads to a situation where upon receiving hello packets again before the circuit->u.bc.adjdb linked list entries age out, the circuit->u.bc.lan_neighs linked list is not constructed based on the circuit->u.bc.adjdb linked list. As a result, the hello packets sent will consistently lack an SNPA, causing the neighbor to remain unable to establish an adjacency upon receiving the hello packets.
Donald Sharp [Thu, 13 Jun 2024 19:30:00 +0000 (15:30 -0400)]
zebra: Use built in data structure counter
Instead of keeping a counter that is independent
of the queue's data structure. Just use the queue's
built-in counter. Ensure that it's pthread safe by
keeping it wrapped inside the mutex for adding/deleting
to the queue.
Direct leak of 1008 byte(s) in 14 object(s) allocated from:
0 0x7f9ea0dc7d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
1 0x7f9ea034d51f in json_object_new_object (/lib/x86_64-linux-gnu/libjson-c.so.3+0x351f)
2 0x564b56d0fed6 in show_ip_ospf_interface_common ospfd/ospf_vty.c:4011
3 0x564b56d1068c in show_ip_ospf_interface ospfd/ospf_vty.c:4285
4 0x7f9ea06fe1c0 in cmd_execute_command_real lib/command.c:1002
5 0x7f9ea06fe684 in cmd_execute_command lib/command.c:1060
6 0x7f9ea06feb03 in cmd_execute lib/command.c:1227
7 0x7f9ea08415b2 in vty_command lib/vty.c:616
8 0x7f9ea0841a5d in vty_execute lib/vty.c:1379
9 0x7f9ea084b367 in vtysh_read lib/vty.c:2374
10 0x7f9ea08350cd in event_call lib/event.c:2011
11 0x7f9ea0764386 in frr_run lib/libfrr.c:1217
12 0x564b56c25b18 in main ospfd/ospf_main.c:295
13 0x7f9e9fd5bc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 7168 byte(s) in 14 object(s) allocated from:
0 0x7f9ea0dc7d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
1 0x7f9ea0350fa4 in lh_table_new (/lib/x86_64-linux-gnu/libjson-c.so.3+0x6fa4)
Indirect leak of 1232 byte(s) in 14 object(s) allocated from:
0 0x7f9ea0dc7d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
1 0x7f9ea0350f82 in lh_table_new (/lib/x86_64-linux-gnu/libjson-c.so.3+0x6f82)
SUMMARY: AddressSanitizer: 9408 byte(s) leaked in 42 allocation(s).
***********************************************************************************
```
Fixes: e24ff4c275f0729f75be9f68d08be80ac1e0ec56 ("ospfd: Drop `interfaceIp` from `show ip ospf neigh json") Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Error type: validation
Error description: YANG error(s):
Path: Data location "/frr-interface:lib/interface[name='x']/frr-isisd:isis/metric/level-1".
Error: Must condition ". < 64 or /frr-isisd:isis/instance[area-tag = current()/../../area-tag]/metric-style = 'wide' or not(/frr-isisd:isis/instance[area-tag = current()/../../area-tag]/metric-style)" not satisfied.
Path: Data location "/frr-interface:lib/interface[name='x']/frr-isisd:isis/metric/level-2".
Error: Must condition ". < 64 or /frr-isisd:isis/instance[area-tag = current()/../../area-tag]/metric-style = 'wide' or not(/frr-isisd:isis/instance[area-tag = current()/../../area-tag]/metric-style)" not satisfied
```
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>
Philippe Guibert [Mon, 10 Jun 2024 06:38:22 +0000 (08:38 +0200)]
topotests: add API to detect if iproute2 is json capable
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>
Philippe Guibert [Thu, 30 May 2024 13:47:11 +0000 (15:47 +0200)]
bgpd: fix do not skip paths with same nexthop
Under a setup where two BGP prefixes are available from multiple sources,
if one of the two prefixes is recursive over the other BGP prefix, then
it will not be considered as multipath. The below output shows the two
prefixes 192.0.2.24/32 and 192.0.2.21/32. The 192.0.2.[5,6,8] are the
known IP addresses visible from the IGP.
> # show bgp ipv4 192.0.2.24/32
> *>i 192.0.2.24/32 192.0.2.21 0 100 0 i
> * i 192.0.2.21 0 100 0 i
> * i 192.0.2.21 0 100 0 i
> # show bgp ipv4 192.0.2.21/32
> *>i 192.0.2.21/32 192.0.2.5 0 100 0 i
> *=i 192.0.2.6 0 100 0 i
> *=i 192.0.2.8 0 100 0 i
The bgp best selection algorithm refuses to consider the paths to
'192.0.2.24/32' as multipath, whereas the BGP paths which use the
BGP peer as nexthop are considered multipath.
> ... has the same nexthop as the bestpath, skip it ...
Previously, this condition has been added to prevent ZEBRA from
installing routes with same nexthop:
> Here you can see the two paths with nexthop 210.2.2.2
> superm-redxp-05# show ip route 2.23.24.192/28
> Routing entry for 2.23.24.192/28
> Known via "bgp", distance 20, metric 0, best
> Last update 00:32:12 ago
> * 210.2.2.2, via swp3
> * 210.2.0.2, via swp1
> * 210.2.1.2, via swp2
> * 210.2.2.2, via swp3
> [..]
But today, ZEBRA knows how to handle it. When receiving incoming routes,
nexthop groups are used. At creation, duplicated nexthops are
identified, and will not be installed. The below output illustrate the
duplicate paths to 172.16.0.200 received by an other peer.
> r1# show ip route 172.18.1.100 nexthop-group
> Routing entry for 172.18.1.100/32
> Known via "bgp", distance 200, metric 0, best
> Last update 00:03:03 ago
> Nexthop Group ID: 75757580
> 172.16.0.200 (recursive), weight 1
> * 172.31.0.3, via r1-eth1, label 16055, weight 1
> * 172.31.2.4, via r1-eth2, label 16055, weight 1
> * 172.31.0.3, via r1-eth1, label 16006, weight 1
> * 172.31.2.4, via r1-eth2, label 16006, weight 1
> * 172.31.8.7, via r1-eth4, label 16008, weight 1
> 172.16.0.200 (duplicate nexthop removed) (recursive), weight 1
> 172.31.0.3, via r1-eth1 (duplicate nexthop removed), label 16055, weight 1
> 172.31.2.4, via r1-eth2 (duplicate nexthop removed), label 16055, weight 1
> 172.31.0.3, via r1-eth1 (duplicate nexthop removed), label 16006, weight 1
> 172.31.2.4, via r1-eth2 (duplicate nexthop removed), label 16006, weight 1
> 172.31.8.7, via r1-eth4 (duplicate nexthop removed), label 16008, weight 1
Fix this by proposing to let ZEBRA handle this duplicate decision.
Fixes: 7dc9d4e4e360 ("bgp may add multiple path entries with the same nexthop") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Dave LeRoy [Wed, 5 Jun 2024 19:10:11 +0000 (12:10 -0700)]
nhrpd: add cisco-authentication password support
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>
Renato Westphal [Fri, 7 Jun 2024 15:03:17 +0000 (12:03 -0300)]
tests: introduce method to update reference data in isis_tilfa_topo1
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.
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.
Renato Westphal [Fri, 7 Jun 2024 13:41:38 +0000 (10:41 -0300)]
tests: rework isis_tilfa_topo1 to fix timing issues
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.
Christian Hopps [Sat, 8 Jun 2024 19:37:47 +0000 (15:37 -0400)]
ci: do apt-get update before installing required modules
- Use `uname -r` to also install specific module versions since
with github runners the running kernel can become out-dated with
the deployed packages.
Christian Hopps [Thu, 6 Jun 2024 18:08:00 +0000 (14:08 -0400)]
mgmtd: add empty notif xpath map for completeness
New back-end clients may need to add notification static allocations so
we should have it available for those users, rather than requiring the
new user delve into the mgmtd infra and modify it themselves.
Louis Scalbert [Fri, 24 May 2024 14:34:23 +0000 (16:34 +0200)]
zebra: fix show route memory consumption
When displaying a route table in JSON, a table JSON object is storing
all the prefix JSON objects containing the prefix information. This
results in excessive memory allocation for JSON objects, potentially
leading to an out-of-memory error on the machine with large routing
tables.
To Fix the memory consumption issue for the "show ip[v6] route [vrf XX]
json" command, display the prefixes one by one and free the memory of
each JSON object after it has been displayed.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Louis Scalbert [Fri, 24 May 2024 15:06:59 +0000 (17:06 +0200)]
zebra: fix show route vrf all memory consumption
0e2fc3d67f ("vtysh, zebra: Fix malformed json output for multiple vrfs
in command 'show ip route vrf all json'") has been reverted in the
previous commit. Although the fix was correct, it was consuming too muca
memory when displaying large route tables.
A root JSON object was storing all the JSON objects containing the route
tables, each containing their respective prefixes in JSON objects. This
resulted in excessive memory allocation for JSON objects, potentially
leading to an out-of-memory error on the machine.
To Fix the memory consumption issue for the "show ip[v6] route vrf all
json" command, display the tables one by one and free the memory of each
JSON object after it has been displayed.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Christian Hopps [Tue, 4 Jun 2024 09:43:49 +0000 (05:43 -0400)]
lib: darr: add free with element cleanup functions
- `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.
Rajesh Girada [Mon, 20 May 2024 16:34:41 +0000 (09:34 -0700)]
ospf6d: Handling Topo Change in GR-HELPER mode for max-age lsas
Description:
OSPF6 GR HELPER router should consider as TOPOCHANGE when
it receives lsas with max age and should exit from Helper.
But, it is not exiting from helper because this max age lsa is
considered as duplicated lsa since the sender uses same seq
number for max age lsa from the previous lsa update.
Currently, topo change is not considered for duplicated lsas.
So removed the duplicated check when validating TOPOCHNAGE.
Christian Hopps [Thu, 6 Jun 2024 08:50:05 +0000 (08:50 +0000)]
tests: munet: update to version 0.14.9
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.
Dave LeRoy [Wed, 5 Jun 2024 17:22:57 +0000 (10:22 -0700)]
nhrpd: cleans up shortcut cache entries on termination
nhrp_shortcut_terminate() previously was just freeing the associated AFI shortcut
RIBs and not addressing existing shortcut cache entries. This cause a use after
free issue in vrf_terminate() later in the terminate sequence
NHRP: Received signal 7 at 1717516286 (si_addr 0x1955d, PC 0x7098786912c0); aborting...
NHRP: zlog_signal+0xf5 709878ad12557fff3d992eb0 /usr/lib/frr/libfrr.so.0 (mapped at 0x709878a00000)
NHRP: core_handler+0xb5 709878b0db857fff3d992ff0 /usr/lib/frr/libfrr.so.0 (mapped at 0x709878a00000)
NHRP: __sigaction+0x50 7098786425207fff3d993140 /lib/x86_64-linux-gnu/libc.so.6 (mapped at 0x709878600000)
NHRP: ---- signal ----
NHRP: __lll_lock_wait_private+0x90 7098786912c07fff3d9936d8 /lib/x86_64-linux-gnu/libc.so.6 (mapped at 0x709878600000)
NHRP: pthread_mutex_lock+0x112 7098786980027fff3d9936e0 /lib/x86_64-linux-gnu/libc.so.6 (mapped at 0x709878600000)
NHRP: _event_add_read_write+0x63 709878b1f4237fff3d993700 /usr/lib/frr/libfrr.so.0 (mapped at 0x709878a00000)
NHRP: zclient_send_message+0xd4 709878b376147fff3d993770 /usr/lib/frr/libfrr.so.0 (mapped at 0x709878a00000)
NHRP: nhrp_route_announce+0x1ad 5ab34d63d39d7fff3d993790 /usr/lib/frr/nhrpd (mapped at 0x5ab34d621000)
NHRP: nhrp_shortcut_cache_notify+0xd8 5ab34d63e7587fff3d99d4e0 /usr/lib/frr/nhrpd (mapped at 0x5ab34d621000)
NHRP: nhrp_cache_free+0x165 5ab34d632f257fff3d99d510 /usr/lib/frr/nhrpd (mapped at 0x5ab34d621000)
NHRP: hash_iterate+0x4d 709878ab949d7fff3d99d540 /usr/lib/frr/libfrr.so.0 (mapped at 0x709878a00000)
NHRP: nhrp_cache_interface_del+0x37 5ab34d633eb77fff3d99d580 /usr/lib/frr/nhrpd (mapped at 0x5ab34d621000)
NHRP: nhrp_if_delete_hook+0x26 5ab34d6350d67fff3d99d5a0 /usr/lib/frr/nhrpd (mapped at 0x5ab34d621000)
NHRP: if_delete_retain+0x3d 709878abcd1d7fff3d99d5c0 /usr/lib/frr/libfrr.so.0 (mapped at 0x709878a00000)
NHRP: if_delete+0x4c 709878abd87c7fff3d99d600 /usr/lib/frr/libfrr.so.0 (mapped at 0x709878a00000)
NHRP: if_terminate+0x53 709878abda837fff3d99d630 /usr/lib/frr/libfrr.so.0 (mapped at 0x709878a00000)
NHRP: vrf_terminate_single+0x24 709878b23c747fff3d99d670 /usr/lib/frr/libfrr.so.0 (mapped at 0x709878a00000)
NHRP: nhrp_request_stop+0x34 5ab34d6368447fff3d99d690 /usr/lib/frr/nhrpd (mapped at 0x5ab34d621000)
NHRP: frr_sigevent_process+0x53 709878b0df537fff3d99d6a0 /usr/lib/frr/libfrr.so.0 (mapped at 0x709878a00000)
NHRP: event_fetch+0x6c5 709878b204057fff3d99d6c0 /usr/lib/frr/libfrr.so.0 (mapped at 0x709878a00000)
NHRP: frr_run+0xd3 709878ac81637fff3d99d840 /usr/lib/frr/libfrr.so.0 (mapped at 0x709878a00000)
NHRP: main+0x195 5ab34d6319157fff3d99d960 /usr/lib/frr/nhrpd (mapped at 0x5ab34d621000)
NHRP: __libc_init_first+0x90 709878629d907fff3d99d980 /lib/x86_64-linux-gnu/libc.so.6 (mapped at 0x709878600000)
NHRP: __libc_start_main+0x80 709878629e407fff3d99da20 /lib/x86_64-linux-gnu/libc.so.6 (mapped at 0x709878600000)
NHRP: _start+0x25 5ab34d631b657fff3d99da70 /usr/lib/frr/nhrpd (mapped at 0x5ab34d621000)
Philippe Guibert [Fri, 13 Jan 2023 14:59:52 +0000 (15:59 +0100)]
bgpd: fix labels in adj-rib-in
In a BGP L3VPN context using ADJ-RIB-IN (ie. enabled with
'soft-reconfiguration inbound'), after applying a deny route-map and
removing it, the remote MPLS label information is lost. As a result, BGP
is unable to re-install the related routes in the RIB.
Philippe Guibert [Fri, 24 Feb 2023 10:53:46 +0000 (11:53 +0100)]
topotests: add bgp test to check the ADJ-RIB-IN label value
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>
Philippe Guibert [Fri, 24 Feb 2023 10:22:14 +0000 (11:22 +0100)]
topotests: add bgp test to check the ADJ-RIB-OUT label value
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>
Louis Scalbert [Mon, 5 Feb 2024 16:05:20 +0000 (17:05 +0100)]
bgpd: check and set extra num_labels
The handling of MPLS labels in BGP faces an issue due to the way labels
are stored in memory. They are stored in bgp_path_info but not in
bgp_adj_in and bgp_adj_out structures. As a consequence, some
configuration changes result in losing labels or even a bgpd crash. For
example, when retrieving routes from the Adj-RIB-in table
("soft-reconfiguration inbound" enabled), labels are missing.
bgp_path_info stores the MPLS labels, as shown below:
To solve those issues, a solution would be to set label data to the
bgp_adj_in and bgp_adj_out structures in addition to the
bgp_path_info_extra structure. The idea is to reference a common label
pointer in all these three structures. And to store the data in a hash
list in order to save memory.
However, an issue in the code prevents us from setting clean data
without a rework. The extra->num_labels field, which is intended to
indicate the number of labels in extra->label[], is not reliably checked
or set. The code often incorrectly assumes that if the extra pointer is
present, then a label must also be present, leading to direct access to
extra->label[] without verifying extra->num_labels. This assumption
usually works because extra->label[0] is set to MPLS_INVALID_LABEL when
a new bgp_path_info_extra is created, but it is technically incorrect.
Cleanup the label code by setting num_labels each time values are set in
extra->label[] and checking extra->num_labels before accessing the
labels.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
TL;DR; When we configure `advertise-all-vni` (in this case), a new BGP instance
is created with the name vrf100, and ASN 50. Next, when we create
`router bgp 100 vrf vrf100`, we look for the BGP instance with the same name
and we found it, but ASNs are different 50 vs. 100.
Every such a new auto created instance is flagged with BGP_VRF_AUTO.
After the fix:
```
router bgp 50
!
address-family l2vpn evpn
advertise-all-vni
exit-address-family
exit
!
router bgp 100 vrf vrf100
exit
!
end
donatas.net(config)# router bgp 51
BGP is already running; AS is 50
donatas.net(config)# router bgp 50
donatas.net(config-router)# router bgp 101 vrf vrf100
BGP is already running; AS is 100
donatas.net(config)# router bgp 100 vrf vrf100
donatas.net(config-router)#
```
projects / matthieu / frr.git / log