This solution consists of four main components and one optional analytics component:
- vManage (management)
- vSmart (controller)
- vEdge (routers)
- vBond (orchestrator)
- vAnalytics (analytics)
vManage is the Network Management System (NMS) to configure and manage the entire SD-WAN solution. We can say it is a dashboard to manage, configure and monitor the network.
We can use a GUI or REST API to access it.
We can create device configurations and network policies using it. vManage also alerts when there are events or outages. It handles centralized management, Rest API, Configuration, Monitoring and management.
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.
vSmart is the control plane of the architecture. vSmart controllers advertise routes, security, and policy information. Cisco SD-WAN uses the proprietary Overlay Management Protocol (OMP) for this. vSmart implements the policies that you configure through vManage. It handles routing information , encryption key propagation, central policy management, service chaining, traffic engineering.
For example, imagine you create a policy through vManage where real-time voice traffic requires a latency of less than 100 ms. In this case, vSmart controller downloads the policy, converts it into a format suitable for the vEdge routers and then implements it on all vEdge routers.
All vEdge routers peer with a vSmart controller, it’s a hub and spoke topology. It’s similar to a BGP route reflector (Because vSmart receives the routes from a site and send to all other sites if we are not having any policy configured for it) or a DMVPN NHRP server. The vSmart controller only lives in the control plane and is never in the data plane.
vEdge is the software or hardware routers at our sites and responsible for the data plane. vEdge routers connect to a vSmart controller through a Datagram Transport Layer Security (DTLS) connection.
If we want to use hardware. Then we have the following options:
- Viptela vEdge: 100, 1000, 2000, or 5000 series routers.
- Cisco ISR and ASR: the IOS XE SD-WAN software image allows you to use Cisco SD-WAN on the ISR 1000, ISR 4000, and ASR 1000 series.
- Cisco ENCS: similar to the ISR series, you can use the IOS XE SD-WAN software images for the ENCS 5000 series platform.
If you want to use software, you have two options for VMs:
- vEdge Cloud
- Cisco Cloud Services Router (CSR)
vBond is the orchestrator. It authenticates vSmart controllers and vEdge routers and coordinates connectivity between them. It tells vEdge routers where and how to connect to vManage and vSmart controllers. vBond requires a public IP address so that all the devices can connect to it. When a vEdge router joins the SD-WAN, the first thing it talks to the vBond orchestrator.
This is the first point of authentication as well as This is the first point to which vEdge interacts. This is also single point in SDWAN where public IP is necessary. When vEdge bootsup, it contacts to vBond using domain name or IP address and DNS. vBond responds to DNS query with vBond pubic IP addresses. vBond validates the serial number of vEdge.
A DTLS (Datagram Transport Layer Security) tunnel creates between vBond and vEdge using RSA & AES-256 encryption. This tunnel will be initiate to the one of IP addresses which shared by vBond. So authentication can be done between vBond and vEdge. Once tunnel is established, both will send the certificates to each other. During the certification validation process, vBond also checks the serial number and chasis number in certificate received from vEdge and matches with the list which is received from vManage. At vEdge end, vEdge checks the organization name in the certificate received from vBond. It should be match with the name configured on vEdge. The organizational name must be identical on all devices that make up the fabric (this name is case-sensitive). Once tunnel established and encryption done, vBond sends the IP address and serial number of vEdge device to vManage and vSmart. It also shares the vManage and vSmart IP address and serial number to vEdge.
This tunnel will be remove after authentication and share the vEdge details with vManage and vSmart.
Now vEdge will initiate new DTLS tunnels with vManage and vSmarts. And will perform the authentication and will exchange the certificates. These all tunnel will be separate for vManage and for each vSmart.
The vManage tunnel is used to push config to our vEdge and also to receive statistics, while our vSmart DTLS tunnels facilitate the propagation of our SD-WAN policies via OMP
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
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.
vAnalytics is an optional analytics service. It gives you visibility of applications and your infrastructure in the entire SD-WAN. You can use it for forecasting, and it gives you recommendations about your traffic and WAN connections. This can be useful to figure out whether you need to upgrade or downgrade certain WAN connections.