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.
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>
Move mp_nexthop_prefer_global boolean attribute to nh_flags. It does
not currently save memory because of the packing.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
This test is failing locally for me 100% of the time
since zebra was converted to mgmtd usage. The failed
command is:
torm11# show evpn mac vni 1000 mac 00:00:00:00:00:11 json
{
"00:00:00:00:00:11":{
"type":"auto",
"uptime":"00:02:01",
"localSequence":0,
"remoteSequence":0,
"detectionCount":0,
"isDuplicate":false,
"syncNeighCount":0,
"neighbors":{
"active":[
],
"inactive":[
"45.0.0.11"
]
}
}
}
The test is expecting an esi as a key in the output. Re-arranging
the startup of the tor's before the hosts fixes the issue.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
A macvlan interface can have its underlying link-interface in another
namespace (aka. netns). However, by default, zebra does not know the
interface from the other namespaces. It results in a crash the pointer
to the link interface is NULL.
> 6 0x0000559d77a329d3 in zebra_vxlan_macvlan_up (ifp=0x559d798b8e00) at /root/frr/zebra/zebra_vxlan.c:4676
> 4676 link_zif = link_ifp->info;
> (gdb) list
> 4671 struct interface *link_ifp, *link_if;
> 4672
> 4673 zif = ifp->info;
> 4674 assert(zif);
> 4675 link_ifp = zif->link;
> 4676 link_zif = link_ifp->info;
> 4677 assert(link_zif);
> 4678
> (gdb) p zif->link
> $2 = (struct interface *) 0x0
> (gdb) p zif->link_ifindex
> $3 = 15
Fix the crash by returning when the macvlan link-interface is in another
namespace. No need to go further because any vxlan under the macvlan
interface would not be accessible by zebra.
Link: https://github.com/FRRouting/frr/issues/15370
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.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>
The following two isis commands have now the algorithm id
optional:
> # show isis segment-routing node algorithm
> # show isis topology algorithm
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
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.
Output example:
> ubuntu2004(config-router)# do show isis route algorithm json
> [
> {
> "area":"1",
> "algorithm":128,
> "level-1":{
> ]
> },
> "level-2":{
> "area":"1"
> },
> "vrf_id":0
> },
> {
> "area":"1",
> "algorithm":129,
> "level-1":{
> "area":"1",
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
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.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
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.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
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.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
Add several protobuf messages to support the installation and removal
of SRv6 Local SIDs via FPM protobuf.
This is a preliminary commit to support sending SRv6 Local SIDs and VPN
SIDs via protobuf.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
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);
^~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
