MPLS VPN: Labels, LSPs, Layer 3 and Layer 2 VPNs

01 /Labels and label-switched paths

MPLS inserts a 4-byte shim header between the Layer 2 header and the IP packet: a 20-bit label, 3 bits of traffic class, a bottom-of-stack bit and an 8-bit TTL. A label-switching router forwards by looking up the incoming label, swapping it for the outgoing label and sending the packet out the associated interface. No IP lookup happens in the core. The sequence of swaps from ingress to egress is a label-switched path (LSP). Labels stack: an outer label steers the packet across the core while an inner label tells the egress router which customer it belongs to.

02 /LDP, RSVP-TE and static LSPs

Segment routing has since replaced RSVP-TE in many new builds by encoding the path as a label stack at the ingress, removing per-path state from the core; the forwarding plane is unchanged.

03 /Layer 3 VPNs: VRFs, route distinguishers and route targets

RFC 4364 (originally RFC 2547) defines the BGP/MPLS IP VPN. Each provider edge (PE) router holds a VRF (virtual routing and forwarding table) per attached customer, populated from the customer edge (CE) router by static routes, OSPF or eBGP. Two customers may both use 10.0.0.0/8; to keep those prefixes distinct in one BGP table, each is prefixed with a 64-bit route distinguisher (RD), forming a VPN-IPv4 address.

PEs exchange VPN-IPv4 routes over MP-BGP (multiprotocol BGP), attaching a VPN label and one or more route target (RT) extended communities. RTs are the policy knob: a VRF imports routes carrying RTs it is configured to accept and exports its own routes with its configured RTs. The same import and export RT at every site gives a full mesh; asymmetric RTs build hub-and-spoke or extranet topologies. The P routers in the core run only the IGP and LDP or RSVP; they carry no customer routes at all, which is what lets the design scale to thousands of VPNs.

vrf CUSTOMER-A
 rd 65000:100
 route-target export 65000:100
 route-target import 65000:100
 address-family ipv4
!
router mpls
 mpls-interface ethernet 1/1
 lsp to-pe2
  to 10.255.0.2
  enable
!

show mpls lsp
show mpls ldp neighbor
show ip route vrf CUSTOMER-A

04 /Worked example: MPLS VPN route targets for hub and spoke

A customer has a head office and two branches; branches may reach each other only through the head office firewall. Give each VRF a distinct RD so the same branch prefix can appear as separate VPN-IPv4 routes: 65000:101 for the hub VRF, 65000:102 and 65000:103 for the branches. Route targets carry the policy. The hub exports 65000:1 and imports 65000:2; each spoke exports 65000:2 and imports 65000:1. Branch A never imports 65000:2, so it never learns branch B directly; it learns a default route from the hub and sends everything there.

Label values have reserved meanings under RFC 3032: 0 is IPv4 explicit null, 1 is router alert, 2 is IPv6 explicit null, 3 is implicit null (the penultimate hop pops instead of swapping), and 4 to 15 are reserved, so usable labels start at 16.

pe1# show bgp vpnv4 unicast rd 65000:102 10.2.0.0/24
  Route Distinguisher: 65000:102   Extended Community: RT:65000:2   Label: 24011
$ ping -I 10.2.0.1 10.1.0.1

05 /Layer 2 VPNs: VLL and VPLS

Some customers want Ethernet, not routing. A virtual leased line (VLL, or pseudowire) carries frames from one attachment circuit to one remote circuit over an LSP, point to point; the provider never looks at customer IP. VPLS (virtual private LAN service) extends this to multipoint: PEs form a full mesh of pseudowires per customer and learn MAC addresses across them, so remote sites behave as one VLAN. VPLS scales poorly with MAC count and is being replaced by EVPN, which distributes MAC addresses in BGP instead of learning them by flooding.

06 /Why providers used it and where it stands

Before MPLS, carriers ran separate Frame Relay, ATM and IP networks. MPLS VPNs let one core sell private Layer 3 and Layer 2 services with traffic engineering and QoS, and the enterprise got any-to-any connectivity without managing a mesh of tunnels. Through the 2000s the MPLS Layer 3 VPN became the default enterprise WAN.

SD-WAN has since taken much of that enterprise business: encrypted tunnels over cheap broadband, centrally orchestrated, often cheaper per megabit. MPLS remains in carrier cores, where label forwarding still underpins mobile backhaul, wholesale transport and the underlays beneath the SD-WAN circuits that compete with it. Mixed designs, MPLS for latency-sensitive sites and broadband elsewhere, are the current norm. The core router page covers where the label switching happens.

07 /Foundry heritage: NetIron IMR 640 and MLX

Foundry entered the provider market with NetIron routers. The NetIron IMR 640, around 2003, was a metro and provider-edge router whose service provider guide included a chapter on BGP/MPLS VPNs that operators linked to when comparing configuration models; the accompanying command reference for static LSPs was also frequently cited. The later NetIron XMR and MLX chassis, around 2005 to 2007, carried MPLS Layer 3 VPN, VLL and VPLS into carrier cores and were part of what made the company attractive in the Brocade acquisition. VRF, route distinguisher and route target statements are easy to get subtly wrong in a machine-drafted configuration, since swapped import and export targets still parse cleanly, so put such drafts through a lab review of generated router configs before they reach a PE. The IGP, redundancy and addressing pieces underneath a VPN service are covered in the routing guide index.

08 /MPLS VPN failure modes and expert tips

• Swapped import and export targets. The configuration parses, the sessions come up, and a spoke sees every other spoke. Test with a lab CE route before cutover and diff the RT lines against the design table.
• Core MTU. Two labels add 8 bytes. A core link at 1500 bytes silently drops full-size customer packets; set core interfaces to at least 1508, more where pseudowires add a control word and Ethernet header.

The P routers in the label core carry none of the above state, which is what keeps them simple; the complexity lives on the PE, so demand a second reviewer for VRF changes even when the diff is three lines. On the attachment circuit, agree the customer VLAN handoff in writing: which VLAN IDs are tagged toward the PE and what MTU the customer expects.