Introduction
This chapter includes the following topics:
VPN Routing and Forwarding Tables
Overlapping Virtual Private Networks
Route Targets
Propagation of VPN Routing Information in the Provider Network
VPN Packet Forwarding
In the previous chapter, you learned about Virtual Private Network (VPN) evolution; two major VPN models, overlay VPN and peer-to-peer VPN; and the major technologies used to implement both VPN models.
The overlay VPN model, most commonly used in a service provider network, dictates that the design and provisioning of virtual circuits across the backbone must be complete prior to any traffic flow. In the case of an IP network, this means that even though the underlying technology is connectionless, it requires a connection-oriented approach to provision the service.
From a service provider's point of view, the scaling issues of an overlay VPN model are felt most when having to manage and provision a large number of circuits/tunnels between customer devices. From a customer's point of view, the Interior Gateway Protocol design is typically extremely complex and also difficult to manage.
On the other hand, the peer-to-peer VPN model suffers from lack of isolation between the customers and the need for coordinated IP address space between them.
With the introduction of Multiprotocol Label Switching (MPLS), which combines the benefits of Layer 2 switching with Layer 3 routing and switching, it became possible to construct a technology that combines the benefits of an overlay VPN (such as security and isolation among customers) with the benefits of simplified routing that a peer-to-peer VPN implementation brings. The new technology, called MPLS/VPN, results in simpler customer routing and somewhat simpler service provider provisioning, and makes possible a number of topologies that are hard to implement in either the overlay or peer-to-peer VPN models. MPLS also adds the benefits of a connection-oriented approach to the IP routing paradigm, through the establishment of label-switched paths, which are created based on topology information rather than traffic flow.
NOTE
This introduction might lead you to believe that any overlay VPN implementation can be replaced with an MPLS/VPN implementation. Unfortunately, that is not true. MPLS/VPN currently supports only IP as the Layer 3 protocol. Other protocols, such as IPX and AppleTalk, still must be tunneled across an IP backbone.
The MPLS/VPN architecture provides the capability to commission an IP network infrastructure that delivers private network services over a shared infrastructure. This is the same type of service that has already been described in the previous chapter. However, the mechanisms used to provision the service are different. The MPLS/VPN technology is quite complex in itself and will be covered in a series of chapters. In this chapter, you'll see the basic MPLS/VPN concepts without going into too many details that would clutter the overall picture. In the next chapter, the detailed operation of MPLS/VPN is explained, along with the relevant configuration information to be able to provision a simple Intranet topology based on the MPLS/VPN architecture.
Case Study: Virtual Private Networks in SuperCom Service Provider Network
As with all complex topics, the MPLS/VPN concepts are best explained through use of a case study. Imagine a service provider (let's call it SuperCom) that is offering VPN services based on MPLS/VPN technologies. The service provider has two points of presence (POP), a U.S. POP in the San Jose area and a French POP in the Paris area. The POPs are linked through a core router located in Washington, D.C.
The service provider has two customers: FastFood, with headquarters in San Jose and branch offices in Santa Clara, Redwood, and Lyon; and EuroBank, with headquarters in Paris and branch offices in Chartres, Nantres, and San Francisco. The FastFood company has a number of other branch offices (for example, in Santa Cruz and Monterey) that are linked directly with the FastFood central site. The whole network is shown in Figure 9-1.
)
Figure 9-1 SuperCom Network and Its Customers
According to the terminology introduced in Chapter 8, "Virtual Private Network (VPN) Implementation Options," the routers in Figure 9-1 have the following roles:
San Jose and Paris routers link the SuperCom network with its customers; they are thus provider edge (PE) routers.
The Washington router does not have any customer connection; therefore, it's a provider (P) router.
Customer routers connected to the SuperCom network—FastFood routers in San Jose, Santa Clara, and Lyon, as well as EuroBank routers in San Francisco, Paris, and Chartres—are customer edge (CE) routers.
The FastFood routers in Santa Cruz and Monterey have no connection to the SuperCom network; they are customer (C) routers. All the networks connected directly to the FastFood San Jose site (Santa Cruz and Monterey networks) form a customer network (C-network) and represent a single site to the SuperCom network. The service provider does not care (and does not need to know) about the internal structure of that site.
Let's assume that both companies, FastFood and EuroBank, follow the same addressing convention—the central sites use public IP addresses, whereas all the remote sites use private IP address space (network 10.0.0.0).
NOTE
The addressing scheme used by these corporations is seen more often in real customer networks, more so in cases in which the customer didn't acquire a significant portion of public IP address space several years ago.
The IP addresses used by these two companies are summarized in Table 9-1.
Table 9-1 Address Space of FastFood and EuroBank
|
Company |
Site |
Subnet |
|
FastFood |
San Jose |
195.12.2.0/24 |
|
|
Santa Clara |
10.1.1.0/24 |
|
|
Redwood |
10.1.2.0/24 |
|
|
Santa Cruz |
10.1.3.0/24 |
|
|
Monterey |
10.1.4.0/24 |
|
|
Lyon |
10.2.1.0/24 |
|
EuroBank |
Paris |
196.7.25.0/24 |
|
|
Chartres |
10.2.1.0/24 |
|
|
Nantes |
10.2.2.0/24 |
|
|
San Francisco |
10.1.1.0/24 |
The SuperCom service provider would like to offer IP-based VPN service based on the peer-to-peer model (not a number of IP-over-IP tunnels), but it cannot do so easily because the address space of sites connected to the same router overlap.
NOTE
The service provider would encounter a similar (but not so obvious) problem if the address space overlap occurred between customers connected to different POPs. The traditional peer-to-peer model requires strict uniqueness of IP address space.
SuperCom can traditionally solve the overlapping addresses issue in three ways:
It can persuade the customers to renumber their networks. Most customers would not be willing to do that and would rather find another service provider.
It can implement the VPN service with IP-over-IP tunnels, where the customer IP addresses are hidden from the service provider routers.
It can implement a complex network address translation (NAT) scheme that would translate customer addresses into a different (but unique) set of addresses at the provider edge router and then translate those addresses back to the customer addresses before the packet would be sent from the egress PE router to the CE router. Although such a solution is technically feasible, the administrative overhead is prohibitively large and difficult to troubleshoot.