In my last post in the series I introduced you to the four architectural components that control and enable our SD-WAN fabric. In that post I had promised that in our next installment we would take a closer look at our fabric bring up sequence, but if you will indulge me I would like to hold off on that topic for the next post. In its place I would like to use this post to introduce you to the lab environment that I have built for this series and take you through the process of deploying and registering a virtual vEdge router into our lab.
SD-WAN Lab Introduction
The below diagram shows a logical view of the environment we will be using throughout this blog series.
We have five (5) sites to work with all with different LAN and WAN connectivity profiles that I will be using to highlight the flexible deployment options we have at our disposal. Site 1 will perform the role of our hub\DC location and will be used to route transit traffic between our SD-WAN deployed sites (2,3 and 4) and our legacy MPLS only site 5.
Site LAN side addressing will be taken from the private 10.x.x.x/8 range with the second octet representing our site number while the third octet will show which VPN (think VRF, more on that later in the series) we are in. So, for example the subnet assigned to VPN 1 at site 1 will be 10.1.1.0/24 while the subnet for VPN 3 at site 2 will be 10.2.3.0/24.
We have three WAN transports (MPLS, Internet A and B) in our lab which will provide us with ample opportunities to kick the tires with the traffic engineering policies on offer with this solution. WAN addressing will be from the private range (RFC1918) 192.168.x.x/16 (MPLS) and the shared address space range (RFC 6598) 100.64.0.0/10 (Internet). Each transport peering subnet will subnetted to a /24 with the third octet representing the site number while the fourth octet will be the device number. The last available ip address in the range (.254) will always be assigned to the provider device. For example, our vEdge at site 1 (our hub site) has two WAN transport connections to the MPLS and Internet A. So, site 1’s vEdge WAN addressing will be 192.168.1.1 with a next hop address of 192.168.1.254 for our MPLS connection, while our Internet A address will be 100.64.1.1 with a next hop of 100.64.1.254.
Our control and management plane nodes (vManage, vBond and vSmart) are all cloud hosted, and are thus currently only accessible via our two internet transports.
The next diagram shows the physical layout of our lab:
I have a single server running VMware ESXi 6.0 which will host our five (5) vEdge cloud instances and four (4) Cisco CSR virtual routers. The WAN clouds will be recreated by deploying two linux machines (MPLS and INET1) running the open source WAN emulation software aptly named “WANem”. This software will allow us to introduce loss, latency and jitter into our environment. Access to the cloud controllers will be achieved via a NAT interface (10.0.0.101) from our second WANem machine onto my home network, where it will be routed to my home firewall for one last NAT to my home public address 76.103.221.x.
CLI access to the equipment will be proxied through virtual serial connections from my laptop .200 to the ESXi host .100.
Deploy vEdge Cloud Virtual Router
Ok, with our lab introduction out of the way lets jump in and deploy a vEdge cloud virtual router. We will be deploying our site 4 vEdge which is rather brilliantly named “e4”.
This virtual router will need to have (4) interfaces. One (1) LAN side interface (ge0/0), two WAN side interfaces (ge0/1 and ge0/2) and one (1) management interface (not shown in our diagrams).
1. Download software ova file and vEdge authorized list from your viptela support page website (http://viptela.com/support/)
We are currently running version 17.2.7 on our cloud nodes so I’ll download the matching version for our vEdge. Notice that we have the choice of downloading KVM, Microsoft Azure or VMWare hypervisor images. I’ll be downloading the VMware version for our ESXi lab:
The vEdge authorized serial number file contains the chassis and serial numbers of all valid vEdge routers in the overlay network. Every time you purchase a vEdge you will need to download this file and add it to your vManage dashboard.
2. Run through the ESXi ova deployment wizard, accepting the defaults and mapping our four virtual networks to the port groups shown in our diagram above.
3. Once deployed add a serial console port to your virtual machine to enable management, and power up the VM.
We can connect directly to the serial console of this VM by telnetting on port 2041 to the ESXi host address.
Hit the power button and we are now done with VMware.
4. Upload vEdge Authorized List.
Before we can register our vEdge cloud node we need to upload that vEdge authorized list to our vManage dashboard. Notice that we only see four devices prior to adding the file. Also notice that I selected the check box for “Validate and upload vEdge List and send to controllers”. This does exactly what it says on the tin, in that once uploaded it sends the new authorized list to our vSmart and vBond controllers. Without the latest list on these nodes we would not be able to authenticate into the fabric (more on that in upcoming posts)
Following the upload, we now have an additional two (2) vEdge cloud nodes added to the dashboard. Notice that they have a onetime password under the “Serial No/Token” column. We will use this in our initial bootstrap config. Once our vEdge registers for the first time a certificate with its own unique serial number will be generated and distributed by vManage. Our vEdge cloud will use this certificate for all future authentication requests.
5. Apply Bootstrap Configuration
The below bootstrap config enables our router to discover its cloud nodes and register with them. None of this would be required if I had setup DHCP on our WAN transports as the device can use zero touch provisioning to discover this info.
organization-name "LookingP1 - 18521"
dns 220.127.116.11 primary
ip address 100.64.4.1/24
ip address 100.100.4.1/24
ip route 0.0.0.0/0 100.64.4.254
ip route 0.0.0.0/0 100.100.4.254
Let’s login to our router using the default username and password of “admin” and apply our config.
6. Confirm Registration
Looks like I’m not registered after all.
Using the “show control connections” (By far my most used command) I am not seeing any control connections up. So, I check my routing table. All looks good, and I confirm that I can ping out to google dns. What’s going on?????
Well remember that one-time password that we generated when we uploaded our vEdge authorized file. Well we need to tell our vEdge Cloud router about that.
To do that we will use the command “request vedge-cloud activate chassis-number <UUID> token <ONT>. We will need to replace the <UUID> and <ONT> variables with the data we saw earlier from our vEdge upload.
But before we do that lets take a look at another one of my favorite command outputs.
The “show control local-properties” command displays the basic configuration parameters and local properties related to the control plane on vEdge routers.
From the above output we can see that we do not have a certificate installed and that our token is invalid.
Now let’s inform our router about its one-time password and rerun our control plane commands.
The above output of the show control local properties looks much better. We now have a valid installed certificate and can see that our state is up and we have two (2) vSmart connections on our private1 transport and two (2) vSmart and one (1) vManage connection on our private2 transport.
Finally let’s run my favorite command “show control-connections” to get a little more detail about those control connections.
And here is how that same information is presented in our dashboard.
Well that about wraps up this edition. Please feel free to submit any questions or suggestions you might have for this series. Next up we will take a closer look at our control plane connections and how you can troubleshoot them.
Until then may your overlays and underlays routing never get leaked and your WAN bandwidth be plentiful and lossless.
Written By: Chris Marshall, LookingPoint Senior Solutions Architect - CCIE #29940
If you are interested in having LookingPoint install SD-WAN into your network, feel free to contact us here!
Check out Chris Marshall's podcast on SD-WAN here on IT in the Bay podcast: