Issue: (*,G) mroute uptime is not updated in mroute table,
after deleting and adding the RP
Root cause: When RP gets deleted or becomes not reachable, then
we un-install the entry from the kernel, but still maintains the
entry in the stack. When RP gets re-configured or becomes reachable,
"show ip mroute" shows the uptime, when the channel_oil gets created.
Fix: Introduce a new time mroute_creation in the channel_oil, gets
updated when mroute gets installed in the kernel.
Signed-off-by: Sarita Patra <saritap@vmware.com>
In order to iterate over MPLS VPN routes, it's necessary to use
two nested loops (the outer loop iterates over the MPLS VPN RDs,
and the inner loop iterates over the VPN routes from that RD).
The bgp_table_stats_walker() function wasn't giving this special
treatment to the MPLS VPN safi as it should, which was leading to
crashes and malfunctioning. Fix this.
Signed-off-by: Renato Westphal <renatowestphal@gmail.com>
pinum (renamed from rinum) was never used for anything useful since
the initial revision ~17 years ago. Get rid of it.
Signed-off-by: Renato Westphal <renatowestphal@gmail.com>
When we delete an interface, we need to set the interface
ifindex to an internal value so that we don't end up in
a state where the re-addition of the same ifindex, due to
a rename operation, causes an infinite loop.
Fixes:#4007
Fix-Suggested-by: Saravanan K
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Clang's SA is reporting that we have a assignment without
subsuquent use. Modify the code such that we no-longer
do this.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
while labeled_unicast routes should be fetched in the
unicast table, we cannot set the safi to SAFI_UNICAST
else the peer afc checks and subgroup retrieval will fail
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
The rib process of handling routes has been unified a bit more
and as a result v6 LL routes are now showing up as a result
of a `redistribute connected`. Doing anything with these
routes is a policy decision that should be enforced by the
individual routing daemons not by zebra. As such add a bit
of code to isisd, ripngd and opsf6d to handle them. The bgp daemon
already handles this situation.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Routing protocols are allowed ( and even encouraged ) to modify
the flags that influence the nexthop tracking. As such when
we modify the tracking of a nexthop to go from, say, connected force
or not we must re-evaluate the nexthop and send the results
up to the interested parties.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
After we have evaluated the rnh for an import-check type
and we copy the re then we know that the state has changed
and we should be notifying the end user about it.
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>
Add a detailed debugging command for NHT tracking and add
the detailed output to the log about why we make some decisions
that we are. I tried to model this like the rib processing
detailed debugs that we added a few months back.
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>
Add a default route_node for our routing tables. This will allow us
to know that we can hang data off the default route for processing.
We will be hanging the nexthop tracking data structures off the rib_dest_t
so that we can know which nexthops we need to handle. Effectively
nexthops that we are tracking that are unresolved will be stored on the
default route. When something changes in the rib tree we can
work up the rn->parent pointer checking for nexthops we need to re-evaluate.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The resolved_route is the prefix we are using in the routing table
to resolve this particular nexthop we are tracking. Add code
to better track it's change.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The prn value as passed in may be NULL as such do not
allow it to be derefed (even though it works now).
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
We have several route types KERNEL and CONNECT that are handled via special
case in the code. This was causing a lot of work keeping the two different
classes of route types as special(SYSTEM OR NOT). Put the dplane
in charge of the code that sets the bits for signalling route install/failure.
This greatly simplifies the code calling path and makes all route types
be handled exactly the same. Additionaly code that we want to run
post data plane install can just work as per normal then, instead
of having to know we need to run it when we have a special type
of route.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com.
When we get a route install failure from the kernel, actually
indicate in the rib the status of the routes.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When switching routes from one route type to another actually
unset the old route as enqueued.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When shutting down, the individual vrf's own the shutdown of the table
and subsuquent removal from the routes from the kernel.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When shutting down and we have a very large table to shutdown
and after we've intentionally closed all the client connections
close the zebra zserv client socket.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When something goes wrong with this test, having these turned
on will help us debug zebra processing a bit better in the
future without having to modify anything else.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Don't delete the Alpine docker image after the build.
Also, extract the packages from the build stage, so that we can
remove them from the final image.
The interface column in pim was limited to 8 or 9 columns
all over the place in pim, fix the code up to allow interface
length to be up to 16 columns.
Ticket: CM-23083
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
