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 
advice 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
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!
