Blog

vManage is the network management system (NMS) and thus your window into the system. It is the dashboard that you will interact with daily. If you are familiar with the Meraki dashboard you can very much think of vManage in the same light. It is responsible for collecting network telemetry from our vEdge devices and alerting on events and outages in the SD-WAN environment. It is also the location where you will build your device configurations (Device Templates) and overlay traffic engineering policies.

This is also the programmatic interface into the system supporting REST API.

On-Premise deployments can be hosted on either ESXi or KVM hypervisors, with even the smallest footprint requiring a minimum of 16 vCPUs, 32GB of dedicated RAM and 500GB of storage. Now you can see why the cloud hosted option is so appealing. A single vManage instance can support up to 2,000 devices and can be deployed as part of a cluster containing 6 instances.

vBond is considered the orchestrator of the system and for good reason. Its job is to orchestrate connectivity between all the other components in the system. In other words, it tells our vEdges where and how to connect to our organizations vManage and vSmart controllers, while also advising our vSmart controllers as new vEdges join the SD-WAN fabric. It also serves the role of informing our vEdges if they are behind a NAT device which facilitates IPsec NAT traversal and allows Authentication Header security to be applied to our data plane tunnels (more on that in upcoming posts).

vBond is the first point of contact and thus our first point of authentication for all SD-WAN components as they boot up and join the SD-WAN fabric.

On-Premise deployments can be hosted on either ESXi or KVM hypervisors. The service can also be run as an agent service on one of your vEdge hardware appliances (although this is strongly discouraged). Each vBond requires a dedicated public IP address.

 vSmart as the name implies is the brains of the system. This is the device that constitutes the control plane component of the architecture. vSmart controllers advertise routing, data plane policies and security. They are positioned as hub devices in the control plane topology with all vEdges peering with a vSmart (vEdges never form control plane peering’s between each other). If you are familiar with BGP route reflectors or DMVPN NHRP servers then you can kind of liken vSmarts to them. Although as noted above they never insert themselves into the data plane and advertise a lot more than just standard reachability information.

vEdge is the software or hardware component that sits at your sites. In fact, if you choose a cloud hosted control/management plane deployment this is the only component of the architecture that you will need to deploy. vEdges are responsible for the data plane of the SD-WAN fabric as they bring up IPsec or GRE tunnels between your sites. As mentioned above vEdges form control plane connections with vSmart controllers, and not between each other.

vEdge hardware comes in many form factors. You have the 100, 1000, 2000 and 5000 models. The main difference being greater interface choices, higher supported throughput and data plane tunnels as the model number increases. With the Cisco integration you can now utilize Cisco’s ASR1K, ISR4K and ISR1K router platforms along with the ENCS to perform this SD-WAN role.