matthieu/frr
1
0
Fork 0
forked from Mirror/frr
Code Pull requests Activity
23231 commits 81 branches 196 tags 202 MiB
Commit graph

222 commits

Author SHA1 Message Date
Stephen Worley 0a7edab036
Merge pull request #7993 from mjstapp/reorg_resolve 
zebra: reorg nexthop resolution code
 2021-03-16 11:34:33 -04:00
Philippe Guibert ef524230a6 zebra: move ipset and ipset_entry to zebra dplane contexts 
like it has been done for iptable contexts, a zebra dplane context is
created for each ipset/ipset entry event. The zebra_dplane_ctx job is
then enqueued and processed by separate thread. Like it has been done
for zebra_pbr_iptable context, the ipset and ipset entry contexts are
encapsulated into an union of structures in zebra_dplane_ctx.

There is a specificity in that when storing ipset_entry structure, there
was a backpointer pointer to the ipset structure that is necessary
to get some complementary information before calling the hook. The
proposal is to use an ipset_entry_info structure next to the ipset_entry,
in the zebra_dplane context. That information is used for ipset_entry
processing. The ipset name and the ipset type are the only fields
 necessary.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
 2021-03-10 14:57:32 +01:00
Philippe Guibert 5162e00045 zebra: move iptable handling in zebra_dplane 
The iptable processing was not handled in remote dataplane, and was
directly processed by the thread in charge of zapi calls. Now that call
can be handled in the zebra_dplane separate thread. once a
zebra_dplane_ctx is allocated for iptable handling, the hook call is
performed later. Subsequently, a return code may be triggered to zclient
interface if any problem occurs when calling the hook call.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
 2021-03-04 11:50:25 +01:00
Mark Stapp 9b4ab90984 zebra: support nh resolution without a route 
Start reorg of zebra nexthop-resolution so that we can use the
resolution logic for nexthop-groups as well as routes. Change
the signature of the core nexthop_active() api so that it does
not require a route-entry or route-node. Move some of the logic
around so that nexthop-specific logic is in nexthop_active(),
while route-oriented logic is in nexthop_active_check().

Signed-off-by: Mark Stapp <mjs@voltanet.io>
 2021-02-19 15:38:37 -05:00
Stephen Worley 3d30f6defb zebra: disallow resolution to duplicate nexthops 
Disallow the resolution to nexthops that are marked duplicate.
When we are resolving to an ecmp group, it's possible this
group has duplicates.

I found this when I hit a bug where we can have groups resolving
to each other and cause the resolved->next->next pointer to increase
exponentially. Sufficiently large ecmp and zebra will grind to a hault.

Like so:

```
D>  4.4.4.14/32 [150/0] via 1.1.1.1 (recursive), weight 1, 00:00:02
  *                       via 1.1.1.1, dummy1 onlink, weight 1, 00:00:02
                        via 4.4.4.1 (recursive), weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                        via 4.4.4.2 (recursive), weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                        via 4.4.4.3 (recursive), weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                        via 4.4.4.4 (recursive), weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                        via 4.4.4.5 (recursive), weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                        via 4.4.4.6 (recursive), weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                        via 4.4.4.7 (recursive), weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                        via 4.4.4.8 (recursive), weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                        via 4.4.4.9 (recursive), weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                        via 4.4.4.10 (recursive), weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                        via 4.4.4.11 (recursive), weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                        via 4.4.4.12 (recursive), weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                        via 4.4.4.13 (recursive), weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                        via 4.4.4.15 (recursive), weight 1, 00:00:02
                          via 1.1.1.1, dummy1 onlink, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1 onlink, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                        via 4.4.4.16 (recursive), weight 1, 00:00:02
                          via 1.1.1.1, dummy1 onlink, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
D>  4.4.4.15/32 [150/0] via 1.1.1.1 (recursive), weight 1, 00:00:09
  *                       via 1.1.1.1, dummy1 onlink, weight 1, 00:00:09
                        via 4.4.4.1 (recursive), weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                        via 4.4.4.2 (recursive), weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                        via 4.4.4.3 (recursive), weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                        via 4.4.4.4 (recursive), weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                        via 4.4.4.5 (recursive), weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                        via 4.4.4.6 (recursive), weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                        via 4.4.4.7 (recursive), weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                        via 4.4.4.8 (recursive), weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                        via 4.4.4.9 (recursive), weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                        via 4.4.4.10 (recursive), weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                        via 4.4.4.11 (recursive), weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                        via 4.4.4.12 (recursive), weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                        via 4.4.4.13 (recursive), weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                        via 4.4.4.14 (recursive), weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                        via 4.4.4.16 (recursive), weight 1, 00:00:09
                          via 1.1.1.1, dummy1 onlink, weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
D>  4.4.4.16/32 [150/0] via 1.1.1.1 (recursive), weight 1, 00:00:19
  *                       via 1.1.1.1, dummy1 onlink, weight 1, 00:00:19
                        via 4.4.4.1 (recursive), weight 1, 00:00:19
                          via 1.1.1.1, dummy1, weight 1, 00:00:19
                        via 4.4.4.2 (recursive), weight 1, 00:00:19

...............
................

and on...

```

You can repro the above via:

```
kernel routes:

1.1.1.1 dev dummy1 scope link

4.4.4.0/24 via 1.1.1.1 dev dummy1

==============================

config:

nexthop-group doof
 nexthop 1.1.1.1
 nexthop 4.4.4.1
 nexthop 4.4.4.10
 nexthop 4.4.4.11
 nexthop 4.4.4.12
 nexthop 4.4.4.13
 nexthop 4.4.4.14
 nexthop 4.4.4.15
 nexthop 4.4.4.16
 nexthop 4.4.4.2
 nexthop 4.4.4.3
 nexthop 4.4.4.4
 nexthop 4.4.4.5
 nexthop 4.4.4.6
 nexthop 4.4.4.7
 nexthop 4.4.4.8
 nexthop 4.4.4.9
!

===========================

Then use sharpd to install 4.4.4.16 -> 4.4.4.1 pointing to that nexthop
group in decending order.
```

With these changes it prevents the growing ecmp above by disallowing
duplicates to be in the resolution decision. These nexthops are not
installed anyways so why should we be resolving to them?

Signed-off-by: Stephen Worley <sworley@nvidia.com>
 2021-02-01 13:02:40 -05:00
Mark Stapp ee94437e28 zebra: send async nhg update results 
Send the results of daemons' nhg updates asynchronously,
after the update has actually completed. Capture additional
info about the source daemon in order to locate the correct
zapi session. Simplify the result types considered by the
zebra_nhg module.

Signed-off-by: Mark Stapp <mjs@voltanet.io>
 2021-01-22 16:33:01 -05:00
Mark Stapp f5b7e50f9a zebra: use afi_t for route-map address family arg 
Use afi_t in the route_map_check api

Signed-off-by: Mark Stapp <mjs@voltanet.io>
 2021-01-21 10:13:57 -05:00
Donald Sharp 7e010c4b78 zebra: notify installing protocol when nexthops cannot be resolved 
In the case where a routes nexthops cannot be resolved as part
of route processing, immmediately notify the upper level protocol
that their routes failed to install if they are interested in
being informed about this issue.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
 2021-01-11 10:11:35 -05:00
Stephen Worley 306720345a zebra: make a couple NHG errors debugs 
A couple NHG messages we were logging as errors are a bit spammy
in usecases where you routinely add/remove interfaces (VM heavy
deployments). Its not really an error a user cares about and
more for a developer to know what went wrong after the fact so
it makes more sense for these to be under a debug rather than
an error since seeing them does not implicitly mean error during
those usecases.

Signed-off-by: Stephen Worley <sworley@nvidia.com>
 2020-12-01 12:04:30 -05:00
Anuradha Karuppiah c60522f702 zebra: dplane APIs for programming evpn-mh access port attributes 
This includes -
1. non-DF block filter
2. List of es-peers that need to be blocked per-access port (for
split horizon filtering)
3. Backup nexthop group to failover local-es via the VxLAN overlay

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
 2020-10-26 10:32:51 -07:00
Mark Stapp 874e77acce
Merge pull request #7374 from sworleys/Revert-Revert-NHG-Dependents 
zebra: Fix the NHG dependents relationship
 2020-10-24 16:49:09 -04:00
Stephen Worley 7fa239f165 zebra: disable dependent backpointers for backup nexthops 
Because the backup nexthop groups currently are more like pseudo-NHEs
(they don't have IDs and are not inserted into the ID table or
hashed), they can't really have this depends/dependents relationship
yet in both directions. Some work needs to be done there to make
them more like first class citizens like "normal" NHGs to enable
this.

Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
 2020-10-22 18:10:44 -04:00
Stephen Worley 8459128259 Revert "Revert "zebra: fix NHE dependents backpointer relationship"" 
This reverts commit a682deea0f.
 2020-10-22 18:09:44 -04:00
Donald Sharp b1b07ef5a6 zebra: Do not delete nhg's when retain_mode is engaged 
When `-r` is specified to zebra, on shutdown we should
not remove any routes from the fib.  This was a problem
with nhg's on shutdown due to their ref-count behavior.

Introduce a methodology where on shutdown we don't mess
with the nexthop groups in the kernel.  That way on
next startup things will be ok.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
 2020-10-22 08:02:33 -04:00
Stephen Worley a682deea0f Revert "zebra: fix NHE dependents backpointer relationship" 
This reverts commit f9f9466e04.
 2020-10-20 17:11:35 -04:00
Stephen Worley f9f9466e04 zebra: fix NHE dependents backpointer relationship 
Apparantly the dependents backpointer trees for singletons
got broken at some point and we never noticed. There is
not really any code making use of this right now so not
suprising but let's go ahead and fix it for zebra and proto
NHGs.

Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
 2020-10-19 12:52:39 -04:00
Stephen Worley 475852b263 zebra: only track NHEs from the dataplane for ID usage 
Let's just track the NHEs we get from the kernel(dplane) for
ID usage with internal routes. I tried to be smart originally
and allow them to be re-used internal to zebra but its proving
to cause more bugs than it's worth.

This doesn't break any functionality. It just means we won't
use NHEs we get from the kernel with our routes, we will create
new ones.

Decided this based on various bugs seen ith the lastest one
being on startup with this kernel state:

```
[root@alfred frr-2]# ip next ls
id 15 via 192.168.161.1 dev doof scope link proto zebra
id 17 group 15 proto zebra
[root@alfred frr-2]# ip ro show 3.3.3.1
3.3.3.1 nhid 17 via 192.168.161.1 dev doof
```

Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
 2020-10-13 11:23:57 -04:00
Stephen Worley 5588801e7a zebra: add from_dplane info for NHE creation 
Add a param to the common NHE creation callstack so we can
know if this is one we have read in from the dataplane. We can
add some logic on how to handle these special ones later.

I considered putting this on a struct as a flag or something
but it would have required it being put on struct nexthop
since we have some `*_find_nexthop()` functions that can
be called when given NHEs from the dataplane.

Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
 2020-10-12 20:39:28 -04:00
Donald Sharp a24d04f4db 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.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
 2020-09-29 07:54:35 -04:00
Donald Sharp 81194feec9 zebra: Add missing reason we could not make an active_nexthop check 
Add a missing reason as to why we are unable to make an active nexthop
check be successful.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
 2020-09-29 07:45:19 -04:00
Stephen Worley 2173535298 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>
 2020-09-28 12:41:00 -04:00
Stephen Worley aaa42e056f zebra: add type to nhg_prot_del API for sanity check 
Add type to the nhg_proto_del API params for sanity checking
that the types of the route sent by the proto matches the type
found with the ID.

Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
 2020-09-28 12:41:00 -04:00
Stephen Worley 8f830b8c64 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>
 2020-09-28 12:41:00 -04:00
Stephen Worley 70f3cda6c1 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>
 2020-09-28 12:41:00 -04:00
Stephen Worley 73937edb73 zebra,sharpd: checkpatch fixes 
Check patches fixes for NHG API pathes.

Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
 2020-09-28 12:41:00 -04:00
Stephen Worley 8155e8c592 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>
 2020-09-28 12:41:00 -04:00
Stephen Worley 70347b7ad6 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>
 2020-09-28 12:41:00 -04:00
Donald Sharp e3b9c0f2f6 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>
 2020-09-28 12:40:59 -04:00
Stephen Worley 9c6c48bc10 zebra: return the proto nhe on del even with refs 
Return the proto nhe on del even if their are still possible
route references.

We may get a del before the routes are removed. So we still need
to return this to the caller so they can decrement the ref.

Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
 2020-09-28 12:40:59 -04:00
Stephen Worley 3bccc0f5eb 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>
 2020-09-28 12:40:59 -04:00
Stephen Worley f651b708e0 zebra: increment the nhg proto score iterator 
Increment the nhg proto score iterator we used to count
leftover NHGs after client disconnect and log.

Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
 2020-09-28 12:40:59 -04:00
Stephen Worley 1f65568046 zebra: fix refcnt/rib issues in NHG replace/delete 
Fix some reference counting issues seen when replacing
a NHG and deleting one.

For replacement, we should end with the same refcnt on the new
one.

For delete, its the caller's job to decrement its ref after
its done with it.

Further, update routes in the rib with the new pointer after replace.

Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
 2020-09-28 12:40:59 -04:00
Stephen Worley 24db1a7b9a zebra: handle proto NHG uninstall client disconnect 
Add code to handle proto-based NHG uninstalling after
the owning client disconnects.

This is handled the same way as rib_score_proto() but for now
we are ignoring instance.

Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
 2020-09-28 12:40:59 -04:00
Stephen Worley 2d8a9c544b zebra: remove unneeded nhg repalce boilerplate 
Remove some leftover boilerplate from the old replace
code path. That code ended up in the add API so its no
longer needed.

Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
 2020-09-28 12:40:59 -04:00
Stephen Worley ac5d1091dc 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>
 2020-09-28 12:40:59 -04:00
Stephen Worley 54c89c9377 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>
 2020-09-28 12:40:59 -04:00
Stephen Worley 16b20ad062 zebra: dont update counter if outside of zebra ID range 
When we receive a NHG from the kernel, we set the ID counter
to that to avoid using IDs owned from the kernel.

If we get one outside of zebra's range, lets not update it
since its probably one we created and never deleted anyway.

Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
 2020-09-28 12:40:59 -04:00
Stephen Worley 2c41ef8c17 zebra: special handling for proto-NHG-based routes 
For now let's assume proto-NHG-based routes are good to go
(we assume they are onlink/interface based anyway) and bypass
route resolution altogether.

Once we determine how to handle recursive nexthop-resolution for
proto-NHGs we will revisit this.

Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
 2020-09-28 12:40:59 -04:00
Stephen Worley dd1e105fe3 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>
 2020-09-28 12:40:59 -04:00
Stephen Worley 08da8bbc22 zebra: hash proto-created but zebra ID spaced NHGS 
To prevent duplication of singleton NHGs, lets hash
any zebra-ID spaced NHGs sent from an upper level proto.

These would be singleton NHGs anyway and should prevent duplication
of dataplane installs.

Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
 2020-09-28 12:40:59 -04:00
Stephen Worley 6c67f41f9e 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>
 2020-09-28 12:40:59 -04:00
Stephen Worley 0885b1e3d9 zebra: implement protocol NHG Add/Del 
Implement the underlying zebra functionality to Add/Del an
internal zebra and kernel NHG.

These NHGs are managed by the upperlevel protocols that send them
down via zapi messaging.

They are not put into the overall zebra NHG hash table and only
put into to the ID table. Therefore, different protos cannot
and will not share NHGs.

The proto is also set appropriately when sent to the kernel.

Expand the separation of Zebra hashed/shared/created NHGs and
proto created and mangaged NHGs.

Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
 2020-09-28 12:40:59 -04:00
Stephen Worley 5b27c09d4e 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>
 2020-09-28 12:40:59 -04:00
Donald Sharp bed74d178e zebra: Move debug information gathering to inside guard 
Let's not make the entire `depend_finds` function pay
for the data gathering needed for the debug.  There
are numerous other places in the code that check
the NEXTHOP_FLAG_RECURSIVE and do the same output.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
 2020-09-22 20:47:33 -04:00
Jakub Urbańczyk d68e74b41c lib, zebra: add support for sending ARP requests 
We can make the Linux kernel send an ARP/NDP request by adding
a neighbour with the 'NUD_INCOMPLETE' state and the 'NTF_USE' flag.

This commit adds new dataplane operation as well as new zapi message
to allow other daemons send ARP/NDP requests.

Signed-off-by: Jakub Urbańczyk <xthaid@gmail.com>
 2020-08-12 23:19:58 +02:00
Sebastien Merle 31f937fb43 lib, zebra: Add SR-TE policy infrastructure to zebra 
For the sake of Segment Routing (SR) and Traffic Engineering (TE)
Policies there's a need for additional infrastructure within zebra.
The infrastructure in this PR is supposed to manage such policies
in terms of installing binding SIDs and LSPs. Also it is capable of
managing MPLS labels using the label manager, keeping track of
nexthops (for resolving labels) and notifying interested parties about
changes of a policy/LSP state. Further it enables a route map mechanism
for BGP and SR-TE colors such that learned BGP routes can be mapped
onto SR-TE Policies.

This PR does not introduce any usable features by now, it is just
infrastructure for other upcoming PRs which will introduce 'pathd',
a new SR-TE daemon.

Co-authored-by: Renato Westphal <renato@opensourcerouting.org>
Co-authored-by: GalaxyGorilla <sascha@netdef.org>
Signed-off-by: Sebastien Merle <sebastien@netdef.org>
 2020-08-07 11:08:49 +02:00
Kaushik 92d6f76988 lib,zebra,bgpd: Fix for nexthop as IPv4 mapped IPv6 address 
Added a macro to validate the v4 mapped v6 address.
Modified bgp receive & send updates for v4 mapped v6 address as
nexthop and installing it as recursive nexthop in RIB.
Minor change in fpm while sending the routes for nexthop as
v4 mapped v6 address.

Signed-off-by: Kaushik <kaushik@niralnetworks.com>
 2020-08-03 23:24:04 -07:00
Mark Stapp 3c0e16228d zebra: improve vty, simplify some primary/backup code 
Improve vty output for routes and lsps with backups, including
json. Simplify or correct some code that uses both primary and
backup nexthops in dplane, nht.

Signed-off-by: Mark Stapp <mjs@voltanet.io>
 2020-07-20 15:09:04 -04:00
Stephen Worley c479909b69 zebra: mark connected nh inactive if not matching ifindex 
If we are asked to check if a nexthop is active and it matches a
connected route but the ifindex on it does not match the interface
with the connected route, mark as inactive. This is a bad nexthop.

Before, we would skip this check and just assume any nexthop that matches
on a connected route is valid and return here then fail during
installation. This adds a check for the IPV*_ifindex nexthop case where the
ifindex we have been sent doesn't match.

Old:
F>r 0.0.0.0/0 [200/0] via 20.0.0.2, test, weight 1, 00:00:27
  r                   via 40.4.4.4, lo, weight 1, 00:00:27

New:
F>* 0.0.0.0/0 [200/0] via 20.0.0.2, test, weight 1, 00:00:06
  *                   via 40.4.4.4, lo inactive, weight 1, 00:00:06

Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
 2020-07-10 13:42:37 -04:00
Mark Stapp 9959f1daba zebra: improve logic handling backup nexthop installation 
When handling a fib notification event that involves a route
with backup nexthops, be clearer about representing the
installed state of the backups: any installed backup will be
on a dedicated route_entry list.

Signed-off-by: Mark Stapp <mjs@voltanet.io>
 2020-07-07 13:14:01 -04:00