Home > Articles > Cisco Network Technology > General Networking > MPLS/VPN Architecture Overview

MPLS/VPN Architecture Overview

Chapter Description

MPLS/VPN concepts are introduced in this mock case study of service provider SuperCom and its two key customers. Learn how VPNs based on MPLS combine the benefits of the overlay VPN model with the benefits of the peer-to-peer VPN model.

Overlapping Virtual Private Networks

The SuperCom example might lead you to believe that a VPN is associated with a single VRF in a PE router. Although that would be true in the case where the VPN customer needs no connectivity with other VPN customers, the situation might become more complex and require more than one VRF per VPN customer.

Imagine that SuperCom wants to extend its service offering with a Voice over IP (VoIP) service with gateways to the public voice network located in San Jose and Paris, as shown in Figure 9-3. The VoIP gateways were placed in a separate VPN to enhance the security of the newly created service. The IP addresses of these gateways are shown in Table 9-2.

Figure 9-3Figure 9-3 VoIP Gateways in SuperCom Network

Table 9-2 IP Addresses of VoIP Gateways in SuperCom Network

VoIP Gateway Location

VoIP Gateway IP Address

San Jose

212.15.23.12

Paris

212.15.27.35


Both EuroBank and FastFood decided to use the service, but only from their central sites—the branch offices have no need for international voice connectivity. This requirement leads to an interesting problem: The central sites of both organizations need to be in two VPNs: the corporate VPN to reach their remote sites and the VoIP VPN to reach the VoIP gateways. The connectivity requirements are illustrated in Figure 9-4.

Figure 9-4Figure 9-4 VPN Connectivity Requirements in SuperCom Network

NOTE

The connectivity requirements in Figure 9-4 are a simplification of the requirements that you would encounter in a real service provider network. Most often, for security reasons, the customers using a common service (for example, VoIP gateways) will not see each other, but only the gateways or servers providing the service that they are using.

To support connectivity requirements similar to those in Figure 9-4, the MPLS/VPN architecture supports the concept of sites, where a VPN is made up of one or multiple sites. A VPN is essentially a collection of sites sharing common routing information, which means that a site may belong to more than one VPN if it holds routes from separate VPNs. This provides the capability to build intranets and extranets, as well as any other topology described in Chapter 8. A VPN in the MPLS/VPN architecture can therefore be pictured as a community of interest or a closed user group, which is dictated by the routing visibility that the site will have.

The VRF concept introduced in the previous section must be modified to support the concept of sites that can reside in more than one VPN. For example, the central site of FastFood and EuroBank cannot use the same VRF as all other FastFood or EuroBank sites connected to the same PE router. The central site of EuroBank, for example, needs to access the VoIP gateways, so the routes toward these gateways must be in the VRF for that site, whereas the same routes will not be in the Chartres' site VRF. Therefore, the MPLS/VPN architecture unbundles the concept of VRF from the concept of VPN. The VRF is simply a collection of routes that should be available to a particular site (or set of sites) connected to a PE router. These routes can belong to more than one VPN.

NOTE

You might be inclined at this moment to jump from a one-VPN-one-VRF model to the other extreme: one-site-one-VRF model. Although that model is theoretically correct and supports any VPN topology, it leads to more complex configurations of the PE routers that are harder to maintain and that also use more memory. Therefore, it is recommended to keep the number of VRFs to a minimum (for example, one VRF for the customer's central site and another VRF for all remote offices connected to the same PE router).

The relationship between the VPNs, sites, and VRFs can be summarized in the following rule, which should be used as the basis for any VRF definition in an MPLS/VPN network.

NOTE

All sites that share the same routing information (usually this means that they belong to the same set of VPNs), that are allowed to communicate directly with each other, and that are connected to the same PE router can be placed in a common VRF.

Using this rule, the minimum set of VRFs in the SuperCom network is the one outlined in Table 9-3.

Table 9-3 VRFs in the PE Routers in the SuperCom Network

PE-router

VRF

Sites in the VRF

VRF Belongs to VPNs

San Jose

FastFood_Central

FastFood SanJose site

FastFood, VoIP

 

FastFood

FastFood Santa Clara site

FastFood Redwood site

FastFood

 

EuroBank

EuroBank San Francisco site

EuroBank

 

VoIP

San Jose VoIP gateway

VoIP

Paris

FastFood

FastFood Lyon site

FastFood

 

EuroBank_Central

EuroBank Paris site

EuroBank, VoIP

 

EuroBank

EuroBank Chartres site

EuroBank Nantes site

EuroBank

 

VoIP

Paris VoIP gateway

VoIP


4. Route Targets | Next Section Previous Section