Donald Sharp [Sat, 26 Nov 2022 14:23:50 +0000 (09:23 -0500)]
lib: Do not log `echo PING` commands from watchfrr
Since the `echo PING` commands are from watchfrr and are sent
a whole bunch when an operator has `log commands` on the amount
of logging done is quite significant.
Renato Westphal [Thu, 24 Nov 2022 01:14:51 +0000 (22:14 -0300)]
ospf6d: fix infinite loop when adding ASBR route
Commit 8f359e1593c414322 removed a check that prevented the same route
from being added twice. In certain topologies, that change resulted in
the following infinite loop when adding an ASBR route:
ospf6_route_add
ospf6_top_brouter_hook_add
ospf6_abr_examin_brouter
ospf6_abr_examin_summary
ospf6_route_add
(repeat until stack overflow)
Revert the offending commit and update `ospf6_route_is_identical()` to
not do comparison using `memcmp()`.
Stephen Worley [Tue, 22 Nov 2022 22:18:02 +0000 (17:18 -0500)]
lib: disable vrf before terminating interfaces
We must disable the vrf before we start terminating interfaces.
On termination, we free the 'zebra_if' struct from the interface ->info
pointer. We rely on that for subsystems like vxlan for cleanup when
shutting down.
'''
==497406== Invalid read of size 8
==497406== at 0x47E70A: zebra_evpn_del (zebra_evpn.c:1103)
==497406== by 0x47F004: zebra_evpn_cleanup_all (zebra_evpn.c:1363)
==497406== by 0x4F2404: zebra_evpn_vxlan_cleanup_all (zebra_vxlan.c:1158)
==497406== by 0x4917041: hash_iterate (hash.c:267)
==497406== by 0x4F25E2: zebra_vxlan_cleanup_tables (zebra_vxlan.c:5676)
==497406== by 0x4D52EC: zebra_vrf_disable (zebra_vrf.c:209)
==497406== by 0x49A247F: vrf_disable (vrf.c:340)
==497406== by 0x49A2521: vrf_delete (vrf.c:245)
==497406== by 0x49A2E2B: vrf_terminate_single (vrf.c:533)
==497406== by 0x49A2D8F: vrf_terminate (vrf.c:561)
==497406== by 0x441240: sigint (main.c:192)
==497406== by 0x4981F6D: frr_sigevent_process (sigevent.c:130)
==497406== Address 0x6d68c68 is 200 bytes inside a block of size 272 free'd
==497406== at 0x48470E4: free (vg_replace_malloc.c:872)
==497406== by 0x4942CF0: qfree (memory.c:141)
==497406== by 0x49196A9: if_delete (if.c:293)
==497406== by 0x491C54C: if_terminate (if.c:1031)
==497406== by 0x49A2E22: vrf_terminate_single (vrf.c:532)
==497406== by 0x49A2D8F: vrf_terminate (vrf.c:561)
==497406== by 0x441240: sigint (main.c:192)
==497406== by 0x4981F6D: frr_sigevent_process (sigevent.c:130)
==497406== by 0x499A5F0: thread_fetch (thread.c:1775)
==497406== by 0x492850E: frr_run (libfrr.c:1197)
==497406== by 0x441746: main (main.c:476)
==497406== Block was alloc'd at
==497406== at 0x4849464: calloc (vg_replace_malloc.c:1328)
==497406== by 0x49429A5: qcalloc (memory.c:116)
==497406== by 0x491D971: if_new (if.c:174)
==497406== by 0x491ACC8: if_create_name (if.c:228)
==497406== by 0x491ABEB: if_get_by_name (if.c:613)
==497406== by 0x427052: netlink_interface (if_netlink.c:1178)
==497406== by 0x43BC18: netlink_parse_info (kernel_netlink.c:1188)
==497406== by 0x4266D7: interface_lookup_netlink (if_netlink.c:1288)
==497406== by 0x42B634: interface_list (if_netlink.c:2368)
==497406== by 0x4ABF83: zebra_ns_enable (zebra_ns.c:127)
==497406== by 0x4AC17E: zebra_ns_init (zebra_ns.c:216)
==497406== by 0x44166C: main (main.c:408)
'''
Signed-off-by: Stephen Worley <sworley@nvidia.com>
Ryoga Saito [Tue, 22 Nov 2022 13:57:24 +0000 (22:57 +0900)]
bgpd: Fix the other of SR locator parameters
The latest FRR's frr-reload.py is broken and we can't reload FRR
gracefully with segment routing locator configuration (if we
execute frr-reload.py, FRR will stop suddenly).
The root cause of this issue is very simple. FRR will display the
current configuration like this (the below is the result of
"show running-configuration").
pim6d, pimd: Discard (*,G) prune if WC bit is set but RPT bit is unset.
As per RFC 7761, Section 4.9.1
The RPT (or Rendezvous Point Tree) bit is a 1-bit value for use
with PIM Join/Prune messages (see Section 4.9.5.1). If the
WC bit is 1, the RPT bit MUST be 1.
ANVL conformance test case is trying to verify this and is failing.
pim6d, pimd: Discard (*,G) join if WC bit is set but RPT bit is unset.
As per RFC 7761, Section 4.9.1
The RPT (or Rendezvous Point Tree) bit is a 1-bit value for use
with PIM Join/Prune messages (see Section 4.9.5.1). If the
WC bit is 1, the RPT bit MUST be 1.
ANVL conformance test case is trying to verify this and is failing.
Louis Scalbert [Mon, 14 Nov 2022 11:49:05 +0000 (12:49 +0100)]
tests: fix bfd in isis_lfa_topo1 step24
isis_lfa_topo1 topotests regularly fails at step 24. The test expects
that the BFD session between rt1 and rt2 comes down after shutting the
link between rt1 and rt2.
Since the BFD is multihop, the BFD can get back through rt3.
Set the BFD type to single-hop.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
ospfd: Fix RFC conformance test cases 25.19 and 27.6
Steps to reproduce:
--------------------------
1. ANVL: Establish full adjacency with DUT for neighbor Rtr-0-A on DIface-0 with DUT as DR.
2. ANVL: Listen (for up to 2 * <RxmtInterval> seconds) on DIface-0.
3. DUT: Send <OSPF-LSU> packet.
4. ANVL: Verify that the received <OSPF-LSU> packet contains a Network- LSA for network N1
originated by DUT, and the LS Sequence Number is set to <InitialSequenceNumber>.
5. ANVL: Establish full adjacency with DUT for neighbor Rtr-0-B on DIface-0 with DUT as DR.
6. ANVL: Listen (for up to 2 * <RxmtInterval> seconds) on DIface-0.
7. DUT: Send <OSPF-LSU> packet.
8. ANVL: Verify that the received <OSPF-LSU> packet contains a new instance of the
Network-LSA for network N1 originated by DUT, and the LS Sequence Number
is set to (<InitialSequenceNumber> + 1).
Both the test cases were failing while verifying the initial sequence number for network LSA.
This is because currently OSPF does not reset its LSA sequence number when it is going down.
Donatas Abraitis [Fri, 18 Nov 2022 13:47:50 +0000 (15:47 +0200)]
bgpd: Allow overriding MPLS VPN next-hops via route-maps
Just do not reset next-hop for MPLS VPN routes.
Example of 172.16.255.1/32 (using extended next-hop capability):
```
pe2# sh bgp ipv4 vpn
BGP table version is 4, local router ID is 10.10.10.20, vrf id 0
Default local pref 100, local AS 65001
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Currently, in `zebra_srte_client_close_cleanup` we use the `RB_FOREACH`
macro to traverse the SR policies tree. We remove the SR policies within
the loop. Removing elements from the tree and freeing them is not safe
and causes a use-after-free crash whenever the
`zebra_srte_client_close_cleanup` is called to perform cleanup.
This commit replaces the `RB_FOREACH` macro with its variant
`RB_FOREACH_SAFE`. Unlike `RB_FOREACH`, `RB_FOREACH_SAFE` permits both
the removal of tree elements as well as freeing them from within the
loop safely.
Donatas Abraitis [Fri, 18 Nov 2022 08:36:24 +0000 (10:36 +0200)]
bgpd: Warn user only if the LL is not seriously available
LL address is assigned, but we get a warning, that it's not:
Interface: enp3s0 does not have a v6 LL address associated with it, waiting until one is created for it
```
donatas-pc# sh int enp3s0
Interface enp3s0 is up, line protocol is up
Link ups: 0 last: (never)
Link downs: 0 last: (never)
vrf: default
index 2 metric 0 mtu 1500 speed 100
flags: <UP,BROADCAST,RUNNING,MULTICAST>
v4 Multicast forwarding is on
v6 Multicast forwarding is on
Type: Ethernet
HWaddr: 18:c0:4d:96:fa:3f
inet 192.168.10.17/24
inet6 2a02:4780:abc:0:e776:6220:1e21:44b1/64
inet6 fe80::ca5d:fd0d:cd8:1bb7/64
```
Ryoga Saito [Sat, 12 Nov 2022 08:45:19 +0000 (17:45 +0900)]
bgpd: fix invalid ipv4-vpn nexthop for IPv6 peer
Given that two routers are connected each other and they have IPv6
addresses and they establish BGP peer with extended-nexthop capability
and one router tries to advertise locally-generated IPv4-VPN routes to
other router.
In this situation, bgpd on the router that tries to advertise IPv4-VPN
routes will be crashed with "invalid MP nexthop length (AFI IP6)".
This issue is happened because MP_REACH_NLRI path attribute is not
generated correctly when ipv4-vpn routes are advertised to IPv6 peer.
When IPv4 routes are leaked from VRF RIB, the nexthop of these routes
are also IPv4 address (0.0.0.0/0 or specific addresses). However,
bgp_packet_mpattr_start only covers the case of IPv6 nexthop (for IPv6
peer).
ipv4-unicast routes were not affected by this issue because the case of
IPv4 nexthop is covered in `else` block.
bgpd: authorise to select bgp self peer prefix on rr case
This commit addresses an issue that happens when using bgp
peering with a rr client, with a received prefix which is the
local ip address of the bgp session.
When using bgp ipv4 unicast session, the local prefix is
received by a peer, and finds out that the proposed prefix
and its next-hop are the same. To avoid a route loop locally,
no nexthop entry is referenced for that prefix, and the route
will not be selected.
When the received peer is a route reflector, the prefix has
to be selected, even if the route can not be installed locally.
Fixes: ("fb8ae704615c") bgpd: prevent routes loop through itself Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
projects / matthieu / frr.git / log