By calling `ly_log_options` with `LY_LOSTORE`, the current code
effectively disables libyang logging and never enables it back. The call
is done to get the current logging options, but we don't really need
that. When looking for a schema node, we don't want neither to log nor
to store the error, so simply set the temporary options to 0.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
When a prefix-list entry is updated, current NB code calls the
replacement code multiple times, once per each updated field. It means
that when multiple fields of an entry are changed in a single commit,
the replacement is done with an interim state of a prefix-list instead
of a final one. To fix the issue, we should call the replacement code
once, after all fields of an entry are updated.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
When an access-list entry is updated, current NB code calls notification
hooks for each updated field. It means that when multiple fields of an
entry are changed in a single commit, the hooks are run with an interim
state of an access-list instead of a final one. To fix the issue, we
should call the hooks once, after all fields of an entry are updated.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Containers inside a choice's case must be treated as presence containers
as they can be explicitly created and deleted. They must have `create`
and `destroy` callbacks, otherwise the internal data they represent may
never be deleted.
The issue can be reproduced with the following steps:
- create an access-list with destination-network params
```
# access-list test seq 1 permit ip any 10.10.10.0 0.0.0.255
```
- delete the `destination-network` container
```
# mgmt delete-config /frr-filter:lib/access-list[name='test'][type='ipv4']/entry[sequence='1']/destination-network
# mgmt commit apply
MGMTD: No changes found to be committed!
```
As the `destination-network` container is non-presence, and all its
leafs are mandatory, mgmtd doesn't see any changes to be commited and
simply updates its YANG data tree without passing any updates to backend
daemons.
This commit fixes the issue by requiring `create` and `destroy`
callbacks for containers inside choice's cases.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
When ordering operations, destroys must always come before other
operations, to correctly cover the change of a "case" in a "choice".
The problem can be reproduced with the following commands:
```
access-list test seq 1 permit 10.0.0.0/8
access-list test seq 1 permit host 10.0.0.1
access-list test seq 1 permit 10.0.0.0/8
```
Before this commit, the order of changes would be the following:
- `access-list test seq 1 permit 10.0.0.0/8`
- `modify` for `ipv4-prefix`
- `access-list test seq 1 permit host 10.0.0.1`
- `destroy` for `ipv4-prefix`
- `modify` for `host`
- `access-list test seq 1 permit 10.0.0.0/8`
- `modify` for `ipv4-prefix`
- `destroy` for `host`
As `destroy` for `host` is called last, it rewrites the fields that were
filled by `modify` callback of `ipv4-prefix`. This commit fixes this
problem by always calling `destroy` callbacks first.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Notifications are sent by mgmtd for each session of a client, so they
should be processed once per each session.
Also, add session_id parameter to an async_notification callback as all
other callbacks have this parameter.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
When ordering the NB callbacks according to their priorities, if the
operation is "destroy" we should reverse the order, to destroy the
dependants before the dependencies.
This fixes the crash, that can be reproduced with the following steps:
```
frr# conf term file-lock
frr(config)# affinity-map map bit-position 10
frr(config)# interface test
frr(config-if)# link-params
frr(config-link-params)# affinity map
frr(config-link-params)# exit
frr(config-if)# exit
frr(config)# mgmt commit apply
frr(config)# no affinity-map map
frr(config)# interface test
frr(config-if)# link-params
frr(config-link-params)# no affinity map
frr(config-link-params)# exit
frr(config-if)# exit
frr(config)# mgmt commit apply
```
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Other objects depend on affinity-maps being created before them by using
leafref with require-instance true. Set the priority to ensure that.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Remove adding of line feeds when encondig. We're using these functions
only for encoding binary data for storing in YANG data tree.
According to RFC 7950, section 9.8.2:
```
9.8.2. Lexical Representation
Binary values are encoded with the base64 encoding scheme (see
Section 4 in [RFC4648]).
```
According to mentioned RFC 4648, section 3.1:
```
Implementations MUST NOT add line feeds to base-encoded data unless
the specification referring to this document explicitly directs base
encoders to add line feeds after a specific number of characters.
```
Therefore, line feeds must not be added to the encoded data.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Before this fix would always return empty results b/c there was no
libyang tree to print to output format.
Signed-off-by: Christian Hopps <chopps@labn.net>
Convert only when this is really needed, e.g. `match ip address prefix-list ...`.
Otherwise, we can't have mixed match clauses, like:
```
match ip address prefix-list p1
match evpn route-type prefix
```
This won't work, because the prefix is already converted, and we can't extract
route type, vni, etc. from the original EVPN prefix.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Currently, YANG notification processing is done using a special type of
callbacks registered in backend clients. In this commit, we start using
regular northbound infrastructure instead, because it already has a
convenient way of registering xpath-specific callbacks without the need
for creating additional structures for each necessary notification. We
also now pass a notification data to the callback, instead of a plain
JSON. This allows to use regular YANG library functions for inspecting
notification fields, instead of manually parsing the JSON.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Current code assumes that notification is always sent in stripped JSON
format and therefore notification xpath starts at the third symbol of
notification data. Assuming JSON is more or less fine, because this
representation is internal to FRR, but the assumption about the xpath is
wrong, because it won't work for not top-level notifications. YANG
allows to define notification as a child for some data node deep into
the tree and in this case notification data contains not only the
notification node itself, but also all its parents.
To fix the issue, parse the notification data and get its xpath from its
schema node.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
When exiting from a level below the config node, like `router rip`,
vtysh executes a resync by sending "end" and "conf term [file-lock]"
commands to all the daemons. As statet in the description comment, it's
done "in case one of the daemons is somewhere else". I don't think this
actually ever happens, but even if it is, it is a bug in a daemon that
needs to be fixed. This resync was okay before the introduction of
mgmtd, but now it unlocks and locks back the datastores during the
configuration reading process, which can lead to a failure which is
explained in the previous commit.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
There exists cases where just honoring the FD_LIMIT size
as given to us by the operating system makes no sense.
Let's just make a switch to allow for this for things
like vtysh and ospfclient which will never have 1k files
open at any given time.
Fixes: #15315
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
We don't need to manually load built-in modules. This fixes the
following warning in mgmtd:
```
YANG model "ietf-yang-metadata@*" "*@*"not embedded, trying external file
```
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
mgmtd is supposed to only register CLI callbacks. If configuration
callbacks are registered, they are getting called on startup when mgmtd
reads config files, and they can use infrastructure that is not
initialized on mgmtd, or allocate some memory that is never freed.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
In a non-controlled startup, the rcu data structures were
not being created until after logging could happen. This
is bad. Move it so that the rcu data structures are
created first, before logging( HA! ) can happen.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
External libraries can re-enter the FRR code through a hook function. A
crash occurs when logging from this hook function if the library has
initiated a new pthread, as the FRR RCU context is not initialized for
this thread.
Add frr_pthread_non_controlled_startup() function to initialize a valid
RCU context within a FRR pthread context, originating from an external
pthread.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
It's unlikely that an operator will ever set a fd
limit of over 100k. Let's warn the operator that
things are in a bit of a wonky state.
Fixes: #15280
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Remove operational data check from CLI command. It never works in mgmtd
and it is not needed in backend daemons because it's done in
`lib_vrf_destroy` callback.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Currently, staticd configuration is tightly coupled with VRF existence.
Because of that, it has to use a hack in NB infrastructure to create a
VRF configuration when at least one static route is configured for this
VRF. This hack is incompatible with mgmtd, because mgmtd doesn't execute
configuration callbacks. Because of that, the configuration may become
out of sync between mgmtd and staticd. There are two main cases:
1. Create static route in a VRF. The VRF data node will be created
automatically in staticd by the NB hack, but not in mgmtd.
2. Delete VRF which has some static routes configured. The static route
configuration will be deleted from staticd by the NB hack, but not
from mgmtd.
To fix the problem, decouple configuration of static routes from VRF
configuration. Now it is possible to configure static routes even if the
VRF doesn't exist yet. Once the VRF is created, staticd applies all the
preconfigured routes.
This change also fixes the problem with static routes being preserved in
the system when staticd "control-plane-protocol" container is deleted
but the VRF is still configured.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Create a single registry of default port values that daemons
are using. Most of these are vty ports, but there are some
others for features like ospfapi and zebra FPM.
Signed-off-by: Mark Stapp <mjs@labn.net>
pahole reports that the hash_bucket has 2 4 byte holes
in the data structure. Let's reorganize this a bit
and save 8 bytes per hash_bucket instance.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
