when removing bgp instance, the parsing of rm->info contexts must be
protected. Also, the main level of hierarchy of rds must not be
allocated more than once.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This is mostly to be consistent with the "show ip import-check"
command, which is very similar.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Favor usage of the afi_t enumeration to identify address-families
over using the classic AF_INET[6] constants for that. The choice to
use either of the two seems to be mostly arbitrary throughout our
code base, which leads to confusion and bugs like the one fixed by
commit 6f95d11a1. To address this problem, favor usage of the afi_t
enumeration whenever possible, since 1) it's an enumeration (helps
the compilers to catch some bugs), 2) has a safi_t sibling and 3)
can be used to index static arrays. AF_INET[6] should then be used
only when interfacing with the kernel or external libraries like
libc. The family2afi() and afi2family() functions can be used to
convert between the two different representations back and forth.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
In the CLI code, each cmd_token has both a "text" field, containing
the full token text (e.g. "unicast"), and an "arg" field,
containing the original text entered by the user (which might be
an abbreviation, like "uni" instead of "unicast").
To avoid the need to handle abbreviations, the recommended pattern
for DEFUN commands is to use the "text" value of fixed parameters
and the "arg" value of everything else.
Using DEFPY, however, the CLI parameters are automagically turned
into C variables which are initialized under the hood (so that
they're conveniently ready for use). The problem is that this
initialization was always using the "arg" value of the parameters,
which was leading to problems like these:
debian# show ipv6 route isi
Unknown route type
debian#
debian# conf t
debian(config)# router isis 1
debian(config-router)# redistribute ipv4 st level-1
% Configuration failed.
Invalid value "st" in "protocol" element.
YANG path: /frr-isisd:isis/instance[area-tag='1']/redistribute/ipv4[protocol='st']/protocol
To fix these problems (and probably others too), make DEFPY commands
auto-detect the type of the input parameters and use either the
"arg" or "text" value from the cmd_tokens accordingly.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
`gate_buf` should be big enough to hold IPv6 addresses and `inet_ntop`
should be run in the correct `sockaddr` struct member.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Debug messages should use `prefix_buf` and `prefix2str` should only be
called once in `kernel_rtm`.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Now that all daemons receive the VRF backend from zebra, we can get
rid of vrf_is_mapped_on_netns() in favor of using the more convenient
vrf_is_backend_netns() function, which doesn't require any argument.
This commit also fixes the following problem:
debian(config)# ip route 50.0.0.0/8 blackhole vrf FAKE table 2
% table param only available when running on netns-based vrfs
Even when zebra was started with the --vrfwnetns, the error
above would be displayed since the VRF FAKE didn't exist, which
would make vrf_is_mapped_on_netns() return 0 incorrectly. Using
vrf_is_backend_netns() this problem doesn't happen anymore.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Add a new field in the ZEBRA_CAPABILITIES zapi message specifying
the VRF backend in use.
For simplicity, make the zclient code call vrf_configure_backend()
to apply the received value automatically instead of requiring
the daemons to do that themselves in their zebra_capabilities()
callbacks.
Additionally, call zebra_vrf_update_all() only after sending the
capabilities message to the client, so that it will know which VRF
backend is in use when processing the VRF messages.
This commit fixes a couple of bugs in the "interface" CLI command and
associated northbound callbacks, which behave differently depending
on the VRF backend in use. Before this commit, the vrf_backend
variable would always be set to VRF_BACKEND_NETNS in the client
daemons, even when zebra was started without the --vrfwnetns option.
This could lead to inconsistent behavior and subtle bugs under
specific circumstances.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
We can make use of the vty->config variable to know when the CLI
user is in the configuration mode or not. This is much simpler
than obtaining this information from the vty node, and also a more
robust solution (the three switch statements below, for example,
were out of sync).
Also, fix a bug where vty->config wasn't being unset in the
vty_config_exit() function (bug introduced by commit f344c66ea3).
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
The CLI code uses the vty->xpath[] array and the vty->xpath_index
variables to keep track of where the user is in the configuration
hierarchy. As such, we were resetting vty->xpath_index to zero
whenever the user exited from the configuration mode in order to
keep the index valid. We weren't doing this in the vty_stop_input()
function however, which is called when the user types ^C in the
terminal. This was leading to bugs like this:
zebra> en
zebra# conf t
zebra(config)# interface eth0
zebra(config-if)# ^C
zebra# conf t
zebra(config)# interface eth0
% Configuration failed.
Schema node not found.
YANG path: /frr-interface:lib/interface[name='eth0'][vrf='default']/frr-interface:lib
To fix this, do something more clever: instead of resetting the
XPath index whenever the user exits from the configuration mode,
do that when the user enters in the configuration mode. This way
the XPath index needs to be reset in a single place only, not to
mention it's a more robust solution.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
ripd and ripngd were leveraging the zclient code to keep track of
the redistribute configuration, which is what most daemons do. The
problem, however, is that the zclient code uses VRF IDs to identify
VRFs, and VRF IDs are unknown until a VRF is enabled (information
received from zebra). This means we can't configure a redistribute
command on a RIP instance when the corresponding VRF is disabled
(doing so leads to a null-dereference crash right now in both ripd
and ripngd).
To fix this, change the rip/ripng data structures so that they
keep track of the full redistribute configuration and not only the
route-map and metric associated to each command. This is similar
to what bgpd and ospfd are doing to solve the same problem. In the
future the zclient code and all daemons need to be refactored to
consolidate the handling of redistribute configuration in a single
place to reduce code duplication. One of the most important changes
to do is to use VRF names and not VRF IDs to identify VRFs.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Description of the new parameter (adapted from the ietf-rip module):
"VRF name identifying a specific RIPng instance.
This leaf is optional for the rpc.
If it is specified, the rpc will clear all routes in the
specified RIPng instance;
if it is not specified, the rpc will clear all routes in
all RIPng instances.";
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
* Turn the "instance" YANG presence-container into a YANG list keyed
by the new "vrf" leaf. This is a backward incompatible change but
this should be ok for now.
* RIPng VRF instances can be configured even when the corresponding
VRF doesn't exist. And a RIPng VRF instance isn't deleted when
the corresponding VRF is deleted. For this to work, implement the
ripng_instance_enable() and ripng_instance_disable() functions
that are called to enable/disable RIPng routing instances when
necessary. A RIPng routing instance can be enabled only when the
corresponding VRF is enabled (this information comes from zebra
and depends on the underlying VRF backend). Routing instances are
stored in the new ripng_instances rb-tree (global variable).
* Add a vrf pointer to the ripng structure instead of storing vrf_id
only. This is much more convenient than using vrf_lookup_by_id()
every time we need to get the vrf pointer from the VRF ID. The
ripng->vrf pointer is updated whenever the VRF enable/disable hooks
are called.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Description of the new parameter (adapted from the ietf-rip module):
"VRF name identifying a specific RIP instance.
This leaf is optional for the rpc.
If it is specified, the rpc will clear all routes in the
specified RIP instance;
if it is not specified, the rpc will clear all routes in
all RIP instances.";
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
* Turn the "instance" YANG presence-container into a YANG list keyed
by the new "vrf" leaf. This is a backward incompatible change but
this should be ok for now.
* RIP VRF instances can be configured even when the corresponding
VRF doesn't exist. And a RIP VRF instance isn't deleted when
the corresponding VRF is deleted. For this to work, implement the
rip_instance_enable() and rip_instance_disable() functions that are
called to enable/disable RIP routing instances when necessary. A
RIP routing instance can be enabled only when the corresponding
VRF is enabled (this information comes from zebra and depends on
the underlying VRF backend). Routing instances are stored in the new
rip_instances rb-tree (global variable).
* Add a vrf pointer to the rip structure instead of storing vrf_id
only. This is much more convenient than using vrf_lookup_by_id()
every time we need to get the vrf pointer from the VRF ID. The
rip->vrf pointer is updated whenever the VRF enable/disable hooks
are called.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
The ripd code can handle this error just fine (e.g. reject the
configuration transaction), there's no need to exit when a socket
fails to be created.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
For unknown reasons, the IP_MULTICAST_IF sockoption doesn't
seem to work when the given socket is bound to a VRF device on
Linux. Switch from sendto() to sendmsg() so that we can specify the
outgoing interface of multicast packets using IP_PKTINFO ancillary
data. This also makes ripd more consistent with ripngd, which also
uses sendmsg() to send packets on the wire.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
When lyd_validate() is used with the LYD_OPT_DATA option, full YANG
validation is performed. As a side-effect to this, default nodes are
created, which is not desirable when displaying operational data
since configuration nodes can also be created. Use LYD_OPT_GET
option to resolve this problem.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
One use case for the new yang_data_list_find() function is to find
input parameters in RPC northbound callbacks easily, without the
need to iterate over the input parameters manually.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Parameters should be const whenever possible to improve code
readability and remove the need to cast away the constness of
const arguments.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
This is the last step to make ripngd ready for multi-instance
support.
Remove the ripng global variable and add a "ripng" parameter
to all functions that need to know the RIPng instance they are
working on. On some functions, retrieve the RIPng instance from
the interface variable when it exists (this assumes interfaces can
pertain to one RIPng instance at most, which is ok for VRF support).
In preparation for the next commits (VRF support), add a "vrd_id"
member to the ripng structure, and use ripng->vrf_id instead of
VRF_DEFAULT wherever possible.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
This is an old standing bug where the list of RIPng peers wasn't
cleared after deconfiguring RIPng, which caused the existing peers
to still be present on a newly configured RIPng instance (except
when the timed out after ~3 minutes). Fix this.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
* Call ripng_clean() only when RIPng is configured, this way we can
remove one indentation level from this function.
* ripng_redistribute_clean() is only called on shutdown, so there's
no need to call ripng_redistribute_withdraw() there since the RIPng
table is already cleaned up elsewhere.
* Deallocate the ripng structure only at the end of the function. This
prepares the ground for the next commits where all global variables
will be moved to the ripng structure.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
This is the last step to make ripd ready for multi-instance support.
Remove the rip global variable and add a "rip" parameter to all
functions that need to know the RIP instance they are working
on. On some functions, retrieve the RIP instance from the interface
variable when it exists (this assumes interfaces can pertain to
one RIP instance at most, which is ok for VRF support).
In preparation for the next commits (VRF support), add a "vrd_id"
member to the rip structure, and use rip->vrf_id instead of
VRF_DEFAULT wherever possible.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
This is an old standing bug where the list of RIP peers wasn't
cleared after deconfiguring RIP, which caused the existing peers
to still be present on a newly configured RIP instance (except when
the timed out after ~3 minutes). Fix this.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
The only sideeffect of this change is that these counters will be
reset when RIP is deconfigured and then configured again, but this
shouldn't be a problem as the RIP MIB isn't specific about this.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
None of these variables or functions were being used since the
initial revision ~16 years ago. It's safe to say we can remove
them now.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
