Peter J. Welcher is a Cisco Champion, an elite group of technical experts who are passionate about IT and enjoy sharing their knowledge, expertise, and thoughts across the social web and with Cisco. The program has been running for over four years and has earned two industry awards as an industry best practice. Learn more about the program at http://cs.co/ciscochampion.

==========================================

The company I work for, NetCraftsmen, is seeing increasing levels of consulting customer interest in Cisco IWAN. That reflects either tech cool-ness or cost-savings — or both!

In a recent blog, I discussed some considerations for those intrigued by the idea of SD-WAN. For organizations with a Cisco WAN in place already, the risk and cost to try out IWAN may be low. We’ll get to that; first, let’s review what IWAN is, as a refresher for those who are not already familiar with IWAN.

About IWAN

IWAN is Cisco’s SD-WAN offering. It leverages the mature DMVPN technology, plus the rapidly maturing PfRv3 technology, to provide for hybrid WAN (MPLS + internet) or internet-based WAN.

The idea behind IWAN and competing SD-WAN offerings is that in many locations, internet SLA’s have improved vastly, and the internet costs are far lower than MPLS costs. Using application-aware technology such as PfRv3, sensitive traffic can be shifted off poorly behaving internet links. Putting all that together, there might be real cost savings if you use a couple of different ISPs and traffic shifts when one of them is having a bad day. Another alternative is to send most traffic over the internet path, VoIP, and sensitive traffic over MPLS, with failover to the other path if conditions turn bad.

The following diagram shows the basic IWAN setup.

 

The heavy lines indicate DMVPN encrypted tunnels, one for the MPLS side, and another for the internet side. Each provides secure encrypted any-to-any connectivity between the branches and the hub. The PfRv3 shifts traffic between the two paths (up to five paths).

There are other Cisco functions that also fit under the IWAN banner. They include:

• QoS (including DMVPN Per-Tunnel QoS for the hub sites)
• WAAS functions to improve WAN performance
• Application Visibility and Control (AVC), and NBAR2
• Cisco Prime Infrastructure integration/monitoring/reporting

I did say “rapidly maturing” PfRv3. I recently had the chance to put in some extended lab time working with PfRv3, and almost all aspects worked as expected. This is worth noting, since PfR versions 1 and 2 had some rough spots. Since then, Cisco appears to have massively redesigned how PfR (v3) works, put in a lot of smart engineering, and done solid testing. There have also been some simplifications, which helps too. Admittedly, if you want different policies site-by-site, well, I haven’t figured out how to do that with PfRv3. But would you really want to have to manage that complexity?

The QoS is pretty much the same QoS we all have been doing. The CVD configurations align with Tim Szigeti’s/Cisco’s recent CiscoLive presentations at the last couple of U.S. CiscoLives, and the currently recommended approach to WAN QoS.

One reason I’m presenting these items as additional is based on my view of IWAN as layered. One can deploy it incrementally: put routers in the right places (if not already at WAN and internet edge), stand up DMVPN (routing between legacy WAN and DMVPN as needed), add PfRv3 application-awareness, then QoS, then other functions.

I see that as mitigating risk, or as letting sites incrementally deploy additional features based on their comfort level, staff time, etc. With a consultant helping, knowledge transfer might be a related gating factor.

Getting Started with IWAN

As noted in this blog, I discussed some considerations for those considering intrigued by the idea of SD-WAN. There are a couple of items that tilt the playing field in favor of Cisco IWAN for many organizations:

• Low risk to piloting/implementing IWAN by leveraging installed equipment
• Sunk equipment costs (i.e., you already have Cisco MPLS and/or internet routers in place)
• SD-WAN vendors, being startups, don’t seem to currently want to talk to small potential customers

NetCraftsmen’s recent experiences have illustrated the power of these driving factors.

Admittedly, you have to still do some homework regarding suitability of the present routers:

• If you’re planning on doing IWAN, you’ll need at least an ISR G2 for branch role, and an ISR 4K or ASR 1K for central or higher speed locations. The CSRv also supports IWAN, can act as hub Master Controller or branch router (e.g. cloud!).
• You’ll also need the appropriate IOS code. Cisco documented the requirements here.
• Check the model of router in place and its IPsec capacity. IWAN entails running DMVPN, which generally decreases throughput.
  • ISR 4K: See the Miercom report for details.
  • ASR 1K: The Miercom reports are dated. There’s some performance data starting on page 12 of this datasheet.

One place where sunk equipment costs might not come into play is where the customer has connected a MetroEthernet service directly to a firewall or Layer 3 switch. We do generally advise against doing that. Firewalls and switches do not support QoS traffic shaping to the contracted speed. When you’re operating at a speed less than the physical line rate, and if your WAN provider enforces the contracted speed, you’ll be taking random provider-induced packet drops during traffic bursts. That’s not the way to good VoIP/video quality on your MAN/WAN.

Having said that, budgets don’t always extend to buying a router plus a firewall for each site. So some sites may not be ideal candidates for IWAN, due to not having the prerequisite routers in place.

The cost for a couple of routers for a pilot project need not be all that high, however. So non-router WAN/internet-edge may not be a show-stopper. Your implementation plan will need to somehow “slide” the routers into the links (directly or indirectly), but there are several ways to do that — and a matching Cisco “brownfield” guide to help! I’ll admit, I have my own thoughts on the subject, which differ a bit from that document.

Tools

This blog is getting a bit long, so I’ll just mention some of the tools that you might use, especially if you don’t have a CCIE to spare for manual IWAN deployment.

• APIC-EM/IWAN
• Cisco Prime Infrastructure
• Glue Networks IWAN Orchestration
• LiveAction (for managing IWAN functions)

Alternatively, many Cisco Partners should be able to support IWAN by now. NetCraftsmen would be glad to talk to you about that.

My personal inclination for deployment in brownfield is to do it manually, for better control, router by router. Your preferences may vary.

Viptela

We’ll have to see how the Viptela acquisition plays out, and how Cisco positions it. Will it be arms’ length, like Meraki and recent acquisitions, or will the Viptela GUI be adapted to also driver routers? Or some other mix? Time will tell.

One big question I’ll have, once I can see the documentation, is how to insert Viptela in brownfield, since there’s so much of it. And how smoothly that can be done. Right now, manual IWAN deployment (templates, not that bad) gives me the control I want.

Links

When in doubt, check out the Cisco Validated Design (CVD) document. There are two fresh PDFs, as of October 2016:

• CVD: IWAN and WAN Design Summary
• CVD: IWAN Deployment Guide

For more resources, check out the CiscoLive OnDemand library, and search on “IWAN.” Comments are welcome, both in agreement or constructive disagreement about the above. I enjoy hearing from readers and carrying on deeper discussion via comments. Thanks in advance!