MPLS L3VPN Overview
Before defining an MPLS VPN, VPN in general must be defined. A VPN is:
-
An IP-based network delivering private network services over a public infrastructure
-
A set of sites that are allowed to communicate with each other privately over the Internet or other public or private networks
Conventional VPNs are created by configuring a full mesh of tunnels or permanent virtual circuits (PVCs) to all sites in a VPN. This type of VPN is not easy to maintain or expand, as adding a new site requires changing each edge device in the VPN.
MPLS-based VPNs are created in Layer 3 and are based on the peer model. The peer model enables the service provider and the customer to exchange Layer 3 routing information. The service provider relays the data between the customer sites without customer involvement.
MPLS VPNs are easier to manage and expand than conventional VPNs. When a new site is added to an MPLS VPN, only the edge router of the service provider that provides services to the customer site needs to be updated.
The following figure depicts a basic MPLS VPN topology.
These are the basic components of MPLS VPN:
-
Provider (P) router—Router in the core of the provider network. P routers run MPLS switching and do not attach VPN labels to routed packets. VPN labels are used to direct data packets to the correct private network or customer edge router.
-
PE router—Router that attaches the VPN label to incoming packets based on the interface or sub-interface on which they are received, and also attaches the MPLS core labels. A PE router attaches directly to a CE router.
-
Customer (C) router—Router in the Internet service provider (ISP) or enterprise network.
-
Customer edge (CE) router—Edge router on the network of the ISP that connects to the PE router on the network. A CE router must interface with a PE router.
MPLS L3VPN Benefits
MPLS L3VPN provides the following benefits:
-
Service providers can deploy scalable VPNs and deliver value-added services.
-
Connectionless service guarantees that no prior action is necessary to establish communication between hosts.
-
Centralized Service: Building VPNs in Layer 3 permits delivery of targeted services to a group of users represented by a VPN.
-
Scalability: Create scalable VPNs using connection-oriented and point-to-point overlays.
-
Security: Security is provided at the edge of a provider network (ensuring that packets received from a customer are placed on the correct VPN) and in the backbone.
-
Integrated Quality of Service (QoS) support: QoS provides the ability to address predictable performance and policy implementation and support for multiple levels of service in an MPLS VPN.
-
Straightforward Migration: Service providers can deploy VPN services using a straightforward migration path.
-
Migration for the end customer is simplified. There is no requirement to support MPLS on the CE router and no modifications are required for a customer intranet.
Major Components of MPLS L3VPN—Details
An MPLS-based VPN network has three major components:
-
VPN route target communities—A VPN route target community is a list of all members of a VPN community. VPN route targets need to be configured for each VPN community member.
-
Multiprotocol BGP (MP-BGP) peering of the VPN community PE routers—MP-BGP propagates VRF reachability information to all members of a VPN community. MP-BGP peering needs to be configured in all PE routers within a VPN community.
-
MPLS forwarding—MPLS transports all traffic between all VPN community members across a VPN service-provider network.
A one-to-one relationship does not necessarily exist between customer sites and VPNs. A given site can be a member of multiple VPNs. However, a site can associate with only one VRF. A customer-site VRF contains all the routes available to the site from the VPNs of which it is a member.
Virtual Routing and Forwarding Tables
Each VPN is associated with one or more VPN routing and forwarding (VRF) instances. A VRF defines the VPN membership of a customer site attached to a PE router. A VRF consists of the following components:
-
An IP version 4 (IPv4) unicast routing table
-
A derived FIB table
-
A set of interfaces that use the forwarding table
-
A set of rules and routing protocol parameters that control the information that is included in the routing table
These components are collectively called a VRF instance.
A one-to-one relationship does not necessarily exist between customer sites and VPNs. A site can be a member of multiple VPNs. However, a site can associate with only one VRF. A VRF contains all the routes available to the site from the VPNs of which it is a member.
Packet forwarding information is stored in the IP routing table and the FIB table for each VRF. A separate set of routing and FIB tables is maintained for each VRF. These tables prevent information from being forwarded outside a VPN and also prevent packets that are outside a VPN from being forwarded to a router within the VPN.
VPN Routing Information: Distribution
The distribution of VPN routing information is controlled through the use of VPN route target communities, implemented by BGP extended communities. VPN routing information is distributed as follows:
-
When a VPN route that is learned from a CE router is injected into a BGP, a list of VPN route target extended community attributes is associated with it. Typically, the list of route target community extended values is set from an export list of route targets associated with the VRF from which the route was learned.
-
An import list of route target extended communities is associated with each VRF. The import list defines route target extended community attributes that a route must have for the route to be imported into the VRF. For example, if the import list for a particular VRF includes route target extended communities A, B, and C, then any VPN route that carries any of those route target extended communities—A, B, or C—is imported into the VRF.
BGP Distribution of VPN Routing Information
A PE router can learn an IP prefix from the following sources:
-
A CE router by static configuration
-
An eBGP session with the CE router
-
Open Shortest Path First (OSPF) as Interior Gateway Protocol (IGP)
The IP prefix is a member of the IPv4 address family. After the PE router learns the IP prefix, the PE converts it into the VPN-IPv4 prefix by combining it with a 64-bit route distinguisher. The generated prefix is a member of the VPN-IPv4 address family. It uniquely identifies the customer address, even if the customer site is using globally nonunique (unregistered private) IP addresses. The route distinguisher used to generate the VPN-IPv4 prefix is specified by the rd command associated with the VRF on the PE router.
BGP distributes reachability information for VPN-IPv4 prefixes for each VPN. BGP communication takes place at two levels:
-
Internal BGP (iBGP)—within the IP domain, known as an autonomous system.
-
External BGP (eBGP)—between autonomous systems.
BGP propagates reachability information for VPN-IPv4 prefixes among PE routers by the BGP protocol extensions (see RFC 2283, Multiprotocol Extensions for BGP-4), which define support for address families other than IPv4. Using the extensions ensures that the routes for a given VPN are learned only by other members of that VPN, enabling members of the VPN to communicate with each other.
MPLS Forwarding
Based on routing information stored in the VRF IP routing table and the VRF FIB table, packets are forwarded to their destination using MPLS.
A PE router binds a label to each customer prefix learned from a CE router and includes the label in the network reachability information for the prefix that it advertises to other PE routers. When a PE router forwards a packet received from a CE router across the provider network, it labels the packet with the label learned from the destination PE router. When the destination PE router receives the labeled packet, it pops the label and uses it to direct the packet to the correct CE router. Label forwarding across the provider backbone is based on dynamic label switching. A customer data packet carries two levels of labels when traversing 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 to the CE router.
Automatic Route Distinguisher Assignment
To take advantage of iBGP load balancing, every network VRF must be assigned a unique route distinguisher. VRF is require a route distinguisher for BGP to distinguish between potentially identical prefixes received from different VPNs.
With thousands of routers in a network each supporting multiple VRFs, configuration and management of route distinguishers across the network can present a problem. Cisco IOS XR software simplifies this process by assigning unique route distinguisher to VRFs using the rd auto command.
To assign a unique route distinguisher for each router, you must ensure that each router has a unique BGP router-id. If so, the rd auto command assigns a Type 1 route distinguisher to the VRF using the following format: ip-address:number. The IP address is specified by the BGP router-id statement and the number (which is derived as an unused index in the 0 to 65535 range) is unique across theVRFs.
Finally, route distinguisher values are checkpointed so that route distinguisher assignment to VRF is persistent across failover or process restart. If an route distinguisher is explicitely configured for a VRF, this value is not overridden by the autoroute distinguisher.
Prerequisites for Implementing MPLS L3VPN
These are the prerequisites to configure MPLS L3VPN:
-
You must be in a user group associated with a task group that includes the proper task IDs for these commands:
-
-
BGP
-
IGP
-
MPLS
-
MPLS Layer 3 VPN
-
-
-
If you suspect user group assignment is preventing you from using a command, contact your AAA administrator for assistance.
-
To configure MPLS Layer 3 VPNs, routers must support MPLS forwarding and Forwarding Information Base (FIB).
Restrictions for MPLS L3VPN
Implementing MPLS L3VPN is subjected to these restrictions:
-
Fragmentation of MPLS packets that exceed egress MTU is not supported. Fragmentation is not supported for IP->MPLS imposition as well. Hence, it is recommended to use Maximum MTU (9216) value on all interfaces in the MPLS core.
-
L3VPN prefix lookup always yields a single path. In case of multiple paths at IGP or BGP level, path selection at each level is done using flow hash computed in data plane.
-
Per VRF aggregate statistics are not supported.
MPLS VPN Inter-AS with ASBRs exchanging IPv4 routes and MPLS labels
-
For networks configured with eBGP multihop, a label switched path (LSP) must be configured between non adjacent routers.
-
Layer 3 VPN over SR-TE is not supported.
Label assignments
-
Local label allocation for every VRF on MPLS VPN.
-
One VPN label for every VRF.
-
Must have per VRF label mode across the VRF deployment.
L3 interface scale value on the Cisco modular router operating in P100 mode
Component |
Maximum number of L3 Interfaces Per Component |
---|---|
NPU (P100) |
8000 |
Line card (88-LC1-36EH) |
16000 |
Router |
30000 |