This post is a part of my NSX SD-WAN by VeloCloud series to dive deeper into the acquisition of VeloCloud by VMware, late last year. I’ve had the privilege to play around with the virtual appliance for a couple of months with a physical appliance on the way. Expect more details in this series. 🙂
The upcoming chapters are building up the components that are in the VeloCloud portfolio and the components that you need to know.
An Edge Appliance is a physical or virtual appliance which is in the data path of your network traffic. It typically runs as the last hop before traffic goes out to the internet or internal connections (i.e. MPLS). In smaller branches, it can even function as the default router for the hosts in the network.
These Edges are provisioned and configured from the Orchestrator (more on that later) and you don’t have to do a lot of configuration to set one up when it comes out of the box. Usually, it is pre-provisioned based on serial number and all you need to do is plug in the power, then connect to a default wireless network it creates (or plug in a direct cable) and browse to the appliance to activate it. When an Edge is pre-provisioned, there is an option to send an email explaining the procedure to someone. That email has a direct link to the activation page on the appliance.
An Edge has the networking functionalities you would expect from an edge router. Internal interfaces that can act as your local switch, VLANs, OSPF & BGP for dynamic routing, firewall, IPsec VPN, VRRP, etc. But also non-standard functionalities like service-chaining and clustering so you can create a high available gateway.
SD-WAN features are by nature placed in software, the physical appliance is usually just there because you need to plug your internet connection or MPLS connection into an actual physical box. This means the virtual appliance has the same features as the physical appliance (except acting as a Wireless Access-Point, of course 😉).
Most of the time, you’d want a physical appliance – because, well, cables. You get a physical connection from your ISP, which needs to plug in somewhere.
Here’s an example of how they look:
Front of an Edge
Back of an Edge
I think one of the main reasons VMware acquired VeloCloud is the Dynamic Multi Path Optimisation protocol. DMPO is a link monitoring protocol that goes further than most. Usually, a link monitor only looks at the state of the connection (up, down, packet loss, CRC errors, etc) and maybe the first hop. DMPO looks at the entire path between edges and main internet connections, monitoring for packet loss, jitter and latency. It can use a multitude of connections by doing per-packet load balancing and selects the best connection for the type of packet it’s currently processing (i.e. voice, transactional data). If a link fails, DMPO will reroute the traffic in a way that your end users don’t even notice it. Connections like SSH sessions will reset, but things like voice and web will continue as if nothing happened.
There are some controls, like you can pin specific traffic to a certain connection and use another connection as a back-up (so you can steer MPLS traffic always over MPLS and fall back to a VPN if the MPLS goes down, for example). If you have the right license and DMPO is enabled, it’s by default pure magic.
These are really interesting. The Cloud Gateways are appliances that are delivered as a service and maintained by the VeloCloud team. These gateways are placed in data centers around the world, close to the cloud providers of the world (Office365, AWS, SalesForce and many more). They make sure you connect via the best possible route to a cloud provider and optimize traffic.
Note: these are different from the appliances you can install into an AWS VPC or Azure Resource Group and act as a ‘cloud’ edge appliance. Those are plain edge appliances, only hosted in your cloud.
You can also employ the cloud gateways to serve as a VPN hub in a Branch to Branch VPN configuration. The best thing about the cloud gateways is the simplicity. You need the proper license and tick one checkbox in your configuration and that’s it!
All the SD-WAN configuration is done via the Orchestrator. Typically this is a Software-as-a-Service solution, but there are possibilities to run the Orchestrator on-premises. You’d want to have it hosted by VMware though, as that means you don’t have to maintain that part of your SDWAN stack.
It is essentially the management plane of the SD-WAN network. Configuration, monitoring & troubleshooting is done here. I’ll go into the configuration objects in a later post, but it is dead simple.
Now that the stage has been set, expect more deep dives to come!