This is a continuation of 915902cb82. Basically the netlink
read of messages up from the kernel is now noticing the proper
owner of the route. As such when rib_delete was being called
as part of the upcall from the kernel we were not noticing that
we were the originator and not diss-allowing the rib_delete
from happening. This restores this behavior that we were getting
pre-915902cb82cfd
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
For ZEBRA_ROUTE_KERNEL types:
The metric/priority of the route received from the kernel
is a 32 bit number. We are going to interpret the high
order byte as the Admin Distance and the low order 3 bytes
as the metric.
This will allow us to do two things:
1) Allow the creation of kernel routes that can be
overridden by zebra.
2) Allow the old behavior for 'most' kernel route types
if a user enters 'ip route ...' v4 routes get a metric
of 0 and v6 routes get a metric of 1024. Both of these
values will end up with a admin distance of 0, which
will cause them to win for the purposes of zebra.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This fixes the broken indentation of several foreach loops throughout
the code.
From clang's documentation[1]:
ForEachMacros: A vector of macros that should be interpreted as foreach
loops instead of as function calls.
[1] http://clang.llvm.org/docs/ClangFormatStyleOptions.html
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
There exists situations where it is possible to have duplicate
nexthops passed from a higher level protocol into zebra.
This code notices this duplication of nexthops and marks
the duplicates as DUPLICATE so we don't attempt to install
it into the kernel.
This is important on *BSD as I understand it because passing
duplicate nexthops will cause the route to be rejected.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
So the current code for a blackhole route assumed that you
would never want a recursively resolved blackhole to work.
Suppose you have this setup:
1) ip route 192.0.2.1/32 Null0
2) BGP installed with a route-map that rewrites the
nexthop to 192.0.2.1.
Zebra will end up with a recursive nexthop that resolves
to the blackhole.
The original rib install function assumed that we would never
want the ability to recursively resolve a blackhole route.
Instead just handle the blackhole as part of the nexthop_num = 1
case.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
With the change to make zebra pass routes to the kernel
with the 'correct' proto name, it caused zebra to
not properly recognize them on startup again
the next time such that the route would not
be deleted.
Modify rt_netlink.c to notice that we have a
self originated route and to properly mark
the type of route it was.
Modify rib_table_sweep to mark the nexthops
as active so that when we go to delete the
self originated routes it would properly
delete from the kernel.
Fixes: #1061
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
If we've set the bh_type to something besides BLACKHOLE_UNSPEC
due to the received route type being RTN_BLACKHOLE,
RTN_UNREACHABLE or RTN_PROHIBIT then just trust that
the nexthop is just what it is and set accordingly.
Fixes: #1082
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
support processing of RTN_BLACKHOLE et al. from kernel and dump them
into appropriate blackhole rib entries.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
blackhole support was horribly broken. cleanup by removing blackhole
stuff from ZEBRA_FLAG_*
introduces support for "prohibit" routes (Linux/netlink only)
also clean up blackhole options on "ip route" vty commands.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Frr has an assumption that when interface A links to B,
we already know about B. But that might be true always.
It is probably purely depends on the configuration
and how the interfaces are hashed in Kernel.
FRR seems to sometimes get "A is linked to B" before it knows about B,
in that case, the linkage between the data structure for A & B won't be proper.
Ticket: CM-17679
Review: ccr-6628
Testing: Manual
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
When the linux kernel adds/deletes routes, the
metric is important, but our routing protocols
add/delete in a slightly different manner,
so allow kernel metrics to match so that our
rib matches the kernel's fib.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
RTA_PAYLOAD() return value depends on the platform bits.
make[5]: Nothing to be done for 'all-am'.
Making all in zebra
CC rt_netlink.o
../../zebra/rt_netlink.c: In function 'netlink_macfdb_change':
../../zebra/rt_netlink.c:1695:63: error: format '%ld' expects argument of type 'long int', but argument 7 has type 'unsigned int' [-Werror=format=]
"%s family %s IF %s(%u) brIF %u - LLADDR is not MAC, len %ld",
^
../../zebra/rt_netlink.c: In function 'netlink_ipneigh_change':
../../zebra/rt_netlink.c:2024:57: error: format '%ld' expects argument of type 'long int', but argument 6 has type 'unsigned int' [-Werror=format=]
"%s family %s IF %s(%u) - LLADDR is not MAC, len %ld",
^
Signed-off-by: Jorge Boncompte <jbonor@gmail.com>
The pimregX devices when created by the kernel are put into
the default vrf. When pim gets the callback that the device
exists, check to see if it is a pimregX device and if so
move it into the appropriate vrf.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This current implementation unfortunately must
ask the kernel for all mroutes because vrf's
do not have the ability to request a single
mroute at this time.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Implement support for sticky (static) MACs. This includes the following:
- Recognize MAC is static (using NUD_NOARP flag) and inform BGP
- Construct MAC mobility extended community for sticky MACs as per
RFC 7432 section 15.2
- Inform to zebra that remote MAC is sticky, where appropriate
- Install sticky MACs into the kernel with the right flag
- Appropriate handling in route selection
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
Reviewed-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Implement handling of MACs and Neighbors (ARP/ND entries) in zebra:
- MAC and Neighbor database handlers
- Read MACs and Neighbors from the kernel, when needed and create
entries in zebra's MAC and Neighbor databases.
- Handle add/update/delete notifications from the kernel for MACs and
Neighbors and update zebra's database appropriately
- Inform locally learnt MACs and Neighbors to client
- Handle MACIP add/delete from client and install appriporiate entries
into the kernel
- Since Neighbor entries will be installed on an SVI, implement the
needed mappings
NOTE: kernel interface is only implemented for Linux/netlink
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Implement fundamental handling for VNIs and VTEPs:
- Handle EVPN enable/disable by client (advertise-all-vni)
- Create/update/delete VNIs based on VxLAN interface events and inform
client
- Handle VTEP add/delete from client and install into kernel
- New debug command for VxLAN/EVPN
- kernel interface (Linux/netlink only)
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
For NHRP, EIGRP and LDP( This is for consistency as opposed to correctness )
assign some new values to routes to be installed into the kernel
so we can know who owns them later.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The 'struct rib' data structure is missnamed. It really
is a 'struct route_entry' as part of the 'struct route_node'.
We have 1 'struct route_entry' per route src. As such
1 route node can have multiple route entries if multiple
protocols attempt to install the same route.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Rearrange the _netlink_route_build*() functions so the labels of the
nexthops are always installed, even for IPv4 routes with IPv6 nexthops.
Fixes Labeled Unicast with BGP Unnumbered.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
the ipv4_ll address used for 5549 routes does not need
to be figured out every single time that we attempt
to install/remove a route of that type.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When zebra issues read (GET) requests to the kernel using the netlink
interface, it is incorrect to format all of them in a generic manner
using 'struct ifinfomsg' or 'struct rtgenmsg'. Rather, messages for a
particular entity (e.g., routes) should use the corresponding structure
for encoding (e.g., 'struct rtmsg'). Of course, this has to correlate
with what the kernel expects.
In the absence of this, there is the possibility of sending extraneous
information in the request which the kernel wouldn't like.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: David Ahern <dsa@cumulusnetworks.com>
The FSF's address changed, and we had a mixture of comment styles for
the GPL file header. (The style with * at the beginning won out with
580 to 141 in existing files.)
Note: I've intentionally left intact other "variations" of the copyright
header, e.g. whether it says "Zebra", "Quagga", "FRR", or nothing.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Ticket: CM-14313
Reviewed By:
Testing Done: bgpmin, ospfmin, bgp_kitchen_sink_test
'ip route show' displays all routes as belonging to protocol zebra.
The user has to run an additional command (in vtysh) to get the actual
source of a route (bgp/ospf/static etc.). This patch addresses that by
pushing the appropriate protocol string into the protocol field of the
netlink route update message. Now you can see routes with the correct
origin as well as filter on them (ip route show proto ospf).
'ospf' is used for both IPv4 and IPv6 routes, even though the OSPF
version is different in both cases.
Sample output (old):
9.9.12.13 via 69.254.2.38 dev swp3.2 proto zebra metric 20
9.9.13.3 proto zebra metric 20
nexthop via 69.254.2.30 dev swp1.2 weight 1
nexthop via 69.254.2.34 dev swp2.2 weight 1
nexthop via 69.254.2.38 dev swp3.2 weight 1
Sample output (new):
9.9.12.13 via 69.254.2.38 dev swp3.2 proto bgp metric 20
9.9.13.3 proto bgp metric 20
nexthop via 69.254.2.30 dev swp1.2 weight 1
nexthop via 69.254.2.34 dev swp2.2 weight 1
nexthop via 69.254.2.38 dev swp3.2 weight 1
The kernel can send a DELROUTE with a individual
nexthop. Technically this is meant to delete that
individual nexthop from the route but zebra
has no way to do this currently. So we just delete
the route.
V4 -> Never sends a DELROUTE with multiple nexthops
as a way to modify the rib. It sends a a NEWROUTE
with RTM_REPLACE with the new appropriate route.
V6 -> Sends a DELROUTE with multiple nexthops
which is supposed to be interpreted as a
subtraction from the route.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
In the near future it will be possible to recieve v6 multipath netlink
messages. This code change is in prep for it. In the meantime the
v6 code path will continue to work as per normal.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The reading if unicast routes from the kernel acts subtly differently
between reading in the routes from the kernel on startup and
reading a new route or getting a response for a route.
Add startup flag(currently ignored) so that we can start
consolidating the functionality.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When starting up bgp and zebra now, you can specify
-e <number> or --ecmp <number>
and that number will be used as the maximum ecmp
that can be used.
The <number specified must be >= 1 and <= MULTIPATH_NUM
that Quagga is compiled with.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This reverts commit 1a11782c40.
The change is not suitable for stable/2.0, it's not a bugfix and has
quite a visible user impact.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Acked-by: Donald Sharp <sharpd@cumulusnetworks.com>
Problem reported was stale routes left in the kernel in certain cases
when overlapping static routes were used and links were bounced. The
problem was determined to be an issue where the nexthop was changed
due to recursion as the link is going down, and the next-hop at the
time of deletion doesn't match what was previously installed by the
kernel. This caused the kernel to reject the deletion and the route
stuck around.
It was pointed out that the kernel doesn't actually require a next-hop
value on the netlink deletion call. In this fix, we are eliminating
the nexthop for RTM_DELROUTE messages to the kernel in the ipv4 singlepath
case. This approach could also be valid for other cases but the fix
as is resolved the reported failure case. More testing should be
performed before similar changes are made for other cases.
Testing included manual testing for the failure condition as well as
complete bgp-smoke and ospf-smoke tests with no new failures.
Ticket: CM-13328
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: CCR-5562
Ticket: CM-14313
Reviewed By:
Testing Done: bgpmin, ospfmin, bgp_kitchen_sink_test
'ip route show' displays all routes as belonging to protocol zebra.
The user has to run an additional command (in vtysh) to get the actual
source of a route (bgp/ospf/static etc.). This patch addresses that by
pushing the appropriate protocol string into the protocol field of the
netlink route update message. Now you can see routes with the correct
origin as well as filter on them (ip route show proto ospf).
'ospf' is used for both IPv4 and IPv6 routes, even though the OSPF
version is different in both cases.
Sample output (old):
9.9.12.13 via 69.254.2.38 dev swp3.2 proto zebra metric 20
9.9.13.3 proto zebra metric 20
nexthop via 69.254.2.30 dev swp1.2 weight 1
nexthop via 69.254.2.34 dev swp2.2 weight 1
nexthop via 69.254.2.38 dev swp3.2 weight 1
Sample output (new):
9.9.12.13 via 69.254.2.38 dev swp3.2 proto bgp metric 20
9.9.13.3 proto bgp metric 20
nexthop via 69.254.2.30 dev swp1.2 weight 1
nexthop via 69.254.2.34 dev swp2.2 weight 1
nexthop via 69.254.2.38 dev swp3.2 weight 1
Signed-off-by: Dinesh Dutt <ddutt@cumulusnetworks.com>
Check and read the IPv6 source prefix on ZAPI messages, and pass it down
to the RIB functions (which do nothing with it yet.) Since the RIB
functions now all have a new extra argument, this also updates the
kernel route read functions to supply NULL.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The code to collect the sg stats was written for linux.
Abstract the call to allow it to work on all platforms.
I have not implemented the call for non-linux systems.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Fully decode mcast messages from the kernel. We are not
doing anything with this at the moment, but that will
change.
Additionally convert over to using lookup for
displaying the route type.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The netlink_talk call sends a message to the kernel, which
with netlink_talk_filter only waits for the ACK.
It would be nice to have the ability to specify what the handler
function would be for when we send queries about mcast S,G routes
so that we can gather the data returned from the kernel.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
There's no need to duplicate the 'vrf_id' and 'name' fields from the 'vrf'
structure into the 'zebra_vrf' structure. Instead of that, add a back
pointer in 'zebra_vrf' that should point to the associated 'vrf' structure.
Additionally, modify the vrf callbacks to pass the whole vrf structure
as a parameter. This allow us to make further simplifications in the code.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
[DL: picked out from: "atomic FIB updates"]
This simplifies the OS-specific route update API into a single entry
point, kernel_route_rib(), which dispatches the various operations
internally.
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
In linux, 'scope' is a hint of distance of the IP. And this is
evident from the fact that only lower scope can be used as recursive
via lookup result. This changes all interface routes scope to link
so kernel will allow regular routes to use it as via. Then we do
not need to use the 'onlink' attribute.
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
This patch installs labeled static routes in the FIB. The routes are installed
using the RTA_ENCAP (and RTA_ENCAP_TYPE) nested attributes.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-6040
Reviewed By: CCR-3091
Testing Done: Tested in SE-1, brief manual testing now
Install the statically configured LSPs into the FIB (kernel). This is done
using the new attributes and definitions for MPLS in the kernel -
RTA_VIA, RTA_NEWDST and AF_MPLS.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-4804
Reviewed By: CCR-3088
Testing Done: Manual in SE-1
The alignment of nlmsg_len is calculated wrong leading to wrong rta_len
calculations for nested TLVs when the data length of the last TLV added
to the nested TLV is not aligned to RTA_ALIGNTO already. Use same fix
that was implemented in iproute2 by Thomas Graf circa 2005. A reference
to the fix is at
http://oss.sgi.com/archives/netdev/2005-03/msg03103.html.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-6491
Reviewed By: CCR-3087
Testing Done: MPLS testing with other patches in SE-1
Note: Prior to MPLS, we didn't face this problem as we haven't really had
any nested TLVs; even if RTA_MULTIPATH were to be considered a nested TLV,
it didn't have any non-aligned fields.
This is a rather large mechanical commit that splits up the memory types
defined in lib/memtypes.c and distributes them into *_memory.[ch] files
in the individual daemons.
The zebra change is slightly annoying because there is no nice place to
put the #include "zebra_memory.h" statement.
bgpd, ospf6d, isisd and some tests were reusing MTYPEs defined in the
library for its own use. This is bad practice and would break when the
memtype are made static.
Acked-by: Vincent JARDIN <vincent.jardin@6wind.com>
Acked-by: Donald Sharp <sharpd@cumulusnetworks.com>
[CF: rebased for cmaster-next]
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
This removes the BSD specific usage of struct sockaddr_dl
hardware address. This unifies to use explict hw_addr member for
the address, and zebra specific enumeration for the link layer
type.
Additionally the zapi is updated to never send platform specific
structures over the wire, but the ll_type along with hw_addr_len
and hw_addr are now sent for all platforms.
Based on initial work by Paul Jakma.
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
# Please enter the commit message for your changes. Lines starting
# with '#' will be kept; you may remove them yourself if you want to.
# An empty message aborts the commit.
#
# Author: Timo Teräs <timo.teras@iki.fi>
#
# rebase in progress; onto 9c2f85d
# You are currently editing a commit while rebasing branch 'renato' on '9c2f85d'.
#
# Changes to be committed:
# modified: isisd/isis_circuit.c
# modified: lib/if.c
# modified: lib/if.h
# modified: lib/zclient.c
# modified: zebra/interface.c
# modified: zebra/interface.h
# modified: zebra/kernel_socket.c
# modified: zebra/rt_netlink.c
# modified: zebra/rtadv.c
# modified: zebra/zserv.c
#
# Untracked files:
# "\033\033OA\033OB\033"
# 0001-bgpd-fix-build-on-Solaris.patch
# ldpd/
# redhat/ldpd.init
# redhat/ldpd.service
# tags
#
This commits allow overriding MTU using netlink attributes on
per-route basis. This is useful for routing protocols that can
advertice prefix specific MTUs between routers (e.g. NHRP).
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
(cherry picked from commit b11f3b54c842117e22e2f5cf1561ea34eee8dfcc)
NS_DEFAULT is #defined to 0, We are passing it
in to a function that is taking 'struct zebra_ns *'
which is translating into a NULL pointer. Which
in some situations will cause a crash.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
Daniel Walton <dwalton@cumulusnetworks.com>
Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
(cherry picked from commit 1e9fa2763953adc603c3acc4ed2a46c9e72cbb29)
We shouldn't have platform-agnostic code (e.g. zebra/interface.c)
calling platform-specific functions (e.g. netlink_neigh_update).
This commit introduces the kernel_neigh_update() function, which then
has to be implemented by all supported platforms. Currently only Linux
implements this function, which is only used by the RTADV code.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Resolved several memory leaks caused by ifdown/ifup the vrf device or
a swp port. For bgp/zebra/ospf/ospf6, bouncing the vrf device would cause
a linked list, Interface, and route-table to get leaked. For ospf6,
bouncing the swp device also caused leaks of Connected and Prefix entries.
Ticket: CM-10841
Signed-off-by: Don Slice
Reviewed-By: Donald Sharp
Testing Done: Manual testing, bgp and ospf mins passed, smokes had fewer failures than base
Add command and associated functionality to enable dumping
raw netlink messages.
Ticket: CM-6568
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
The patches to allow kernel v6 Route Replacement semantics
to work correctly are on a very recent kernel. If you are
compiling on a linux kernel where it's broken, just
compile with --disable-rr-semantics.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When zebra receives a recvmsg buffer from the kernel
silently exit so that watchquagga will notice and then
restart zebra.
Ticket: CM-11130
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
This makes code more robust, consice and readable.
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
(cherry picked from commit be6335d682c5ee1b6930345193eda875705fbab2)
In _netlink_route_build_multipath():
- Each time when appending a IPv4 gateway in the message, rtnh_len
is increased by sizeof (struct rtattr) + 4, where we should use
"bytelen" instead of the hard coding "4".
- As what done for IPv4, we should increase rtnh_len accordingly
along with adding a IPv6 gateway, or else the IPv6 gateways will
be lost.
Signed-off-by: Feng Lu <lu.feng@6wind.com>
Reviewed-by: Alain Ritoux <alain.ritoux@6wind.com>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
(cherry picked from commit 621e2aaf33d8ab73bf44b0eea3f3900135d34996)
Conflicts:
zebra/rt_netlink.c
The only user of this was rib_bogus_ipv6(), which was removed in the
previous commit. Good riddance.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Acked-by: Greg Troxel <gdt@ir.bbn.com>
Acked-by: Feng Lu <lu.feng@6wind.com>
Acked-by: Paul Jakma <paul@jakma.org>
(cherry picked from commit 51bdebad99fe813d1b7104543b352f0e39b1c8dc)
CM-10680
Issue: When BGP daemon is stopped, all the BGP BFD sessions are not getting deleted from PTM.
Root cause: BGP daemon stop causes BFD de-register message to be sent for every peer on which BFD is enabled. But, all the de-register messages from bgpd to zebra are not processed before the socket close. This results in some stale BGP BFD sessions.
Fix: Support for client de-register message has been added in PTM/BFD. Changes in Quagga to support BFD client de-registrations:
− The BFD clients de-registration is sent directly from zebra daemon when zebra client (bgpd, ospfd and ospf6d) socket close is detected.
− Introduced a BFD flag for the zebra clients to prevent BFD de-registration messages from being sent to zebra daemon when the client is shutting down. This reduces the BFD messaging.
CM-10540
Issue: Invalid ptm status “fail” instead of “n/a” being displayed for VRF interfaces.
Root cause: ptm status is not being initialized to “unknown” status when VRF interface is added or changed. The uninitialized value is ‘0’ which is the value for “fail”
Fix: Initialized the ptm status to the correct value.
Signed-off-by: Radhika Mahankali <radhika@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Kanna Rajagopal <kanna@cumulusnetworks.com>
Ticket: CM-10680, CM-10540
Reviewed By: CCR-4653
Testing Done: PTM smoke, BGP smoke and ptmd_test.py:TestMultipleAddrsIntfOspfBgp
Instead of turning on IPv6 RA on every interface as soon as it has an IPv6
address, only enable it upon configuration of BGP neighbor. When the BGP
neighbor is deleted, signal that RAs can be turned off.
To support this, introduce new message interaction between BGP and Zebra.
Also, take appropriate actions in BGP upon interface add/del since the
unnumbered neighbor could exist prior to interface creation etc.
Only unnumbered IPv6 neighbors require RA, the /30 or /31 based neighbors
don't. However, to keep the interaction simple and not have to deal with
too many dynamic conditions (e.g., address deletes or neighbor change to/from
'v6only'), RAs on the interface are triggered upon any unnumbered neighbor
configuration.
BGP-triggered RAs will cause RAs to be initiated on the interface; however,
if BGP asks that RAs be stopped (upon delete of unnumbered neighbor), RAs
will continue to be exchanged if the operator has explicitly enabled.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-10640
Reviewed By: CCR-4589
Testing Done: Various manual and automated (refer to defect)
Quagga does not have proper recovery for route install failure (in
the kernel). The lack of this may not be a significant issue if the
failure is only an exception. However, the introduction of route
replace presents a new failure scenario which was not there earlier.
Before replace, the update operation involved a delete followed by
add; the failure of add would not leave hanging route entries in the
kernel as they would've got deleted first. With route replace, if
the replace fails, recovery action to delete the route is needed, else
the route remains hanging in the kernel.
In particular, with VRFs and in the presence of ECMP/multipath, a
failure mode exists where Quagga thinks that routes have been cleaned
up and deleted from the kernel but the kernel continues to retain them.
This happens when multiple VRF interfaces are moved from one VRF to
another.
This patch addresses this scenario by implementing proper recovery for
route install failure.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Dinesh Dutt <ddutt@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-10361
Reviewed By: CCR-4566
Testing Done: bgp-min, ospf-min, bgp-smoke, ospf-smoke and manual
Note: There are some test failures and results aren't consistent across
runs; Daniel has resolved many of these through other fixes.
IFLA_INFO_SLAVE_KIND is a new type of netlink message
If the kernel makes it available compile in support
else we'll just silently do the right thing.
Additionally reduce the test cases for netlink by 1
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: David Ahern <dsa@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Move zebra_vrf_XXX functionality into it's own
file so that we can isolate a bit the api edges
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
The struct zebra_ns was littered throughout the code
base in a half-hazard fashion. Gather up the references
and isolate the code a bit better.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
We were including 'extern struct zebra_t zebrad;' all
over the place. This made no sense. Refactor
into zserv.h where the definition was and remove resulting
unnecessary code.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
The vrf_add_update function does not need to exist.
Move it's constituent parts into the appropriate
vrf_create/vrf_enable functionality as well as
move the zebra_vrf_add_update() function call
into zebra_vrf_enable()
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
vrf_delete_update really belongs in vrf.c broken up
into it's appropriate places.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Zebra in rt_netlink.c has a while (1) loop that handles
recvmsg from the netlink socket. In early bootup a
situation can occur whereby the netlink messages
take a long time to parse. This time starts to
take an exponential amount of time the more netlink
messages that you read in. There reaches
a point where the incoming netlink messages are
coming in at about the same rate that they are processed.
This ends up causing the while (1) loop to never exit.
Eventually this causes quagga to fail when the watchdog message
is never sent to systemd.
This patch attempts to address this deficiency in that
we allow for a pause from reading in netlink messages
to allow other work to be done. This pause drains
the work queue items created by the netlink received
data and allows zebra to respond to other system input.
I believe we will need to come back in and modify zebra
startup a bit more. There are ineffiencies that need
to be addressed as part of boot up.
Ticket: CM-9992
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: Wilson Kok <wkok@cumulusnetworks.com>
Zebra code was not handling larger table-ids correctly. There were 2 issues:
a) In the netlink interface, RTA_TABLE was never sent or processed. This
pretty much limited the table-ids that zebra could understand to < 255.
b) In the interface into the zebra RIB (in particular for protocols), there
were some incorrect checks that again assumed the table id should be < 252
or be "main". This is valid only for the Default VRF (for now), for other
VRFs, the table-id should be the value learnt from the kernel.
These two issues are addressed with this change.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Ticket: CM-10087, CM-10091
Reviewed By: CCR-4359
Testing Done: Manual
zebra was not actually deleting the vrf passed in.
Ticket: CM-9412
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
Restrict interfaces on which IPv6 Router Advertisements are allowed. The list
excludes loopback interfaces including the VRF device interface; specific to
Cumulus, it also includes "switch0" and "ethX" interfaces.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
Ticket: CM-9849
Reviewed By: CCR-4334
Testing Done: Manual
Invoke VRF change for an interface, if appropriate, upon netlink
notification.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
Ticket: CM-9527
Reviewed By: CCR-4174
Testing Done: Manual tests of various scenarios
Modified response to netlink message for VRF creation, allowing it to be
created as an interface and setting the right vrf_id and bringing in the ip address.
Ticket: CM-9277
Signed-off-by: Don Slice
Reviewed-by: Vivek Venkatraman
The earlier change to ignore status for VRF device was not quite perfect. As
defect CM-9437 illustrates, there are situations when Quagga may get a VRF
member interface (that refers to the VRF id of the VRF device) before it gets
the VRF device itself. The code has some logic to handle this, creating a
VRF structure which is partly initialized. The initialization is completed
with some additional incorrect status processing when the VRF is learnt. The
fix done earlier completely ignored the VRF message treating it as a status
change because the VRF is already present, but this left the VRF structure
not fully initialized in Quagga. The fix is to do some additional checks
to handle this scenario.
Fixes: 3e66be2ee6
Ticket: CM-9437
Reviewed By: None
Testing Done: Reproduced problem, verified fix.
Temporary change to ignore status change for a VRF device as it is
incorrectly implemented now. When VRF is also supported as an
interface, the status change will be handled for the interface.
Ticket:
Reviewed By:
Testing Done:
Since the netlink socket is per namespace and not per VRF, do not
invoke vrf_socket().
Note: This needs to be changed when we support multiple namespaces -
needed only for upstreaming.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-9206
Reviewed By: CCR-4127
Testing Done:
When enabling IPv6 Router Advertisements automatically based on the
presence of IPv6 address on an interface, do it only for relevant
interfaces.
Note: This needs a configure option for completion.
Ticket: CM-9358
Reviewed By: CCR-4116
Testing Done: Manual verification
vrf: check netlink message for slave info and set the vrf-id accoringly
When a netlink newlink or link change comes into zebra, check the IFLA_INFO_SLAVE_KIND
to discover if the interface is a member of a vrf or not. Set the vrf-id to the correct
value if the interface is a slave member
Signed-off-by: Don Sice
Reviewed-by:
When a slave device is received via netlink, all the
devices were being treated as vrf's instead of the
myriad of slave devices that are possible.
Add code to check to see if the device is truly a vrf slave
or not.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Fixup the debug handling of vrf's to be a bit
more explicit how we create a vrf internally.
Add code to turn on/off debugging of vrf's.
Ticket: CM-9063
Testing: Manual
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Convert the rest of zebra over to use a Namespae and VRF.
Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com>
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The NEXTHOP_TYPE_XXX_IFNAME types were never being used. Remove them
and the code associated with them.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
During CR for nexthop upstream it was noticed that usage
of prefix2str was not consistent. This fixes this problem
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
