Bootstrapping the SD-WAN Controllers

Updated: Nov 4, 2019

Hello everyone.


In this post, we’ll be focusing on bootstrapping our controllers and vEdges for deployment.


First off, let me introduce myself. My name is Brandon Stimson, the second trainer that is focused on delivering you quality content on all things network related. I am a Network Security engineer with a CCIE in Security and have worked with Jon Spindler a lot on SDWAN using Cisco Viptela. Rest assured, you’re in good hands learning about SDWAN with Jon and I manning the wheel!


Lets jump into the topology shall we? If you are a SUBSCRIBER to NotLayer3's SD-WAN Channel, you should have an idea of what our lab already looks like. If not, here it is again ready for configuration.




We have our management network for provisioning certificates with a Windows 7 computer and to reach the GUI of vManage, a Windows 2008 R2 Server to serve as our Certificate Authority and local domain.


Also pictured is our vSmart, vBond, and vManage.


And the two branch offices that hold the two vEdge we’ll be configuring in the video course series.


For the IP schemes for the lab, Go SUBSCRIBE to our SD-WAN Channel!



Before we start configuring, I want everyone to keep in mind that the method we are about to learn together is just one of the many ways to deploy Cisco Viptela. Cisco sells this product based on the concept of Zero-Touch Provisioning. The idea is, you can plug in our vEdge with any internet connection and connect to Cisco’s hosted controllers in the cloud for easy deployment. While this is a cool method, it doesn’t really help us engineers learn the product in all it’s glory. The video course will hopefully give you a better understanding of how to deploy, troubleshoot, and articulate the complexity of what Cisco is selling with their SD-WAN solution.


With that out of the way, I’m going to stop typing and start finally configuring!


First, we’ll click on vManage here to start it’s boot process. As you can see here, vManage needs to select which disk storage to store it’s configuration files. The correct storage to select is hdb, from there vManage will boot to completion. As we wait for this to boot, I’m going to start configuring our vBond. I’ll explain the meaning of each command as we go along.


Lets click on our vBond, and the username and password for all our Viptela devices are admin/admin all lowercase.


This is the default user and password for any Viptela device. You’ll notice our vBond at the moment says vEdge. Well that’s because we’re going to make this vEdge a vBond with the configuration changes we are set to make.


Check out Jon’s last video on the SD-WAN Channel (SD-WAN Solution Overview) to see the exact image you’ll need to download to start configuring your vBond. One thing to note when configuring any vEdge or Controller, the syntax is case sensitive and can be quite daunting at first, since it has differences from regular Cisco IOS commands. That being said, lets enter config terminal.


We’re entering system commands next so now type "system".


The first command we’re going to enter is our host-name NL3-SDWAN-VB-1.


Next is going to be our site-id.


The site in question in our case is this “cloud overlay” we have.


The site-id is important as each site is identified by a unique integer. The site-id is used to uniquely identify each site location for branches, data centers, campuses, etc. If we had a second vEdge in one of the branch sites, we’d configure it with the same site-id for redundancy. The site-id also serves as a loop prevention for routes being advertised from vEdges that joins the SDWAN fabric in case someone from another site decides to use the same site-id from a data center in a different location. The site-id for this lab is 103.


Next is the system-ip. For system-ip, just think of it as a router-id like in Cisco IOS terminology. It’s a numeric 4-octet value like an IPv4 address that is used to identify vEdge routers and the Controllers. The vBond system-ip will be x.x.x.x.


Next is the organization-name. This is a very important configuration that needs to be the same amongst our entire SDWAN fabric! Organization name is what ties the PKI trust to form DTLS connections in our fabric. PKI certificates all have basic information configured such as the common-name, state, locality, email, etc. The organization name is one of those fields also included. The org name will always be included in a CSR with Viptela devices. Our organization-name will be NOTLAYER3.


Next we’ll configure the transport interface. And when I say transport, I mean the link connecting us to the outside world. We’re gonna exit out of system configuration mode and enter vpn 0. Now, keep in mind Viptela has decided to name their VRF’s as VPN’s instead. I’m not particularly sure at this point, but just try not to get confused whenever you’re configuring Viptela devices and run into creating new VRF’s/VPN’s. Also, consider VPN 0 as the default routing table and transport VRF. This is by default and doesn’t ever change with Viptela devices. Now that we’re in our VPN 0 instance, we’re gonna assign the interface. But first, I’m going to enter a dns command, since this is all static, in order to reach our vbond via DNS. The command is dns x.x.x.x. Now for the interface; Interface ge0/0 is available to us and is the usual interface vBond/vEdge uses for transport. We’re gonna enter the command ip address x.x.x.x/24. Note the /24 because in Viptela syntax, subnet masks are not accepted anymore. We also have to configure our default route statically. This needs to be configured under VPN 0, so we’ll first exit out of interface ge0/0 and then enter our default route command. Our default route is 0.0.0.0/0 x.x.x.x.



Vpn 0

Dns x.x.x.x

Interface eth0

Ip address x.x.x.x/24

exit

Ip route 0.0.0.0/0 x.x.x.x


By default, all viptela devices also come with an out of band management VRF/VPN, which is called VPN 512. We’re now gonna assign an interface to our VPN 512. Interface eth0 will be our interface. And we’re gonna give vBond a management address of x.x.x.x/24.


vpn 512

interface eth0

ip address x.x.x.x/24

no shutdown



We’re now done configuring our vBond, so we’re going to save our configs. The easiest way to do this is to commit and quit. Now we’ve committed the changes and also exited out of configuration mode. Lets test connectivity to our transport gateway. Ping x.x.x.x. Success! Now lets move on to our loaded vManage. It should be done loading by now I would hope.

Same user and password to enter with admin/admin. We’re gonna fly through most of these configurations now that I’ve explained what each command does.



System

Host-name NL3-SDWAN-VM-1

System-ip x.x.x.x

Site-id 101

organization-name NOTLAYER3



Now, the vbond configuration is one of the key differences you’ll find amongst the rest of our devices (for obvious reasons). Here we’re going to reference our vbond IP via DNS, which will be vbond.notlayer3.com. This is an internal DNS name that is already pre-configured in our lab. You can reference it by IP too, we’re using a DNS name because this is what you’ll typically see in a real world deployment scenario.


Now lets go into our VPN/VRF 0 instance. The interfaces we have for vsmart and vmanage are both different from our vedges. We have interface eth0 pre-installed and that’s what we’ll use to associate to our transport VRF.



Vpn 0

Dns x.x.x.x

Interface eth0

Ip address x.x.x.x/24

exit



We also need to assign our default route for connectivity.

Ip route 0.0.0.0/0 x.x.x.x

Next we need to create our out of band management VRF/VPN.

vpn 512


One thing i’m going to add here for our lab is a dns command pointing to our DNS server so our management PC can hit the vManage GUI via DNS name lookup to make it easier for us.


dns 192.168.66.101 primary (This is only for the MGMT PC to have a DNS name to point to)

interface eth1

ip address x.x.x.x/24

no shutdown



"Commit and quit" to save our changes and vManage is now configured! Next we’ll configure our vSmart.


Good thing about vsmart bootstrapping, is that its the pretty much the same configuration as vmanage. Lets get started!



system

host-name NL3-SDWAN-VS-1

system-ip x.x.x.x

site-id 102

admin-tech-on-failure

organization-name NOTLAYER3

vbond vbond.notlayer3.com

Vpn 0

Dns x.x.x.x

Interface eth0

Ip address x.x.x.x/24

exit

Ip route 0.0.0.0/0 x.x.x.x

vpn 512

interface eth1

ip address x.x.x.x/24

no shutdown



Now that vsmart is configured, we can move onto our vedges for bootstrapping. The differences in configuring a vedge is not much compared to vbond. The only obvious difference is the vbond command, so this configuration will also be easy!



system

host-name NL3-EDGE-4

system-ip x.x.x.x

site-id 204

admin-tech-on-failure

organization-name NOTLAYER3



I wanted to configure the clock timezone here because our certificate provisioning will rely on the time the cert is created. If it’s created too early, our PKI trust can’t be established!



clock timezone America/New_York

vbond vbond.notlayer3.com

Commit and-quit

Next to configure is our second vedge.

system

host-name NL3-EDGE-5

system-ip x.x.x.x

site-id 205

admin-tech-on-failure

organization-name NOTLAYER3

clock timezone America/New_York

vbond vbond.notlayer3.com

Commit and-quit



And there you have it! We don’t have to configure our vedges’ transport interface since we’re leasing addresses from the internet service provider in our lab. Our bootstrapping is complete and we’re ready to move on to the next step, which will be certificate provisioning. The most important piece for setting up our control plane. We’ll set up our own certificate authority and install our newly created root certificate, while also creating identity certs too.


If you haven't already i HIGHLY RECOMMEND subscribing to our NotLayer3 SD-WAN Channel for a Flood of Awesome Cisco SD-WAN Content because That will be in our next video.




Also Follow US on Social Media to stay updated on what's to come next!






Goodbye for now!