Zivaro Blog

Thinking Hybrid WAN? Think Cisco iWAN (Part One)

As a network engineer, I am always looking for technologies that allow me to more easily control how traffic flows over a Wide Area Network (WAN). Until recently, many of these technologies had too many tradeoffs: policy-based routing (PBR) risks black holing traffic, native routing protocols are notoriously difficult to manipulate, and Multiprotocol Label Switching […]

As a network engineer, I am always looking for technologies that allow me to more easily control how traffic flows over a Wide Area Network (WAN). Until recently, many of these technologies had too many tradeoffs: policy-based routing (PBR) risks black holing traffic, native routing protocols are notoriously difficult to manipulate, and Multiprotocol Label Switching (MPLS) traffic engineering…well, requires MPLS.

Fortunately, many of the shortcomings of traditional WAN services can be overcome with a Hybrid WAN, which takes advantage of more than one type of connectivity to deliver data to geographically dispersed offices and workers.

While there are several Hybrid WAN services available today, I will focus on Cisco’s Intelligent WAN (iWAN) solution. iWAN allows: “transport independence, secure connectivity and intelligent path control.” While that might sound like something written by the marketing department, in this three-part post I’ll explain why engineers should be excited about this solution.

Let’s start with transport independence. This means that engineers can create a WAN without regard to the underlying service. The transport technology can be MPLS, Metro Ethernet, or Internet – it doesn’t matter as long as it is Internet Protocol (IP).

This is important because it allows engineers to design networks based on the service and bandwidth they choose. They are not required to spend weeks or months working with a service provider to get service, or wait for weeks for a change, or spend months attempting to migrate services. As long as IP connectivity is available, engineers can add or remove services based on their needs – not the service providers.

Within Cisco’s iWAN solution, transport independence is provided by Dynamic Multipoint Virtual Private Network (DMVPN). Because Cisco can explain this much better than me, below is an excerpt from a Cisco DMVPN configuration guide that explains some of the technical details of DMVPN.

The DMVPN feature combines GRE (Generic Routing Encapsulation) tunnels, IPsec encryption, and NHRP (Next Hop Resolution Protocol) routing to provide users an ease of configuration via crypto profiles – which override the requirement for defining static crypto maps – and dynamic discovery of tunnel endpoints. This feature relies on the following two Cisco enhanced standard technologies:

– NHRP – A client and server protocol where the hub is the server and the spokes are the clients. The hub maintains an NHRP database of the public interface addresses of the each spoke. Each spoke registers its real address when it boots and queries the NHRP database for real addresses of the destination spokes to build direct tunnels.

– Multiple GRE (mGRE) Tunnel Interface – Allows a single GRE interface to support multiple IPsec tunnels and simplifies the size and complexity of the configuration.

The topology shown in the diagram below and the corresponding bullets explain how this feature works.

Source: Cisco

– Each spoke has a permanent IPsec tunnel to the hub, not to the other spokes within the network. Each spoke registers as clients of the NHRP server. DMVPN Configuration Guide, Cisco IOS Release 15M&T 5 DMVPN Feature Design of DMVPN

– When a spoke needs to send a packet to a destination (private) subnet on another spoke, it queries the NHRP server for the real (outside) address of the destination (target) spoke.

– After the originating spoke “learns” the peer address of the target spoke, it can initiate a dynamic IPsec tunnel to the target spoke.

– The spoke-to-spoke tunnel is built over the multipoint GRE interface.

– The spoke-to-spoke links are established on demand whenever there is traffic between the spokes. Thereafter, packets can bypass the hub and use the spoke-to-spoke tunnel.

(Source: Cisco)

As you can see, DMVPN allows for easy multihoming of circuits, consistent configuration, and proven IPsec security, regardless of service provider or WAN transport type.

In my next post, I’ll take a closer look at another benefit of Cisco iWAN – secure connectivity.

Michael Edwards is a principal architect in professional services at GTRI.

3900 E Mexico Avenue, Suite 1000,
Denver, CO 80210