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>
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>
cisco routers are not dealing fairly whith unsupported capabilities.
When a cisco router receive an unsupported capabilities it reset the
negociation without notifying the unmatching capability as described in
RFC2842.
Cisco suggest the use of
neighbor x.x.x.x capability fqdn
to avoid the use of fqdn in open message.
this new command is to remove the use of fqdn capability in the
open message with the peer "x.x.x.x".
Link: https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/116189-problemsolution-technology-00.pdf
Signed-off-by: Francois Dumontet <francois.dumontet@6wind.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>
Add tests in bgp_vrf_route_leak_basic topotest to check that route
leaking from the default VRF results in an operational route.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Add a test in bgp_vrf_route_leak_basic topotest to check that route
leaking from a non existing VRF results in an inactive route.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Update bgp_vrf_route_leak_basic to set up the VRF interfaces. Otherwise
the routes to the VRF interface are inactives.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Previously, routes leaked from one VRF to another VRF were associated
with the original nexthop interface.
Due to this change, the `bgp_srv6l3vpn_route_leak` topotest always fails
because it still expects the nexthop interface.
This commit fixes the expected interface name in the
`bgp_srv6l3vpn_route_leak` topotest.
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Leaked connected routes have now the following nexthop interfaces:
- lo for routes imported from the default VRF
- or the VRF interface for routes imported from the other VRFs.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
We shouldn't pass "lo" as an interface to create_interface_in_kernel.
It always exists, and this function flushes all configured IP addresses
from it.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
This needs to be used for persistent state, which currently is misplaced
into `/var/run` / `/run` where it gets deleted across reboots.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The name of the `test_zebra_seg6local_routes` test is wrong. The goal
of this test is to verify seg6 routes (not seg6local routes).
Let's put the correct name.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
Per the RFC6860, check OSPFv2 using point-to-multipoint
over Ethernet.
Enable the behavior of the RFC6860 using:
ip ospf prefix-suppress A.B.C.D
See:
https://www.rfc-editor.org/rfc/rfc6860#section-2.3.2.2
Note that nexthops are not required to assess the checks.
Signed-off-by: Vincent Jardin <vjardin@free.fr>
Getting this error:
2024-01-17 19:05:20,688 WARNING: torm11: Router(torm11): proc failed: rc 255 pid 2436134
args: /usr/bin/nsenter --mount=/proc/2435168/ns/mnt --net=/proc/2435168/ns/net --uts=/proc/2435168/ns/uts -F /bin/bash -c /sbin/bridge vlan add vid 1000 dev bridge
stdout: RTNETLINK answers: Operation not supported
stderr: *empty*
As I understand it the correct thing to do here is pass in:
bridge vlan add vid 1000 dev bridge self
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When received malformed AS4 capability, it should return -1 (notification send),
and the received flag SHOULD NOT be set.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
