SD-WAN – VMware SD-WAN by VeloCloud – Part 1

I’ve been using VMware NSX SD-WAN by VeloCloud (and that mouthful for the remainder of the post will be referred to as VeloCloud), for the last 4 months. I thought it would be useful to provide an unbiased technical evaluation of the product with a lot of network architects and engineers beginning to dip their toe into the SD-WAN market either this year or next hardware refresh.

I’ve covered why SD-WAN in another blog but in short the key driver for SD-WAN is Cloud service adoption. The shift of traffic patterns from on-premise data centres to the Internet (SaaS/PaaS/IaaS) and SD-WAN’s ability to provide simple deployment, VPN and secure local Internet breakout either by itself, Virtual Network Function (such as a Palo Alto) or service chaining to a cloud security service such as Zscaler.

Product Features

VeloCloud stood out to me when compared to rivals for a few reasons. I’ve covered SD-WAN product selection in another blog so these are the features having now productionised an SD-WAN environment that I think VeloCloud excels at.

Deployment – Once you have designed and piloted your SD-WAN environment deploying branch VCEs is simple. It takes the stress out of a site migration for an engineer and time to deliver is much quicker. In one instance I arrived at small branch site, migrated, tested and left in less an hour. This isn’t always the case as with larger or more complex branch sites requiring more testing but the VeloCloud deployment was never the issue and in most cases I could deploy the VCE in parallel of the existing WAN so that the downtime was minimal when cutting across.

QoE (Quality of Experience) – If you intend to use multiple WAN links for all or some of your branch sites, the QoE monitoring and VeloCloud’s Dynamic MultiPath Optimization (DMPO) protocol is seriously impressive. DMPO enables per packet steering across the best WAN link and QoE reports on why it moved the traffic whether it detected packet loss, increased latency or jitter. It also has the ability to buffer, duplicate packets or perform error correction on the fly. Sounds good right? I’m currently running Voice over IP over the Internet, granted my bandwidth and latency are good but this is typically a reason why enterprises are looking to deploy SD-WAN in hybrid mode (Internet and MPLS), my experience so far is that even with contention on the WAN links there has yet to be any call degradation.

QoS (Quality of Service) – Referred to as the business policy, this has application recognition and the ability for an administrator to move applications to different queues to fit the customer’s traffic pattern. VeloCloud kindly provide a starter policy which to be fair doesn’t need that much altering to get you started. The VOIP traffic as mentioned above is categorized as Real Time Protocol and put in the realtime queue which gives it outbound and inbound priority over other traffic, so even if you only have a single WAN link the VCE will still perform error correction. buffering, duplication and QoS.

Monitoring – Having used CA Spectrum and SolarWinds for years network engineers are used to fairly basic monitoring systems. The VeloCloud monitoring is mind blowing. You get all your typical statistics on bandwidth, latency, jitter etc however you also get appflow data to see what applications are being used and how much bandwidth they are using so you can see how much bandwidth a SQL query takes up one hour to the extent that you can see how much bandwidth Windows Updates have used over a year. That’s right almost instantly you can go back up to a year to that level of granularity. And then you can do something about it, for example I could see Windows updates continually using a significant amount of Internet bandwidth so instead of letting it impact users I created a business policy rule for Windows updates and put it in the low priority queue, I did this at the profile level which meant once I finished, the rule got pushed out by the Orchestrator to all branch VCEs. This visibility into the WAN and simplicity to implement application layer QoS is awesome and will benefit many enterprises.

Product Integration

VeloCloud was bought by VMware just over a year ago. In terms of product integration, there doesn’t seem to have been many announcements. I Instantly think of Viptela’s integration with Cisco and how it is already available as a container on the Cisco ISR router. But is this like-for-like? Yes and no, VMware doesn’t do routers so that was never going to be their market, so I can only surmise that VeloCloud will integrate with their existing NSX portfolio to improve their workload management capabilities between on-premise, private and public cloud providers.

While VeloCloud’s integration into VMware appears a bit slow, its integration with Microsoft and their Azure Virtual WAN has been quick. Azure Virtual WAN offers an alternative to spinning up a VeloCloud Edge virtual appliance in Azure which if you are already using Virtual WAN or a have a mixed bag of WAN solutions maybe worth investigating. Myself, I prefer a full stack, having VeloCloud throughput provides end-to-end QoS (within the VPN) using the Business Policy and excellent traffic visibility in a single dashboard. However if you have many Azure locations or subscriptions this might not be cost effective in which case Azure Virtual WAN should be strongly considered.

If I had to ask for an integration feature I would like the ability to use an external Identity Provider (IdP) such as Azure AD or Okta to control management access to the VeloCloud Orchestrator, leveraging an existing identity source and conditional based access policies.

Product Development

VeloCloud is still a developing product, like all SD-WAN products out there. I am currently using the latest version as it allows me to have direct IPsec tunnels from a branch site VeloCloud Edge (VCE) to a Cloud Security Service (Zscaler). Before this release the tunnel to Zscaler was from the cloud hosted VeloCloud Gateways (VCG). The idea of a single, resilient egress point from your VPN overlay to your cloud security service seems like a good design however, remember that IPsec tunnels to Zscaler are limited to 200Mbps so depending on the size of your organisation this may not be suitable. To be fair this isn’t a VeloCloud issue but it is something to be mindful of if you are integrating with a Cloud Security Service. Direct Tunnels from a VCE to Zscaler allow me to pick and choose which sites should use Zscaler and whether it should be used as the default route (using the Zscaler Cloud Firewall) or just for web traffic. The profile functionality of VeloCloud is very good for this and enables you to configure at scale.

One area that still needs improvement is the tunnel failover, which is planned to use IP SLA soon (IP SLA is used if using the Cloud Gateway method today).

Having used earlier versions of the code it does seem to have stabilized which is good with more emphasis on stability as opposed to rushing new features into a release, which shows a maturing product. Getting hold of release notes however was not easy, it would be good if these were made available publicly or in the VeloCloud Orchestrator.

Product Documentation

When down selecting VeloCloud it was very difficult to find any technical documentation, just the sales and solution briefs on the website which made it hard to compare the product to its rivals; although Cisco made a good mess of their website with a mix of I-WAN and Viptela (now resolved). The technical documentation is located in the VeloCloud Orchestrator which is great once you have access but trying to ascertain whether the product met a customer’s technical requirements prior to an evaluation was a bit painful and may put off some potential customers if they can’t find the information.

Now the help documentation is a mixed bag. I hold the Zscaler help documentation to be one of the better public help document repositories as it is easy to navigate and the instructions, whether is be design, implement or troubleshoot are clear and inline with the current version at that time. The VeloCloud technical documentation needs some work.

Product Support

VeloCloud Support are very responsive and the engineers I have dealt with so far are very knowledgable about the product. In some scenarios I wish I was able to SSH into the VCEs like the support engineers do to troubleshoot but then I remember this isn’t a Cisco router, its a cloud managed service. It would be good to have a cloud health status page and I believe that service providers have this kind of visibility but for enterprise customers it would be good to know if there are live issues with the underlying cloud service.

Summary

The above is my opinion based on my experience of the VeloCloud ecosystem. I look forward to see how it evolves and i’m sure my minor gripes will be resolved at some point. If you would like to discuss SD-WAN or VeloCloud please reach out to me.

Alex