Auto-Learn MAC Protect in EVPN
This chapter provides information about Auto-Learn MAC Protect in EVPN.
Topics in this chapter include:
Applicability
This chapter was initially written for SR OS Release 14.0.R5, but the MD-CLI in the current edition is based on SR OS Release 21.2.R1. Auto-Learn MAC Protect (ALMP) is supported for EVPN in SR OS Release 14.0.R1, and later.
Overview
MAC protection is needed in Layer 2 services to safeguard business-critical MAC addresses against the possibility of being learned on the wrong SAP/SDP-binding. When a MAC address is learned on the wrong SAP/SDP-binding, traffic would be diverted from its intended destination. This could be caused by misconfiguration or by a malicious source launching a Denial of Service (DoS) attack. MAC protect can also be used to prevent loops in certain topologies.
Chapter EVPN for VXLAN Tunnels (Layer 2) describes MAC protection for static MAC addresses that are configured on SAPs or spoke-SDPs. The command to configure static MAC addresses in a VPLS service is as follows:
*[ex:configure service vpls "1" fdb static-mac]
A:admin@PE-4# mac ?
[mac-address] <unicast-mac-address-no-zero>
<unicast-mac-address-no-zero> - <xx:xx:xx:xx:xx:xx>
Static MAC address to SAP/SDP-binding or black-hole
Configuring static MAC addresses is not scalable if large numbers of MAC addresses need to be protected. Also, configuring static MAC addresses is not an option when the MAC addresses are unknown. Auto-Learn MAC Protect (ALMP) offers the same protection for learned MAC addresses in services such as EVPN VPLS and EVPN R-VPLS. However, ALMP is not supported for PBB-EVPN.
ALMP can be enabled with the auto-learn-mac-protect command in EVPN with VXLAN or MPLS bindings on the following:
-
SAPs
-
Mesh-SDPs
-
Spoke-SDPs
-
Pseudowire (PW) templates
-
Split Horizon Groups (SHGs)
-
SHGs in PW templates
When enabled, all MAC addresses learned on those objects become protected.
The following commands can be used to enable ALMP on objects in VPLS 1:
configure {
service {
pw-template "PW1" {
fdb {
auto-learn-mac-protect true
}
}
vpls "VPLS 1" {
split-horizon-group "SHG1" {
fdb {
saps {
auto-learn-mac-protect true
}
}
}
spoke-sdp 23:1 {
fdb {
auto-learn-mac-protect true
}
}
mesh-sdp 24:1 {
fdb {
auto-learn-mac-protect true
}
}
sap 1/2/1:1 {
fdb {
auto-learn-mac-protect true
}
}
}
When enabled on an SHG, it is only applicable to the SAPs within the SHG, not to spoke-SDPs. If ALMP is required on spoke-SDPs in the SHG, the parameter must be configured on each spoke-SDP individually. All MAC Source Addresses (SAs) learned on these objects will be protected and advertised with the sticky bit set. The sticky bit indicates that these MAC addresses should be treated as protected on the remote PEs, where these protected MAC addresses are considered to have been learned on the EVPN MPLS/VXLAN destinations. The remote EVPN peers then use the MAC protection functionality in the same way as the local peer to protect the MAC address.
By default, ALMP enables an implicit protected-src-mac-violation-action discard (restrict protected source discard frame (RPS-DF)) on SAPs and spoke/mesh-SDPs. When enabled, frames with a protected MAC SA are discarded if received on objects where they were not learned and protected. This configuration is the default and cannot be configured on objects where MAC addresses are learned, such as SAPs, spoke/mesh-SDPs, and SHGs.
However, protected-src-mac-violation-action discard can optionally be configured on destinations in EVPN MPLS or EVPN VXLAN, where data plane MAC learning is never performed for incoming traffic. The only configurable protected source MAC violation action is discard; it is not an option to bring down the entire EVPN destination. For EVPN MPLS, this configuration is in the BGP EVPN context, as follows:
*[ex:configure service vpls "VPLS 1" bgp-evpn mpls 1 fdb]
A:admin@PE-2# protected-src-mac-violation-action ?
protected-src-mac-violation-action <keyword>
<keyword> - discard
Action when a relearn request for a protected MAC is received
configure {
service {
vpls "VPLS 1" {
bgp-evpn {
mpls 1 {
fdb {
protected-src-mac-violation-action discard
}
}
For EVPN VXLAN, this configuration is in the VXLAN context, as follows:
*[ex:configure service vpls "VPLS 1" vxlan instance 1 fdb]
A:admin@PE-2# protected-src-mac-violation-action ?
protected-src-mac-violation-action <keyword>
<keyword> - discard
Action when a relearn request for a protected MAC is received
configure {
service {
vpls "VPLS 1" {
vxlan {
instance 1 {
vni 1
fdb {
protected-src-mac-violation-action discard
}
}
Instead of discarding the frame, the SAP or spoke/mesh-SDP can be brought operationally down when a frame is received with a protected MAC SA that has not been learned on the object, by configuring protected-src-mac-violation-action sap-oper-down or sdp-bind-oper-down on the object in EVPN services. After the object has been brought down, an operator needs to disable and re-enable the object in order to make it operational again.
The protected source MAC violation action can be configured as sap-oper-down on SAPs and SHGs, or sdp-bind-oper-down on spoke/mesh-SDPs, and PW templates, but not on EVPN MPLS/VXLAN destinations, using following commands:
configure {
service {
pw-template "PW1" {
fdb {
auto-learn-mac-protect true
protected-src-mac-violation-action sdp-bind-oper-down
}
}
pw-template "PW2" {
split-horizon-group {
name "SHG1"
fdb {
saps {
auto-learn-mac-protect true
protected-src-mac-violation-action sap-oper-down
}
}
}
}
vpls "VPLS 1" {
split-horizon-group "SHG1" {
fdb {
saps {
auto-learn-mac-protect true
protected-src-mac-violation-action sap-oper-down
}
}
}
spoke-sdp 23:1 {
fdb {
auto-learn-mac-protect true
protected-src-mac-violation-action sdp-bind-oper-down
}
}
mesh-sdp 24:1 {
fdb {
auto-learn-mac-protect true
protected-src-mac-violation-action sdp-bind-oper-down
}
}
sap 1/2/1:1 {
fdb {
auto-learn-mac-protect true
protected-src-mac-violation-action sap-oper-down
}
}
The configuration of protected-src-mac-violation-action alarm-only is not allowed in BGP-EVPN.
Protection is provided at the point where a MAC address first enters the EVPN part of the network. Therefore, the preference for an auto-learned protected MAC address is higher than that of a MAC address received in a BGP update with the sticky bit set.
The following list shows the MAC learning priority, with the highest priority first:
-
Local MAC address (including AS-MAC without static-black-hole, es-bmac, src-bmac, OAM, and so on)
-
Conditional static MAC address (including AS-MAC with static-black-hole)
-
Auto-learn protected MAC address
-
EVPN MAC address with sticky/static bit set
-
Data plane learned MAC address (regular learning on SAP/SDP-binding)
-
EVPN MAC address without sticky/static bit set
ALMP MAC addresses have a higher priority but do not overwrite EVPN static MAC addresses.
Configuration
Example topology - no LAG shows the example topology with one MTU and three PEs.
-
Cards, MDAs
-
The ports between the PEs are configured as network ports; the other ports are access ports. No LAG is configured initially.
-
IGP (IS-IS is used in this example) between the PEs
-
LDP between the PEs
-
BGP with address family EVPN on the PEs
PE-2 is the BGP route reflector. The BGP configuration on the PEs is similar. The BGP configuration on the clients PE-3 and PE-4 is as follows:
# on PE-3, PE-4:
configure {
router "Base" {
autonomous-system 64500
bgp {
vpn-apply-export true
vpn-apply-import true
rapid-withdrawal true
peer-ip-tracking true
split-horizon true
rapid-update {
evpn true
}
group "internal" {
peer-as 64500
family {
evpn true
}
}
neighbor "192.0.2.2" {
group "internal"
}
}
VPLS 1 is configured on all nodes. Initially, ALMP is disabled. On MTU-1, the VPLS 1 contains three SAPs: one toward CE-10, one toward PE-2, and one toward PE-3.
On PE-2, VPLS 1 is configured with EVPN MPLS and contains a SAP toward CE-20 and a SAP toward MTU-1, as follows:
# on PE-2:
configure {
service {
vpls "VPLS 1" {
admin-state enable
service-id 1
customer "1"
bgp 1 {
}
bgp-evpn {
evi 1
mpls 1 {
admin-state enable
ingress-replication-bum-label true
auto-bind-tunnel {
resolution any
}
}
}
sap 1/2/1:1 {
}
sap 1/2/3:1 {
}
}
On PE-3, VPLS 1 is configured with EVPN MPLS and contains a SAP toward MTU-1, as follows:
# on PE-3:
configure {
service {
vpls "VPLS 1" {
admin-state enable
service-id 1
customer "1"
bgp 1 {
}
bgp-evpn {
evi 1
mpls 1 {
admin-state enable
ingress-replication-bum-label true
auto-bind-tunnel {
resolution any
}
}
}
sap 1/2/3:1 {
}
}
The following use cases will be described in this section:
-
EVPN MPLS without multi-homing.
-
Default behavior: no ALMP on SAPs, no protected MAC addresses
-
No ALMP on SAPs, RPS-DF on EVPN MPLS destinations
-
ALMP and implicit RPS-DF on SAPs.
-
RPS-DF on EVPN MPLS destinations, MAC first learned on PE-2
-
RPS-DF on EVPN MPLS destinations, MAC simultaneously learned on PE-2 and PE-3
-
No RPS-DF on EVPN MPLS destinations, MAC simultaneously learned on PE-2 and PE-3
-
-
ALMP and RPS on SAPs.
-
RPS-DF on EVPN MPLS destinations, MAC first learned on PE-2
-
RPS-DF on EVPN MPLS destinations, MAC simultaneously learned on PE-2 and PE-3
-
No RPS-DF on EVPN MPLS destinations, MAC simultaneously learned on PE-2 and PE-3
-
-
-
EVPN MPLS with ALMP in all-active multi-homing.
-
RPS-DF on SAPs, RPS-DF on EVPN MPLS destinations
-
Default behavior: no protected MAC addresses
The following example is not a recommended configuration because it causes a loop. By default, ALMP is disabled and no static MAC addresses are configured. As described in chapter EVPN for VXLAN Tunnels (Layer 2), duplicate MAC addresses are detected in BGP EVPN and the MAC address will be put in a hold-down state on the EVPN destinations after a configurable threshold is reached. This applies to EVPN-MPLS as well as to EVPN-VXLAN. By default, the maximum number of MAC address moves is five in a time window of 3 minutes.
MAC address learned simultaneously on SAPs on PE-2 and PE-3 shows that the MAC address from CE-10 is learned simultaneously on the SAPs in VPLS 1 on PE-2 and PE-3.
CE-10 sends frames to CE-20 with MAC Destination Address (DA) aa:aa:02:20:20:20. MTU-1 has not learned that MAC DA, so the frames are flooded to PE-2 and PE-3, where they enter the SAPs simultaneously. PE-2 and PE-3 have not learned the MAC DA either, so the frames are flooded to all potential destinations. The frames received on PE-2 will be sent (among others) to PE-3, and vice versa. These frames are forwarded back out of the SAP toward MTU-1. This causes a loop.
Both PEs send a BGP update for the MAC SA aa:aa:01:10:10:10 to the other PEs with no sticky bit set. That MAC SA is learned, but not protected on the destination to the other PE. The stream of frames will cause the learned MAC SA to oscillate between the SAP and EVPN destinations on PE-2 and PE-3, and between the EVPN destinations on PE-4.
After a configurable number of BGP EVPN MAC address moves in a time span (by default, after five MAC address moves in a period of 3 minutes), the MAC address is put in a hold-down state on the EVPN destinations for a specific duration (until the next MAC address duplication detection retry; by default, after 9 minutes).
The following message in log 99 on PE-2 (and also on PE-3) indicates that duplicate MAC addresses have been detected:
77 2021/03/23 09:42:59.410 CET MINOR: SVCMGR #2331 Base
"VPLS Service 1 has MAC(s) detected as duplicates by EVPN mac-duplication detection."
The following shows the settings for EVPN MAC address duplication detection, which are the default. It also lists the detected duplicate MAC addresses of CE-10 and CE-20:
[/]
A:admin@PE-3# show service id 1 bgp-evpn
===============================================================================
BGP EVPN Table
===============================================================================
MAC Advertisement : Enabled Unknown MAC Route : Disabled
CFM MAC Advertise : Disabled
Creation Origin : manual
MAC Dup Detn Moves : 5 MAC Dup Detn Window: 3
MAC Dup Detn Retry : 9 Number of Dup MACs : 2
MAC Dup Detn BH : Disabled
IP Route Advert : Disabled
Sel Mcast Advert : Disabled
EVI : 1
Ing Rep Inc McastAd: Enabled
Accept IVPLS Flush : Disabled
-------------------------------------------------------------------------------
Detected Duplicate MAC Addresses Time Detected
-------------------------------------------------------------------------------
aa:aa:01:10:10:10 03/23/2021 09:42:59
aa:aa:02:20:20:20 03/23/2021 09:42:59
-------------------------------------------------------------------------------
===============================================================================
===============================================================================
BGP EVPN MPLS Information
===============================================================================
Admin Status : Enabled Bgp Instance : 1
Force Vlan Fwding : Disabled
Route NextHop Type : system-ipv4
Control Word : Disabled
Max Ecmp Routes : 1
Entropy Label : Disabled
Default Route Tag : none
Split Horizon Group: (Not Specified)
Ingress Rep BUM Lbl: Enabled
Ingress Ucast Lbl : 524284 Ingress Mcast Lbl : 524283
RestProtSrcMacAct : none
Evpn Mpls Encap : Enabled Evpn MplsoUdp : Disabled
Oper Group :
===============================================================================
===============================================================================
BGP EVPN MPLS Auto Bind Tunnel Information
===============================================================================
Allow-Flex-Algo-Fallback : false
Resolution : any Strict Tnl Tag : false
Max Ecmp Routes : 1
Bgp Instance : 1
Filter Tunnel Types : (Not Specified)
===============================================================================
By default, there is no protected source MAC violation action on the EVPN destinations (RestProtSrcMacAct : none).
The MAC addresses are in a hold-down state on the EVPN destinations and no MAC address moves take place until the next MAC address duplication detection retry after 9 minutes. After 9 minutes, the EVPN MAC address duplication alarm is cleared, but after the next five MAC address moves within a time span of 3 minutes, the alarm is raised again and this threshold is reached soon after the alarm has been cleared.
The MAC addresses of both CEs are learned on the SAP of PE-3 (CE-20's MAC address is also learned on the SAP toward MTU-1), not on the EVPN destinations, because of the MAC address duplication detection and hold-down state in EVPN, as follows:
[/]
A:admin@PE-3# show service id 1 fdb detail
===============================================================================
Forwarding Database, Service 1
===============================================================================
ServId MAC Source-Identifier Type Last Change
Transport:Tnl-Id Age
-------------------------------------------------------------------------------
1 aa:aa:01:10:10:10 sap:1/2/3:1 L/0 03/23/21 09:42:59
1 aa:aa:02:20:20:20 sap:1/2/3:1 L/0 03/23/21 09:42:59
-------------------------------------------------------------------------------
No. of MAC Entries: 2
-------------------------------------------------------------------------------
Legend: L=Learned O=Oam P=Protected-MAC C=Conditional S=Static Lf=Leaf
===============================================================================
A similar output can be shown for PE-2.
Both PE-2 and PE-3 learn the MAC addresses locally and send BGP EVPN MAC address route updates to their BGP peers. PE-3 received the following BGP EVPN MAC address routes from PE-2, with the MAC address mobility sequence number representing the number of MAC address moves:
[/]
A:admin@PE-3# show router bgp routes evpn mac
===============================================================================
BGP Router ID:192.0.2.3 AS:64500 Local AS:64500
===============================================================================
Legend -
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
l - leaked, x - stale, > - best, b - backup, p - purge
Origin codes : i - IGP, e - EGP, ? - incomplete
===============================================================================
BGP EVPN MAC Routes
===============================================================================
Flag Route Dist. MacAddr ESI
Tag Mac Mobility Label1
Ip Address
NextHop
-------------------------------------------------------------------------------
u*>i 192.0.2.2:1 aa:aa:01:10:10:10 ESI-0
0 Seq:4 LABEL 524284
n/a
192.0.2.2
u*>i 192.0.2.2:1 aa:aa:02:20:20:20 ESI-0
0 Seq:4 LABEL 524284
n/a
192.0.2.2
-------------------------------------------------------------------------------
Routes : 2
===============================================================================
PE-3 does not use these BGP EVPN MAC address routes in its FDB, because locally learned MAC addresses are preferred.
The remote PE (PE-4) received the following BGP EVPN MAC routes from PE-2 and PE-3:
[/]
A:admin@PE-4# show router bgp routes evpn mac
===============================================================================
BGP Router ID:192.0.2.4 AS:64500 Local AS:64500
===============================================================================
Legend -
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
l - leaked, x - stale, > - best, b - backup, p - purge
Origin codes : i - IGP, e - EGP, ? - incomplete
===============================================================================
BGP EVPN MAC Routes
===============================================================================
Flag Route Dist. MacAddr ESI
Tag Mac Mobility Label1
Ip Address
NextHop
-------------------------------------------------------------------------------
u*>i 192.0.2.2:1 aa:aa:01:10:10:10 ESI-0
0 Seq:4 LABEL 524284
n/a
192.0.2.2
u*>i 192.0.2.2:1 aa:aa:02:20:20:20 ESI-0
0 Seq:4 LABEL 524284
n/a
192.0.2.2
u*>i 192.0.2.3:1 aa:aa:01:10:10:10 ESI-0
0 Seq:3 LABEL 524284
n/a
192.0.2.3
u*>i 192.0.2.3:1 aa:aa:02:20:20:20 ESI-0
0 Seq:5 LABEL 524284
n/a
192.0.2.3
-------------------------------------------------------------------------------
Routes : 4
===============================================================================
In the preceding output, MAC aa:aa:01:10:10:10 is learned from BGP peer 192.0.2.3 with MAC mobility sequence number 3, and from BGP peer 192.0.2.2 with sequence number 4. MAC aa:aa:02:20:20:20 is learned from BGP peer 192.0.2.2 with sequence number 4 and from BGP peer 192.0.2.3 with sequence number 5. The FDB for VPLS 1 on PE-4 contains the MAC addresses learned from BGP EVPN MAC updates with the highest MAC mobility sequence number, as follows:
[/]
A:admin@PE-4# show service id 1 fdb detail
===============================================================================
Forwarding Database, Service 1
===============================================================================
ServId MAC Source-Identifier Type Last Change
Transport:Tnl-Id Age
-------------------------------------------------------------------------------
1 aa:aa:01:10:10:10 mpls: Evpn 03/23/21 09:42:59
192.0.2.2:524284
ldp:65537
1 aa:aa:02:20:20:20 mpls: Evpn 03/23/21 09:42:59
192.0.2.3:524284
ldp:65538
-------------------------------------------------------------------------------
No. of MAC Entries: 2
-------------------------------------------------------------------------------
Legend: L=Learned O=Oam P=Protected-MAC C=Conditional S=Static Lf=Leaf
===============================================================================
VPLS 1 on MTU-1 does not have EVPN configured and no MAC address duplication detection mechanism implemented. The MAC address from CE-10 is last learned on the SAP toward PE-2 (it might equally have been the SAP toward PE-3) instead of the SAP toward CE-10, resulting from the loop, as follows:
[/]
A:admin@MTU-1# show service id 1 fdb detail
===============================================================================
Forwarding Database, Service 1
===============================================================================
ServId MAC Source-Identifier Type Last Change
Transport:Tnl-Id Age
-------------------------------------------------------------------------------
1 aa:aa:01:10:10:10 sap:1/1/4:1 L/0 03/23/21 09:45:56
1 aa:aa:02:20:20:20 sap:1/1/3:1 L/0 03/23/21 09:42:59
-------------------------------------------------------------------------------
No. of MAC Entries: 2
-------------------------------------------------------------------------------
Legend: L=Learned O=Oam P=Protected-MAC C=Conditional S=Static Lf=Leaf
===============================================================================
No ALMP on SAPs, RPS-DF on EVPN destinations
When there are no protected MAC addresses (ALMP is disabled and no static MAC addresses are configured), the behavior is as described earlier. RPS-DF discards frames with protected MAC addresses that were not learned on the object, but there are no protected MAC addresses, because ALMP is not configured. RPS-DF does not discard frames with MAC SAs that are not protected.
RPS-DF is enabled on EVPN destinations on all PEs, as follows:
# on PE-2, PE-3, PE-4:
configure {
service {
vpls "VPLS 1" {
bgp-evpn {
mpls 1 {
fdb {
protected-src-mac-violation-action discard
}
}
}
The state of RPS is now "discard-frame" instead of "none", as follows:
[/]
A:admin@PE-3# show service id 1 bgp-evpn | match RestProtSrcMacAct
RestProtSrcMacAct : Discard-frame
It is also allowed to configure RPS (protected-src-mac-violation-action sap-oper-down) on the SAPs, but that does not change the behavior when ALMP is disabled and there are no protected MAC addresses. RPS will not bring down a SAP after receiving a frame with an unprotected MAC SA.
ALMP and implicit RPS-DF on SAPs
ALMP is enabled on the SAPs in PE-2 as follows:
# on PE-2:
configure {
service {
vpls "VPLS 1" {
sap 1/2/1:1 { # SAP toward CE-20
fdb {
auto-learn-mac-protect true
}
}
sap 1/2/3:1 { # SAP toward MTU-1
fdb {
auto-learn-mac-protect true
}
}
The configuration is similar on PE-3.
The following shows that ALMP is enabled on the SAP and that the default RPS-DF is used:
[/]
A:admin@PE-2# show service id 1 sap 1/2/3:1 detail
===============================================================================
Service Access Points(SAP)
===============================================================================
Service Id : 1
SAP : 1/2/3:1 Encap : q-tag
Description : (Not Specified)
Admin State : Up Oper State : Up
Flags : None
---snip---
Restr MacUnpr Dst : Disabled
Auto Learn Mac Prot: Enabled
ALMP Exclude List : <none>
RestMacProtSrc Act : none (oper: Discard-frame)
---snip---
ALMP and RPS-DF on SAPs, RPS-DF on EVPN MPLS destinations, MAC first learned on PE-2
Initially, the SAP on PE-3 is disabled to ensure that the MAC address will first be learned on PE-2, then on PE-3, as follows:
# on PE-3:
configure {
service {
vpls "VPLS 1" {
sap 1/2/3:1 { # SAP toward MTU-1
admin-state disable
}
Each learned MAC address on the SAPs on PE-2 will be protected; therefore, a BGP update with the static/sticky bit set will be sent to the BGP EVPN peers. In this example, the MAC aa:aa:01:10:10:10 of CE-10 is learned first on SAP 1/2/3:1 on PE-2, and MAC aa:aa:02:20:20:20 is learned on SAP 1/2/1:1 on PE-2. Consequently, PE-2 sends BGP updates with the static/sticky bit set to PE-3 for both MAC aa:aa:01:10:10:10 and MAC aa:aa:02:20:20:20, as follows:
95 2021/03/23 09:55:45.486 CET MINOR: DEBUG #2001 Base Peer 1: 192.0.2.3
"Peer 1: 192.0.2.3: UPDATE
Peer 1: 192.0.2.3 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 89
Flag: 0x90 Type: 14 Len: 44 Multiprotocol Reachable NLRI:
Address Family EVPN
NextHop len 4 NextHop 192.0.2.2
Type: EVPN-MAC Len: 33 RD: 192.0.2.2:1 ESI: ESI-0, tag: 0, mac len: 48
mac: aa:aa:01:10:10:10, IP len: 0, IP: NULL, label1: 8388544
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 16 Len: 24 Extended Community:
target:64500:1
bgp-tunnel-encap:MPLS
mac-mobility:Seq:0/Static
"
97 2021/03/23 09:55:45.486 CET MINOR: DEBUG #2001 Base Peer 1: 192.0.2.3
"Peer 1: 192.0.2.3: UPDATE
Peer 1: 192.0.2.3 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 89
Flag: 0x90 Type: 14 Len: 44 Multiprotocol Reachable NLRI:
Address Family EVPN
NextHop len 4 NextHop 192.0.2.2
Type: EVPN-MAC Len: 33 RD: 192.0.2.2:1 ESI: ESI-0, tag: 0, mac len: 48
mac: aa:aa:02:20:20:20, IP len: 0, IP: NULL, label1: 8388544
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 16 Len: 24 Extended Community:
target:64500:1
bgp-tunnel-encap:MPLS
mac-mobility:Seq:0/Static
"
The MPLS label is label1 in the BGP update divided by 16 (24), as follows:
PE-2 sends similar BGP EVPN updates to peer PE-4.
After these BGP EVPN updates have been sent to PE-3 (and PE-4), the SAP on PE-3 is enabled again, as follows:
# on PE-3:
configure {
service {
vpls "VPLS 1" {
sap 1/2/3:1 { # SAP toward MTU-1
admin-state enable
}
The MAC addresses in the FDB on PE-2, where these MAC addresses are learned, get the indication "L" for learned and "P" for protected MAC address, as follows:
[/]
A:admin@PE-2# show service id 1 fdb detail
===============================================================================
Forwarding Database, Service 1
===============================================================================
ServId MAC Source-Identifier Type Last Change
Transport:Tnl-Id Age
-------------------------------------------------------------------------------
1 aa:aa:01:10:10:10 sap:1/2/3:1 LP/60 03/23/21 09:55:45
1 aa:aa:02:20:20:20 sap:1/2/1:1 LP/60 03/23/21 09:55:45
-------------------------------------------------------------------------------
No. of MAC Entries: 2
-------------------------------------------------------------------------------
Legend: L=Learned O=Oam P=Protected-MAC C=Conditional S=Static Lf=Leaf
===============================================================================
The MAC addresses in the FDB on PE-3 are learned from the BGP EVPN updates and get the indication "S" for static (sticky bit) and "P" for protected MAC address, as follows
[/]
A:admin@PE-3# show service id 1 fdb detail
===============================================================================
Forwarding Database, Service 1
===============================================================================
ServId MAC Source-Identifier Type Last Change
Transport:Tnl-Id Age
-------------------------------------------------------------------------------
1 aa:aa:01:10:10:10 mpls: EvpnS:P 03/23/21 09:55:45
192.0.2.2:524284
ldp:65537
1 aa:aa:02:20:20:20 mpls: EvpnS:P 03/23/21 09:55:45
192.0.2.2:524284
ldp:65537
-------------------------------------------------------------------------------
No. of MAC Entries: 2
-------------------------------------------------------------------------------
Legend: L=Learned O=Oam P=Protected-MAC C=Conditional S=Static Lf=Leaf
===============================================================================
The FDB on the remote PE (PE-4) looks similar, as follows:
[/]
A:admin@PE-4# show service id 1 fdb detail
===============================================================================
Forwarding Database, Service 1
===============================================================================
ServId MAC Source-Identifier Type Last Change
Transport:Tnl-Id Age
-------------------------------------------------------------------------------
1 aa:aa:01:10:10:10 mpls: EvpnS:P 03/23/21 09:55:45
192.0.2.2:524284
ldp:65537
1 aa:aa:02:20:20:20 mpls: EvpnS:P 03/23/21 09:55:45
192.0.2.2:524284
ldp:65537
-------------------------------------------------------------------------------
No. of MAC Entries: 2
-------------------------------------------------------------------------------
Legend: L=Learned O=Oam P=Protected-MAC C=Conditional S=Static Lf=Leaf
===============================================================================
The BGP EVPN MAC address routes on PE-3 have MAC address mobility equal to "Static", as follows:
[/]
A:admin@PE-3# show router bgp routes evpn mac
===============================================================================
BGP Router ID:192.0.2.3 AS:64500 Local AS:64500
===============================================================================
Legend -
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
l - leaked, x - stale, > - best, b - backup, p - purge
Origin codes : i - IGP, e - EGP, ? - incomplete
===============================================================================
BGP EVPN MAC Routes
===============================================================================
Flag Route Dist. MacAddr ESI
Tag Mac Mobility Label1
Ip Address
NextHop
-------------------------------------------------------------------------------
u*>i 192.0.2.2:1 aa:aa:01:10:10:10 ESI-0
0 Static LABEL 524284
n/a
192.0.2.2
u*>i 192.0.2.2:1 aa:aa:02:20:20:20 ESI-0
0 Static LABEL 524284
n/a
192.0.2.2
-------------------------------------------------------------------------------
Routes : 2
===============================================================================
The BGP EVPN MAC routes on PE-4 are similar.
When a stream of frames with MAC SA aa:aa:01:10:10:10 enters the SAP on PE-3, these frames will be dropped by this SAP because of the implicit RPS-DF behavior in the SAP for protected MAC addresses, as shown in Default RPS-DF on SAPs - MAC learned and protected on SAP on PE-2.
Because the MAC address was protected on the SAP on PE-2 and the BGP EVPN MAC route update had been received by PE-3 before any frame was received with this MAC SA, there will be no temporary loop. The frames with the protected MAC SA will be discarded at the SAP on PE-3, not on the EVPN MPLS destination on PE-2. In this case, there is no need to configure RPS-DF on the EVPN MPLS destinations, but it will make a difference when the MAC address is learned on both SAPs simultaneously.
ALMP and RPS-DF on SAPs, RPS-DF on EVPN MPLS destinations, MAC simultaneously learned on PE-2 and PE-3
In the preceding example, the MAC addresses of CE-10 and CE-20 were first learned and protected on PE-2 and received on PE-3's SAP after the BGP update with static/sticky bit was received by PE-3. However, when the MAC address of CE-10 is learned simultaneously on both PEs, for example, because the MAC DA aa:aa:02:20:20:20 is unknown, there is a temporary loop until the MAC addresses are protected. Initially, the frames enter a SAP, are forwarded to the EVPN peer, and forwarded out of the remote SAP.
After the MAC addresses are learned and protected on the SAPs on both PEs, new frames received on a SAP with the protected MAC address will be sent to the other PE. However, they will be discarded due to RPS-DF on destination, as shown in MAC learned and protected simultaneously on PEs - RPS-DF on EVPN endpoints, because the destination PE has that same MAC address protected on its local SAP. This prevents a loop. BGP updates with the static/sticky bit set are sent to the BGP EVPN peer, but the locally learned and protected MAC address is preferred to the MAC address in a BGP update. Therefore, the FDB contains the locally learned MAC address aa:aa:01:10:10:10, not the BGP EVPN MAC address update for MAC address aa:aa:01:10:10:10.
The MAC addresses of the CEs are cleared from the FDBs on all nodes, as follows:
clear service id 1 fdb mac aa:aa:01:10:10:10
clear service id 1 fdb mac aa:aa:02:20:20:20
This clear command for the FDB only works for auto-learned MAC addresses, not for BGP EVPN MAC address updates. BGP EVPN MAC address withdraw updates need to be sent. In this example, BGP is configured with rapid-update evpn, as shown previously.
When traffic is sent from CE-10 to CE-20, MAC address aa:aa:01:10:10:10 of CE-10 is learned simultaneously on SAP 1/2/3:1 in PE-2 and PE-3 and protected on both SAPs. MAC address aa:aa:02:20:20:20 is, in this case, first learned via MAC address learning on PE-2 and advertised via a BGP EVPN MAC address route update. However, it might happen that it was learned and protected on the SAP on PE-3 first, before the MAC address was learned and protected on PE-2 and the BGP EVPN MAC address route update sent by PE-2 was received at PE-3. In the latter case, both MAC address aa:aa:01:10:10:10 and MAC address aa:aa:02:20:20:20 are learned and protected on the SAPs on both PE-2 and PE-3, and RPS-DF on the EVPN-MPLS destinations prevents loops.
However, in the present case, MAC address aa:aa:02:20:20:20 is only protected on the SAP on PE-2, because PE-3 received the EVPN MAC address update before it received a frame with MAC SA aa:aa:02:20:20:20. Therefore, the SAP on PE-3 will discard any frames with MAC SA aa:aa:02:20:20:20.
The FDB for VPLS 1 on PE-2 shows that both MAC addresses are learned locally and protected, as follows:
[/]
A:admin@PE-2# show service id 1 fdb detail
===============================================================================
Forwarding Database, Service 1
===============================================================================
ServId MAC Source-Identifier Type Last Change
Transport:Tnl-Id Age
-------------------------------------------------------------------------------
1 aa:aa:01:10:10:10 sap:1/2/3:1 LP/0 03/23/21 09:59:44
1 aa:aa:02:20:20:20 sap:1/2/1:1 LP/0 03/23/21 09:59:44
-------------------------------------------------------------------------------
No. of MAC Entries: 2
-------------------------------------------------------------------------------
Legend: L=Learned O=Oam P=Protected-MAC C=Conditional S=Static Lf=Leaf
===============================================================================
The FDB for VPLS 1 on PE-3 shows that MAC address aa:aa:01:10:10:10 is learned and protected locally, but MAC address aa:aa:02:20:20:20 is protected on PE-2, which has been advertised by PE-2 in a BGP EVPN MAC update, as follows:
[/]
A:admin@PE-3# show service id 1 fdb detail
===============================================================================
Forwarding Database, Service 1
===============================================================================
ServId MAC Source-Identifier Type Last Change
Transport:Tnl-Id Age
-------------------------------------------------------------------------------
1 aa:aa:01:10:10:10 sap:1/2/3:1 LP/0 03/23/21 09:59:44
1 aa:aa:02:20:20:20 mpls: EvpnS:P 03/23/21 09:59:44
192.0.2.2:524284
ldp:65537
-------------------------------------------------------------------------------
No. of MAC Entries: 2
-------------------------------------------------------------------------------
Legend: L=Learned O=Oam P=Protected-MAC C=Conditional S=Static Lf=Leaf
===============================================================================
Both PE-2 and PE-3 send BGP EVPN MAC updates to their BGP peers for each locally learned and protected MAC address. The following BGP EVPN MAC update is sent by PE-2 to PE-3 for MAC address aa:aa:01:10:10:10:
# on PE-2:
103 2021/03/23 09:59:44.284 CET MINOR: DEBUG #2001 Base Peer 1: 192.0.2.3
"Peer 1: 192.0.2.3: UPDATE
Peer 1: 192.0.2.3 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 89
Flag: 0x90 Type: 14 Len: 44 Multiprotocol Reachable NLRI:
Address Family EVPN
NextHop len 4 NextHop 192.0.2.2
Type: EVPN-MAC Len: 33 RD: 192.0.2.2:1 ESI: ESI-0, tag: 0, mac len: 48
mac: aa:aa:01:10:10:10, IP len: 0, IP: NULL, label1: 8388544
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 16 Len: 24 Extended Community:
target:64500:1
bgp-tunnel-encap:MPLS
mac-mobility:Seq:0/Static
"
Similar BGP EVPN updates are sent to the remote PE (PE-4). The FDB for VPLS 1 on PE-4 only contains entries learned from BGP EVPN updates, as follows:
[/]
A:admin@PE-4# show service id 1 fdb detail
===============================================================================
Forwarding Database, Service 1
===============================================================================
ServId MAC Source-Identifier Type Last Change
Transport:Tnl-Id Age
-------------------------------------------------------------------------------
1 aa:aa:01:10:10:10 mpls: EvpnS:P 03/23/21 09:59:44
192.0.2.2:524284
ldp:65537
1 aa:aa:02:20:20:20 mpls: EvpnS:P 03/23/21 09:59:44
192.0.2.2:524284
ldp:65537
-------------------------------------------------------------------------------
No. of MAC Entries: 2
-------------------------------------------------------------------------------
Legend: L=Learned O=Oam P=Protected-MAC C=Conditional S=Static Lf=Leaf
===============================================================================
PE-4 received BGP EVPN MAC address route updates from PE-2 and PE-3, but only installs the MAC address routes to PE-2 in its FDB, based on the lowest next-hop IP of the EVPN NLRI (192.0.2.2).
ALMP and RPS-DF on SAPs, no RPS-DF on EVPN MPLS destinations, MAC simultaneously learned on PE-2 and PE-3
RPS-DF is disabled on the EVPN MPLS destinations on the PEs, as follows:
# on PE-2, PE-3, PE-4:
configure {
service {
vpls "VPLS 1" {
bgp-evpn {
mpls 1 {
fdb {
delete protected-src-mac-violation-action
}
}
When a frame is received at SAP 1/2/3:1 on PE-3 with protected MAC SA aa:aa:01:10:10:10, it is not dropped by the SAP, because this MAC SA has been learned and protected on this SAP on PE-3. The frame is forwarded to PE-2 where it will not be discarded by the EVPN MPLS destination because RPS-DF is disabled. The frame will be forwarded to other objects in the VPLS in PE-2. For BUM traffic, there will be a loop, because all frames will be flooded to all objects in VPLS 1 on PE-2, including the SAP toward MTU-1.
ALMP and RPS on SAPs
When ALMP is enabled on an object, the default behavior is that frames with a protected MAC SA are discarded (RPS-DF). However, it is possible to configure RPS with sap-oper-down (or sdp-bind-oper-down), in this case on the SAPs on PE-2 and PE-3, as follows:
# on PE-2, PE-3:
configure {
service {
vpls "VPLS 1" {
sap 1/2/3:1 {
fdb {
protected-src-mac-violation-action sap-oper-down
}
}
Instead of discarding frames with MAC SAs that are protected on another object or node, the entire object (here: SAP) can be brought operationally down after a frame has been received with a MAC SA that is protected on another node.
The RPS configuration on the SAP can be shown as follows. The SAP has not been brought down yet.
[/]
A:admin@PE-2# show service id 1 sap "1/2/3:1" detail
===============================================================================
Service Access Points(SAP)
===============================================================================
Service Id : 1
SAP : 1/2/3:1 Encap : q-tag
Description : (Not Specified)
Admin State : Up Oper State : Up
Flags : None
---snip---
Restr MacUnpr Dst : Disabled
Auto Learn Mac Prot: Enabled
ALMP Exclude List : <none>
RestMacProtSrc Act : SAP-oper-down
---snip---
The RestMacProtSrc Act parameter is set to SAP-oper-down, meaning that RPS is configured, which causes the system to bring down the SAP when a duplicate MAC address is received that is protected on another object or node. When a SAP is brought down because of this, the RxProtSrcMAC flag will be raised and can be shown in the detailed SAP show output.
ALMP and RPS on SAPs, RPS-DF on EVPN MPLS destinations, MAC first learned on PE-2
RPS-DF is enabled on the EVPN MPLS destinations on the PEs, as follows:
# on PE-2, PE-3, PE-4:
configure {
service {
vpls "VPLS 1" {
bgp-evpn {
mpls 1 {
fdb {
protected-src-mac-violation-action discard
}
}
To simulate a scenario where the MAC addresses are first learned on PE-2, the SAP on PE-3 is disabled until the BGP EVPN MAC route updates are sent, as follows:
# on PE-3:
configure {
service {
vpls "VPLS 1" {
sap 1/2/3:1 {
admin-state disable
}
The FDBs are cleared on the nodes, as follows:
clear service id 1 fdb mac aa:aa:01:10:10:10
clear service id 1 fdb mac aa:aa:02:20:20:20
Traffic is sent between CE-10 and CE-20, and the MAC addresses are learned and protected on the SAP on PE-2, as follows:
[/]
A:admin@PE-2# show service id 1 fdb detail
===============================================================================
Forwarding Database, Service 1
===============================================================================
ServId MAC Source-Identifier Type Last Change
Transport:Tnl-Id Age
-------------------------------------------------------------------------------
1 aa:aa:01:10:10:10 sap:1/2/3:1 LP/0 03/23/21 10:04:09
1 aa:aa:02:20:20:20 sap:1/2/1:1 LP/0 03/23/21 10:04:09
-------------------------------------------------------------------------------
No. of MAC Entries: 2
-------------------------------------------------------------------------------
Legend: L=Learned O=Oam P=Protected-MAC C=Conditional S=Static Lf=Leaf
===============================================================================
No MAC learning took place on the SAP on PE-3, and the FDB contains the MAC addresses from the BGP EVPN updates, as follows:
[/]
A:admin@PE-3# show service id 1 fdb detail
===============================================================================
Forwarding Database, Service 1
===============================================================================
ServId MAC Source-Identifier Type Last Change
Transport:Tnl-Id Age
-------------------------------------------------------------------------------
1 aa:aa:01:10:10:10 mpls: EvpnS:P 03/23/21 10:04:09
192.0.2.2:524284
ldp:65537
1 aa:aa:02:20:20:20 mpls: EvpnS:P 03/23/21 10:04:09
192.0.2.2:524284
ldp:65537
-------------------------------------------------------------------------------
No. of MAC Entries: 2
-------------------------------------------------------------------------------
Legend: L=Learned O=Oam P=Protected-MAC C=Conditional S=Static Lf=Leaf
===============================================================================
The SAP on PE-3 is enabled, as follows:
# on PE-3:
configure {
service {
vpls "VPLS 1" {
sap 1/2/3:1 {
admin-state enable
}
The operational state of the SAP is up, because no protected MAC addresses have been received yet:
[/]
A:admin@PE-3# show service id 1 sap
===============================================================================
SAP(Summary), Service 1
===============================================================================
PortId SvcId Ing. Ing. Egr. Egr. Adm Opr
QoS Fltr QoS Fltr
-------------------------------------------------------------------------------
1/2/3:1 1 1 none 1 none Up Up
-------------------------------------------------------------------------------
Number of SAPs : 1
-------------------------------------------------------------------------------
===============================================================================
The FDB is cleared for MAC address aa:aa:02:20:20:20 on MTU-1, as follows:
# on MTU-1:
clear service id 1 fdb mac aa:aa:02:20:20:20
Traffic from CE-10 toward the unknown MAC address aa:aa:02:20:20:20 reaches the SAPs on PE-2 and PE-3. When MAC SA aa:aa:01:10:10:10, which is protected on PE-2, is received on PE-3, SAP 1/2/3:1 will be brought operationally down, as shown in MAC learned and protected on SAP on PE-2 - RPS enabled on SAP on PE-3, and the following alarms will be raised in log 99:
89 2021/03/23 10:05:32.247 CET MINOR: SVCMGR #2208 Base
"Protected MAC aa:aa:01:10:10:10 received on SAP 1/2/3:1 in service 1. The SAP will be disabled."
90 2021/03/23 10:05:32.247 CET MINOR: SVCMGR #2203 Base
"Status of SAP 1/2/3:1 in service 1 (customer 1) changed to admin=up oper=down flags=RxProtSrcMac "
The operational state of SAP 1/2/3:1 is now down with flag RxProtSrcMAC, indicating that a duplicate MAC address that is protected on a remote node has been received, as follows:
[/]
A:admin@PE-3# show service id 1 sap 1/2/3:1
===============================================================================
Service Access Points(SAP)
===============================================================================
Service Id : 1
SAP : 1/2/3:1 Encap : q-tag
Description : (Not Specified)
Admin State : Up Oper State : Down
Flags : RxProtSrcMac
Multi Svc Site : None
Last Status Change : 03/23/2021 10:05:32
Last Mgmt Change : 03/23/2021 10:04:55
===============================================================================
The SAP is operationally down and will not come up automatically when the FDB is cleared. To bring the SAP up, an operator needs to disable and re-enable the SAP, as follows:
# on PE-3:
configure exclusive
service {
vpls "VPLS 1" {
sap 1/2/3:1 {
admin-state disable
commit
admin-state enable
commit
[/]
A:admin@PE-3# show service id 1 sap
===============================================================================
SAP(Summary), Service 1
===============================================================================
PortId SvcId Ing. Ing. Egr. Egr. Adm Opr
QoS Fltr QoS Fltr
-------------------------------------------------------------------------------
1/2/3:1 1 1 none 1 none Up Up
-------------------------------------------------------------------------------
Number of SAPs : 1
-------------------------------------------------------------------------------
===============================================================================
ALMP and RPS on SAPs, RPS-DF on EVPN MPLS destinations, MAC simultaneously learned on PE-2 and PE-3
When CE-10 sends traffic to CE-20 and the destination MAC address is unknown, MAC address aa:aa:01:10:10:10 is simultaneously learned and protected on PE-2 and PE-3. No SAP will be brought down when MAC address aa:aa:01:10:10:10 is received on PE-2 or PE-3. This scenario is identical to the one with ALMP and (default) RPS-DF on the SAPs, as shown in RPS enabled on SAPs - RPS-DF on EVPN endpoints, MACs learned simultaneously (which is identical to MAC learned and protected simultaneously on PEs - RPS-DF on EVPN endpoints).
A temporary loop is possible until the MAC address is protected on the SAPs. Initially, the frames enter the SAP, are forwarded to the other PEs, and are forwarded out of the other SAP (unless the MAC address is protected). When the MAC address is protected, any other frames received on the SAP will be sent to the other PE (for example, from PE-3 to PE-2, or vice versa), but they will be discarded by the receiving PE, because RPS-DF is applied on the EVPN destination. BGP EVPN updates are sent to the peer PEs with the sticky bit set. This MAC route will not be installed in the FDB of PE-2 and PE-3 because the MAC address has already been learned locally, which has a higher preference.
The FDB on PE-2 contains locally learned and protected MAC addresses, as follows:
[/]
A:admin@PE-2# show service id 1 fdb detail
===============================================================================
Forwarding Database, Service 1
===============================================================================
ServId MAC Source-Identifier Type Last Change
Transport:Tnl-Id Age
-------------------------------------------------------------------------------
1 aa:aa:01:10:10:10 sap:1/2/3:1 LP/0 03/23/21 10:09:54
1 aa:aa:02:20:20:20 sap:1/2/1:1 LP/0 03/23/21 10:09:54
-------------------------------------------------------------------------------
No. of MAC Entries: 2
-------------------------------------------------------------------------------
Legend: L=Learned O=Oam P=Protected-MAC C=Conditional S=Static Lf=Leaf
===============================================================================
The FDB on PE-3 contains MAC address aa:aa:01:10:10:10 that is locally learned and protected, and MAC address aa:aa:02:20:20:20 that is protected on PE-2, as follows:
[/]
A:admin@PE-3# show service id 1 fdb detail
===============================================================================
Forwarding Database, Service 1
===============================================================================
ServId MAC Source-Identifier Type Last Change
Transport:Tnl-Id Age
-------------------------------------------------------------------------------
1 aa:aa:01:10:10:10 sap:1/2/3:1 LP/0 03/23/21 10:09:54
1 aa:aa:02:20:20:20 mpls: EvpnS:P 03/23/21 10:09:54
192.0.2.2:524284
ldp:65537
-------------------------------------------------------------------------------
No. of MAC Entries: 2
-------------------------------------------------------------------------------
Legend: L=Learned O=Oam P=Protected-MAC C=Conditional S=Static Lf=Leaf
===============================================================================
SAP 1/2/3:1 will not be brought down if frames are received with MAC address aa:aa:01:10:10:10 that is locally learned and protected. However, MAC address aa:aa:02:20:20:20 was learned and protected first on PE-2 and the BGP update was received by PE-3 before the MAC address was received on PE-3. Therefore, MAC address aa:aa:02:20:20:20 will not be learned and protected on PE-3 and, if frames with a MAC SA aa:aa:02:20:20:20 were received on SAP 1/2/3:1 on PE-3, the SAP would be brought down.
ALMP and RPS on SAPs, no RPS-DF on EVPN MPLS destinations, MAC simultaneously learned on PE-2 and PE-3
RPS-DF is disabled on the EVPN MPLS destinations on the PEs, as follows:
# on PE-2, PE-3, PE-4:
configure {
service {
vpls "VPLS 1" {
bgp-evpn {
mpls 1 {
fdb {
delete protected-src-mac-violation-action
}
}
When frames are received at SAP 1/2/3:1 on PE-3 with protected MAC SA aa:aa:01:10:10:10, the SAP is not brought down, because this MAC SA has been learned and protected on this SAP. The frame is forwarded to PE-2 where it will not be discarded by the EVPN MPLS destination because RPS-DF is disabled. It will be forwarded to other objects in the VPLS. For BUM traffic, there will be a loop, because the frames will be flooded to all objects, including the SAP on PE-2 toward MTU-1.
ALMP in all-active multi-homing SAPs
All-active multi-homing for EVPN MPLS is explained in chapter EVPN for MPLS Tunnels. ALMP is not required on all-active multi-homing SAPs. The following example shows that traffic can be dropped when ALMP is enabled on the SAPs and RPS-DF is enabled on the EVPN-MPLS destinations.
ALMP in all-active multi-homing SAPs shows the example topology for all-active multi-homing.
VPLS is configured with SAP lag-1:1 on the three nodes in the topology, as follows:
# on MTU-1, PE-2, PE-3:
configure {
service {
vpls "VPLS 1" {
sap lag-1:1 {
}
The SAPs used in the preceding scenarios are removed.
All-active multi-homing is configured on PE-2 and PE-3, as follows:
# on PE-2, PE-3:
configure {
service {
system {
bgp {
evpn {
ethernet-segment "ESI-12" {
admin-state enable
esi 01:00:00:00:00:23:00:00:00:01
multi-homing-mode all-active
df-election {
es-activation-timer 3
}
association {
lag "lag-1" {
}
}
}
}
ALMP is enabled on the SAPs on PE-2 and PE-3, as follows:
# on PE-2, PE-3:
configure {
service {
vpls "VPLS 1" {
sap lag-1:1 {
fdb {
auto-learn-mac-protect true
}
}
MAC address aa:aa:01:10:10:10 is learned and protected on PE-2 and PE-3, as follows:
[/]
A:admin@PE-2# show service id 1 fdb detail
===============================================================================
Forwarding Database, Service 1
===============================================================================
ServId MAC Source-Identifier Type Last Change
Transport:Tnl-Id Age
-------------------------------------------------------------------------------
1 aa:aa:01:10:10:10 sap:lag-1:1 EvpnS:P 03/23/21 10:11:51
1 aa:aa:02:20:20:20 sap:1/2/1:1 LP/90 03/23/21 10:09:54
-------------------------------------------------------------------------------
No. of MAC Entries: 2
-------------------------------------------------------------------------------
Legend: L=Learned O=Oam P=Protected-MAC C=Conditional S=Static Lf=Leaf
===============================================================================
[/]
A:admin@PE-3# show service id 1 fdb detail
===============================================================================
Forwarding Database, Service 1
===============================================================================
ServId MAC Source-Identifier Type Last Change
Transport:Tnl-Id Age
-------------------------------------------------------------------------------
1 aa:aa:01:10:10:10 sap:lag-1:1 LP/0 03/23/21 10:11:51
1 aa:aa:02:20:20:20 mpls: EvpnS:P 03/23/21 10:09:54
192.0.2.2:524284
ldp:65537
-------------------------------------------------------------------------------
No. of MAC Entries: 2
-------------------------------------------------------------------------------
Legend: L=Learned O=Oam P=Protected-MAC C=Conditional S=Static Lf=Leaf
===============================================================================
ALMP in all-active multi-homing, RPS-DF on EVPN MPLS destinations
ALMP is not recommended in all-active multi-homing because it can cause traffic loss. The following example shows when frames are dropped.
All-active multi-homing - RPS-DF on SAPs and EVPN endpoints shows the example setup with MAC address aa:aa:01:10:10:10 protected on SAP lag-1:1 on both PE-2 and PE-3, and RPS-DF enabled on the EVPN endpoints.
When frames with MAC address aa:aa:01:10:10:10 are sent between PE-2 and PE-3, these frames will be dropped by the EVPN MPLS destination that has RPS-DF enabled.
The traffic flows from CE-10 and CE-20 are hashed over both links in the LAG. When the frames are sent out on MTU-1 on port 1/1/1 toward PE-2, the traffic reaches CE-20, and traffic can be sent back from CE-20 to CE-10 via the direct link between PE-2 and MTU-1. However, when traffic is sent out from MTU-1 on port 1/1/2 toward PE-3, the frames will be forwarded from PE-3 to PE-2, where they will be discarded at the EVPN MPLS destination on PE-2 because of RPS-DF. No traffic flow is possible for frames with the protected MAC SA aa:aa:01:10:10:10 via PE-3 to PE-2, or vice versa. If the MAC address is not protected yet on PE-2, the first few messages get through until the MAC address is protected on PE-2. Both multi-homing PEs, PE-2 and PE-3, protect the MAC address aa:aa:01:10:10:10 on their local all-active SAP. Therefore, PE-2 discards all frames with the MAC SA aa:aa:01:10:10:10 when they are received on the EVPN MPLS destination from the other multi-homing PE (PE-3).
An improved mechanism for EVPN loop protection in all-active multi-homing is black-hole MAC duplication, as described in chapter Black-hole MAC for EVPN Loop Protection.
For single-active multi-homing, this problem does not arise: only the designated forwarder in the Ethernet segment receives and forwards traffic. Therefore, the CE MAC addresses will not be learned and protected on different PEs in the same Ethernet segment.
Conclusion
For security, MAC addresses learned on objects, such as SAPs, spoke/mesh-SDPs, and SHGs in EVPN services can be protected and advertised by BGP with the sticky bit set. By default, frames with a protected MAC SA are discarded if received on objects where the MAC address was not learned. Objects can be configured to be brought operationally down when a frame is received with a protected MAC SA that has not been learned locally.