Considering SD-WAN? How to Make the Best Decision for your Organization

Peter Welcher
Architect, Operations Technical Advisor

You did read my prior two blog posts on VeloCloud and Viptela, right? And my older blog posts from #NFD9?

After #NFD13 and writing those two blogs, I’ve been pondering some questions regarding SD-WAN, trying to put myself in the place of you, the reader. I’ve also been considering this because I’ve recently had the opportunity to provide some Networking Field Dayadvice to consulting customers on the topic.

The key questions I ask myself:

  • If I were a potential SD-WAN customer, what should I be thinking about?
  • There are many vendors; how can I possibly decide which to try?

Rather than providing you with a decision tree flow chart or canned answer, I’d like to be a bit more flexible by discussing things someone considering SD-WAN should think about.

First, there are a couple of up-front questions to consider (and they’re not just because I work for a Cisco Gold partner):

  • Does your organization have a heavy investment in Cisco equipment, particularly WAN routers, and skills?
  • Do you have a current Cisco VPN that works OK? Are you or your organization risk-averse?
  • Do you need simplicity, or do you favor in-house control?

The Case for Cisco IWAN

If you have Cisco WAN routers, then you can probably try IWAN for relatively low cost.

Granted, if you’re not already doing DMVPN, you do need to consider ASR 1K or ISR 4K capacity as part of that. DMVPN and other features can impact max throughput — there are Miercom reports with performance data for the ISR 4K routers, and for ASR 1K routers.

If you already have Cisco Prime Infrastructure (“PI”) with suitable licensing, you can also try out the GUI side of things (or, if you insist, pilot some SDN). If you want to (or can) treat things as (mostly) greenfield, you can go for APIC-EM/IWAN, or push IWAN configs from PI. Glue Networks and LiveAction also have IWAN capabilities. Both are on the Cisco GPL. You can likely get a Cisco VAR to demo LiveAction, APIC-EM/IWAN, or PI config of IWAN for you via Cisco dCloud.

At this point, I should probably note, I’ve done my share of wrestling with IOS and VPN bugs. Recently, I’ve been having adventures with FVRF and crypto maps — works fine and as expected in VIRL, but not on a real 899 router with slightly older code. In general, the early days of DMVPN were not always fun.

Having said that, the code has been rather stable for me lately. Similarly for PfRv3 — some learning curve, the documentation has some gaps (like what a transit site is really for — see the docwiki). And figuring out the key show commands helps. I don’t consider matching on apps to be mature yet, based on my VIRL experiments — but that might be old-ish code too.

Yes, both the PfRv3 big picture and the key show commands/troubleshooting are possible future blog fodder.

I have ended up thinking the CLI for DMVPN and PfRv3 is rather low-risk for those with Cisco WAN/internet routers already. Ditto the routing. So use a GUI if you want, or use the CLI.

Caveats I see with IWAN: It’s architectural, as in you have several moving parts to integrate if you want GUI management info about status, apps, and paths. More if you insist on using the WAAS functions. That makes it more complex than SD-WAN might be for smaller shops, say those with only 1-3 admins. The recent blog on Cisco’s Identity Crisis is interesting in this regard.

As I’ve noted elsewhere, part of the SD-WAN value proposition is all-in-one packaging, with success riding on ease of use, GUI, stability.

There is another important consideration: Do you leverage your WAN edge routers for more than just WAN/site-site connectivity? Remote access for staff, voice gateway/CUBE, NAT, decentralized internet access? This isn’t necessarily a show-stopper, but you do need to be aware of what you need to somehow support an SD-WAN solution. Venture capital folks like their startups to stay tightly focused, so SD-WAN won’t provide the wide variety of features a Cisco router does.

The Case for SD-WAN

If you’re not heavily invested in routers, or router EOL (End of Life) is approaching and you’re not doing much with your routers other than routing and perhaps QoS, then SD-WAN might be of considerable interest. (It might anyway, but would entail more effort and some risk compared to leveraging your Cisco installed base.)

Comparing costs might be one useful thing to factor into your decision-making. If the SD-WAN vendor charges by throughput, that might not be totally predictable as bandwidth growth occurs. On the other hand, that also might require you to upsize your router.

We have some data indicating that SD-WAN vendors seem to not be very interested in small customers — as in they don’t always return phone calls. That makes sense: expend limited sales capability on potential big sales; smaller customers obtain SD-WAN services from a service provider.

You might also think about physical ports. Are all your WAN handoffs Ethernet-based, or do you still have some TDM/DS-3 or other legacy hand-offs? You’ll have to bear types of WAN media supported in mind when looking at SD-WAN vendors.

Are you in retail, hospitality, services, or another industry with many sites?

  • SD-WAN might buy you simplicity of operation, since lower skills are required
  • ZTP plug-and-play at remote site might work for you — decide if that’s simpler/more workable than Cisco ZTP (Yes, Cisco does that)

SD-WAN potentially requires less in the way of networking skills to stand up and get working, and may be faster and easier to deploy with less skilled staff. That might be particularly important at large scale. As far as troubleshooting, someone at HQ may still better be able to notice and work issues with the SD-WAN provider or vendor.

What Next?

So you’ve made up your mind to do either IWAN or SD-WAN, or to do a bake-off. What’s next?

The next thing to consider is how to pilot it and, after that, how to migrate to it. As noted above, with Cisco routers, that’s likely incremental. You do need ASR or ISR 4K routers running the right code for the PfRv3 hub site. That’s doable. So the rest of this blog will focus more on SD-WAN.

Some (most?) SD-WAN vendors allow you to insert their appliance or virtual appliance behind your WAN router, and do SD-WAN as an overlay.

Asking the vendors how they’d do that is a good thing to include in your “shopping list.” If they do work as an overlay, do they do static or BGP routing or what so you can eventually remove your WAN or Internet router? Or do they require a direct connection to your WAN or Internet link?

That indirectly brings up the whole decentralized internet topic (which is too big to go into here, but may be a topic for another blog or two): Colo/Cloud-centric WAN designs vs. corporate datacenter-centric WAN, and security for decentralized or regionalized internet access.

Some other SD-WAN thoughts:

  • If not heavily invested in Cisco or EOL is approaching: Bear in mind that there are replacement costs for hardware or for deploying SD-WAN virtual appliances. Don’t assume SD-WAN will or will not be much cheaper.
  • Migration may entail running in parallel or even inserting SD-WAN appliances in the data path. The latter could mean disruptions while you’re learning the GUI, etc. It’s never going to be a total no-brainer. Or running with two links during the pilot/learning period.
  • IWAN can be done as a sequence: DMVPN, layer on PfRv3, add other features and management. Except APIC-EM/IWAN or PI may assume greenfield, which still could require a migration.
  • CapEx/OpEx: YMMV, so I have no comment.
  • Testing should include observing the quality of app detection, reporting, and simplicity of operation.

Other things to consider:

  • The costs (present and future) and limitations.
  • What is the performance range of the appliance? You don’t want to be doing forklift upgrades every couple of years, as some WAN accelerator appliances have required.
  • Interoperability with IPsec and existing devices, e.g. office/datacenter router-based with many sites SD-WAN.
  • Link types supported.
  • Quirks of SD-WAN vendor, e.g. Aryaka reportedly requires all devs on same code version (which makes for painful upgrades).
  • Ability to not only provide WAN but decentralized or regionalized internet access.
  • Cloud optimization (and how they do that).
  • Enabling changes to design model (regionalized internet access for faster SaaS access for geographically distributed sites, etc.).
  • Cisco: Security and edge functions built in, versus SD-WAN NFV for e.g. virtualized Palo Alto in the SD-WAN box, or a physical firewall at a regional colo or cloud site.
  • Some SD-WAN vendors seem to be more about unified edge boxes with link/path failover than application quality.
  • Vendor-specific features, e.g. VeloCloud has FEC, dual streams with re-assembly, etc.
  • SD-WAN vendor/code maturity.
  • SD-WAN vendor longevity (betting on startups); options if the vendor goes out of business.
  • Growing SD-WAN integrated support for NFV, partnering with FW, IPS, etc., security vendors.
  • Consulting/services support, vendor support quality.

Thanks to Russ White and John Cavanaugh for some discussions around these topics. What you see above including errors, omissions, etc. is all on me, not them!


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!

Disclosure Statement
Cisco Certified 20 Years

Leave a Reply


Nick Kelly

Cybersecurity Engineer, Cisco

Nick has over 20 years of experience in Security Operations and Security Sales. He is an avid student of cybersecurity and regularly engages with the Infosec community at events like BSides, RVASec, Derbycon and more. The son of an FBI forensics director, Nick holds a B.S. in Criminal Justice and is one of Cisco’s Fire Jumper Elite members. When he’s not working, he writes cyberpunk and punches aliens on his Playstation.


Virgilio “BONG” dela Cruz Jr.

CCDP, CCNA V, CCNP, Cisco IPS Express Security for AM/EE
Field Solutions Architect, Tech Data

Virgilio “Bong” has sixteen years of professional experience in IT industry from academe, technical and customer support, pre-sales, post sales, project management, training and enablement. He has worked in Cisco Technical Assistance Center (TAC) as a member of the WAN and LAN Switching team. Bong now works for Tech Data as the Field Solutions Architect with a focus on Cisco Security and holds a few Cisco certifications including Fire Jumper Elite.


John Cavanaugh

CCIE #1066, CCDE #20070002, CCAr
Chief Technology Officer, Practice Lead Security Services, NetCraftsmen

John is our CTO and the practice lead for a talented team of consultants focused on designing and delivering scalable and secure infrastructure solutions to customers across multiple industry verticals and technologies. Previously he has held several positions including Executive Director/Chief Architect for Global Network Services at JPMorgan Chase. In that capacity, he led a team managing network architecture and services.  Prior to his role at JPMorgan Chase, John was a Distinguished Engineer at Cisco working across a number of verticals including Higher Education, Finance, Retail, Government, and Health Care.

He is an expert in working with groups to identify business needs, and align technology strategies to enable business strategies, building in agility and scalability to allow for future changes. John is experienced in the architecture and design of highly available, secure, network infrastructure and data centers, and has worked on projects worldwide. He has worked in both the business and regulatory environments for the design and deployment of complex IT infrastructures.