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>
Create the idea of a VRF_UNKNOWN, this is for a vrf where we don't
yet have the vrf_id for it yet.
Refactor the vrf_create code out of existence. We had two code
paths vrf_create and vrf_get. We should use vrf_get to create
the new vrf since XXX_get() creates the data structures now.
Signed-off-by: Donald Sharp
Reviewed-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
The file if.c has a iflist that had the list of interfaces
in the default vrf. Remove this variable and replace
with a vrf_iflist lookup on the default vrf where it
was used.
Additionally, modify ptm code to iterate over all vrf's
when enabling ptm.
Ticket: CM-10338
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: Radhika Mahankali <radhika@cumulusnetworks.com>
ZEBRA_VRF_ACTIVE is a poor name for when a vrf is
actually active. Rename VRF_ACTIVE.
Ticket: CM-10338
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: Radhika Mahankali <radhika@cumulusnetworks.com>
It is quite useful to be able to assert whether specific interfaces have
flapped or also to verify that specific interfaces have not flapped.
By having counters for those events and storing the last time of their
occurrence, this is made possible.
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
Acked-by: Jafar Al-Gharaibeh <jafar@atcorp.com>
When we encounter a problem loading a config file
quantify to the end user what has gone wrong,
with a combination of err output as well as
return codes.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
Reviewed-by: Dave Olson <olson@cumulusnetworks.com>
In the case of BGP unnumbered RFC 5549 (IPv4 routes with IPv6 nexthop), the
zebra code to handle routes was not initializing the correct VRF id and
locating the correct routing table, resulting in the routes not getting
installed. Fixed with this change.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-10247
Reviewed By: CCR-4429
Testing Done: Manual verification
When signalled to stop quagga, iterate through any "other_tables" that may have
been imported and close them all before stopping.
Ticket: CM-9386
Signed-off-by: Don Slice
Reviewed-by: Donald Sharp
This commit fixes two issues:
1) The creation of a new vrf from the cli was not calling the vrf_create hook.
This is fixed.
2) The zebra_vrf_delete callback was deleting interface information that
belonged to vrf not zvrf. Remove the code as that it was not it's job
to do so.
Ticket: CM-10100
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@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>
When configuring an IPv6 static route with the nexthop as a link-local
IPv6 address, the associated interface has to be looked up in the correct
VRF.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Ticket: CM-10169
Reviewed By: CCR-4382
Testing Done: Manual
Changed display/saving of global router-id to use the vrf name instead
of the vrf_id, since the vrf_id would get lost on quagga restart or
reboot.
Ticket: CM-10106
Signed-off-by: Don Slice
Reviewed-by: Donald Sharp
Changed output of the "ipv6 route ... vrf red" to display and store with the
vrf name instead of the vrf_id, since the vrf_id would disappear on reboot
or quagga restart.
Ticket: CM-10126
Signed-off-by: Don Slice
Reviewed-by: Donald Sharp
When an interface changes which vrf it is part of, it needs to be added
to the list of possible router-id choices in the new vrf and removed
from the old vrf/default.
Ticket: CM-9074
Signed-off-by: Don Slice
Reviewed-by: Vivek Venkatraman
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
There are cases where we get an interface name but do not have a
corresponding vrf. We care about getting an interface pointer
so just provide a function that searches all vrf's for the ifp.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Radhicak Mahankali <radhika@cumulusnetworks.com>
Reviewed-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
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>
We were incorrectly using vrf instead of zebra_vrf in a
few spots.
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
During some tests of the release I noticed that we
have some issues with it properly building due
to missing information in the Makefile.am files
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-7615, CM-7773
Reviewed By: CCR-3610, CCR-3708
Testing Done: Unit, BGP Smoke and OSPF Smoke
Changes (70790261926b17200c8c9377c4576cd3b486fcef) ported from 2.5
Issue (related to CM-7615): 1. CM-7615: There is mismatch in the client name between ptm display of client BFD sessions and the zebra logs. For example, if bgpd added BFD session, zebra logs will show the client as “bgp” but the ptm display will show it as “quagga”
2. Bigger problem is when 2 clients (for example OSPF and BGP) from Quagga register for same BFD session and only one client de-registers the BFD session. This results in BFD session deletion from PTM even though other client still has the BFD registration.
Root Cause: Even though BGP, OSPF and OSPF6 are 3 different clients from Quagga that are trying to register/deregister BFD sessions with PTM, all 3 are represented as one client “quagga” from zebra. This makes it hard for PTM/BFD to distinguish between all three when BFD peer registration/deregistration happens from the clients.
Fix: Send the actual client name bgp, ospf or ospf6 from zebra with BFD reg/dereg messages instead of one unified client name “quagga”
CM-7773: BFD sessions are not getting cleaned from PTM even though no BGP peering exists in Quagga.
Root Cause: PTM cleans up stale BFD sessions from a client when it finds a change in seq id advertised by the client. But, if PTM never detects a change in the seq id then the stale BFD sessions never get cleaned up. The test restarts the quagga without saving the configuration, which results in no BGP peering. No BGP peers are registered with PTM after restart and PTM does not detect a client seq id change resulting in stale BFD sessions.
Fix: New client registration message was added in PTM. Every client that is interested in BFD monitoring will register with PTM with the client seq id. Client will register with a different seq id (typically pid) every time it restarts. This will help in detecting the change in seq id and cleanup of stale BFD sessions for a client.
Code Changes: To support the new client registration message following changes have been made
- Added support for client registration messaging in zebra for sending messages to PTM.
- Added support for client registration messaging between zebra and clients (BGP, OSPF and OSPF6) in BFD library.
- Expanded the reg/de reg peer messaging between zebra and clients to support client specific seq id to distinguish between multiple clients registering for BFD peer rather than one “quagga” client.
- Changes in bgpd, ospfd and ospf6d to send client registrations at the time of daemon initialization and on receiving BFD peer replay message.
Following changes have been done to support VRF for BFD in zebra and bgpd.
- Pass the correct VRF value from bgpd to zebra for reg and dereg of BFD destinations.
- Send the non-default vrf name in reg/dereg messages of multihop destination to BFD/PTM from zebra.
Signed-off-by: Radhika Mahankali <radhika@cumulusnetworks.com>
Ticket: CM-8450
Reviewed By: CCR-4253
Testing Done: Unit, PTM smoke, BGP Smoke
To make the syntax of the "show ip route" vrf commands more closely align with the bgp variety,
moved the vrf forward in the command. In other words, show ip route 10.1.1.1/32 vrf green became
show ip route vrf green 10.0.0.1/32. Also added a couple of missing show vrf commands (ipv4 and
ipv6 tags).
Ticket: CM-9114
Signed-off-by: Don Slice
Reviewed-by: Donald Sharp
Cleanup code and improve debugs as part of fixing NHT for static routes
in a VRF.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
Ticket: CM-9457
Reviewed By: CCR-4185
Testing Done: Manual verification
Implement VRF support for static nexthop resolution (NHT). This is
achieved by ensuring the correct VRF is passed as a parameter to
the NHT functions and is stored in the registered nexthop data
structure.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
Ticket: CM-9457
Reviewed By: CCR-4185
Testing Done: Manual verification
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
Implement VRF change semantics for an interface to be invoked
when an interface is moved from one VRF (e.g., the Default) to
another. This includes the message definition as well as updating,
deleting or adding the interface from clients, depending on their
interest in the VRFs (old and new). Also handle replay of the
addresses on the interface upon VRF change, if required.
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
Changed output to use the name and table id rather than the vrf_id, since the vrf_id
isn't really meaningful to customers reading the output.
Ticket: CM-9464
Signed-off-by: Don Slice
Reviewed-by: Donald Sharp
There exist cases where Cumulus Code( in this case code surrounding
when we want to send Router Advertisements ) should only be
turned on for Cumulus Switches.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
NHT evaluation was not being triggered for any VRF after RIB processing. Fix
this and attempt to schedule only those VRFs for which RIB processing was
scheduled.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Ticket: CM-9175
Reviewed By: CCR-4149
Testing Done: Manual verification
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:
This patch reorganizes the RA handling to be per namespace rather than per
VRF. The VRF library by 6wind had done the original change to make the RA
data structures (socket information) per VRF, but this was correct only if
each VRF represented a NS. In our reorganization, we have created a NS
structure (struct zebra_ns) and VRFs don't correspond to namespaces (i.e.,
all VRFs exist in the default namespace). So, the RA handling should be
done under 'struct zebra_ns'.
With the changes, there is a single raw socket per NS (=> 1 for us) on which
we will receive and handle RAs for all interfaces. The interface information
is available through cmsg and the processing will then happen for that interface.
There is a problem with transmitting RAs over a VRF interface. This is
tracked by CM-9398.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-9206
Reviewed By: CCR-4217
Testing Done: Manual testing
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:
