WAN Design


The WAN provides connectivity between the different sites of an enterprise. In general, WAN design involves the aggregation of many branch sites into one headend site in a hub-and-spoke fashion. The headend site is usually located at the main enterprise campus where key computing resources can be accessed at a data center. Large enterprises often have several headend sites that service diverse branches according to geographic proximity. Figure 2-4 shows a typical WAN distribution of headend sites and branches. These head-end sites must also be interconnected, thus we breakdown the problem of the WAN in two: Branch Aggregation and Site Interconnection.

Figure 2-4. WAN


WAN Provider Service Offerings

Because the WAN uses connectivity services from a service provider, many variations exist as to traffic aggregation and security. The different types of wide-area services can be broadly categorized as private services or public services, providing either point-to-point or point-to-cloud connectivity, as shown in Figure 2-5.

Figure 2-5. WAN Service Types. Point-to-Point vs. Point-to-Cloud Connectivity


Examples of private services providing point-to-point connectivity are traditional services such as leased lines (PPP, High-Level Data Link Control [HDLC]), Frame Relay, and ATM. Meanwhile, the Internet is an example of a service that is publicly shared and allows multipoint connectivity (because each point is connected to an IP cloud).

In general, private point-to-point services are perceived as secure and not requiring encryption. In contrast, public services such as the Internet require an overlay of encrypted logical circuits to form VPNs on the shared WAN.

Depending on the WAN service, the enterprise network may be a mesh of physical or logical circuits. To successfully scale the mesh of circuits, a hub-and-spoke topology, such as that shown in Figure 2-6, is used. This can be a static topology in which the hub acts as the headend for the network. In this scenario, all traffic traverses the headend, including spoke-to-spoke traffic.

Figure 2-6. Tunnel Overlay on a Shared CloudHub-and-Spoke Topology


Alternatively, techniques such as dynamic multipoint VPN (DMVPN) allow for the dynamic creation of circuits to allow direct spoke-to-spoke connectivity. Such techniques require an IP-based WAN service capable of providing point-to-cloud (or multipoint) connectivity. Figure 2-7 illustrates the dynamic creation of circuits in a DMVPN WAN.

Figure 2-7. Dynamic Spoke-to-Spoke Overlay Connectivity


Aside from the Internet, service providers are increasingly providing private IP-based WAN services that allow private point-to-cloud connectivity. This type of service is known as IP VPN. In theory, an IP VPN service should not require encryption. However, many customers think IP VPNs are not as secure as private virtual circuits and therefore call for an encryption overlay that renders a static or dynamic hub-and-spoke topology similar to that discussed for the Internet.

Regardless of the WAN service purchased or the circuit overlay implemented in the WAN, certain principles must be followed in architecting the WAN. Namely, the WAN must be hierarchical, modular, and resilient. The following section discusses these architectural design principles.

WAN Architecture

The WAN architecture should provide hierarchy, modularity, and resiliency. Similar to the campus architecture principle of hierarchy, the different devices in the WAN have different roles depending on the hierarchy they occupy. The hierarchical network layers in the WAN are similar to those proposed for campus networks: access, distribution, and core (as shown in Figure 2-8). However, the roles and functionality of the devices at each layer differ from those that are required in the campus.

Figure 2-8. WAN Hierarchical Architecture


The branch-end routers at the access layer provide the branches access to the WAN, and all traffic from the access layer devices is aggregated by the WAN aggregation routers at the distribution layer. The aggregation routers connect into the network core, which provides connectivity between the aggregation routers, the VPN headend devices, and the campus core.

In the hub-and-spoke topology, the branch routers represent the access layer. These routers, known as branch-end routers, terminate the WAN interfaces to the service provider, connect to the local-branch LAN segment, and provide IPsec and generic routing encapsulation (GRE) tunnel termination when necessary.

The distribution layer is implemented with pairs of WAN aggregation routers. All traffic from the access layer devices is aggregated by the WAN aggregation routers. In an implementation over a Layer 3 service provider providing point-to-cloud connectivity (Internet service provider [ISP]), these routers would have a high-speed WAN interface and one or more high-speed Ethernet interfaces. They would typically be external Border Gateway Protocol (eBGP) peers with the ISP's edge routers and would peer via internal Border Gateway Protocol (iBGP) between all WAN aggregation routers. This Layer 3 peering provides the single connection to the cloud required to aggregate WAN traffic from a point-to-cloud service such as an ISP or IP VPN provider.

In an implementation with a Frame Relay service provider or point-to-point network, the distribution layer WAN aggregation routers have one or more high-speed WAN interfaces and hundreds of subinterfaces/DLCIs (data-link connection identifiers), one for each branch. In this scenario, each WAN aggregation router must maintain a separate circuit for each branch.

The core layer is implemented with pairs of high-performance multilayer switches such as the Catalyst 6500. These switches provide connectivity to the network core and provide redundant Layer 2 and Layer 3 connectivity between the WAN aggregation routers and the IPsec/GRE headend routers. Thus, different devices at different network layers aggregate traffic and terminate IPsec/GRE tunnels.

The IPsec/GRE headend routers terminate the IPsec peers and the IP GRE tunnels. They advertise the branch subnets learned through the tunnel interfaces to the core switches.

Dedicating routers for a specific function at the network core provides several advantages:

  • The performance characteristics of the IPsec/GRE headend might dramatically differ from those of a WAN aggregation router.

  • Separating the two functions allows different ratios between IPsec/GRE headends and WAN aggregation: Two WAN aggregation routers might be sufficient for four IPsec/GRE headends.

  • WAN aggregation routers require a lower average CPU busy percentage to accommodate CPU spikes.

  • WAN aggregation routers running Border Gateway Protocol (BGP) might experience considerable CPU spikes during network instability because of link flaps, for example.

  • In addition, the separation of roles allows different versions of Cisco IOS Software to be run at different locations in the network topology. For example, the WAN aggregation router can run a General Deployment (GD) release of 12.0 mainline, whereas the IPsec/GRE headend routers may need an Early Deployment (ED) release to support a new hardware encryption accelerator.

The advantages and flexibility of this design outweigh the additional capital costs involved in separating the WAN aggregation from the IPsec/GRE headend.

WAN Resiliency

When using a point-to-point service, it is recommended to provision two circuits out of each branch-end router, connecting the branch to both headend routers. As Figure 2-9 shows, this setup involves the provisioning of a permanent virtual circuit (PVC) for each branch at the headend routers and the provisioning of two PVCs at each branch-end router to connect with the redundant headend points. In this model, load balancing and failover are achieved via the routing protocol enabled between the branch routers and the core routers.

Figure 2-9. Dual-Circuit Resiliency


An alternative to deploying dual PVCs is to provide ISDN dialup connections as backup links. Figure 2-10 shows this resiliency mechanism.

Figure 2-10. ISDN Backup


When IPsec or GRE tunnels are overlaid onto the WAN, resiliency must be provided for the tunnels (as shown in Figure 2-11). Each branch router can provide two IP GRE tunnels, one to each pair of IPsec/GRE headend routers. This setup provides for an alternate path in the event a headend router is taken out of service.

Figure 2-11. Resilient Tunnel Overlay


Alternatively, IPsec/GRE stateful resiliency mechanisms can be used to avoid the use of dual tunnels to the headend site. As shown in Figure 2-12, with IPsec/GRE stateful resiliency, the headend site is seen as a single router site by the branches, allowing the establishment of a single tunnel between each branch and the redundant pair of headend routers while still preserving the required headend resiliency.

Figure 2-12. Stateful Resiliency for IPsec/GRE


WAN Routing Considerations

Depending on the type of WAN service purchased, different routing challenges must be considered.

For an IP service (point-to-cloud), exchange of routes between the enterprise and the provider cloud is necessary. This is usually achieved by using eBGP between the enterprise routers and the service provider (some providers support the use of IGPs for provider edge-to-customer edge (PE-CE) integration of IP VPN services). Figure 2-13 shows the routing adjacencies necessary to connect to a point-to-cloud type of service.

Figure 2-13. Point-to-Cloud IP Service Routing Adjacencies


It is common to overlay a mesh of IPsec/GRE tunnels to provide encryption over an IP service. In this case, two types of routing information must be present:

  • Routes for the endpoints to reach each other and establish the tunnels

  • Routes for the traffic at the sites to use the encrypted tunnels to reach remote destinations

These routes are all part of the same control plane. Therefore, to ensure that traffic between sites uses the tunnels, the traffic must be engineered based on its source and destination. You can do so by tweaking the routing protocols to use the tunnels for inter-site communication, or you can use policy-based routing to inject traffic into the tunnels as needed.

When virtualizing the network, you can use the same mesh of IPsec/GRE tunnels to create IP VPNs over an IP service. In this scenario, the tunnel interfaces are assigned to a routing table that differs from that used to establish the tunnels. Thus, the tunnel overlay forms VPNs that require a routing overlay additional to the routing used to provide connectivity into the IP cloud and between the tunnel endpoints. As depicted in Figure 2-14, two routing control planes will be active in an IP cloud supporting VPNs, one global control plane providing connectivity between all branch and headend routers and a VPN-specific control plane that transports routing updates for the different VPNs. The routing overlay for the VPNs will benefit from similar best practices as those described for point-to-point services, which are discussed next.

Figure 2-14. IP Service with VPN Overlay Routing Adjacencies


Note

This model and many others for creating VPNs in the WAN are explored in detail in Chapter 7, "Extending the Virtualized Enterprise over the WAN."


For point-to-point services, no route exchange occurs between provider and enterprise. Routing adjacencies for the enterprise's IGP are established over the overlay of point-to-point tunnels. For these routing adjacencies, it is advisable to summarize the routes from the branches into the core.

Note

The summarization of routes allows a single IP prefix to represent many subnets in the branch. A failure in one of the subnets will not alter the advertised route and therefore will not cause any sort of reconvergence.


Advertising default routes from the core (headend) into the branches greatly simplifies the routing overlay and reduces the size and number of routing updates necessary. By choosing an IP addressing scheme capable of accommodating such use of the IP address space, you can reduce the burden on the routing protocols and thus accelerate convergence times and minimize potential network reconvergence by creating a simple routing hierarchy that isolates failures. Figure 2-15 shows these routing recommendations.

Figure 2-15. Point-to-Point Service Routing


Securing the WAN

Securing the WAN involves two main tasks: protecting the perimeter and securing the transport.

The protection of the perimeter involves the use of firewall functionality at the branch-end routers and at the headend.

The most widely used mechanism to secure the transport in the WAN is IPsec encryption. Because IPsec is a point-to-point technology, its use can alter the logical topology of the WAN. If the logical topology is altered, chances are that resiliency is also affected. Therefore, it is necessary to be able to support routing protocol adjacencies over the tunnels created by the IPsec overlay. Many IGPs use multicast to maintain communications between routers. Multicast is not natively supported by IPsec, and therefore an auxiliary tunneling mechanism is required to transport the multicast and still be able to encrypt the traffic (achieved by combining IPsec with GRE encapsulation). The main principle is that of encapsulating all traffic, including the multicast, in a GRE tunnel and then encrypting the contents of the GRE tunnel. Not all enterprises require support for multicast as their resiliency models may not rely on routing protocols. However, a resiliency model based on routing protocols has proven to deliver the best results and is therefore recommended.

The combination of IPsec and GRE tunnels leads to several deployment scenarios depending on the dynamic or static nature of the tunnels.

The simplest scenario is that in which plain IPsec encapsulation is used. As previously discussed, IPsec alone will not support multicast and, therefore, IGP updates. Plain IPsec designs require resiliency mechanisms such as stateful IPsec failover at the headend, which basically eliminates the need to provision dual tunnels from the branch to the headend while still providing headend resiliency. Because routing updates are not able to traverse the IPsec overlay, this solution must rely on static routing or unicast-based routing protocols such as BGP. This solution lacks support for any type of multicast traffic or any non-IP protocol.

When support for an IGP across the IPsec overlay is required, and this is a common requirement when virtualizing networks, it is necessary to combine GRE tunneling with IPsec encryption. You can establish the GRE tunnel mesh in many ways, including static point-to-point GRE, dynamic point-to-point GRE, and dynamic multipoint GRE. All of these tunnel meshes support IPsec encryption, but the most flexible combination is provided by DMVPN, which combines dynamic multipoint GRE with the dynamic creation of IPsec tunnels. Chapter 5 "Infrastructure Segmentation Architectures: Theory" discusses this technology and other relevant technologies in detail.

WAN Virtualization

The challenge of virtualizing the WAN is in preserving the required hierarchy and resiliency while deploying an increased number of VPNs over the WAN in a cost-effective manner. Doing so may lead to the creation of VPNs or tunnels within provider VPNs. The proliferation of VPNs in the WAN brings with it the challenge of managing a more-complex logical topology and sets higher expectations for a processing hierarchy that will scale to support the increased number of VPNs.

Chapter 5 "Infrastructure Segmentation Architectures: Theory" discusses the different techniques available for the creation of VPNs in the WAN, based on the foundation technologies introduced in Chapter 4 "A Virtualization Technologies Primer: Theory."

Chapter 7 "Extending the Virtualized Enterprise over the WAN" discusses in detail the design recommendations and best practices an enterprise must follow when virtualizing the WAN.




Network Virtualization
Network Virtualization
ISBN: 1587052482
EAN: 2147483647
Year: 2006
Pages: 128

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net