There are certain interfaces that when brought up and we receive
the netlink notification about it, the speed of the interface is
not set correctly. This creates a one-shot thread that will
wait 15 seconds and then requery the speed and if it is different
it will renotify the running daemons.
The kernel should notify us on speed changes, unfortunately this
is not done currently via a netlink message as you would think.
As I understand it there is some in-fighting about the proper
way to approach this issue and due to the way the kernel release
cycle works we are a ways off from getting this fixed. This
is a `hack` to make us work correctly while we wait for the
true answer.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The rn can not have an rn->info pointer and as
such the dest may be NULL. Don't assign
the old_fib pointer if so. This is ok
because we know RNODE_FOREACH... will not
iterate if dest is NULL.
Fixes: #1575
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
EVPN is only enabled when user configures advertise-all-vni.
All VNIs (L2 and L3) should be cleared upon removal of this config.
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
For EVPN type-5 route the NH in the NLRI is set to the local tunnel ip.
This information has to be obtained from kernel notification.
We need to pass this info from zebra to bgp in l3vni call flow.
This patch doesn't handle the tunnel-ip change.
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
When a remote VTEP next hop entry (for symmetric routing) becomes
stale, reinstall it. This makes the behavior the same as what is
done for remote host next hops (for asymmetric routing and ARP
suppression).
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Upon a l3vni delete (no vni under a vrf) is executed,
we should uninstall all the RMACs and NHs associated with the l3vni.
This is because by the time we get a route delete in zebra
l3vni is already deleted and we dont have refernce to RMACs and NHs
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
It is technically possible to attempt to use a NULL pointer.
Remove this from happening.
Additionally cleanup code indentation a small bit.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When displaying a specific route and if it has a tag
and if we have turned on realm support notify the user
that a tag value of (1-255) is installed into the kernel
with the realm set.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Linux has the ability to support a concept of 'realms'.
This concept allows you to mark routes with a realm id
value of 1-255. If you have marked the realm
of a route then you can use the tc program to
apply policy to the routes.
This commit adds the ability of FRR to interpret
a tag from (1-255) as a realm when installing into
the kernel. Please note that at this point in time
there is no way to set policy from within FRR. This
must be done outside of it.
The normal methodology for setting tags is valid here
via a route-map.
Finally this is only applied if the --enable-realms configure
option is applied.
Signed-off-by: Kaloyan Kovachev <kkovachev@varna.net>
As netlink is available for all linux systems ( old linux distributions
are not considered), this commit removes the ipv6 ioctl support for
linux.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
It is possible to configure IPv6 addresses from interfaces by using
netlink socket, intead of using standard sockets.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
zserv.c had a grab bag of function declarations that
did not belong in it. Move those to where they better
belong.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
zserv.c has become a bit of a dumping ground for zebra cli.
I'd like to focus the zserv.c code into it's core functionality
which is handling the zapi interface.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The zebrad initialization does not need to be part of cli
initialization and should be done separately.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
