Definitive MPLS Network Designs [Electronic resources] نسخه متنی

Layer 3 MPLS VPN Service Design

The design of the Globenet Layer 3 MPLS VPN service caters to both "managed" and "unmanaged" access. The managed service allows Globenet to supply and manage the customer access equipment. The unmanaged service just provides connectivity to the Layer 3 MPLS VPN service; no management of the customer access equipment is deployed. The vast majority of Globenet customers use the managed service, with only a few large Enterprises taking the unmanaged service.

Many aspects of the MPLS VPN design (such as PE router engineering guidelines, load-balancing support, naming conventions, and so on) are as detailed in previous chapters. Therefore, we will not cover them again here. Unless otherwise stated, Globenet uses all the Layer 3 MPLS VPN design best practices we have already detailed. Because Globenet is an international service provider, providing a worldwide service portfolio, this chapter concentrates on the aspects of the design that are specific to these types of providers.

Shared-Edge Internet and MPLS VPN Services

Globenet chose to use the same PE routers to terminate all services, including Internet and Layer 3 MPLS VPN, as well as for ATM pseudowires used to trunk their ATM switches. However, Internet routes are distributed only to PE routers that have customer sites attached that require Internet access or that need more than just a default route. You will see later in this chapter how Globenet provides Internet access.

The implication of shared services on the same edge routers was taken into consideration when designing the network. The main areas of concern were identified as security and scale. Both of these topics are discussed later in this chapter.

Globenet decided it did not want to run a Border Gateway Protocol (BGP)-free core (unlike Telecom Kingland, which was reviewed in the preceding chapter). The primary reasons for this decision were that Globenet had been running an Internet network with BGP in the core for a number of years and saw no compelling reason to change, and it also wanted to provide a failsafe mechanism for Internet traffic in case of LSP failure. Therefore, BGP-4 is delivered to all P routers for Internet routes. All traffic (including VPN and Internet) is label-switched across the network by means of RSVP-TE LSPs between P routers and LDP between PE/P routers.

Note

LDP is enabled on the RSVP-TE tunnel interfaces between P routers. This is an important part of the design, because it allows the Layer 3 MPLS VPN traffic to maintain a complete end-to-end LSP between ingress and egress PE routers.

Connectivity Between Globenet Regions

Because the Globenet Layer 3 MPLS VPN service caters primarily to large Enterprise connectivity, routes belonging to different customers frequently need to be distributed between different regions of the worldwide network. Because of this requirement, Globenet needed to choose an inter-AS solution to provide connectivity across its different autonomous systems.

For scalability reasons, Globenet chose to evaluate only options B and C of the inter-AS solution for its internal connectivity requirements. For detailed discussions of these two solutions, refer to the section "Layer 3 MPLS VPN Services Across Autonomous System Boundaries" in Chapter 1 and also to section 10 of [2547bis]. As a reminder, the three main inter-AS solutions are as follows:

Option A Back-to-back Virtual Routing/Forwarding instances (VRFs)

Option B VPNv4 route exchange between ASBRs

Option C VPNv4 route exchange between route reflectors (RRs) with next hops exchanged between ASBRs

Having reviewed options B and C, Globenet chose to deploy the inter-AS option B solution on all its internal interconnection points between its various autonomous systems.

Globenet chose direct exchange of VPNv4 routes between regions as the right solution for a number of reasons:

Filtering at the autonomous system boundaries can be easily deployed so as to distribute only necessary routes.

The ASBRs do not require any VRFs (as they would with option A). They simply populate their Label Forwarding Information Base (LFIB) with VPNv4 forwarding information that is more scalable.

Each autonomous system does not need to carry the Interior Gateway Protocol (IGP) routes of the PE routers located in other regions.

Figure 5-13 provides an overview of how the option B connectivity is deployed between the different worldwide regions.

Filtering VPNv4 Routes at the ASBRs

Globenet uses dedicated P routers within the POP to provide ASBR functionality. These P routers are attached to the core P routers within the POP using OC-3 or OC-48 links.

The default behavior of a PE router or ASBR when receiving VPNv4 routes is to keep only the routes that carry a route target extended community for which the receiving router has a corresponding "import" statement configured within a particular VRF. This functionality is commonly called Automatic Route Filtering (ARF).

The use of inter-AS option B at the ASBRs means that no VRFs are necessary. Therefore, by default, an ASBR never keeps any VPNv4 routes it receives. To overcome this issue, and therefore provide connectivity between different autonomous systems, the default ARF functionality must be disabled. Globenet achieves this using the configuration template shown in Example 5-1.

Example 5-1. ASBR Configuration Template to Disable ARF

router bgp 32763
no bgp default route-target filter

Having enabled the ASBRs to keep all VPNv4 routes, Globenet realized that the overall number of routes that would need to be advertised between autonomous systems would be a subset of the overall number of routes within a given region. For example, it found that only 20 percent of the routes within the EMEA region needed to be advertised toward the North America region. This was because only a small percentage of its overall customer base has a presence in more than one region. However, without some kind of filtering at the ASBRs, all VPNv4 routes would by default be distributed to all regions. This behavior was not an acceptable long-term design practice for Globenet.

To overcome the distribution of all VPNv4 routes to all regions, Globenet chose to implement a filtering scheme at the ASBRs. It evaluated two primary options:

Reserved range route target filtering Filter at the ASBRs based on a route target value taken from Globenet's reserved range, and add this value to any VRF during export of its routes if those routes need to cross autonomous system boundaries

Customer-specific route target filtering Filter based on customer-specific route target values at the ASBRs

[Route-filter] proposes a change to this behavior in which the route reflector downloads only the relevant routes based on route target values. However, at the time of the initial design, this option was unavailable to Globenet.

Although the reserved route target option has the previously described advantages, it does not completely eliminate configuration changes. Consider the case in which an existing VPN is regional in terms of connectivity but wants to add sites in other regions of the worldwide network. Changes to the PE router configurations need to be made so that the reserved route target value may be added to the VRFs of that VPN so that their routes may be advertised between regions. This is not an issue for new customer deployments, because the PE routers need to be touched anyway. A further disadvantage of this approach occurs when multiple autonomous systems exist. This means that several route target values need to be assigned to provide the relevant filtering on a per-AS pair basis. This can quickly become very complex and difficult to manage.

Although the majority of changes to the Globenet network configuration involve the addition of new customers rather than to existing ones (who move from regional connectivity to multi-regional connectivity), they decided to utilize the second option of using the customer specific route-target values and apply filters at the ASBR-routers only. The main reason for this was that each autonomous system could select its own import/export policy (as you will see in the next section). This essentially forced Globenet to rewrite the route target values at each AS boundary. Rewriting these attributes requires ASBR-specific configuration changes; therefore, the advantages of using reserved route target values were significantly diminished. Furthermore, Globenet did not want to touch multiple points in the network to apply filtering policy, even if this was unlikely to be a regular occurrence.

The risk of filter misconfiguration was deemed minimal because all provisioning is achieved through the use of a centralized tool rather than at the router itself. Also, the number of VPNv4 routes held by the route reflectors was not believed to be an issue in terms of route refresh at this time. Therefore, a download of the full table when changing the filters was not a major concern. The configuration shown in Example 5-2 shows how this filtering is applied.

Example 5-2. ASBR Configuration Template to Filter VPNv4 Routes

router bgp 32763
no bgp default route-target filter
neighbor Globenet_RR-address remote-as 32763
neighbor Globenet_RR-address update-source loopback0
!
address-family vpnv4
neighbor Globenet_RR-address activate
neighbor Globenet_RR-address route-map asbr-routes-in in
exit-address-family
!
ip extcommunity-list 1 permit rt InterAS-client-RT-value/s
!
route-map asbr-routes-in permit 10
match extcommunity 1
!

Route Target/Route Distinguisher Allocation Between Regions

Option B inter-AS provided Globenet with the opportunity to deploy its own IGP domain for each region, and also its own filtering and route distribution policies. But from a Layer 3 MPLS VPN service provisioning aspect, this left Globenet with a dilemma as to how the route targets (RTs) and route distinguishers (RDs) for a given customer VPN should be allocated. It essentially had two options to choose from:

Cross-regional values Use the same values for a given VPN across all regions

Region-specific values Use values that are specific to a given region

Although the use of cross-regional values had some benefits in terms of troubleshooting and network provisioning, it was rejected as a viable solution. The main reason was that it would have forced Globenet to coordinate the RT/RD value assignments for all Layer 3 MPLS VPNs (regardless of whether the VPN had interregional connectivity requirements) between all regions to avoid any conflict between value selection. From a service management perspective, this was unacceptable. Therefore, the choice to use specific values for a given region was selected. This allowed the local region to use its autonomous system number value within the RT/RD structure, thus making each assignment unique across regions.

Using region-specific values provides the desired autonomy between regions but introduced a coordination issue at the autonomous system boundaries. Because each region uses its own RT/RD values, if it wants to exchange routes with another region, it must know what values are in use for the same VPN by other regions in the worldwide network. Although this is a service management issue, it is not as large a problem as using cross-regional values. Only the VPNs that cross regional boundaries need to have their RT/RD assignments coordinated, and only so that the relevant values can be entered into the filters at the ASBRs. Furthermore, the issue is isolated to the ASBRs because Globenet rewrites the route target values to the local regional values when accepting routes from another region. This is achieved using the RT-rewrite functionality. Example 5-3 shows the configuration template used.

Example 5-3. ASBR Configuration Template for RT-rewrite

ip extcommunity-list 1 permit rt incoming-rt-value
!
route-map Inter-Region-RT-rewrite permit 10
match extcommunity 1
set extcomm-list 1 delete
set extcommunity rt local-rt-value additive

Figure 5-14 shows a customer (SoccerOnline) that has presence in the North America and EMEA regions, as well as its RD/RT assignments with the relevant ASBR RT-rewrite filters.

Connectivity with Regional Service Providers

Globenet has a number of VPNv4 peering agreements with various local Layer 3 MPLS VPN service providers in different parts of the globe. Thus, it can provide seamless VPN services to customers that can be attached through these local operators. Globenet co-locates its equipment with the regional service provider whenever possible and uses Gigabit Ethernet as the preferred connectivity medium. In some cases Frame Relay is used for this purpose.

When assessing the design requirements for these connections, it was clear that they were different from those considered for connectivity between the various Globenet regions. Several issues were identified with the option B and C inter-AS solutions:

Coordination of RD/RT assignments with regional service providers was considered too complex.

Security from label spoofing, intrusion, and denial-of-service (DoS) attacks was difficult to achieve with 100 percent accuracy.

Forwarding is based on the global LFIB rather than a VRF-specific Forwarding Information Base (FIB) and therefore is arguably more open to abuse.

Exchange of Globenet IP address space would be necessary if inter-AS option C were chosen.

Certain services such as Multicast and IPv6 are more complex to deploy and require functionality beyond that which is needed within a single Globenet region.

Considering these issues, Globenet chose to deploy option A inter-AS (back-to-back VRFs, as discussed in Chapter 1) for all regional service provider connectivity. This model, although less scalable than the other inter-AS solutions in terms of memory allocation, number of interfaces, and so forth, allows Globenet to easily deploy inter-AS VPNs and overcome the issues introduced by the other solutions. Figure 5-15 shows each of the current peering connections.

Using this inter-AS option, Globenet can treat all regional service providers as if they are just another VPN client. At the ASBRs, a VRF is enabled for each inter-AS VPN that needs connectivity to the regional service provider. Furthermore, a separate logical interface is required for each VPN. Hence, Gigabit Ethernet and Frame Relay are needed, because both of these technologies provide this functionality through VLANs and PVCs, respectively.

BGP-4 is enabled within each VRF context, and routes are exchanged using this protocol.

The same set of configuration parameters are enabled as used for normal VPN customer VRFsmaximum routes, maximum prefix on the BGP-4 session, and so forth.

Figure 5-16 shows an example of a customer (Candy International) that needs connectivity with Globenet and a regional service provider and how this type of connectivity is used.