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 and Lyon; and EuroBank, with headquarters in Paris and branch offices in Chartres 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 8-1.
According to the terminology introduced in Chapter 7, "Virtual Private Network (VPN) Implementation Options," the routers in Figure 8-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.
Figure 8-1. SuperCom Network and Its Customers
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 8-1.
|
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.
