When we receive a route that we think we own and we
are not in startup conditions, then add a small debug
to help debug the issue when this happens, instead
of silently just ignoring the route.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The re-use of RTPROT_STATIC has caused too many collisions
where other legitimate route sources are causing us to
believe we are the originator of the route. Modify
the code so that if another protocol inserts RTPROT_STATIC
we will assume it's a Kernel Route.
Fixes: #2293
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
With:
commit ba7773964c
Author: Renato Westphal <renato@opensourcerouting.org>
Date: Wed Sep 20 22:12:56 2017 -0300
We added our own copy of if_link.h (among others). This
file unconditionally defines IFLA_WIRELESS, so we don't need
the conditional defines in the if_netlink.c code...
Issue: https://github.com/FRRouting/frr/issues/2299
Signed-off-by: Arthur Jones <arthur.jones@riverbed.com>
Added improved error message text to other places that could also
encounter the same condition. In testing found that in certain
case, duplicate error messages were previously issued. This fix
also removes the duplicates.
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Problem reported due to tab completion showing all possible peers
in every vrf, but when neighbor in wrong vrf entered "no such
neighbor" is the error message. Making it slightly more clear
with "no such neighbor in the view/vrf" to clue the user that they
may have specified the wrong vrf.
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
In case, the BGP or PBR daemon leaves, the PBR contexts created by this
daemon are flushed.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Move the list_delete_and_null of the virt->vrfs code to
the actual deletion function to ensure proper lifecycle.
This assumption allows us to know that irt->vrfs is always
true so remove the NULL check on it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The irt->vnis list was being freed on going down,
but actually delete it from the deletion function. Then
we can know that the irt->vnis is a valid list anywhere
we have a irt pointer.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This option is only implemented by 4 daemons:
- BGPD
- RIPD
- RIPNGD
- Zebra
Manpages and documentation say that the option causes routes to not be
uninstalled from zebra when the daemon terminates. This is true for RIPD
and RIPNGD. This is not true for BGPD; in that daemon it only prevents
transmission of Cease / Peer Unconfig NOTIFICATION messages to peers.
Moreover, when any daemon disconnects from Zebra, all of its routes are
uninstalled from Zebra and the kernel regardless of this option,
rendering the option largely vestigial.
It is still useful in Zebra, where it prevents all routes from being
uninstalled when Zebra shuts down, so it is left there.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Functionality to let vtysh attempt to reconnect to daemons when
connection is lost (e.g. crash or restart).
Signed-off-by: Mladen Sablic <mladen.sablic@gmail.com>
There exists code paths where the rn was being used after free.
This eliminates these code paths.
Fixes: CM-21019
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The linux kernel is getting the same Route Replace semantics
for v6 that v4 uses. Allow the end-user to know if their
kernel has this ability and if so to specify it so zebra
can take advantage of this.
Why not do auto-detection? Because you would have to write
code in zebra to add a route then add the same route again
with different nexthops to see if which semantics it is using.
It sure is easier to just add a cli that allows the user to
do it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Apparently Automake has some undocumented logic somewhere that makes it
so any Makefile generated from an Automake Makefile.am is removed from
its secret list of things to delete that it deletes when performing a
recursive distclean before actually performing the recursive distclean
and since the secret list is automatically generated from the list of
things that Autoconf should generate in configure.ac we can't remove the
Makefile from that list or it will break Automake's list of things to
automatically generate that it generates from Autoconf's list of things
to automatically generate.
Thus, to prevent Automake from deleting Makefiles and then immediately
trying to use the Makefiles it just deleted to delete said Makefiles, we
must remove ourselves from the secret list, which is accomplished by
changing the file extension to '.am' instead of '.in'.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
