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>
Implement all BFD integration northbound callbacks and integrate BFD
with `staticd` route installation procedure.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
There exists some nexthop attributes that are not the unique
part of the nexthop and if you change the static route
with those values then the route is not being updated
in zebra with the new values:
Example of brokenness:
eva# conf
eva(config)# ip route 1.2.3.9/32 192.168.119.1 enp39s0 label 16020
eva(config)# do show ip route 1.2.3.9
Routing entry for 1.2.3.9/32
Known via "static", distance 1, metric 0, best
Last update 00:00:05 ago
* 192.168.119.1, via enp39s0, label 16020, weight 1
eva(config)# ip route 1.2.3.9/32 192.168.119.1 enp39s0 label 16040
eva(config)# do show ip route 1.2.3.9
Routing entry for 1.2.3.9/32
Known via "static", distance 1, metric 0, best
Last update 00:00:12 ago
* 192.168.119.1, via enp39s0, label 16020, weight 1
Fixed behavior:
eva# conf
eva(config)# ip route 1.2.3.10/32 192.168.119.1 enp39s0 label 16020
eva(config)# do show ip route 1.2.3.10
Routing entry for 1.2.3.10/32
Known via "static", distance 1, metric 0, best
Last update 00:00:04 ago
* 192.168.119.1, via enp39s0, label 16020, weight 1
eva(config)# ip route 1.2.3.10/32 192.168.119.1 enp39s0 label 16040
eva(config)# do show ip route 1.2.3.10
Routing entry for 1.2.3.10/32
Known via "static", distance 1, metric 0, best
Last update 00:00:01 ago
* 192.168.119.1, via enp39s0, label 16040, weight 1
I've gone through most of the items in staticd that can change
the nexthop
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Restrict the number of nexthops for a route to the compiled-in
limit. Be careful with the zapi route struct's array of nexthops
too.
Signed-off-by: Mark Stapp <mstapp@nvidia.com>
If there's no route table in a VRF, it's a hard bug - staticd will crash
on any subsequent action with this route anyway. So let's assert the
existence of a route table instead of returning an unrecoverable error.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Add a couple of back pointers to static route/path/nexthop structures to
simplify the NB code and save ~200 lines.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Compile with v2.0.0 tag of `libyang2` branch of:
https://github.com/CESNET/libyang
staticd init load time of 10k routes now 6s vs ly1 time of 150s
Signed-off-by: Christian Hopps <chopps@labn.net>
`config.h` has all the defines from autoconf, which may include things
that switch behavior of other included headers (e.g. _GNU_SOURCE
enabling prototypes for additional functions.)
So, the first include in any `.c` file must be either `config.h` (with
the appropriate guard) or `zebra.h` (which includes `config.h` first
thing.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Currently, staticd creates a VRF for the nexthop it is trying to install.
Later, when this nexthop is deleted, the VRF stays in the system and can
not be deleted by the user because "no vrf" command doesn't work for this
VRF because it was not created through northbound code.
There is no need to create the VRF. Just set nh_vrf_id to VRF_UNKNOWN
when the VRF doesn't exist.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
When checking for local connected address used as a nexthop gateway, we
should check nexthop VRF, not route VRF.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
At present, libyang validate api takes longer time to complete
for a transaction to complete if the same config is re-applied.
For instance if set of static routes are reapplied the config
completion takes longer than it took initial time.
One of the solution is to remove when statement from staticd nexthop yang OM.
When condition adds peformance toll on libyang's validate api.
The same when condition checks are done in frr northbound
validation phase (which are must faster).
With this change, if the same static routes are configured
agian and again, the time to completion does not go up and
perfomance does not degrade.
Ticket:CM-32530
Testing Done:
Configure 400 static routes across two vrfs and keep re-applying them.
The time to complete the config remains in few seconds.
Before:
root@bharat:~/stash/frr4# time vtysh -f static_route_cfg
real 0m19.877s
user 0m0.263s
sys 0m0.014s
After:
root@bharat:~/stash/frr4# time vtysh -f static_route_cfg
real 0m3.857s
user 0m0.239s
sys 0m0.034s
Co-developed-by: VishalDhingra <vdhingra@vmware.com>
Signed-off-by: Chirag Shah <chirag@nvidia.com>
problem: table-id gets overwritten for a given route.
RCA: table-id was getting overwritten from the NB layer,
So route was getting installed with the latest table-id.
Fix: make the table-id as the key in the NB layer.
This will program the route in zebra correctly.
- Removed the table-id modify callbacks.
- Moved the validate and apply table-id changes to path-list creation
issue #7347
Signed-off-by: vishaldhingra <vdhingra@vmware.com>
During the yangification of staticd, refactoring of code
around static_hold_route data struct has been done, In this
context warning log message when VRF is not ready had been
removed. This should not be removed, adding it back.
I have missed one MPLS validation too, adding it back.
Signed-off-by: vishaldhingra <vdhingra@vmware.com>
Configuration example:
ip route 9.9.9.9/32 6.6.6.6 color 123
The SR Policy to be chosen is uniquely identified by the policy
endpoint (6.6.6.6) and the SR-TE color (123). Traffic will be
augmented with an MPLS label stack according to the active
candidate path of that particular policy.
Co-authored-by: GalaxyGorilla <sascha@netdef.org>
Signed-off-by: Sebastien Merle <sebastien@netdef.org>
To address the ip mroute command there is a need to add
safi as a key. So adding the afi-safi-type identityref
as a key.
Signed-off-by: VishalDhingra <vdhingra@vmware.com>
1. Modifies the data structs to make the distance, tag and table-id
property of a route, i.e created a hireachical data struct to save
route and nexthop information.
2. Backend northbound implementation
Signed-off-by: VishalDhingra <vdhingra@vmware.com>
