summaryrefslogtreecommitdiffstats
path: root/zebra/zebra_evpn_mac.h (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Merge pull request #10726 from chiragshah6/fdev2Sri Mohana Singamsetty2022-03-231-2/+2
|\ | | | | zebra: evpn revamp l3vni routermac db
| * zebra: cleanup host prefix from rmacChirag Shah2022-03-111-3/+0
| | | | | | | | | | | | | | Ticket:#2798406 Testing Done: Signed-off-by: Chirag Shah <chirag@nvidia.com>
| * zebra: maintain list of nhs in rmac dbChirag Shah2022-03-111-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Keep the list of remote-vteps/nexthops in rmac db. Problem: In CLAG deployment there might be a situation where CLAG secondary sends individual ip as nexthop along with anycast mac as RMAC. This combination is updated in zebra's rmac cache. Upon recovery at clag secondary sends withdrawal of the incorrect rmac and nexthop mapping. The RMAC entry mapping to nh is not cleaned up properly in the zebra rmac cache. Fix: Zebra rmac db needs to maintain a list of nexthops. When a bgp withdrawal for rmac to nexthop mapping is received, remove the old nexthop from the rmac's nh list and if the host reference still remains for the RMAC,fall back to the nexthop one remaining in the list. At most you expect two nexthops mapped to RMAC (in clag deployment). Ticket: 2798406 Reviewed By: Testing Done: CLAG primary and secondary have advertise-pip enabled advertise type-5 route (default route) with individual IP as nh and individual svi mac as rmac. - disable advertise pip on both clag devices, this results in advertisement of routes with anycast ip as nh and anycast mac as rmac. - disable peerlink on clag primary, this triggers clag secondary to (transitory) send bgp update with individual ip as nh and anycast mac as rmac. - At the remote vtep: Check the zebra's rmac cache/nh mapping correctly and points to anycast rmac and anycast ip as nh of the clag system. Signed-off-by: Chirag Shah <chirag@nvidia.com>
* | zebra: minor changes on "zebra_evpn_mac_gw_macip_add" functionanlan_cs2022-02-191-5/+6
|/ | | | | | | | | | | Two minor changes: 1) Change `zebra_evpn_mac_gw_macip_add()` 's return type to `void`. 2) Since `zebra_evpn_mac_gw_macip_add()` has already `assert` the returned `mac`, the check of its return value makes no sense. And keep setting `mac->flags` inside `zebra_evpn_mac_gw_macip_add()` is more reasonable. So just move the setting `mac->flags` inside `zebra_evpn_mac_gw_macip_add()`. Signed-off-by: anlan_cs <vic.lan@pica8.com>
* zebra: Convert to `struct zebra_mac` as per our internal standardDonald Sharp2021-09-021-27/+28
| | | | | | | We do not use typedef's to talk about structures as per our standard. Fixing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* zebra: Convert to `struct zebra_evpn` as per our internal standardDonald Sharp2021-09-021-30/+29
| | | | | | | We do not use typedef's to talk about structures as per our standard. Fixing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* zebra: use more constMark Stapp2021-07-191-18/+22
| | | | | | | Use const in many more evpn apis, especially for macaddr, ipaddr arguments. Signed-off-by: Mark Stapp <mjs@voltanet.io>
* zebra: give some evpn apis better namesMark Stapp2021-07-191-5/+5
| | | | | | Use more useful names for a few evpn apis. Signed-off-by: Mark Stapp <mjs@voltanet.io>
* zebra: link local MACs to destination port for efficient lacp-bypass processingAnuradha Karuppiah2021-02-241-1/+15
| | | | | | | | | When an ES-bond comes out of bypass FRR needs to flush the local MACs learnt while the bond was in bypass. To do that efficiently local MACs are linked to the dest-access port. This only happens if the access-port is in LACP-bypass or if it is non-ES. Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
* zebra: support for lacp bypass with EVPN MHAnuradha Karuppiah2021-02-241-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Feature overview: ================= A 802.3ad bond can be setup to allow lacp-bypass. This is done to enable servers to pxe boot without a LACP license i.e. allows the bond to go oper up (with a single link) without LACP converging. If an ES-bond is oper-up in an "LACP-bypass" state MH treats it as a non-ES bond. This involves the following special handling - 1. If the bond is in a bypass-state the associated ES is placed in a bypass state. 2. If an ES is in a bypass state - a. DF election is disabled (i.e. assumed DF) b. SPH filter is not installed. 3. MACs learnt via the host bond are advertised with a zero ESI. When the ES moves out of "bypass" the MACs are moved from a zero-ESI to the correct non-zero id. This is treated as a local station move. Implementation: =============== When (a) an ES is detached from a hostbond or (b) an ES-bond goes into LACP bypass zebra deletes all the local macs (with that ES as destination) in the kernel and its local db. BGP re-sends any imported MAC-IP routes that may exist with this ES destination as remote routes i.e. zebra can end up programming a MAC that was perviously local as remote pointing to a VTEP-ECMP group. When an ES is attached to a hostbond or an ES-bond goes LACP-up (out of bypss) zebra again deletes all the local macs in the kernel and its local db. At this point BGP resends any imported MAC-IP routes that may exist with this ES destination as sync routes i.e. zebra can end up programming a MAC that was perviously remote as local pointing to an access port. Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
* zebra: fix problem with SVI MAC not being sent to BGPAnuradha Karuppiah2021-02-191-1/+2
| | | | | | | | | | For MH the SVI MAC is advertised to prevent flooding of ARP replies. But because of a bug the SVI MAC was being added to the zebra database but not sent to bgpd for advertising. Ticket: CM-33329 Signed-off-by: Anuradha Karuppiah <anuradhak@nvidia.com>
* zebra: changes to advertise SVI mac by default if evpn-mh is enabledAnuradha Karuppiah2021-02-191-0/+10
| | | | | | | | | | | | | | | Added support for advertising SVI MAC if EVPN-MH is enabled. In the case of EVPN MH arp replies from an attached server can be sent to the ES-peer. To prevent flooding of the reply the SVI MAC needs to be advertised by default. Note: advertise-svi-ip could have been used as an alternate way to advertise SVI MAC. However that config cannot be turned on if SVI IPs are re-used (which is done to avoid wasting IP addresses in a subnet). Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
* zebra: resolve multiple functions for local MAC deletePat Ruddy2021-02-031-2/+1
| | | | | | | | | | the old VXLAN function for local MAC deletion was still in existence and being called from the VXLAN code whilst the new generic function was not being called at all. Resolve this so the generic function matches the old function and is called exclusively. Signed-off-by: Pat Ruddy <pat@voltanet.io>
* zebra: Create a dump function for mac->flags and use itDonald Sharp2021-01-131-0/+1
| | | | | | | Create a function that can dump the mac->flags in human readable output and convert all debugs to use it. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* zebra: support for slow-failover of local MACs on an ESAnuradha Karuppiah2020-12-011-4/+2
| | | | | | | | | | | | | | | | | | | | | When a local ES flaps there are two modes in which the local MACs are failed over - 1. Fast failover - A backup NHG (ES-peer group) is programmed in the dataplane per-access port. When a local ES flaps the MAC entries are left unaltered i.e. pointing to the down access port. And the dataplane redirects traffic destined to the oper-down access port via the backup NHG. 2. Slow failover - This mode needs to be turned on to allow dataplanes not capable of re-directing traffic. In this mode local MAC entries on a down local ES are re-programmed to point to the ES-peers' NHG. And vice-versa i.e. when the ES comes up the MAC entries are re-programmed with the access port as dest. Fast failover is on by default. Slow failover can be enabled via the following config - evpn mh redirect-off Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
* zebra: remove FDB entries before de-activating a L2-NHGAnuradha Karuppiah2020-12-011-1/+2
| | | | | | | | | NHG is activated i.e. programmed in the dataplane only if there are active-VTEPs associated with it. When a NHG is de-activated all the remote-mac entries associated with it need to be removed before the NHG is removed. Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
* zebra: Add uptime to `show evpn mac vni ... detail`Donald Sharp2020-10-261-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add the uptime a mac entry has been in the system. New Output: eva# show evpn mac vni all detail VNI 1000 #MACs (local and remote) 16 MAC: 4e:2d:f3:75:ff:db ESI: 03:44:38:39:ff:ff:01:00:00:02 Intf: hostbond2(10) VLAN: 1000 Sync-info: neigh#: 0 peer-active Local Seq: 0 Remote Seq: 0 Uptime: 00:00:28 Neighbors: No Neighbors MAC: 7a:a4:f2:30:dd:5d ESI: 03:44:38:39:ff:ff:01:00:00:01 Intf: hostbond1(9) VLAN: 1000 Sync-info: neigh#: 0 peer-active Local Seq: 0 Remote Seq: 0 Uptime: 00:00:28 Neighbors: No Neighbors MAC: 66:9e:d7:3a:f1:f1 Remote VTEP: 192.168.100.18 Sync-info: neigh#: 0 Local Seq: 0 Remote Seq: 0 Uptime: 00:00:26 Neighbors: 45.0.0.5 Active fe80::649e:d7ff:fe3a:f1f1 Active MAC: 26:f1:bd:5f:e1:77 Remote ES: 03:44:38:39:ff:ff:02:00:00:02 Sync-info: neigh#: 0 Local Seq: 0 Remote Seq: 0 Uptime: 00:00:23 Neighbors: No Neighbors MAC: 16:80:eb:c4:43:6d ESI: 03:44:38:39:ff:ff:01:00:00:01 Intf: hostbond1(9) VLAN: 1000 Sync-info: neigh#: 0 peer-active Local Seq: 0 Remote Seq: 0 Uptime: 00:00:28 Neighbors: No Neighbors MAC: 00:00:00:00:00:22 Remote ES: 03:44:38:39:ff:ff:02:00:00:02 Sync-info: neigh#: 0 Local Seq: 0 Remote Seq: 0 Uptime: 00:00:26 Neighbors: No Neighbors Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* zebra: add ns_id attribute to mac structurePhilippe Guibert2020-08-181-0/+1
| | | | | | | | | this information is necessary for local information, because the interface associated to the mac address is stored with its ifindex, and the ifindex may not be enough to get to the right interface when it comes with multiple network namespaces. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
* zebra: extract gateway mac add from zebra_vxlan.cPat Ruddy2020-08-121-0/+3
| | | | | | | extract mac_gateway add code from zevi_gw_macip_add and move it to a new generic function zebra_evpn_mac_gw_macip_add in zebra_evpn_mac.c Signed-off-by: Pat Ruddy <pat@voltanet.io>
* zebra: extract local mac del from zebra_vxlan.cPat Ruddy2020-08-121-0/+3
| | | | | | | extract generic local mac add code from zebra_vxlan_local_mac_del into a new function zebra_evpn_del_local_mac in zebra_evpn_mac.c Signed-off-by: Pat Ruddy <pat@voltanet.io>
* zebra: extract local mac add code from vxlanPat Ruddy2020-08-121-14/+7
| | | | | | | | extract the local mac add code from zebra_vxlan_local_mac_add_update and create a new generic local mac add function zebra_evpn_add_update_local_mac Signed-off-by: Pat Ruddy <pat@voltanet.io>
* zebra: split out mac_add code from process_remote_macip_addPat Ruddy2020-08-121-2/+8
| | | | | | | | Move MAC add code from process_remote_macip_add in zebra_vxlan.c to a generic function process_mac_remote_macip_add in zebra_evpn_mac.c Signed-off-by: Pat Ruddy <pat@voltanet.io>
* zebra: extract evpn mac functions from zebra_vxlan.cPat Ruddy2020-08-121-0/+258
Move MAC dB specific functions to zebra_evpn_mac.c Signed-off-by: Pat Ruddy <pat@voltanet.io>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-19 12:38:02 +0100