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>
Sometimes it's very useful to compare pointers from the gdb (and/or from the
logs) or just do some quick adhoc analysis.
```
donatas# sh ip bgp 1.1.1.0/24 internal
BGP routing table entry for 1.1.1.0/24, version 0
Paths: (1 available, no best path)
Not advertised to any peer
65002
127.0.0.1 (inaccessible, import-check enabled) from 127.0.0.1 (127.0.0.2)
Origin IGP, invalid, external
Last update: Thu Jan 16 16:49:53 2025
net: 0x63f3e6fc2ea0, path: 0x63f3e6fc2f50, pathext: 0x63f3e6faed00, attr: 0x63f3e6e8c550
flags net: 0x0, path: 0x1024, attr: 0x7
donatas#
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
The dg_update_list access is controlled by the dg_mutex in all
other locations. Let's just add a mutex usage around the initialization
of the dg_update_list even if it's part of the startup, just to keep
things consistent.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Grab the count of streams in ibuf when it is protected
by a mutex. Since this data is written to it in another
pthread.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
msg_new takes a uint16_t, the length passed
down variable is a unsigned int, thus 32 bit.
It's possible, but highly unlikely, that the
msglen could be greater than 16 bit.
Let's just add some checks to ensure that
this could not happen.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Related: https://datatracker.ietf.org/doc/html/draft-white-linklocal-capability
TL;DR; use 16 bytes long next-hops for point-to-point (unnumbered) links instead
of sending 32 bytes (::/LL, GUA/LL, LL/LL combinations).
For backward compatiblity we should handle even 32 bytes existing next hops.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
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>
