Network Field Day 13 was my second encounter with the smart people at VeloCloud. Just as in #NFD9, VeloCloud provided an awesome series of presentations to the #NFD13 delegates. I’ll spare you talk about founders, etc. — you can read VeloCloud’s corporate About page as well as I can.
VeloCloud is one of many SD-WAN vendors. Their presentations have made them stand out, due to the clarity and intelligence of their approach and the features in their product.
Per my notes, VeloCloud claims about 600 customers and commitments for about 50,000 sites, as well as the largest two SD-WAN wins. They have partnered with many service providers (see my pre-NFD13 blogs).
General thoughts
The SD-WAN space has become rather cluttered lately, with all the WAN acceleration and WAN vendors wanting to participate. My take is that SD-WAN startups with a clear vision, those like VeloCloud, are the most likely to produce a robust, comprehensive solution.
One of the key features for SD-WAN products is the ability to automatically detect link problems and selectively re-route application flows over a second path to meet business requirements/SLAs. Determining how well they do so would require some pretty careful testing.
As part of any such product, GUI reporting of app traffic and “weather conditions” (quality of paths) is rather important as well — if you can’t tell what it is doing and why it is doing it, that would be bad.
Disclaimer: Bear in mind that I’ve seen slides and demos. I do not have hands-on time with SD-WAN products. I’ve been looking for someone to produce The Matrix — not the movies, but a SD-WAN product feature comparison table. Better yet, testing results. I’m not holding my breath on either one. With all the vendors, doing so would take a lot of work!
See, however, this fairly recent report by Mike Fratto. His blog ties this back to letting automation do the work for you — which indeed is a key aspect of SD-WAN.
Recommendation: If you’re looking at SD-WAN, talk to vendors, decide what your requirements are and what the key functionality is, pick the top two vendors, and do a detailed POC. Bear in mind that you’re going to have to live with the results for the next N years, and your job may depend on your choice.
I’m planning a future blog with some ideas on things to consider when looking at SD-WAN products, including Cisco IWAN.
And if you produce a version of The Matrix, do send me a copy!
Ways to do SD-WAN
There are (at least) two ways to do SD-WAN. One is to deploy your own. That has the virtue of WAN/ISP independence, but takes some work. The other is to outsource it, and buy a managed SD-WAN solution via your favorite ISP or WAN vendors.
(Hmm, “favorite” might be the wrong word — I have yet to encounter anyone who likes their ISP or WAN vendor. Perhaps “usual suspects”?)
VeloCloud’s presentations emphasized that their solution has the multi-tenant capabilities that a service provider might want, to manage physical or virtual edge devices across multiple customers. Specifically:
- The VeloCloud Orchestration component is a multi-tenant management GUI that configures and deploys SD-WAN and policy, with per-tenant web portals.
- The VeloCloud Gateway is a multi-tenant virtual appliance suitable for use in cloud or colocation. It terminates MPLS and internet-based access.
- VeloCloud Edge is the branch edge CPE or virtual CPE appliance — think site edge device.
As a consequence of the push toward service providers and managed services, VeloCloud is also focused on scaling their product.
Some VeloCloud features of note:
- Virtualized services delivery: services insertion in cloud POP or regional hub
- Real-time analytics
- Forward error correction
- Encrypted tunnels
- Zero-touch deployment, or remote push if you wish
- Standardized IPsec to legacy supported
- VeloCloud sells direct to enterprises or via MSPs
- Optimized cloud access (I’ll likely blog separately about the related design concepts; too much for this blog)
Edge functions
For years, I’ve seen a tension between routers and firewalls for edge functionality. I’ve often wished for a device with the best of both. We now have SD-WAN devices (physical or virtual), which are mostly app-aware routers with encryption and tunnels.
Strictly speaking, they have to run a routing protocol to be a router — some SD-WAN boxes conceivably might be based on something more like OpenFlow/flow-forwarding tables under central control. Another good question to ask your vendor: Is there some distributed routing under the hood, e.g. to fall back on when app or flow-specific controls aren’t working?
SD-WAN devices/virtual appliances are currently not so much firewalls, but there are ways to get firewall and other security functions into the mix.
Specifically, service chaining or insertion fits well with service providers wanting to deliver Network Function Virtualization (NFV). Both VeloCloud and Viptela (the other SD-WAN vendor at #NFD13) partner with virtualized firewall and anti-malware vendors, and support service chaining.
If you are decentralizing your company’s internet access, you likely don’t want to have to deploy and manage firewalls plus SD-WAN devices at sites. You might use SD-WAN with localized (distributed) internet access, but then you have distributed firewall and anti-malware devices to contend with, or services like Zscaler to use. These may impose latency and management overhead, in part through sheer numbers.
Instead, your SD-WAN box might do NFV, running a virtual partner appliance like virtual Palo Alto in the physical SD-WAN appliance or as a co-hosted VM. Integrated management might be something to look for if that approach appeals to you. This is not a novel concept: Cisco is doing similarly with NFV: You can buy a router with virtual firewall (etc.), or if you prefer, a device with virtual router and virtual firewall, etc.
Another SD-WAN alternative, especially with a managed offering, is where your traffic is back-hauled to a regional POP (yours or the provider’s) and runs through firewalls and anti-malware there. That has the advantage of fewer physical or virtual appliances to license and manage. It provides expedited internet access along with regionalized low-latency WAN.
One other possible wish-list item is direct decentralized internet access to trusted SaaS services, while centrally forwarding other internet traffic to the corporate or MSP “web-washer.” With CDNs as part of the mix, you can’t just use IP addresses to identify SaaS servers; that would be an ongoing IP ACL maintenance headache. Cisco is pushing the idea of DNS interception, dynamically creating firewall/router rules to allow traffic to/from the IP address that the SaaS resolves to. That basically amounts to dynamic DNS name-based ACLs.
If you like that idea, it’s something to add to your “desired features” SD-WAN shopping list.
Use cases
Where do I see SD-WAN fitting? In general, it offers the potential opportunity to lighten the workload and tech skills required to operate a WAN.
Where is that most useful? Here’s what I’ve come up with:
- Large WAN networks (e.g. hotel chains, retailers) looking to outsource/offload WAN support costs.
- Construction, engineering, home building, and other firms that need quick site trailer or field presence — getting one or two internet connections is simpler, cheaper, and faster than getting WAN connection. SD-WAN boxes likely support zero-touch deployment, but then again Cisco routers do as well (whether people use it is another topic entirely).
- Small to medium businesses that don’t have a CCNP or CCIE on staff and don’t want to deal with routing — especially where high availability is a consideration.
- Price-sensitive organizations, where MPLS bandwidth is too pricey, and perhaps less-costly Metro Ethernet not available at some/many locations.
- Larger organizations who think their staff’s time can be better spent solving other problems.
Considerations
Cisco routers are complex, but are like a super-Swiss Army knife (i.e. if you realize you need to layer on another function/feature, it’s there).
SD-WAN devices or virtual appliances and GUI are a canned solution. They do a focused set of things well. That’s good because you don’t have to learn to program, support automation scripts, or even know as much. That’s bad if the product doesn’t do what you need or provide the flexibility you need. That’s also what SDN requires: cookie-cutter networking, resisting customized tweaking of sites.
Operational ease of use is a factor to consider. One of the NFD13 folks mentioned an issue with the Aryaka SD-WAN solution: All the devices must be upgraded at the same time, in one big outage. Big ouch! Add that to your feature/POC checklist.
Describe competing products, pros/cons
There are now many firms that want to play in the SD-WAN space, including link-bonding firms and WAN acceleration firms.
SD-WAN requires a far bigger programming code base, and perhaps higher-level skills. Concerning SD-WAN, if you think “routing + DMVPN + app awareness + GUI” (did I just say “IWAN”?), that’s a lot of code! Startups with experience may have a lot of code to build but also may know how to do it right from scratch. Bolt-on additions to existing products — well, maybe that helps, maybe not.
Speaking of Cisco, there’s of course IWAN. Cisco IWAN is a competing SD-WAN product, combining DMVPN, routing, PfRv3, application awareness, and network management products into a solution. CLI or APIC-EM to configure it and monitor it. I’ve been doing PfRv3 lately — some learning curve, not a lot of CLI to make it work. I’ve been less focused on the GUI/management side of IWAN.
On another front, I hear that Cisco Meraki is now adding SD-WAN functionality to its firewalls.
If it matters to you, SD-WAN solutions are likely more tightly integrated than that: The startups live or die based on the ease of use of their product. They’re all in on ease of use and their GUI. Having no CLI might be a positive factor.
Which is better? Consultant’s answer #1: “It depends.”
Links and other blogs
If you want to learn more or see the demos (NFD is big on demos), be sure to check out the streaming videos.
- The NFD13 VeloCloud Deep Dive session went into some of the VeloCloud features and ways of doing things that might be of interest to Service Providers/Managed SPs. As a case study, Earthlink talked briefly about how they leverage VeloCloud and the API to provide SD-WAN services.
Links:
- #NFD13 streaming videos of VeloCloud presentations and related blogs
- Some of my prior words on SD-WAN (from #NFD9)
- NetCraftsmen’s Terry Slattery on SD-WAN
- Terry, again
Other links of interest:
- VeloCloud SD-WAN Enables Managed Hybrid WAN with MPLS for Service Providers
- A Mock RFI for SD-WAN
- Software-Defined WAN for Dummies — a good read!
Blogs by other #NFD13 delegates:
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!
