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>
Set static router-id for OSPF, because otherwise it depends on timing of
router-id updates received from zebra and may differ between test runs.
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>
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.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Following new json decoder for Opaque LSA, this patch adapts the ospfapiclient
test to the new json output.
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
When dumping ospf database with json output, decode Extended Link and Extended
Prefix TLVs and sub-TLVs.
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
Instead of output bulk of data with json output, prepare json context to decode
opaque TLVs and sub-TLVs.
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
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>
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`.
Let's add the missing `#include nexthop.h`.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.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>
While checking the code, we can notice that they are already converted.
Suggested-by: Igor Ryzhov <iryzhov@nfware.com>
Signed-off-by: Vincent Jardin <vjardin@free.fr>
Leaked recursive routes are not resolved.
> VRF r1-cust1:
> B> 5.1.0.0/24 [200/98] via 99.0.0.1 (recursive), weight 1, 00:00:08
> * via 192.168.1.2, r1-eth4, weight 1, 00:00:08
> B>* 99.0.0.1/32 [200/0] via 192.168.1.2, r1-eth4, weight 1, 00:00:08
> 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>
Include gtsm_hops (minttl) field when copying peer structure,
so that a new connection could set a proper value.
Signed-off-by: Alexander Skorichenko <askorichenko@netgate.com>
