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

You must stop the evpn topology, and start the mh-evpn topology in containerlab. Make sure to also transfer the config files. All nodes in the mh-evpn topology are XRd.

Load init.cfg

configure
load init.cfg
commit replace
y

SR-MPLS with ISIS is already preconfigured in the core. BGP L2VPN/EVPN peering sessions are already established.

Create an All-Active multi-homed EVPN-VPWS service from CE1 to CE2.
LACP active mode should be used.
Configure 10.0.0.1/24 on CE1 and 10.0.0.2/24 on CE2.

Answer

#CE1
int gi0/0/0/1
 no shut
 bundle id 1 mode active
!
int gi0/0/0/2
 no shut
 bundle id 1 mode active
!
int be1
 ip add 10.0.0.1/24

#CE2
int gi0/0/0/1
 no shut
 bundle id 1 mode active
!
int gi0/0/0/2
 no shut
 bundle id 1 mode active
!
int be1
 ip add 10.0.0.2/24

#PE1, PE2
int gi0/0/0/1
 no shut
 bundle id 1 mode active
!
lacp system mac 0000.0000.0012
!
int be1 l2transport
!
evpn
 interface Bundle-Ether1
  ethernet-segment
   identifier type 0 12.12.12.12.12.12.12.12.12
!
l2vpn xc group VPWS p2p 1
 int be1
 neighbor evpn evi 100 service 100

#PE3, PE4
int gi0/0/0/1
 no shut
 bundle id 1 mode active
!
lacp system mac 0000.0000.0034
!
int be1 l2transport
!
evpn
 interface Bundle-Ether1
  ethernet-segment
   identifier type 0 34.34.34.34.34.34.34.34.34
!
l2vpn xc group VPWS p2p 1
 int be1
 neighbor evpn evi 100 service 100

Explanation

XRv9K has full LACP functionality, allowing us to fully test EVPN multihoming modes. XRv9K only supports EVPN-VPWS, so we will use this to test all multihoming modes. (Note that I originally wrote this lab using XRv9K, but all functionality is also supported in XRd).

The default mode is all-active. All PEs are actively forwarding traffic on the ESI. In EVPN, a DF must be elected to prevent duplication of BUM traffic onto the ESI. But with EVPN-VPWS, there is no bridging, so the DF election doesn’t make any difference with all-active mode.

First we must configure a common LACP SysID on the two PEs to “trick” the CE into believing that it is connected to the same LACP partner on both links.

#PE1, PE2
lacp system mac 0000.0000.0012

Then we configure the bundle and give it the same ESI value on both PEs. Note that you should not use an ESI that contains many zeros in the middle octects. In other multi-homing modes, an ESI Import RT is generated from the ESI, and if these values are all zeros, it breaks the functionality.

#PE1, PE2
evpn
 interface Bundle-Ether1
  ethernet-segment
   identifier type 0 12.12.12.12.12.12.12.12.12

We then simply configure the bundle on each PE and assign it to the VPWS. Note that on every PE, each bundle will only consist of a single member link.

#PE1, PE2
int gi0/0/0/1
 no shut
 bundle id 1 mode active
!
int be1 l2transport
!
l2vpn xc group VPWS p2p 1
 int be1
 neighbor evpn evi 100 service 100

The CE should see the bundle as up, and both links as active:

We can see the details of the ESI using the following show command:

RP/0/RP0/CPU0:PE1#show evpn ethernet-segment detail
Mon Jan  8 16:24:40.669 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.1212.1212.1212.1212 BE1                                10.0.0.1
                                                            10.0.0.2
  ES to BGP Gates   : Ready
  ES to L2FIB Gates : Ready
  Main port         :
     Interface name : Bundle-Ether1
     Interface MAC  : 0050.f003.a0fe
     IfHandle       : 0x0000002c
     State          : Up
     Redundancy     : Not Defined
  ESI type          : 0
     Value          : 12.1212.1212.1212.1212
  ES Import RT      : 1212.1212.1212 (from ESI)
  Source MAC        : 0000.0000.0000 (N/A)
  Topology          :
     Operational    : MH, All-active
     Configured     : All-active (AApF) (default)
  Service Carving   : Auto-selection
     Multicast      : Disabled
  Convergence       :
  Peering Details   : 2 Nexthops
     10.0.0.1 [MOD:P:7fff:T]
     10.0.0.2 [MOD:P:00:T]
  Service Carving Synchronization:
     Mode           : NONE
     Peer Updates   :
                10.0.0.1 [SCT: N/A]
                10.0.0.2 [SCT: N/A]
  Service Carving Results:
     Forwarders     : 1
     Elected        : 0
     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]
  HRW Reset timer   : 5 sec [not running]
  Local SHG label   : 24005
  Remote SHG labels : 1
              24005 : nexthop 10.0.0.2
  Access signal mode: Bundle OOS (Default)

Above we see under Topology that the mode is All-active. The configure AApF means All-Active per Flow. We should see the remote peer under the Peering Details.

We should see that both PEs are activing as Primary for the EVPN-VPWS service:

The remote PEs will load balance traffic to both PE1 and PE2. This is achieved by allocating a local label with an ECMP instruction to forward to each remote PE. In this case, both PEs happened to reserve the same service label for the VPWS (24002):

Traffic between the two CEs should be working. Traffic is hashed among both links in the bundle, and likewise the ingress PE will use hashing to determine which of the two egress PEs to send the traffic to.

This mode of course offers redundancy as well, because if any one link goes down, that PE will remove its type 1 BGP route. For example, let’s shutdown Gi0/0/0/1 on PE1.