Theoretical foundations and architecture
A corporate customer rarely settles for a single link to the provider: the site is attached to two PEs so that a link or PE failure does not stop the L2 service. In classic L2VPNs (VPWS, VPLS) this is solved with a backup pseudowire: the primary PW forwards, the backup stays in standby and takes over based on PW status; on the CE side MC-LAG with ICCP between the PEs is used. Both approaches are active/standby, need manual coordination of the PE pair, and cannot load-balance across both PEs. EVPN (RFC 7432) moves the task into BGP: both PEs announce that they are attached to the same Ethernet Segment (ESI), elect a Designated Forwarder for BUM traffic, and remote PEs see both paths (aliasing) and can balance traffic across them. The lesson compares the three approaches and covers Type 1 and Type 4 routes, all-active and single-active modes, mass withdrawal and the split-horizon label. It assumes you know VPWS, VPLS and Type 2/3 routes from the previous module.
The problem: a customer on two PEs
A customer site is attached to two PEs for two reasons: a failure of one link or PE must not interrupt the service, and maintenance on a PE must not require a downtime window on the customer side. The difficulty in L2VPN is that Ethernet has no path-selection mechanism of its own: two parallel active paths create a loop. Any multihoming scheme therefore has to solve three things at once: which PE forwards traffic to the CE, how to avoid BUM loops, and how to update MAC tables on the other PEs quickly after a failure.
PW redundancy: active/standby
In VPWS and H-VPLS redundancy is built at the pseudowire level. The remote PE (or hub PE) has two PWs: a primary to PE1 and a backup to PE2. PW state is signalled in LDP through the PW Status TLV (RFC 4447, section 5.4.2): the bit field reports that the PW is not forwarding (0x01), a local AC receive fault (0x02) or transmit fault (0x04), with similar codes for the PSN side. RFC 6870 adds Preferential Forwarding Status: the PEs agree which PW is active and which is standby, and a return to the primary PW after recovery is possible (revertive behaviour depends on the implementation and the revert delay). After a switchover MAC tables on remote switches and PEs are stale, so VPLS uses LDP MAC Address Withdrawal (RFC 4762) and a TCN often reaches the CE. Limitations: the backup PW carries no traffic, the scheme is configured per PW or VC ID, and the switchover time is set by the failure detection method (PW status for an AC failure, BFD or LDP keepalive for a PSN failure); it can range from tens of milliseconds to several seconds.
MC-LAG and ICCP
Multi-Chassis LAG lets a CE build one LACP bundle from links to two different chassis. The two PEs look like a single partner to the CE: they use the same LACP system-id and system priority. To agree on state (which port is active, synchronisation of MACs, ARP, IGMP) the PEs run ICCP (RFC 7275, TCP port 646, LDP transport). RFC 7275 defines the general framework, but the actual behaviour (active/standby and active/active modes, synchronisation, split-brain protection) is vendor specific, so MC-LAG between platforms of different vendors is usually avoided. Operational risk: if ICCP is lost (split brain) both PEs may consider themselves active, and without protection mechanisms (for example a dedicated inter-PE link) duplicate traffic is possible.
EVPN: Ethernet Segment and ESI
In EVPN the set of links between a CE and the PEs shared by several PEs is an Ethernet Segment (ES). Its identifier, the ESI, is 10 bytes: the first byte is the type and the other 9 bytes depend on it (RFC 7432, section 5). Type 0 is an arbitrary, manually configured value; type 1 is built from the CE LACP system-id and port key; type 2 comes from the bridge (STP root bridge); type 3 is the system MAC plus a local discriminator; type 4 is the router-id plus a discriminator; type 5 is the AS number plus a discriminator. ESI 0 denotes a single-homed site. All PEs attached to the same CE must use the same ESI on the corresponding interfaces; with all-active the CE must run a LAG and the PEs must present the same LACP system-id (for example configured manually). A mismatch in ESI creates two separate segments, and then neither DF election nor split horizon works.
Type 4 and Type 1 routes
Route Type 4 (Ethernet Segment route) contains an RD, the ESI and the originating PE address. It carries the ES-Import Route Target extended community, whose value is derived from the ESI, so only PEs with this ESI configured locally import the route. This is how PEs discover each other on a segment and start the Designated Forwarder election.
Route Type 1 (Ethernet Auto-Discovery) comes in two forms. Per-ES A-D: the Ethernet Tag ID is MAX-ET (0xFFFFFFFF), one route is announced per segment with the RTs of all EVIs of the segment, and it carries the ESI Label extended community, which contains the Single-Active flag and the split-horizon label. Per-EVI A-D: the Ethernet Tag ID corresponds to the VLAN (0 for a VLAN-based service) and the MPLS label field holds the aliasing label; one route is announced per EVI. Withdrawing the per-ES route signals mass withdrawal: remote PEs immediately invalidate all MACs reachable through this ES and PE.
Designated Forwarder
A DF is elected for each (ES, VLAN/Ethernet Tag) pair. The default RFC 7432 procedure: the PE announces its ES route, starts the DF wait timer (3 seconds by default), then sorts the IP addresses of all PEs of the segment in ascending order and, for a VLAN with number V, selects the PE with ordinal V mod N, where N is the number of PEs. The drawback is that a change in the PE set shifts the VLAN distribution on the others, so RFC 8584 introduces extensibility (the DF Election extended community) and the HRW (Highest Random Weight) algorithm, which changes the DF role only for the VLANs of the failed PE. In single-active the DF is responsible for both receiving and sending segment traffic; in all-active the DF is responsible only for BUM towards the CE, while unicast in both directions is forwarded by all PEs.
