in the CLI we state that the bandwidth of a link is
in Megabits per second, but when converting it to
Bytes per second for TE purposes we were treating
it as Kilobits. Fix the conversion error.
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
the interface name was not present in the hook in charge of updating the
interface context to the registered hook service. For that, update the
name before informing it.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
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>
Having a fixed set of parameters for each northbound callback isn't a
good idea since it makes it difficult to add new parameters whenever
that becomes necessary, as several hundreds or thousands of existing
callbacks need to be updated accordingly.
To remediate this issue, this commit changes the signature of all
northbound callbacks to have a single parameter: a pointer to a
'nb_cb_x_args' structure (where x is different for each type
of callback). These structures encapsulate all real parameters
(both input and output) the callbacks need to have access to. And
adding a new parameter to a given callback is as simple as adding
a new field to the corresponding 'nb_cb_x_args' structure, without
needing to update any instance of that callback in any daemon.
This commit includes a .cocci semantic patch that can be used to
update old code to the new format automatically.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Replace sprintf with snprintf where straightforward to do so.
- sprintf's into local scope buffers of known size are replaced with the
equivalent snprintf call
- snprintf's into local scope buffers of known size that use the buffer
size expression now use sizeof(buffer)
- sprintf(buf + strlen(buf), ...) replaced with snprintf() into temp
buffer followed by strlcat
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Remove gcc 4.x workaround for variable size array as gcc
check moved to header file.
In lib/northbound.h : struct frr_yang_module_info made
size 1000 for gcc 4.x, where maximum 1000 nodes can fit.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
This fixes a theoretical bug that could occur when trying to change an
ifindex on an interface to that of an existing interface. We would
remove the interface from the ifindex tree, and change the ifindex, but
when we tried to reinsert the interface, the insert would fail. It was
impossible to know if this failed due to the insertion / deletion macros
capturing the result value of the underlying BSD tree macros. So we
would effectively delete the interface.
Instead of failing on insert, we just check if the prospective ifindex
already exists and return -1 if it does.
Macros have been changed to statement expressions so the result can be
checked, and bubbled up.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Old gcc versions (< 5.x) have a bug that prevents C99 flexible
arrays from working properly on shared libraries.
We already have a hack in place to work around this problem, but it
needs to be replicated in every declaration of a frr_yang_module_info
variable within libfrr. This clearly isn't a good solution if we
consider that many more libfrr YANG modules are about to come in
the future.
This commit introduces a different workaround that operates within
the northbound layer itself, such that implementers of libfrr YANG
modules won't need to worry about this problem anymore.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Add some additional output/debug to code to allow
us to see the vrf name instead of just the vrf id.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The previous workaround only works for -O0, at higher optimization
levels gcc reorders the statements in the file global scope which breaks
the asm statement :(.
Fixes: #4563Fixes: #5074
Signed-off-by: David Lamparter <equinox@diac24.net>
gcc 4.x does not properly support structs with variable length array
members. Specifically, for global variables, it completely ignores the
array, coming up with a size much smaller than what is correct. This is
broken for both sizeof() as well as ELF object size.
This breaks for frr_interface_info since this variable is in some cases
copy relocated by the linker. (The linker does this to make the address
of the variable a "constant" for the main program.) This copying uses
the ELF object size, thereby copying only the non-array part of the
struct.
Breakage ensues...
(This fix is a bit ugly, but it's limited to very old gcc, and it's
better than changing the array to "nodes[1000]" and wasting memory...)
Fixes: #4563Fixes: #5074
Signed-off-by: David Lamparter <equinox@diac24.net>
Cleanup the interface creation apis to make it more
clear what they are doing.
Make it explicit that the creation via name/ifindex will
only add it to the appropriate list.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
If the name has not been set yet (we were only passed the
ifindex in some cases like with master/slave timings) then
do not add/del it from the ifname rb tree on the vrf struct.
Doing so causes duplicate entries on the tree and infinte loops
can happen when iterating over it.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Current autocompletion works only for simple "vrf NAME" case.
This commit expands it also for the following cases:
- "nexthop-vrf NAME" in staticd
- usage of $varname in many daemons
All daemons are updated to use single varname "$vrf_name".
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
For all the places we have a zclient->interface_up convert
them to use the interface ifp_up callback instead.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Switch the zclient->interface_add functionality to have everyone
use the interface create callback in lib/if.c
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Start the conversion to allow zapi interface callbacks to be
controlled like vrf creation/destruction/change callbacks.
This will allow us to consolidate control into the interface.c
instead of having each daemon read the stream and react accordingly.
This will hopefully reduce a bunch of cut-n-paste stuff
Create 4 new callback functions that will be controlled by
lib/if.c
create -> A upper level protocol receives an interface creation event
The ifp is brand spanking newly created in the system.
up -> A upper level protocol receives a interface up event
This means the interface is up and ready to go.
down -> A upper level protocol receives a interface down
destroy -> A upper level protocol receives a destroy event
This means to delete the pointers associated with it.
At this point this is just boilerplate setup for future commits.
There is no new functionality.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When zebra gets a callback from the kernel that an interface has
actually been deleted *and* the end users has not configured
the interface, then allow for deletion of the interface from zebra.
This is especially important in a docker environment where containers
and their veth interfaces are treated as ephermeal. FRR can quickly
have an inordinate amount of interfaces sitting around that are
not in the kernel and we have no way to clean them up either.
My expectation is that this will cause a second order crashes
in upper level protocols, but I am not sure how to catch these
and fix them now ( suggestions welcome ). There are too many
use patterns and order based events that I cannot know for certain
that we are going to see any at all, until someone sees this problem
as a crash :( I do not recommend that this be put in the current
stabilization branch and allow this to soak in master for some time
first.
Testing:
sharpd@donna ~/frr4> sudo ip link add vethdj type veth peer name vethjd
sharpd@donna ~/frr4> sudo ip link add vethaa type veth peer name vethab
sharpd@donna ~/frr4> sudo vtysh -c "show int brief"
Interface Status VRF Addresses
--------- ------ --- ---------
dummy1 down default
enp0s3 up default 10.0.2.15/24
enp0s8 up default 192.168.209.2/24
enp0s9 up default 192.168.210.2/24
enp0s10 up default 192.168.212.4/24
lo up default 10.22.89.38/32
vethaa down default
vethab down default
vethdj down default
vethjd down default
virbr0 up default 192.168.122.1/24
virbr0-nic down default
sharpd@donna ~/frr4> sudo ip link set vethaa up
sharpd@donna ~/frr4> sudo ip link set vethab up
sharpd@donna ~/frr4> sudo ip link del vethdj
sharpd@donna ~/frr4> sudo vtysh -c "show int brief"
Interface Status VRF Addresses
--------- ------ --- ---------
dummy1 down default
enp0s3 up default 10.0.2.15/24
enp0s8 up default 192.168.209.2/24
enp0s9 up default 192.168.210.2/24
enp0s10 up default 192.168.212.4/24
lo up default 10.22.89.38/32
vethaa up default
vethab up default
virbr0 up default 192.168.122.1/24
virbr0-nic down default
sharpd@donna ~/frr4> sudo ip link del vethaa
sharpd@donna ~/frr4> sudo vtysh -c "show int brief"
Interface Status VRF Addresses
--------- ------ --- ---------
dummy1 down default
enp0s3 up default 10.0.2.15/24
enp0s8 up default 192.168.209.2/24
enp0s9 up default 192.168.210.2/24
enp0s10 up default 192.168.212.4/24
lo up default 10.22.89.38/32
virbr0 up default 192.168.122.1/24
virbr0-nic down default
sharpd@donna ~/frr4> sudo ip link add vethaa type veth peer name vethab
sharpd@donna ~/frr4> sudo vtysh -c "show int brief"
Interface Status VRF Addresses
--------- ------ --- ---------
dummy1 down default
enp0s3 up default 10.0.2.15/24
enp0s8 up default 192.168.209.2/24
enp0s9 up default 192.168.210.2/24
enp0s10 up default 192.168.212.4/24
lo up default 10.22.89.38/32
vethaa down default
vethab down default
virbr0 up default 192.168.122.1/24
virbr0-nic down default
sharpd@donna ~/frr4> sudo vtysh -c "show run"
Building configuration...
Current configuration:
!
frr version 7.2-dev
frr defaults datacenter
hostname donna.cumulusnetworks.com
log stdout
no ipv6 forwarding
!
ip route 192.168.3.0/24 192.168.209.1
ip route 192.168.4.0/24 blackhole
ip route 192.168.5.0/24 192.168.209.1
ip route 192.168.6.0/24 192.168.209.1
ip route 192.168.7.0/24 99.99.99.99 nexthop-vrf EVA
ip route 192.168.8.0/24 192.168.209.1
ip route 4.5.6.7/32 12.13.14.15
!
interface dummy1
ip address 12.13.14.15/32
!
interface vethaa
description FROO
!
line vty
!
end
sharpd@donna ~/frr4> sudo ip link del vethaa
sharpd@donna ~/frr4> sudo vtysh -c "show int brief"
Interface Status VRF Addresses
--------- ------ --- ---------
dummy1 down default
enp0s3 up default 10.0.2.15/24
enp0s8 up default 192.168.209.2/24
enp0s9 up default 192.168.210.2/24
enp0s10 up default 192.168.212.4/24
lo up default 10.22.89.38/32
vethaa down default
virbr0 up default 192.168.122.1/24
virbr0-nic down default
sharpd@donna ~/frr4> sudo vtysh -c "show run"
Building configuration...
Current configuration:
!
frr version 7.2-dev
frr defaults datacenter
hostname donna.cumulusnetworks.com
log stdout
no ipv6 forwarding
!
ip route 192.168.3.0/24 192.168.209.1
ip route 192.168.4.0/24 blackhole
ip route 192.168.5.0/24 192.168.209.1
ip route 192.168.6.0/24 192.168.209.1
ip route 192.168.7.0/24 99.99.99.99 nexthop-vrf EVA
ip route 192.168.8.0/24 192.168.209.1
ip route 4.5.6.7/32 12.13.14.15
!
interface dummy1
ip address 12.13.14.15/32
!
interface vethaa
description FROO
!
line vty
!
end
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Adding a lock to protect the global running configuration doesn't
help much since the FRR daemons are not prepared to process
configuration changes in a pthread that is not the main one (a
whole lot of new protections would be necessary to prevent race
conditions).
This means the lock added by commit 83981138 only adds more
complexity for no benefit. Remove it now to simplify the code.
All northbound clients, including the gRPC one, should either run
in the main pthread or use synchronization primitives to process
configuration transactions in the main pthread.
This reverts commit 83981138fe.
FRR has two implementations of VRF, one backed by netns and the other by
the proper VRF implementation in the Linux kernel. In certain places, the
code assumes that a VRF is netns and so lookups fail. One example of this
is in IPv6 RA code. This causes functionality such as Unnumbered BGP to
fail. To fix this, this patch makes if_lookup_by_index handle the
behavior based on the backend, similar to if_get_by_index. For the two
places in if.c that were calling if_lookup_by_index to be specific to
the VRF, I renamed the existing code, if_lookup_by_ifindex and made it a
static function that is never exposed or called by any routine outside of
if.c.
Signed-off-by: Dinesh G Dutt <5016467+ddutt@users.noreply.github.com>
In if_netlink.c, when an interface structure, ifp, is first created,
its possible for the master to come up after the slave interface does.
This means, the slave interface has no way to display the master's ifname
in show outputs. To fix this, we need to allow creation by ifindex instead
of by ifname so that this issue is handled.
Signed-off-by: Dinesh G Dutt<5016467+ddutt@users.noreply.github.com>
For some reason, the compiler on OpenBSD on our CI boxes doesn't like
struct initializers with ".a.b = x, .a.c = y", generating a warning
about overwritten initializers...
Signed-off-by: David Lamparter <equinox@diac24.net>
Field vrf_id is replaced by the pointer of the struct vrf *.
For that all other code referencing to (interface)->vrf_id is replaced.
This work should not change the behaviour.
It is just a continuation work toward having an interface API handling
vrf pointer only.
some new generic functions are created in vrf:
vrf_to_id, vrf_to_name,
a zebra function is also created:
zvrf_info_lookup
an ospf function is also created:
ospf_lookup_by_vrf
it is to be noted that now that interface has a vrf pointer, some more
optimisations could be thought through all the rest of the code. as
example, many structure store the vrf_id. those structures could get
the exact vrf structure if inherited from an interface vrf context.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
vrf_id parameter is replaced with struct vrf * parameter. It is
needed to create vrf structure before entering in the fuction.
an error is generated in case the vrf parameter is missing.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
there may be cases where the vrf is yet allocated from the vty, and the
discovery process did not make the relationship between the vrf_id and
the name of the vrf. For instance, by parsing an interface belonging to
vrf-id X, it is not sure that vrf-id X and vrfname XX are talking about
the same vrf. For that, lets allocate the vrf, and lets try to detect
there is a duplicate case in vrf, so that the merge can be done without
any impact for the user.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
