Igor Ryzhov [Mon, 26 Feb 2024 09:30:57 +0000 (11:30 +0200)]
lib: fix setting temporary log options for libyang
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.
Igor Ryzhov [Sun, 25 Feb 2024 19:50:41 +0000 (21:50 +0200)]
bgpd, yang: fix missing mandatory/default statements on some leafs
The code expects these leafs to always exist. If they are not set, the
daemon would crash. CLI always sets them, but we should properly mark
them as mandatory/default to prevent them from being missed when using
the API.
Igor Ryzhov [Fri, 23 Feb 2024 22:06:41 +0000 (00:06 +0200)]
lib: fix nb callbacks for containers inside choice case
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.
Igor Ryzhov [Fri, 23 Feb 2024 19:14:26 +0000 (21:14 +0200)]
lib: fix order of northbound operations
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.
Igor Ryzhov [Tue, 20 Feb 2024 20:32:52 +0000 (22:32 +0200)]
lib: fix order of northbound callbacks
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
```
Igor Ryzhov [Mon, 19 Feb 2024 13:35:22 +0000 (15:35 +0200)]
lib: fix base64 encoding
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.
Philippe Guibert [Mon, 19 Dec 2022 14:39:00 +0000 (15:39 +0100)]
isisd: show isis route .. json adds the algorithm value
When walking over all the flex-algorithm routes, it is
difficult to know which route is associated to which
algorithm: add "algorithm" attribute to the json object.
Philippe Guibert [Thu, 15 Dec 2022 08:26:45 +0000 (09:26 +0100)]
isisd: make optional algorithm id in 'show isis route'
To avoid calling for each algorithm the 'show isis route'
command, the algorithm id is optional. The below command
will dump the routes for all the algorithms:
> show isis route algorithm
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com> Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Add a bunch of helper functions to support encoding of SRv6 SIDs in
protobuf.
Specifically,
* `fpm_srv6_sid_format_create`: encode SID format information into a
protobuf `SRv6SIDFormat` structure
* `fpm_srv6_local_sid_*_behavior_create` functions: encode an SRv6 SID
behavior and associated attributes into a protobuf
`Fpm__SRv6LocalSID__*` structure
This is a preliminary commit to support sending SRv6 Local SIDs and VPN
SIDs via protobuf.
Add two helper functions to encode/decode nexthops in protobuf.
Specifically,
* `fpm_nexthop_create`: encode a `struct nexthop` in a protobuf nexthop
structure
* `fpm_nexthop_get`: decode a nexthop protobuf structure into a `struct
nexthop`
This is a preliminary commit to support sending SRv6 Local SIDs and VPN
SIDs via protobuf.
Add two optional fields to the AddRoute protobuf message to support
SRv6 VPN use cases:
* `srv6_vpn_sid`: used to associate an SRv6 VPN SID to a route; if
present, the router will steer the traffic that matches the prefix by
encapsulating the payload in an outer IPv6 header where the destination
address is the SRv6 VPN SID provided
* `srv6_encap_source_address`: source Address of outer encapsulating
IPv6 header
This is a preliminary commit to support sending SRv6 Local SIDs and VPN
SIDs via protobuf.
Donald Sharp [Fri, 16 Feb 2024 04:28:18 +0000 (23:28 -0500)]
bgpd: Fix value stored to group never being read
SA Reports:
bgpd/bgp_rpki.c:1085:24: warning: Value stored to 'group' during its initialization is never read [deadcode.DeadStores]
struct rtr_mgr_group *group = get_connected_group(rpki_vrf);
^~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Louis Scalbert [Fri, 9 Feb 2024 15:28:23 +0000 (16:28 +0100)]
bgpd: update route leak when vrf appears
If the VRF is not yet created and a BGP instance is created for the
VRF, dependent leaked routes are inactive, which is normal. However,
when the VRF interface appears, they remains inactive.
Update route leak when a VRF interface appears. Note that routes to a
deleted VRF are already removed by zebra.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Louis Scalbert [Fri, 9 Feb 2024 14:47:40 +0000 (15:47 +0100)]
tests: check route leak after changing vrf state
Check that local route leaks are set to "inactive" when the VRF
interface is shutdown and, conversely, that they are set to "active"
when the VRF interface is unshut.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
lynnemorrison [Tue, 13 Feb 2024 15:20:11 +0000 (10:20 -0500)]
ospfd: fix cli shown in running config when turning off ldp-sync
LDP-Sync is automatically enabled on interfaces when turned on in
router ospf context. The user can remove ldp-sync from running
on an interface, by issuing a "no ip ospd mpls ldp-sync" command.
To remove all ldp-sync interface commands the user must delete
ldp-sync at the router level. The code was not correctly removing
the config. This PR fixes that issue. Now the extra cli
ldp-sync commands are removed when ldp-sync is disabled.
Igor Ryzhov [Mon, 12 Feb 2024 18:34:33 +0000 (20:34 +0200)]
mgmtd: fix be_is_client_interested
Backend "subscribe" API allows daemons to dynamically register xpaths
they are interested in. Such xpaths are not stored in hardcoded
config/oper xpath arrays so this function fails to understand that a
backend daemon is interested in them. Fix by using dynamic xpath maps
instead which store both hardcoded and dynamic xpaths.
Igor Ryzhov [Sat, 10 Feb 2024 00:11:13 +0000 (02:11 +0200)]
lib, mgmtd: rework processing of yang notifications
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.
In `qpb.h` we have a bunch of functions that make use of
`union g_addr`. `union g_addr` is defined in `nexthop.h`, which
actually is NOT included in `qpb.h`.
Igor Ryzhov [Fri, 9 Feb 2024 22:58:49 +0000 (00:58 +0200)]
lib, mgmtd: fix processing of yang notifications
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.
> VRF r1-cust4:
> B 5.1.0.0/24 [20/98] via 99.0.0.1 (vrf r1-cust1) inactive, weight 1, 00:00:08
> B>* 99.0.0.1/32 [20/0] via 192.168.1.2, r1-eth4 (vrf r1-cust1), weight 1, 00:00:08
When announcing the routes to zebra, use the peer of the ultimate bgp
path info instead of the one of the first parent path info to determine
whether the route is recursive.
The result is:
> VRF r1-cust4:
> B> 5.1.0.0/24 [20/98] via 99.0.0.1 (vrf r1-cust1) (recursive), weight 1, 00:00:02
> * via 192.168.1.2, r1-eth4 (vrf r1-cust1), weight 1, 00:00:02
> B>* 99.0.0.1/32 [20/0] via 192.168.1.2, r1-eth4 (vrf r1-cust1), weight 1, 00:00:02
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
projects / mirror / frr.git / log