This is actually not reset, and should be ignored showing it as last reset
under `show bgp neighbor`.
Fixes: 1e91f1d119 ("bgpd: Update failed reason to distinguish some NHT scenario")
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
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).
Signed-off-by: Christian Hopps <chopps@labn.net>
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: d1cfd73060 ("tests: Check if ENHE capability can be handled dynamically")
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
- Previously we sent selectors to all backends when a replace was
done, improve this to only send them to backends that provide
the selected state.
Signed-off-by: Christian Hopps <chopps@labn.net>
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].
Signed-off-by: Christian Hopps <chopps@labn.net>
This commit moves DEFAULT_SRV6_IFNAME from isis_srv6.h to srv6.h
because there are other daemons that might want to use it (e.g. staticd).
Signed-off-by: Yuqing Zhao <galadriel.zyq@alibaba-inc.com>
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
Signed-off-by: Yuqing Zhao <galadriel.zyq@alibaba-inc.com>
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.
Signed-off-by: Julian Klaiber <jklaiber@open-systems.com>
Add ability to enable -w option for all daemons in a topotest and use
this option instead of the deprecated -n.
Signed-off-by: Igor Ryzhov <idryzhov@gmail.com>
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.
Signed-off-by: Igor Ryzhov <idryzhov@gmail.com>
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.
Signed-off-by: Igor Ryzhov <idryzhov@gmail.com>
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.
Signed-off-by: Igor Ryzhov <idryzhov@gmail.com>
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.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
