Tunnel Overlay for L3VPN
| The tunnel overlay architecture has been in use in WANs for quite some time. Typically, GRE or IPsec is used to connect private networks together over a public infrastructure. Tunnel-based solutions sometimes get bad press for being unscalable, or operationally complex, but this is unfair. With a correctly defined problem, tunnels often represent an excellent answer. Scalability issues can arise if you use p2p linkswhich is what a tunnel isto build multipoint connectivity, which is what a LAN offers. With that caveat firmly in mind, we look first at p2p and then p2mp alternatives for Layer 3 connectivity. The next section uses the same approach to look at Layer 2 connectivity (for data center-to-data center clustering, for example). L3VPN Using GRE and IPsec OverlayThe basic topology for a tunnel-based Layer 3 VPN is to use a hub-and-spoke architecture. In its most simple expression, such a network has a single, central site, called a hub, to which are connected all the other sites in the network, called spokes. The name comes from an analogy with a wheel: a single point that connects all the others. The advantage of hub-and-spoke architecture is that the operation of the spoke routers is simple. All their traffic is forwarded to the hub router, and they use a straightforward default route. The hub must route traffic back to the correct site and announce the site addresses to the rest of the network. As long as there is some degree of flexibility in the network address plan, the hub router can aggregate the prefixes used on the site networks. Provisioning is equally simple. The configuration is almost identical on each spoke router, with IP addresses and passwords (possibly) differing from one site to the next. It is easy to automate the setup and bulk provision many such devices quickly. The GRE and IPsec solution uses GRE p2p tunnels between customer premises equipment (CPE) devices and encrypts the GRE packet with IPsec. This combination enables you to use GRE over public networks. The GRE implementation enables you to run multicast, routing protocols, or even carry non-IP traffic between sites, but by itself offers no security whatsoever. Adding IPsec to the hub-and-spoke architecture solves the security issue but adds a little more complexity to the overall picture:
The combination of GRE and IPsec is so common that Cisco IOS configurations use a special command to enable encryption directly on the GRE tunnel interface itself. Example 5-1 shows such a configuration, in which the HUB-VPN crypto map is applied to the tunnel interface. You do not need to define an ACL that matches the local and remote addresses and IPsec protocol type (or ports); the router does this automatically, which is convenient. Example 5-1. GRE and IPsec Tunnel Configuration
Note how the Comment field in Example 5-1 refers to Spoke1. This touches on one of the major drawbacks of simple hub-and-spoke networks, at least with GRE+IPsec. The hub must have a different tunnel interface for every spoke. Add a new spoke and you must also configure the hub router. Not only does this add a provisioning step, but the hub configuration file can grow to be large, which has never been known to improve the troubleshooting experience. The gravity of the other main limitation of this architecture depends on the network traffic patterns. If spoke traffic naturally flows to the hub, which provides Internet access for an enterprise, for example, or houses the main data center, such a centralized network makes perfect sense. If there is traffic between the spokes, the topology is inefficient because inter-spoke traffic still goes through the hub router, creating an obvious bottleneck. In fact, high-throughput networks, even one where the traffic does flow to a main site, can also pose problems because the overall network throughput is limited by either the performance of the hub router (which is not usually an absolute limitationyou can buy fast routers) or by the interface speeds on the hub, either on the ingress or egress sides. If you do have a bottleneck, the workaround is obvious: Use multiple hub routers and load balance sites between them. The simple network in Figure 5-4 has two branch sites connected to a main site, with two hub routers. The main site provides Internet connectivity for the branch sites. Figure 5-4. GRE+IPsec Topology with Redundant Hub Routers The topology of Figure 5-4 also introduces a degree of resiliency to the design that was missing in the single-hub scenario. If Hub-1 experiences a problem, traffic from Spoke-1 can be diverted to Hub-2. If the problematic device liberates itself of whatever issue was preventing it from forwarding traffic and comes back on line, the original path from Spoke-1 to Hub-2 can be restored. Now we have introduced both robustness and complexity to the network. The most common way to fail over between GRE tunnels is to use routing protocols to detect when a tunnel goes down and use an alternative path, if there is one. Because of the way GRE tunnels are implemented in Cisco routers, you must statically configure tunnels to both hubs to do this and then make the backup path have a higher routing cost than the main one. Convergence times will not be subsecond, but the advantages of a backup path are clear. You might wonder whether it is possible to use IKE to manage remote endpoint availability. It is true that if Hub-1 were to fail, the IKE session on Spoke-1 would go down, probably well before the routing protocol between the two devices decides, after timeouts and retransmissions, that the path is unavailable. If the router implementation supports it, this is a viable alternative method to manage tunnel redundancy and failover. Referring back to Figure 5-4, because GRE tunnels never go down, another alternative is to use per-flow load balancing between, for example, Spoke-1 and both hubs. The economics of your network service would determine whether this is cost-effective. If you can use the second tunnel with no additional cost (because it goes over a public network for example), all is well. If it is a managed service with per-tunnel usage pricing, this might not be such a reasonable idea. The routing in the hub site is also that much more involved because the core network must deliver the right packets to the right hub router, so there is less opportunity to aggregate prefixes. However, the difficulty of deploying a hub-and-spoke topology should not be exaggerated. Many WANs use this sort of design perfectly well, and it should not escape your attention that the architecture is identical to a classic Frame Relay VPN, using p2p circuits between sites. The question is whether the hub-and-spoke architecture is the most suitable architecture and whether GRE and IPsec are the most suitable protocols for other connection scenarios. Some of the issues discussed here are linked to the choice of protocols: the extra complexity of using IPsec, the reliance on routing protocols for GRE resiliency, separate interfaces for every tunnel on hub routers, and so on. Using a different protocol might address some of these issues, but it would certainly introduce another set of problems. In all cases, the architecture would remain a hub-and-spoke architecture, which is a good fit in some scenarios and a poor one in others. The next section discusses a multipoint version of the GRE+IPsec solution, which addresses many of the limitations just discussed. Putting It All Together: DMVPNDynamic multipoint VPN (DMVPN) is a solution that combines multipoint GRE (mGRE) and IPsec. Recall from Chapter 4 that mGRE is a p2mp implementation, in which every spoke router has a tunnel interface to reach the hub. The hub has a single interface for all the GRE tunnels. Example 5-2 shows the hub mGRE configuration, which you should compare to the standard configuration of Example 5-1. Example 5-2. mGRE Hub Router Configuration
The first advantage of mGRE is already clear from the example. The hub configuration has become extremely simple, with only a single static tunnel interface to worry about. The second advantage comes from mGRE's capability to dynamically provision tunnels. If two spoke sites need to communicate, the first packet is sent to the hub along with a Next Hop Routing Protocol (NHRP) request for the site's IP address. When the site CPE receives the NHRP reply, it builds a tunnel directly to the destination router. Figure 5-5 shows an mGRE network with two dynamic tunnels between the spoke routers and the permanent GRE tunnels to the hub router. Figure 5-5. mGRE Operation The mGRE solution still uses the same protocol stack as "simple" GREso the data plane does not change. Inter-site tunnels exist now, where there were none before, and you can now use NHRP to manage tunnel setup. If your network requirements do not require strong security protection, you can deploy a DMVPN just using mGRE. Otherwise, the next layer in the DMVPN cake is IPsec. Example 5-3 shows the hub configuration with IPsec enabled. Just as for GRE+IPsec, a single command is all that is required to encrypt all the GRE tunnels that are created from this mGRE interface. Example 5-3. Hub DMVPN Interface Configuration
The "MVPN profile" in the example refers to an IPsec crypto map, which, in this case, has the exact same instructions as the VPN crypto map of Example 5-1. The spoke routers use the same tunnel profile command. Example 5-4 has a typical site router configuration. Example 5-4. Spoke Router DMVPN Configuration
Creating encrypted tunnels dynamically has an interesting implication for the security of this architecture. Obviously, the cryptographic credentials used by hubs and spokes must match. For example, Examples 5-3 and 5-4 must both use the same tunnel key value. However, all the IPsec security associations shown so far require the peer IP address to be configured in a router's crypto map. With DMVPN, it is not possible to know in advance which router will create a tunnel to a particular spoke or hub. The alternative is either to statically list every possible IP address, which is cumbersome, or to allow any IP address to begin an incoming IPsec session. DMVPN uses the second alternative, which removes a layer of protection in that you cannot limit who connects to a router. However, an IPsec session is established only if the peer device has the correct security credentials. Example 5-5 shows the spoke router IPsec configuration. Note the wildcard addressing in the IKE security association. The hub has something similar. Example 5-5. Spoke DMVPN IPsec Configuration
Layer 3 Tunnel SummaryA network built using Layer 3 tunnels to connect IP networks has the same architectural characteristics as a network built using traditional Layer 2 circuits. The IPsec and GRE combination are widely used as a WAN solution. Resiliency and load balancing are possible using a routing protocol control plane. DMVPN is a multipoint variation of standard hub-and-spoke architecture. The biggest advantage of using mGRE is that inter-spoke traffic does not have to go through a hub router. In addition, the configuration files are short and simple, excellent qualities in any router. You might argue that DMVPN slightly lowers the security threshold that one usually gains with IPsec because you must allow any remote router to try to begin a session, but DMVPN supports strong encryption and authenticationeither certificates or shared secrets can be used to authenticate peers. DMVPN has essentially the same resiliency characteristics as standard hub-and-spoke architectures because a predefined hub router must be available for the design to function and because you need to use an additional control plane to manage primary hub selection. |
EAN: 2147483647
Pages: 128
- Chapter VII Objective and Perceived Complexity and Their Impacts on Internet Communication
- Chapter X Converting Browsers to Buyers: Key Considerations in Designing Business-to-Consumer Web Sites
- Chapter XI User Satisfaction with Web Portals: An Empirical Study
- Chapter XII Web Design and E-Commerce
- Chapter XVIII Web Systems Design, Litigation, and Online Consumer Behavior