When the rib code is informed that a table is closing/
going away, only try once to uninstall associated routes from
the fib/dataplane. The close path can be called multiple times
in some cases - zebra shutdown, e.g.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
Impose a configurable limit on the number of route updates
that can be queued towards the dataplane subsystem.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
Correct use of netlink_parse_info() in the netlink fuzzing path.
Also clarify a couple of comments about pthreads.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
We need a bit of special handling for system routes, which need
to be offered for redistribution even though they won't be
passing through the dplane system.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
Set SELECTED re immediately in rib_process, without expecting
that fib install has completed. Remove premature redistribute
call also.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
Reduce or eliminate use of global zebra_ns structs in
a couple of netlink/kernel code paths, so that those paths
can potentially be made asynch eventually.
Slide netlink_talk_info into place to remove dependency on core
zebra structs; add accessors for dplane context block
Start init of route context from zebra core re and rn structs;
start queueing and event handling for incoming route updates.
Expose netlink apis that don't rely on zebra core structs;
add parallel route-update code path using the dplane ctx;
simplest possible event loop to process queued route'
updates.
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>
During a debugging session last night I discovered that I was
still having some `fun` figuring out why zebra was not making
a route's nexthop active. After some debugging I figured out
that I was missing some states that we could end up in that
didn't have debug information about what happened in nexthop_active.
Add the missing breadcrumbs for nexthop resolution. In addition
add a bit of code to notice the ebgp state without recursion turned
on and to let the user know about it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
on some cases, kernel routes are not selected, because the kernel
suppressed it without informing the netlink layer that the route has
been suppressed ( for instance, when an interface goes down, the route
never goes back when interface goes up again). This commit intends to
suppress that entry from zebra.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.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
Wrapper the get/set of the table->info pointer so that
people are not directly accessing this data.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Debugging inactive nexthops in zebra can be quite difficult
and non-obvious what has gone wrong. Add detailed rib
debugs for the cases where we decide that a nexthop is
inactive so that we can more easily debug a reason
for the failure.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The _route_entry_dump function was not handling the nexthop as passed
in from an upper level protocol appropriate and as such not displaying
the v4/v6 nexthop right in the case where we have both going.
Additionally dump the nexthop vrf as well.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
For OpenFabric operation, we need to be able to install routes via
interfaces without any IPv4 addresses configured. Introduce a flag
ZEBRA_FLAG_ONLINK which upper protocols can set on a route they send
towards zebra, to force the nexthops to be considered onlink.
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
* Check for the modified routemap in zebra_route_map_process_update_cb()
* Added zebra_rib_table_rm_update() for RIB routemap processing
* Added zebra_nht_rm_update() for NHT routemap processing
Signed-off-by: kssoman <somanks@vmware.com>
There is no need to check for failure of a ALLOC call
as that any failure to do so will result in a assert
happening. So we can safely remove all of this code.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Allow protocols to specify to zebra that they would like zebra
to use the distance passed down as part of determine sameness for
Route Replace semantics.
This will be used by the static daemon to allow it to have
backup static routes with greater distances.
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>
Commit a2ca67d1d2 consolidated IPv4 and IPv6 handling. It also applied
our ignorance for IPv4 srcdest routes onto IPv6.
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
Add 'const' to prefix args to several zebra route update,
redistribution, and route owner notification apis.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
Add a bit of code to allow return of data plane
request messages.
Add the ability to pass the result back to callers
of kernel_route_rib.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The SOUTHBOUND_XXX enum was named a bit poorly.
Let's use a bit better name for what we are trying to do.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
