MPLS and Virtual Private Networks Using the Route Processor Module
Virtual Private Networks (VPNs) provide the appearance, functions, and usefulness of a dedicated private network. The VPN feature for MPLS allows a Cisco IOS network to deploy scalable IPv4 Layer 3 VPN backbone service with private addressing, controlled access, and service-level guarantees between sites.
VPNs are supported by service provider networks over which labeled packets are forwarded from RPM ELSRs to other RPM ELSRs. A VPN service creates multiple private network environments within the public infrastructure. Service providers can use VPNs to target a given clientele and to deliver individualized private network services to that clientele in a secure IP environment by using the public infrastructure.
VPN Requirements
Here are the requirements for an effective VPN:
Privacy—All IP VPN services offer privacy over a shared (public) network infrastructure, the most well-known solution of which is an encrypted tunnel. An IP VPN service must offer private addressing, in which addresses within a customer private network do not need to be globally unique.
Scalability—IP VPN services must scale to serve hundreds of thousands of sites and users. An IP VPN service should also serve as a management tool for service providers to control access to services, such as closed user groups for data and voice services. Controlled access places performance limits on authorized programs, processes, or other systems in a network.
Flexibility—IP VPN services must accommodate any-to-any traffic patterns and be able to accept new sites quickly, connect users over different media, and meet transport and bandwidth requirements of new intranet applications.
Predictable performance—Intranet applications supported by an IP VPN service require different classes of service. The service level performance between customer sites must be guaranteed. Examples include widespread connectivity required by remote access for mobile users and sustained performance required by interactive intranet applications in branch offices.
MPLS VPN Features
Beyond the functions of an IP VPN, the VPN features for MPLS allow a Cisco IOS network to deploy the following scalable IPv4 Layer 3 VPN backbone services:
Connectionless service—MPLS VPNs are connectionless. They also are significantly less complex because they do not require tunnels or encryption to ensure network privacy.
Centralized service—VPNs in Layer 3 privately connect users to intranet services and allow flexible delivery of customized services to the user group represented by a VPN. VPNs deliver IP services such as multicast, QoS, and telephony support within a VPN, and centralized services such as content and Web hosting. Combinations of services can be customized for individual customers.
Scalability—MPLS-based VPNs use a Layer 3 connectionless architecture and are highly scalable.
Security—MPLS VPNs provide the same security level as connection-based VPNs. Packets from one VPN cannot accidentally go to another VPN. At the edge of a provider network, incoming packets go to the correct VPN. On the backbone, VPN traffic remains separate.
Easy to create—Because MPLS VPNs are connectionless, it is easy to add sites to intranets and extranets and to form closed user groups. A given site can have multiple memberships.
Flexible addressing—MPLS VPNs provide a public and private view of addresses, allowing customers to use their own unregistered or private addresses. Customers can freely communicate across a public IP network without network address translation (NAT).
Straightforward migration—MPLS VPNs can be built over multiple network architectures, including IP, ATM, Frame Relay, and hybrid networks. There is no requirement to support MPLS on the customer edge (CE) router.
Supported Platforms
The MGX 8850 node with RPM supports VPNs, as do all Cisco routers from the 3600 series up, the 6400 series, and several other devices. Any LSR-capable platform can serve in the backbone including the LS 1010 ATM switch, the 8540 MSR, and the BPX 8650 switch. Non-MPLS-capable switches can also be used, because they can carry MPLS over PVCs or PVPs.
How Do VPNs Work?
Each VPN is associated with one or more VPN routing/forwarding instances (VRFs), which define a VPN at a customer site attached to a PE router. A VRF table consists of the following:
IP routing table
Derived Cisco Express Forwarding table
Set of interfaces that use the forwarding table
Set of rules and routing protocol variables that determine what goes into the forwarding table
VPNs for MPLS
A customer site can be a member of multiple VPNs. However, a site can be associated with only one VRF. A customer site's VRF contains all routes available to the site from the associated VPNs.
The IP routing table and CEF table for each VRF store packet-forwarding information. (Together, these tables are analogous to the forwarding information base [FIB] used in MPLS.) A logically separate set of routing and CEF tables is constructed for each VRF. These tables prevent packets from being forwarded outside a VPN and prevent packets outside a VPN from being forwarded to a router within the VPN.
VPN Route-Target Communities and Export and Import Lists
The distribution of VPN routing information is controlled through the use of VPN route-target communities, implemented by BGP extended communities. Distribution works as follows:
When a VPN route is injected into BGP, it is associated with a list of VPN route-target communities. This list is set through an export list associated with the VRF from which the route was learned.
Associated with each VRF is an import list of route-target communities that defines values to be verified by the VRF table before a route is deemed eligible for import into the VPN routing instance. For example, if a given VRF's import list includes community distinguishers A, B, and C, any VPN route carrying A, B, or C is imported into the VRF.
IBGP Distribution of VPN Routing Information
A PER learns an IP prefix from a CE router through static configuration, a BGP session, RIP, or OSPF. The PER then generates a VPN-IPv4 (vpnv4) prefix by linking an 8-byte route distinguisher to the IP prefix. The VPN-IPv4 address uniquely identifies hosts within each VPN site, even if the site uses globally nonunique (unregistered private) IP addresses. The route distinguisher used to create the VPN-IPv4 prefix is specified by a configuration command on the PER.
BGP uses VPN-IPv4 addresses to distribute network reachability information for each VPN within a service provider network. In building and maintaining routing tables, BGP sends routing messages within (interior BGP [IBGP]) or between (exterior BGP or [EBGP]) IP domains.
BGP propagates vpnv4 information using BGP multiprotocol extensions to handle extended addresses. Refer to RFC 2283, "Multiprotocol Extensions for BGP-4." BGP propagates reachability information (expressed as VPN-IPv4 addresses) among PE routers; reachability information for a given VPN is propagated only to members of that VPN. BGP multiprotocol extensions identify valid recipients of VPN routing information.
Label Forwarding
Based on the routing information stored in each VRF's IP routing and CEF tables, Cisco MPLS uses extended VPN-IPv4 addresses to forward packets to their destinations.
To achieve this, an MPLS label is associated with each customer route. The PE router assigns the route originator's label and directs data packets to the correct CE router. Tag forwarding across the provider backbone is based on dynamic IP paths or traffic-engineered paths.
A customer data packet has two levels of labels attached when it is forwarded across the backbone:
The top label directs the packet to the correct PE router.
The second label indicates how that PE router should forward the packet.
The PE router associates each CE router with a forwarding table that contains only the set of routes that are available to that CE router.