This commit adds ZAPI encoders & decoders for traffic control operations, which
include tc_qdisc, tc_class and tc_filter.
Signed-off-by: Siger Yang <siger.yang@outlook.com>
At this point add abilty for the encode/decode of the
resilience down ZAPI to zebra. Just hookup sharpd
at this point in time.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
In this commit, we extend the ZAPI to support encoding and decoding the
locator flags contained in the messages exchanged between zebra and the
routing daemons.
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
The code was working but the coverity scan reported a failure.
Clarify the code to make the coverity scan happy.
Fixes: fe0a129687 ("lib,zebra: link-params are not flushed after no enable")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Daemons like isisd continue to use the previous link-params after they
are removed from zebra.
For example,
>r0# sh run zebra
> (...)
> interface eth-rt1
> link-params
> enable
> metric 100
> exit-link-params
> r0# conf
> r0(config)# interface eth-rt1
> r0(config-if)# link-params
> r0(config-link-params)# no enable
After "no enable", "sh run zebra" displays no more link-params context.
The "no enable" causes the release of the "link_params" pointer within
the "interface" structure. The zebra function to update daemons with
a ZEBRA_INTERFACE_LINK_PARAMS zapi message is called but the function
returns without doing anything because the "link_params" pointer is
NULL. Therefore, the "link_params" pointers are kept in daemons.
When the zebra "link_params" pointer is NULL:
- Send a zapi link param message that contains no link parameters
instead of sending no message.
- At reception in daemons, the absence of link parameters causes the
release of the "link_params" pointer.
Fixes: 16f1b9e ("Update Traffic Engineering Support for OSPFD")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Running `bgp_srv6l3vpn_to_bgp_vrf` and `bgp_srv6l3vpn_to_bgp_vrf2`
topotests with `--valgrind-memleaks` gives several memory leak errors.
This is due to the way FRR daemons pass local SIDs to zebra: to send a
local SID to zebra, FRR daemons call the `zclient_send_localsid()`
function.
The `zclient_send_localsid()` function performs the following sequence
of operations:
* create a temporary `struct nexthop`;
* call `nexthop_add_srv6_seg6local()` to fill the `struct nexthop` with
the proper local SID information;
* create a `struct zapi_route` and call `zapi_nexthop_from_nexthop()` to
copy the information from the `struct nexthop` to the
`struct zapi_route`;
* send the `struct zapi_route` to zebra through the ZAPI.
The `nexthop_add_srv6_seg6local()` function uses `XCALLOC()` to allocate
memory for the SRv6 nexthop. This memory is never freed.
Creating a temporary `struct nexthop` is unnecessary, as the local SID
information can be pushed directly to the `struct zapi_route`. This
patch simplifies the implementation of `zclient_send_localsid()` by
avoiding using the temporary `struct nexthop`. This eliminates the need
to use `nexthop_add_srv6_seg6local()` to fill the `struct nexthop` and
consequently fixes the memory leak.
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
Multipath route may have mixed nexthops of EVPN and IP unicast. Move
EVPN flag to nexthop to support such cases.
Signed-off-by: Xiao Liang <shaw.leon@gmail.com>
Don't rely on the OS interface name length definition and use the FRR
definition instead.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Currently the nexthop tracking code is only sending to the requestor
what it was requested to match against. When the nexthop tracking
code was simplified to not need an import check and a nexthop check
in b8210849b8 for bgpd. It was not
noticed that a longer prefix could match but it would be seen
as a match because FRR was not sending up both the resolved
route prefix and the route FRR was asked to match against.
This code change causes the nexthop tracking code to pass
back up the matched requested route (so that the calling
protocol can figure out which one it is being told about )
as well as the actual prefix that was matched to.
Fixes: #10766
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Currently, it is possible to rename the default VRF either by passing
`-o` option to zebra or by creating a file in `/var/run/netns` and
binding it to `/proc/self/ns/net`.
In both cases, only zebra knows about the rename and other daemons learn
about it only after they connect to zebra. This is a problem, because
daemons may read their config before they connect to zebra. To handle
this rename after the config is read, we have some special code in every
single daemon, which is not very bad but not desirable in my opinion.
But things are getting worse when we need to handle this in northbound
layer as we have to manually rewrite the config nodes. This approach is
already hacky, but still works as every daemon handles its own NB
structures. But it is completely incompatible with the central
management daemon architecture we are aiming for, as mgmtd doesn't even
have a connection with zebra to learn from it. And it shouldn't have it,
because operational state changes should never affect configuration.
To solve the problem and simplify the code, I propose to expand the `-o`
option to all daemons. By using the startup option, we let daemons know
about the rename before they read their configs so we don't need any
special code to deal with it. There's an easy way to pass the option to
all daemons by using `frr_global_options` variable.
Unfortunately, the second way of renaming by creating a file in
`/var/run/netns` is incompatible with the new mgmtd architecture.
Theoretically, we could force daemons to read their configs only after
they connect to zebra, but it means adding even more code to handle a
very specific use-case. And anyway this won't work for mgmtd as it
doesn't have a connection with zebra. So I had to remove this option.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Since f60a1188 we store a pointer to the VRF in the interface structure.
There's no need anymore to store a separate vrf_id field.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
zclient_send_localsid is called by various routing protocol daemons. To set the
srv6 endpoint function. Fix a hard-coded error in the initial implementation.
Before this PR, the srv6 function will be registered to zebra as a BGP route
even if isisd executes zclient_send_localsid.
Signed-off-by: Hiroki Shirokura <hiroki.shirokura@linecorp.com>
This removes a giant `switch { }` block from lib/zclient.c and
harmonizes all zclient callback function types to be the same (some had
a subset of the args, some had a void return, now they all have
ZAPI_CALLBACK_ARGS and int return.)
Apart from getting rid of the giant switch, this is a minor security
benefit since the function pointers are now in a `const` array, so they
can't be overwritten by e.g. heap overflows for code execution anymore.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
It allows FRR to read the interface config even when the necessary VRFs
are not yet created and interfaces are in "wrong" VRFs. Currently, such
config is rejected.
For VRF-lite backend, we don't care at all about the VRF of the inactive
interface. When the interface is created in the OS and becomes active,
we always use its actual VRF instead of the configured one. So there's
no need to reject the config.
For netns backend, we may have multiple interfaces with the same name in
different VRFs. So we care about the VRF of inactive interfaces. And we
must allow to preconfigure the interface in a VRF even before it is
moved to the corresponding netns. From now on, we allow to create
multiple configs for the same interface name in different VRFs and
the necessary config is applied once the OS interface is moved to the
corresponding netns.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Pass down the safi for when we need address
resolution. At this point in time we are
hard coding the safi to SAFI_UNICAST.
Future commits will take advantage of this.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
These are no longer really needed. The client just needs
to call nexthop resolution instead.
So let's remove the zapi types.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
As NHRP expects some notification of neighboring entries on GRE
interface, when a new interface notification is encountered, the
exact neighbor state flag is found. Previously, the flag passed
to the upper layer was forced to NDM_STATE which is REACHABLE,
as can be seen on below trace:
2021/08/25 10:58:39 NHRP: [QQ0NK-1H449] Netlink: new-neigh 102.1.1.1 dev gre1 lladdr 10.125.0.2 nud 0x2 cache used 1 type 5
When passing the real value, NHRP received an other value like STALE.
2021/08/25 11:28:44 NHRP: [QQ0NK-1H449] Netlink: new-neigh 102.1.1.1 dev gre1 lladdr 10.125.0.2 nud 0x4 cache used 0 type 5
This flag is important for NHRP, as it permits to monitor the link
layer of NHRP entries.
Fixes: d603c0774e ("nhrp, zebra, lib: enforce usage of zapi_neigh_ip structure")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When we get a bad value for the opaque data length, instead
of stopping the program, discard the data and move on.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
We are sending up to ZAPI_MESSAGE_OPAQUE_LENGTH but checking
for one less. We know the data will fit in it to that size.
Also we have asserts on the write to ensure we don't go over
it
Fixes: #8995
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Adding defensive code to the interface_link_params zebra callback
to check if the link params changed before taking action.
Signed-off-by: Karen Schoener <karen@voltanet.io>
The %p printf format specifier does already print the pointer address
with a leading "0x" prefix (indicating a hexadecimal number). There's
no need to add that prefix manually.
While here, replace explicit function names in log messages by
__func__.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
https://github.com/FRRouting/frr/pull/5865#discussion_r597670225
As this comment says. ZEBRA_FLAG_XXX should not have been used.
To communicate SRv6 Route Information. A simple Nexthop Flag would
have been sufficient for SRv6 information. And I fixed the whole
thing that way.
Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
I agree with the PR review from mstap and merged
the following two functions into one.
- zapi_nexthop_seg6_cmp
- zapi_nexthop_seg6local_cmp
[note]
If both of them have more complex extensions in the future,
I think it will be less confusing to remove the integration
of these functions and make them as separate functions as
before.
Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
This commit add usuful function to configure SRv6 localsid
which is represented with seg6local lwt route.
Now, it can support only NEXTHOP_TYPE_IFINDEX route.
Actual configurationof SRv6 localsid is performed with
ZEBRA_ROUTE_ADD. So this is just a wrapper function
for route-install.
Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
This commit add new nexthop's addional object for SRv6
routing about seg6 route. Before this commit,
we can add MPLS info as additional object on nexthop.
This commit make it add more support about seg6 routes.
seg6 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>
