proxmox-mirrors/mirror_frr
1
0
Fork 0
mirror of https://git.proxmox.com/git/mirror_frr synced 2025-05-28 16:06:20 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity
14,889 Commits 4 Branches 191 Tags 125 MiB
08252eceee
Commit Graph

2607 Commits

Author SHA1 Message Date
Sri Mohana Singamsetty
08252eceee
Merge pull request #3800 from chiragshah6/evpn_dev 
zebra: advertise evpn route upon l3vni svi mac chg
 2019-02-27 13:38:03 -08:00
Russ White
24ee026b1a
Merge pull request #3865 from qlyoung/fix-zebra-vxlan-smelly-strings 
zebra: replace strncpy with strlcpy
 2019-02-26 11:08:18 -05:00
Quentin Young
138a496596 zebra: remove all instances of strncpy 
We have strlcpy.

Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
 2019-02-25 17:52:37 +00:00
Tim Bray
e3b78da875 *: Rename backet to bucket 
Presume typo from original author

Signed-off-by: Tim Bray <tim@kooky.org>
 2019-02-25 16:22:36 +00:00
Donald Sharp
5f27bcba2a zebra: Fix use after free in rib_process_result 
Running zebra after commit 888756b208
in valgrind produces this item:

==17102== Invalid read of size 8
==17102==    at 0x44D84C: rib_dest_from_rnode (rib.h:375)
==17102==    by 0x4546ED: rib_process_result (zebra_rib.c:1904)
==17102==    by 0x45436D: rib_process_dplane_results (zebra_rib.c:3295)
==17102==    by 0x4D0902B: thread_call (thread.c:1607)
==17102==    by 0x4CC3983: frr_run (libfrr.c:1011)
==17102==    by 0x4266F6: main (main.c:473)
==17102==  Address 0x83bd468 is 88 bytes inside a block of size 96 free'd
==17102==    at 0x4A35F54: free (vg_replace_malloc.c:530)
==17102==    by 0x4CCAC00: qfree (memory.c:129)
==17102==    by 0x4D03DC6: route_node_destroy (table.c:501)
==17102==    by 0x4D039EE: route_node_free (table.c:90)
==17102==    by 0x4D03971: route_node_delete (table.c:382)
==17102==    by 0x44D82A: route_unlock_node (table.h:256)
==17102==    by 0x454617: rib_process_result (zebra_rib.c:1882)
==17102==    by 0x45436D: rib_process_dplane_results (zebra_rib.c:3295)
==17102==    by 0x4D0902B: thread_call (thread.c:1607)
==17102==    by 0x4CC3983: frr_run (libfrr.c:1011)
==17102==    by 0x4266F6: main (main.c:473)
==17102==  Block was alloc'd at
==17102==    at 0x4A36FF6: calloc (vg_replace_malloc.c:752)
==17102==    by 0x4CCAA2D: qcalloc (memory.c:110)
==17102==    by 0x4D03D88: route_node_create (table.c:489)
==17102==    by 0x4D0360F: route_node_new (table.c:65)
==17102==    by 0x4D034F8: route_node_set (table.c:74)
==17102==    by 0x4D03486: route_node_get (table.c:327)
==17102==    by 0x4CFB700: srcdest_rnode_get (srcdest_table.c:243)
==17102==    by 0x4545C1: rib_process_result (zebra_rib.c:1872)
==17102==    by 0x45436D: rib_process_dplane_results (zebra_rib.c:3295)
==17102==    by 0x4D0902B: thread_call (thread.c:1607)
==17102==    by 0x4CC3983: frr_run (libfrr.c:1011)
==17102==    by 0x4266F6: main (main.c:473)
==17102==

This is happening because of this order of events:

1) Route is deleted in the main thread and scheduled for rib processing.
2) Rib garbage collection is run and we remove the route node since it
is no longer needed.
3) Data plane returns from the deletion in the kernel and we call
the srcdest_rnode_get function to get the prefix that was deleted.
This recreates a new route node.  This creates a route_node with
a lock count of 1, which we freed via the route_unlock_node call.
Then we continued to use the rn pointer.  Which leaves us with use
after frees.

The solution is, of course, to just move the unlock the node at the
end of the function if we have a route_node.

Fixes: #3854
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
 2019-02-23 20:03:48 -05:00
Chirag Shah
97c4e1d0e4 zebra: advertise evpn route upon l3vni svi mac chg 
L3VNI keeps reference to svi interface (ifp).

When a netlink change received there is no flag
that mac has changed. Currently simply overwrite
interface's (ifp) hw_addr (MAC) field.

For originating EVPN type-2 and type-5 routes due to VNI
MAC change, comparison is required to check existing MAC
vs. netlink change MAC field.

Ticket:CM-23850
Reviewed By:CCR-8283
Testing Done:

Validate EVPN type-5 routes originated upon changing MAC address
of L3VNI's SVI inteface via ip link set cmd.

checked show bgp l2vpn evpn route and Rmac field contains new
MAC address.

Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
 2019-02-21 13:50:43 -08:00
Mark Stapp
5c111895d6 zebra: unlock route-node in dplane results handler 
Unlock the route-node struct we look up while processing
async dataplane results.

Signed-off-by: Mark Stapp <mjs@voltanet.io>
 2019-02-21 16:15:14 -05:00
Mark Stapp
1d0c39fbd8
Merge pull request #3791 from sworleys/RT-Braces-rtadv 
zebra: Fix CLANG suggestion for braces on init of struct
 2019-02-14 09:07:47 -05:00
Donald Sharp
3fd385c685 zebra: Deletion of a lsp is not a failure event 
FRR is reporting that a lsp deletion event as a failure
in the log messsages.  This will lead to confusion and
lots of fun debugging.

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
 2019-02-13 12:49:59 -05:00
Donald Sharp
7a197b9269
Merge pull request #3778 from mjstapp/fix_dplane_update 
zebra: use update semantics for routes consistently
 2019-02-12 19:36:02 -05:00
Stephen Worley
844e918027 zebra: Fix CLANG suggestion for braces on init of struct 
CLANG was throwing an error because struct rtadv_rdnss(dnssl) was being
initialized with = {0} instead of {}. Change to be the latter.

Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
 2019-02-12 15:24:00 -05:00
David Lamparter
0fe29323f5
Merge pull request #3723 from slrz/zebra-rtadv-add-rfc8106-support 
zebra: add support for IPv6 RA options for DNS configuration (RFC8106)
 2019-02-12 14:30:00 +01:00
Mark Stapp
8263d1d0d9 zebra: use update semantics for routes consistently 
Use 'update' semantics for route updates, to ensure that
netlink replace behavior works correctly.

Signed-off-by: Mark Stapp <mjs@voltanet.io>
 2019-02-11 16:11:02 -05:00
Lars Seipel
110765e34a zebra: prefer DEFINE_MTYPE_STATIC for local memtypes 
Signed-off-by: Lars Seipel <ls@slrz.net>
 2019-02-11 21:46:06 +01:00
Donald Sharp
494247b58c zebra: Update zserv debug messages to give a bit more useful info 
When we schedule a packet for future handling, list the packet
type so that we can see what we are getting with debugs.

Also note which client and how many packets we received from that
client.

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
 2019-02-10 11:48:14 -05:00
Russ White
1632290b3f
Merge pull request #3745 from chiragshah6/evpn_dev1 
EVPN advertise svi ip as macip route changes via config command
 2019-02-07 14:36:46 -05:00
David Lamparter
b7777b57c4
Merge pull request #3722 from donaldsharp/static_recursive 
Zebra fixes
 2019-02-07 19:22:29 +01:00
Chirag Shah
278e26de8e zebra: advertise svi ip as macip route changes 
In Asymmetric and symetric routing scenario in EVPN
where each VTEP pair having different set of addresses
for the SVIs.
This knob allows reachability (ping connectivity) of
SVI IPs and resolve ARP resoultion VTEPs across racks.

This knob should not be used when same SVI IPs configured
on VTEPs across racks or when advertise default gateway
is configured.

Ticket:CM-23782
Testing Done:
Bring up EVPN symmetric routing topology with different
SVI IPs on different VTEPs. Enable advertise svi ip
at each VTEP, remote VTEPs installs arp entry for
SVI IPs via EVPN type-2 route exchange.

Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
 2019-02-06 19:57:53 -08:00
Donald Sharp
4634d02cfd
Merge pull request #3684 from mjstapp/dplane_pw 
zebra: async dataplane for pseudowires
 2019-02-05 18:41:12 -05:00
Donald Sharp
e625a783ed zebra: Do not display recursive nexthops as installed 
Recursive nexthops should not be marked as installed

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
 2019-02-05 15:21:26 -05:00
Donald Sharp
6c47d39902 zebra: Fix multiple levels of static recursion 
Allow the nexthop-check code to figure out recursive static routes
in a logical manner.

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
 2019-02-05 15:21:26 -05:00
Donald Sharp
9f3a86d3e6
Merge pull request #3518 from rgirada/routemap_3090 
libd: Implemented a cli "show route-map-unused" to track all unused rou…
 2019-02-05 11:13:22 -05:00
Russ White
5dd91bc84f
Merge pull request #3733 from donaldsharp/meta_queue_nht_game_over_man_game_over 
zebra: NHT was being run at least 2 times and missreporting data
 2019-02-05 11:06:42 -05:00
Russ White
b8f248ab6f
Merge pull request #3730 from donaldsharp/send_information 
Send information
 2019-02-05 10:53:50 -05:00
Russ White
37a5432422
Merge pull request #3688 from chiragshah6/evpn_dev 
zebra: EVPN probe local inactive neigh/arp entry upon mac mobility
 2019-02-05 10:48:33 -05:00
Russ White
0848547352
Merge pull request #3679 from chiragshah6/evpn_dev2 
zebra: reinstate bgp evpn remote route on local evpn route delete
 2019-02-05 10:47:35 -05:00
Donald Sharp
46a4e3455b zebra: NHT was being run at least 2 times and missreporting data 
With the data plane changes that were made, we are now running
nexthop tracking 2 times.  Once at the end of meta-queue insertion
and once at the end of receiving a bunch of data from the dataplane.

The Addition of the data plane code caused flags to not be set
fully for the resolved routes( since we do not know the answer yet ),
This in turn caused the nexthop tracking run after the meta-queue
to think that the route was not `good`.  This would cause it to
tell all interested parties that there was no nexthop.

After the dataplane insertion we are also no running nht code.
This was re-figuring out the nexthop correctly and also
correctly reporting to interested parties that there was a path again.

Example:
donna.cumulusnetworks.com(config)# do show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
       F - PBR, f - OpenFabric,
       > - selected route, * - FIB route, q - queued route, f - failed route

K>* 0.0.0.0/0 [0/103] via 10.50.11.1, enp0s3, 00:06:47
S>* 4.5.6.7/32 [1/0] via 192.168.209.1, enp0s8, 00:04:47
C>* 10.50.11.0/24 is directly connected, enp0s3, 00:06:47
C>* 192.168.209.0/24 is directly connected, enp0s8, 00:06:47
C>* 192.168.210.0/24 is directly connected, enp0s9, 00:06:47
donna.cumulusnetworks.com(config)# ip route 4.5.6.7/32 192.168.210.1
donna.cumulusnetworks.com(config)# do show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
       F - PBR, f - OpenFabric,
       > - selected route, * - FIB route, q - queued route, f - failed route

K>* 0.0.0.0/0 [0/103] via 10.50.11.1, enp0s3, 00:07:06
S>* 4.5.6.7/32 [1/0] via 192.168.209.1, enp0s8, 00:00:04
  *                  via 192.168.210.1, enp0s9, 00:00:04
C>* 10.50.11.0/24 is directly connected, enp0s3, 00:07:06
C>* 192.168.209.0/24 is directly connected, enp0s8, 00:07:06
C>* 192.168.210.0/24 is directly connected, enp0s9, 00:07:06
donna.cumulusnetworks.com(config)#

Log files for sharp, which is watching 4.5.6.7:
2019/02/04 15:20:54.844288 SHARP: Received update for 4.5.6.7/32
2019/02/04 15:20:54.844820 SHARP: Received update for 4.5.6.7/32
2019/02/04 15:20:54.844836 SHARP: 	Nexthop 192.168.209.1, type: 2, ifindex: 3, vrf: 0, label_num: 0
2019/02/04 15:20:54.844853 SHARP: 	Nexthop 192.168.210.1, type: 2, ifindex: 4, vrf: 0, label_num: 0

As you can see we have received an update with no nexthops( invalid route )
and a second update immediately after it with 2 nexthops.

What's the big deal you say?  Well we have code in other daemons that reacts
to not having a path for a nexthop.  In BGP this will cause us to tear
down the peer.  In staticd we'll remove the recursively resolved route.
In pim we'll remove all paths to the mroute.  This is not desirable.

The fix is to remove the meta-queue run of nexthop tracking.

While running after data plane notice of routes to handle is not ideal
we will be fixing this in the future with the nexthop group code, which
should know what nexthops are affected by a nexthop group change.

Fixed code debug code:
donna.cumulusnetworks.com(config)# do show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
       F - PBR, f - OpenFabric,
       > - selected route, * - FIB route, q - queued route, f - failed route

K>* 0.0.0.0/0 [0/103] via 10.50.11.1, enp0s3, 00:00:46
S>* 4.5.6.7/32 [1/0] via 192.168.209.1, enp0s8, 00:00:02
C>* 10.50.11.0/24 is directly connected, enp0s3, 00:00:46
C>* 192.168.209.0/24 is directly connected, enp0s8, 00:00:46
C>* 192.168.210.0/24 is directly connected, enp0s9, 00:00:46
donna.cumulusnetworks.com(config)# ip route 4.5.6.7/32 192.168.210.1
donna.cumulusnetworks.com(config)# do show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
       F - PBR, f - OpenFabric,
       > - selected route, * - FIB route, q - queued route, f - failed route

K>* 0.0.0.0/0 [0/103] via 10.50.11.1, enp0s3, 00:00:59
S>* 4.5.6.7/32 [1/0] via 192.168.209.1, enp0s8, 00:00:02
  *                  via 192.168.210.1, enp0s9, 00:00:02
C>* 10.50.11.0/24 is directly connected, enp0s3, 00:00:59
C>* 192.168.209.0/24 is directly connected, enp0s8, 00:00:59
C>* 192.168.210.0/24 is directly connected, enp0s9, 00:00:59

2019/02/04 15:26:20.656395 SHARP: Received update for 4.5.6.7/32
2019/02/04 15:26:20.656440 SHARP: 	Nexthop 192.168.209.1, type: 2, ifindex: 3, vrf: 0, label_num: 0
2019/02/04 15:26:33.688251 SHARP: Received update for 4.5.6.7/32
2019/02/04 15:26:33.688322 SHARP: 	Nexthop 192.168.209.1, type: 2, ifindex: 3, vrf: 0, label_num: 0
2019/02/04 15:26:33.688329 SHARP: 	Nexthop 192.168.210.1, type: 2, ifindex: 4, vrf: 0, label_num: 0

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
 2019-02-05 09:17:02 -05:00
Donald Sharp
a8a20c4e3c zebra: Remove zclient->idinfo restrictions 
The restricting of data about interfaces was both inconsistent
in application and allowed protocol developers to get into states where
they did not have the expected data about an interface that they
thought that they would.  These restrictions and inconsistencies
keep causing bugs that have to be sorted through.

The latest iteration of this bug was that commit:
f20b478ef3

Has caused pim to not receive interface up notifications( but
it knows the interface is back in the vrf and it knows the
relevant ip addresses on the interface as they were changed
as part of an ifdown/ifup cycle ).

Remove this restriction and allow the interface events to
be propagated to all clients.

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
 2019-02-05 09:13:30 -05:00
Renato Westphal
3524352154
Merge pull request #3698 from donaldsharp/netlink_is_serious_business 
Netlink is serious business
 2019-02-05 11:52:33 -02:00
rgirada
54e80c7656 zebrad: Added changes to track route-map usage 
Made changes and updated the routemap applied counter in the following flows.
1.Increment when route map attached to a list.
2.Decrement when route map removed / modified from a list.
3.Increment/decrement when route map create/delete callback triggered.
4.Besides ,This counter need not be updated when a route map is got updated.
  i.e changing/adding a match value to the existing routemap.

In Zebra , same update api called for all three add/delete/update operation.
But this counter have to be updated only for routemap addition.
Addressed this specific change by identifying the routemap operation based
on routemap pointer.

Signed-off-by: RajeshGirada <rgirada@vmware.com>
 2019-02-04 05:19:54 -08:00
Lars Seipel
7eab94f9b1 zebra: avoid exceeding link MTU through RA options 
Signed-off-by: Lars Seipel <ls@slrz.net>
 2019-02-02 19:10:19 +01:00
Lars Seipel
3eb4fbb0f5 zebra: support DNS configuration options in rtadv 
Add support for the RDNSS and DNSSL router advertisement
options described in RFC 8106.

Signed-off-by: Lars Seipel <ls@slrz.net>
 2019-02-02 19:10:19 +01:00
Donald Sharp
b120fe3b69 zebra: Add ability to send to all clients updated capability information 
When capability information changes, allow for resending of data.

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
 2019-01-31 09:28:39 -05:00
Donald Sharp
236667251d zebra: Add code to allow us to add debug for mlag 
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
 2019-01-31 09:20:46 -05:00
Donald Sharp
e96ba9daeb zebra: Add mlag information to zrouter 
Since this is zebra router global level information
store mlag data in the zrouter structure.

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
 2019-01-31 09:20:46 -05:00
Donald Sharp
2561d12e5d zebra: Remove struct zebra_t 
This structure is unused anymore and does not belong in zserv.h

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
 2019-01-31 09:20:46 -05:00
Donald Sharp
5ec5a7160a zebra: Move packets_to_process to zrouter 
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
 2019-01-31 09:20:46 -05:00
Donald Sharp
e2353ec265 zebra: Move lsp_process_q to zrouter 
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
 2019-01-31 09:20:46 -05:00
Donald Sharp
ea45a4e7db zebra: Move the mq data structure to zrouter 
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
 2019-01-31 09:20:46 -05:00
Donald Sharp
489a961429 zebra: Move ribq from zebrad to zrouter 
The zrouter should own this data structure and it should not
be defined in zserv.h

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
 2019-01-31 09:20:46 -05:00
Donald Sharp
b3d43ff471 zebra: Move rtm_table_default to zrouter 
The zrouter should own this particular piece of data.

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
 2019-01-31 09:20:46 -05:00
Donald Sharp
cc3d883445 zebra: Make zebrad.sock zserv.c private data 
The zebra.sock data is the listener socket for the zapi protocol.
The rest of the zebra router does not need to see this data.

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
 2019-01-31 09:20:46 -05:00
Donald Sharp
161e9ab7e2 zebra: Move client_list to the zebra_router data structure 
The client_list should be owned by the zebra_router data structure
as that it is part of global state information.

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
 2019-01-31 09:20:46 -05:00
Donald Sharp
3801e7646c zebra: Move the master thread handler to the zrouter structure 
The master thread handler is really part of the zrouter structure.
So let's move it over to that.  Eventually zserv.h will only be
used for zapi messages.

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
 2019-01-31 09:20:46 -05:00
David Lamparter
19b336d343
Merge pull request #3699 from donaldsharp/zebra_rib_debugs 
Zebra Respect my authority
 2019-01-31 01:51:52 +01:00
Donald Sharp
b9f0e5ee24 zebra: On route update context is sometimes indeterminate in post-processing 
When we get into rib_process_result and the operation we are handling
is DPLANE_OP_ROUTE_UPDATE *and* the route entry being looked at
is a route replace, we currently have no way to decode to the old_re
and the re due to how we have stored context.  As such they are the
same pointer.

As such the route replace for the same route type is causing the re
to set the installed flag and then immediately unset the installed
flag, leaving us in a state where the kernel has the route but
the rib thinks we are not installed.

Since the true old_re( the one being replaced by the update operation )
is going away( as that it zebra deletes the old one for us already )
this fix is not optimal but will get us moving forward.

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
 2019-01-30 09:52:13 -05:00
Donald Sharp
6cae47ed38 zebra: When the kernel passes up a onlink route respect those flags 
Read the onlink flag from the kernel for routes and pass them
up and through to zebra so that we are consistent with what
the kernel is telling us.

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
 2019-01-29 22:01:03 -05:00
Donald Sharp
058c16b7e2 zebra: Trust kernel and System routes 
If we receive a valid message from the kernel that
is either a kernel or system route, we should trust
that the route is legit and just use it.

Old behavior:

K * 172.22.0.0/15 [0/0] via 172.22.2.254, eva_dummy1 inactive, 00:00:16

New Behavior:

K>* 172.22.0.0/15 [0/0] via 172.22.2.254, eva_dummy1, 00:02:35

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
 2019-01-29 21:45:02 -05:00
Donald Sharp
2da33d6b3a zebra: Convert route entry id number to string in debugs 
The route entry being displayed in debugs was displaying
the originating route type as a number.  While numbers
are cool, I for one am not terribly interested in
memorizing them.  Modify the (type %d) to a (%s) to
just list the string type of the route.

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
 2019-01-29 21:35:07 -05:00
Donald Sharp
b0538fc8b7 lib, zebra: Fix 'show ip route' char collision 
Apparently 'f' means both OpenFabric and a Failed kernel
route installation.

Let's switch the 'f' for the failed kernel route installation
to 'r - rejected route'.

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
 2019-01-29 20:41:36 -05:00