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:
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):
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.
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 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.
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:
Other things to consider:
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!
Pay Attention to Throughput / Oversubscription
Configuring Greetings Administrator Without New Routing Rules