Nobody uses it, but it's got the same definition. Move the parser
function into zclient.c and use it.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
* Add DEBUG*() macros
This set of macros allows you to write printf-like debugging lines that
automatically check whether a debug is on before printing. This should
eliminate the need for explicit checks in simple cases. For example:
if (SUCH_AND_SUCH_DEBUG_IS_ON) {
zlog_warn(...);
}
Becomes:
DEBUG(warn, such_and_such, ...);
Or, equivalently,
DEBUGE(such_and_such, ...);
The levels passed to DEBUG are expanded into the names of zlog_*
functions, so the same zlog levels are available. There's also a set of
macros that have the level built into them; DEBUGE for errors, DEBUGW
for warnings, etc. Good for brevity.
* Add singular setting macros
Change the 'SET' macros to accept a boolean indicating whether the
provided bits should be set or unset, and map on/off macros to them.
Helps condense code where you already have a boolean condition that
tells you what you want to do as you can avoid writing the branch.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Also modify `struct route_entry` to use nexthop_groups.
Move ALL_NEXTHOPS loop to nexthop_group.h
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Allow the calling daemon to pass down what table-id we
want to use to install the route. Useful for PBR.
The vrf id passed must be the VRF_DEFAULT else this
value is ignored.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The work_queue_free function free'd up the wq pointer but
did not set it too NULL. This of course causes situations
where we may use the work_queue after it is freed. Let's
modify the work_queue to set the pointer for you.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
If a interested party removes one of it's routes let
it know that it has happened as asked for.
Add a ZAPI_ROUTE_REMOVED to the send of the route_notify_owner
Add a ZAPI_ROUTE_REMOVE_FAIL to the send of the route_notify_owner
Add code in sharpd to notice this and to allow it to keep
track of routes removed for that invocation and give timing
results.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The buffer size is currently 4k. Increase x4 times to allow for bigger
messages to be sent over the zapi.
The current size sufficient for most cases, but there are a couple
of cases with installing data to the kernel ip rules where we will
quickly hit this 4k size limit. I forsee flowspec getting close
to this limit as well.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The NS_DEFAULT value returns UNKNOWN in the case the vrf lite backend is
used, whereas this is wrong. This commit fixes the default value.
Also, it fixes the default value in the case NETNS support from system
is not ok, or some error can occur when reading default NS at startup.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The current strategy for fine-grained debugging across FRR is to use
static long int bitfields, in combination with helper macros that are
copy-pasted between daemons, to hold state on what debugging information
should be collected at any given time. This has a couple of problems:
* These bitfields are generally extern'd and accessed everywhere, so
they are not MT-safe or easy to make MT-safe
* Lots of code duplication from copy-pasting the DEBUG_* macros...
* Code duplication because of the "term" vs "conf" debugging concept
This patch aims to remedy that by providing some infrastructure to work
with debugs. The core concept of using bitfields has been retained, but
the number of these for each debug has been reduced to 1. This allows
easy use of lock-free methods for synchronizing access to debugging
info.
The helper macros have also been retained but they are now collected in
one place and perform exclusively atomic operations.
Finally there is a bit of code that allows daemons to register
callbacks, which I used to implement a command that will toggle all
debugging for any daemons that use these facilities.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Add the originating routes type and instance to the nexthop
update message. This is necessary because there exist
scenarios where BGP needs to make a decision about the
originating route type and instance to know if it is
going to be doing a route replace to a route that would
resolve to itself.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The addition of some rmac code snuck in the usage of a
stream_get instead of a STREAM_GET()
We need to be using STREAM_GET()
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Implement support for EVPN symmetric routing for IPv6 routes. The next hop
for EVPN routes is the IP address of the remote VTEP which is only an IPv4
address. This means that for IPv6 symmetric routing, there will be IPv6
destinations with IPv4 next hops. To make this work, the IPv4 next hops are
converted into IPv4-mapped IPv6 addresses.
As part of support, ensure that "L3" route-targets are not announced with
IPv6 link-local addresses so that they won't be installed in the routing
table.
Signed-off-by: Vivek Venkatraman vivek@cumulusnetworks.com
Reviewed-by: Mitesh Kanjariya mitesh@cumulusnetworks.com
Reviewed-by: Donald Sharp sharpd@cumulusnetworks.com
Because socket creation is tightly linked with socket binding for vrf
lite, the proposal is made to extend socket creation APIs and to create
a new API called vrf_bind that applies to vrf lite. The passed interface
name is the interface that will be bound to the socket passed.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
That API can be used to wrap the ioctl call with various vrf instances.
This permits transparently doing the ioctl() call without taking into
consideration the vrf backend kind.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This split is introducing logicalrouter.[ch] as the file that contains
the vty commands to configure logical router feature. The split has as
consequence that the backend of logical router is linux_netns.c formerly
called ns.c. The same relationship exists between VRF and its backend
which may be linux_netns.c file.
The split is adapting ns and vrf fiels so as to :
- clarify header
- ensure that the daemon persepctive, the feature VRF or logical router
is called instead of calling directly ns.
- this implies that VRF will call NS apis, as logical router does.
Also, like it is done for default NS and default VRF, the associated VRF
is enabled first, before NETNS is enabled, so that zvrf->zns pointer is
valid when NETNS discovery applies.
Also, other_netns.c file is a stub handler that will be used for non
linux systems. As NETNS feature is only used by Linux, some BSD systems
may want to use the same backend API to benefit from NETNS. This is what
that file has been done.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The vrf_sockunion_socket() wraps sockunion_socket() with vrf_id as
additional parameter. The creation of socket forces the user to
transparently move to new NETNS for doing the operation.
The vrf_getaddr_info() wraps getaddr_info() with vrf_id as additional
parameter. That API relies on the underlying system. Then there may be
need to switch to an other netns in that case too.
Also, the vrf_socket() implementation is simplified.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
For supporting vrf based on namespaces, it is possible that an interface
with the same index is present. This is the case for loopback
interfaces. For that, for each query, if the interface is not found
, matching the vrf identifier, then a new interface is created, when the
backens for VRF is NETNS.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
when the netns backend is selected for VRF, the default VRF is being
assigned a NSID. This avoids the need to handle the case where if the
incoming NSID was 0 for a non default VRF, then a specific handling had
to be done to keep 0 value for default VRF.
In most cases, as the first NETNS to get a NSID will be the default VRF,
most probably the default VRF will be assigned to 0, while the other
ones will have their value incremented. On some cases, where the NSID is
already assigned for NETNS, including default VRF, then the default VRF
value will be the one derived from the NSID of default VRF, thus keeping
consistency between VRF IDs and NETNS IDs.
Default NS is attempted to be created. Actually, some VMs may have the
netns feature, but the NS initialisation fails because that folder is
not present.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Two apis are provided so that the switch from one netns to an other one
is taken care.
Also an other API to know if the VRF has a NETNS backend or a VRF Lite
backend.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
