Theoretical foundations and architecture
This lab combines the whole module: CE-A attaches to PE1 and PE2 with one LACP bundle, both PEs announce one Ethernet Segment (ESI) in all-active mode, and the customer subnet 192.168.100.0/24 lives in EVI 100 with an anycast gateway. The second subnet 192.168.200.0/24 is in EVI 200 on PE3. Routing between the EVIs is done by symmetric IRB in the shared IP-VRF TENANT-A: subnet prefixes and hosts are carried by Type 5 and Type 2 routes. You will verify Type 1/2/3/4/5 routes, the Designated Forwarder election and aliasing, then run a failure test: shut a link or PE1 and measure the packet loss. At the end you compare the result with the legacy PW redundancy (active/standby) design, shown as a separate block for comparison only. It assumes that the IGP/LDP underlay and the RR 10.255.0.100 (AS 65000) from the previous labs already work, and that you know ESI, Type 5 and IRB from the lessons of the module.
What exactly you are building
The design combines three mechanisms of the module. Multihoming: CE-A attaches to PE1 and PE2 through one LACP bundle, and both PEs announce an ES with ESI 00:11:22:33:44:55:66:77:88:10 in all-active mode. This yields Type 4 (ES) routes, Type 1 per-ES (ESI label, mass withdrawal) and Type 1 per-EVI (aliasing). The L2 service: EVI 100 connects PE1, PE2 and (if needed) PE3 with Type 2 and Type 3 routes. L3: the IP-VRF TENANT-A with symmetric IRB, where the subnets 192.168.100.0/24 and 192.168.200.0/24 are announced as Type 5 and the hosts as Type 2 with two labels. Traffic CE-A -> CE-B goes through an L3 lookup on the ingress PE (PE1 or PE2), is delivered to PE3 by the IP-VRF label, then gets an L3 lookup on the egress PE3 and L2 delivery into EVI 200.
Preparation and order of activation
The underlay (OSPF/IS-IS, LDP or SR) and iBGP with the RR 10.255.0.100 already work, so on the RR you only need to activate the l2vpn evpn address family and make PE1-PE3 route-reflector clients. Order of activation: first LACP and ESI (without IRB), then the EVI, then the VRF and IRB, then Type 5. After each step verify the corresponding routes: this localises errors. An identical LACP system-id on PE1 and PE2 is set explicitly on Junos; on other platforms check with the LACP status command that it is derived from the ES settings. The RD is unique per PE (10.255.0.X:100) and the RT is shared; the IP-VRF RD is also unique per PE, otherwise the RR picks one of two identical routes and loses the second path.
What each route type shows
Type 4 confirms that PE1 and PE2 found each other via the ES-Import RT. Type 1 per-ES with MAX-ET (0xFFFFFFFF) is responsible for mass withdrawal, per-EVI for aliasing. Type 3 builds the ingress replication lists of the EVI. Type 2 on PE1 and PE2 contains the MAC and IP of CE-A: it is announced first by the PE that the LACP hash sent the CE traffic to, but thanks to the per-EVI A-D the remote PE installs both next hops. Type 5 carries the subnet prefix with the IP-VRF label. If both PEs announce the same prefix (both have an IRB interface), PE3 builds ECMP of two equal-cost next hops; this is exactly what is expected in the TENANT-A table on PE3.
Failure test and convergence
Consider three events. 1) Shutting a port on PE1 (interface shutdown): PE1 detects the link loss locally, withdraws the per-ES A-D and Type 2 routes, and remote PEs immediately remove PE1 from the next hops of the MACs of this ES (mass withdrawal); CE-A redistributes the flows onto the remaining link through LACP. The loss is determined by link/LACP detection time and BGP processing and is usually measured in fractions of a second (it depends on the platform and load). 2) A failure of the whole PE1 (reload or power loss): PE1 cannot withdraw routes; they are removed by the RR after the BGP session drops (hold timer), or earlier when the IGP and next-hop tracking mark the PE1 loopback unreachable, or by BFD for BGP/IGP. Without BFD and fast session detection the loss may last tens of seconds. 3) Link recovery: PE1 re-announces the ES, the DF wait timer starts (3 s by default) and the DF for the VLAN is recomputed; because the DF role returns, a short gap in BUM forwarding is possible.
Comparison with PW redundancy
In the legacy design (given as a separate block) PE3 holds a primary PW to PE1 and a backup PW to PE2, and CE-A attaches to both PEs in active/passive fashion (for example with STP or MC-LAG). One path is active and the other idles; when PE1 fails, PE3 switches to the backup PW on PW status or after failure detection (BFD, LDP keepalive), and MAC tables are flushed by MAC withdrawal. There is no aliasing, no inter-subnet Type 5 routing, every PW is configured by hand, and the number of PWs grows with the number of customers. EVPN gives standard behaviour from one common ES and service configuration, but requires platform support for all route types and consistent LACP/ESI settings.
Common errors and diagnostics
If ping fails, go bottom-up: (1) LACP and ESI; (2) Type 4 and DF; (3) EVI: Type 2 and Type 3; (4) VRF and IRB: the interface is bound to the VRF and the anycast MAC is identical; (5) Type 5 and the IP-VRF RT; (6) MTU and filters. For a loss test use a long ping with a 10 ms interval (rapid ping) and count lost requests: one lost request at a 10 ms interval corresponds roughly to 10 ms of downtime. The result depends on the platform, so record it in the lab report together with the software version.
Architecture Diagram & Topology
RR 10.255.0.100 (AS 65000)
|
+---------------------+---------------------+
| | |
+-----+------+ +-----+-----+ +-----+------+
| PE1 |--------| P1 |---------| PE3 |
| 10.255.0.1 | | 10.255.0.11| | 10.255.0.3 |
+-----+------+ +-----+-----+ +-----+------+
| | |
| +-----+-----+ EVI 200, VLAN 200
| | PE2 | 192.168.200.0/24
| | 10.255.0.2| |
| +-----+-----+ +----+----+
| ae10 / Po10 | ae10 / Po10 | CE-B |
| ESI ...88:10 | | .200.10 |
+-------+ +---------+ +---------+
| |
+--+---+--+
| CE-A | EVI 100, VLAN 100, 192.168.100.0/24
| .100.10 | anycast gateway 192.168.100.1
+---------+
IP-VRF TENANT-A (RT 65000:1100): PE1, PE2, PE3 - symmetric IRB, Type 5Traffic Flow & Label Stack Scheme
1. Bring up the LACP bundle: CE-A to PE1 and PE2 with the same LACP system-id
on both PEs and the same ESI on ae10/Po10.
2. Check Type 4 (ES) and Type 1 (A-D per-ES and per-EVI) routes from PE1 and
PE2; confirm one DF per VLAN and the all-active mode.
3. Verify Type 2 and Type 3 routes in EVI 100 and EVI 200 (MAC, IP, IM).
4. Check Type 5: PE3 receives 192.168.100.0/24 from PE1 and PE2 (two next
hops, ECMP) and PE1/PE2 receive 192.168.200.0/24 from PE3.
5. Ping CE-A -> CE-B (192.168.100.10 -> 192.168.200.10) through the anycast
gateway, then start a long ping with size 1400.
6. Failure test: shut the PE1 link; PE1 withdraws per-ES A-D, PE3 invalidates
PE1 for the ES at once (mass withdrawal), the DF is recomputed.
7. Restore the link, repeat the test with a PE1 reload, and compare with the
legacy active/standby PW redundancy block.State & Parameter Comparison Table
| Element | Value in the lab | What to check |
|---|---|---|
| ES segment | ESI ...88:10, all-active, ae10/Po10 on PE1 and PE2 | Type 4 from both PEs, one DF per VLAN |
| EVI 100 | VLAN 100, RT 65000:100, 192.168.100.0/24, anycast 192.168.100.1 | Type 2 with MAC and IP, Type 3 from PE1/PE2/PE3 |
| EVI 200 | VLAN 200, RT 65000:200, 192.168.200.0/24 on PE3 | Type 2 of the host CE-B |
| IP-VRF TENANT-A | RT 65000:1100, symmetric IRB | Type 5 for both subnets, ECMP on PE1/PE2 |
| Failure test | Shutting the PE1 link and reloading PE1 | Packet loss, mass withdrawal, DF change |
Architectural model and principles
In real service provider networks, MPLS unifies equipment from multiple vendors. Below are practical configuration and operational verification examples across four platforms: Cisco IOS-XE/XR, Huawei VRP, Juniper Junos, and MikroTik RouterOS v7. Pay close attention to syntax nuances and label distribution mechanisms.
Practical Configuration (Cisco, Huawei, Juniper, MikroTik)
Cisco (IOS-XE/XR)
vrf definition TENANT-A
rd 10.255.0.3:1100
address-family ipv4
route-target export 65000:1100
route-target import 65000:1100
exit-address-family
l2vpn evpn instance 200 vlan-based
encapsulation mpls
rd 10.255.0.3:200
route-target export 65000:200
route-target import 65000:200
default-gateway advertise enable
interface GigabitEthernet2
no ip address
service instance 200 ethernet
encapsulation dot1q 200
rewrite ingress tag pop 1 symmetric
bridge-domain 200
member GigabitEthernet2 service-instance 200
member evpn-instance 200
router bgp 65000
neighbor 10.255.0.100 remote-as 65000
neighbor 10.255.0.100 update-source Loopback0
address-family l2vpn evpn
neighbor 10.255.0.100 activate
neighbor 10.255.0.100 send-community both
address-family ipv4 vrf TENANT-A
advertise l2vpn evpn
redistribute connected
interface BDI200
vrf forwarding TENANT-A
ip address 192.168.200.1 255.255.255.0
mac-address 0000.5e00.00c8This is the configuration of PE3 (the single-homed site of CE-B). The VRF TENANT-A with RD 10.255.0.3:1100 and RT 65000:1100 matches the RT of the VRFs on PE1/PE2, so Type 5 routes of the subnet 192.168.100.0/24 are imported here. EVI 200 with RT 65000:200 provides the L2 service for CE-B through bridge-domain 200, and BDI200 in the VRF forms the gateway 192.168.200.1. The advertise l2vpn evpn command in address-family ipv4 vrf turns the connected VRF routes into Type 5; the last lines set the gateway IP and MAC.
