Acee Lindem [Wed, 22 Jan 2025 20:32:50 +0000 (20:32 +0000)]
tests: OSPF topotest for next-hop pruning
OSPF topotest to test OSPF next-hop pruning on installation
into zebra routing table. Also fix multicast_pim_dr_nondr_test
topotest which had a duplicate OSPF route in the results.
Chirag Shah [Tue, 7 Jan 2025 02:57:54 +0000 (18:57 -0800)]
bgpd: fix evpn path info get api
EVPN imported routes AF is not AF_EVPN, in that case
the path info extra with EVPN is nver created.
In order to create evpn info under path extra, define
new api which does not specifically check for AF_EVPN
afi type.
Philippe Guibert [Tue, 21 Jan 2025 14:34:13 +0000 (15:34 +0100)]
bgpd: fix do not send twice peer up/down messages
With recent BMP code, on a standard BMP config, the peer up and peer
down messages related to a BGP peer are sent twice, whereas they should
be send only once.
Fix this by better controlling the condition.
Fixes: f8a693311145 ("bgpd: bmp, handle imported bgp instances for peer up/down events") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Krishnasamy R [Tue, 21 Jan 2025 09:06:53 +0000 (01:06 -0800)]
bgpd: Fix for local interface MAC cache issue in 'bgp mac hash' table
Issue:
During FRR restart, we fail to add some of the local interface's MAC
to the 'bgp mac hash'. Not having local MAC in the hash table can cause
lookup issues while receiving EVPN RT-2.
Currently, we have code to add local MAC(bgp_mac_add_mac_entry) while handling
interface add/up events in BGP(bgp_ifp_up/bgp_ifp_create). But the code
'bgp_mac_add_mac_entry' in bgp_ifp_create is not getting invoked as it
is placed under a specific check(vrf->bgp link check).
Fix:
We can skip this check 'vrf->bgp link existence' as the tenant VRF might
not have BGP instance but still we want to cache the tenant VRF local
MACs. So keeping this check in bgp_ifp_create inline with bgp_ifp_up.
Philippe Guibert [Fri, 17 Jan 2025 16:28:00 +0000 (17:28 +0100)]
bgpd: fix display json value of interface for BGP unnumbered
The 'show bgp ipv[4,6] json' command does not display the interface
value of the nexthop, when BGP sessions are unnumbered, whereas the
non json output displays it correctly. The below example indicates
'r1-eth0' wheras in json, the value is not displayed.
> r1# show bgp ipv4
> BGP table version is 3, local router ID is 10.254.254.1, vrf id 0
> Default local pref 100, local AS 101
> Status codes: s suppressed, d damped, h history, u unsorted, * 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
>
> Network Next Hop Metric LocPrf Weight Path
> *> 10.254.254.1/32 0.0.0.0 0 32768 ?
> *> 10.254.254.2/32 r1-eth0 0 0 102 ?
>
> Displayed 2 routes and 2 total paths
Fix this by adding an 'interface' keyword in the json attributes.
Christian Hopps [Sat, 18 Jan 2025 23:39:32 +0000 (23:39 +0000)]
lib: fix dnode_create to use correct libyang function.
The previous use of `lyd_new_path()` returns the first node created, rather
than the xpath target node. The code is lucky in the sense that it is
normally only creating a single node rather than a branch. Fix this to
use `lyd_new_path2()` which returns the target node to actually implement
the semantics expected by callers of `dnode_create()` (i.e., returning the
newly created target node).
Drop redundant function (duplicate), and reset counters for r2 instead of r1.
We check received capabilities on r2, hence we need to flush the counters on r2 too.
Fixes: d1cfd730601e5063d126ca1e78be5695fe909a77 ("tests: Check if ENHE capability can be handled dynamically") Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Christian Hopps [Thu, 16 Jan 2025 04:14:03 +0000 (04:14 +0000)]
lib: yang: add yang_parse_data function
This is similar to notify and RPC parsers, but this is for normal datastore
data. This is initially used in handling datastore notifications being sent to
another backend client[s].
Yuqing Zhao [Mon, 13 Jan 2025 10:02:23 +0000 (11:02 +0100)]
staticd: Add infrastructure for SRv6
This commit adds datastructures and helper functions required to support SRv6 in staticd.
* List of locators
* List of SIDs
* Data structure to represent an SRv6 SID
* Functions to allocate/deallocate an SRv6 SID
* Functions to allocate, deallocate and lookup a locator
* Function to initialize/Cleanup SRv6
The frr-reload script currently deletes configurations
line-by-line under an interface context, if the interface was removed.
This approach fails when the interface has already been removed from the system.
This change enables whole interface removal using a single command
(no interface <interface-name>), simplifying the reload process and
reducing reload errors.
Igor Ryzhov [Fri, 27 Dec 2024 19:33:39 +0000 (21:33 +0200)]
lib: introduce global -w option for VRF netns backend
Current -n option is only for zebra and mgmtd. All other daemons receive
the VRF backend configuration from zebra upon connection to it. This
leads to a potential race condition - daemons need to know the backend
before they start reading their config, but they can be not connected to
zebra yet at this point. As the VRF backend cannot change during runtime,
let's introduce a new global -w option for setting netns backend, to
make sure that all daemons know their VRF backend immediately after
start.
The reason for introducing a new option instead of making -n global is
that ospfd already uses -n for another purposes.
Igor Ryzhov [Fri, 27 Dec 2024 13:10:27 +0000 (15:10 +0200)]
lib, zebra: move ns context intialization to zebra
vrf->ns_ctxt is only ever used in zebra, so move its initialization to
zebra's callback. Ideally this pointer shouldn't even be a part of
library's vrf struct, and moved to zebra-specific struct, but this is
the first step.
Igor Ryzhov [Thu, 26 Dec 2024 21:08:21 +0000 (23:08 +0200)]
lib: remove VRF_BACKEND_UNKNOWN
The backend type cannot be unknown. It is configured to VRF_LITE by
default in zebra anyway, so just init to VRF_LITE in the lib and remove
the UNKNOWN type.
Donald Sharp [Tue, 14 Jan 2025 21:23:40 +0000 (16:23 -0500)]
zebra: On Nexthop install failure don't set Installation failed
Currently FRR when installing a nexthop group, the installation can fail.
The assumption with the code was that the current nexthop group was
not already installed. This leaves a problem state where if the
users of the nexthop group are removed, the nexthop group will be
removed possibly leaving a orphaned nexthop group in the data plane.
FRR on a nexthop group installation does not actually know the status
of the nexthop group in the kernel. It's possible that a earlier
version of the nexthop group is left in play. It's possible that
there is no nexthop group in the kernel at all. Leaving the
Installed flag alone allows upon Zebra removing the nexthop
group when it is removed from zebra.
Donatas Abraitis [Tue, 14 Jan 2025 16:57:45 +0000 (18:57 +0200)]
bgpd: Handle ENHE capability via dynamic capability
FRR supports dynamic capability which is useful to exchange the capabilities
without tearing down the session. ENHE capability was missed to be included
handling via dynamic capability. Let's add it too.
This was missed and asked in Slack that it would be useful.
Donald Sharp [Tue, 14 Jan 2025 20:12:32 +0000 (15:12 -0500)]
zebra: Nexthops need to be ACTIVE in some cases
Currently if you have an interface down event, Zebra
sets the nexthop(s) as !ACTIVE that use it. On
interface up events the singleton nexthops are not being
set as ACTIVE. Due to timing events it is sometimes
possible to end up with a route that is using a singleton
Change singleton nexthops to set the nexthop to ACTIVE.
This will allow the nexthop to be reinstalled appropriately
as well.
I was able to easily reproduce this using sharpd since
it does not attempt to reinstall the routes when a interface
goes up/down.
Before:
D>* 10.0.0.0/32 [150/0] via 192.168.102.34, dummy2, weight 1, 00:00:01
sharpd@eva ~/frr5 (master)> sudo ip link set dummy2 down ; sudo ip link set dummy2 up
Chirag Shah [Mon, 13 Jan 2025 02:31:02 +0000 (18:31 -0800)]
tools: fix frr-reload for nbr deletion of no form cmds
When a bgp neighbor removed from associated to peer-group,
the neighbor is fully deleted, subsequent deletion of any
configuration related to the neighbor leads to failure
in frr-reload.
Handle any 'no neighbor ...' part of lines_to_del list
Testing:
Below first line would delete the neighbor swp1.10,
the existing code before the change handles to remove
config starts with 'neighbor swp1.10 ...' but not
'no neighbor swp1.10 ...'.
projects / matthieu / frr.git / log