Site Typifying WAN Access: Impact on Topology
| You should carefully consider site typifying access to the new service. Typically, you would think about business need, location, and the number of users and applications or services required for a given site. As discussed in Chapter 3, "Analyzing Service Requirements," many elements must be considered beyond these basic tenants. For the purposes of this discussion, we will concentrate on the following topological needs:
Site typification becomes important to define the characteristics of operational and technical implementation to be delivered, by both the internal operations teams and the service provider. If you take Acme, Inc. as an example, four site types have been created:
Aside from support for corporate applications, such as e-mail, collaboration tools, Customer Relationship Management (CRM), and Enterprise Resource Planning (ERP), all sites have a requirement to support voice over IP (VoIP), and most require video over IP. When considering performance characteristics, you can divide these into categories based on the number of users, application traffic volume, and profile and interactive traffic (voice and video) to derive the needs. Availability is the point we're concerned with. In the context of routing between the service provider and Acme, there will be differing needs based on the site typifications. These can be divided into the following areas:
Note xDSL refers to ADSL-, HDSL-, SDSL-, and VDSL-type connections. Flexibility is a further consideration that must be examined, specifically when it comes to ease of migration. Ease of migration can be addressed through the standardization of access model. A standardized access model applied across the site typification models (Site Types A, B, C, and D) will aid the migration greatly. Site Type: TopologySite Type A typically constitutes large data centers, major campus sites, or core operational facilities in the Acme network. They need high-speed access to the MPLS VPNsin this case, via dual connections to the service provider MPLS VPN. This can create challenges for connectivity, so this needs to be addressed carefully if an IGP is between the CE and PE. Mainly caused by the presence of connectivity via dual links to the MPLS VPN, this can create what is known as a "backdoor link." This will be addressed later, with the dual CE/dual PE connection model. Figure 4-5 shows the topology. Figure 4-5. Site Type AConnectivity to the Service Provider Site Type A has the following characteristics:
These core sites also act as the gateway to other Acme international sites, which may not be part of the MPLS VPN. Diversity of service provider access is a key requirement with high site level service-level agreements (SLAs) required. Low convergence times are key. Site Type B is largely similar to Site Type A sites in their mode of connection to the MPLS VPN, with the same requirements to have diverse connections to the service provider network. With this site type, connectivity may not need the same level of separation, but diversity is still a requirement. Figure 4-6 shows Site Type A and B connectivity options. Figure 4-6. Site Types A and B Site Type C sites are the majority of locations, mainly using services at central sites and generating the bulk of the inbound traffic toward the Site Type A or Site Type B sites. Figure 4-7 shows Site Type C/dual CE/single PE. Figure 4-7. Site Type CDual CE, Single PE Type C sites have the following characteristics:
Efficiency of the access mechanism, bandwidth, and site service levels will vary for this site type because of the locations involved. The characteristics are balanced against economic cost factors, some of which may require compromises because of cost. These sites may also "bundle" the dual links to use multilink PPP (MLP) to provide live link resilience between the CE and PE where terminating on dual PEs is cost- or operationally prohibitive. Type D sites are typically the smaller field sites, mainly for sales staff, that use a limited set of central services in terms of applications. However, they may be using voice and, as such, still require high performance in the real-time site type and low convergence common to all other sites. Figure 4-8 shows Site Type D connectivity. Figure 4-8. Dual Home Site Type DSingle PE Type D sites have the following characteristics:
WAN Connectivity StandardsVarious connection options are required to service the generic site models of the four site types. These models derive varying site-level SLAs that can provide alignment against the level of criticality to the business. Although you can select many permutations, Acme has categorized its requirement model as shown in Figure 4-9. Figure 4-9. Connectivity Option Overview These provide the characteristics that can be used to derive the SLA delivery for sites against
Acme's needs require it to be translated to the service provider connectivity options, matching against Layer 2 transport to connect to the MPLS network. It also derives the performance assurances the service provider will deliver through its SLA. Examples of these can be seen in Chapter 8. The importance of these topologies plays on the routing elements, which in turn derive aspects of the SLA when it comes to convergence and availability aspects of the topologies employed. Where redundancy is applied in the chosen topology, you must consider the CE-PE routing in the MPLS VPN environment, especially where potential routing loops are concerned. Site Type A Attached Sites: Dual CE and Dual PEEstablishing the connectivity for the most critical sites within Acme follows the model of dual CEs and dual PEsdiversity of connectivity. (Diversity is the complete service provider resilience of Layer 1, Layer 2 connectivity to the service providerno common duct/trunking, a separate service provider carrier office [CO] facility, and so on.) This provides protection from link-level failures to PE and CE failure protection, as shown in Figure 4-10. This presents some challenges:
Figure 4-10. Dual-Homed Connectivity (Diverse) Extending this redundancy option would be connecting to a second service provider MPLS VPN to increase resilience and avoid complete service failure from one service provider. This introduces other challenges in the form of route exchange, if required, between two service providersthrough back-end inter-autonomous system (AS) VPN peering arrangements or through managing eBGP connectivity between multiple service provider autonomous systems on the enterprise side. Figure 4-11 shows an overview of this model. Figure 4-11. Dual-Attached SiteDual Service Providers Backdoor links need to be guarded against in the multihomed scenarios just shown. Loops don't occur when a site is only a stub, but in the multihomed environment, these can be prevented through the application of Site of Origin (SoO) by the service provider. A backdoor link or route is a connection that is configured outside the VPN between a remote site and a main site. An example is a WAN leased line that connects a remote site to the corporate network. Backdoor links are typically used as backup routes between EIGRP sites if the VPN link is down or unavailable. A metric is set on the backdoor link so that the route through the backdoor router is not selected unless a VPN link fails. The SoO extended community is defined on the backdoor router's interface. It identifies the local site ID, which should match the value that is used on the PE routers that support the same site. When the backdoor router receives an EIGRP update (or reply) from a neighbor across the backdoor link, the router checks the update for an SoO value. If the SoO value in the EIGRP update matches the SoO value on the local backdoor interface, the route is rejected and is not installed to the EIGRP topology table. This typically occurs when the route with the local SoO value in the received EIGRP update is learned by the other VPN site and then is advertised through the backdoor link by the backdoor router in the other VPN site. SoO filtering on the backdoor link prevents transient routing loops from occurring by filtering out EIGRP updates that contain routes that carry the local site ID. If this feature is enabled on the PE routers and the backdoor routers in the customer sites, and SoO values are defined on both the PE and backdoor routers, both the PE and backdoor routers support convergence between the VPN sites. The other routers in the customer sites only need to propagate the SoO values carried by the routes, as the routes are forwarded to neighbors. These routers do not otherwise affect or support convergence beyond normal Diffusing Update Algorithm (DUAL) computations. Site Type B/3 Dual-Attached SiteSingle CE, Dual PEThe option of connecting a site with a single CE to two PEs provides protection against service provider failures at either the PE level or the link level. You must take into consideration routing loops and convergence times. Load sharing can be achieved on a per-destination basis or by weighting links so that they operate a primary/backup mechanism. Figure 4-12 provides an overview of this option. Figure 4-12. Dual-Attached SiteSingle CE, Dual PE Site Type B/3 Dual-Attached SiteSingle CE, Single PEWhere demand for link protection is a necessity, the option of connecting with dual paths between the CE and PE provides a simple solution. This protects against carrier link failures. Load balancing can be done either per-destination or by distributing based on equal-cost paths. CEF can deliver the per-packet or per-destination solution. The per-destination, which is the default mechanism, is typically the preferred option. Figure 4-13 provides an overview of this option. Figure 4-13. Dual-Attached SiteSingle CE, Single PE Site Type D Single-Attached SiteSingle CE with BackupWhere the option for a single attached site is pursued for smaller field sites, consideration should be given to recovery in the event of link loss or service provider failure. As soon as the link or service is restored, the backup service should cease. There are multiple ways to do this. The most common is ISDN-based dial between the CE and the service provider network, with the service provider network initiating the call to the CE on failure detection. ISDN is being replaced by xDSL connectivity either direct to the service provider network or as an Internet-based VPN service in many enterprise implementations. However, this can be more complex to implement. Acme pursued the option of Internet-based VPN where available on a cost basis. An example of how this was implemented is discussed later in this chapter. Figure 4-14 shows a single-attached site with backup via ISDN or Internet. Figure 4-14. Single-Attached Site with Backup Via ISDN or the Internet Convergence: Optimized RecoveryConvergence, in routing terms, is the time taken to converge to a new path when a path fails or a new route is introduced within the network. Table 4-1 documents the mechanisms of provider convergence, which the enterprise needs to be aware of.
When assessing how convergence will impact the network recovery, keep in mind these two main elements:
Although the service provider is responsible for optimizing the recovery of its backbone network, it is the joint collaboration between the service provider and the enterprise that improves edge convergence times. IP AddressingThe addressing within the enterprise is maintained when implementing an MPLS VPN; however, it is strongly advisable to take the time to allocate site-based blocks that can be easily summarizedthus reducing the need to announce unaggregated addresses toward the service provider. This streamlines routing tables and improves the network's operational support. When it comes to the links between the service provider and the enterprise, the service provider should provide the enterprise with address space to facilitate this. Typically, the addresses are delegated from public address space by the service provider. In some cases, the service provider may prefer to use unnumbered PE-CE links. Addressing can be a key point that drives whether it will be possible to integrate the IGP between the CE and PE. For example, if unnumbered links were to be used, the implication is that the service provider is sharing the loopback address on its PE with multiple customers to optimize address allocation. This also makes it easier for the service provider to secure the PE, because the policies are based on PE loopback addresses and not IP interface addresses. Other alternatives to this are as follows:
Where shared network management is taking place (that is, when ownership of the CE still resides with the enterprise but the service provider is given management access for SLA purposes), careful allocation of address space is a necessity. Typically, this is RFC 1918 address space. To ensure that management options are not restricted, it is advisable to use IP numbered interfaces between the CE and PE, with an RFC 1918 address assigned to loopback interfaces. Where shared management is required, it is important to align with the service provider the use of these blocks to ensure consistency. Routing Between the Enterprise and the Service ProviderAs you will see in the case of Acme, two mechanisms can be employed to route between the service provider and the enterprise. The more common of these is the use of BGP between the CE and PE. However, this sacrifices some aspects of routing information, such as route metrics, while adding the need to operate and support multiple routing protocols. Some enterprises are not geared to such change. In any event, it is often a required balance. Multihomed sites, or sites with multiple service provider demarcations, may benefit from the use of BGP as the routing protocol between the CE and PE. The simplification to be gained by running the IGP between the CE and PE reduces the change needs for the greater number of sites. Any use of IGP between the CE and PE must be able to provide the same, or similar, security as delivered by BGP, as well as be able to handle multiple route policies. In the case of Acme, the use of BGP was maintained in the Site Type A sites while all other sites were delivered using EIGRP between the CE and PE. This allowed for maintenance of routing metric information that would otherwise have been lost. Using EIGRP Between the CE and PEThe EIGRP IP network routing solution is well known to enterprise customers, who take advantage of its greater optimization of path routing, fast convergence, and lower CPU usage benefits. EIGRP allows service providers to more rapidly and cost-effectively deploy IP VPN services for their customers. In turn, enterprise customers can more quickly enjoy affordable, efficient, and secure managed VPNs. IP/MPLS VPNs deployed using site-to-site EIGRPrather than external BGP or static routeseliminate the need for enterprise network staff to learn new protocols. By integrating the capabilities of link-state and distance vector protocols, EIGRP greatly increases operational efficiency in networks of all sizes. It is highly scalable for large networks, giving bigger enterprises the confidence they need to implement managed services offered by service providers. Why do service providers support EIGRP as PE-CE?
How EIGRP MPLS VPN PE-to-CE WorksEIGRP MPLS VPN support allows native EIGRP to run on PE-CE links, requiring no upgrade of existing enterprise customer equipment or configurations. All necessary equipment or configuration changes are consolidated to the PE routers, as shown in Figure 4-15. BGP redistributes routes into EIGRP using route type and metric information extracted from BGP extended community information. Figure 4-15. Redistributing EIGRP into BGP Without EIGRP PE-CE support, normal redistribution of EIGRP into BGP (and vice versa at the PE) would result in intersite EIGRP routes appearing as external routes in the target CE cloud. The loss of the original route attributes would result in all routes traversing the MPLS VPN backbone becoming less preferable than the routes that do not traverse the MPLS VPN backbone. To solve this problem, redistribution of EIGRP metrics are preserved across the MPLS VPN backbone through the use of MP-BGP extended community attributes. The EIGRP route type and vector metric information is encoded in a series of well-known attributes. These attributes are transported across the MPLS VPN backbone and are used to re-create the EIGRP route when received by the target PE router. The MPLS VPN backbone is treated as another transport to pass EIGRP route information from one customer site to its peering site. EIGRP routes are redistributed into BGP with extended community information appended to the BGP route. BGP then carries this route over the MPLS VPN backbone, with the EIGRP-specific information encoded in the BGP extended community attributes. The EIGRP route information appears as any other MPLS label-encapsulated data within the VPN backbone. Routing protocols within the MPLS VPN backbone have nothing to do with the enterprise routes. After the peering enterprise site receives the route, BGP redistributes the route into EIGRP. EIGRP then extracts the BGP extended community information and reconstructs the route as it appeared in the original enterprise site. PE Router: Non-EIGRP-Originated RoutesOn the PE router, if a route is received via BGP and it has no extended community information for EIGRP, it is advertised to the CE router as an external EIGRP route using the default metric. If no default metric is configured, the route is not advertised to the CE router. PE Router: EIGRP-Originated Internal RoutesIf a route is received via BGP and it has extended community information for EIGRP, the route type is set to "internal" if the source's AS matches. If the source AS fails to match the configured AS for the given VPN VRF Cisco IOS route table instance, the rules for non-EIGRP-originated routes hold. The internal route is then reconstructed and advertised to the CE router as an internal EIGRP route using the extended community information. EIGRP supports internal and external routes. Internal routes originate within an EIGRP AS. Therefore, a directly attached network that is configured to run EIGRP is considered an internal route and is propagated with this information throughout the EIGRP AS. External routes are learned by another routing protocol or reside in the routing table as static routes. These routes are tagged individually with the identity of their origin. External routes are tagged with the following information:
Route tagging lets the network administrator customize routing and maintain flexible policy controls. Route tagging is particularly useful in transit autonomous systems, where EIGRP typically interacts with an interdomain routing protocol that implements more global policies, resulting in very scalable, policy-based routing. PE Router: EIGRP-Originated External RoutesIf a route is received via BGP and it has extended community information for EIGRP, the route type is set to "external" if the source AS matches. If the source AS fails to match the configured AS for the given VRF, the rules for non-EIGRP originated routes hold. The external route is then reconstructed and advertised to the CE router as an external EIGRP route using the extended community information. Multiple VRF SupportOn a PE router, one instance of EIGRP can support multiple EIGRP MPLS VPN VRFs. Support for each VRF translates into its own EIGRP process. The number of EIGRP processes depends on the available system resources and the number of supported VRFs on a given platform. An EIGRP process is always created for the default routing table. Extended Communities Defined for EIGRP VPNv4No EIGRP adjacencies, EIGRP updates, or EIGRP queries are sent across the MPLS VPN backbone. Only EIGRP metric information is carried across the MPLS VPN backbone via the MP-BGP extended communities. The PE router is part of the EIGRP network; therefore, all EIGRP protocol-specific behavior with MPLS VPNs is no different than with any other regular EIGRP network. As mentioned before, the MPLS VPN backbone is treated as a transport. For EIGRP to re-create metrics derived from the originating enterprise site, the PE router encodes the original metric in MP-BGP extended communities. BGP may then transport these extended communities across the MPLS VPN backbone. Metric PropagationThe PE router re-creates routes and sends them to the CE router as an EIGRP route, as shown in Figure 4-16. The same route type and cost bases as the original route are used to re-create the EIGRP route. The metric of the re-created route is increased by the interface's link cost. You can make the MPLS VPN backbone or the backdoor link the preferred path by adjusting the metrics. Figure 4-16. EIGRP Between the CE and PE For a given Network X, in the CE 1 router, the following things happen:
Note At this point, CE 2 has the same information as CE 1 for Network X. Configuring EIGRP for CE-to-PE OperationConfiguring EIGRP operation on the CE router requires little change over the normal operations of EIGRP for the enterprise. Example 4-1 provides a sample configuration. Example 4-1. Configuring EIGRP Between the CE and PE
In the preceding Acme CE EIGRP routing example, a simple policy is applied to do the following:
This policy services the needs of all the Acme sites that are using EIGRP between the CE and PE. In the case where there are multiple interfaces toward the service provider PE, the same policy can be applied to the additional interfaces under the EIGRP router configuration. The permit of the default route ensures reachability to the Internet. In the case of Acme, this is generated from the Internet connection point of presence (PoP) in the Site Type A site. The implicit deny that is incorporated into the OUTBOUND prefix list ensures that sites cannot resend a default toward the network and cause routing anomalies. Using BGP Between the CE and PEConfiguring BGP (eBGP) between the CE and the PE requires that the local site redistribute its local routes into BGP and learn through redistribution external routes from BGP. CE routers need to have specific policies applied to ensure that the correct routes are being learned from BGP and that the correct routes are being injected into the MPLS VPN BGP process from the local site. Example 4-2 shows the configuration required to do this. Example 4-2. Configuring BGP Between the CE and PE
This provides the basics of the BGP configuration. The policy needs to be set. This is handled as shown in Example 4-3. Example 4-3. Setting the Redistribution Policy on the CE
Route filtering is employed, as before in the EIGRP example, to ensure that no bogus or unintentional routes are introduced into the MPLS VPN. The policy is a simple one that can be extended to include specific routes within the enterprise domain. As in the EIGRP example, these are used to do the following:
This filter could be extended to include the filtering of undesired RFC 1918 address blocks (10.0.0.0/8, 172.16.0.0/16, 192.168.0.0/16), provide granular filtering based on lengths (le) of address blocks greater than a certain desired size, and deny any subnet originated by the service provider (other than those desired for management purposes). The final aspect is to permit all other routes. Securing CE-PE Peer SessionsThrough the use of encrypted passwords for neighbor authentication, either with EIGRP or BGP, the use of MD5 is preferred. When neighbor authentication is enabled, the receiving router authenticates the source of the routing updates by using a shared key that the source and the receiver have been set up with. MD5 authentication ensures that no plaintext sending of the key occurswhere the key is sent in the clear and is open to compromise. MD5 creates a hash by using the key and the message. Example 4-4 demonstrates this for BGP. Example 4-4. Configuring MD5 Authentication for BGP Peers
Improving BGP ConvergenceYou might need to tune the BGP convergence parameters. This applies to CE-PE recovery times when losing a link and improving the BGP advertisement times. This applies to the CE side configuration. The PE side is the responsibility of the service provider. However, enterprises are encouraged to work with service providers to test and validate the correct alignment of convergence needs to ensure operational integrity. When you use a directly connected interface for the eBGP session between the CE and PE, a link failure causes the eBGP session to go down immediately. Failure detection for nondirectly connected eBGP peers depends greatly on the BGP hold timer. The holdtime timer defaults to 180 seconds for nondirect peers. The BGP next-hop validation time (known as the scan-time timer) defaults to 60 seconds. From this it could, in worst cases, cause longer convergence times, depending on the peer mechanism employed and the configured parameters for the holdtime and scan-time timers. eBGP sessions don't go down immediately when a transit interface fails. There are mechanisms to fine-tune these. Principally, these depend on the peer mechanism employed. BGP fast-external-failover applies only to directly connected eBGP sessions, for example. Thus, when peering indirectly, BGP relies on keepalive and holdtime timers or BGP scan-time to check activities. Scan-time can be tuned from its default of 60 seconds to 30 seconds. However, this can affect where static routes are employed, thereby pointing to a false or unavailable peer when no end-to-end signaling capability exists. Low scan-time configurations also affect the CPU when a large number of routes are present. Adjusting the keepalive and holdtime values from their defaults on the CE causes BGP to select the smaller of the two hold timesfor example, changing to 10 seconds for keepalive and 30 seconds for holdtime. Tuning can also be done on the advertisement interval. The default advertisement interval is 60 seconds; this can be tuned to 0. On the CE side, this can be lowered to 15 seconds, but you should ensure that the PE side is also 15 seconds. It is critical to work with your service provider to ensure that tuning is matched to its configured parameters. Example 4-5 is a sample of the required CE side configuration. Example 4-5. Tuning CE Configuration Timers
|
EAN: 2147483647
Pages: 136