Donald Sharp [Tue, 29 Sep 2020 11:54:35 +0000 (07:54 -0400)]
zebra: Make nexthop_active check use the same debug
When debugging why a route was not successfully installed into the
rib, it would be preferable that the end user only have to turn
on `debug zebra rib detail` as that is what we have been telling
people to do for the last couple of years. Consolidate *back*
to this.
Chirag Shah [Sun, 27 Sep 2020 21:09:43 +0000 (14:09 -0700)]
zebra: avoid duplication node in l3vni l2vni-list
With l2vni flap leading to duplicate entry creation
in l3vni's l2vni-list.
Use list sorted add with no duplicates.
root@TORC11:mgmt:~# show evpn vni 4001
VNI: 4001
Type: L3
Tenant VRF: vrf1
State: Up
...
L2 VNIs: 1000 1000 1000 0 0 1002
root@TORC11:mgmt:~# ip link set down vx-1002
root@TORC11:mgmt:~# ip link set up vx-1002
root@TORC11:mgmt:~# show evpn vni 4001
VNI: 4001
Type: L3
Tenant VRF: vrf1
State: Up
...
L2 VNIs: 1000 1000 1000 0 0 1002 1002
Ticket:CM-31545
Reviewed By:
Testing Done:
With Fix:
Multiple time flaps vni counts remained the same.
root@TORC11:mgmt:~# ip link set down vx-1002
root@TORC11:mgmt:~# ip link set up vx-1002
root@TORC11:mgmt:~# ip link set down vx-1002
root@TORC11:mgmt:~# ip link set up vx-1002
root@TORC11:mgmt:~# net show evpn vni 4001
VNI: 4001
Type: L3
Tenant VRF: vrf1
State: Up
...
L2 VNIs: 1000 1002
bfdd: Make new multihop peer if local-address is unique
Previously if there were two multihop peers created that had the same
peer address but different local addresses then the second peer to be
created would be merged with the first one and niether would be able to
be deleted. This was due to an issue in the function bfd_key_lookup().
When the second peer was created its key would be sent into the lookup
function and would reach the last section, even though it shouldn't
have. A check has been placed around the section so that it will not be
entered if a peer is multihop.
Stephen Worley [Mon, 28 Sep 2020 16:39:22 +0000 (12:39 -0400)]
zebra: set NHG/backup NHG pointers on success zapi read
Only set the NHG/backup NHG pointers of the caller if the read
of the nexthops was successfull. Otherwise, we might free when not
neccessary or double free.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Stephen Worley [Fri, 25 Sep 2020 17:48:21 +0000 (13:48 -0400)]
lib,zebra,sharpd: add code for backup proto-NHs but disabled
Add the zapi code for encoding/decoding of backup nexthops for when
we are ready for it, but disable it for now so that we revert
to the old way with them.
When zebra gets a proto-NHG with a backup in it, we early fail and
tell the upper level proto. In this case sharpd. Sharpd then reverts
to the old way of installation with the route.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Stephen Worley [Thu, 3 Sep 2020 17:04:10 +0000 (13:04 -0400)]
zebra: limit no re-install to NHG PROTO using routes
Limit the not re-installation of routes with the same NHG ID
to routes that are using the new NHG PROTO API. This would
only include sharpd and EVPN-MH for now.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Stephen Worley [Tue, 1 Sep 2020 20:02:12 +0000 (16:02 -0400)]
lib: add doc to clear-up hash_iterate multi deletion
Add some header documentation to make it clear that you
cannot delete more than one item during each iteration.
Doing so could cause memory corruption for next pointer
if its also deleted from the table.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Stephen Worley [Tue, 1 Sep 2020 18:53:09 +0000 (14:53 -0400)]
zebra: use list to mark for removal when scoring
In scoring our NHEs during shutdown there is a chance we could release mutliple
NHEs at the same time during one iteration. This can cause memory corruption
if the two being released are directly next to each other in the hash table.
hash_iterate accounts for releasing one during the iteration but not
two by setting hbnext before release but if hbnext is also freed,
we obviously can have a problem.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Stephen Worley [Mon, 3 Aug 2020 18:34:52 +0000 (14:34 -0400)]
zebra: reject proto NHGs of blackhole/interface
Reject proto NHGs of type blackhole/interface for now.
We need to think a bit more about how to resolve these
given the linux kernel needs to know the Address Family
of the routes that will use them and install it with them.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Stephen Worley [Wed, 22 Jul 2020 17:45:47 +0000 (13:45 -0400)]
zebra: add flag track released state of proto NHGS
Add a flag to track the released state of a proto-based NHG.
This flag is used to know whether the upper level proto has called
the *_del API. Typically, the NHG would just get removed and uninstalled
at this point but there is a chance we are being sent it while routes
are still being owned or we were sent it multiple times. This flag
and associated code handles that.
Ticket: CM-30369
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Stephen Worley [Thu, 11 Jun 2020 17:49:25 +0000 (13:49 -0400)]
sharpd: implement NHG notification handling
Implement handling of NHG notifications in sharpd so that
the routes don't attempt to use an NHG ID that did not
successfully get created. If it does not get installed, we
fall back to traditional zapi messaging.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Stephen Worley [Thu, 11 Jun 2020 17:46:48 +0000 (13:46 -0400)]
zebra: reply fail on NHG add if not ifindex/onlink
We currently don't support ADD/DEL/REPLACE with proto-based
NHGs that are not already fully resolved and ifindex/onlink
based. If we are handed one that doesn't have ifindex set
i.e. recursive, gracefully fail and with a notification.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Donald Sharp [Thu, 11 Jun 2020 11:34:18 +0000 (07:34 -0400)]
zebra: Only install a minimal amount of times
The code was installing the nexthop group again using
the NLM_F_REPLACE function causing extremely large
route installation times. This reduces the time from
installing 1 million routes from sharpd with a nhg
from > 200 seconds ( where I gave up ) to ~15
seconds on my machine for 32 x ecmp. As a side note 1 million
routes using master sharpd takes ~50 seconds to do
the same thing.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Stephen Worley [Thu, 28 May 2020 17:22:18 +0000 (13:22 -0400)]
zebra: add logging for NHG ignoring in netlink
Add some logging for when we choose to ignore a NHG install
for one reason or another. Also, cleanup some of the code
using the same accessor functions for the context object.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Stephen Worley [Wed, 27 May 2020 21:39:41 +0000 (17:39 -0400)]
lib,sharpd,pbrd: `set installable` nhg command
Add a command `set installable` that allows configured nexthop
groups to be treated as separate/installable objects in the RIB.
A callback needs to be implemented per daemon to handle installing
the NHG into the rib via zapi when this command is set. This
patch includes the implementation for sharpd.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Stephen Worley [Sun, 24 May 2020 20:03:01 +0000 (16:03 -0400)]
zebra: fix releasing proto-owned singletons
Fix the releasing of proto-owned singletons from the attribute
hashed table. Proto-owned singleton nexthops are hashed so they
can still be shared therefore they are present in this table
and need to be released when the time comes.
This check was only matching on zebra proto before. Changed
to match IDs in zebra allocated range.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Stephen Worley [Wed, 20 May 2020 15:26:44 +0000 (11:26 -0400)]
zebra: inc/dec refcount on add/del NHG proto
When we add a proto NHG, increment the refcount, when
we del a proto NHG, decrement the refcount rather than
deleting it explicitly. If the upper level proto is handling
it properly, it should get decremented to zero when we
receive a NHG del.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Stephen Worley [Mon, 18 May 2020 18:22:06 +0000 (14:22 -0400)]
lib: add onlink flag to zapi_nh conversion helper
Add setting the onlink flag to the zapi_nh conversion
helper function so that we can set the onlink flag with
it when passing down NHGs from upper level protos.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Stephen Worley [Wed, 13 May 2020 21:42:55 +0000 (17:42 -0400)]
zebra: make NHG ID allocation smarter
Make NHG ID allocation smarter so it wraps once it hits
the lower bound for protos and performs a lookup to make
sure we don't already have that ID in use.
Its pretty unlikely we would wrap since the ID space is somewhere
around 24million for Zebra at this point in time.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Stephen Worley [Wed, 13 May 2020 18:32:13 +0000 (14:32 -0400)]
zebra: NHG ID bounds macros
Determine the NHG ID spacing and lower bound with ZEBRA_ROUTE_MAX
in macros.
Directly set the upperbound to be the lower 28bits of the uint32_t ID
space (the top 4 are reserved for l2-NHGs). Round that number down
a bit to make it more even.
Convert all former lower_bound calls to just use the macro.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Stephen Worley [Sun, 10 May 2020 20:36:49 +0000 (16:36 -0400)]
zebra: implement NHG proto replace
Implement the ability to replace an NHG sent down
from an upper level proto. With proto-owned NHGs, we make the
assumption they are ecmp and always treat them as a group
to make the replace from 1 -> 2 and 2 -> 1 quite a bit
easier.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Stephen Worley [Wed, 13 May 2020 19:50:14 +0000 (12:50 -0700)]
zebra,lib: command to only install proto-based nexthops
Add a command/functionality to only install proto-based nexthops.
That is nexthops owned/created by upper level protocols, not ones
implicitly created by zebra.
There are some scenarios where you would not want zebra to be
arbitrarily installing nexthop groups and but you still want
to use ones you have control over via lib/nexthop_group config
and an upper level protocol.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Stephen Worley [Thu, 30 Apr 2020 22:35:13 +0000 (18:35 -0400)]
zebra: remove NHG unhashable flag and its code
Remove the code for setting a NHG as unhashable. Originally
this was to prevent us from attempting to put duplicates from
the kernel in our hashtable.
Now I think its better to not use them in the hashtable at all
and only track them in the ID table. Routes will still be able
to use them if they specify the ID explicitly when sending Zebra
the route, but 'normal' routes we hash the nexthop group on
will not.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
projects / mirror / frr.git / log