EVPN-VPWS Multihomed IOS-XR (Single-Active)

Load multi.service.init.cfg

configure
load multi.service.init.cfg
commit replace
y

The CEs now have two subinterfaces: BE1.10 and BE1.20.

Configure two separate VPWS, one per VLAN.

Configure the PEs so that PE1 and PE3 are active for VLAN 10 and PE2 and PE4 are active for VLAN 20.

Answer

#PE1, PE2
int Gi0/0/0/1
 no shut
 bundle id 1 mode active
!
int be1
 lacp system mac 0000.1111.2222
!
int be1.10 l2transport
 encap dot1q 10
 rewrite ingress tag pop 1 symmetric
!
int be1.20 l2transport
 encap dot1q 20
 rewrite ingress tag pop 1 symmetric
!
l2vpn xconnect group VPWS
 p2p 10
  int be1.10
  neighbor evpn evi 10 service 10
 p2p 20
  int be1.20
  neighbor evpn evi 20 service 20

#PE1
evpn
 interface Bundle-Ether1
  ethernet-segment
   identifier type 0 12.12.12.12.12.12.12.12.12
   load-balancing-mode single-active
   service-carving manual
    primary 10 secondary 20

#PE2
evpn
 interface Bundle-Ether1
  ethernet-segment
   identifier type 0 12.12.12.12.12.12.12.12.12
   load-balancing-mode single-active
   service-carving manual
    primary 20 secondary 10

#PE3, PE4
int Gi0/0/0/1
 no shut
 bundle id 2 mode active
!
int be2
 lacp system mac 0000.3333.4444
!
int be2.10 l2transport
 encap dot1q 10
 rewrite ingress tag pop 1 symmetric
!
int be2.20 l2transport
 encap dot1q 20
 rewrite ingress tag pop 1 symmetric
!
l2vpn xconnect group VPWS
 p2p 10
  int be2.10
  neighbor evpn evi 10 service 10
 p2p 20
  int be2.20
  neighbor evpn evi 20 service 20


#PE3
evpn
 interface Bundle-Ether2
  ethernet-segment
   identifier type 0 34.34.34.34.34.34.34.34.34
   load-balancing-mode single-active
   service-carving manual
    primary 10 secondary 20

#PE4
evpn
 interface Bundle-Ether2
  ethernet-segment
   identifier type 0 34.34.34.34.34.34.34.34.34
   load-balancing-mode single-active
   service-carving manual
    primary 20 secondary 10

Explanation

Single-Active multihoming adds some complexity but has better utilization of link bandwidth. With single-active, all links in the bundle are always up. However, the PEs only forward traffic for a certain set of EVIs (services).

To configure single-active, you simply specify the load-balancing-mode as single-active:

evpn
 interface Bundle-Ether1
  ethernet-segment
   load-balancing-mode single-active

Additionally, we can manually specify which PE should be active for which service using the following configuration. The service is based on the service command in the xconnect, not the EVI number.

evpn
 interface Bundle-Ether1
  ethernet-segment
   service-carving manual
    primary 10 secondary 20

We can see the results of the carving election using the following command. Below we see that PE1 is primary for EVI 10 but backup for EVI 20:

These values are not signaled in a BGP update as we saw previously, when using preference weights with port-active. Instead, this is manually configuring each PE to be primary and backup on a specific list of EVIs.

We see on PE1 that it puts the xconnect using EVI 20 in standby mode:

This posses a potential problem for the CE. The CE always sees both links as active in the bundle when using single-active. Therefore the CE needs to also manually map VLAN 20 to the link towards PE2 as primary. For this reason, traffic may or may not work between CE1 and CE2.

Just as before, the PEs indicate whether they are active or standby for a given VPWS in the BGP update. PE4 sees that PE1 is standby for EVI 20.

Getting traffic to work

To get traffic to work, we need to manually map each VLAN to each link on the CE. One quick way to do it is to just create two separate BE interfaces.

#CE1
no int be1.20
!
int gi0/0/0/2
 bundle id 2 mode active
!
int be2
!
int be2.20
 ipv4 address 10.0.20.1 255.255.255.0
 encapsulation dot1q 20

#CE2
no int be1.20
!
int gi0/0/0/2
 bundle id 2 mode active
!
int be2
!
int be2.20
 ipv4 address 10.0.20.2 255.255.255.0
 encapsulation dot1q 20

Each CE now has two single-interface bundles:

Traffic is now working:

However, we have lost redundancy now. If the CE1-PE1 link goes down, the operator would need to manually move the be1.10 interface to be2.10.

For this reason, I would think that port-active is more widely-deployed than single-active.

Other Options

The hrw mode (highest random weight) is another option for automatic load sharing for the DF election. By default, with the modulo based election, uneven distribution can occur if all EVIs are even or odd. By using HRW mode, the election is based on a more random calculation that should produce more optimal load distribution.

evpn
 interface Bundle-Ether1
  ethernet-segment
   service-carving hrw

There is a new multihoming mode called single-flow-active. This is used with bridged EVPN. The PE that first advertises the host MAC for a VLAN is the one that will forward traffic for that specific flow. This feature helps with fast reconvergence as well. The primary PE learns the MAC through the data plane and advertises it with LP=100. The standby PE learns the MAC through the control plane, and reoriginates it with LP=80. If the standby PE later learns the MAC through the data plane, it advertises it with LP=100.

The use case for this is a ring topology. First, CE1 forwards traffic through CE3 and PE2 originates all MACs:

Then the CE1-CE3 link goes down, and PE1 learns the MAC in the data plane, advertising them with LP=100.

The key idea behind this seems to be that the active PE is driven by receiving the traffic in the data plane, not by DF election. Note that this mode cannot be used with EVPN-VPWS.