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-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-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 |