Pass lists of results back to zebra from the dataplane subsystem
(and pthread). This helps reduce the lock/unlock cycles when
zebra is busy. Also remove a couple of typedefs that made their
way into the dataplane header file - those violate the FRR style
guidelines.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
The route_info data structure already had a mapping of route type
to admin distance. Consolidate the meta_queue_map information
into this route_info data structure. This is to reduce the number
of places we need to remember to touch when adding a new routing
protocol.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When a route removal failure happens return to the installing
protocol that the route deletion failed.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
In the zebra rib processing workqueue, set a small timeout
so that we will wait a short time if the queue into the
async dataplane is full. This helps avoid a situation where
the zebra main pthread constantly retries rib work without
giving the dataplane pthread a chance to make progress.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
NEXTHOP_FLAG_ACTIVE currently means that the nexthop is considered
good enough to be installed. With current ecmp restrictions this
translation from multipath_num is enforced in the data plane.
The problem with this is of course that every data plane now
becomes concerned about the multipath num and must enforce it
independently. Currently *bsd does not honor multipath_num at
all and linux marks all nexthops as being installed even when
it honors a multipath_num that is less than the total.
This code change moves the multipath_num enforcement from a dataplane
decision to a zebra nexthop decision. Thus dataplanes now can
just install those nexthops marked as NEXTHOP_FLAG_ACTIVE
without having to worry about multipath_num.
*BSD will now respect multipath_num and Linux now properly notes
which routes are actually installed or not:
sharpd@donna ~/f/t/topotests> ps -ef | grep frr
frr 6261 1556 0 09:12 ? 00:00:00 /usr/lib/frr/zebra -e 2 --daemon -A 127.0.0.1
frr 6279 1556 0 09:12 ? 00:00:00 /usr/lib/frr/staticd --daemon -A 127.0.0.1
donna.cumulusnetworks.com(config)# do show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
F - PBR, f - OpenFabric,
> - selected route, * - FIB route
K>* 0.0.0.0/0 [0/106] via 10.0.2.2, enp0s3, 00:00:45
S>* 4.4.4.4/32 [1/0] via 10.0.2.1, enp0s3, 00:00:02
* via 192.168.209.1, enp0s8, 00:00:02
via 192.168.210.1, enp0s9 inactive, 00:00:02
C>* 10.0.2.0/24 is directly connected, enp0s3, 00:00:45
C>* 192.168.209.0/24 is directly connected, enp0s8, 00:00:45
C>* 192.168.210.0/24 is directly connected, enp0s9, 00:00:45
donna.cumulusnetworks.com(config)#
sharpd@donna ~/f/t/topotests> ip route show
default via 10.0.2.2 dev enp0s3 proto dhcp metric 106
4.4.4.4 proto 196 metric 20
nexthop via 10.0.2.1 dev enp0s3 weight 1
nexthop via 192.168.209.1 dev enp0s8 weight 1
10.0.2.0/24 dev enp0s3 proto kernel scope link src 10.0.2.15 metric 106
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
192.168.209.0/24 dev enp0s8 proto kernel scope link src 192.168.209.2 metric 105
192.168.210.0/24 dev enp0s9 proto kernel scope link src 192.168.210.2 metric 103
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The rib_lookup_ipv4_route function is only used in a debug path.
Is only used for v4 and only checks to make sure that the rib
and fib are in sync( which is not needed/used/supported on other
platforms ). So let's just remove it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Limit the number of updates processed from the incoming queue;
add more stats. Fill out apis for dataplane providers; convert
route update processing to provider model; move dataplane
status enum
Signed-off-by: Mark Stapp <mjs@voltanet.io>
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>
Add to zebra route-maps the ability to match on a source-instance
route-map FOO deny 55
match source-instance 5
route-map FOO permit 60
ip protocol any route-map FOO
This will match any protocol route installation with a source-instance of 5.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ensure that when EVPN routes are installed into zebra, the router MAC
is passed per next hop and appropriately handled. This is required for
proper multipath operation.
Ticket: CM-18999
Reviewed By:
Testing Done: Verified failed scenario, other manual tests
Signed-off-by: Vivek Venkatraman <vivek@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>
The code to reinstall self originated routes was not behaving
correctly. For some reason we were looking for self originated
routes from the kernel to be of type KERNEL. This was probably
missed when we started installing the route types. We should
depend on the self originated flag that we determine from
the callback from the kernel.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com.
There were a few cases where we were not properly de-registering
the static nexthops passed to us. This was important when
the static route was being removed for whatever reason that
we did not leave slag for the nexthop tracking.
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>
PR #1739 added code to leak routes between (default VRF) VPN safi and unicast RIBs in any VRF. That set of changes included temporary CLI including vpn-policy blocks to specify RD/RT/label/&c. After considerable discussion, we arrived at a consensus CLI shown below.
The code of this PR implements the vpn-specific parts of this syntax:
router bgp <as> [vrf <FOO>]
address-family <afi> unicast
rd (vpn|evpn) export (AS:NN | IP:nn)
label (vpn|evpn) export (0..1048575)
rt (vpn|evpn) (import|export|both) RTLIST...
nexthop vpn (import|export) (A.B.C.D | X:X::X:X)
route-map (vpn|evpn|vrf NAME) (import|export) MAP
[no] import|export [vpn|evpn|evpn8]
[no] import|export vrf NAME
User documentation of the vpn-specific parts of the above syntax is in PR #1937
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
the rib_wib_table function was uncalled by anyone remove
and additionally remove it's static function it called.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we receive an arbitrary table over the netlink bus
save it for later perusal and sweep any routes that
we may have created from an earlier run.
The current redistribute code is limited to
ZEBRA_KERNEL_TABLE_MAX. I left this alone for the
moment because I believe it needs to be converted
to a RB tree instead of a flat array. Which is more
work for the future. Additionally this proposed
change might necessitate some cli changes or rethinks.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
It is possible for clients to install routes into tables
that they desire. Modify the code to delete these routes
from these tables as well.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
There were several places where when I am attempting
to debug zebra functionality that I would really
like to have the ability to know what vrf I think
I am operating on.
Add the vrf_id to a bunch of zlog_debug messages
to help figure out issues when they happen.
Signed-off-by: Donald Sharp <sharpd@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>
If a interested party removes one of it's routes let
it know that it has happened as asked for.
Add a ZAPI_ROUTE_REMOVED to the send of the route_notify_owner
Add a ZAPI_ROUTE_REMOVE_FAIL to the send of the route_notify_owner
Add code in sharpd to notice this and to allow it to keep
track of routes removed for that invocation and give timing
results.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Implement support for EVPN symmetric routing for IPv6 routes. The next hop
for EVPN routes is the IP address of the remote VTEP which is only an IPv4
address. This means that for IPv6 symmetric routing, there will be IPv6
destinations with IPv4 next hops. To make this work, the IPv4 next hops are
converted into IPv4-mapped IPv6 addresses.
As part of support, ensure that "L3" route-targets are not announced with
IPv6 link-local addresses so that they won't be installed in the routing
table.
Signed-off-by: Vivek Venkatraman vivek@cumulusnetworks.com
Reviewed-by: Mitesh Kanjariya mitesh@cumulusnetworks.com
Reviewed-by: Donald Sharp sharpd@cumulusnetworks.com
The ZEBRA_FLAG_INTERNAL flag is used to signal to zebra that
the route being added, the nexthops for it can be recursively
resolved. This name keeps throwing me off when I read it
so let's rename to something that allows the developer to
understand what is going on.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The 'struct route_entry *old' and 'struct route_entry *new' can sometimes
be the same route type( for a route replace ), so when we are checking
to see if a new owner has taken over, don't tell the owner it is
replacing it self.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com.
Some of the tables are no longer stored in the zvrf
and in the zns now. On shutdown zns is cleaned up
after vrf( and rightly so!) As such we should not
attempt to count the information if we don't have
a zvrf.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Problem seen when a prefix was learned with nexthops from multiple
route sources (static and ospf in this case) and the link to that
nexthop flaps. The nht entry was incorrectly deleted so when the
link came back up the static was not re-installed correctly.
Ticket: CM-19675
Signed-off-by: Don Slice <dslice@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>
When a rib_unlink() event is directly called for a
route_entry we need to see if the dest->selected_fib
is the same and just unset the dest->selected_fib.
This was happening for redistributed table 10 routes
into BGP.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The dest->selected_fib assignment needs to happen
after the install and should be controlled by
the southbound api return of success or failure.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The route_node that we are working on is going to be interesting
to the kernel_route_rib_pass_fail. So I am setting up the
code to allow me to pass it. This will be done in a subsuquent
commit.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When a nexthop is resolved via a label based nexthop, copy
the labels into the newly created recursive nexthop.
Please note that this does not fix the case where we
have a label based nexthop that is recursively resolved
through *another* nexthop that is also label based.
In this case we need to create a new label stack
for those routes.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Allow this to work:
vrf DONNA
ip route 4.3.2.1/32 192.168.1.5 nexthop-vrf EVA
The static route code was not properly telling the
nexthop resolution code what vrf to use.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we are handling nexthops in zebra, use the appropriate
vrf to figure out if the nexthops are active or not.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Add to the rib_add function the ability to pass in the nexthops
vrf.
Additionally when we decode the netlink message from the linux
kernel, properly figure out the nexthops vrf_id.
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>
The rn can not have an rn->info pointer and as
such the dest may be NULL. Don't assign
the old_fib pointer if so. This is ok
because we know RNODE_FOREACH... will not
iterate if dest is NULL.
Fixes: #1575
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Linux has the ability to support a concept of 'realms'.
This concept allows you to mark routes with a realm id
value of 1-255. If you have marked the realm
of a route then you can use the tc program to
apply policy to the routes.
This commit adds the ability of FRR to interpret
a tag from (1-255) as a realm when installing into
the kernel. Please note that at this point in time
there is no way to set policy from within FRR. This
must be done outside of it.
The normal methodology for setting tags is valid here
via a route-map.
Finally this is only applied if the --enable-realms configure
option is applied.
Signed-off-by: Kaloyan Kovachev <kkovachev@varna.net>
The SELECTED_FIB flag was placed upon the entry that we
have inserted into the kernel. Remove this flag and replace
with a `rib_dest_t` *selected_fib. Just keep track of the
selected_fib as we modify it. This removes allot of
FOREACH_RE loops as that we do not need to find the
entry anymore.
At this point in time I think this is a very minor performance
boost. Most `rib_dest_t` structures do not typically carry
more than 1 route_entry, but the minute you start having more
than one entry you can and will start having significant processing
time spent finding the selected_fib.
A future commit may re-order the route entries and possibly
keep more pointers on `rib_dest_t` to avoid lookup. This
is a bit tricky because of the FIB_OVERRIDE code.
Signed-off-by Donald Sharp <sharpd@cumulusnetworks.com>
When a route is installed or deleted into the kernel allow a
callback mechanism to handle the success/failure of
the kernel call.
This separation is to allow us to do these things:
1) In the future create a true pthread to handle route
install/deletes. This way we can schedule these
events in a smarter fashion
2) Allow us to use a common southbound api for route
install and deletion.
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>
When we are installing into the kernel, not the
change points for notification to a higher level
protocol and make it happen
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The rib_uninstall_kernel for non-UNICAST routes when
it is marking a route as no-longer installed should
actually mark it as uninstalled.
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.
Allow the user to modify the work-queue processing hold time
from 10ms to a value from (0-10000). Make the command hidden
as that it's a semi-dangerous command and it could cause
issues.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Convert the list_delete(struct list *) function to use
struct list **. This is to allow the list pointer to be nulled.
I keep running into uses of this list_delete function where we
forget to set the returned pointer to NULL and attempt to use
it and then experience a crash, usually after the developer
has long since left the building.
Let's make the api explicit in it setting the list pointer
to null.
Cynical Prediction: This code will expose a attempt
to use the NULL'ed list pointer in some obscure bit
of code.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
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>
While u_char is technically a uint8_t in size I would
like to treat and think about the admin distance
as an actual integer value from 0-255, instead
of a char.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
If we have already scheduled a node to be on the meta_queue, there is no
need to schedule it up again.
On startup we are calling rib_update() multiple times per connected route.
Due to the multiple ways we can get callbacks for adding a connected route
I decided it was best to just improve meta_queue performance as opposed
to trying to figure out all the different ways across all the platforms
that we can decide that a connected route has changed. This appears
to solve the issue with a very large # of interfaces coming up
at the same time on startup.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Both function were very similar, and as we know code duplication is not
good. As an example, in the past couple of weeks some fixes were made
on rib_add() but not on rib_add_multipath(), causing known bugs to still
exist in a different form.
Instead of merging the two functions into one, let's make rib_add()
call rib_add_multipath() with the appropriate parameters. This way we
remove the code duplication but still keep the easy-to-use rib_add()
function for single-path routes.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Fixes the following bug:
% ip route add 50.0.0.0/8 nexthop via 10.0.1.2 nexthop via 10.0.2.2
% ip route replace 50.0.0.0/8 nexthop via 10.0.1.3 nexthop via 10.0.2.3
% ip route replace 50.0.0.0/8 nexthop via 10.0.1.4 nexthop via 10.0.2.4
%
% vtysh -c "show ip route"
[snip]
K * 50.0.0.0/8 [0/0] via 10.0.1.4, rt1-eth1, 00:00:00
* via 10.0.2.4, rt1-eth2, 00:00:00
K * 50.0.0.0/8 [0/0] via 10.0.1.3, rt1-eth1, 00:00:10
* via 10.0.2.3, rt1-eth2, 00:00:10
K>* 50.0.0.0/8 [0/0] via 10.0.1.2, rt1-eth1, 00:00:24
* via 10.0.2.2, rt1-eth2, 00:00:24
Commit a3d18ce6 fixed a similar problem for single-path routes.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Commit f19435a8 fixed rib_add() but didn't fix rib_add_multipath().
While here, remove the unnecessary 'same->table == re->table' check as
it always evaluate to true.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
This fixes the broken indentation of several foreach loops throughout
the code.
From clang's documentation[1]:
ForEachMacros: A vector of macros that should be interpreted as foreach
loops instead of as function calls.
[1] http://clang.llvm.org/docs/ClangFormatStyleOptions.html
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
There exists situations where it is possible to have duplicate
nexthops passed from a higher level protocol into zebra.
This code notices this duplication of nexthops and marks
the duplicates as DUPLICATE so we don't attempt to install
it into the kernel.
This is important on *BSD as I understand it because passing
duplicate nexthops will cause the route to be rejected.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* Reuse route_distance() on rib_add_multipath() and on rib_add();
* Set the admin distance of LDP and BGP MPLS LSPs.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Set the default admin distance for some route types
more appropriately. The route_distance function
would return 0 for array items not configured, which
is not the right thing to do.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
When we get a route install for a route that needs to be recursively
resolved allow the blackhole to be considered and used if it is
available.
This allows bgp to install a route that will be blackholed.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
We should only be operating RIB_UPDATE_IF_CHANGE on
types that zebra has control of. We assume that
the calling routing protocol is going to take care
of their own route changes based upon the interface
state change.
Also try to re-organize the code a tiny bit to allow
it to fit better within a tabed world.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
There is no need to retrieve the zvrf *unless* we are doing
debugs. So move the retrieval under the debug statement.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
With unnumbered interfaces on Linux we have the same IP address configured
on several different interfaces and hence multiple connected routes for
the same prefix.
With that said, add an exception in rib_add() to allow zebra to keep
track of all connected routes. We don't need to worry about the bugs
reported in a3d18ce because connected routes are always added from the
connected_up() function, and connected_update() already takes care of
handling duplicate addresses per interface.
Fixes#1112.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
With the change to make zebra pass routes to the kernel
with the 'correct' proto name, it caused zebra to
not properly recognize them on startup again
the next time such that the route would not
be deleted.
Modify rt_netlink.c to notice that we have a
self originated route and to properly mark
the type of route it was.
Modify rib_table_sweep to mark the nexthops
as active so that when we go to delete the
self originated routes it would properly
delete from the kernel.
Fixes: #1061
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Link-local routes are unique in the sense that they all have the same
prefix but have different nexthops (local interfaces). Add an exception
in rib_add() to allows us to keep track of all of them.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Fixes the following bugs:
1)
% ip -6 route add 5000::/64 via 3000::2
% ip -6 route replace 5000::/64 via 3000::2
% ip -6 route replace 5000::/64 via 3000::2
% ip -6 route replace 5000::/64 via 3000::2
% ip -6 route replace 5000::/64 via 3000::2
%
% vtysh -c "show ipv6 route"
[snip]
K * 5000::/64 [0/1024] via 3000::2, rt1-eth0
K * 5000::/64 [0/1024] via 3000::2, rt1-eth0
K * 5000::/64 [0/1024] via 3000::2, rt1-eth0
K * 5000::/64 [0/1024] via 3000::2, rt1-eth0
K>* 5000::/64 [0/1024] via 3000::2, rt1-eth0
2)
% ip -6 route add 7000::/64 via 3000::2
% ip -6 route replace 7000::/64 via 3000::3
% ip -6 ro | grep 7000
7000::/64 via 3000::3 dev rt1-eth0 metric 1024 pref medium
%
% vtysh -c "show ipv6 route"
[snip]
K * 7000::/64 [0/1024] via 3000::3, rt1-eth0
K>* 7000::/64 [0/1024] via 3000::2, rt1-eth0
NOTE: the check for ROUTE_ENTRY_REMOVED was redundant as it was already
performed at the beginning of the loop.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
