WAN Services
| The most common WAN services currently offered by providers are as follows:
In addition, it is common for an enterprise to deploy overlay networks on top of these services. Some of the most widely used overlays are as follows:
The following sections describe these services and overlays in more detail. IP ServicesIP services are among the most common types of WAN services available from providers. These can be public services such as the Internet or private IP VPNs. In either case, IP services provide any-to-any site connectivity to the enterprise. Such connectivity makes the service particularly attractive to the enterprise because it can integrate the WAN IP cloud into its own Layer 3 routing. Figure 7-1 shows a Multiprotocol Label Switching (MPLS)-based provider cloud with separate IP VPNs for customers X and Y. The figure displays shared services offered by the provider and the capability of creating extranet connectivity for partners to customers X/Y. Figure 7-1. WAN IP Services To optimize their operations and minimize their costs, service providers use different technologies to provide IP connectivity for enterprises. One widely used technology is MPLS; other alternatives to create IP VPNs are based on Layer 2 Tunnel Protocol Version 3 (L2TPv3) or even GRE. However, the technology used by the service provider should not matter to the enterprise. All an enterprise should be concerned about is the fact that it is getting IP services. This service implies routed hops in the WAN that the enterprise does not control. The lack of control over the Layer 3 hops in the IP WAN affects the capability of the enterprise to maintain multiple VNs per customer across the WAN cloud. It is important to note at this point that the scenario we face is the need to create multiple VNs inside each customer VPN present in the provider network. For instance, customer X might have two internal groups: contractors and employees. In this case, Customer X requires a single service provider VPN and two VNs, one for contractors and one for employees, to be transported separately inside the service provider VPN. To maintain the separation between VNs across the IP WAN, an overlay of logical circuits is usually required. For example, a full mesh of GRE tunnels between the customer edge (CE) routers provides a logical topology in which the enterprise controls all routed hops. For the purposes of IP control and forwarding, the tunnels create a direct logical connection between the enterprise routers, thus bypassing the provider's routers. This overlay allows the enterprise to use hop-to-hop (h2h) virtualization techniques in an IP WAN. Other alternatives include the use of separate IP VPN services per group and the use of carrier supporting carrier (CsC) services from the WAN provider. We discuss all these options in detail later in this chapter. Layer 2 CircuitsLayer 2 circuits such as Frame Relay and ATM circuits are the traditional way in which service providers have offered WAN connectivity. More recent technologies have extended these offerings to include Ethernet services, allowing the enterprise to connect to the WAN over a familiar Ethernet interface. Whichever the case, these p2p Layer 2 circuits can be deployed in a hub-and-spoke topology or in a full mesh, as depicted in Figure 7-2. Over these topologies, enterprises can deploy and manage their own IP routing. This gives the enterprise complete control over the IP forwarding and control planes, which enables it to implement different IP-based technologies to provide the desired segmentation in the WAN. Figure 7-2. WAN Layer 2 Circuits P2P GREPoint-to-point GRE tunnels can be overlaid onto a private IP VPN or a public IP service such as the Internet. As discussed previously, this tunnel overlay creates a logical topology for the enterprise to deploy its own IP routing independently of the IP routing provided by the service provider. Thus, there are two independent IP control planes in operation:
The enterprise routing process sees the mesh of GRE tunnels as the set of interfaces it can use to forward traffic and reach the different destinations. The enterprise prefixes need to be included only in the enterprise routing process, which also includes the GRE tunnel interfaces, as described in Chapter 6, "Infrastructure Segmentation Architectures: Practice." Therefore, the enterprise will use a separate interior gateway protocol (IGP) that peers over the mesh of GRE tunnels. Figure 7-3 shows how the address spaces for the provider cloud and the enterprise are kept separate as the service provider peers over the physical topology and the enterprise peers over the logical tunnel overlay. In the diagram, the 192.168.x.0/24 and the 10.0.0.0/24 networks are part of the enterprise address space inside the logical topology established by the tunnels. The physical interfaces are in the service provider address space, illustrated with the 172.x.x.x IP addresses on the physical interfaces in Figure 7-3. Figure 7-3. P2P GRE Tunnel Overlay on an IP WAN The mesh of GRE tunnels can be seen as a form of VPN in itself, a view further enhanced by the association of the GRE tunnel mesh to independent routing tables or virtual routing and forwarding (VRF) instances. Another important element that enhances this type of deployment is the ability to encrypt the GRE connections with IPsec. The combination of GRE and IPsec is instrumental in providing concurrent support for encryption and multicast traffic. The multicast support provided through the GRE encapsulation is necessary for the deployment of the enterprise IGP over the mesh of tunnels. Encryption is critical whenever the IP service is shared with other users. Multipoint GREThe GRE tunnel overlay solution can be improved by consolidating the multiple tunnel interfaces used at a hub site into single multipoint tunnel interfaces. However, this approach is restricted to providing a hub-and-spoke logical topology in which the hub hosts a multipoint GRE (mGRE) tunnel interface and each spoke has a single p2p GRE tunnel going back to the hub. Even though we use the same any-to-any Layer 3 adjacency mesh that is used for the p2p GRE overlay, traffic between spokes will always transit the hub site as shown in Figure 7-4. DMVPN, described in the next section, provides a means to achieve a more efficient spoke-to-spoke traffic path. Figure 7-4. mGRE Tunnel Overlay on an IP WAN Dynamic Multipoint VPNDynamic multipoint VPN, better known as DMVPN, provides a mechanism to build an efficient and manageable GRE tunnel overlay with encryption. DMVPN relies on the use of multipoint GRE interfaces at the hub-and-spoke sites while dynamically building tunnels between spokes to allow direct spoke-to-spoke connectivity. The solution relies on the Next Hop Resolution Protocol (NHRP). Each spoke registers its address with the NHRP database at the hub when it first connects. This information is then used to provide tunnel selection at the hub site. At the spokes, the NHRP database is queried by the spokes to resolve the real addresses of destination spokes and build direct tunnels between spokes, as shown in Figure 7-5. DWVPN is analyzed in more detail in Chapter 5. Figure 7-5. DMVPN Overlaid to an IP WAN |
EAN: 2147483647
Pages: 128