In this lesson, we are going to go through the different WAN edge onboarding options that Cisco SD-WAN provides.
vEdge devices could be physical appliances or virtual instances. Both types can be onboarded using an automated deployment process, such as Zero Touch Provisioning (ZTP) for Viptela devices and Cisco Plug-and-Play for IOS XE devices. However, there are two available options in case that automated deployment is not possible - manual deployment using the CLI or bootstrap configuration that can be loaded via USB stick.
It is important to make sure that the following statements are true before a WAN edge device can be onboarded:
- All Cisco SD-WAN Controllers (vManage, vBond, and vSmart) should be deployed and operational with valid certificates installed.
- The Edge device should have IP reachability to all controllers.
Automated Deployments
The automated WAN edge deployment is the recommended method for adding new nodes to the Cisco SD-WAN fabric. It is enabled by default on all vEdge devices and provides a true zero-touch experience. In essence, this automated onboarding just discovers the vBond IP address dynamically using one of the following processes:
- On all Cisco IOS-XE devices, the process is called Cisco Plug-and-Play (PnP). It basically resolves the hostname devicehelper.cisco.com and asks what is the vBond IP for my organization-name.
- On all Viptela vEdge appliances, the process is called Zero-Touch provisioning (ZTP). It resolves the hostname vtp.viptela.com and gets the vBond IP for the given organization-name.
A high-level overview of the steps involved during the Zero-touch Provisioning (ZTP) / Cisco Plug-and-Play (PnP) deployment process is listed below:
- The WAN edge device is powered up.
- The vEdge attempts to assign an IP address to its transport interface in VPN0. If it receives IP settings (address/mask/gateway/DNS) via DHCP or Auto-IP, it continues to step 2, otherwise, the automatic deployment does not continue
- The router tries to resolve the URL ztp.viptela.com (for Viptela vEdge devices) or devicehelper.cisco.com ( for Cisco IOS-XE device).
- The device contacts the PnP/ZTP server. The server verifies the vEdge router and sends back the IP address of the respective vBond Orchestrator for this Organization-name.
- The vEdge establishes a transient connection to the vBond orchestrator. Note that at this point in the automated deployment process, the WAN edge router does not have a system-IP configured, so the connection is established with a NULL system IP address. The Edge authenticates to vBond with a chassis number and serial number. The vBond then sends back the IP address/port of the other SD-WAN controllers as visualized in figure 3.
- The WAN edge node then establishes a connection to vManage and gets its System-IP address. Then it repeats the process but this time with the correct System-IP (not NULL):
- It re-establishes a connection to the vBond using its system IP.
- It re-establishes a connection to vManage using its system IP.
- vManage then pushes the full configuration to the WAN edge routers.
- The router establishes a connection to vSmart and joins the overlay fabric.
Bootstrap Deployment
In use-cases where the WAN edge router is not able to obtain a dynamic IP address (no DHCP), or cannot reach the PnP/ZTP public URL addresses, or the device is deployed in an air-gapped environment, there is an alternative onboarding option called Bootstrap deployment. It is only available on the Cisco IOS-XE device though! It requires a device template configuration to be configured and attached to the WAN Edge device in the vManage GUI. The configuration file can then be uploaded to the device’s internal flash memory or by using a bootable USB stick, which can be plugged into the device at bootup. It is important to note that, the config file must have a specific filename for the device to load it - ciscosdwan.cfg (exception is ASR1002-x, where the file must be named ciscosdwan_cloud_init.cfg)
The bootstrap onboarding process sequence is listed below:
- At bootup, a WAN Edge router searches its boot flash memory for a configuration file with a specific filename based on the platform. If the file is not present, the PnP process continues to search for the file on all connected USB sticks. If it manages to find the file, it loads the config, otherwise, the process does not continue further
- If the config file is successfully loaded, the WAN Edge router learns the vBond IP address and organization name and establishes a secure connection to the vBond orchestrator. The Bond sends back the controllers-list.
- The WAN Edge router then establishes secure connections to vManage and vSmart, downloads its configuration using NETCONF over SSH (TCP 830) from vManage, and joins the SD-WAN overlay fabric.
Manual Deployment
The manual onboarding option is something that Network Engineers are pretty familiar with. The WAN edge device is basically configured via the console port or using the KVM/ESXi virtual console connection if the device is a virtual one.
Тhe minimum configuration that is required to successfully onboard a WAN edge router is as follow:
- System-IP, Site-id, Organization-name, vBond IP address.
- VPN 0 interface with IP address/mask, default route, and tunnel interface.
WAN Edge Authorized List
If you have been going through the lesson very closely, you should have noted that the automatic authentication of vEdges can only occur if the vBond/vSmart knows the serial and chassis numbers of the WAN edge routers. The SD-WAN controllers learn this information through a document called vEdge authorized list. This provisioning file can be downloaded from the Cisco Software Central > Plug and Play Connect portal and then uploaded to vManage, which then, sends the list to all vSmart and vBond controllers.
This process will be covered in more detail in the lab lessons about vEdge onboarding.
WAN edge deployment behind a Firewall
At the beginning of this lesson, I have written that it is mandatory to have IP reachability from the vEdge to all controllers in order to onboard a device. In reality, the connectivity can be restricted only to the following protocols/ports in case that the solution uses the default DTLS encapsulation.
Note that, for the certificate authentication to succeed, the time between the WAN Edge routers and the SD-WAN controllers should be synced. That is why NTP should be allowed through the firewall.