VPN Customer Connectivity?MPLS/VPN Design Choices
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.
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."
Figure 10-9. Migrated MPLS/VPN Customer Network Topology
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.
Migrating Customers Using iBGP in Their Network to MPLS/VPN Service
Regardless of which PE-to-CE connectivity option is chosen, after VPN routes have been advertised across the MPLS/VPN backbone and have been imported into the relevant VRFs, the next step is to advertise these routes to other sites that are associated with the VRF. If the advertisement of these routes is achieved through use of the BGP-4 protocol, we have already seen that several design choices exist between the service provider and the VPN customer sites. One such design choice is to run the same AS number within each region, as shown in Figure 10-11.
Figure 10-11. Multiple Regions Using the Same Autonomous System Number
As highlighted in the previous section, this type of topology presents a problem for the BGP-4 protocol. One of the requirements of the BGP-4 protocol is that a BGP speaker should ignore any received updates that contain its own AS number within the AS_PATH. Therefore, the AS number must be removed from the AS_PATH before the route is advertised to another VPN site if different sites use the same AS number. In topologies such as the one described in Figure 10-10, in which a different AS number is used in all sites, this requirement can be met and routes can be advertised between sites without any issues. However, if internal BGP is used between sites, as in Figure 10-11, this requirement cannot be met using the standard BGP procedures.
To try to overcome this restriction, we could use a private AS number. Using this method, you might think that this private AS number could be removed by the MPLS/VPN service provider before advertisement of any routes, using the existing procedures for stripping private AS numbers when advertising routes to an external BGP neighbor. However, these procedures have the following restrictions:
The private AS number is removed if only private AS numbers exist within the AS_PATH.
The private AS number is removed if it is not equal to the neighboring AS number.
In the MPLS/VPN environment, the first restriction detailed here is met. However, because the neighboring AS number of a receiving VPN site will be the same as the originator of the route, the second restriction fails. Therefore, the PE-router will not remove the private AS number from the AS_PATH.
As seen in Figure 10-12, the EuroBank London site receives an update for 196.7.25.0/24, but this update contains its own AS number, 65001, within the AS_PATH. Because a BGP speaker should ignore any updates it receives that contain its own AS Number within the AS_PATH, the London CE-router ignores this update. Example 10-15 gives confirmation of this.
Figure 10-12. Use of Private ASN with MPLS/VPN
Example 10-15 BGP-4 Rejection of Update Containing Own AS Number
London# debug ip bgp update BGP(0): 10.2.1.6 rcv UPDATE w/ attr: nexthop 10.2.1.6, origin i, ori ginator 0.0.0.0, path 1 65001, extended community BGP(0): 10.2.1.6 rcv UPDATE about 196.7.25.0/24 -- DENIED due to: as- path contains our own AS;
Therefore, another mechanism is required so that the reuse of the AS number, whether public or private, can be supported in the MPLS/VPN environment. This mechanism is provided through use of a feature called AS Override.
Autonomous System Number Override
The AS Override feature allows the MPLS/VPN service provider to run the BGP routing protocol with a customer even if the customer is using the same AS number at different sites. This goal is achieved by rewriting the AS_PATH received from one VPN site route to contain only the MPLS/VPN backbone autonomous system number in the path. Using this mechanism, if a customer uses the same autonomous system number within each of its sites, it receives routes from other sites without failing the BGP requirement that they should not accept a route that has their own autonomous system number in the AS_PATH attribute.
This feature is necessary only if a customer's intention is to use the same autonomous system number in some or all of its sites. This feature can be used if the VPN customer uses either a private or a public autonomous system number, and it may be used in conjunction with the Site of Origin feature that we saw in the previous chapter, for the prevention of routing loops in a multi-homed scenario.
Figure 10-13. AS Override Feature?BGP-4 Between PE- and CE-routers
As Figure 10-13 shows, the EuroBank London site is now capable of receiving the 196.7.25.0/24 prefix from the Paris site because the AS_PATH does not contain its 65001 autonomous system number.
The AS Override feature is configured through use of the neighbor statement within the BGP process configuration, under the relevant address family used for the VPN customer. When configured, the PE-router checks each update before advertisement to the CE-router and performs the following operations:
If the last autonomous system number in the AS_PATH is equal to the neighboring autonomous system number, then the PE-router will replace it with its own.
If the last autonomous system number has multiple occurrences (which may happen with the use of AS_PATH prepend), then the PE-router will replace all the occurrences of this number with its own autonomous system number.
The PE-router will add its own autonomous system number to the AS_PATH, per normal eBGP procedures.
Example 10-16 shows the necessary configuration for the SuperCom London PE-router to allow the EuroBank London site to receive BGP-4 updates for VPN routes that are reachable in other EuroBank sites.
Example 10-16 AS Override Feature Configuration
hostname London ! interface serial0 description ** interface to EuroBank London ** ip vrf forwarding EuroBank ip address 10.2.1.6 255.255.255.252 ! router bgp 1 no bgp default ipv4-unicast neighbor 194.22.15.2 remote-as 1 neighbor 194.22.15.2 update-source loopback0 ! address-family ipv4 vrf EuroBank neighbor 10.2.1.5 remote-as 65001 neighbor 10.2.1.5 activate neighbor 10.2.1.5 as-override no auto-summary no synchronization exit-address-family ! address-family vpnv4 neighbor 194.22.15.2 activate neighbor 194.22.15.2 send-community extended exit-address-family
With the configuration shown in Example 10-16, we can now see in Example 10-17 that the update for 196.7.25.0/24 is accepted by the EuroBank London CE-router and is installed into the BGP table with an AS_PATH of 1:1.
Example 10-17 BGP-4 Update Acceptance with AS Override Enabled
London# debug ip bgp update BGP(0): 10.2.1.6 rcvd UPDATE w/ attr: nexthop 10.2.1.6, origin i, path 1 1 BGP(0): 10.4.1.22 rcvd 196.7.25.0/24 BGP(0): Revise route installing 196.7.25.0/24 -> 10.2.1.6 to main IP table London# show ip bgp BGP table version is 3, local router ID is 10.2.1.5 Status codes: s suppressed, d damped, h history, * valid, > best, i ? internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 196.7.25.0 10.2.1.6 0 1 1 i
