Switch the RB tree implementation completely to the new dlg@'s version
that uses pre-declared functions instead of macros for tree functions.
Original e-mail/diff:
https://marc.info/?l=openbsd-tech&m=147087487111068&w=2
Pros:
* Reduces the amount of code that the usage of those macros generate
* Allows the compiler to do a better compile-time check job
* Might have better i-cache utilization since the tree code is shared
Con:
* dlg@ benchmarks shows it has 'very slightly slower' insertions
* imported RB_* code must adapt the following calls:
RB_INIT(), RB_GENERATE(), RB_ROOT(), RB_EMPTY(), make compare
functions use 'const' (if not already) and maybe others.
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>
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>
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>
... no need to have struct zlog generally-exposed.
A few files get to include log_int.h because they use zlog/vzlog.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
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>
This commit is also taking into account changes related to srcdes
feature introduction in zebra folder.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Ticket: CM-12262
Reviewed By: CCR-5065
Testing Done: Manual
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The original goal of the zebra change was to force all:
NEXTHOP_TYPE_IPV4 -> NEXTHOP_TYPE_IPV4_IFINDEX
NEXTHOP_TYPE_IPV6 -> NEXTHOP_TYPE_IPV6_IFINDEX
This causes issues in routes being installed into the kernel
backing this out until I can get time to fully understand
what is going wrong.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
We had a large block of #if 0 code. Since it's
been that way for like 8 months now, lets go ahead
and just remove it.
Additionally the rib_delete function was returning
a return code that was summarily ignored. Let's
clean up the expectation of returning anything.
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>
There is a scenario where a RIB entry is unlinked and freed during RIB
processing. However, the walk of the entries is not being performed in
a safe manner. Fix the code to do this correctly.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Ticket: CM-13393
Reviewed By: Trivial
Testing Done: Basic manual test
It looks like 'nexthop_fib_num' has been lingering around since 2003
without any use. Remove it.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
On *BSD, we update a route in the FIB by removing the old one and then
installing the new version.
With that said, on kernel_route_rib() we need to provide a pointer to
both the old version and the new version of the route.
We were, however, passing a pointer to the new version to both the
'old' and 'new' parameters. This is not a problem on Linux, which uses
NLM_F_REPLACE to update routes, but it breaks route updates on *BSD
because the 'old' parameter points to a route that is not installed in
the kernel. The kernel_route_rib() function then fails to uninstall the
supposedly 'old' route and can fail to install the new version as well if
the kernel doesn't support ECMP (e.g. FreeBSD with default configuration).
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
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>
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>
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>
[DL: picked out from: "atomic FIB updates"]
This simplifies the OS-specific route update API into a single entry
point, kernel_route_rib(), which dispatches the various operations
internally.
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
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>
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>
In linux, 'scope' is a hint of distance of the IP. And this is
evident from the fact that only lower scope can be used as recursive
via lookup result. This changes all interface routes scope to link
so kernel will allow regular routes to use it as via. Then we do
not need to use the 'onlink' attribute.
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
This patch installs labeled static routes in the FIB. The routes are installed
using the RTA_ENCAP (and RTA_ENCAP_TYPE) nested attributes.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-6040
Reviewed By: CCR-3091
Testing Done: Tested in SE-1, brief manual testing now
Fix LSP scheduling to occur only after routes are processed because
the LSP resolution depends on the nexthop route being selected. This
is similar to how NHT processing is scheduled.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
Ticket: CM-6743
Reviewed By: CCR-3233
Testing Done: Verified the failed test multiple times.
Install the statically configured LSPs into the FIB (kernel). This is done
using the new attributes and definitions for MPLS in the kernel -
RTA_VIA, RTA_NEWDST and AF_MPLS.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-4804
Reviewed By: CCR-3088
Testing Done: Manual in SE-1
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>
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>
rib_match is broken because the prefix is being
treated as a char * pointer instead of the
correct data type.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
(cherry picked from commit 8b5d6c95781b7c55faa957a2d3edf00c1ecb5c5a)
Author: Timo Teräs <timo.teras@iki.fi>
Date: Fri Jan 15 17:36:29 2016 +0200
zebra: atomic FIB updates
This commit updates the kernel API so that route changes are
atomically updated using change/replaces messages instead
of first sending a withdraw followed with update.
Same for zclient updates, changes are sent as single ADD
instead of DELETE + ADD.
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
Isolate the zebra static_XXX functions from zebra_rib.c
This is the first in a series of changes to clean up
the zebra code a bit more.
Signed-off-by: Donald Sharp <sharpd@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)
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)
Ticket: CM-8228
Signed-off-by: Donald Slice
Reviewed By:
Testing Done: Manual testing succesful. bgp-min and ospf-smoke successful. redistribute-neighbor-smoke
has the same failures as the base image.
Problem was due to considering imported /32 arp entries as elible next-hops for other routes
(in this case a static route.) This confuses the rib since this next-hop is considered both
recursive and onlink. Disallowed the use of this imported arp entry in next-hop determination.
This makes code more robust, consice and readable.
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
(cherry picked from commit be6335d682c5ee1b6930345193eda875705fbab2)
On higher warning levels, compilers expect %p printf arguments to be
void *. Since format string / argument warnings can be useful
otherwise, let's get rid of this noise by sprinkling casts to void *
over printf calls.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
MBGP routes are used only for PIM RPF checks and hence should
not be installed in the kernel's FIB. Ignore route node set to Multicast
SAFI.
Signed-off-by: Balaji.G <balajig81@gmail.com>
Acked-by: Everton Marques <everton.marques@gmail.com>
[pushed down rn->table->info assignment below assert]
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
(cherry picked from commit 9511633e08ff15c23608983fdc1bc735d427332e)
Conflicts:
zebra/zebra_rib.c
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 is a followup to 9511633 ("zebra: MBGP routes should not be
installed in the kernel"), which was correct in disabling MRIB routes
being installed in the kernel, yet broke the MRIB since now routes were
never marked as active.
Hence, push down the check into the kernel install functions, so that
the routes are still marked active. At the same time, the FPM calls get
a check each since otherwise we'd bump the FPM interface on MRIB
updates.
Fixes: 9511633 ("zebra: MBGP routes should not be installed in the kernel")
Cc: Everton Marques <everton.marques@gmail.com>
Cc: Balaji G <balajig81@gmail.com>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
With the MRIB being independent from the Unicast RIB, there's currently
now way to add static routes to the MRIB. Address that by adding a
separate set of commands for MRIB static routes.
Combines these original patches:
- zebra: mrib: ip mroute command to add unicast route to MRIB for multicast RPF.
- zebra: mrib: no ip mroute: Fix removal of static multicast RPF route.
- zebra: mrib: remove unused static_add/delete_ipv4
- zebra: Cleanups to zebra_rib.
- pimd: Merge pim-only branch.
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>
since the same code handles both URIB and MRIB, the debug messages can
get rather confusing if the RIB isn't identified. Mark the MRIB in
debug messages so we can distinguish that.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Introduces a logging function that takes a struct route_node * argument,
and prefixes log output with that node's prefix. While this removes
some duplication, it will also later be useful for srcdest route nodes.
Behaviour before and after the patch should be exactly identical.
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 the case of a route replace failing we
saw two issues with the logging:
1) The route replace was a debug instead of a warn
-> In this case change code to zlog_warn
2) The buf in the route replace was not being initialized
because buf initialization was protected by a debug check.
-> In this case move the buf initialization to inside
the failure case.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
Reviewed-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
This commit fixes interface based static routes.
static routes are now stored and if an interface
comes up it finds the route and installs it.
Ticket: CM-10869
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
On enable/disable of static routes add and remove them
from the rib as appropriate.
Ticket: CM-10139
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
The static zebra functions are passing around the vrf_id
At the crunchy edges gather the zvrf from passed in
vrf name and pass that around instead.
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
We were passing in the vrf_id pass in the zvrf
instead.
Signed-off-by: donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
Quagga does not have proper recovery for route install failure (in
the kernel). The lack of this may not be a significant issue if the
failure is only an exception. However, the introduction of route
replace presents a new failure scenario which was not there earlier.
Before replace, the update operation involved a delete followed by
add; the failure of add would not leave hanging route entries in the
kernel as they would've got deleted first. With route replace, if
the replace fails, recovery action to delete the route is needed, else
the route remains hanging in the kernel.
In particular, with VRFs and in the presence of ECMP/multipath, a
failure mode exists where Quagga thinks that routes have been cleaned
up and deleted from the kernel but the kernel continues to retain them.
This happens when multiple VRF interfaces are moved from one VRF to
another.
This patch addresses this scenario by implementing proper recovery for
route install failure.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Dinesh Dutt <ddutt@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-10361
Reviewed By: CCR-4566
Testing Done: bgp-min, ospf-min, bgp-smoke, ospf-smoke and manual
Note: There are some test failures and results aren't consistent across
runs; Daniel has resolved many of these through other fixes.
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-7789, CM-8806
If the route-map for an "ip import-table" denied a route it only flagged
the nexthop as inactive, it did not actually delete the route. This
breaks all directly connected EBGP peers that peer via IPv4 because NHT
finds this /32 with an inactive nexthop.
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>
Create the idea of a VRF_UNKNOWN, this is for a vrf where we don't
yet have the vrf_id for it yet.
Refactor the vrf_create code out of existence. We had two code
paths vrf_create and vrf_get. We should use vrf_get to create
the new vrf since XXX_get() creates the data structures now.
Signed-off-by: Donald Sharp
Reviewed-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
In the case of BGP unnumbered RFC 5549 (IPv4 routes with IPv6 nexthop), the
zebra code to handle routes was not initializing the correct VRF id and
locating the correct routing table, resulting in the routes not getting
installed. Fixed with this change.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-10247
Reviewed By: CCR-4429
Testing Done: Manual verification
When signalled to stop quagga, iterate through any "other_tables" that may have
been imported and close them all before stopping.
Ticket: CM-9386
Signed-off-by: Don Slice
Reviewed-by: Donald Sharp
Zebra code was not handling larger table-ids correctly. There were 2 issues:
a) In the netlink interface, RTA_TABLE was never sent or processed. This
pretty much limited the table-ids that zebra could understand to < 255.
b) In the interface into the zebra RIB (in particular for protocols), there
were some incorrect checks that again assumed the table id should be < 252
or be "main". This is valid only for the Default VRF (for now), for other
VRFs, the table-id should be the value learnt from the kernel.
These two issues are addressed with this change.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Ticket: CM-10087, CM-10091
Reviewed By: CCR-4359
Testing Done: Manual
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
NHT evaluation was not being triggered for any VRF after RIB processing. Fix
this and attempt to schedule only those VRFs for which RIB processing was
scheduled.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Ticket: CM-9175
Reviewed By: CCR-4149
Testing Done: Manual verification
zebra: add the creation of the alternative table for rdnbrd in the context of vrfs
When rdnbrd pulls arp entries into table 10, which are then sent into quagga via netlink, the entries were incorrectly being added to the main table. This fix creates or uses the alternative table if the table-id is not default but the vrf-id is default. Tested manually and also run successfully in the /tests/l3/ospf_ebgp_redist_comprehensive_test.py:TestBasicEndToEndPing , which consistently failed bafore this fix was applied.
Signed-off-by: Don Slice
Reviewed-by: Donald Sharp
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>
Currently, when RIB processing is initiated (i.e., by calling rib_update()),
all routes are queued for processing. This is not desirable in all situations
because, sometimes the protocol may have an alternate path. In addition,
with NHT tracking nexthops, there are situations when NHT should be kicked
off first and that can trigger subsequent RIB processing.
This patch addresses this by introducing the notion of a trigger event. This
is only for the situation when the entire RIB is walked. The current triggers
- based on when rib_update() is invoked - are "interface change" and "route-
map change". In the former case, only the relevant routes are walked and
scheduled, in the latter case, currently all routes are scheduled for
processing.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-7662
Reviewed By: CCR-3905
Note: The initial defect in this area was CM-7420. This was addressed in
2.5.4 with an interim change that only walked static routes upon interface
down. The change was considered a bit risky to do for interface up etc. Also,
this did not address scenarios like CM-7662. The current fix addresses CM-7662.
When static routes are added, they get processed and potentially installed
in the RIB once. Subsequently, NHT is invoked and ends up scheduling the
route for processing again because this is the first time the nexthop is
resolved for NHT. This used to result in a del-add earlier (as noted in
the defect), but is a replace now. This change eliminates the unnecessary
replace by ensuring NHT is invoked first if the static route has a nexthop
that will be tracked by NHT.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Dinesh Dutt <ddutt@cumulusnetworks.com>
Ticket: CM-4573
Reviewed By: CCR-3903
Testing Done: Manual and bgpsmoke
Note: Updates/improves static route NHT patch(es).
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>
When we get a static route through an interface convert the interface
name to an ifindex and pass it through to zebra_rib.c. zebra_rib.c
should not care about the ifname.
This code change will allow us to collapse some of the NEXTHOP_XXX types.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
