BGP/MPLS IP Virtual Private Networks (VPNs)
obsoletes
- rfc-2547 — BGP/MPLS VPNs
updated by
- rfc-4577 — OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)
- rfc-4684 — Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)
- rfc-5462 — Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field
Extracted elements (26)
MPLS labels may be assigned at three granularities: one per VRF (requiring a VRF lookup at the egress PE), one per attachment circuit (avoiding the VRF lookup but requiring an ARP lookup), or one per route (allowing path switching without label redistribution). The choice is implementation-specific and transparent to other devices; per-route assignment is expected to be most common.
P (core) routers are intentionally kept free of any per-VPN routing information; only PE routers attached to a given VPN hold its routes. Tunneling labeled MPLS packets across the backbone achieves this, making VPN scalability independent of P router capacity and allowing the total number of supported VPN routes to grow without bound.
Route Reflectors are used in place of a full IBGP mesh among PE routers for scalability. Two partitioning strategies are described: pre-configuring each RR with a static block of Route Targets, or dynamically deriving the RT set from the routes received from client PEs. Both approaches allow VPN Join/Prune operations to be non-disruptive via BGP route refresh.
The peer model (CE peers only with its attached PE; CE routers at different sites never peer with each other) is chosen over an overlay model so that customers have no backbone or virtual backbone to administer. Site-to-site routing follows optimal IGP paths rather than an artificial tunnel topology.
The RD's sole purpose is to allow BGP to carry multiple distinct routes to the same IPv4 prefix; it carries no inherent information about route origin or target VPN membership. Route distribution policy is governed entirely by the Route Target attribute, keeping the two concerns orthogonal and allowing a single route to target multiple VRFs.
The Route Target attribute uses BGP Extended Communities rather than the BGP Communities attribute because BGP Communities provide only a 2-byte numbering space, which is insufficient for globally unique SP-administered identifiers. The Extended Communities format mirrors the type/administrator/assigned-number structure used for RDs.
For Multi-AS option (c), PE routers in different ASes establish multi-hop EBGP sessions to exchange VPN-IPv4 routes directly, while ASBRs distribute labeled /32 PE-address routes between ASes to build an end-to-end label switched path. When PE /32 routes are not propagated to P routers, the ingress PE must push a three-label stack: VPN route label, ASBR-to-egress-PE label, and IGP-next-hop-to-ASBR tunnel label.
When OSPF is used as the PE/CE protocol, the PE appears to the CE as an OSPF Area 0 router; routes learned from the CE are redistributed into BGP as VPN-IPv4 routes with Extended Community attributes preserving the OSPF LSA type. OSPF route tagging is used to prevent routes received from the backbone from being re-injected into it.
When RIP is used as the PE/CE protocol, the CE must not advertise back to any PE a route originally learned from the VPN backbone unless the receiving PE maps it to a VPN-IPv4 route with a different RD than the original. Without this precaution, routing loops can arise in multi-homed site configurations.
A backbone router MUST NOT accept a labeled packet from any adjacent non-backbone device unless (1) the top label was distributed by that backbone router to that device, and (2) using that label will cause the packet to exit the backbone before any lower label or IP header is inspected. The simplest compliant implementation refuses all labeled packets from non-backbone devices.
A PE router should not install a VPN-IPv4 route unless it has at least one VRF whose Import Target matches one of the route's Route Targets. If a new Import Target is later added (VPN Join), the PE must re-acquire previously discarded routes using the BGP route refresh mechanism.
A route whose Site of Origin attribute identifies a particular site MUST NOT be redistributed to any CE at that site, preventing routing loops when a site is multi-homed across multiple PE/CE connections.
If a CE is permitted to attach Route Targets to its routes, the PE MUST filter out all routes carrying RTs the customer is not authorized to use. If the CE attaches unauthorized RTs, the PE MUST remove them before converting the route to a VPN-IPv4 route.
In Multi-AS option (b), VPN-IPv4 routes SHOULD only be accepted on EBGP connections at private peering points as part of a trusted SP arrangement; they should not be distributed to or accepted from the public Internet or untrusted peers. An ASBR should never accept a labeled packet from an EBGP peer unless it has distributed the top label to that peer.
In the Carriers' Carriers scenario, the PE must not distribute the same label to two different CEs unless those CEs are associated with exactly the same set of VRFs or the PE maintains a separate Incoming Label Map per CE. The PE must verify that the top label on any packet received from a CE was actually distributed to that CE.
PE routers and ASBRs that redistribute VPN-IPv4 addresses MUST insert /32 address prefixes for themselves into the backbone IGP routing tables so that MPLS can assign labels for the label switched path to each PE. LDP is required for setting up these paths, though other methods are also permitted.
To ensure interoperability among MPLS-based implementations, all systems MUST support LDP. Downstream Unsolicited mode MUST be supported on interfaces that are neither LC-ATM nor LC-FR; Downstream on Demand mode MUST be supported on LC-ATM and LC-FR interfaces.
A VPN Routing and Forwarding (VRF) table is a per-VPN forwarding table maintained on PE routers. Each PE/CE attachment circuit is associated by configuration with one or more VRFs; incoming packets are looked up in the VRF determined by their ingress attachment circuit.
The Route Target (RT) attribute, encoded as a BGP Extended Community, controls which PE routers receive and install VPN-IPv4 routes. Each VRF has distinct Export Targets (attached to outgoing routes) and Import Targets (matched against incoming routes); a route is eligible for installation in a VRF only if it carries at least one RT that matches an Import Target.
The Site of Origin attribute, encoded as a Route Origin Extended Community, uniquely identifies the set of routes learned from a particular site. It prevents a route from being redistributed back to the originating site via a different PE/CE connection, and is especially important when multiple CEs share the same ASN.
The VPN-IPv4 address family introduces a 12-byte address consisting of an 8-byte Route Distinguisher (RD) followed by a 4-byte IPv4 address. This ensures BGP never treats routes from different VPNs as comparable, even when those VPNs share the same IPv4 address prefix.
When forwarding across the backbone, the ingress PE pushes a two-label MPLS stack: a VPN route label (inner) identifying the egress VRF or attachment circuit, and a tunnel label (outer) routing the packet to the egress PE. The core P routers switch solely on the tunnel label and never inspect VPN routes.
BGP/MPLS VPNs without cryptographic measures are intended to provide security equivalent to a Layer 2 backbone (e.g., Frame Relay): absent misconfiguration, systems in one VPN cannot access systems in another. However, this method does not encrypt data or verify integrity; IPsec or other cryptographic measures must be added when confidentiality or tamper detection is required.
For data-plane VPN isolation, no backbone router should accept a tunneled packet originating from outside the backbone. If MPLS-in-IP or MPLS-in-GRE tunneling is used (non-MPLS backbone), filtering must ensure such encapsulated packets are accepted only if their IP destination address routes them back outside the backbone.
A Route Distinguisher is 8 bytes: a 2-byte type field followed by a 6-byte value. Type 0 encodes a 2-byte ASN administrator and 4-byte assigned number; Type 1 encodes a 4-byte IP address administrator and 2-byte assigned number; Type 2 encodes a 4-byte 4-octet ASN administrator and 2-byte assigned number.
Labeled VPN-IPv4 NLRI is carried in BGP Multiprotocol Extensions with AFI=1 and SAFI=128; the prefix is an 8-byte RD followed by an IPv4 prefix, encoded per the MPLS labeled routes specification. Two BGP speakers must advertise capability code 1 (multiprotocol BGP) with AFI=1/SAFI=128 before exchanging this NLRI.