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>
zebra_find_client needs to match on instance as well so
protocols like ospfd will work correctly for notification.
Modify the zebra_find_client code to accept the instance
number and to pass it in appropriately.
Signed-off-by: Doanld Sharp <sharpd@cumulusnetworks.com>
Allow the higher level protocol to specify if it would
like to receive notifications about it's routes that
it has installed.
I've purposely made it part of zclient_new_notify because
we need to track the routes on a per daemon basis only.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Provide ZAPI code that can pass to an upper level protocol
what happened to it's route on install.
There are these notifications:
1) ZAPI_ROUTE_FAIL_INSTALL - The route attempted to be
installed did not work.
2) ZAPI_ROUTE_BETTER_ADMIN_WON - A route that was installed
has become un-installed due to another routing protocol
installing a better admin distance
3) ZAPI_ROUTE_INSTALLED - The route specified has been installed
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The flags value is not used for unregister events. Let's purposefully
not send anything and purposefully not accept non 0 for it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This code modifies zebra to use the STREAM_GET functionality.
This will allow zebra to continue functioning in the case of
bad input data from higher level protocols instead of crashing.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
1) Write zserv api commands( one of each type ) to the side. This will allow
us to use them as input for a fuzzer.
2) Add -c <file to pass to zapi read process> into zebra as a run-time
option of we've turned on fuzzing.
While in and of itself these are not terribly useful( you still need
an external fuzzer ), they provide an infrastructure to allow
tools like afl to test the zapi.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Store the number of packets we should process at
one time in `struct zebra_t`. A future commit
will allow the user to control this via
a hidden cli.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The zebra_client_read functionality was reading 1 message
from a peer at a time. Modify the code so that we can
read up to 10 at a time.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The zserv command handlers make an already long function
even longer. Isolate this code so that we can rearrange
the zebra_client_read function.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This improves code readability and also future-proofs our codebase
against new changes in the data structure used to store interfaces.
The FOR_ALL_INTERFACES_ADDRESSES macro was also moved to lib/ but
for now only babeld is using it.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
This is an important optimization for users running FRR on systems with
a large number of interfaces (e.g. thousands of tunnels). Red-black
trees scale much better than sorted linked-lists and also store the
elements in an ordered way (contrary to hash tables).
This is a big patch but the interesting bits are all in lib/if.[ch].
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
This was causing some weird prefixes to pop up in my log files. One
alternate solution would be to call apply_mask() on the prefix, but
memcpy() is faster and just enough in this case.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
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>
On shutdown we were deleting the linked list that
kept the zclient connections, but we were not
freeing the data pointed at by the link list.
This modification allows the normal cleanup of the
linked list to cleanup the zclient data structure.
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>
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
This fixes route redistribution for VRFs
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>
Specifically, gcc 4.2.1 on OpenBSD 6.0 warns about these; they're bogus
(gcc 4.2, being rather old, isn't quite as "intelligent" as newer
versions; the newer ones apply more logic and less warnings.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
1) Various socket close issues
2) Ensure afi passed is usable
3) Fix some reads beyond buffer and reads after free
4) Ensure some failure modes are handled properly
5) Memory Leak(s) fix
6) There is no 6.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Some differences compared to the old API:
* Now the redistributed routes are sent using address-family
independent messages (ZEBRA_REDISTRIBUTE_ROUTE_ADD and
ZEBRA_REDISTRIBUTE_ROUTE_DEL). This allows us to unify the ipv4/ipv6
zclient callbacks in the client daemons and thus remove a lot of
duplicate code;
* Now zebra sends all nexthops of the redistributed routes to the client
daemons, not only the first one. This shouldn't have any noticeable
performance implications and will allow us to remove an ugly exception
we had for ldpd (which needs to know all nexthops of the redistributed
routes). The other client daemons can simply ignore the nexthops if
they want or consult just the first one (e.g. ospfd/ospf6d/ripd/ripngd).
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
As noticed in 657cde1, the zapi_ipv[4|6]_route functions are broken in
many ways and that's the reason that many client daemons (e.g. ospfd,
isisd) need to send handcrafted messages to zebra.
The zapi_route() function introduced by Donald solves the problem
by providing a consistent way to send ipv4/ipv6 routes to zebra with
nexthops of any type, in all possible combinations including IPv4 routes
with IPv6 nexthops (for BGP unnumbered routes).
This patch goes a bit further and creates two new address-family
independent ZAPI message types that the client daemons can
use to advertise route information to zebra: ZEBRA_ROUTE_ADD and
ZEBRA_ROUTE_DELETE. The big advantage of having address-family independent
messages is that it allows us to remove a lot of duplicate code in zebra
and in the client daemons.
This patch also introduces the zapi_route_decode() function. It will be
used by zebra to decode route messages sent by the client daemons using
zclient_route_send(), which calls zapi_route_encode().
Later on we'll use this same pair of encode/decode functions to
send/receive redistributed routes from zebra to the client daemons,
taking the idea of removing code duplication to the next level.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Route attributes like tag, distance and metric are irrelevant when we
want to delete a route from a client daemon. The same can be said about
the nexthops of the route. Only the IP prefix and client protocol are
enough to identify the route we want to remove, considering that zebra
maintains at most one route from each client daemon for each prefix. Once
rib_delete() is called, it deletes the selected route with all of its
nexthops.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
This is the v6 counterpart of commit c963c20.
Fixes a bug where ipv6 routes received from babeld were being ignored.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Raising privileges is only necessary when binding to a TCP/UDP privileged
port (< 1024).
This solves a problem where the zserv.api socket was being created with
root ownership, preventing the client daemons to connect to zebra.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
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>
Base framework for supporting MPLS pseudowires in FRR.
A consistent zserv interface is provided so that any client daemon
(e.g. ldpd, bgpd) can install/uninstall pseudowires in a standard
way. Static pseudowires can also be implemented by using the same
interface.
When zebra receives a request to install a pseudowire and the installation
in the kernel or hardware fails, a notification is sent back to the
client daemon and a new install attempt is made every 60 seconds (until
it succeeds).
Support for external dataplanes is provided by the use of hooks to
install/uninstall pseudowires.
Signed-off-by: ßingen <bingen@voltanet.io>
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Implicit-null labels are never installed in the FIB but we need to keep
track of them because of L2/L3 VPN nexthop resolution.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
The defines:
ONE_DAY_SECOND
ONE_WEEK_SECOND
ONE_YEAR_SECOND
were being defined all over the system, move the
define to a central location.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This adds "@tcp" as new choice on the -z option present in zebra and the
protocol daemons. The --enable-tcp-zebra option on configure is no
longer needed, both UNIX and TCP socket support is always available.
Note that @tcp should not be used by default (e.g. in an init script),
and --enable-tcp-zebra should never have been in any distro package
builds, because
**** TCP-ZEBRA IS A SECURITY PROBLEM ****
It allows arbitrary local users to mess with the routing table and
inject bogus data -- and also ZAPI is not designed to be robust against
attacks.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Zebra receiving a macip_del message will automatically call
into the set_master function( a pim function ). Add missing
break statement
Ticket: CM-16841
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.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 reverts commit c14777c6bf.
clang 5 is not widely available enough for people to indent with. This
is particularly problematic when rebasing/adjusting branches.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
This allows frr-reload.py (or anything else that scripts via vtysh)
to know if the vtysh command worked or hit an error.
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>
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
- All ipv4 labeled-unicast routes are now installed in the ipv4 unicast
table. This allows us to do things like take routes from an ipv4
unicast peer, allocate a label for them and TX them to a ipv4
labeled-unicast peer. We can do the opposite where we take routes from
a labeled-unicast peer, remove the label and advertise them to an ipv4
unicast peer.
- Multipath over a labeled route and non-labeled route is not allowed.
- You cannot activate a peer for both 'ipv4 unicast' and 'ipv4
labeled-unicast'
- The 'tag' variable was overloaded for zebra's route tag feature as
well as the mpls label. I added a 'mpls_label_t mpls' variable to
avoid this. This is much cleaner but resulted in touching a lot of
code.
pim controls the vrf table creation for due to the way that
pim must interact with the kernel. In order to match the
table_id for unicast <-> multicast( not necessary but a
real nice to have ) we need to pass up from zebra the
table_id associated with the vrf.
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>
Prior to the fix, labels weren't getting installed in zebra nor were the
ifindex values correctly set if labeled-unicast was used in conjunction
with bgp unnumbered.
Ticket: CM-16531
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: CCR-6276
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>
To avoid blocking zebra when it's acting as a proxy for an external
label manager.
Besides:
Fix get chunk reconnection. Socket was still being destroyed on failure,
so next attempt would never work.
Filter out unwanted messages in lm sync sock.
Until LDE client sends ZEBRA_LABEL_MANAGER_CONNECT message, zserv
doesn't know which kind of client it is, so it might enqueue unwanted
messages like interface add, interface up, etc. Changes in this commit
discard those messages in the client side in case they arrive before the
expected response.
Change function name for zclient_connect in label manager to avoid
confusion with zclient one.
Signed-off-by: ßingen <bingen@voltanet.io>
Pass pointer to pointer instead of assigning by return value. See
previous commit message.
To ensure that the behavior stays functionally correct, any assignments
with the result of a thread_add* function have been transformed to set
the pointer to null before passing it. These can be removed wherever the
pointer is known to already be null.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
The way thread.c is written, a caller who wishes to be able to cancel a
thread or avoid scheduling it twice must keep a reference to the thread.
Typically this is done with a long lived pointer whose value is checked
for null in order to know if the thread is currently scheduled. The
check-and-schedule idiom is so common that several wrapper macros in
thread.h existed solely to provide it.
This patch removes those macros and adds a new parameter to all
thread_add_* functions which is a pointer to the struct thread * to
store the result of a scheduling call. If the value passed is non-null,
the thread will only be scheduled if the value is null. This helps with
consistency.
A Coccinelle spatch has been used to transform code of the form:
if (t == NULL)
t = thread_add_* (...)
to the form
thread_add_* (..., &t)
The THREAD_ON macros have also been transformed to the underlying
thread.c calls.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Be a bit more rigoruous about what we can receive
from another protocol and attempt to make the code
less likely to crash and to just safely bail
out when an error is received.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
flags is set but never used. Since we
plan to use it in the future, make
it evident what is going on here.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Implement BGP Prefix-SID IETF draft to be able to signal a labeled-unicast
prefix with a label index (segment ID). This makes it easier to deploy
global MPLS labels with BGP, even without other aspects of Segment Routing
implemented.
This patch implements the handling of the BGP-Prefix-SID Label Index
attribute. When received from a peer and the index is acceptable, the local
label is picked up from the SRGB and is programmed as the incoming label as
well as advertised to peers. If the index is not acceptable, no local label
is assigned. The outgoing label will always be the one advertised by the
downstream neighbor.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Support install of labeled-unicast routes by a client. This would be
BGP, in order to install routes corresponding to AFI/SAFI 1/4 (IPv4)
or 2/4 (IPv6). Convert labeled-unicast routes into label forwarding
entries (i.e., transit LSPs) when there is a static label binding.
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Implement interface that allows a client to register a FEC for obtaining
a label binding (in-label). Update client whenever the label binding is
updated and cleanup when client goes away.
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
This is a prepatory commit for future improvements.
Add a change to the zapi to pass the interface speed up.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Label Manager allows to share MPLS label space among different
daemons. Each daemon can request a chunk of consecutive labels and
release it if it doesn't need them anymore. Label Manager stores the
daemon protocol and instance to identify the owner client. It uses them
to perform garbage collection, releasing all label chunks from a client
when it gets disconnected or reconnected.
Additionally, every client can request that the chunk is never garbage
collected. In that case client has the responsibility to release
non-used labels.
Zebra can host the label manager itself (if no -l param is provided) or
connect to an external one using zserv/zclient (providing its address
with -l param).
Client code is in lib/zclient.c, but currently only LDP is using it.
TODO: Allow for custom ranges requests, i.e., specify the start label
besides the chunk.
TODO: Release labels from LDP.
Signed-off-by: Bingen Eguzkitza <bingen@voltanet.io>
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>
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>
NEXTHOP_TYPE_IPV4 has the ifindex of the route. Pass it
along so the other side can use it if it is needed.
This will make pim much happier in that we will need to do less
recursive lookups.
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>
Since VRFs can be searched by vrf_id or name, make this explicit in the
helper functions.
s/vrf_lookup/vrf_lookup_by_id/
s/zebra_vrf_lookup/zebra_vrf_lookup_by_id/
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
As a general rule of thumb, we should write functions that do one thing
and that do it well. All callers of zsend_redistribute_route() are already
checking if the route should be redistributed or not (as the comment
says), so we definitely shouldn't bother with that in this function.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
If a command is put into the VIEW_NODE, it is going into the
ENABLE_NODE as well. This is especially true for show commands.
As such if a command is in both consolidate it down to VIEW_NODE.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This patch improves zebra,ripd,ripngd,ospfd and bgpd so that they can
make use of 32-bit route tags in the case of zebra,ospf,bgp or 16-bit
route-tags in the case of ripd,ripngd.
It is based on the following patch:
commit d25764028829a3a30cdbabe85f32408a63cccadf
Author: Paul Jakma <paul.jakma@hpe.com>
Date: Fri Jul 1 14:23:45 2016 +0100
*: Widen width of Zserv routing tag field.
But also contains the changes which make this actually useful for all
the daemons.
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
This feature adds an L3 & L2 VPN application that makes use of the VPN
and Encap SAFIs. This code is currently used to support IETF NVO3 style
operation. In NVO3 terminology it provides the Network Virtualization
Authority (NVA) and the ability to import/export IP prefixes and MAC
addresses from Network Virtualization Edges (NVEs). The code supports
per-NVE tables.
The NVE-NVA protocol used to communicate routing and Ethernet / Layer 2
(L2) forwarding information between NVAs and NVEs is referred to as the
Remote Forwarder Protocol (RFP). OpenFlow is an example RFP. For
general background on NVO3 and RFP concepts see [1]. For information on
Openflow see [2].
RFPs are integrated with BGP via the RF API contained in the new "rfapi"
BGP sub-directory. Currently, only a simple example RFP is included in
Quagga. Developers may use this example as a starting point to integrate
Quagga with an RFP of their choosing, e.g., OpenFlow. The RFAPI code
also supports the ability import/export of routing information between
VNC and customer edge routers (CEs) operating within a virtual
network. Import/export may take place between BGP views or to the
default zebera VRF.
BGP, with IP VPNs and Tunnel Encapsulation, is used to distribute VPN
information between NVAs. BGP based IP VPN support is defined in
RFC4364, BGP/MPLS IP Virtual Private Networks (VPNs), and RFC4659,
BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN . Use
of both the Encapsulation Subsequent Address Family Identifier (SAFI)
and the Tunnel Encapsulation Attribute, RFC5512, The BGP Encapsulation
Subsequent Address Family Identifier (SAFI) and the BGP Tunnel
Encapsulation Attribute, are supported. MAC address distribution does
not follow any standard BGB encoding, although it was inspired by the
early IETF EVPN concepts.
The feature is conditionally compiled and disabled by default.
Use the --enable-bgp-vnc configure option to enable.
The majority of this code was authored by G. Paul Ziemba
<paulz@labn.net>.
[1] http://tools.ietf.org/html/draft-ietf-nvo3-nve-nva-cp-req
[2] https://www.opennetworking.org/sdn-resources/technical-library
Now includes changes needed to merge with cmaster-next.
FIB override routes are for routing protocols that establish
shortcut routes, or establish point-to-point routes that should
not be redistributed. Namely this is useful NHRP daemon to come.
Zebra is extended to select two entries from RIB the "best" entry
from routing protocols, and the FIB entry to install to kernel.
FIB override routes are never selected as best entry, and thus
are never adverticed to other routing daemons. The best FIB
override, or if it does not exist the otherwise best RIB is
selected as FIB entry to be installed.
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
Acked-by: Donald Sharp <sharpd@cumulusnetworks.com>
[CF: Massage to fit cumulus tree]
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
BABEL was removed, ifname nexthops were removed, additional includes
were needed, and lastly the protobuf enum-handling triggers a warning.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
FPM aims to provide cross platform mechanism to support the scenario
where the router has forwarding path distinct fromt the kernel.Commonly
Hardware based fast path.Hence it is non-configurable paramter.This
limits us to use funcationality to update FIB information to remote
hosts, like SDN controller.
This implementation provides the CLI to configure remote hosts and port
information of remote fpm controller.Otherwise default fpm server will
be localhost and default fpm port will be well know port 2620.
* zebra_fpm.c: added fpm_server paramter to zfpm_global_t handler.
Implemented CLI for configuring the fpm server and no fpm
command to revert back to default configuration.
* zserv.c: Install zebra node to write fpm configuration info
on console/config file.
Further documentation supplied:
-------------------------------
ZEBRA : CLI CONFIGURATION FOR FPM MODULE
========================================================
1. INTRODUCTION
================================
1.1 scope
This memo discusses the configuration option for zebra to update
FIB information to local and remote modules.
This will also helps to address the issue associated with CORD project.
https://jira.onosproject.org/browse/CORD-411
2. REFERENCE
================================
Quagga version 99.24+ ( main branch committed on 29-sep-2015)
3. PROBLEM DESCRIPTION
================================
Once FPM is enabled, Quagga periodically tries to initiate fpm
connection to localhost:2620. These values are non configurable in
existing implementation. There is no CLI available to configure
"host:port". hence limits us to use it for hardware based fast path
modules only.
4. PROPOSED CHANGES
================================
Following changes are done to the quagga code
a) Added new CLI to configure "host address : port".
The CLI format
<conf t>
$ fpm connection ip <ipv4 address> port <tcp port num>
and no fpm command to revert back to default
<conf t>
$ no fpm connection ip <ipv4 address> port <tcp port num>
b) Allowed values are ipv4 address and tcp port range <1-65535>
c) FPM initialization code has been enhanced to pick the "host
address : port" values from zebra.conf. if not found then
default values as localhost:2620 will be used. and updated the
information on to config file on write config command
5. FILES MODIFIED
================================
1) fpm/fpm.h :
a) Added MACRO to represent network order loopback ip
2) zebra/zebra_fpm.h :
a) introduced fpm_server variable in zfpm_glob_t handler to hold
the remote fpm server address
b) Hooked 'fpm_remote_ip_cmd' and 'no_fpm_remote_ip_cmd' at CONFIG
node to configure remote fpm detail and to revert back to
default respectively
3) zebra/zserv.c :
a) Hooked 'config_write_fpm' callback function, at ZEBRA_NODE to
display the fpm connection details on console on entering
command
$ show running_config
and to write to configuration file on entering command
$ write config
6. TESTING DETAILS
================================
6.1. default behavior
In default configuration FPM will attempt to connect to
localhost:2620
6.2. update fpm info
a) Using CLI command user can configure fpm host:port details
and can be able to write to config file(zebra.conf) using
write config command. this parameters has no
dependency/impact on other parameters of config file
b) show running-config/write config will display the fpm
information if configured. and will not display any
information related to fpm for default configuration
c) these configured information will be stored to config file.
only on write config command.
6.3 loading from config file
a) zebra attempts to connect to fpm server if fpm parameter
found in config file.else connects to default parameters.
b) if fpm connection drops, fpm will periodically attempts to
connect to remote server.
c) if fpm connections already established. then newly
configured fpm parameters will not disconnect the existing
connection. new connection to the different fpm server will
happen only after existing connection closes by either of
the end.
fix fpm prototype
FIB override routes are for routing protocols that establish
shortcut routes, or establish point-to-point routes that should
not be redistributed. Namely this is useful NHRP daemon to come.
Zebra is extended to select two entries from RIB the "best" entry
from routing protocols, and the FIB entry to install to kernel.
FIB override routes are never selected as best entry, and thus
are never adverticed to other routing daemons. The best FIB
override, or if it does not exist the otherwise best RIB is
selected as FIB entry to be installed.
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
Acked-by: Donald Sharp <sharpd@cumulusnetworks.com>
[CF: Massage to fit cumulus tree]
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
Replace all HAVE_MPLS #ifdef's by a run-time check if MPLS is supported
by the kernel or not. This way we don't need to create multiple packages
for each OS distribution.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Most routing daemons are not interested in certain pieces of information
when a redistributed route is being removed, like its metric and distance.
ldpd, in the other hand, needs to know the distance of the removed routes
in order to work properly. Now, instead of adding another exception in
zserv's code for ldpd, let's make zebra always send all information
about each route to its clients, independently if the route is being
added or removed. This is ok because all daemons are already prepared
to process these additional fields when the appropriate flags are set
in the zebra messages.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
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>
When sending the received route in to be added to the rib,
actually use the correct Address family.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Zebra api that was never used.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
(cherry picked from commit 33361d3992c8bff66247b76e5adaf4b0de8217df)
ZEBRA_IPV4_NEXTHOP_LOOKUP and ZEBRA_IPV6_NEXTHOP_LOOKUP
were never used by any protocol. Remove dead code
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
(cherry picked from commit 22cd6214bf44863bfb5a34b40ab4abba3c5c4574)
Pass around the vrf_id to rib_match_ipv4_multicast
so that proper lookup can be maintained. Not really
needed yet, but future fixing now.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When building a stream of nexthop information,
refactor the code that writes it to 1 function.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
NOTE: I am squashing several commits together because they
do not independently compile and we need this ability to
do any type of sane testing on the patches. Since this
series builds together I am doing this. -DBS
This new structure is the basis to get new link parameters for
Traffic Engineering from Zebra/interface layer to OSPFD and ISISD
for the support of Traffic Engineering
* lib/if.[c,h]: link parameters struture and get/set functions
* lib/command.[c,h]: creation of a new link-node
* lib/zclient.[c,h]: modification to the ZBUS message to convey the
link parameters structure
* lib/zebra.h: New ZBUS message
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
Add support for IEEE 754 format
* lib/stream.[c,h]: Add stream_get{f,d} and stream_put{f,d}) demux and muxers to
safely convert between big-endian IEEE-754 single and double binary
format, as used in IETF RFCs, and C99. Implementation depends on host
using __STDC_IEC_559__, which should be everything we care about. Should
correctly error out otherwise.
* lib/network.[c,h]: Add ntohf and htonf converter
* lib/memtypes.c: Add new memeory type for Traffic Engineering support
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
Add link parameters support to Zebra
* zebra/interface.c:
- Add new link-params CLI commands
- Add new functions to set/get link parameters for interface
* zebra/redistribute.[c,h]: Add new function to propagate link parameters
to routing daemon (essentially OSPFD and ISISD) for Traffic Engineering.
* zebra/redistribute_null.c: Add new function
zebra_interface_parameters_update()
* zebra/zserv.[c,h]: Add new functions to send link parameters
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
Add support of new link-params CLI to vtysh
In vtysh_config.c/vtysh_config_parse_line(), it is not possible to continue
to use the ordered version for adding line i.e. config_add_line_uniq() to print
Interface CLI commands as it completely break the new LINK_PARAMS_NODE.
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
Update Traffic Engineering support for OSPFD
These patches update original code to RFC3630 (OSPF-TE) and add support of
RFC5392 (Inter-AS v2) & RFC7471 (TE metric extensions) and partial support
of RFC6827 (ASON - GMPLS).
* ospfd/ospf_dump.[c,h]: Add new dump functions for Traffic Engineering
* ospfd/ospf_opaque.[c,h]: Add new TLV code points for RFC5392
* ospfd/ospf_packet.c: Update checking of OSPF_OPTION
* ospfd/ospf_vty.[c,h]: Update ospf_str2area_id
* ospfd/ospf_zebra.c: Add new function ospf_interface_link_params() to get
Link Parameters information from the interface to populate Traffic Engineering
metrics
* ospfd/ospfd.[c,h]: Update OSPF_OPTION flags (T -> MT and new DN)
* ospfd/ospf_te.[c,h]: Major modifications to update the code to new
link parameters structure and new RFCs
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
tmp
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
#
Use the 'enum nexthop_types_t' instead of
the zebra.h #defines. And remove code from
zebra.h that does not belong there.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
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)
A few places are using 0 in place of the MTYPE_* argument. The
following rewrite of the alloc tracking won't deal with that, so let's
use MTYPE_TMP instead.
Acked-by: Vincent JARDIN <vincent.jardin@6wind.com>
Acked-by: Donald Sharp <sharpd@cumulusnetworks.com>
[DL: v2: fix XFREE(0, foo) calls too]
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
quagga_time() will disappear with the next commit, this is the last
remaining user of it.
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Since IP forwarding is enabled by default on Quagga startup, it
makes more sense to only explicitly report the state of this
setting when it is disabled. Inverted the relevant printouts.
Ticket: CM-11462
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Ticket: CM-11256
Signed-off-by: Radhika Mahankali <radhika@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Kanna Rajagopal <kanna@cumulusnetworks.com>
Testing: Unit, PTM smoke, OSPF smoke, BGP Smoke
Issue:
BFD client registrations are not being sent to PTM from BGP/OSPF clients when the quagga clients have no BFD configuration. This can create stale BFD sessions in PTM when BFD is removed from quagga configuration before quagga is restarted.
BFD client de-registrations from BGP/OSPF also go missing sometimes when quagga is restarted. This also will cause stale BFD sessions in PTM.
Root Cause:
BFD client registrations were being sent at the time of BGP/OSPF daemon initialization. But, they were being sent to zebra before the socket connection between zebra and BGP/OSPF was established. This causes the missing BFD client registrations.
BFD client de-registrations are sent from zebra when zebra detects socket close for BGP/OSPF daemons. Based on the timing, the de-registrations may happen after socket between PTM and zebra is closed. This will result in missing de-registrations.
Fix:
Moved sending of BFD client registration messages to zebra connected callback to make sure that they are sent after the BGP/OSPF daemons connect with zebra.
Added BFD client de-registrations for BGP/OSPF to be also sent when zebra daemon gets restart signal. They are sent from the signal handler only if it was not already handled in zebra client socket close callback.
It's possible to have a comparison where
MULTIPATH_NUM is greater than the size of
data that a u_char supports for nexthop_num
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
With the addition of VRF's we were not properly
storing the last sent command to individual
protocols from zebra. This commit fixes this:
Pre-Fix:
Client: bgp
------------------------
FD: 14
Route Table ID: 0
Connect Time: 00:10:51
Not registered for Nexthop Updates
Last Msg Rx Time: 00:10:51
Last Msg Tx Time: 00:00:04
Last Rcvd Cmd: ZEBRA_REDISTRIBUTE_ADD
Last Sent Cmd: (null)
Post-Fix:
Client: bgp
------------------------
FD: 14
Route Table ID: 0
Connect Time: 00:02:42
Not registered for Nexthop Updates
Last Msg Rx Time: 00:02:42
Last Msg Tx Time: 00:00:09
Last Rcvd Cmd: ZEBRA_REDISTRIBUTE_ADD
Last Sent Cmd: ZEBRA_INTERFACE_UP
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
I found that zebra doesn't set correct IPv6 address in its result because of
using *addr's address. Although I'm using 0.99.22, the latest version has
also use "&addr". Shouldn't it use "addr"?
Signed-off-by: Hiroshi Yokoi <hiroshi.yokoi.0313@gmail.com>
Acked-by: Donald Sharp <sharpd@cumulusnetworks.com>
(cherry picked from commit 8ccd74c29f5242f312c1e0561497558482c9be65)
zebra_serv_un() is unused if --enable-tcp-zebra is given.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
(cherry picked from commit 4b6c33282973c9e1545a519f2a51bda3cf42ae21)
depending on the usage scenario (and availability of multitopology IGP
protocols, which is currently zero in Quagga), different approaches of
Multicast RPF lookups are useful.
Reference behaviours from commercial vendors are urib-only/mrib-only
(Juniper, depending on inet.2 availability) and lowest-distance (Cisco).
As we are currently without MT IGP support, mrib-first seems the most
useful default for Quagga.
Cc: Everton Marques <everton.marques@gmail.com>
Cc: Balaji G <balajig81@gmail.com>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The multicast code needs to know the route_node in addition to the rib
entry in order to perform distance or prefix-length comparisons. Add it
as optional "out" pointer parameter.
Cc: Everton Marques <everton.marques@gmail.com>
Cc: Balaji G <balajig81@gmail.com>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
This adds a new zapi call "ZEBRA_IPV4_NEXTHOP_LOOKUP_MRIB" performing a
Multicast RPF lookup for a given source. Details of the lookup
behaviour are left to the zebra side of things.
Note: this is non-reactive, as in, only delivers a snapshot of the state
at a particular point in time. There's no push notification of changes
happening to the RIB.
This combines the following 3 original patches:
- zebra: add zsend_ipv4_nexthop_lookup_mrib()
- zserv: Query mrib (SAFI_MULTICAST).
- zebra: Cleanups to zebra_rib.
Cc: Everton Marques <everton.marques@gmail.com>
Cc: Balaji G <balajig81@gmail.com>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
This is the same as rib_lookup_ipv4(), without the SAFI hardcoded.
Cc: Balaji G <balajig81@gmail.com>
Cc: Everton Marques <everton.marques@gmail.com>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Fix code to not discard received RAs with a lifetime of 0. The router lifetime
is only applicable for default router processing which is not relevant here.
For the purposes of BGP unnumbered, the neighbor should be learnt without
consideration of the value of router lifetime in received RA.
Note: This patch brings in a portion of the earlier commit
690baa5359 - this included some additional
changes which have been reverted.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
Ticket: CM-10943
Reviewed By: CCR-4611
Testing Done: bgp-smoke
This reverts commit 690baa5359.
Making the router lifetime in the IPv6 RAs as 0 by default would break BGP
unnumbered when this version of Quagga goes up against a 2.5.x Quagga. This
is because of a defect in the Quagga code that ignores any received RAs with
a lifetime of 0.
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
BGP Unnumbered relies on IPv6 Router Advertisements (RAs) to advertise our
link-local IPv6 address and learn of the peer's address in order to initiate
the BGP peering. When IPv6 RAs are enabled on an interface, Quagga currently
advertises a non-zero router lifetime which causes hosts receiving the RAs
to install the router as the default router. This may not be desirable in
many situations - the IPv6 RAs may be turned on just to get BGP unnumbered
peering up.
There is a sysctl available to control the host behavior (net.ipv6.conf.all.
accept_ra_defrtr). However, this requires setting on all hosts and this may
mean many hosts, especially if Quagga is run on the hosts.
An alternate solution arrived at was to modify Quagga to advertise a zero
router lifetime, unless a value is specifically set by the operator. This
patch implements this change. The change may not meet a strict interpretation
of the RFC, so it is under HAVE_CUMULUS. When hosts see an IPv6 RA with a
router lifetime of 0, they won't make that router a default router. The
patch also fixes an incorrect check in handling of received RAs which would
have caused us to drop RAs with a lifetime of 0.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
Ticket: CM-9815
Reviewed By: CCR-4611
Testing Done: Manual, bgp-min etc. (defails in defect)
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)
Changed interaction between zebra and routing protocols so that they correctly
fill in the vrf_iflist even for vrfs they're not responsible for. In that way,
when they get callbacks from zebra they can correctly understand whether they need
to create them or not.
Ticket: CM-10427
Signed-off-by: Don Slice
Reviewed-by:
Zebra is crashing inside of zserv_rnh_register when it attempts to
lookup a vrf that was just deleted:
Imagine this series of events:
Pre (A): ifdown -a -X eth0
(A) zebra notification from kernel that vrf is goneroo
(B) zebra notifies all daemons
(C) bgpd is churning because we have been removing interfaces and we
have an new path and it hasn't handled the vrf goneroo event yet from
zebra so it sends to zebra a new rnh with an old vrf_id.
(D) zebra attempts to lookup the zvrf and crashes because of pointer
dereference.
zebra handles all callbacks in one function. Convert that function to
check to see if we have a valid zvrf. If so make the callback
Ticket: CM-10482
Signed-off-by: Donald Sharp <sharpd@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>
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>
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
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>
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
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
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>
