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.
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
Donald Sharp [Tue, 26 Mar 2019 13:11:28 +0000 (09:11 -0400)]
bgpd: Split up warn message to allow finer grained understanding
We have the same warn message in 3 spots, which makes it extremely
hard to figure out which of the 3 has gone terribly wrong.
Add a bit of code to disambiguate the 3 situations.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Christian Franke [Tue, 26 Mar 2019 09:28:09 +0000 (10:28 +0100)]
tools/frr.in: Only attempt to load daemons.conf if present
Apparently, the default changed to use `/etc/frr/daemons` instead of
`/etc/frr/daemons.conf`. Therefore, we should ignore absence of the
latter file, because its absence is not an actuall error but will
cause a confusing error message like this:
/etc/init.d/frr: line 507: /etc/frr/daemons.conf: No such file or directory
Stephen Worley [Tue, 26 Mar 2019 05:03:06 +0000 (01:03 -0400)]
zebra: Fix extended ack error message parsing
Fix the macros for reading NLA attribute info
from an extended error ack. We were processing the data
using route attributes (rtattr) which is identical in size
to nlattr but probably should not be used.
Further, we were incorrectly calculating the length of the
inner netlink message that cause the error. We have to read
passed that in order to access all the nlattr's.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Chirag Shah [Fri, 22 Mar 2019 17:02:07 +0000 (10:02 -0700)]
zebra: evpn dup detect handle ip state change
For a MAC-IP pair generally local/netlink msg for
MAC is received followed by Neigh. The MAC can be detected as duplicate
during this event.
When a neigh update is received, the neigh inherits DUP flag from its
MAC and along with that mark the neigh as INACTIVE.
Also, In the case of DUP detected neigh, do not update its state
to ACTIVE before determining to send notification to bgpd.
There is a time when Neigh update received prior to MAC update.
In that case neigh is marked as inactive since its MAC is
still in REMOTE state. Once the MAC update is received and
it is detected as DUPLICATE, the neigh would inherit DUP flag
but remained in inactive state.
By fixing the first case, the neigh remains in inactive once
detected as DUPLICATE in both scenarios.
The unfreeze action would mark all inherited neighs to ACTIVE,
and clears DUP flag then sends notification to bgpd (to send type-2).
Ticket:CM-24339
Reviewed By:CCR-8451
Testing Done:
Validated dup detection on both environment where neigh and mac
notification can come as either one first.
With the fix, the neigh was remained in "inactive" state
once detected as duplicate.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
Quentin Young [Mon, 25 Mar 2019 20:11:47 +0000 (20:11 +0000)]
doc: update build docs for Ubuntu 18.04
* Update build package list
* Update ./configure options
* Fix some RST syntax errors
* Use monolithic config examples
* Use compile include snippet
* Reorganize a bit
Tested on Ubuntu 18.04
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Mark Stapp [Mon, 25 Mar 2019 17:35:02 +0000 (13:35 -0400)]
zebra: use the INSTALLED flag consistently in route summary
The 'sho ip route summary' and 'sho ip route summary <prefix>'
paths used different definitions of a 'fib' route. Use
the route-entry 'INSTALLED' flag in both places.
Don Slice [Mon, 25 Mar 2019 15:00:02 +0000 (15:00 +0000)]
lib: zclient provide interface info during reg_requests
Problem found in bgpd where it wasn't learning interface address
information at startup due to the interface information becoming
available before the bgp instance was created. This issue was
caused by an earlier change that tried to make the interface
information discovery process more efficient but left this hole
for bgpd. For now, putting back in the previous method of
gathering interface info via the zclient_send_reg_requests call
and will revisit a more efficient way to get the info in the future.
Ticket: CM-23932 Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
projects / mirror / frr.git / log