Now that the basic mechanisms for PE-to-CE connectivity are clear, it is important to understand which method may be appropriate for which type of deployment. To assist with this investigation, a sample VPN topology for a typical VPN customer will be used, as seen in Figure 10-8.
Figure 10-8 Typical VPN Customer Network Topology
This sample topology shows that EuroBank has two central site locations, connected via Frame Relay to various remote sites. Both central site locations are connected (via fiber), and each remote site has a primary PVC to one central site location and a secondary (shadow) PVC to the backup central site. Routing between sites is provided through use of the EIGRP Interior Gateway Protocol.
The EuroBank VPN customer has decided to migrate its Frame Relay infrastructure to an MPLS/VPN solution to overcome the complexities and limitations of a private network being run across an overlay Frame Relay service. The new network infrastructure, using the SuperCom service provider's MPLS/VPN backbone, can be seen in Figure 10-9.
Figure 10-9 Migrated MPLS/VPN Customer Network Topology
Note
For a review of the limitations of the VPN overlay model (for example, traditional Frame Relay service offered by most service providers today), refer to Chapter 7, "Virtual Private Network (VPN) Implementation Options."
Given this network topology, we need to decide which of the four currently available PE-to-CE connectivity options should be used at each point in the network. As already discussed in the section on OSPF connectivity options, if the VPN customer is already running OSPF within each of its sites, it could decide to continue to use this protocol between PE- and CE-routers. This would be a good design choice in this case for the reasons already discussed in the OSPF section.
In our example, EIGRP is the current IGP, so the customer needs to migrate the routing protocol used across the PE-to-CE links to OSPF, BGP-4, or RIP Version 2, or use static routing so that routes can be exchanged between the EuroBank VPN sites and the SuperCom MPLS/VPN backbone. (Note that this migration is limited to the PE/CE links only.) Given the fact that some of the spoke sites have only one link into the backbone, static routing could be used on each PE-router within the SuperCom MPLS/VPN
backbone—there is little point in running a dynamic routing protocol across a single link.
However, some sites, such as the two central sites and the Reading spoke site, are
multihomed into the backbone network. Static routing is not really an option in this case, so a more dynamic means of route advertisement is required.
The routing requirements of the spoke and central sites in our example are slightly different.
In the case of the spoke sites, these sites must learn other VPN routes from the MPLS/VPN backbone so that inter-site routing is available. The central site locations, however, not only need to learn routes from other spoke sites, but they also need to apply policy in terms of traffic flow. In addition, they need to be a concentration point in terms of the number of routes that they must carry in memory (this could include Internet routes learned from the MPLS/VPN backbone). For these reasons, RIP Version 2 may be an adequate design choice for the spoke sites, but BGP-4 is an obvious choice for the central sites, because of its scaling and policy enforcement properties.
From the service provider's point of view, the use of BGP-4 between PE-routers and VPN customer CE-routers might be the protocol of choice. This is because the use of this protocol offers several advantages for the service provider:
• The service provider does not need to run multiple routing protocol processes, or routing contexts, per VRF.
• The configuration overhead is reduced, and the maintenance of the PE-router configuration is simplified.
• Redistribution between routing protocols is not necessary if the routes are learned via BGP-4.
In our example topology, BGP-4 could easily be used on each PE-to-CE link, and an autonomous system number from the private 64512–65535 range could be used in each site. This type of migration would be easy to achieve, and successful advertisement of VPN routes between sites could be provisioned.
However, if we consider another sample topology shown in Figure 10-10, you can see that the migration issues and subsequent BGP-4 deployment may become more complex as the size of the organization increases.
Figure 10-10 VPN Customer Topology—Multiple Regions Running BGP-4
The VPN customer in Figure 10-10 has split the network into multiple regions, each connected via BGP-4. This type of topology is typical of a large (potentially multinational) customer that has chosen to split its network into separate regions, running BGP in the network core (on inter-regional links) and separate IGP process in each region. One of the reasons for using this topology would be the IGP scalability; another might be the need to apply routing policy. With this type of topology, if the customer has chosen to use a different AS number in each region and to run external BGP between regions, then replacement of the leased-line core infrastructure with an MPLS/VPN infrastructure is essentially the same as we have seen previously. However, if the same AS number is used in all regions (thus, internal BGP is used), then this type of connectivity presents some challenges for the MPLS/VPN backbone.