vBond in Cisco Viptela SDWAN

vBond Orchestrator (or a better word "facilitator") ensures SD-WAN fabric on-boarding. It holds the information needed to authenticate vEdges that wish to join the fabric and also a list of vSmart Controllers and vManage to pass along to the vEdges (routers). Before any on-boarding, cross-authentication process takes place. All elements of the SD-WAN fabric authenticate each other using a white-list model utilizing certificates. vSmart and vManage authenticate and be authenticated by vBond as well.

Fig 1.1- Cisco Viptela SDWAN

For the vBond to authenticate any vEdge, a few things must exist:

1.      vManage must have an entry for each switch along with its serial number (or token if cloud vEdge) ad it must not be in the state of invalid.

2.      vManage must have an Organization name defined which matches with vBond and vEdge routers certificate or it must be able to handle CSR/certificate install during the on-boarding if vEdges have only default root certificate installed (common in 0 touch provisioning).

3.      vBond must have a list of switches from the vManage and a valid certificate by a trusted CA. With enterprise CA, you can't do ZTP (zero touch provisioning) as all vEdges must have the enterprise trusted root certificate installed.

4.      vBond must have a reachable public IP address or 1:1 NAT and there must be a DNS entry for each vBond address. If not using zero-touch provisioning (ZTP), the vEdges devices must have a minimal configuration added which includes the system-IP, the DNS name of the vBond and the DNS server which can resolve the name, and the organization name.

This list from vManage is used by vBond to check all the vEdges and it is this list which contains vSmart and vManage as well.

Process of validation/authentication between vBond to vSmart

vSmart validates:

1.      Root certificate (checks that it trusts the root certificate)

2.      Certificate serial number

3.      Organization name compared to local certificate OU

4.      White-list from vManage

vSmart validates:

1.      Root certificate (checks that it trusts the root certificate)

2.      Organization name compared to local certificate OU

Process of validation/authentication between vBond to vManage

vSmart validates:

1.      Check root certificate

2.      Organization name that it matches with local certificate OU

3.      White-list from vManage

vManage validates:

1.      Checks root certificate

2.      Organization name that it matches with local certificate OU

Process of validation/authentication between vBond and vEdge

vBond validates:

1.      Root certificate

2.      White-list from vManage

3.      Organization name

vEdge validates:

1.      Root certificate

2.      Organization name

After successful authentication, vEdge drops the DTLS connection to vBond while vManage and vSmart keeps the tunnel established to provide updates.

vBond also informs vEdge router of its Public IP address to inform it's behind a NAT. If there's no interface configured with that Public IP address, the router would know it's behind a NAT. This will be vital for data plane connectivity with IPSec later on as NAT-T will be needed. After this, vBond passes along the information of the router (including Public IP, if assigned) to vManage and vSmart as heads up. vManage and vSmart would still authenticate the router but this information is sent as an FYI to facilitate the process.

At this point, ether vManage is configured with automatic certificate enrollment or vEdge is pre-installed with root certificate, vManage will on-board the router into the fabric establishing the DTLS tunnel for the purpose of management, IP Sec tunnel establishment and policy/template application. Once marked valid, the router will establish IP Sec tunnel as policy dictates for traffic forwarding and sending/receiving OMP routes.

Cloud vEdge On-boarding: Virtually Simple

In case of virtual vEdge, there's a slight difference in the process:

1.      vManage creates a one-time-password to authenticate the router (during the cloud device instantiation) and it serves the same function as serial/chassis ID.

2.      Once authenticated, vBond also uses the same OTP as part of authentication.

3.      After the cloud vEdge is on-boarded, this OTP will no longer be used.

WAN Edge Routers

From Control plane perspective, TLOC (Transport Locator) performs similar function as BGP next hop addresses for the purpose of routing. From the data plane perspective, and based on the topology policy applied, TLOCs can be thought of as tunnel/fabric endpoints.

1.       WAN Edge routers are on-boarded onto the fabric.

2.       vSmart shares the topology and control plane policies with the WAN Edge router while vManage shares any local policies.