Move &rpki_cmd from VIEW to ENABLE. A non-enabled session could
enter into the rpki command node and exit into glocalb config mode
without having to enable.
Move &show_rpki* from ENABLE to VIEW. Allow non-enabled user to
view cache state and prefix table state.
Signed-off-by: David Teach <dteach@routeviews.org>
Adrian Ban [Tue, 2 Apr 2019 15:25:50 +0000 (17:25 +0200)]
staticd: Fix static routes that are not added in RIB after Null0 or vrf routes
When you add a static route like:
ip route 10.0.0.0/24 Null0
ip route 192.168.7.0/24 99.99.99.99 nexthop-vrf EVA
all routes after this command will be ignored by staticd and are not inserted in RIB.
This is the cause of return instead of continue in the for loop in static_nht_update_safi() function that is stopping the search in the routes list and is returning in the previous function without calling static_zebra_route_add() function.
Donald Sharp [Mon, 1 Apr 2019 16:31:28 +0000 (12:31 -0400)]
pimd: Limit lookup of neighbor since we know we have one
When a new pim neighbor comes up, we need to go through and
mark nexthops that we have received from zebra for reachability
tracking so we can refigure stuff. If we pass in the new neighbor
we can limit the search to those nexthops out the interface that
the new neighbor has come up.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
pimd: Introduce mroute_creation in channel oil data structure
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.
Renato Westphal [Sat, 30 Mar 2019 03:53:16 +0000 (00:53 -0300)]
bgpd: fix "show bgp statistics" for the VPN safi
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.
Donald Sharp [Fri, 29 Mar 2019 02:08:37 +0000 (22:08 -0400)]
bfdd, nhrpd, pimd: When deleting an interface clean up
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>
Donald Sharp [Thu, 28 Mar 2019 19:44:58 +0000 (15:44 -0400)]
pimd: Cleanup extra paranthesis around S,G printout
When we are displaying S,G string data we already auto
display the string as (S,G) no need to have ((S,G)).
Cleanup some that were found during log look through.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Thu, 28 Mar 2019 19:26:06 +0000 (15:26 -0400)]
pimd: Reduce RP checks a bit
The pim_rp_check_is_my_ip_address function was checking to see
if we were the actual RP as well as the pim_register code
was doing the same thing. Remove the reduncancy a bit and
just make this function check for that we are the actual receiver
of this data.
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>
Donald Sharp [Thu, 28 Mar 2019 14:27:57 +0000 (10:27 -0400)]
pimd: No need to rescan upstream list on rpf change
The code as written will scan the entirety of all pim upstreams
on a rpf change, this is not necessary because we know that when
we get a nexthop change we already scan the upstreams reliant
on that and do this work. There is no need to do this again a
short time later.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Fri, 22 Feb 2019 15:20:51 +0000 (10:20 -0500)]
isisd, ospf6d, ripngd: Do not allow v6 LL's to be `redist connected` in
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>
Donald Sharp [Thu, 21 Feb 2019 21:10:56 +0000 (16:10 -0500)]
zebra: Re-evaluate the nexthop tracking if flags changed
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>
Donald Sharp [Tue, 12 Feb 2019 14:51:08 +0000 (09:51 -0500)]
zebra: If we copy re than the state has changed
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>
Donald Sharp [Fri, 8 Feb 2019 22:14:30 +0000 (17:14 -0500)]
zebra: Modify lsp processing to be invoked as needed
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>
Donald Sharp [Fri, 8 Feb 2019 14:11:47 +0000 (09:11 -0500)]
zebra: Add detailed debugging command for NHT tracking
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>
Donald Sharp [Wed, 6 Feb 2019 15:23:58 +0000 (10:23 -0500)]
zebra: Modify NHT to occur when needed.
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>
Donald Sharp [Wed, 6 Feb 2019 19:44:44 +0000 (14:44 -0500)]
zebra: Add a base node for the zebra vrf tables
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>
Donald Sharp [Wed, 6 Feb 2019 16:16:07 +0000 (11:16 -0500)]
zebra: Set and track the resolved_route for the rnh as it changes.
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>
Donald Sharp [Fri, 8 Feb 2019 20:01:41 +0000 (15:01 -0500)]
zebra: Modify code so that dplane is responsible for indicating success/fail of install
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.
Donald Sharp [Sat, 9 Feb 2019 21:38:34 +0000 (16:38 -0500)]
zebra: When shutting down actually close the socket
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>
Donald Sharp [Sat, 9 Feb 2019 16:09:32 +0000 (11:09 -0500)]
topotests: Add a bit more useful debugging to ldp-vpls-topo1
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>
Tuetuopay [Wed, 27 Mar 2019 01:13:16 +0000 (02:13 +0100)]
zebra: Change checks for EVPN VRF to a macro
A lot of checks relied on the VRF ID and the EVPN VRF ID to be the same.
This patch changes those checks to the EVPN_ENABLED macro, which checks
if the VRF is the EVPN one.
Christian Franke [Tue, 26 Mar 2019 13:56:59 +0000 (14:56 +0100)]
alpine/APKBUILD.in: Add libyang-dev dependency, drop binutils-libs
We need libyang to build FRR, so add it to the make dependencies.
Alpine will automatically detect it as runtime dependency, so no
need to add it there.
The package binutils-libs doesn't exist anymore, so remove it from
the dependencies.
Nitin Soni [Tue, 12 Mar 2019 05:57:51 +0000 (22:57 -0700)]
bgpd: handle all afi safi while bgp clear soft
Currently, as part of bgp clear soft inboud and outbound we don't handle
l2vpn evpn. Now clearing soft for all supported afi safi.
One of the examples where this was a problem -
On applying graceful-shutdown, bgp clear soft inboud and outbound don't
handle AFI L2VPN and SAFI EVPN. Gshut gets applied to EVPN Type 5 routes
by asking peer to refresh the routes (provided we have config - "advertise
ipv4/ipv6 unicast" as part of l2vpn evpn) but is not applied to type 2
and type 3 EVP routes. This fix takes care of l2vpn evpn type2 and type3
routes being readvertised with gshut community.
This fix also fixes similar issues related to following where bgp clear
soft is requred for l2vpn evpn -
-config bgp cluster-id
-config bgp client-to-client reflection
-config bgp default local-preference
-config bgp route-reflector allow-outbound-policy
-config bgp disable-ebgp-connected-route-check
Ticket: CM-22813 Signed-off-by: Nitin Soni <nsoni@cumulusnetworks.com> Reviewed-by: CCR-8361
Testing-Done:
-With gshut configured on all BGP VRFs (operator has to know about the
auto-created BGP VRFs - we do show them in show commands - and turn on
graceful-shutdown in all of them.
-We announce all EVPN routes (type-2, type-3 and type-5) with GSHUT and
we mark IPv4/IPv6 routes in a VRF that are based on received EVPN type-2
or type-5 routes with local pref 0.
-On the receiver side, when EVPN routes are received with GSHUT, the
correct handling takes place (to treat them with local preference 0, and
hence not select them)
-When the gshut configuration is removed on all BGP VRFs, we re-announce
all of our EVPN routes without GSHUT and receiver does the appropriate
thing. Also, we no longer mark EVPN-based IPv4/IPv6 routes with local
pref 0.
-evpn-smoke
-bgp-smoke
projects / mirror_frr.git / log