proxmox-mirrors/mirror_frr
1
0
Fork 0
mirror of https://git.proxmox.com/git/mirror_frr synced 2025-08-06 02:30:38 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity
14,657 Commits 4 Branches 191 Tags 125 MiB
fb85ce1b81
Commit Graph

2591 Commits

Author SHA1 Message Date
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
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
Donald Sharp
275565fb5a zebra: some v4 attributes were being written 2 times 
When the nexthop->type is NEXTHOP_TYPE_IPV4_IFINDEX we
were writing the RTA_PREFSRC 2 times for the build_singlepath
and build_multipath functions.

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
 2019-01-29 20:41:18 -05:00
Donald Sharp
e405df7e78 zebra: some v6 attributes were being written twice 
Some v6 attributes for the netlink_route_build_singlepath
code were being written two times for the NEXTHOP_TYPE_IPV6_IFINDEX
nexthop type.

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
 2019-01-29 20:40:41 -05:00
Chirag Shah
44bc8ae550 zebra: probe local inactive neigh 
In extended-mobility case ({IP1, MAC} binding),
when a MAC moves from local to remote, binding
changes to {IP2, MAC}, local neigh (IP1) marked
as inactive in frr.
The evpn draft recommends to probe the entry once
local binding changes from local to remote.
Once the probe is set for the local neigh entry,
kernel will attempt refresh the entry via sending
unicast address resolution message, if host does not
reply, it will mark FAILED state.
For FAILED entry, kernel triggers delete neigh
request, which result in frr to remove inactive entry.

In absence of probing and aging out entry,
if MAC moves back to local with {IP3, MAC},
frr will mark both IP1 and IP3 as active and sends
type-2 update for both.
The IP1 may not be active host and still frr advertises
the route.

Ticket:CM-22864
Testing Done:

Validate the MAC mobilty in extended mobility scenario,
where local inactive entry gets removed once MAC moves
to remote state.
Once probe is set to the local entry, kernel triggers
reachability of the neigh/arp entry, since MAC moved remote,
ARP request goes to remote VTEP where host is not residing,
thus local neigh entry goes to failed state.
Frr receives neighbor delete faster and removes the entry.

Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
 2019-01-29 10:23:19 -08:00
David Lamparter
ab66f55556
Merge pull request #3691 from pguibert6WIND/debug_rule_fwmark 
zebra: add fwmark information at netlink level
 2019-01-29 17:38:11 +01:00
Renato Westphal
718cfa14f4
Merge pull request #3687 from donaldsharp/ifp_flags 
zebra: Use the kernel flags from the IFA_FLAGS if it is available
 2019-01-29 14:35:09 -02:00
Chirag Shah
6fe2b0e67f zebra: add kernel neigh update api 
The kernel neigh update api helps update neighbor entry,
using changing state and flags parameters.

Ticket:CM-22864
Reviewed By:
Testing Done:

Signed-off-by:Chirag Shah <chirag@cumulusnetworks.com>
 2019-01-29 08:02:29 -08:00
David Lamparter
185fd9ca77
Merge pull request #3288 from nitinsoniism/show_intf_brief 
zebra: Support "brief" output for "show interface"
 2019-01-29 16:23:36 +01:00
Russ White
2538f1dad7
Merge pull request #3681 from donaldsharp/onlink 
*: The onlink attribute should be owned by the nexthop not the route.
 2019-01-29 10:09:44 -05:00
Russ White
1553085aa7
Merge pull request #3678 from chiragshah6/evpn_dev1 
zebra: EVPN fix duplicate address detection remote macip add case
 2019-01-29 10:05:50 -05:00
Philippe Guibert
15e6eed417 zebra: add fwmark information at netlink level 
ip rule configuration is being equipped with extra log information for
fwmark information.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
 2019-01-29 14:15:51 +01:00
Donald Sharp
9254efede1 zebra: Use the kernel flags from the IFA_FLAGS if it is available 
The ifa_flags value in the netlink message was originally a uint8_t
value.  The linux kernel quickly ran out of 8 bits of data to
pass and the IFA_FLAGS value was added to the netlink message to allow
more than 8 bits of data to be passed.  So replace the ifa_flags
with the IFA_FLAGS value if it exists in the interface netlink
message.

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
 2019-01-28 16:29:55 -05:00
Donald Sharp
fe85601c96 *: The onlink attribute should be owned by the nexthop not the route. 
The onlink attribute was being passed from upper level protocols
as an attribute of the route *not* the individual nexthop.  When
we pass this data to the kernel, we treat the onlink as a attribute
of the nexthop.  This commit modifies the code base to allow
us to pass the ONLINK attribute as an attribute of the nexthop.

This commit also fixes static routes that have multiple nexthops
some onlink and some not.

ip route 4.5.6.7/32 192.168.41.1 eveth1 onlink
ip route 4.5.6.7/32 192.168.42.2

S>* 4.5.6.7/32 [1/0] via 192.168.41.1, eveth1 onlink, 00:03:04
  *                  via 192.168.42.2, eveth2, 00:03:04

sharpd@robot ~/frr2> sudo ip netns exec EVA ip route show
4.5.6.7 proto 196 metric 20
	nexthop via 192.168.41.1 dev eveth1 weight 1 onlink
	nexthop via 192.168.42.2 dev eveth2 weight 1

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
 2019-01-26 21:02:26 -05:00
Donald Sharp
60f98b236e zebra: Keep track of when routes are queued/dequeued from the dataplane 
When we process the dataplane data, keep track of whether or not a route
is in transit or not.

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
 2019-01-25 20:16:15 -05:00
Donald Sharp
677c1dd5cb zebra: Use ROUTE_ENTRY_INSTALLED as decision for route is installed 
zebra is using NEXTHOP_FLAG_FIB as the basis of whether or not
a route_entry is installed.  This is problematic in that we plan
to separate out nexthop handling from route installation.  So modify
the code to keep track of whether or not a route_entry is installed/failed.

This basically means that every place we set/unset NEXTHOP_FLAG_FIB, we
actually also set/unset ROUTE_ENTRY_INSTALLED on the route_entry.
Additionally where we check for route installed via NEXTHOP_FLAG_FIB
switch over to checking if the route think's it is installed.

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
 2019-01-25 20:16:15 -05:00
Donald Sharp
4a2f796f2e lib, zebra: Abstract character selection for nexthop display 
When we are selecting nexthops for disply, abstract the notion
of what character we display to the end user about the status
of the nexthop.

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
 2019-01-25 20:14:38 -05:00
Donald Sharp
5ea8213f14 zebra: Fix use before initialized 
When we discover that a command given to the route add/delete
function in rt_socket.c is bogus, print out a debug message
but don't attempt to actually use a nexthop that we have not
figured out yet as part of the data.

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
 2019-01-25 20:14:38 -05:00