Routing v4 over an v6 nexthop is already well supported within zebra
(and FRR). This adds support to staticd, allowing an IPv6 nexthop to
be provided to ip route statements. For this the commands are
extended and the address family is parsed from the parameter.
When receiving nht updates from zebra, both AFIs are checked because
prefixes could exist in both. Additionally when route_node is known,
family of prefix is used instead of nexthop.
Signed-off-by: Christopher Dziomba <christopher.dziomba@telekom.de>
A user can configure static SIDs as follows:
[...]
segment-routing
srv6
static-sids
sid fcbb:bbbb:1::/48 locator MAIN behavior uN
sid fcbb:bbbb:1:fe00::/64 locator MAIN behavior uDT46
[...]
When the user runs vtysh and executes the `no srv6` command, the
expectation is that staticd will deallocate all SIDs.
However, currently FRR does not behaves as expected. After the user
executes `no srv6`, the SIDs are still present.
The problem is that vtysh does not forward the `no srv6` command to
mgmtd/staticd.
The `no srv6` command is defined using the `DEFUN_YANG_NOSH` macro,
which instructs `xref2vtysh.py` to skip the `no srv6` command during
the generation of `vtysh_cmd.c`. As a result, vtysh is unaware that it
should forward the `no srv6` command to mgmtd/staticd.
This commit fixes the issue by replacing `DEFUN_YANG_NOSH` with
`DEFUN_YANG`. This change ensures that `xref2vtysh.py` includes the
`no srv6` command when generating `vtysh_cmd.c` and makes vtysh forward
the `no srv6` command to mgmtd/staticd.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
Currently, when the user tries to delete all static SIDs with the
`no static-sids` command, staticd returns an error.
```
router# config
router(config)# segment-routing
router(sr)# srv6
router(srv6)# no static-sids
% Unknown command: no static-sids
```
The problem is the `static-sids` command does not support the `no` form.
This PR enables the `no` form for the `static-sids` command.
```
router# config
router(config)# segment-routing
router(sr)# srv6
router(srv6)# no static-sids
```
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
This commit converts the `static-sids` command from `DEFUN` to `DEFPY`
to simplify the parsing of the command string definition.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
This commit extends the SRv6 SIDs show CLI to display the configured
SRv6 uA SIDs.
```
segment-routing
srv6
static-sids
sid fcbb:bbbb:1:fe40::/64 locator MAIN behavior uA interface sr0 nexthop 2001::2
!
!
!
```
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
This commit extends the STATIC CLI to support the deletion of uA SIDs.
```
router(config)# no sid fcbb:bbbb:1:fe00::/64 locator MAIN behavior uA interface sr0 nexthop 2001::2
```
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
This commit extends the STATIC CLI to support the configuration of uA
SIDs.
```
router(config)# sid fcbb:bbbb:1:fe00::/64 locator MAIN behavior uA interface sr0 nexthop 2001::2
```
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
Some codepoints can not be read by interoperating with CISCO.
This is because PSP/USP flavor are used by default, and the display of
the isis output has to be adapted.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When a user wants to delete a specific SRv6 SID, he executes the
`no sid X:X::X:X/M` command.
However, by mistake, in addition to deleting the SID requested by the
user, this command also removes all other SIDs.
This happens because `no sid X:X::X:X/M` triggers a destroy operation
on the wrong xpath `frr-staticd:staticd/segment-routing/srv6`.
This commit fixes the issue by replacing the wrong xpath
`frr-staticd:staticd/segment-routing/srv6` with the correct xpath
`frr-staticd:staticd/segment-routing/srv6/static-sids/sid[sid='%s']`.
This ensures that the `no sid X:X::X:X/M` command only deletes the SID
that was requested by the user.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
staticd already has a CLI to steer IPv6 traffic over a given SRv6 SID
list:
```
vrf vrf10
ipv6 route 2001:db8:1:1::/64 sr0 segments fcbb:bbbb:1:2:3:fe00::
```
This PR extends the existing CLI `ip route` to support steering of IPv4
traffic over an SRv6 SID list.
```
vrf vrf10
ip route 10.0.0.0/24 sr0 segments fcbb:bbbb:1:2:3:fe00::
```
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
staticd already has a CLI to steer IPv6 traffic over a given SRv6 SID
list:
```
ipv6 route 2001:db8:1:1::/64 sr0 segments fcbb:bbbb:1:2:3:fe00::
```
This PR extends the existing CLI `ip route` to support steering of IPv4
traffic over an SRv6 SID list.
```
ip route 10.0.0.0/24 sr0 segments fcbb:bbbb:1:2:3:fe00::
```
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
staticd already has a CLI to steer IPv6 traffic over a given SRv6 SID
list:
```
vrf vrf10
ipv6 route 2001:db8:1:1::/64 sr0 segments fcbb:bbbb:1:2:3:fe00::
```
This PR extends the existing CLI `ip route` to support steering of IPv4
traffic over an SRv6 SID list.
```
vrf vrf10
ip route 10.0.0.0/24 sr0 segments fcbb:bbbb:1:2:3:fe00::
```
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
staticd already has a CLI to steer IPv6 traffic over a given SRv6 SID
list:
```
ipv6 route 2001:db8:1:1::/64 sr0 segments fcbb:bbbb:1:2:3:fe00::
```
This PR extends the existing CLI `ip route` to support steering of IPv4
traffic over an SRv6 SID list.
```
ip route 10.0.0.0/24 sr0 segments fcbb:bbbb:1:2:3:fe00::
```
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
The staticd YANG conversion completely f*cked up dst-src routes.
Stupidly enough, the correct thing is much simpler as seen by the amount
of deletes in this commit.
This does, unfortunately, involve a rather annoying YANG edge case with
what should reasonably be an optional leaf as part of a list key, which
is not possible. It uses `::/0` as unconditional filler instead, since
that is semantically correct.
The `test_yang_mgmt` topotest needed to be adjusted after this to add
`src-prefix='::/0'`.
Fixes: 88fa5104a0 ("staticd : Configuration northbound implementation")
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Implement common code for debug status output and remove daemon-specific
code that is duplicated everywhere.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Implement common code for debug config output and remove daemon-specific
code that is duplicated everywhere.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
This reverts commit 76b2bc97e7.
This change is wrong for several reasons:
- it is backwards incompatible - previously it was always possible to
create blackhole/reject routes using shortened versions of the words
and it suddenly became impossible if there's an interface in the
system with the same name
- it uses operational data for validation which is prohibited
- it doesn't really solve the problem with inability to create routes
using interface names like `bla` or `rej`
We may actually need to send CLI commands to mgmtd and another daemon at
the same time, for example, if this daemon is not mgmtd-converted. The
only daemon this exception protects is staticd. But we don't actually
need any configuration commands in staticd, so just remove the exception
and don't install unnecessary commands to staticd.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Setting this variable to true makes NB ignore only configuration-related
callbacks. CLI-related callbacks are still loaded and executed, so
rename the variable to make it clearer.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
As mgmtd now implements vty for staticd, it's logical to output the
configuration from there as well. Fully-converted backend daemons should
not handle vty commands at all.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
XSTRDUP and then calling strsep mangles the
pointer returned by XSTRDUP. Keep a copy
of the orig and when we are done, free that instead.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Before this patch we allow entering next-hop interface address as any string.
Like, we can type: `ip route 10.10.10.10/32 bla`, but this will create a blackhole
route instead of using an interface `bla`.
The same is with reject.
After the patch:
```
$ vtysh -c 'con' -c 'ip route 10.10.10.100/32 bla'
ERROR: SET_CONFIG request failed, Error: nexthop interface name must be (reject, blackhole)
$ ip link show dev bla
472: bla: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 1000
link/ether fa:45:bd:f1:f8:f0 brd ff:ff:ff:ff:ff:ff
$ vtysh -c 'sh run | include ip route'
$ vtysh -c 'con' -c 'ip route 10.10.10.100/32 blac'
$ vtysh -c 'sh run | include ip route'
ip route 10.10.10.100/32 blackhole
$ vtysh -c 'con' -c 'no ip route 10.10.10.100/32 blac'
$ vtysh -c 'sh run | include ip route'
$ vtysh -c 'con' -c 'ip route 10.10.10.100/32 blackhole'
$ vtysh -c 'sh run | include ip route'
ip route 10.10.10.100/32 blackhole
$ vtysh -c 'con' -c 'no ip route 10.10.10.100/32 blackhole'
$ vtysh -c 'sh run | include ip route'
$ vtysh -c 'con' -c 'ip route 10.10.10.100/32 Null0'
$ vtysh -c 'sh run | include ip route'
ip route 10.10.10.100/32 Null0
$ vtysh -c 'con' -c 'no ip route 10.10.10.100/32 Null0'
$ vtysh -c 'sh run | include ip route'
$
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
When displaying the configuration, the order of nexthop-vrf is wrong,
because the default VRF is not displayed, but still compared as the word
"default". Therefore it is placed in the middle of the list instead of
always being the first one.
Before the fix:
```
ip route 1.1.1.0/24 2.2.2.2 nexthop-vrf ccc
ip route 1.1.1.0/24 2.2.2.2
ip route 1.1.1.0/24 2.2.2.2 nexthop-vrf eee
```
After the fix:
```
ip route 1.1.1.0/24 2.2.2.2
ip route 1.1.1.0/24 2.2.2.2 nexthop-vrf ccc
ip route 1.1.1.0/24 2.2.2.2 nexthop-vrf eee
```
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
This commmit introduces Staticd as a backend client for the MGMTd
framework. All the static commands will be diverted to the MGMT
daemon and will use the transactional model to make changes to the
internal state. Similar mechanism can be used by other daemons to use
the MGMT framework in the future.
This commit includes the following functionalities in the changeset:
1. Diverts all the staticd (config only) commands to MGMTd.
2. Enrolls staticd as a backend client to use the MGMT framework.
3. Modify the staticd NB config handlers so that they can be compiled
into a library and loaded in the MGMTd process context.
Co-authored-by: Pushpasis Sarkar <pushpasis@gmail.com>
Co-authored-by: Abhinay Ramesh <rabhinay@vmware.com>
Co-authored-by: Ujwal P <ujwalp@vmware.com>
Signed-off-by: Yash Ranjan <ranjany@vmware.com>
Passing a pre-formatted buffer in these places needs a `"%s"` in front
so it doesn't get formatted twice.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
This command helps in troubleshooting static bfd feature.
Add traces upon bfd events.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Simplify all DEFUNs by moving all logic to the northbound translation
function and transforming all function parameters into a single
structure.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Rather than running selected source files through the preprocessor and a
bunch of perl regex'ing to get the list of all DEFUNs, use the data
collected in frr.xref.
This not only eliminates issues we've been having with preprocessor
failures due to nonexistent header files, but is also much faster.
Where extract.pl would take 5s, this now finishes in 0.2s. And since
this is a non-parallelizable build step towards the end of the build
(dependent on a lot of other things being done already), the speedup is
actually noticeable.
Also files containing CLI no longer need to be listed in `vtysh_scan`
since the .xref data covers everything. `#ifndef VTYSH_EXTRACT_PL`
checks are equally obsolete.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
There are lib debugs being set but never show up in
`show debug` commands because there was no way to show
that they were being used. Add a bit of infrastructure
to allow this and then use it for `debug route-map`
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
