MPLS Layer 2 VPNs and IPv6 over MPLS: AToM pseudowires, VPLS, EVPN, 6PE and 6VPE

Layer 2 services over MPLS

Some customers want a plain Ethernet link between two sites, not routing: for example, to extend a VLAN between two data centre halls, or to connect their own routers as if by a long cable. Any Transport over MPLS (AToM) is Cisco's name for point-to-point pseudowires, standardised by the IETF (RFC 4447, later RFC 8077). Ethernet over MPLS (EoMPLS) is the most common type; historically AToM also carried Frame Relay, ATM, PPP and HDLC.

How a pseudowire works

• Each PE has an attachment circuit: a port or VLAN facing the customer.
• The two PEs form a targeted LDP session between their loopbacks and exchange a pseudowire label for a shared virtual circuit ID.
• Frames from the customer get two labels: the inner pseudowire label and the outer transport label to reach the far PE.
• The far PE removes the labels and sends the original frame out of its attachment circuit.

interface GigabitEthernet0/3
 description Customer site A - EoMPLS port mode
 xconnect 10.255.0.9 100 encapsulation mpls
!
show mpls l2transport vc 100 detail

Newer IOS XE releases use an equivalent l2vpn xconnect context syntax. Both PEs must use the same VC ID (100 here), and the MTU must match at both ends or the pseudowire stays down.

Multipoint: VPLS and EVPN

Virtual Private LAN Service (VPLS) joins many sites into one bridged Ethernet segment, with a full mesh of pseudowires between PEs that learn MAC addresses like a switch. It works, but it floods unknown traffic and cannot easily use several links from one site at once. Ethernet VPN (EVPN), RFC 7432, uses MP-BGP to advertise MAC addresses, supports active-active multihoming and is now the preferred choice for new provider and data centre designs, often with VXLAN instead of MPLS in data centres.

IPv6 over an IPv4 MPLS core: 6PE and 6VPE

Upgrading every core router to dual stack takes time. Because core routers forward on labels, they do not need to understand the payload. 6PE (RFC 4798) uses this:

• Only the PEs run IPv6 towards customers.
• PEs exchange IPv6 routes using MP-BGP with labels (neighbor x send-label in the IPv6 address family), with an IPv4-mapped IPv6 next hop pointing at the remote PE's IPv4 loopback.
• Traffic gets an inner IPv6 label and an outer IPv4 LDP transport label, so P routers forward it without any IPv6 knowledge.

router bgp 64500
 neighbor 10.255.0.9 remote-as 64500
 neighbor 10.255.0.9 update-source Loopback0
 address-family ipv6
  neighbor 10.255.0.9 activate
  neighbor 10.255.0.9 send-label

6VPE (RFC 4659) does the same for VPNs: IPv6 routes inside customer VRFs travel in the VPNv6 address family, with RDs and RTs exactly as for VPNv4. One VRF can hold both IPv4 and IPv6 address families.

Real-world example: a university network operator had an IPv4-only MPLS core of older routers that could not be upgraded for two more years, while several member colleges wanted native IPv6. The operator enabled 6VPE on its PE routers only, adding an IPv6 address family to each college's existing VRF. Colleges received IPv6 connectivity within weeks, and when the core was later replaced, IPv6 in the core was added without any change for the colleges.