zebra is using NEXTHOP_FLAG_FIB as the basis of whether or not
a route_entry is installed. This is problematic in that we plan
to separate out nexthop handling from route installation. So modify
the code to keep track of whether or not a route_entry is installed/failed.
This basically means that every place we set/unset NEXTHOP_FLAG_FIB, we
actually also set/unset ROUTE_ENTRY_INSTALLED on the route_entry.
Additionally where we check for route installed via NEXTHOP_FLAG_FIB
switch over to checking if the route think's it is installed.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Favor usage of the afi_t enumeration to identify address-families
over using the classic AF_INET[6] constants for that. The choice to
use either of the two seems to be mostly arbitrary throughout our
code base, which leads to confusion and bugs like the one fixed by
commit 6f95d11a1. To address this problem, favor usage of the afi_t
enumeration whenever possible, since 1) it's an enumeration (helps
the compilers to catch some bugs), 2) has a safi_t sibling and 3)
can be used to index static arrays. AF_INET[6] should then be used
only when interfacing with the kernel or external libraries like
libc. The family2afi() and afi2family() functions can be used to
convert between the two different representations back and forth.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
The zebra_delete_rnh function is not needed to be exposed
to the entire world. Limit it's scope.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The deletion of a rnh is always proceeded by the same checks
to see if it is done. Just let zebra_delete_rnh do this test.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
For nexthop handling use the actual resolved nexthop.
Nexthops are stored as a `special` list:
Suppose we have 3 way ecmp A, B, C:
nhop A -> resolves to nhop D
|
nhop B
|
nhop C -> resolves to nhop E
A and C are typically NEXTHOP_TYPE_IPV4( or 6 ) if they recursively resolve
We do not necessarily store the ifindex that this resolves to.
Current nexthop code only loops over A,B and C and uses those for
the zebra_rnh.c handling. So interested parties might receive non-fully
resolved nexthops( and they assume they are! ).
Let's convert the looping to go over all nexthops and only deal with
the resolved ones, so we will look at and use D,B and E.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Always resend the nexthop information when we get a registration
event. Multiple daemons expect this information.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com.
Dplane support for zebra's route cleanup during shutdown (clean
shutdown via SIGINT, anyway.) The dplane has the opportunity to
process incoming updates, and then triggers final cleanup
in zebra's main thread.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
The `struct zebra_ns` data structure is being used
for both router information as well as support for
the vrf backend( as appropriate ). This is a confusing
state. Start the movement of `struct zebra_ns` into
2 things `struct zebra_router` and `struct zebra_ns`.
In this new regime `struct zebra_router` is purely
for handling data about the router. It has no knowledge
of the underlying representation of the Data Plane.
`struct zebra_ns` becomes a linux specific bit of code
that allows us to handle the vrf backend and is allowed
to have knowledge about underlying data plane constructs.
When someone implements a *bsd backend the zebra_vrf data
structure will need to be abstracted to take advantage of this
instead of relying on zebra_ns.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Work to handle the route-maps, namely the header changes in zebra_vrf.h
and the mapping of using that everywhere
Signed-off-by: vishaldhingra vdhingra@vmware.com
The code prior to this change, was allowing clients to register
for nexthop tracking. Then zebra would look up the rnh and
send to that particular client any known data. Additionally
zebra was blindly re-evaluating the rnh for every registration.
This leads to interesting behavior in that all people registered
for that nexthop will get callbacks even if nothing changes.
Modify the code to know if we have evaluated the rnh or not
and if so limit the re-evaluation to when absolutely necessary
This is of particular importance to do because of nht callbacks
for protocols cause those protocols to do not insignificant
work and as more protocols are registering for nht callbacks
we will cause more work than is necessary.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This is the start of separating out the static
handling code from zebra -> staticd. This will
help simplify the zebra code and isolate static
route handling to it's own code base.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* Add centralized thread scheduling dispatchers for client threads and
the main thread
* Rename everything in zserv.c to stop using a combination of:
- zebra_server_*
- zebra_*
- zserv_*
Everything in zserv.c now begins with zserv_*.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
* Rename client_connect and client_close hooks to zapi_client_connect
and zapi_client_close
* Remove some more unnecessary headers
* Fix a copy-paste error in zapi_msg.[ch] header comments
* Fix an inclusion comment in zserv.c
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
zserv.c was using hardcoded callbacks to clean up various components
when a client disconnected. Ergo zserv.c had to know about all these
unrelated components that it should not care about. We have hooks now,
let's use the proper thing instead.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
zserv.c has become something of a dumping ground for everything vaguely
related to ZAPI and really needs some love. This change splits out the
code fo building and consuming ZAPI messages into a separate source
file, leaving the actual session and client lifecycle code in zserv.c.
Unfortunately since the #include situation in Zebra has not been paid
much attention I was forced to fix the headers in a lot of other source
files. This is a net improvement overall though.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
When I implemented this code change I was only testing against
static routes and with one nexthop. I missed the fact that
we needed to tell rib_process to actually rethink the nexthops.
Ticket: CM-20274
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we have a PBR installed as a table, we need to notice
when a nexthop changes and rethink the routes for the pbr
tables.
Add code to nexthop tracking to notice the pbr watched
nexthop has changed in some manner. If it is a pbr route
that depends on the nexthop then just enqueue it for
rethinking.
This is a bit of a hammer, we know that only pbr routes
are going to be installing routes in weird non-standard
tables as such we need to only handle nexthop changes
for nexthops that are actually changing that we care
about and to only requeue for route nodes we have
route entries for from PBR
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The following types are nonstandard:
- u_char
- u_short
- u_int
- u_long
- u_int8_t
- u_int16_t
- u_int32_t
Replace them with the C99 standard types:
- uint8_t
- unsigned short
- unsigned int
- unsigned long
- uint8_t
- uint16_t
- uint32_t
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
When we are signaling to a client from zebra that a nexthop
has changed, include the labels on the nexthop as well.
Upper level protocols need to know if the labels exist
in order to make intelligent decisions about what to do.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Group send and receive functions together, change handlers to take a
message instead of looking at ->ibuf and ->obuf, allow zebra to read
multiple packets off the wire at a time.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Also modify `struct route_entry` to use nexthop_groups.
Move ALL_NEXTHOPS loop to nexthop_group.h
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Add the originating routes type and instance to the nexthop
update message. This is necessary because there exist
scenarios where BGP needs to make a decision about the
originating route type and instance to know if it is
going to be doing a route replace to a route that would
resolve to itself.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The nh_resolve_via_default function is an accessor function
for NHT in zebra. Let's move this function to it's proper
place.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The encoding of the nexthop update made some distinctions
between nexthop types that it does not need to.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The function zserv_create_header was exactly the same
as zclient_create_header. Let's just have one in the
system.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
With VRF route-leaking we need to know what vrf
the nexthops are in compared to this vrf. This
code adds the nh_vrf_id to the route entry and
sets it up correctly for the non-route-leaking
case.
The assumption here is that future commits
will make the nh_vrf_id *different* than
the vrf_id.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Problems reported with zebra nht oscillating when a nexthop is resolved
using the same address to reach the nexthop (for example, 10.0.0.8 is
resolved via 10.0.0.8/32.) This fix removes this attempt to resolve
thru itself unless the route being resolved is also a host route.
This fix also walks up the tree looking for a less specific route to
reach the nexthop if needed. Smoke testing completed successfully.
Ticket: CM-8192
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: CCR-6583
Testing done: Manual testing successful, bgp-min completed successfully
l3-smoke completed with two test changes required.
list_free is occassionally being used to delete the
list and accidently not deleting all the nodes.
We keep running across this usage pattern. Let's
remove the temptation and only allow list_delete
to handle list deletion.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Current cleanup is for unset values or variables that are not used anymore.
Regarding ospfd/ospf_vty.c: argv_find()
we'll never get it NULL, so get coststr = argv[idx]->arg;
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>
With the introduction of the pseudowire manager, the NHT tracking code
needs to detect label updates as well.
Create a specific nexthop flag for that. We can't reuse the
RIB_ENTRY_NEXTHOPS_CHANGED flag for this porpose because this flag is
always cleared and reevaluated in rib_process(), setting it outside that
function is a nop.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
If the remote end of a pseudowire becomes unreachable (no route or an
unlabeled route), then it must be uninstalled. In the same way, when
the remote end becomes reachable, the pseudowire must be installed.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
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>
Fix for another issue with next-hop tracking for overlapping static routes
created a problem removing the dead routes. This fix corrects that error.
Ticket: CM-13710
Signed-off-by: Don Slice
Reviewed By: Donald Sharp
Testing Done: ospf-smoke, bgp-smoke
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>
Suppose we are handling the process_workq and either a new static
route is installed or a Routing Protocol installs a new route.
We will call evaluate_rnh with a specific prefix. We might
have a situation where we clear the NHC flag prematurely.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Zebra when it was scanning the tree would unset NEXTHOPS_CHANGED
after the first notification. If the route we are notifying because
of covers multiple interesting nexthops then we would be unable
to know that we need to notify for that one as well because of
the flag removal.
Ticket: CM-15157
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This provides DMVPN support and integrates to strongSwan. Please read
README.nhrpd and README.kernel for more details.
[DL: cherry-picked from dafa05e65fe4b3b3ed5525443f554215ba14f42c]
[DL: merge partially resolved, this commit will not build.]
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
In the future we plan to update Nexthop tracking to better
handle ipv6 lla. This commit will set this up for that.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When passing up NEXTHOP_TYPE_IPV4 pass up the ifindex as well
Zebra already stores this data by passing it up PIM will be
able to use NEXTHOP_TYPE_IPV4 without having to do a recursive
lookup.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: Chirag Shah <chirag@cumulusnetworks.com>
When zebra calls routing protocols back with either
ZEBRA_NEXTHOP_UPDATE or ZEBRA_IMPORT_CHECK_UPDATE
pass the distance value too.
This is to set us up for nht for pim as that it needs
the distance sometimes too.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This contains bgp memory leak fixes as well as cleanups to VRF/namespace
handling and has been run through extended testing in Cumulus' testbed:
Tested-by: Donald Sharp <sharpd@cumulusnetworks.com>
Try to free all memory explicitly on exit. This should help to detect
new memory leaks in the future with tools like valgrind.
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>
It seems these two were at some point copied in from rsync; replace with
more recent versions that will hopefully become available in glibc as
well.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Problem reported that in certain configs, when a router is initially
booted and the link is bounced, we can end up with a bogus static route
in the table. This was due to the assumption in zebra_rnh that a static
route would not be recursively resolved through another static route with
a different next-hop. This fix changes this assumption. Tested manually
and bgp-min, ospf-min, and vrf-min run with no new failures.
Ticket: CM-13328
Signed-off-by: Don Slice
Reviewed-by: CCR-5338
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>
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-12561
(cherry picked from commit 337299a936)
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 flag is used internally in zebra only. And it makes no sense
to expose it over the zclient API, as having it set from client
could corrupt the internal state.
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
Acked-by: Donald Sharp <sharpd@cumulusnetworks.com>
(cherry picked from commit 7eb6136b2732d4782360f9f376336c6d4f667ff0)
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>
Added the ability to supply a route-map to the ip import-table command,
which greatly improves filtering between the kernel prefixes in a
non-default table that are imported into the zebra rib.
Ticket:CM-8168
Signed-off-by: Donald Slice
Reviewed By: Donald Sharp
In zebra_deregister_rnh_static_nexthops the nh_p
structure was not being properly initialized for
all the cases that we could be storing a nexthop
for. This was causing code later to retrieve
the table from an nh_p->family which was garbage.
In the case of BLACKHOLE and Ifindex based routes
do nothing because they shouldn't be a nexthop
considered for NHT.
==2239== Conditional jump or move depends on uninitialised value(s)
==2239== at 0x4E5F6CE: family2afi (prefix.c:217)
==2239== by 0x155F7C: get_rnh_table (zebra_rnh.c:83)
==2239== by 0x156194: zebra_lookup_rnh (zebra_rnh.c:148)
==2239== by 0x15655E: zebra_deregister_rnh_static_nh (zebra_rnh.c:242)
==2239== by 0x156681: zebra_deregister_rnh_static_nexthops
(zebra_rnh.c:280)
==2239== by 0x12F3DF: rib_unlink (zebra_rib.c:2210)
==2239== by 0x12E9CE: rib_process (zebra_rib.c:1843)
==2239== by 0x12EA8A: process_subq (zebra_rib.c:1873)
==2239== by 0x12ECAF: meta_queue_process (zebra_rib.c:1936)
==2239== by 0x4E89625: work_queue_run (workqueue.c:298)
==2239== by 0x4E63230: thread_call (thread.c:1577)
==2239== by 0x125830: main (main.c:432)
==2239==
==2239== Conditional jump or move depends on uninitialised value(s)
==2239== at 0x4E5F6DB: family2afi (prefix.c:220)
==2239== by 0x155F7C: get_rnh_table (zebra_rnh.c:83)
==2239== by 0x156194: zebra_lookup_rnh (zebra_rnh.c:148)
==2239== by 0x15655E: zebra_deregister_rnh_static_nh (zebra_rnh.c:242)
==2239== by 0x156681: zebra_deregister_rnh_static_nexthops
(zebra_rnh.c:280)
==2239== by 0x12F3DF: rib_unlink (zebra_rib.c:2210)
==2239== by 0x12E9CE: rib_process (zebra_rib.c:1843)
==2239== by 0x12EA8A: process_subq (zebra_rib.c:1873)
==2239== by 0x12ECAF: meta_queue_process (zebra_rib.c:1936)
==2239== by 0x4E89625: work_queue_run (workqueue.c:298)
==2239== by 0x4E63230: thread_call (thread.c:1577)
==2239== by 0x125830: main (main.c:432)
Ticket: CM-10667
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Shrijeet Mukherjee <shm@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>
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
NextHop Tracking (NHT) is a significant function introduced into Quagga
by Cumulus. Initially intended for tracking BGP nexthops, this has been
extended subsequently to also cater to nexthops for static routes, BGP
peer reachability tracking and BGP route tracking for routes to be
imported into BGP.
This patch reorganizes the code a bit to make it easier to follow and
maintain. No functional changes introduced.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Dinesh Dutt <ddutt@cumulusnetworks.com>
Ticket: CM-5599
Reviewed By: CCR-3906
Testing Done: Manual and bgpsmoke
