This commit is a part of #5853 that add new cmd-node for SRv6 configuration.
This commit just add cmd-node and moving node cli only, acutual SRv6 config
command isn't added. (that is added later commit. of this branch)
new cli nodes:
* SRv6
* SRv6-locators
* SRv6-locator
Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
This commit checks seg6local route configuration via ZAPI is
working fine.
SRv6 feature is little young feature as kernel feature so netlink
interface may be changed/updated in the future. And this ZAPI extention
is something to support new routing paradigm, so it should be checked by
topotests until srv6 feature of linux kernel will be well stable.
Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
In this patch, we can install seg6local routes from shapd cli. New sub
command "sharp install route $PREFIX nexthop-seg6local" is added to
install seg6local routes via ZEBRA_ROUTE_ADD. This is for the behaviour
test(topotest) to ensure SRv6 ZAPI is working fine.
NEW-CLI:
sharp install routes 1::1 nexthop-seg6local dum0 End 1
sharp install routes 2::1 nexthop-seg6local dum0 End_X 2001::1 1
sharp install routes 3::1 nexthop-seg6local dum0 End_T 10 1
sharp install routes 4::1 nexthop-seg6local dum0 End_DX4 10.0.0.1 1
SRv6 routes are installed as NEXTHOP_IFINDEX routes because of seg6local
specification. seg6local routes depends the output device status instead
of routing-nexthop.
FYI:
In seg6local implementation, kernel don't care RTA_OIF on the nexthop
deeply but some requirement are exist as follow.
(a) DEV isn't loopback interface
(b) DEV's ipv6 status is enabled
(c) DEV's enslaving status is the same with target-route
Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
current route addition mechanism on shaprd support only ipv4/v6 nexthop
routes simply. so It doesn't need to ensure flags of zapi_routes.
Then when we want to configure more complicated routing feature (like a
srv6), we will want to control flags of zapi_route. In this patch, it
will supports to configure flags of zapi_route when sharpd calls
ZEBRA_ROUTE_ADD.
Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
FRRouting operator can install seg6local route via ZAPI,
But linux kernel operator also can install seg6local route
via Netlink directry (i.e. iproute2)
This commit make zebra to parse non-frr seg6local
route configuration via netlink and audit Zebra's RIB.
Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
With this patch, zclient can intall seg6local rotues whem
they set properties nh_seg6local_{action,ctx} on struct nexthop
and set ZEBRA_FLAG_SEG6LOCAL_ROUTE on zapi_route's flag.
Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
This commit is a part of #5853 works that add new nexthop's addional
object for SRv6 routing about seg6local route. Before this commit,
we can add MPLS info as additional object on nexthop.
This commit make it add more support about seg6local routes.
seg6local routes are ones of the LWT routing mechanism,
so configuration of seg6local routes is performed by
ZEBRA_ROUTE_SEND, it's same as MPLS configuration.
Real configuration implementation isn't implemented at this commit.
later commit add that. This commit add only nexthop additional object
and some misc functions.
Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
Make seg6local_context2str function's prototype better.
This function is added on commit e496b4203, and function
interface's considering wasn't enough.
Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
The backoff code assumed that yang operations always completed quickly.
It checked for > 100 YANG modeled commands happening in under 1 second
to enable batching. If 100 yang modeled commands always take longer than
1 second batching is never enabled. This is the exact opposite of what
we want to happen since batching speeds the operations up.
Here are the results for libyang2 code without and with batching.
| action | 1K rts | 2K rts | 1K rts | 2K rts | 20k rts |
| | nobatch | nobatch | batch | batch | batch |
| Add IPv4 | .881 | 1.28 | .703 | 1.04 | 8.16 |
| Add Same IPv4 | 28.7 | 113 | .590 | .860 | 6.09 |
| Rem 1/2 IPv4 | .376 | .442 | .379 | .435 | 1.44 |
| Add Same IPv4 | 28.7 | 113 | .576 | .841 | 6.02 |
| Rem All IPv4 | 17.4 | 71.8 | .559 | .813 | 5.57 |
(IPv6 numbers are basically the same as iPv4, a couple percent slower)
Clearly we need this. Please note the growth (1K to 2K) w/o batching is
non-linear and 100 times slower than batched.
Notes on code: The use of the new `nb_cli_apply_changes_clear_pending`
is to commit any pending changes (including the current one). This is
done when the code would not correctly handle a single diff that
included the current changes with possible following changes. For
example, a "no" command followed by a new value to replace it would be
merged into a change, and the code would not deal well with that. A good
example of this is BGP neighbor peer-group changing. The other use is
after entering a router level (e.g., "router bgp") where the follow-on
command handlers expect that router object to now exists. The code
eventually needs to be cleaned up to not fail in these cases, but that
is for future NB cleanup.
Signed-off-by: Christian Hopps <chopps@labn.net>
the config for dynamic candidate paths with bandwidth preferences
was using a different order of keywords (required bandwidth X) than
the corresponding command (bandwidth X required). This confuses
frr-reload, and possibly users too. Make both use the same order.
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
The code that actually calls FRR northbound functions needs to be running in the
master thread. The previous code was running on a GRPC pthread. While fixing
moved to more functional vs OOP to make this easier to see.
Also fix ly merge to merge siblings not throw the originals away.
Signed-off-by: Christian Hopps <chopps@labn.net>
Never send an interface name/index for multihop sessions. It breaks
"neighbor A.B.C.D update-source" config in BGP.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
There are two possible use-cases for the `vrf_bind` function:
- bind socket to an interface in a vrf
- bind socket to a vrf device
For the former case, there's one problem - success is returned when the
interface is not found. In that case, the socket is left unbound without
throwing an error.
For the latter case, there are multiple possible problems:
- If the name is not set, then the socket is left unbound (zebra, vrrp).
- If the name is "default" and there's an interface with that name in the
default VRF, then the socket is bound to that interface.
- In most daemons, if the router is configured before the VRF is actually
created, we're trying to open and bind the socket right after the
daemon receives a VRF registration from zebra. We may not receive the
VRF-interface registration from zebra yet at that point. Therefore,
`if_lookup_by_name` fails, and the socket is left unbound.
This commit fixes all the issues and updates the function description.
Suggested-by: Pat Ruddy <pat@voltanet.io>
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Return SUCCESS if trying to delete route that doesn't exist.
This was always staticd's behavior before the northbound
conversion.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
