Multiprotocol Label Switching Virtual Private Network, or Multiprotocol Label Switching Virtual Private Networks, is the most popular and widespread implementation of Multiprotocol Label Switching technology. Its popularity has grown exponentially since it was invented, and it is still growing steadily. Although most service providers have implemented it as a replacement for the Frame Relay and Asynchronous Transfer Mode services that were popular before it, Multiprotocol Label Switching Virtual Private Network is now seeing a growing interest from large enterprise companies who view it as the next step in their network design. Multiprotocol Label Switching Virtual Private Network can provide scalability and divide the network into separate smaller networks, which is often necessary in the larger enterprise networks, where the common IT infrastructure has to offer isolated networks to individual departments. Many service providers that have run Multiprotocol Label Switching Virtual Private Network for years are now looking at interconnecting their network to the Multiprotocol Label Switching Virtual Private Network networks of other service providers to improve the scalability and ease of operation of their network. This is where Inter-Autonomous Multiprotocol Label Switching Virtual Private Network and Carrier’s Carrier (CsC) come into the picture.

Introduction to Multiprotocol Label Switching Virtual Private Network

This section introduces virtual private networks (Virtual Private Network) in general and Multiprotocol Label Switching Virtual Private Network specifically.

Definition of a Virtual Private Network

A Virtual Private Network is a network that emulates a private network over a common infrastructure. The Virtual Private Network might provide communication at OSI Layer 2 or 3. The Virtual Private Network usually belongs to one company and has several sites interconnected across the common service provider infrastructure. The private network requires that all customer sites are able to interconnect and are completely separate from other Virtual Private Networks. That is the minimum connectivity requirement. However, Virtual Private Network models at the IP layer might require more than that. They can provide connectivity between different Virtual Private Networks when that is wanted and even provide connectivity to the Internet. Multiprotocol Label Switching Virtual Private Network offers all of this. Multiprotocol Label Switching Virtual Private Networks are made possible because the service provider runs Multiprotocol Label Switching in the backbone network, which supplies a decoupling of forwarding plane and control plane that IP does not.

Virtual Private Network Models

Virtual Private Networks did exist before the arrival of Multiprotocol Label Switching. Most popular were Frame Relay or Asynchronous Transfer Mode technologies, providing Virtual Private Network service at Layer 2. The provider had a Frame Relay or Asynchronous Transfer Mode backbone and supplied Layer 2 connectivity to the customer routers. This was commonly referred to as the overlay model. The service provider might have actually owned or managed the edge routers that were connected to the customer network. The point is that the routers were physically at the customer premises. Refer to the section “Peer-to-Peer Virtual Private Network Model Versus Overlay Virtual Private Network Model”  for more information on this. Peer-to-peer Virtual Private Network networks existed, but they were not popular. The main reason is that they were not easy to deploy and maintain because they needed distribute lists, IP packet filters, or GRE tunnels. Because the CE and PE routers interact at Layer 3, they must run a routing protocol (or static routing) between them.

The CE router has only one peer outside of its own site: the PE router. If the CE router is multihomed, it can peer with multiple PE routers. The CE router does not peer with any of the CE routers from the other sites across the service provider network, as with the overlay model. The name peer-to-peer model is derived from the fact that the CE and PE form a peer at Layer 3. The P in Virtual Private Network stands for private. As such, the customers of the service provider are allowed to have their own IP addressing scheme. This means that they can use registered IP addresses but also private IP addresses (see RFC 1918) or even IP addresses that are also used by other customers who are connecting to the same service provider (referred to as overlapping IP addressing). If the packets were to be forwarded as IP packets within the service provider network, this would cause problems, because the P routers would be confused. If the private and overlapping IP addressing scheme is not allowed, then every customer must be using a unique address range. In that case, the packets can be forwarded by looking up the destination IP address on every router in the service provider network. This means that all P and PE routers must have the complete routing table of every customer. This would be a large routing table. The only routing protocol that is capable of carrying a large number of routes is Border Gateway Protocol (Border Gateway Protocol). This would mean that all P and PE routers would have to run internal Border Gateway Protocol (iBorder Gateway Protocol) among them. However, this is not a Virtual Private Network scheme, because it is not private to the customers. Another solution is that every P and PE router has a private routing table for each customer. Several processes of one routing protocol (one process per Virtual Private Network) could be running on all the routers to distribute the Virtual Private Network routes. Running one routing process per Virtual Private Network on every P router is not very scalable.

Each time one Virtual Private Network is added to the network, a new routing process must be added to every P router. Furthermore, if an IP packet enters a P router, how does the P router determine which Virtual Private Network the packet belongs to to figure out which private routing table to use to forward the packet? If the packet is an IP packet, this is not possible. You could add one extra field to the IP packet indicating which Virtual Private Network the IP packet belongs to. The P routers could then forward the IP packets by looking at this extra field and at the destination IP address. Again, all P routers would have to be aware of this extra field. A scalable solution would be to have the P routers completely unaware of the Virtual Private Networks. Then the P routers would not be burdened with having routing information for Virtual Private Network routes. Can you achieve this by using Multiprotocol Label Switching? The answer is yes. The customer IP packets are labeled in the service provider network to achieve a private Virtual Private Network for each customer. Furthermore, the P routers no longer need to have the routing table of the customers by using two Multiprotocol Label Switching labels. Therefore, Border Gateway Protocol is not needed on the P routers. The Virtual Private Network routes are only known on the PE routers. As such, the Virtual Private Network knowledge is present only on the edge routers of the Multiprotocol Label Switching Virtual Private Network network, which makes the Multiprotocol Label Switching Virtual Private Network solution scalable.

Architectural Overview of Multiprotocol Label Switching Virtual Private Network

To achieve Multiprotocol Label Switching Virtual Private Network, you need some basic building blocks on the PE routers. These building blocks are the following: VRF, route distinguisher (RD), route targets (RT), route propagation through MP-Border Gateway Protocol, and forwarding of labeled packets.

Virtual Routing Forwarding

A virtual routing/forwarding (VRF) is a Virtual Private Network routing and forwarding instance. It is the name for the combination of the Virtual Private Network routing table, the VRF Cisco Express Forwarding (CEF) table, and the associated IP routing protocols on the PE router. A PE router has a VRF instance for each attached Virtual Private Network. Because the routing should be separate and private for each customer (Virtual Private Network) on a PE router, each Virtual Private Network should have its own routing table. This private routing table is called the VRF routing table. The interface on the PE router toward the CE router can belong to only one VRF. As such, all IP packets received on the VRF interface are unambiguously identified as belonging to that VRF. Because there is a separate routing table per Virtual Private Network, there is a separate CEF table per Virtual Private Network to forward these packets on the PE router. This is the VRF CEF table. As with the global routing table and the global CEF table, the VRF CEF table is derived from the VRF routing table.

You create the VRF on the PE router with the ip vrf command. You use the ip vrf forwarding command to assign PE-CE interfaces on the PE router to a VRF. You can assign an interface to only one VRF, but you can assign several interfaces to the same VRF. The PE router then automatically creates a VRF routing table and CEF table. The VRF routing table does not differ from a regular routing table in Cisco IOS other than that it is used for a set of Virtual Private Network sites only and is completely separated from all other routing tables. The routing table as you have known it to this point will now be referred to as the global or the default routing table. The VRF routing table cust-one has prefixes in it that are populated by dynamic routing protocols and static routing, just like the global routing table.

The concept of metrics, distance, next hop, and so on does not change. Because the VRF instance is associated with interfaces, only IP packets that are entering the PE router via those VRF interfaces are forwarded according to that VRF CEF table. The Virtual Private Network prefixes are propagated across the Multiprotocol Label Switching Virtual Private Network network by Multiprotocol Border Gateway Protocol (MPBorder Gateway Protocol). The problem is that when Border Gateway Protocol carries these IPv4 prefixes across the service provider network, they must be unique. If the customers had overlapping IP addressing, the routing would be wrong. To solve this problem, the concept of RDs was conceived to make IPv4 prefixes unique. The basic idea is that each prefix from each customer receives a unique identifier (the RD) to distinguish the same prefix from different customers.

A prefix derived from the combination of the IPv4 prefix and the RD is called a vpnv4 prefix. MP-Border Gateway Protocol needs to carry these vpnv4 prefixes between the PE routers. An RD is a 64-bit field used to make the VRF prefixes unique when MP-Border Gateway Protocol carries them. The RD does not indicate which VRF the prefix belongs to. The function of the RD is not that of a Virtual Private Network identifier, because some more complex Virtual Private Network scenarios might require more than one RD per Virtual Private Network. Each VRF instance on the PE router must have one RD assigned to it. This 64-bit value can have two formats: ASN:nn or IP-address:nn, where nn represents a number. The most commonly used format is ASN:nn, where ASN stands for autonomous system number. Usually, the service provider uses ASN:nn, where ASN is the autonomous system number that the Internet Assigned Numbers Authority (IANA) assigns to the service provider and nn is the number that the service provider uniquely assigns to the VRF. The RD does not impose semantics; it is just used to uniquely identify the Virtual Private Network routes. This is needed because the IPv4 routes from one customer might be overlapping with the IPv4 routes from another. The combination of the RD with the IPv4 prefix provides a vpnv4 prefix, of which the address is 96 bits long.

The mask is 32 bits long, just as it is for an IPv4 prefix. If you take an IPv4 prefix 10.1.1.0/24 and an RD 1:1, the vpnv4 prefix becomes 1:1:10.1.1.0/24. One customer might use different RDs for the same IPv4 route. When a Virtual Private Network site is connected to two PE routers, routes from the Virtual Private Network site might get two different RDs, depending on which PE router the routes are received. Each IPv4 route would get two different RDs assigned and would have two completely different vpnv4 routes. This would allow Border Gateway Protocol to see them as different routes and apply a different policy to the routes.