proxmox-mirrors/mirror_frr
1
0
Fork 0
mirror of https://git.proxmox.com/git/mirror_frr synced 2025-05-01 09:24:46 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity
31,695 Commits 4 Branches 191 Tags 125 MiB
a3e8e1aacb
Commit Graph

289 Commits

Author SHA1 Message Date
Hiroki Shirokura
eab0f8f0a2 lib,sharpd,zebra: update nexthop object with nh_srv6 
Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
 2021-06-02 10:24:48 -04:00
Hiroki Shirokura
76fb7ae4de zebra: ZEBRA_ROUTE_ADD supports seg6 route (step3) 
With this patch, zclient can intall seg6 rotues when
they set properties "nh_seg6_segs" on struct nexthop
and set ZEBRA_FLAG_SEG6_ROUTE on zapi_route's flag.

Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
 2021-06-02 10:24:48 -04:00
Hiroki Shirokura
8689b25a08 zebra: ZEBRA_ROUTE_ADD supports seg6local route (step1) 
With this patch, zclient can intall seg6local rotues whem
they set properties nh_seg6local_{action,ctx} on struct nexthop
and set ZEBRA_FLAG_SEG6LOCAL_ROUTE on zapi_route's flag.

Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
 2021-06-02 10:24:47 -04:00
Philippe Guibert
62b4b7e44a zebra: new dplane action to set gre link interface 
This action is initiated by nhrp and has been stubbed when
moving to zebra. Now, a netlink request is forged to set
the link interface of a gre interface if that gre interface
does not have already a link interface.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
 2021-04-30 10:33:18 +02:00
Russ White
d8c3daca19
Merge pull request #8531 from mjstapp/fix_backups_misc 
zebra: Misc fixups for backup nexthops
 2021-04-27 16:04:24 -04:00
Stephen Worley
829c939a88
Merge pull request #8488 from mjstapp/more_workqueue 
lib, zebra: use zebra workqueue for NHG updates
 2021-04-27 11:59:33 -04:00
Stephen Worley
dc65cd999d zebra: handle gracefulRS/retain with proto NHGs 
Properly handle refcounting of Proto-owned NHGs when
zebra is operating under graceful restart and retain
conditions.

We have an extra refcnt of 1 we keep for proto-owned NHGs to
indicate the upper level proto has created and owns it.

When we are reading these in from the kernel, we need to set them
to 1 as appropriate. Without this, we fail in the assert() during
zebra_nhg_proto_add() after the owning daemons resends the NHG
and the refcnts are off by one.

Also add in the same logic we use for routes when sweeping with
respect to uptimes.

Signed-off-by: Stephen Worley <sworley@nvidia.com>
 2021-04-22 17:25:15 -04:00
Stephen Worley
45691de9a0 zebra: add uptime to NHEs 
Add uptime for use with NHEs to keep track of how
long we have had this NHE in our rib without an update.

This is treated exactly the same as the re->uptime for
routes. When we get an update for a route, we reset the
uptime.

Signed-off-by: Stephen Worley <sworley@nvidia.com>
 2021-04-22 17:25:15 -04:00
Stephen Worley
65f137fe3c zebra: add PROTO_OWNED macro for NHE id bounds checking 
Add a PROTO_OWNED macro for code readability when checking
ID bounds for whether a NHG is proto owned.

Signed-off-by: Stephen Worley <sworley@nvidia.com>
 2021-04-22 17:25:15 -04:00
Mark Stapp
a082cd9a51 zebra: include inner labels with recursive backups 
When capturing backup nexthops with recursive resolution,
ensure that inner labels from the recursive nexthop are
included in each backup (as they are with the resolving
primary nexthops).

Signed-off-by: Mark Stapp <mjs@voltanet.io>
 2021-04-21 14:30:15 -04:00
Mark Stapp
c56c16eb2c zebra: fix some issues in recursive backup nexthop code 
Fix a couple of small things in the code that captures backup
nexthops during recursive resolution.

Signed-off-by: Mark Stapp <mjs@voltanet.io>
 2021-04-21 14:30:15 -04:00
Mark Stapp
04bec7b217 zebra: use workqueue for daemon-owned NHGs 
Use the main zebra workqueue for daemon-owned NHGs, in addition
to processing kernel-owned NHGs. The zapi message processing
creates a temporary object that's enqueued to the workqueue,
then processed/installed as part of the workqueue processing.

Signed-off-by: Mark Stapp <mjs@voltanet.io>
 2021-04-15 14:20:39 -04:00
Philippe Guibert
e18747a967 zebra: move neighbor table configuration to dplane contexts 
Instead of directly configuring the neighbor table after read from zapi
interface, a zebra dplane context is prepared to host the interface and
the family where the neighbor table is updated. Also, some other fields
are hosted: app_probes, ucast_probes, and mcast_probes. More information
on those fields can be found on ip-ntable configuration.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
 2021-04-09 18:29:58 +02:00
Philippe Guibert
0a27a2fef5 zebra, lib: handle NEIGH_ADD/DELETE to zebra dataplane framework 
EVPN neighbor operations were already done in the zebra dataplane
framework. Now that NHRP is able to use zebra to perform neighbor IP
operations (by programming link IP operations), handle this operation
under dataplane framework:
- assign two new operations NEIGH_IP_INSTALL and NEIGH_IP_DELETE; this
is reserved for GRE like interfaces:
example: ip neigh add A.B.C.D lladdr E.F.G.H
- use 'struct ipaddr' to store and encode the link ip address
- reuse dplane_neigh_info, and create an union with mac address
- reuse the protocol type and use it for neighbor operations; this
permits to store the daemon originating this neighbor operation.
a new route type is created: ZEBRA_ROUTE_NEIGH.
- the netlink level functions will handle a pointer, and a type; the
type indicates the family of the pointer: AF_INET or AF_INET6 if the
link type is an ip address, mac address otherwise.
- to keep backward compatibility with old queries, as no extension was
done, an option NEIGH_NO_EXTENSION has been put in place
- also, 2 new state flags are used: NUD_PERMANENT and NUD_FAILED.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
 2021-04-09 18:29:58 +02:00
David Lamparter
224ccf29d9 zebra: kill zebra_memory.h, use MTYPE_STATIC 
This one also needed a bit of shuffling around, but MTYPE_RE is the only
one left used across file boundaries now.

Signed-off-by: David Lamparter <equinox@diac24.net>
 2021-03-22 20:02:17 +01:00
Mark Stapp
5530d55d3c zebra: capture backup nexthop info with recursive resolution 
When resolving a recursive route, capture backup nexthop info
along with the resolving nexthops.

Signed-off-by: Mark Stapp <mjs@voltanet.io>
 2021-03-16 12:14:53 -04:00
Mark Stapp
aa45883818 zebra: add ui control for use of backup nexthops in resolution 
Add a control and api for the use of backup nexthops in
recursive resolution. With 'no', we won't try to use installed
backup nexthops when resolving a recursive route.

Signed-off-by: Mark Stapp <mjs@voltanet.io>
 2021-03-16 12:14:53 -04:00
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
Mark Stapp
92ad0c558c zebra: skip un-installed recursive match 
Do less work when resolving a recursive route: just skip
nexthops if the resolving route is not installed.

Signed-off-by: Mark Stapp <mjs@voltanet.io>
 2020-07-07 13:14:01 -04:00
Mark Stapp
9d43854d94 zebra: only use ACTIVE nexthops in recursive resolution 
Only use ACTIVE nexthops to resolve recursive routes, not all
nexthops from a resolving route.

Signed-off-by: Mark Stapp <mjs@voltanet.io>
 2020-07-07 13:14:01 -04:00
Mark Stapp
f264672058 zebra: allow recursive resolution to use backup nexthops 
Allow both primary and backup nexthops to be used in
recursive resolution processing.

Signed-off-by: Mark Stapp <mjs@voltanet.io>
 2020-07-07 13:14:01 -04:00
Mark Stapp
6b193087ca staticd,zebra: use ALLOW_RECURSION for static routes 
Remove a special-case clause for static routes - it was the same
as the clause for other recursive routes. Have staticd just tell
zebra that recursion is allowed. Update topotest that was aware
of this 'internal' flag.

Signed-off-by: Mark Stapp <mjs@voltanet.io>
 2020-07-07 13:14:01 -04:00
Mark Stapp
cb3e512d97 tests,zebra: fix more startup topotest issues 
Use the right list of daemons to avoid trying to start zebra twice.
Change a zebra log message to INFO level to avoid stderr check
failure.

Signed-off-by: Mark Stapp <mjs@voltanet.io>
 2020-07-04 12:25:10 -04:00
Jakub Urbańczyk
60d8d43be4 zebra: prepare dplane to deal with pbr rules 
This commit is the first step to convert IP rule installation to
use dplane thread.
 * Add dataplane's internal representation of a pbr rule
 * Add dplane stats related to rules
 * Introduce a new type of dplane operation

Signed-off-by: Jakub Urbańczyk <xthaid@gmail.com>
 2020-06-10 16:18:45 +02:00
Mark Stapp
f727646ada zebra: rename 'nhg_copy' to 'nhe_copy' 
It copies nhes...

Signed-off-by: Mark Stapp <mjs@voltanet.io>
 2020-06-01 14:46:32 -04:00
Russ White
0a6fd9ce9d
Merge pull request #6389 from mjstapp/fix_recursive_label_type 
zebra: prefer outer label_type for recursive nexthops
 2020-05-19 11:42:36 -04:00
vivek
12b4d77bab zebra: Trust onlink flag for nexthop active resolution 
When checking if a nexthop is active, if it has been marked as onlink,
just check on the presence and status of the nexthop's interface. When
handling client request to create a route, if the client says that the
nexthop is onlink, trust it; when internally (in zebra) determining
that the nexthop is onlink, ensure it is only done in the case of an
interface with a /32 IP address which is the case for OSPF unnumbered.

Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by:   Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by:   Stephen Worley <sworley@cumulusnetworks.com>
 2020-05-15 16:22:01 -07:00
Mark Stapp
6bc5d97795 zebra: prefer outer label_type for recursive nexthops 
When resolving a recursive nexthop, prefer the "outer"
label type, if present.

Signed-off-by: Mark Stapp <mjs@voltanet.io>
 2020-05-12 14:27:02 -04:00
Donald Sharp
630d596249 zebra: Remove typedef rib_table_info_t from system 
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
 2020-05-08 08:10:49 -04:00
Donald Sharp
5cfaa2d92b zebra: Loosen ONLINK restrictions a tiny bit 
Loosen the ONLINK restrictions such that when an upper
level protocol sends us a nexthop with an ONLINK attribute
just ensure that interface is up and usable.  ONLINK effectively
means we know what we are doing to the kernel.

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
 2020-05-06 10:15:41 -04:00
Mark Stapp
f924db4961 zebra: fix some coverity SA warnings 
Fix several coverity scan warnings.

Signed-off-by: Mark Stapp <mjs@voltanet.io>
 2020-04-14 07:44:54 -04:00
Mark Stapp
0328a5bd0d zebra: don't include backup nhs in main nhe dependency tree 
We don't want to install backup nexthops - yet - as part of the
nexthop-id-based kernel interactions on netlink platforms. Avoid
mixing backup and primary nexthops in the tree of dependencies
in the ecmp cases.

Signed-off-by: Mark Stapp <mjs@voltanet.io>
 2020-03-27 11:50:03 -04:00
Mark Stapp
377e29f7e7 zebra: handle backup nexthops in nhe/nhgs 
Include backup nexthops in nhe processing; connect incoming
zapi route data with updated rib/nhg apis; add more debugs in
nhg processing.

Signed-off-by: Mark Stapp <mjs@voltanet.io>
 2020-03-27 11:50:03 -04:00
Mark Stapp
1d48702ede zebra: add per-nexthop backup index 
Use a backup index in a nexthop directly (if it has a backup
nexthop); revise the zebra nhe/nhg code; revise zapi route
decoding to match; revise the dataplane route datastructs.

Refactor some of the rib_add_multipath code to be prepared to
be called with an nhe, carrying nexthop and (possibly) backup
info together.

Signed-off-by: Mark Stapp <mjs@voltanet.io>
 2020-03-27 11:50:03 -04:00
Stephen Worley
d43122b58f zebra: break if duplicate nexthop found in nhe2grp 
If we find that a nexthop is a duplicate, break immediately
rather than continuing to look through the rest of the list.

Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
 2020-03-26 10:57:45 -04:00
Stephen Worley
086e4e02f5 zebra: properly set the NEXTHOP_GROUP_VALID flag 
Properly set the NEXTHOP_GROUP_VALID flag and use it
as a conditional for installation decisions for individual
nexthop and groups containing it.

We set the NEXTHOP_GROUP_VALID flag it is:

1) A fully resolved active nexthop
or
2) Its a group that contains at least one VALID NHE

Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
 2020-03-26 10:48:16 -04:00
Stephen Worley
715e5c70d5 zebra: set valid on re->nhe directly in nexthop_active_update() 
We were still doing a lookup on the nhe_id from before we
started referencing re->nhe directly.

Change set flag to just use re->nhe directly here since they
should always be the same at this point in the code anyway.

Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
 2020-03-26 10:48:15 -04:00
Stephen Worley
b1c3f7ef80 zebra: add debug for duplicate NH in dataplane array conversion 
When we find a nexthop ID thats a duplicate in the code that converts
NHG rb trees into a flat list of nexthop IDs for the dataplane,
output a debug message.

Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
 2020-03-26 10:48:15 -04:00
Stephen Worley
1866b3afc2 zebra: don't add ID to kernel nh_grp if not installed/queued 
When we transform the nexthop group rb trees into a flat
array of IDs to send into the dataplane code (zebra_nhg_nhe2grp),
don't put an ID in there that has not been in installed or is
not currently queued to be installed into the dataplane.

Otherwise, if some of the nexthops fail to install, we will
still try to create a group with them and then the entire group
will fail.

Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
 2020-03-26 10:48:15 -04:00
Stephen Worley
497ff5792f zebra: handle NHG in NHG dataplane group conversion 
We were not properly handling the case of a NHG inside of
another NHG when converting the rb tree of a multilevel NHG
into a flat list of IDs. When constructing, we call the function
zebra_nhg_nhe2grp_internal() recursively so that the rare
case of a group within a group is handled such that its
singleton nexthops are appended to the grp array of IDs
we send to the dataplane code.

Ex)

1:
	-> 2:
		-> 3
		-> 4
	->5:
		->6

becomes this:

1:
	->3
	->4
	->6

when its sent to the dataplane code for final kernel installation.

Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
 2020-03-26 10:48:15 -04:00
David Lamparter
d6951e5ef9 *: remove tabs from log messages 
Some logging systems are, er, "allergic" to tabs in log messages.
(RFC5424: "The syslog application SHOULD avoid octet values below 32")

Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
 2020-03-24 18:47:12 +01:00
Ruben Kerkhof
99e7ab12cf zebra: use modern C function definition 
And also remove an assignment without effect while we're here.

Signed-off-by: Ruben Kerkhof <ruben@rubenkerkhof.com>
 2020-03-11 14:06:34 +01:00
Donald Sharp
0752c8d8a4 zebra: nhg->nexthop is not NULL 
We have already asserted on nhg->nexthop an if statement
to flog_err makes no sense.

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
 2020-03-06 16:37:19 -05:00
Donald Sharp
5e81f5dd1a *: Finish off the __PRETTY_FUNCTION__ to __func__ 
FINISH IT

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
 2020-03-06 09:23:22 -05:00
Donatas Abraitis
15569c58f8 *: Replace __PRETTY_FUNCTION__/__FUNCTION__ to __func__ 
Just keep the code cool.

Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
 2020-03-05 20:23:23 +02:00
Stephen Worley
fc8a02c45f zebra: trust directly connected kernel/system routes 
We made the decision to explicitly trust kernel and system routes
of every other type with 058c16b7e2.

So, we should trust directly connected routes the same way, assuming
the interface exists.

Old Behavior:

K   2.2.2.1/32 [0/0] is directly connected, unknown inactive, 00:00:39

New Behavior:

K>* 2.2.2.1/32 [0/0] is directly connected, test1, 00:00:03

As a bonus, this fixes the issues we were seeing with not removing
directly connected routes of certain interface types when
those interfaces go down/are deleted.

Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
 2020-03-02 13:45:40 -05:00
Mark Stapp
c415d89528 zebra: Embed lib nexthop-group in zebra hash entry 
Embed nexthop-group, which is just a pointer, in the zebra
nexthop-hash-entry object, rather than mallocing one.

Signed-off-by: Mark Stapp <mjs@voltanet.io>
 2020-02-27 15:49:31 -05:00
Renato Westphal
ecaeb3b697
Merge pull request #5750 from qlyoung/fix-null-after-xfree 
*: don't null after XFREE; XFREE does this itself
 2020-02-05 01:49:08 -03:00
Russ White
c7a754408e
Merge pull request #5746 from donaldsharp/bgp_sa 
Coverioty sa stuff
 2020-02-04 11:24:08 -05:00
Russ White
05d0c66d8f
Merge pull request #5737 from mjstapp/zebra_disable_kern_nhs 
zebra: add config to disable use of kernel nexthops
 2020-02-04 08:12:34 -05:00
Donald Sharp
9275682559 zebra: top has already been derefed 
The top variable has already been derefed by the time we get
to the test to see if it is non-NULL.  No need to check it.

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
 2020-02-04 08:10:52 -05:00