EVPN Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 24.1.x, 24.2.x, 24.3.x
Bias-Free Language
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This chapter describes how to configure EVPN MPLS Multi-Homing on EVPN E-LAN and EVPN E-Line services.
EVPN MPLS Multi-Homing
Table 1. Feature History Table
Feature Name
Release Information
Feature Description
EVPN MPLS Multi-Homing on 8212-48FH-M, 8711-32FH-M, 88-LC1-52Y8H-EM, and 88-LC1-12TH24FH-E
Release 24.3.1
The EVPN MPLS multi-homing is now supported on these fixed systems and line cards:
8212-48FH-M
8711-32FH-M
88-LC1-52Y8H-EM
88-LC1-12TH24FH-E
EVPN MPLS Multi-Homing
Release 24.2.11
EVPN multi-homing enables you to connect a customer edge (CE) device to two or more provider edge (PE) devices to provide
redundant connectivity.
When the primary link fails, the standby PE device becomes active immediately, ensuring no traffic disruption and providing
faster convergence.
This feature is supported only on routers with the 88-LC1-36EH line cards.
In EVPN MPLS multi-homing mode, you can connect a customer edge (CE) device to more than one provider edge (PE) device to
ensure redundant connectivity. The redundant PE device ensures that there is no traffic disruption when there is a network
failure.
The following types of multi-homing are supported:
Single-Active - In this mode, only a single PE among a group of PEs attached to the particular Ethernet-Segment is allowed
to forward traffic to and from that Ethernet Segment.
All-Active - In this mode, all PEs attached to the particular Ethernet-Segment is allowed to forward traffic to and from that
Ethernet Segment.
Port-Active - In this mode, only the PE which is in the active mode sends and receives the traffic. This mode supports single-active
redundancy load balancing at the port-level or the interface-level.
Single-Flow-Active - In this mode, only the PE that first advertises the host MAC address in a VLAN forwards the traffic in
a specific flow.
EVPN E-LAN Single-Active Multi-Homing
In EVPN E-LAN single-active mode, the PE nodes locally connected to an Ethernet Segment load balance traffic to and from the
Ethernet Segment based on EVPN service instance (EVI). Within an EVPN service instance, only one PE forwards traffic to and
from the Ethernet Segment.
In a ring topology, only one of the PEs, which is the active PE, sends and receives the traffic to prevent a traffic loop.
When the link to the active PE fails, the traffic switches over to the standby PE. Traffic switchover takes a while because
the standby PE has to learn the MAC addresses of the connected hosts. There is a traffic loss until the traffic switch over
happens.
EVPN E-LAN single-active multi-homing enables you to connect a customer edge (CE) device to more than one provider edge (PE)
device with redundant connectivity. In single-active mode, only a single PE among a group of PEs attached to the particular
Ethernet segment is allowed to forward traffic to and from that Ethernet segment. In this mode, only the PE that first advertises
the host MAC address in a VLAN forwards the traffic in a specific flow.
When the primary link fails, the traffic quickly switches to the standby PE that learns the MAC address from the originated
path, thereby providing fast convergence. This also enables load balancing of traffic to and from the Ethernet Segment based
on EVPN service instance (EVI).
The following image illustrates an EVPN E-LAN single-active multi-homing topology.
Figure 1. EVPN E-LAN Single-Active Multi-Homing
In this topology, CE1 is multi-homed to PE1 and PE2. The PE1 and PE2 are connected to PE3 through MPLS core. CE2 is connected
to PE3 through an Ethernet interface bundle. PE1 and PE2 advertise Type 4 routes to elect the designated forwarder (DF). The
non-DF blocks the traffic in both the directions in single-active mode. In this example, PE1 is elected as the DF and PE2
is the non-DF.
The traffic flow from CE1 and CE2 happens as follows:
CE1 sends an address resolution protocol (ARP) broadcast request to both PE1 and PE2.
As PE1 is the designated forwarder for the EVI, PE1 forwards the ARP request from CE1.
PE2, the non-DF, drops the traffic from CE1.
All the traffic is sent through PE1. PE2 remains as a standby device and traffic is not sent through PE2.
PE1 advertises MAC routes to PE3 and PE3 always sends and receives traffic through PE1.
PE3 sends the traffic to CE2 over Ethernet interface bundle.
When there is a link failure and the active PE1 goes down, PE2 becomes active to continue with the traffic flow.
Configure EVPN Single-Active Multi-homing
Perform the following configuration on PE1, PE2, and PE3.
Configure BGP session and MPLS Label Distribution Protocol (LDP) to enable EVPN.
Configure EVPN EVI parameters and advertisement of MAC routes.
Enter the bundle interface mode and configure the Ethernet segment identifier (ESI) for the interface.
Ensure that you configure the same ESI on all the PEs.
Enable single-active mode by using the load-balancing-mode single-active command.
/* Configure Bridge Domain and EVI on PE1, PE2, and PE3 */
Router(config)# l2vpn
Router(config-l2vpn)# bridge group bg1
Router(config-l2vpn-bg)# bridge-domain bd1
Router(config-l2vpn-bg-bd)# interface Bundle-Ether1.1
Router(config-l2vpn-bg-bd-ac)# evi 1
Router(config-l2vpn-bg-bd-ac)# root
Router(config)# l2vpn
Router(config-l2vpn)# bridge group bg2
Router(config-l2vpn-bg)# bridge-domain bd2
Router(config-l2vpn-bg-bd)# interface Bundle-Ether1.2
Router(config-l2vpn-bg-bd-ac)# evi 2
/* Configure EVPN EVI and advertise the MAC routes on PE1, PE2, and PE3 */
Router(config)# evpn
Router(config-evpn)# evi 1
Router(config-evpn-evi)# advertise-mac
Router(config-evpn-evi)# exit
Router(config-evpn)# evi 2
Router(config-evpn-evi)# advertise-mac
/* Configure the same ESI on all the PE Routers */
Router(config)# evpn
Router(config-evpn)# interface Bundle-Ether1
Router(config-evpn-ac)# ethernet-segment
Router(config-evpn-ac-es)# identifier type 0 40.00.00.00.00.00.00.00.01
Router(config-evpn-ac-es)# load-balancing-mode single-active
Router(config-evpn-ac-es)# commit
/* Configuration on all the PEs */
l2vpn
bridge group bg1
bridge-domain bd1
interface Bundle-Ether1.1
!
evi 1
!
!
!
bridge group bg2
bridge-domain bd2
interface Bundle-Ether1.2
!
evi 2
!
!
!
!
evpn
evi 1
advertise-mac
!
!
evi 2
advertise-mac
!
!
interface Bundle-Ether1
ethernet-segment
identifier type 0 40.00.00.00.00.00.00.00.01
load-balancing-mode single-active
!
!
!
Verification
The following output shows configuration of single-active mode on PE1:
Router#show evpn ethernet-segment interface BE1 carving detail
Ethernet Segment Id Interface Nexthops
------------------------ ---------------------------------- --------------------
0040.0000.0000.0000.0001 BE1 54.54.54.54
55.55.55.55
ES to BGP Gates : Ready
ES to L2FIB Gates : Ready
Main port :
Interface name : Bundle-Ether1
Interface MAC : 008d.9c38.7205
IfHandle : 0x0f00003c
State : Up
Redundancy : Not Defined
ESI ID : 1
ESI type : 0
Value : 0040.0000.0000.0000.0001
ES Import RT : 4000.0000.0000 (from ESI)
Topology :
Operational : MH, Single-active
Configured : Single-active (AApS)
Service Carving : Auto-selection
Multicast : Disabled
Convergence :
Peering Details : 2 Nexthops
54.54.54.54 [MOD:P:00:T]
55.55.55.55 [MOD:P:00:T]
Service Carving Synchronization:
Mode : NONE
Peer Updates :
54.54.54.54 [SCT: N/A]
55.55.55.55 [SCT: 2024-03-12 10:42:30.1710254]
Service Carving Results:
Forwarders : 2
Elected : 1
EVI E : 2
Not Elected : 1
EVI NE : 1
EVPN-VPWS Service Carving Results:
Primary : 0
Backup : 0
Non-DF : 0
MAC Flush msg : STP-TCN
Peering timer : 3 sec [not running]
Recovery timer : 30 sec [not running]
Carving timer : 0 sec [not running]
Revert timer : 0 sec [not running]
HRW Reset timer : 5 sec [not running]
Local SHG label : 24004
Remote SHG labels : 1
24004 : nexthop 55.55.55.55
Access signal mode: Bundle OOS
EVPN E-LAN All-Active Multi-Homing
In all-active multi-homing mode, a device is connected to multiple PEs and all the links actively forward the traffic on that
Ethernet Segment.
Figure 2. EVPN E-LAN All-Active Multi-homing
All-active load-balancing is known as Active/Active per Flow (AApF). In the above topology, identical Ethernet Segment Identifier
is used on both EVPN PEs. PEs are attached to Ethernet Segment using bundle interfaces. In the CE, single bundles are configured
towards two EVPN PEs. In this mode, both PE1 and PE2 can forward the traffic within the same EVI.
Configure EVPN E-LAN All-Active Multi-Homing
Perform the following tasks on both PE1 and PE2.
Configure BGP session and MPLS Label Distribution Protocol (LDP) to enable EVPN.
Configure EVPN EVI parameters and advertisement of MAC routes.
Enter the bundle interface mode and configure the Ethernet segment identifier (ESI) for the interface.
Ensure that you configure the same ESI on all the PEs.
/* Configure Bridge Domain and EVI on PE1 and PE2 */
Router(config)# l2vpn
Router(config-l2vpn)# bridge group bg1
Router(config-l2vpn-bg)# bridge-domain bd1
Router(config-l2vpn-bg-bd)# interface Bundle-Ether11.1
Router(config-l2vpn-bg-bd-ac)# evi 1
Router(config-l2vpn-bg-bd-ac)# root
Router(config)# l2vpn
Router(config-l2vpn)# bridge group bg2
Router(config-l2vpn-bg)# bridge-domain bd2
Router(config-l2vpn-bg-bd)# interface Bundle-Ether11.2
Router(config-l2vpn-bg-bd-ac)# evi 2
/* Configure EVPN EVI and advertise the MAC routes on PE1 and PE2 */
Router(config)# evpn
Router(config-evpn)# evi 1
Router(config-evpn-evi)# advertise-mac
Router(config-evpn-evi)# exit
Router(config-evpn)# evi 2
Router(config-evpn-evi)# advertise-mac
/* Configure the same ESI on all the PE Routers */
Router(config)# evpn
Router(config-evpn)# interface Bundle-Ether11
Router(config-evpn-ac)# ethernet-segment
Router(config-evpn-ac-es)# identifier type 0 40.00.00.00.00.00.00.00.01
Router(config-evpn-ac-es)# commit
/* Configuration on all the PEs */
l2vpn
bridge group bg1
bridge-domain bd1
interface Bundle-Ether11.1
!
evi 1
!
!
!
bridge group bg2
bridge-domain bd2
interface Bundle-Ether11.2
!
evi 2
!
!
!
!
evpn
evi 1
advertise-mac
!
!
evi 2
advertise-mac
!
!
interface Bundle-Ether11
ethernet-segment
identifier type 0 40.00.00.00.00.00.00.00.01
!
!
!
Verification
The following output shows configuration of all-active mode:
Router#show evpn ethernet-segment int Bundle-Ether 11 carving detail
Ethernet Segment Id Interface Nexthops
------------------------ ---------------------------------- --------------------
0040.0000.0000.0000.0001 BE11 54.54.54.54
55.55.55.55
ES to BGP Gates : Ready
ES to L2FIB Gates : Ready
Main port :
Interface name : Bundle-Ether11
Interface MAC : 008d.9c38.7205
IfHandle : 0x0f00001c
State : Up
Redundancy : Not Defined
ESI ID : 1
ESI type : 0
Value : 0040.0000.0000.0000.0001
ES Import RT : 4000.0000.0000 (from ESI)
Topology :
Operational : MH, All-active
Configured : All-active (AApF) (default)
Service Carving : Auto-selection
Multicast : Disabled
Convergence :
Peering Details : 2 Nexthops
54.54.54.54 [MOD:P:00:T]
55.55.55.55 [MOD:P:00:T]
Service Carving Synchronization:
Mode : NONE
Peer Updates :
54.54.54.54 [SCT: N/A]
55.55.55.55 [SCT: N/A]
Service Carving Results:
Forwarders : 2
Elected : 1
EVI E : 2
Not Elected : 1
EVI NE : 1
EVPN-VPWS Service Carving Results:
Primary : 0
Backup : 0
Non-DF : 0
MAC Flush msg : STP-TCN
Peering timer : 3 sec [not running]
Recovery timer : 30 sec [not running]
Carving timer : 0 sec [not running]
Revert timer : 0 sec [not running]
HRW Reset timer : 5 sec [not running]
Local SHG label : 24004
Remote SHG labels : 1
24004 : nexthop 55.55.55.55
Access signal mode: Bundle OOS
EVPN E-LAN Port-Active Multi-Homing
The EVPN E-LAN port-active multi-homing feature supports single-active redundancy load balancing at the port-level or the
interface-level. You can use this feature when you want to forward the traffic to a specific interface, rather than have a
per-flow load balancing across multiple PE routers. This feature provides a faster convergence during a link failure. This
feature enables protocol simplification as only one of the physical ports is active at a given time. You can enable this feature
only on bundle interfaces.
EVPN E-LAN port-active provides protocol simplification compared to Inter-Chassis Communication Protocol (ICCP), which runs
on top of Label Distribution Protocol (LDP). You can use this feature as an alternative to multi-chassis link aggregation
group (MC-LAG) with ICCP.
Also, you can use this feature when you want certain QoS features to work.
This feature allows one of the PEs to be in active mode and another in the standby mode at the port-level. Only the PE which
is in the active mode sends and receives the traffic. The other PE remains in the standby mode. The PEs use the Designated
Forwarder (DF) election mechanism to determine which PE must be in the active mode and which must be in the standby mode.
You can use either modulo or Highest Random Weight (HRW) algorithm for per port DF election. By default, the modulo algorithm
is used for per port DF election.
Figure 3. EVPN E-LAN Port-Active Multi-Homing
Consider a topology where the customer edge device (CE) is multi-homed to provider edge devices, PE1 and PE2. Use single link
aggregation at the CE. Only one of the two interfaces is in the forwarding state, and the other interface is in the standby
state. In this topology, PE2 is in the active mode and PE1 is in the standby mode. Hence, PE2 carries traffic from the CE.
All services on the PE2 interface operate in the active mode. All services on the PE1 operate in the standby mode.
If you remove the port-active configuration on both PE1 and PE2 and then add back the port-active configuration on both the
PEs, PE2 is chosen as an active interface again.
Configure EVPN Port-Active Multi-homing
Perform the following configuration on PE1 and PE2.
Configure BGP session and MPLS Label Distribution Protocol (LDP) to enable EVPN.
Configure EVPN EVI parameters and advertisement of MAC routes.
Enter the bundle interface mode and configure the Ethernet segment identifier (ESI) for the interface.
Ensure that you configure the same ESI on all the PEs.
Enable single-active mode by using the load-balancing-mode port-active command.
/* Configure Bridge Domain and EVI on PE1 and PE2 */
Router(config)# l2vpn
Router(config-l2vpn)# bridge group bg1
Router(config-l2vpn-bg)# bridge-domain bd1
Router(config-l2vpn-bg-bd)# interface Bundle-Ether11.1
Router(config-l2vpn-bg-bd-ac)# evi 1
Router(config-l2vpn-bg-bd-ac)# root
Router(config)# l2vpn
Router(config-l2vpn)# bridge group bg2
Router(config-l2vpn-bg)# bridge-domain bd2
Router(config-l2vpn-bg-bd)# interface Bundle-Ether11.2
Router(config-l2vpn-bg-bd-ac)# evi 2
/* Configure EVPN EVI and advertise the MAC routes on PE1 and PE2 */
Router(config)# evpn
Router(config-evpn)# evi 1
Router(config-evpn-evi)# advertise-mac
Router(config-evpn-evi)# exit
Router(config-evpn)# evi 2
Router(config-evpn-evi)# advertise-mac
/* Configure the same ESI on all the PE Routers */
Router(config)# evpn
Router(config-evpn)# interface Bundle-Ether11
Router(config-evpn-ac)# ethernet-segment
Router(config-evpn-ac-es)# identifier type 0 40.00.00.00.00.00.00.00.01
Router(config-evpn-ac-es)# load-balancing-mode port-active
Router(config-evpn-ac-es)# commit
/* Configuration on all the PEs */
l2vpn
bridge group bg1
bridge-domain bd1
interface Bundle-Ether11.1
!
evi 1
!
!
!
bridge group bg2
bridge-domain bd2
interface Bundle-Ether11.2
!
evi 2
!
!
!
!
evpn
evi 1
advertise-mac
!
!
evi 2
advertise-mac
!
!
interface Bundle-Ether11
ethernet-segment
identifier type 0 40.00.00.00.00.00.00.00.01
load-balancing-mode port-active
!
!
!
Verification
The following output shows configuration of port-active mode:
/* PE2 is in active mode and is Up */
Router# show bundle BE11
Bundle-Ether11
Status: Up
Local links <active/standby/configured>: 1 / 0 / 1
Local bandwidth <effective/available>: 400000000 (400000000) kbps
MAC address (source): 008d.9c38.7205 (Chassis pool)
Inter-chassis link: No
Minimum active links / bandwidth: 1 / 1 kbps
Maximum active links: 64
Wait while timer: 2000 ms
Load balancing:
Link order signaling: Not configured
Hash type: Default
Locality threshold: None
LACP: Operational
Flap suppression timer: Off
Cisco extensions: Disabled
Non-revertive: Disabled
mLACP: Not configured
IPv4 BFD: Not configured
IPv6 BFD: Not configured
Port Device State Port ID B/W, kbps
-------------------- --------------- ----------- -------------- ----------
FH0/0/0/3 Local Active 0x8000, 0x0001 400000000
Link is Active
/* PE1 is in standby mode */
Router#show bundle BE11
Bundle-Ether11
Status: EVPN Hot-Standby
Local links <active/standby/configured>: 0 / 1 / 1
Local bandwidth <effective/available>: 0 (0) kbps
MAC address (source): 003f.ee3b.5a05 (Chassis pool)
Inter-chassis link: No
Minimum active links / bandwidth: 1 / 1 kbps
Maximum active links: 64
Wait while timer: 2000 ms
Load balancing:
Link order signaling: Not configured
Hash type: Default
Locality threshold: None
LACP: Operational
Flap suppression timer: Off
Cisco extensions: Disabled
Non-revertive: Disabled
mLACP: Not configured
IPv4 BFD: Not configured
IPv6 BFD: Not configured
Port Device State Port ID B/W, kbps
-------------------- --------------- ----------- -------------- ----------
FH0/0/0/6 Local Standby 0x8000, 0x0001 400000000
Link is in standby due to bundle out of service state
/* The following output shows port-active mode configuration */
Router#show evpn ethernet-segment int Bundle-Ether 11 carving detail
Ethernet Segment Id Interface Nexthops
------------------------ ---------------------------------- --------------------
0040.0000.0000.0000.0001 BE11 54.54.54.54
55.55.55.55
ES to BGP Gates : Ready
ES to L2FIB Gates : Ready
Main port :
Interface name : Bundle-Ether11
Interface MAC : 008d.9c38.7205
IfHandle : 0x0f00005c
State : Up
Redundancy : Not Defined
ESI ID : 1
ESI type : 0
Value : 0040.0000.0000.0000.0001
ES Import RT : 4000.0000.0000 (from ESI)
Topology :
Operational : MH
Configured : Port-Active
Service Carving : Auto-selection
Multicast : Disabled
Convergence :
Peering Details : 2 Nexthops
54.54.54.54 [MOD:P:00:T]
55.55.55.55 [MOD:P:00:T]
Service Carving Synchronization:
Mode : NTP_SCT
Peer Updates :
54.54.54.54 [SCT: 2024-03-12 10:58:28.1710255]
55.55.55.55 [SCT: 2024-03-12 10:58:47.1710255]
Service Carving Results:
Forwarders : 2
Elected : 2
EVI E : 1, 2
Not Elected : 0
EVPN-VPWS Service Carving Results:
Primary : 0
Backup : 0
Non-DF : 0
MAC Flush msg : STP-TCN
Peering timer : 3 sec [not running]
Recovery timer : 30 sec [not running]
Carving timer : 0 sec [not running]
Revert timer : 0 sec [not running]
HRW Reset timer : 5 sec [not running]
Local SHG label : 24004
Remote SHG labels : 1
24004 : nexthop 55.55.55.55
Access signal mode: Bundle Hot-Standby
EVPN E-LAN Single-Flow-Active Multi-Homing
Table 2. Feature History Table
Feature Name
Release Information
Feature Description
EVPN E-LAN Single-Flow-Active Multi-Homing on 8212-48FH-M, 8711-32FH-M, 88-LC1-52Y8H-EM, and 88-LC1-12TH24FH-E
Release 24.3.1
EVPN E-LAN single-flow-active multi-homing is now supported on these fixed systems and line cards:
8212-48FH-M
8711-32FH-M
88-LC1-52Y8H-EM
88-LC1-12TH24FH-E
EVPN E-LAN Single-Flow-Active Multi-Homing
Release 24.2.11
This feature introduces EVPN E-LAN single-flow-active multi-homing load balancing mode to connect PE devices in an access
network that run Layer 2 access gateway protocols. In this mode, only the PE that first advertises the host MAC address in
a VLAN forwards the traffic in a specific flow. When the primary link fails, the traffic quickly switches to the standby PE
that learns the MAC address from the originated path, thereby providing fast convergence.
The feature introduces the load-balancing-mode command with keyword, single-flow-active.
This feature is supported only on routers with the 88-LC1-36EH line cards.
In a ring topology, only one of the PEs, which is the active PE, sends and receives the traffic to prevent a traffic loop.
When the link to the active PE fails, the traffic switches over to the standby PE. Traffic switchover takes a while because
the standby PE has to learn the MAC addresses of the connected hosts. There’s a traffic loss until the traffic switch over
happens.
The EVPN E-LAN single-flow-active multi-homing mode connects PE devices in an access network, and in the event of active link
failure the switchover happens immediately and reduces the traffic loss.
Both active and standby PEs learn the MAC addresses of the connected host. The PE that learns the MAC address of the host
directly is called the Primary (active) PE. The primary PE advertises the learnt MAC addresses to the peer PE, which is referred
as standby PE. As the standby PE learns the MAC address of the host through the active PE, this learnt path is referred to
as the reoriginated path.
When the primary link fails, the convergence happens fast and the traffic is sent through the standby PE (reoriginated path).
Let us understand how EVPN E-LAN single flow-active mode helps in fast convergence:
In this topology, the access network devices are connected through a ring topology. The access network uses Layer-2 gateway
protocols such as G.8032, MPLS-TP, REP-AG or MSTP-AG to prevent traffic loop due to continuous flooding.
Host 1 is connected to CE1.
CE1 is connected to both PE1 and PE2, thus is multihomed.
PE1 and PE2 are Multihoming devices.
Both PE1 and PE2 is configured with the same non-zero Ethernet Segment ID (ESI) number 0 36.37.00.00.00.00.00.11.00 for the bundle interface to enable multihoming of the host (CE1).
PE1 and PE2 belongs to te same VLAN and hence configured with the same EVPN instance (EVI) 100.
Traffic Flow
Consider a traffic flow from Host 1 to Host 2. The traffic is sent from Host 1 to CE1.
In this ring topology, the link between CE1 to CE2 is in the blocked state; the link between CE1 to CE3 is in the forwarding
state. Hence, CE1 sends the traffic to PE2 through CE3.
PE2 first learns the MAC address of Host1 through CE1. PE2 advertises the learnt MAC address to the peering PE1.
As PE2 has learnt the MAC address directly from Host 1, and acts as an active PE.
The PE which originates the MAC route due to access learning sets the default BGP local preference attribute value to 100.
PE1 learns the MAC address from PE2 and acts as a stand-by PE. As PE1 gets the reoriginated MAC route from PE2, PE1 sets the
BGP local preference attribute value to 80.
The PE that has the higher local preference always sends and receives the traffic. Thus PE1 sends the traffic to PE3. PE3
sends the traffic to Host 2.
Failure Scenario
When the link between CE1 and CE3 is down or when the link between CE3 and PE2 is down, traffic is sent through PE1.
When the link fails, the link CE1-CE2 changes to the forwarding state.
PE1 learns the MAC address of Host 1 directly and advertises the learnt MAC address to PE2.
PE1 sends the traffic to Host 2 through the remote PE3 with a BGP local preference value of 100.
PE3 sends and receives the traffic from PE1 until the access link between CE1 and CE2 changes to the blocked state.
Limitations and Restrictions for EVPN E-LAN Single-Flow-Active Multi-Homing
The EVPN E-LAN single-flow active multi-homing is not supported for EVPN VPWS.
The EVPN E-LAN single-flow-active multi-homing is not supported on the Q100 and Q200 based systems.
Starting from Release 24.1.1, only the G.8032 is supported for EVPN E-LAN single-flow-active multi-homing.
Router#show evpn ethernet-segment interface be 1 detail
Legend:
B - No Forwarders EVPN-enabled,
C - MAC missing (Backbone S-MAC PBB-EVPN / Grouping ES-MAC vES),
RT - ES-Import Route Target missing,
E - ESI missing,
H - Interface handle missing,
I - Name (Interface or Virtual Access) missing,
M - Interface in Down state,
O - BGP End of Download missing,
P - Interface already Access Protected,
Pf - Interface forced single-homed,
R - BGP RID not received,
S - Interface in redundancy standby state,
X - ESI-extracted MAC Conflict
SHG - No local split-horizon-group label allocated
Hp - Interface blocked on peering complete during HA event
Rc - Recovery timer running during peering sequence
Ethernet Segment Id Interface Nexthops
0 36.37.00.00.00.00.00.11.01 BE1 172.16.0.4
172.16.0.5
ES to BGP Gates : Ready
ES to L2FIB Gates : P
Main port :
Interface name : Bundle-Ether1
Interface MAC : b0a6.51e5.00dd
IfHandle : 0x2000802c
State : Up
Redundancy : Not Defined
ESI type : 0
Value : 07.0807.0807.0807.0800
ES Import RT : 0708.0708.0708 (from ESI)
Source MAC : 0000.0000.0000 (N/A)
Topology :
Operational : MH, Single-flow-activeConfigured : Single-flow-active
Service Carving : Auto-selection
Multicast : Disabled
Convergence : MAC-Mobility
Mobility-Flush : Debounce 1 sec, Count 0, Skip 0
: Last n/a
Peering Details : 2 Nexthops
172.16.0.4 [MOD:P:00:T]
172.16.0.5 [MOD:P:00:T]
Service Carving Synchronization:
Mode : NONE
Peer Updates :
172.16.0.4 [SCT: N/A]
172.16.0.5 [SCT: N/A]
Service Carving Results:
Forwarders : 1
Elected : 0Not Elected : 0
EVPN-VPWS Service Carving Results:
Primary : 0
Backup : 0
Non-DF : 0
MAC Flushing mode: STP-TCN
Peering timer : 3 sec [not running]
Recovery timer : 30 sec [not running]
Carving timer : 0 sec [not running]
HRW Reset timer : 5 sec [not running]
Local SHG label : 24007
Remote SHG labels: 1
24010 : nexthop 172.16.0.5
Access signal mode: Bundle OOS (Default)
Router#show l2vpn protection main-interface
Main Interface ID # of subIntf Protected Protect Type
Bundle-Ether1 2 Yes ERP
Instance : 1
State : FORWARDING
Sub-Intf # : 2
Flush # : 6
EVPN E-Line Multi-Homed
The EVPN E-Line feature supports multi-homing capability that enables you to connect a customer edge device to two or more
provider edge (PE) devices to provide load balancing and redundant connectivity. The load balancing is done using equal-cost
multipath (ECMP).
Topology
Figure 4. EVPN E-Line Multi-Homed
In this topology, the CEs and PEs are connected as follows:
CE1 is multi-homed to PE1 and PE2.
CE2 is multi-homed to PE3 and PE4.
PE1 and PE2 advertise an EAD per EVI route per AC to remote PEs which is PE3 and PE4, with the associated MPLS label. The
ES-EAD route is advertised per ES (main interface), and it will not have a label.
PE3 and PE4 advertise an EAD per EVI route per AC to remote PEs, which is PE1 and PE2, with the associated MPLS label.
Consider a traffic flow from CE1 to CE2:
The selection of path is dependent on the CE implementation for forwarding over a LAG.
Traffic is encapsulated at each PE and forwarded to the remote PEs (PE 3 and PE4) through MPLS core.
Selection of the destination PE is established by flow-based load balancing.
PE3 and PE4 send the traffic to CE2. The selection of path from PE3 or PE4 to CE2 is established by flow-based load balancing.
If there is a failure and when the link from CE1 to PE1 goes down, the PE1 withdraws the ES-EAD route; sends a signal to the
remote PEs to switch all the E-Line service instances associated with this multi-homed ES to the backup PE, which is PE2.
Configure EVPN E-Line Single-Active Multi-Homed
This section describes how to configure single-active multi-homed EVPN E-Line.
Configure cross-connect group.
Configure point-to-point (p2p) cross-connect and assign an interface to the cross-connect.
Enable EVPN E-Line endpoint on the p2p cross-connect.
Configure Ethernet segment identifier (ESI) for the interface.
Enable the single-active mode by using the load-balancing-mode single-active command.
/* On PE1 */
!
l2vpn xconnect group xg1
p2p e1_5-6
interface Bundle-Ether10.2
neighbor evpn evi 1 target 5 source 6
!
evpn
interface Bundle-Ether10
ethernet-segment
identifier type 0 00.01.00.ac.ce.55.00.0a.00
load-balancing-mode port-active
!
/* On PE2 */
!
l2vpn xconnect group xg1
p2p e1_5-6
interface Bundle-Ether10.2
neighbor evpn evi 1 target 5 source 6
!
evpn
interface Bundle-Ether10
ethernet-segment
identifier type 0 00.01.00.ac.ce.55.00.0a.00
load-balancing-mode port-active
!
/* On PE3 */
!
l2vpn xconnect group xg1
p2p e1_5-6
interface Bundle-Ether20.1
neighbor evpn evi 1 target 6 source 5
!
evpn
interface Bundle-Ether20
ethernet-segment
identifier type 0 00.01.00.ac.ce.55.00.14.00
load-balancing-mode port-active
!
/* On PE4 */
!
l2vpn xconnect group xg1
p2p e1_5-6
interface Bundle-Ether20.1
neighbor evpn evi 1 target 6 source 5
!
evpn
interface Bundle-Ether20
ethernet-segment
identifier type 0 00.01.00.ac.ce.55.00.14.00
load-balancing-mode port-active
!
EVPN Designated Forwarder Election
Table 3. Feature History Table
Feature Name
Release Information
Feature Description
EVPN Designated Forwarder Election on 8212-48FH-M, 8711-32FH-M, 88-LC1-52Y8H-EM, and 88-LC1-12TH24FH-E
Release 24.3.1
The EVPN Designated Forwarder election is now supported on these fixed systems and line cards:
8212-48FH-M
8711-32FH-M
88-LC1-52Y8H-EM
88-LC1-12TH24FH-E
EVPN Designated Forwarder Election
Release 24.2.11
Designated Forwarder (DF) election enables the access network to control EVPN PE devices by defining the backup path much
before the event of a link failure. During the link failure, the PE node is aware of the next PE that will take over the active
role and this reduces the traffic loss.
DF election supports preference-based and access-driven mechanism.
This feature is supported only on routers with the 88-LC1-36EH line cards.
Designated Forwarder (DF) election enables the access network to control EVPN PE devices by defining the backup path much
before the event of a link failure. During the link failure, the PE node is aware of the next PE that will take over the active
role and this reduces the traffic loss.
You can configure the DF election as preference-based or access driven.
In a preference-based DF election mechanism, the weight decides which PE is the DF at any given time. You can use this method
for topologies where interface failures are revertive. However, for topologies where an access-PE is directly connected to
the core PE, use the access-driven DF election mechanism.
When access PEs are configured in a non-revertive mode, the access-driven DF election mechanism allows the access-PE to choose
which PE is the DF.
Consider an interface in an access network that connects PE nodes with the EVPN PE in the core network. When this interface
fails, there may be a traffic loss for a longer duration. The delay in convergence is because the backup PE is not chosen
before failure occurs.
The EVPN DF Election feature allows the EVPN PE to preprogram a backup PE even before the failure of the interface. In the
event of failure, the PE node will be aware of the next PE that will take over, thereby reducing the convergence time. Use
the preference df weight option for an Ethernet segment identifier (ESI) to set the backup path. By configuring the weight for a PE, you can control
the DF election, thus define the backup path.
Restrictions
The feature is supported only on EVPN PEs in the port-active mode.
The bundle attached to the ethernet segment must be configured with the lacp mode active command.
The LACP mode on command is not supported.
Topology
Let’s understand the feature on how the backup path is precomputed with the following topology.
Figure 5. EVPN DF Election
PE1, PE2, and PE3 are PEs for the EVPN core network.
aPE1, aPE2, and aPE3 are their access PE counterparts and configured in a multichassis link aggregation group (MCLAG) redundancy
group. Only one link among the three is active at any given time. aPE1, aPE2, and aPE3 are in a non-revertive mode.
PE1 is directly connected to aPE1, PE2 to aPE2, and PE3 to aPE3. EVPN VPWS is configured on the PE devices in the core.
All PE devices are attached to the same bundle and shares the same ethernet segment identifier.
PE1, PE2, and PE3 are configured with a weight of 100, 10, and 1 respectively.
Traffic Flow
In this example, consider a traffic flow from a host connected to PE4 to the host connected to the access PE.
Figure 6. Traffic Flow
aPE1-PE1 interface state is up. The aPE2-PE2 and aPE3-PE3 remains in OOS state.
The traffic is sent from PE4 to aPE1 through PE1 as the PE1 is configured with the highest weight of 100.
The highest weight is modified by adding 32768 to the configured weight. For example, the weight of PE1 is 100, 32768 is added
to this weight. Hence, 32868 is advertised to the peer PEs.
The highest weight is advertised as P-bit, which is primary. The next highest weight is advertised as B-bit, which is secondary.
The lowest weight as non-DF (NDF).
When the EVPN PE devices are of same weight, the traffic is sent based on the IP address. Lowest IP address takes the precedence.
Only one PE indicates that the state of the bundle for the Ethernet Segment is up. For all other PEs, the Ethernet Segment
is standby and the bundle is in OOS state.
All PE devices are aware of the associated next hop and weights of their peers.
Failure and Recovery Scenarios
The weights configured on the EVPN PE devices cascade in the same order as the protection mechanism on the access side PEs:
During the network failure, the redundancy ordering for the access PEs is aPE1, aPE2, aPE3.
The weights of PE1 through PE3 are weight of PE1 > weight of PE2 > weight of PE3.
If this ordering is not satisfied, the network will eventually converge, but it will not be as efficient as if the weights
are ordered correctly.
Scenario - 1
Consider a scenario where the aPE1-PE1 interface is down.
When aPE1-PE1 interface is down, the PE1 withdraws the EAD/ES route, and the traffic is sent through the backup path, which
is PE2.
The aPE2-PE2 becomes the primary with a weight of 32778, and aPE3-PE3 becomes the backup. The aPE2-PE2 advertises P-bit to
PE4. aPE3-PE3 advertises the B-bit to PE4.
Scenario - 2
Consider a scenario where aPE2-PE2 interface is also down.
When the aPE2-PE2 interface is also down, the traffic is sent through aPE3-PE3 link. aPE3-PE3 becomes the primary path with
a weight of 32769.
Scenario - 3
When the aPE2-PE2 interface comes up, the aPE3-PE3 link still remains the primary path. aPE2-PE2 interface becomes the backup
path with a weight of 10.
Scenario - 4
When the aPE1-PE1 interface comes up, the aPE3-PE3 link remains the primary path with a weight of 32769. aPE1-PE1 interface
becomes the backup path with a weight of 100. The aPE2-PE2 interface becomes NDF with a weight of 10.
Configure EVPN DF Election
Perform the following tasks to configure access-driven and preference based EVPN DF Election:
Configure EVPN DF election on PE1, PE2, and PE3, with the service carving mode as preference-based and access-driven.
Configure LACP on aPE1, aPE2, and aPE3
Configuration Example
All PE devices are configured with different weights. PE1, PE2, and PE3 are configured with a weight of 100, 10, and 1 respectively.
The bundle attached to the ethernet segment is configured with lacp mode active.
The following output shows configuration of the EVPN DF Election.
Router#show evpn ethernet-segment detail
Ethernet Segment Id Interface Nexthops
------------------------ ---------------------------------- --------------------
0001.0001.0001.1b01.001b BE1 192.168.0.1
192.168.0.3
ES to BGP Gates : Ready
ES to L2FIB Gates : Ready
Main port :
Interface name : Bundle-Ether1
Interface MAC : 02ef.af8d.8008
IfHandle : 0x00004190
State : Up
Redundancy : Active
ESI type : 0
Value : 01.0001.0001.1b01.001b
ES Import RT : 0100.0100.011b (from ESI)
Source MAC : 0000.0000.0000 (N/A)
Topology :
Operational : MH
Configured : Port-Active
Service Carving : Preferential
Multicast : Disabled
Convergence :
Peering Details : 2 Nexthops
192.168.0.1 [PREF:P:d6ce:T] >> Weight in hexadecimal
192.168.0.3 [PREF:P:457]
Service Carving Synchronization:
Mode : NONE
Peer Updates :
Service Carving Results:
Forwarders : 3
Elected : 3
Not Elected : 0
EVPN-VPWS Service Carving Results:
Primary : 1
Backup : 0
Non-DF : 0
MAC Flushing mode : STP-TCN
Peering timer : 3 sec [not running]
Recovery timer : 30 sec [not running]
Carving timer : 0 sec [not running]
Local SHG label : 28384
Remote SHG labels : 0
Access signal mode: Bundle OOS (Default)
Highest Random Weight Mode for EVPN DF Election
The Highest Random Weight (HRW) Mode for EVPN DF Election feature provides optimal load distribution of Designated Forwarder
(DF) election, redundancy, and fast access. It ensures a nondisruptive service for an ES irrespective of the state of a peer
DF.
The DF election is calculated based on the weight. The highest weight becomes the DF and the subsequent weight becomes a backup
DF (BDF). The weight is determined by the mathematical function of EVI, ESI, and the IP address of the server.
DF weight calculation is based on the weight vector:
Wrand(v, Si) = (1103515245((1103515245.Si+12345)XOR
D(v))+12345)(mod 2^31)
where:
Si: IP Address of the server i
v: EVI
D(v): 31 bit digest [CRC-32 of v]
The existing DF election algorithm is based on ordinal value of a modulus calculation, and it comprises of number of peers
and EVI. The DF is determined by the mathematical function of ESI and EVI, which is called “service carving”. This mode of
DF election is described in RFC 7432.
In modulus calculation mode, the algorithm does not perform well when the Ethernet tags are all even or all odd. When the
Ethernet Segment (ES) is multihomed to two PEs, all the VLANs pick only one of the PEs as the DF; one of the PEs does not
get elected at all as the DF. The DF election is not optimal in this mode of operation.
The HRW mode of DF election has the following advantages over modulus mode of DF election:
The DF election for the respective VLANs is equally distributed among the PEs.
When a PE which is neither a DF nor a BDF hosts some VLANs on a given ES, and if the PE goes down, or its connection to the
ES goes down, it does not result in a DF and BDF reassignment to the other PEs. This eliminates computation during the connection
flaps.
It avoids the service disruption that are inherent in the existing modulus based algorithm.
The BDF provides redundant connectivity. The BDF ensures that there is no traffic disruption when a DF fails. When a DF fails,
the BDF becomes the DF.
Configure Highest Random Weight Mode for EVPN DF Election
Perform this task to configure Highest Random Weight Mode for EVPN DF Election feature.
Verify that you have configured HRW mode of DF election.
Router#show evpn ethernet-segment interface bundleEther 23 carving detail
Ethernet Segment Id Interface Nexthops
------------------------ ---------------------------------- --------------------
0011.1111.1111.1111.1111 Gi0/2/0/0 192.168.0.2
192.168.0.3
ES to BGP Gates : Ready
ES to L2FIB Gates : Ready
Main port :
Interface name : GigabitEthernet0/2/0/0
Interface MAC : 02db.c740.ca4e
IfHandle : 0x01000060
State : Up
Redundancy : Not Defined
ESI type : 0
Value : 11.1111.1111.1111.1111
ES Import RT : 0011.0011.0011 (Local)
Source MAC : 0000.0000.0000 (N/A)
Topology :
Operational : MH, Single-active
Configured : Single-active (AApS) (default)
Service Carving : HRW -> Operation mode of carving
Peering Details : 192.168.0.2[HRW:P:00] 192.168.0.3[HRW:P:00] -> Carving capability as advertised by peers
Service Carving Results:
Forwarders : 1
Permanent : 0
Elected : 0
Not Elected : 1
MAC Flushing mode : STP-TCN
Peering timer : 3 sec [not running]
Recovery timer : 30 sec [not running]
Carving timer : 0 sec [not running]
Local SHG label : 28109
Remote SHG labels : 1
24016 : nexthop 192.168.0.3
Virtual Ethernet Segment
Table 4. Feature History Table
Feature Name
Release Information
Feature Description
Virtual Ethernet Segment on 8212-48FH-M, 8711-32FH-M, 88-LC1-52Y8H-EM, and 88-LC1-12TH24FH-E
Release 24.3.1
The Virtual Ethernet Segment is now supported on these fixed systems and line cards:
8212-48FH-M
8711-32FH-M
88-LC1-52Y8H-EM
88-LC1-12TH24FH-E
Virtual Ethernet Segment
Release 24.2.11
A Virtual Ethernet Segment (VES) allows a Customer Edge (CE) device to connect to an EVPN service over an MPLS network, which
can be used for redundancy and load balancing.
This feature is supported only on routers with the 88-LC1-36EH line cards.
Traditionally, multi-homing access to EVPN bridge is through bundle Ethernet connection or a physical Ethernet connection.
A customer edge (CE) is connected to multiple provider edges (PEs) and each CE-PE pair is an Ethernet segment (ES). When
multiple Ethernet segments are made to appear as one common Ethernet segment to the CE device, it is a Virtual Ethernet Segment
(VES). The VES allows a CE to access EVPN bridge through MPLS network. The logical connection between CE and PE is a pseudowire
(PW). You can use VES to access PW and AC sub-interface, which is used for redundancy and load balancing.
Figure 7. Virtual Ethernet Segment (VES)
Consider the topology where EVPN data centers, DCI1 and DCI2 are connected to legacy data centers through access PW on a
single Ethernet segment, which is VES. In the topology, the traffic flow from CE2 reaches the legacy data centers through
EVPN data centers using VES.
Consider a traffic flow from CE2 to PE3, the Legacy Data Center 2.
CE2 sends the traffic to DCI1 or DCI2 through EVPN.
DCI1 and DCI2 are connected to PE3 through access PW on a single Ethernet segment.
DCI1 and DCI2 advertise Type 4 routes, and then perform designated forwarder (DF) election after they discover each other.
One of them becomes a DF and other a non-DF.
The traffic is forwarded through the DF. The non-DF path is in standby mode. DCI1 or DCI2, whichever is the DF, sends the
traffic to PE3.
Consider a traffic flow from CE2 to PE1 and PE2, the Legacy Data Center 1.
CE2 sends the traffic to DCI1 or DCI2 through EVPN.
DCI1 or DCI2 sends the traffic to PE1 and PE2.
DCI1 and DCI2 advertise Type 4 routes, and then perform DF election after they discover each other. One of them becomes a
DF and other a non-DF.
One of them becomes a DF and other a non-DF.
The traffic is forwarded through the DF. The non-DF path is in standby mode. DCI1 or DCI2, whichever is the DF, sends the
traffic to PE1 and PE2.
Configure Virtual Ethernet Segment
The following section describes how to configure access PW that acts as VES.
Configure DCI1 and DCI2 with bridge domain and assign EVI to the bridge domain.
Configure EVPN with virtual ethernet segment on both DCI1 and DCI2.
Configure PE3 with bridge domain and assign the virtual ethernet segments of DC1 and DCI2 as neighbors to the bridge domain.
This section shows access PW running configuration.
/* On DCI1 */
l2vpn
bridge group bg1
bridge-domain bd1
neighbor 70.70.70.70 pw-id 17300001
evi 1
member vni 10001
!
evpn
virtual neighbor 70.70.70.70 pw-id 17300001
ethernet-segment
identifier type 0 12.12.00.00.00.01.00.00.03
bgp route-target 1212.8888.0003
!
timers peering 15
!
/* On DCI2 */
l2vpn
bridge group bg1
bridge-domain bd1
neighbor 70.70.70.70 pw-id 27300001
evi 1
member vni 10001
!
evpn
virtual neighbor 70.70.70.70 pw-id 27300001
ethernet-segment
identifier type 0 12.12.00.00.00.01.00.00.03
bgp route-target 1212.8888.0003
!
timers peering 15
!
/* On PE3 */
!
l2vpn
bridge group bg73
bridge-domain bd73-1
neighbor 10.10.10.10 pw-id 17300001
!
neighbor 20.20.20.20 pw-id 27300001
!
Verification
The following output shows the virtual access PW configuration.
Router# show evpn ethernet-segment
Thu Mar 7 10:56:37.662 UTC
Ethernet Segment Id Interface Nexthops
------------------------ ---------------------------------- --------------------
0012.1200.0000.0100.0003 PW:70.70.70.70,17300001 N/A
RP/0/RP0/CPU0:ios#show evpn ethernet-segment detail
Thu Mar 7 10:56:53.806 UTC
Legend:
B - No Forwarders EVPN-enabled,
C - MAC missing (Backbone S-MAC PBB-EVPN / Grouping ES-MAC vES),
RT - ES-Import Route Target missing,
E - ESI missing,
H - Interface handle missing,
I - Name (Interface or Virtual Access) missing,
M - Interface in Down state,
O - BGP End of Download missing,
P - Interface already Access Protected,
Pf - Interface forced single-homed,
R - BGP RID not received,
S - Interface in redundancy standby state,
X - ESI-extracted MAC Conflict
SHG - No local split-horizon-group label allocated
Hp - Interface blocked on peering complete during HA event
Rc - Recovery timer running during peering sequence
Ethernet Segment Id Interface Nexthops
------------------------ ---------------------------------- --------------------
0012.1200.0000.0100.0003 PW:70.70.70.70,17300001 N/A
ES to BGP Gates : R
ES to L2FIB Gates : Ready
Virtual Access :
Name : PW_70.70.70.70_17300001
State : Peering
Num PW Up : 0
ESI ID : 1
ESI type : 0
Value : 0012.1200.0000.0100.0003
ES Import RT : 1212.8888.0003 (Local)
Source MAC : 0000.0000.0000 (N/A)
Topology :
Operational : SH
Configured : Single-active (AApS) (default)
EVPN Cost-Out
Table 5. Feature History Table
Feature Name
Release Information
Feature Description
EVPN Cost-Out on 8212-48FH-M, 8711-32FH-M, 88-LC1-52Y8H-EM, and 88-LC1-12TH24FH-E
Release 24.3.1
The EVPN Cost-Out is now supported on these fixed systems and line cards:
8212-48FH-M
8711-32FH-M
88-LC1-52Y8H-EM
88-LC1-12TH24FH-E
EVPN Cost-Out
Release 24.2.11
The cost-out node brings down the bundle interfaces on the PE to prepare the node for reload or software upgrade. By costing
out a node, the traffic is steered away from the PE without any traffic disruption. This allows you to manage the network
traffic effectively while reloading or upgrading a node.
This feature is supported only on routers with the 88-LC1-36EH line cards.
EVPN cost-out enables you to control the state of bundle interfaces that are part of an Ethernet segment that have Link Aggregation
Control protocol (LACP) configured. This feature enables you to put a node out of service (OOS) without having to manually
shutdown all the bundles on their provider edge (PE) and prepare the node for reload or software upgrade.
Use the cost-out command to bring down all the bundle interfaces belonging to an Ethernet VPN (EVPN) Ethernet segment on a node. The Ethernet
A-D Ethernet Segment (ES-EAD) routes are withdrawn before shutting down the bundles. The PE signals to the connected customer
edge (CE) device to bring down the corresponding bundle member. This steers away traffic from this PE node without traffic
disruption. The traffic that is bound for the Ethernet segment from the CE is directed to the peer PE in a multi-homing environment.
Note
EVPN cost-out is supported only on manually configured ESIs.
In the following topology, the CE is connected to PE1 and PE2. When you configure the cost-out command on PE1, all the bundle interfaces on the Ethernet segment are brought down. In addition, the corresponding bundle
member is brought down on the CE. Hence, the traffic for this Ethernet segment is now sent to PE2 from the CE.
Figure 8. EVPN Cost-Out
To bring up the node into service, use the no cost-out command. This brings up all the bundle interfaces belonging to EVPN Ethernet segment on the PE and the corresponding bundle
members on the CE.
When the node is in
cost-out state, adding a new bundle Ethernet segment brings that bundle down.
Similarly, removing the bundle Ethernet segment brings that bundle up.
Use the startup-cost-in command to bring up the node into service after the specified time on reload. The node will cost-out when EVPN is initialized
and remain cost-out until the set time. If you execute the no startup-cost-in command while the timer is running, the timer stops and the node is cost-in.
The 'cost-out' configuration always takes precedence over the 'startup-cost-in' timer. So, if you reload with both the configurations,
cost-out state is controlled by the 'cost-out' configuration and the timer is not relevant. Similarly, if you reload with
the startup timer, and configure 'cost-out' while the timer is running, the timer is stopped and OOS state is controlled only
by the 'cost-out' configuration.
If you do a process restart while the startup-cost-in timer is running, the node remains in cost-out state and the timer restarts.
Configure EVPN Cost-Out
The following examples show configuration of cost-out and startup cost-in timer.
/* Configuring cost-out to bring down the node on a PE */
Router# configure
Router(config)# evpn
Router(config-evpn)# cost-out
Router(config-evpn)commit
/* Bringing up the node into service */
Router# configure
Router(config)# evpn
Router(config-evpn)# no cost-out
Router(config-evpn)commit
/* Configuring the timer to bring up the node into service after the specified time on reload */
Router# configure
Router(config)# evpn
Router(config-evpn)# startup-cost-in 6000
Router(config-evpn)commit
The following examples show outputs to verify the cost-out and startup cost-in timer configurations.
/* Verify the node cost-out configuration */
Router# show evpn summary
Fri Apr 7 07:45:22.311 IST
Global Information
-----------------------------
Number of EVIs : 2
Number of Local EAD Entries : 0
Number of Remote EAD Entries : 0
Number of Local MAC Routes : 0
Number of Local MAC Routes : 5
MAC : 5
MAC-IPv4 : 0
MAC-IPv6 : 0
Number of Local ES:Global MAC : 12
Number of Remote MAC Routes : 7
MAC : 7
MAC-IPv4 : 0
MAC-IPv6 : 0
Number of Local IMCAST Routes : 56
Number of Remote IMCAST Routes: 56
Number of Internal Labels : 5
Number of ES Entries : 9
Number of Neighbor Entries : 1
EVPN Router ID : 192.168.0.1
BGP Router ID : ::
BGP ASN : 100
PBB BSA MAC address : 0207.1fee.be00
Global peering timer : 3 seconds
Global recovery timer : 30 seconds
EVPN cost-out : TRUE
startup-cost-in timer : Not configured
/* Verify the no cost-out configuration */
Router# show evpn summary
Fri Apr 7 07:45:22.311 IST
Global Information
-----------------------------
Number of EVIs : 2
Number of Local EAD Entries : 0
Number of Remote EAD Entries : 0
Number of Local MAC Routes : 0
Number of Local MAC Routes : 5
MAC : 5
MAC-IPv4 : 0
MAC-IPv6 : 0
Number of Local ES:Global MAC : 12
Number of Remote MAC Routes : 7
MAC : 7
MAC-IPv4 : 0
MAC-IPv6 : 0
Number of Local IMCAST Routes : 56
Number of Remote IMCAST Routes: 56
Number of Internal Labels : 5
Number of ES Entries : 9
Number of Neighbor Entries : 1
EVPN Router ID : 192.168.0.1
BGP Router ID : ::
BGP ASN : 100
PBB BSA MAC address : 0207.1fee.be00
Global peering timer : 3 seconds
Global recovery timer : 30 seconds
EVPN cost-out : FALSE
startup-cost-in timer : Not configured
/* Verify the startup-cost-in timer configuration */
Router# show evpn summary
Fri Apr 7 07:45:22.311 IST
Global Information
-----------------------------
Number of EVIs : 2
Number of Local EAD Entries : 0
Number of Remote EAD Entries : 0
Number of Local MAC Routes : 0
Number of Local MAC Routes : 5
MAC : 5
MAC-IPv4 : 0
MAC-IPv6 : 0
Number of Local ES:Global MAC : 12
Number of Remote MAC Routes : 7
MAC : 7
MAC-IPv4 : 0
MAC-IPv6 : 0
Number of Local IMCAST Routes : 56
Number of Remote IMCAST Routes: 56
Number of Internal Labels : 5
Number of ES Entries : 9
Number of Neighbor Entries : 1
EVPN Router ID : 192.168.0.1
BGP Router ID : ::
BGP ASN : 100
PBB BSA MAC address : 0207.1fee.be00
Global peering timer : 3 seconds
Global recovery timer : 30 seconds
EVPN node cost-out : TRUE
startup-cost-in timer : 6000
Feedback