MPLS VPNs 161

PE1(config)#tag-switching advertise tags

PE1(config-if)#interface serial 0/0

PE1(config-if)#tag-switching ip

MPLS VPNs

As you learned in Chapter 4, “VPNs: An Overview,” there are many ways to connect customer sites together. Point-to-point links provide guaranteed security and privacy, but they’re expensive. Virtual private networks (VPNs) are an alternative to point-to-point links.

As a new service offering, providers introduced peer-to-peer VPNs several years ago. A peer-to-peer VPN was radically different from other VPNs in that the customer router actually peered with a service provider device. Now that the customer and service provider were communicating with each other, a whole new set of problems arose. How do you manage security? An overlapping address space? The answer was simply more network management, including access lists and route filters.

MPLS VPNs offer the same privacy and security as a traditional VPN without the worries. Overlapping address spaces, intranets, extranets, and even hub-and-spoke topologies are supported in an MPLS VPN. The next few sections describe the characteristics of MPLS VPNs.

Virtual Router

The most basic concept of an MPLS VPN is that of a virtual router. If you remember back to Chapter 4, there were two ways to implement a peer-to-peer VPN: dedicated router and shared router. An MPLS VPN combines these two functions into what is called a virtual router.

So far in this book I haven’t yet bored you with any RFCs. Hey, you’re studying MPLS so you can pass a test, right? Well, I want to use a little snippet from RFC 2917, “A Core MPLS IP VPN Architecture,” to explain the basic principles of a virtual router.

RFC 2917 states the following:

“A virtual router is a collection of threads, either static or dynamic, in a routing device, that provides routing and forwarding services much like physical routers. A virtual router need not be a separate operating system process (although it could be); it simply has to provide the illusion that a dedicated router is available to satisfy the

162 Chapter 5 MPLS VPNs

needs of the network(s) to which it is connected. A virtual router, like its physical counterpart, is an element in a routing domain. The other routers in this domain could be physical or virtual routers themselves. Given that the virtual router connects to a specific (logically discrete) routing domain and that a physical router

can support multiple virtual routers, it follows that a physical router supports multiple (logically discrete) routing domains. From the user (VPN customer) standpoint, it is imperative that the virtual router be as equivalent to a physical router as possible. In other words, with very minor and very few exceptions, the virtual router should appear for all purposes (configuration, management, monitoring, and troubleshooting) like a dedicated physical router.”

Remember that an MPLS VPN is different from a peer-to-peer VPN. An MPLS VPN works by acting like a dedicated router (with separate routing tables) but is on a single router (just like a shared peer-to-peer VPN).

In plain language, a virtual router is a single router that appears to be many routers. Customer routing tables are kept separated from one another, even though they all connect to the same router. In essence, from the customer’s perspective, they have a dedicated router just for them. From the service provider’s perspective, a single router simulates all the necessary mechanisms to provide this perspective to the customer.

Virtual Routing and Forwarding Tables

To implement the concept of virtual routers, Cisco uses an IOS mechanism called a virtual routing and forwarding (VRF) table. A VRF is made up of the following components:

A VRF-specific IP routing table

A CEF (Cisco Express Forwarding) table

Interfaces in the VRF

Routing protocol rules and filters

A VRF is essentially a dedicated routing table, with routing table mechanisms, for a particular customer. Remember that we’re talking about a virtual router here.

Any commands executed on the router in global configuration mode apply to

the router as a whole or globally.

MPLS VPNs 163

MPLS Operational Overview

Before getting started on the particulars of the operation of an MPLS VPN, I’d first like to give you the 35,000-foot view. Figure 5.2 illustrates a simple service provider network that we’ll use for this discussion.

F I G U R E 5 . 2 A simple service provider network

Notice in Figure 5.2 that CE1 and CE2 have private addresses. The service provider network uses public addresses. In Figure 5.2, only two customer sites are connected together in the VPN. Although there are no problems with overlapping addresses in Figure 5.2, most service providers do not like to carry private customer network addresses through their backbone.

Therefore, Network Address Translation (NAT) is used to convert the private customer networks to a public address space determined by the service provider. In addition, as more customers are added, there will certainly be a problem with overlapping private addresses. Therefore, NAT is used to prevent the overlapping addresses.

With the advent of a VRF, a single router can “pretend” to be many routers by maintaining separate routing tables for each VRF, thereby eliminating the need for NAT to support customer VPNs. Figure 5.3 shows the routing tables as they would exist on devices in the service provider network.

F I G U R E 5 . 3 Routing tables with VRFs

164 Chapter 5 MPLS VPNs

For Internet access, NAT would still be required for private-IP-address-to- public-IP-address translation.

Notice in Figure 5.3 that there are two types of routing tables: one for the router as a whole (global) and another representing the VRF (vrf vpn). Router CE1 has a global routing table. The routing table on CE1 contains only routes for the VPN. On PE1, there are two separate routing tables. One of the routing tables is used for the VPN. The other routing table, the global routing table, only contains routes for the service provider network. Routers P1 and P2 have no knowledge whatsoever of the customer routes coming from CE1 and CE2. Finally, router PE2 has both a global routing table and a separate routing table just for the customer’s VPN.

You may be wondering how all of this is going to work. Recall the discussions in the first two chapters of this book. In an MPLS-enabled network, it is not necessary for every device in the network to know about every possible network route. In addition, labels can be stacked. In the case of

MPLS VPNs, IP packets enter the network as unlabeled IP. The edge-LSR not only applies a label for the packet to move through the network, but it also provides a VPN label. This process is called label stacking. Figure 5.4 illustrates this operation.

F I G U R E 5 . 4 MPLS VPN label stacking

Why is the VPN label important? Well, how else does an egress LSR know which VPN a packet is destined for? Figure 5.5 illustrates a subset of the service provider network. Notice in this figure that there are two customers (Customer X and Customer Y) with IP addressing that overlaps. If a packet arrives at PE2 with a destination address on the 10.1.0.0 network, router PE2 has no idea which 10.1.0.0 network the packet should go to.

To remedy this situation, the PE2 router assigns labels to customer routes that show up in the VRF. Those labels are then propagated through MultiProtocol BGP (MP-BGP). MP-BGP must be configured for an MPLS VPN to work. In Figure 5.6, the PE2 router has assigned a label of 32 to the