The `struct rib_dest_t` was being used to store the linked
list of rnh's associated with the node. This was taking up
a bunch of memory. Replace with new data structure supplied
by David and see the memory reductions associated with 1 million
routes in the zebra rib:
Old:
Memory statistics for zebra:
System allocator statistics:
Total heap allocated: 675 MiB
Holding block headers: 0 bytes
Used small blocks: 0 bytes
Used ordinary blocks: 567 MiB
Free small blocks: 39 MiB
Free ordinary blocks: 69 MiB
Ordinary blocks: 0
Small blocks: 0
Holding blocks: 0
New:
Memory statistics for zebra:
System allocator statistics:
Total heap allocated: 574 MiB
Holding block headers: 0 bytes
Used small blocks: 0 bytes
Used ordinary blocks: 536 MiB
Free small blocks: 33 MiB
Free ordinary blocks: 4600 KiB
Ordinary blocks: 0
Small blocks: 0
Holding blocks: 0
`struct rnh` was moved to rib.h because of the tangled web
of structure dependancies. This data structure is used
in numerous places so it should be ok for the moment.
Future work might be needed to do a better job of splitting
up data structures and function definitions.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
LSP processing was a zvrf flag based upon a connected route
coming or going. But this did not allow us to know
that we should do lsp processing other than after the meta-queue
processing was finished.
Eventually we moved meta-queue processing of do_nht_processing
to after the dataplane sent the main pthread some results.
This of course left us with a timing hole where if a connected
route came in and we received a data plane response *before*
the meta queue was processed we would not do the work as necessary.
Move the lsp processing to a flag off of the rib_dest_t. If it
is marked then we need to process lsps.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Currently nexthop tracking is performed for all nexthops that
are being tracked after a group of contexts are passed back
from the data plane for post install processing.
This is inefficient and leaves us sending nexthop tracking
changes at an accelerated pace, when we think we've changed
a route. Additionally every route change will cause us
to relook at all nexthops we are tracking irrelevant if
they are possibly related to the route change or not.
Let's modify the code base to track the rnh's off of the rib
table's rn, `rib_dest_t`. So after we process a node, install
it into the data plane, in rib_process_result we can
look at the `rib_dest_t` associated with the rn and see that
a nexthop depended on this route node. If so, refigure it.
Additionally we will store rnh's that are not resolved on the
0.0.0.0/0 nexthop tracking list. As such when a route node
changes we can quickly walk up the rib tree and notice that
it needs to be reprocessed as well.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Modify the status flag from 8 bits to 32 bits and to add
a few new flags that will be used in future commits.
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>
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>
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>
* 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>
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>
Add 'const' to prefix args to several zebra route update,
redistribution, and route owner notification apis.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
The linux kernel is getting the same Route Replace semantics
for v6 that v4 uses. Allow the end-user to know if their
kernel has this ability and if so to specify it so zebra
can take advantage of this.
Why not do auto-detection? Because you would have to write
code in zebra to add a route then add the same route again
with different nexthops to see if which semantics it is using.
It sure is easier to just add a cli that allows the user to
do it.
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>
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>
Add to the function prototypes the names of variables
to hopefully make it easier for people to program against
this header.
Signed-off-by: Donald Sharp<sharpd@cumulusnetworks.com>
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>
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>
When zebra is being configed we allow for static routes
to be entered. This presents a problem for when a vrf
is cli configed but not kernel configed yet.
Modify zebra to notice that when a static route is
entered and either the nexthop vrf or the vrf
is not fully configed, to save that config to the
side.
When vrf's become active( kernel configed ) parse
through the list of saved to the side static routes
and determine if any of them can be installed.
Additionally modify the cli to output the saved
to the side cli, so that we can properly handle
a wr mem.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Move the code that generates the 'show run' output for
'ip route' to be controlled by the vrf config generation
code. Since it really belongs there.
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>
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>
zserv.c had a grab bag of function declarations that
did not belong in it. Move those to where they better
belong.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
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>
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>
This reference counter was introduced in 2001, apparently to solve a
problem with connected routes being added/removed multiple times. The RIB
code changed a lot since then, and giving the current callers of rib_add()
and rib_delete() it's safe to assume that we don't need this anymore.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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
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>
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)
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>
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>
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>
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>
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
This patch reorganizes the RA handling to be per namespace rather than per
VRF. The VRF library by 6wind had done the original change to make the RA
data structures (socket information) per VRF, but this was correct only if
each VRF represented a NS. In our reorganization, we have created a NS
structure (struct zebra_ns) and VRFs don't correspond to namespaces (i.e.,
all VRFs exist in the default namespace). So, the RA handling should be
done under 'struct zebra_ns'.
With the changes, there is a single raw socket per NS (=> 1 for us) on which
we will receive and handle RAs for all interfaces. The interface information
is available through cmsg and the processing will then happen for that interface.
There is a problem with transmitting RAs over a VRF interface. This is
tracked by CM-9398.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-9206
Reviewed By: CCR-4217
Testing Done: Manual testing
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>
This commit adds the 'struct zebra_ns' data structure.
We are not currently using it. But pretty much
everything after this commit in zebra depends on it.
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.
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>
