Building A WAN Using Cisco DMVPN

WANs have been around for a long time. The first networks were built for local needs but once they became popular, there was a need to be able to connect offices to each other. Frame Relay was one popular technology for building WANs and connecting offices. Frame Relay, a non-broadcast multiple access (NBMA) technology, was normally used to build a hub-and-spoke network. In hub-and-spoke networks, traffic is passed from spokes to the hub and then to other spokes.

Today, many organizations are turning to the Internet for their WAN needs. Why? There’s potentially a lot of money to save by buying Internet circuits as opposed to other technologies such as Multiprotocol Label Switching (MPLS). For large organizations with many WAN circuits, savings can be in the millions range.

Dynamic Multipoint VPN (DMVPN) is a Cisco technology that's very popular for building VPNs over the Internet. This is a design blog so we won’t dive into the technical details, but here’s a brief overview of how the technology works and available designs.

DMVPN is a multipoint GRE (mGRE), which means that it builds tunnels to transport the data over them. A tunnel is built from the spoke to the hub and this tunnel is always active. Tunnels may also be built from a spoke to another spoke, depending on which phase of DMVPN that's deployed.

Figure 1:

The hub must have a known (static) IP while the spokes may use dynamic addressing. Next Hop Routing Protocol (NHRP) is used to map between the tunnel address and the real address. To secure the traffic passed over the Internet, IPSEC is used to encrypt the packets.

DMVPN can be deployed in phase 1, phase 2 or phase 3. Phase 1 is hub and spoke only, no spoke-to-spoke tunnels. Phase 2 supports spoke to spoke, but requires a certain routing design. Phase 3 is the latest and most flexible design while supporting both hub to spoke and spoke-to-spoke tunnels.

So what should be considered in a DMVPN design? Should the design support hub to spoke only or also spoke to spoke? In some networks, it may be necessary to send all traffic to the central site, possibly  due to policy requirements stating that traffic must pass through a firewall. This will require more bandwidth at the hub site and a high-end router.

Redundancy requirements also should be considered. Redundancy can be added at the hub level by having two hubs. Redundancy also can be provided by using two ISPs, a so called dual-cloud topology. There’s also the possibility of adding redundancy at the spoke by using multiple spoke routers.

Figure 2:

These designs provide different levels of redundancy and require different routing designs with regards to how to select which path should be active or if they both should be. In dual cloud designs, spoke-to-spoke tunnels between clouds can’t be setup, which is one factor to consider when going single or dual cloud.

DMVPN most often uses Internet as a transport and it may be very compelling to move your organization’s WAN to the Internet. Before turning to the Internet as a WAN, consider these factors:

When transporting packets over the Internet, there are no guarantees. Since packets will traverse multiple ISPs, there’s no way of guaranteeing parameters such as RTT, jitter and QoS markings. This may or may not matter to you, depending on what applications are in use. It’s still possible to use QoS for shaping and prioritizing traffic on your routers but any markings will not be honoured by the ISPs forwarding your traffic.

In my next blog, I’ll look at design considerations at the hub and spokes and the scaling factors of DMVPN.