Introduction to SD-WAN: How It Saves Money by Combining Internet and Private WAN

Introduction to SD-WAN
Software Defined WAN (SD-WAN) is hot nowadays. Why?
Private WAN connections like MPLS are reliable but also expensive. WAN connections are
usually a big chunk of the IT budget, so it’s understandable that organizations are interested in
replacing their private WAN connections with regular Internet connections to reduce costs.
To understand SD-WAN, we first have to talk about some “problems” with traditional WAN
connections. We can choose between private WAN connections or public Internet connections.
Let’s compare these two options:
• Cost: private WAN connections like MPLS are way more expensive than regular Internet
connections.
• Time to deploy: it takes longer to deploy a private WAN connection than a regular
Internet connection.
• SLA: Service providers offer SLAs for private WAN connections that we don’t have for
regular Internet connections. There are providers who offer SLAs for “business” class
Internet connections, but these are usually way more expensive than regular (consumer)
Internet connections.
• Packet loss: Internet connections have a higher packet loss rate compared to private
WAN connections like MPLS.
• QoS: Internet connections don’t offer any QoS. You can prioritize your outgoing traffic
but that’s it, the Internet itself is like the wild west. Private WAN connections often
support end-to-end QoS.
The way we use our WAN has also changed throughout the years. Most organizations had an
HQ, remote users, and perhaps some branch offices. Branch offices were connected to the HQ
with private WAN or VPNs over the Internet. Remote users used remote VPN over the Internet
to connect.
Nowadays, organizations also run their own applications in the cloud instead of on-premises, and
they use applications like Office 365 or Gsuite. Our traffic patterns look different now:
What about network management? Each router has its own control plane, and we use the CLI
to manually create our router configurations “box-by-box”. This is time-consuming and prone to
errors. We can use network automation tools to make our lives easier, but the control plane
remains decentralized.
SD-WAN promises to save money by using a combination of Internet and private WAN
connections and make network management much easier.
One problem with SD-WAN is that each vendor has a different idea about what SD-WAN is. I’ll
give you a basic overview of what SD-WAN is about. An SD-WAN solution has parts of the
control plane centralized and is built with network automation and orchestration in mind.
We create network policies globally and push them to all routers from a central location. You
could create a QoS policy and push it to all your 500 branch routers with a single mouse click.
We don’t use the CLI anymore. Instead, we have a GUI and use APIs to configure and manage
our WAN connections. Some vendors still support a CLI if you want to do some troubleshooting.
We use multiple WAN connections and active/active per-application load-balancing. Let’s say
we have a site with a fiber, cable, 4G, and DSL connection. SD-WAN monitors all these WAN
connections and keeps track of performance metrics like the throughput and delay. It selects the
WAN connection with the lowest latency and highest throughput.
When a certain link fails then it can fail over to the next best option. It can also do this on a per-
application level. You could use the fiber connection for traffic to the public cloud and the cable
connection for low-priority FTP traffic. It protectson traffic over public Internet connections with
IPSec.
SD-WAN could be an alternative to an expensive private WAN link with an SLA that promises
“five nines” of uptime (99.999%). The idea behind it is that multiple WAN connections are
always more reliable than a single WAN connection.
Cisco SD-WAN Solutions

Cisco offers three SD-WAN solutions:
•
o Intelligent WAN (IWAN)
o Meraki SD-WAN
o Cisco SD-WAN (Viptela)
IWAN is Cisco’s first SD-WAN solution for the ISR platform and intended for hybrid WAN
(MPLS and Internet) or Internet-only connections.
Behind the scenes they use some familiar protocols:
• DMVPN with QoS

• Wide Area Application Services (WAAS)
• Application Visibility and Control (AVC)
• Performance Routing (PfR)
Meraki SD-WAN is for existing Meraki customers that are interested in the advantages of SD-
WAN. Here are some features that it offers:
• Apply bandwidth, routing, and security policies from a central location to all WAN
connections (MPLS, Internet, 4G, etc.)
• Centralized network visibility and control.
• QoS and bandwidth management with Meraki traffic shaping
• Dynamic policy and performance-based path selection with automatic load balancing.
• Secure connectivity with cloud applications, remote offices, or datacenters.
Cisco SD-WAN (Viptela)

Cisco acquired Viptela, a major SD-WAN player, in 2017 and re-branded it to Cisco SD-WAN.
This is Cisco’s enterprise SD-WAN solution.
Components
This solution consists of four main components and one optional analytics component:
• vManage (management)
• vSmart (controller)
• vEdge (routers)
• vBond (orchestrator)
• vAnalytics (analytics)
Let me explain these components.
vManage
vManage is the Network Management System (NMS) to configure and manage the entire SD-
WAN solution. You can use a GUI or REST API to access it. This is where you create device
configurations and network policies. vManage also alerts you when there are events or outages.
vSmart
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.
For example, imagine you create a policy through vManage where real-time voice traffic
requires a latency of less than 100 ms. The 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 or a DMVPN NHRP server. The vSmart controller only lives in the control
plane and is never in the data plane.
vBond
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 devices can connect to it. When
a vEdge router joins the SD-WAN, the first thing it talks to is the vBond orchestrator.
vAnalytics
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.
Cloud or on-premises
You can implement Cisco SD-WAN with a combination of cloud and on-premises options:
• The vEdge routers and vBond orchestrator are available as hardware or VMs.
• vManage and vSmart controllers are only available as VMs.
You can run the VMs on-premises on ESXi or KVM, or host them at cloud providers like
Amazon AWS or Microsoft Azure.
vEdge
vEdge is the software or hardware routers at your sites and responsible for the data plane. vEdge
routers connect to a vSmart controller through a Datagram Transport Layer Security (DTLS)
connection. If you want to use hardware, you 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)
Cloud onRamp
In the traditional model, you find all on-premises infrastructure and applications in a central HQ
site or data center. We connect our branch offices in a hub and spoke topology and route all
traffic from the branch offices to the HQ or datacenter.
Organizations nowadays often use cloud SaaS applications like Office 365, Gmail, or Salesforce.
Instead of running everything on-premises, we also use IaaS services in the public cloud.
The traditional hub and spoke model where we connect and route all branch traffic to the main
site or datacenter doesn’t work anymore. Cisco SD-WAN connects sites directly to these SaaS
applications or IaaS services using one or more WAN connections.
There are two options:
• Cloud onRamp SaaS

• Cloud onRamp IaaS
Cloud onRamp SaaS monitors the performance of all WAN connections from a branch office to
a SaaS application. Each path gets a “quality of experience” performance score from 0-10, 10
being the highest score. It makes real-time decisions to choose the best performing path between
the end users at the branch office and the SaaS application in the cloud. You can monitor this in
the vManage GUI.
Cloud onRamp IaaS extends the SD-WAN network into the public cloud. Through vManage,
you can automatically create vEdge cloud routers in the public cloud provider infrastructure.
This allows you to connect directly from your on-premises vEdge routers to the vEdge cloud
routers at the public cloud provider.
Cisco SD-WAN Lab Options
If you want to learn Cisco SD-WAN, you need to get some hands-on experience. In this lesson,
I’ll give you an overview of the different options.
Online
DevNet
Cisco calls DevNet their single resource for everything “developer”. You can find labs, tutorials,
sandboxes, and code examples here. DevNet also includes a couple of Cisco SD-WAN
sandboxes.
There is a sandbox you can access without making a reservation which is great if you want to
quickly look at a couple of things. You can also reserve a sandbox so you can work on it alone.
The only thing you need to access DevNet is a CCO account.
I think DevNet is great if you are already somewhat familiar with the basics of Cisco SD-WAN.
It’s great for testing things like templates or policies without having to worry about building a
lab. It’s also a great option if you want to play around with the Cisco SD-WAN API.
dCloud
Like DevNet, Cisco’s dCloud also offers labs, sandboxes, and demos. You only need a CCO
account to get access.
There used to be some Cisco SD-WAN sandboxes here but the last time I checked, they were all
gone except for the “SASE – Viptela Secure Edge v1” guided demo. It might be worth it to
check though.
Build your own Lab

How about building your own lab? I believe it is a great idea if you are new to Cisco SD-WAN.
You’ll quickly become familiar with the different components and how they interact. Once you
have it up and running, you can use it whenever you want. The disadvantage of building your
own lab is that it is time-consuming and it requires quite some resources.
To run the Cisco SD-WAN images you need:
en
Image vCPU(s) RAM

vManage controller 4 16
vBond orchestrator 1 1
vSmart controller 2 2
vEdge router 1 1
You only need to run the vManage, vBond, and vSmart controllers once but those require 6
vCPUs and 19GB of RAM. You’ll need multiple vEdge routers. Also, you will need some other
devices like regular Cisco IOS routers, switches, and perhaps an ASA.
The vManage 20.x image apparently requires 24GB of RAM.

I have a medium-sized lab that consumes about 52GB of RAM. Make sure you have a powerful
machine or spare server that you can use.
What do we use to run the images? Cisco offers three image types:
The image types are VMWare, KVM, and Azure.
VMWare ESX
The first time I messed around with Cisco SD-WAN I tried the OVA images in VMWare ESX.
This works, but I think it’s too much of a hassle:
• You need to manually add a serial port if you want to telnet into a console.
• You need to create port-groups if you want to create “segments” between devices.
• If you want to change the port-group of a vNIC, you have to shut the VM first.
It’s possible, but I don’t recommend it.
Cisco Modeling Labs (CML)

CML is Cisco’s official emulator but unfortunately, it doesn’t have any built-in support for SD-
WAN yet. If it did, this would be a great option. It is possible to run KVM images on CML but
it’s not that easy. I wouldn’t advise trying this.
EVE-NG
EVE-NG is a good choice to build your own Cisco SD-WAN lab. They offer a how-to solution
where they explain how to add the KVM images. It doesn’t take much work and once you add
the images, you can quickly build a topology. I do recommend getting the professional version.
Otherwise, you can’t add links between devices that are already running. Here is our lesson on
how to build your own EVE-NG SD-WAN lab.
Here’s an example of my EVE-NG Cisco SD-WAN lab:
GNS3
I believe GNS3 would be a good option. I haven’t tried it, but there are examples out there of
how you can add Cisco SD-WAN KVM images to GNS3. Once that’s done, you should be able
to quickly build a topology.
Conclusion
Here’s what I would do:
• If you are new to Cisco SD-WAN, I would recommend building your own lab in EVE-
NG:
o Building things from scratch is a great way to learn how it works.
o It’s always available to you.
• If you are already familiar with Cisco SD-WAN and you just want to test some things,
DevNet is a great option.
Cisco SD-WAN EVE-NG Lab Installation
There are a number of options to build your own Cisco SD-WAN lab. I believe EVE-NG is your
best option at the moment. In this lesson, I’ll show you everything you need to do to install
EVE-NG and build your own Cisco SD-WAN lab. This includes:
• Downloading the required Cisco and EVE-NG images.

• Installing EVE-NG.
• Installing the images on your EVE-NG installation.
• Testing whether you can use the images.
Installation
You can run EVE-NG on physical hardware, or on a KVM or VMWare hypervisor. Details are
on the EVE-NG requirements page. I’m going to install it on VMWare ESXi 7.
Images
To get started, we need to download the Cisco SD-WAN and EVE-NG images.
Cisco
To download the Cisco SD-WAN images, you need a CCO account with a contract. You can
find the images at Cisco’s Software Download.
You can run Cisco SD-WAN on multiple platforms, including VMWare ESXi, KVM, or
Microsoft Azure. We need the KVM images for EVE-NG.
EVE-NG
You can download EVE-NG from the download page. There are two options:
• Professional/Learning Center Version

• Community Edition Version
I downloaded the ISO of the professional version because of two reasons:
• It’s the latest version.

• It allows you to add/remove links without shutting down virtual devices.
The professional version requires a license but it’s definitely worth the money. Copy the ISO
image to the datastore of your VMware ESXi server.
VMWare ESXi
Let’s create a virtual machine for EVE-NG.
Port Groups
Before we create the virtual machine, we need to create some additional port groups. Take a look
at the following picture:
I’m creating four port groups. The first port group (LAB) connects to the eth0 interface of the
EVE-NG virtual machine. We use this so we can access the EVE-NG GUI or access it with
SSH.
The other three port groups connect to different “cloud” networks that we can use within EVE-
NG. We can use these to bridge virtual devices to our physical network. Each of the port
groups uses a different VLAN. These cloud icons are useful for SD-WAN because we are going
to use them to simulate different WAN connections.
Let’s create the port groups. Go to Networking in the Navigator:

Click on Add port group and create them:
Make sure you change the security options to Accept on all port groups:
• Promiscuous mode
• MAC address changes
• Forged transmits
We need this because the EVE-NG virtual machine creates different MAC addresses for the
virtual devices. It’s also nice that we can use Wireshark if we ever want to look at our traffic.
Here’s what the end result looks like:
Virtual Machine
Now we can create the virtual machine. Go to Virtual Machines in the Navigator:
Click Create / Register VM and select Create a new virtual machine:
Now we need to configure some parameters:
Set the Guest OS family to Linux and the Guest OS version to Ubuntu Linux (64-bit). Choose a
data storage:
Now we have to customize our virtual machine hardware. Don’t be shy with resources, you’ll
need them. You need at least 19 GB of RAM and 6 vCPUs to run the Cisco SD-WAN
controllers. You need more than that because we need to run vEdge routers and some “regular”
IOS devices.
The vManage controller requires a 100 GB hard disk so make sure your EVE-NG virtual
machine has plenty of storage. You can set the hard disk as “thin provisioned” because it
probably won’t really use 100 GB of storage. Don’t forget to add network cards that map to your
port groups. Also, map the CD/DVD drive to the EVE-NG ISO image you uploaded to the
datastore:
Click on Next and Finish, then power on the virtual machine.
EVE-NG installation
All right, it’s time to install EVE-NG. The next few steps are probably familiar to you’ve if you
installed Ubuntu before. Most of the steps are self-explanatory but let’s go through them anyway.
Let’s select a language:
And select your location:
Now we need to select our network interface. This is what we’ll use to connect SSH into EVE-
NG or access the GUI. Make sure you select the eth0 interface:
We have to set a hostname:
Set the time zone:
Hit Enter if you don’t use a proxy:
Optionally, you can install security updates automatically. If you plan to use this virtual machine
for a long time then it might be a good idea to do so:
The installation will take a few minutes to complete.
Setup
Once the installation is complete, the virtual machine reboots and you see the following screen:
Log in and you are greeted with a setup screen. You need to set the hostname again:
And (optionally) a DNS domain name:
We can use DHCP or a static IP address. I’ll use a static IP address:
Enter the IP address you want to use:
With the subnet mask:
And a default gateway:
Enter the primary DNS server:
And the secondary DNS server:
If you have an NTP server, enter the address here:
If you have a proxy server, configure it here:
Once the setup completes, you’ll see the IP address on the CLI:
You can now access EVE-NG through the GUI or with SSH.
Add Images
With EVE-NG up and running, we can add the Cisco SD-WAN images.
Open a web browser and type in the IP address of your EVE-NG virtual machine. You’ll see this
screen:
If you use the HTML5 console, you can access the CLI of your virtual devices through the web
browser. I prefer the Native Console because it allows you to use your own applications like
Putty or SecureCRT.
Once you are logged in, click on the Add new lab button:
Give your lab a name nd click on Save:

In the left menu, choose Add an object:
And select Node:
In the dropdown, you only have two options at the moment:
When we add new images, they will automatically show up here. This is how you can check
whether EVE-NG detected your installed images.
Cisco SD-WAN Images
EVE-NG has an excellent tutorial that explains how to add the Cisco SD-WAN images. I’m
using these three images:
• viptela-vmanage-19.3.0-genericx86-64.qcow2
• viptela-smart-19.3.0-genericx86-64.qcow2
• viptela-edge-19.3.0-genericx86-64.qcow2
We need to copy these files and add them to the following folder:
/opt/unetlab/addons/qemu/
Let’s create these folders.
# mkdir /opt/unetlab/addons/qemu/vtbond-19.3.0
# mkdir /opt/unetlab/addons/qemu/vtedge-19.3.0
# mkdir /opt/unetlab/addons/qemu/vtsmart-19.3.0
# mkdir /opt/unetlab/addons/qemu/vtmgmt-19.3.0
The name before the dash (-) has to match. You can add the version number behind the dash.
Use an application like SecureCRT, WinSCP, or Filezilla to copy the image files to the above
folders. The vEdge image is also used for the vBond controller. Your folders and files should
look like this now:
# ls -lR /opt/unetlab/addons/qemu
/opt/unetlab/addons/qemu:
total 16
drwxr-xr-x 2 root root 4096 Jul 15 16:47 vtbond-19.3.0
drwxr-xr-x 2 root root 4096 Jul 15 16:46 vtedge-19.3.0
drwxr-xr-x 2 root root 4096 Jul 15 16:47 vtmgmt-19.3.0
drwxr-xr-x 2 root root 4096 Jul 15 16:47 vtsmart-19.3.0
/opt/unetlab/addons/qemu/vtbond-19.3.0:
total 241284
-rw-r--r-- 1 root root 247070720 Feb 20 2020 viptela-edge-19.3.0-genericx86-
64.qcow2
/opt/unetlab/addons/qemu/vtedge-19.3.0:
total 241284
-rw-r--r-- 1 root root 247070720 Feb 20 2020 viptela-edge-19.3.0-genericx86-
64.qcow2
/opt/unetlab/addons/qemu/vtmgmt-19.3.0:
total 1084676
-rw-r--r-- 1 root root 1110704128 Feb 20 2020 viptela-vmanage-19.3.0-
genericx86-64.qcow2
/opt/unetlab/addons/qemu/vtsmart-19.3.0:
total 241280
-rw-r--r-- 1 root root 247070720 Feb 20 2020 viptela-smart-19.3.0-
genericx86-64.qcow2
We have to rename the image file names to virtioa.qcow2. Let’s use the mv command for this.
Here’s the vBond image:
# cd /opt/unetlab/addons/qemu/vtbond-19.3.0/
# mv viptela-edge-19.3.0-genericx86-64.qcow2 virtioa.qcow2
The vEdge image:
# cd /opt/unetlab/addons/qemu/vtedge-19.3.0/
# mv viptela-edge-19.3.0-genericx86-64.qcow2 virtioa.qcow2
vSmart image:
# cd /opt/unetlab/addons/qemu/vtsmart-19.3.0/
# mv viptela-smart-19.3.0-genericx86-64.qcow2 virtioa.qcow2
And the vManage image:
# cd /opt/unetlab/addons/qemu/vtmgmt-19.3.0/
# mv viptela-vmanage-19.3.0-genericx86-64.qcow2 virtioa.qcow2
For the vManage image we have to do one more thing. This image requires a 100 GB hard disk.
You can create it with the following command:
# /opt/qemu/bin/qemu-img create -f qcow2 virtiob.qcow2 100G

Formatting 'virtiob.qcow2', fmt=qcow2 size=107374182400 encryption=off
cluster_size=65536 lazy_refcounts=off refcount_bits=16
And we need to set some permissions:
# cd
# /opt/unetlab/wrappers/unl_wrapper -a fixpermissions
Let’s take another look at our folders so we can see the end result:
# ls -lR /opt/unetlab/addons/qemu
/opt/unetlab/addons/qemu:
total 16
drwxr-xr-x 2 root root 4096 Jul 15 16:49 vtbond-19.3.0
drwxr-xr-x 2 root root 4096 Jul 15 16:50 vtedge-19.3.0
drwxr-xr-x 2 root root 4096 Jul 15 16:52 vtmgmt-19.3.0
drwxr-xr-x 2 root root 4096 Jul 15 16:50 vtsmart-19.3.0
/opt/unetlab/addons/qemu/vtbond-19.3.0:
total 241284
-rw-r--r-- 1 root root 247070720 Feb 20 2020 virtioa.qcow2
/opt/unetlab/addons/qemu/vtedge-19.3.0:
total 241284
/opt/unetlab/addons/qemu/vtmgmt-19.3.0:
total 1084872
-rw-r--r-- 1 root root 198656 Jul 15 16:52 virtiob.qcow2
/opt/unetlab/addons/qemu/vtsmart-19.3.0:
total 241280
In the output above, you can see the 100 GB hard disk (virtiob.qcow2) that we created. It’s
only using 198656 bytes at the moment.
That’s all we have to do on the CLI. When you go back to the GUI and try to add a new node,
you should see more options:
You can now add one of the Cisco SD-WAN nodes. For example:
The default settings should be OK. Click on Save and add the node to your topology.
IOS Images
Before we wrap up this lesson, we should add some more images. It can be useful to have Cisco
IOS routers and switches if you want to build a large topology.
I grabbed the following two vIOS images from my Cisco CML installation:
• vios_l2-adventerprisek9-m.ssa.high_iron_20190423.qcow2 virtioa.qcow2
• vios-adventerprisek9-m.spa.159-3.m2.qcow2
The first image is for a switch, the second one is a router. These images come with the “refplat”
ISO that you can download if you purchase Cisco CML. I have therefplat_p-20201110-
fcs.iso image.
Like the Cisco SD-WAN images, we have to add some folders in the
/opt/unetlab/addons/qemu folder. Let’s create those:
# mkdir /opt/unetlab/addons/qemu/vios-159-3
# mkdir /opt/unetlab/addons/qemu/viosl2-2019
Now I can copy the files with SCP into these folders and rename them:
# cd /opt/unetlab/addons/qemu/vios-159-3
# mv vios-adventerprisek9-m.spa.159-3.m2.qcow2 virtioa.qcow2
# cd /opt/unetlab/addons/qemu/viosl2-2019/
# mv vios_l2-adventerprisek9-m.ssa.high_iron_20190423.qcow2 virtioa.qcow2
That takes care of it. The images should now be in the node list:
That’s it! We are now ready to build a Cisco SD-WAN lab.
Conclusion
You have now learned:
• Which images you need to download.

• How to create the required port groups for the EVE-NG virtual machine.
• How to create an EVE-NG virtual machine with enough resources.
• How to add the Cisco SD-WAN and IOS images to your EVE-NG installation.
Cisco SD-WAN Controllers Installation
If you want to learn Cisco SD-WAN and do some labs then you have two options:
• Use one of the free Cisco Devnet sandboxes.

• Build your own lab.
The sandboxes are great if you want to jump right into testing things like policies, templates, or
the REST API. You don’t have to worry about building a topology and setting everything up.
However, if you are new to SD-WAN then building everything from scratch is a good idea.
You’ll learn how everything works right from the beginning and once it’s up and running, it’s
always available to you. You will also be able to connect devices to your lab that the sandboxes
don’t provide. In this lesson, we’ll configure the required controllers:
•
o vManage
o vBond
o vSmart
You can learn more about what these controllers do in our introduction to SD-WAN lesson.
Once you finish this lesson, the controllers are up and running and you are ready to onboard
vEdge routers.
Configuration
Let me give you an overview of what we are going to do. When you boot the vManage, vBond,
or vSmart controllers for the first time, you will only have access to the CLI. On each controller,
we have to configure two items:
• System configuration: A basic configuration where we specify things such as a hostname,

organization name, and some other items.
• VPN0 interface: This is the overlay network.
With a basic configuration, the controllers will have network reachability and can talk to each
other. The other thing we have to take care of are certificates. Cisco SD-WAN requires
certificates on each and every device. To create certificates, we’ll set up a new root CA and
sign certificates ourselves for all controllers (and vEdge routers once we finish the installation of
the controllers).
Setting everything up is not too difficult once you understand the steps but it is time-consuming.
Here is the topology we’ll use:

Let me explain what we have:
• Site 1:
o This is where we add our controllers:
▪ vManage
▪ vBond
▪ vSmart
o System IPs:
▪ The addresses in purple are not IP addresses but system IPs.
▪ Each Cisco SD-WAN requires a unique system IP that is similar to a router ID like
you use in OSPF or BGP.
▪ You can’t use this address anywhere else, not even on a physical interface.
o DC1:
▪ This is an IOS switch I use to connect the controllers to the same VLAN (10).
▪ The switch connects to two different “clouds” to simulate two different ISPs.
• Internet connectivity:
o Clouds:
▪ biz-internet: This cloud simulates a “business class” Internet connection. In
reality, it connects to a VLAN on my office network which provides Internet
access.
▪ public-internet: This cloud simulates a “normal” Internet connection. In reality,
it connects to another VLAN on my office network which provides Internet
access.
• vEdges: the vEdge routers connect through one of the two Internet connections to reach our
controllers.
I’m using the Cisco SD-WAN Release 19.3.x images for this lab. Under the hood, I am using
Eve-NG.
vManage
Let’s start with vManage. This is our NMS (Network Management System) where we control
and monitor our SD-WAN network once everything is up and running.
Startup Configuration
Let’s log in. The default username and password is “admin”:
vmanage login: admin

Password:
Welcome to Viptela CLI
admin connected from 127.0.0.1 using console on vmanage
You must set an initial admin password.
Password:
Re-enter password:
The first time you log in you get a message that you have to select a storage device. I use the
100GB drive that I created when I built the entire topology in Eve-NG:
Available storage devices:

vdb 100GB
hdc 3GB
1) vdb
2) hdc
Select storage device to use: 1
Would you like to format vdb? (y/n): y
mke2fs 1.43.8 (1-Jan-2018)
Creating filesystem with 26214400 4k blocks and 6553600 inodes
Filesystem UUID: 55c71c51-4e3d-4f74-96cb-cee2c32917f2
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632,
2654208,
4096000, 7962624, 11239424, 20480000, 23887872
Allocating group tables: done

Writing inode tables: done
Creating journal (131072 blocks): done
Writing superblocks and filesystem accounting information: done
wall: cannot get tty name: Success
Broadcast message from root@vmanage (somewhere) (Thu Jul 8 13:36:31 2021):
13:44:26.454 §Thu Jul 8 13:36:31 UTC 2021: The system is going down for
reboot NOW!
Once it’s done formatting the drive, the vManage controller reboots. This can take a few
minutes. Once you see the following message you can log in again:
System Ready
If you don’t see this message then you will be able to log in but it throws an authentication
failure:
viptela 19.3.0
vmanage login: admin

Password:
System Initializing. Please wait to login...
Authentication failure
Once you are logged in you see the # symbol. This tells us we are in the CLI mode:
vmanage#
Let’s start with a basic system configuration:
vmanage(config)# system
vmanage(config-system)# host-name vManage1
vmanage(config-system)# system-ip 172.16.1.101
vmanage(config-system)# site-id 1
vmanage(config-system)# organization-name nwl-lab-sdwan
vmanage(config-system)# vbond 10.1.0.2
vmanage(config-system)# exit
And let’s configure the VPN0 interface:
vmanage(config)# vpn 0
vmanage(config-interface-eth0)# ip route 0.0.0.0/0 10.1.0.254
vmanage(config-vpn-0)# interface eth0
vmanage(config-interface-eth0)# ip address 10.1.0.1/24
vmanage(config-interface-eth0)# no shutdown
vmanage(config-interface-eth0)# tunnel-interface
vmanage(config-tunnel-interface)# allow-service all
vmanage(config-tunnel-interface)# exit
vmanage(config-interface-eth0)# exit
vmanage(config-vpn-0)# exit
vmanage(config)#
The VPN0 configuration requires some explanation:
• The tunnel-interface command configures the eth0 interface as a tunnel interface.

• The allow-service all command allows all traffic over the VPN0 interface. By default, only
DTLS, TLS, and IPSec (for vEdges) traffic is allowed. This will be useful later in our lab.
Before the configuration becomes active, we have to commit it:
vmanage(config)# commit
Commit complete.
Certificates
As I explained at the beginning of this lesson, Cisco SD-WAN requires certificates on all
devices. When you generate your own certificates you have different options. For example, some
different options are:
• Cisco IOS router.

• Linux box.
• Windows server.
All Cisco SD-WAN controllers run Linux and come with some useful commands, including
OpenSSL. I’m going to use the openssl command on the vManage controller to generate every
certificate we need.
You can use the vshell command to access the Linux commands. For a detailed explanation of
how to build your own CA, you can always check the openssl ca server lesson.
Root CA Certificate
First, we need to create a root CA and the first step is to generate a private key. Let’s open
vshell:
vManage1# vshell
vManage1:~$
Notice how the # changes to a $. We are now in the home folder:
vManage1:~$ pwd
/home/admin
Let’s generate a private key and call it ROOT-CA.key:
vManage1:~$ openssl genrsa -out ROOT-CA.key 2048

Generating RSA private key, 2048 bit long modulus
.........
......
e is 65537 (0x10001)
Use the following one-liner to create a root CA certificate using the private key we just created:
vManage1:~$ openssl req -x509 -new -nodes -key ROOT-CA.key -sha256 -days 3652
\
-subj "/C=NL/ST=NL/O=nwl-lab-sdwan/CN=vmanage1.lab.nwl.ai" \
-out ROOT-CA.pem
This root certificate is valid for 10 years. You can set the subject if you want. In the output above
I showed how you can do that but it’s not a requirement.
Let’s take a look at our certificate with the cat command:
vmanage:~$ cat ROOT-CA.pem

-----BEGIN CERTIFICATE-----
MIIDczCCAlugAwIBAgIJAL0YvJsnyG61MA0GCSqGSIb3DQEBCwUAMFAxCzAJBgNV
BAYTAk5MMQswCQYDVQQIDAJOTDEWMBQGA1UECgwNbndsLWxhYi1zZHdhbjEcMBoG
A1UEAwwTdm1hbmFnZTEubGFiLm53bC5haTAeFw0yMTA3MDgxMzUxMTNaFw0zMTA3
MDgxMzUxMTNaMFAxCzAJBgNVBAYTAk5MMQswCQYDVQQIDAJOTDEWMBQGA1UECgwN
bndsLWxhYi1zZHdhbjEcMBoGA1UEAwwTdm1hbmFnZTEubGFiLm53bC5haTCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALXqecoq4L19Stwbz92iDr7X0o20
Uq1sMKKsDVIKRrJW78kIP+tJD3qb9iuKSsViqlOY7nqT96306adKRJtcx002f4gN
ETiY/APhk3R5ryTuEPJ5dnDa2TYtjUbsK4/f54RBWjBeMvm8x2g+/xYMKaYrPU6+
VYY8HR2idPF/q5B7mg7Thpr16qbmDM5F2MxK8WZFqPjRg0fyIzK5T/tb82PuTJpE
+MFxv2BYsW/xZbfu1jXZnCj/6OaoaJ0j0ZYX0JGd8TnNglCSxjL5OpC2PKKwlqrr
1Xq/hg5L9NMRHCCFr0616HZkw9Okr47R2kmXsemP6y40ydm+XwkYPzHGJ4sCAwEA
AaNQME4wHQYDVR0OBBYEFBv1C14HVrF0H2kMrzfrjtr23fxKMB8GA1UdIwQYMBaA
FBv1C14HVrF0H2kMrzfrjtr23fxKMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEL
BQADggEBAFnwbs5RaUQs8d9SSGZ/YDCCxFf+T4QdQGhkH2E8gb5sKC/VW8bvTcjT
65ac0DUkhVnBWCShVCia5egzyqUzpYdrOcRPZh5RiLecU2ekvOHsm1PiQctnPehL
eDTw+Ft0IAuQMrHO7rwquV1JQyuPQEBIabSTwrDn3dQh61nuFk9qGb8mcwzqrQ7Z
sRXYOUwT9awMP5UKx3j6jt3vN5xvpeShd9H5scww0NyUew5ucd8raO4Jb/LKLIgJ
E9TuBX2Wv9RhM5Bcv1iznUe+hcvsHUrfRhysZetbftJ5Z80QIfcaLWLjPe6kASRr
q9JEcuKO1OoJOgDuWe8BqYVYruBn+cU=
-----END CERTIFICATE-----
Now it’s time to open the vManage GUI. This is where we need to install the certificate.
Open a web browser and enter the URL https://10.1.0.1:8443/. You’ll see the following screen:
Log in with username and password “admin” and you’ll end up at the main dashboard. Go to
Administration > Settings:
While we are here, we need to change two settings that don’t have anything to do with the root
CA certificate but that we do have to change. Look for the organization name:
Set the Organization name and click on Save. Now open the vBond settings:
Enter the IP address of the vBond orchestrator and click on Save. Now look for Controller
Certificate Authorization:
The default setting is Cisco Automated. If you use Cisco SD-WAN in a production network you
can have all your certificates signed automatically. We are not so lucky for our home lab so
change it to Enterprise Root Certificate and paste the contents of the ROOT-CA.pem file here:
Click Import & Save.
vManage Certificate
Now it’s time for the vManage certificate. Head over to Configuration > Certificates >
Controllers > vManage > Generate CSR:
You’ll see a pop-up which shows the CSR:
You don’t have to download or copy and paste to your clipboard because it’s saved locally
automatically. Let me show you. We’ll open vshell on our vManage controller:
vManage1# vshell
Take a look at the contents of our home folder:
vManage1:~$ ls -lh
total 16K
-rw-r--r-- 1 admin admin 1.7K Jul 8 13:50 ROOT-CA.key
-rw-r--r-- 1 admin admin 1.3K Jul 8 13:51 ROOT-CA.pem
-rw-r--r-- 1 admin admin 394 Jul 8 13:40 archive_id_rsa.pub
-rw-r--r-- 1 root root 1.2K Jul 8 14:14 vmanage_csr
The CSR is saved automatically in /home/admin as vmanage_csr.
Let’s sign a certificate. You can use the following openssl command:
vManage1:~$ openssl x509 -req -in vmanage_csr \

> -CA ROOT-CA.pem -CAkey ROOT-CA.key -CAcreateserial \
> -out vmanage1.crt -days 1826 -sha256
Signature ok
subject=/C=US/ST=California/L=San Jose/OU=nwl-sdwan-lab/O=Viptela
LLC/CN=vmanage-4a0c409a-bc56-428d-9449-c27635715990-
0.viptela.com/emailAddress=support@viptela.com
Getting CA Private Key
In the output above, you can see it uses a default subject because I didn’t specify one. That’s no
problem at all. We only care about a valid certificate.
Use cat to see the output:
vmanage:~$ cat vmanage1.crt

MIIDmTCCAoECCQCSxilWaQdcEjANBgkqhkiG9w0BAQsFADBQMQswCQYDVQQGEwJO
TDELMAkGA1UECAwCTkwxFjAUBgNVBAoMDW53bC1sYWItc2R3YW4xHDAaBgNVBAMM
E3ZtYW5hZ2UxLmxhYi5ud2wuYWkwHhcNMjEwNzA4MTQxOTAyWhcNMjYwNzA4MTQx
OTAyWjCBzDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNV
BAcTCFNhbiBKb3NlMRYwFAYDVQQLEw1ud2wtc2R3YW4tbGFiMRQwEgYDVQQKEwtW
aXB0ZWxhIExMQzFDMEEGA1UEAxM6dm1hbmFnZS00YTBjNDA5YS1iYzU2LTQyOGQt
OTQ0OS1jMjc2MzU3MTU5OTAtMC52aXB0ZWxhLmNvbTEiMCAGCSqGSIb3DQEJARYT
c3VwcG9ydEB2aXB0ZWxhLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBALb1M9g86ZNl0HA1rk0mrjUosXNZ/rvlwPpPk5uhcJkmTAgweLKBm0E1DCri
j3qx1v9awePzX5JCQWWjeXvIZgyqWI/zmiHRts3cTxALWtsvI7ndjyW4njE4zqJs
d1X1LPgf4oMUhY21JhZKUbXwXLuyY7TSaIbVVcGG4pLb/pCZLQBTag98Lb2k5uOl
hntrH0R2m3uipGLmHmVIMd3fJune8toubRfqq8tvnhtzxWpRYiXIQ8+psvvO13Y+
TCs2Umy7ZgGMp+NyXhGHtV4ZhRQbHV2wBrELp6JOkiEzylPxf31FImPSf0PTNpsV
R2o7Y+JZ4u8ljx1kqprwk6Dr49UCAwEAATANBgkqhkiG9w0BAQsFAAOCAQEAoa4f
OaOe8qSzmHy4/KL0idDgq6mgz7KcW9fn2HJMMYqiRt02Lrl4VG3XczTe2OWVsmCD
COj4000laRyQqlt1d7m0zyKd+gBcJC9ZS0NVyRhfMqqFOTEfU1+XsB6ZCkIrkuOd
vPGUpdwZqb5FewYUDSTZ+LG6Sr69TmP0ZfLIkckGwr178/TiSJgP8s9UVIoO0hvs
ffLroq5Aoa9unkKJIcsZ/vMgMJcaR8mCkuv0J9jk7uPpORvTbMaxpPq8TX4IbTZ9
cjNAPrheD9CtmUPzCC/1DAVbbQYGhIlw3ka04mdN+l7RwIOuokR9m1tCHBNUompL
H3Y1/nuTytOAar5Fig==
Go back to the vManage GUI and click on Install Certificate. Paste the contents of the
vmanage1.crt file here:
Click on Install. It might take a few seconds to install the certificate but once it does, you’ll see
the Success message:
This completes the configuration of the vManage controller. Let me summarize what we just did:
• We created a new root CA:

o Generated a private key.
o Generated a root CA certificate.
• We created a certificate for the vManage controller:
o Generated a CSR.
o Signed the certificate on the CLI.
o Installed the certificate through the GUI.
One down, two to go. We have the vBond and vSmart controllers left!
vBond
vBond is the orchestrator in our SD-WAN network.
Let’s log in for the first time:
viptela 19.3.0
vedge login: admin

Password:
admin connected from 127.0.0.1 using console on vedge
Password:
Re-enter password:
The username and password is “admin”. If you look closely, you can see it shows “vedge”. This
is because the vBond orchestrator and vEdge routers share the same image. We’ll start with the
system configuration:
vedge(config)# system
vedge(config-system)# host-name vBond1
vedge(config-system)# system-ip 172.16.1.102
vedge(config-system)# site-id 1
vedge(config-system)# organization-name nwl-lab-sdwan
vedge(config-system)# vbond 10.1.0.2 local
vedge(config-system)# exit
The configuration above is similar to the vManage controller configuration except for the vbond
command. We have to add the local parameter. This tells vBond that the local device is the
vBond orchestrator.
Let’s continue with the VPN0 interface:
vedge(config)# vpn 0
vedge(config-vpn-0)# ip route 0.0.0.0/0 10.1.0.254
vedge(config-vpn-0)# interface ge0/0
vedge(config-interface-ge0/0)# ip address 10.1.0.2/24
vedge(config-interface-ge0/0)# tunnel-interface
vedge(config-tunnel-interface)# encapsulation ipsec
vedge(config-tunnel-interface)# allow-service all
vedge(config-tunnel-interface)# no shutdown
vedge(config-tunnel-interface)# exit
vedge(config-interface-ge0/0)# exit
vedge(config-vpn-0)# exit
vedge(config)# commit
Commit complete.
The VPN0 configuration is similar to the one on the vManage controller. One difference is that
we have to specify the encapsulation type (GRE or IPSec) with the encapsulation command.
With the above configuration, the vBond orchestrator should be able to reach the vManage
controller. Open the vManage GUI and go to Configuration > Devices > Controllers > Add
controller > Add vBond:
Enter the IP address, username, and password. Keep the “Generate CSR” checkbox marked:
Click on Add. The vManage controller will now add the vBond orchestrator.
Certificate
The vBond orchestrator has been added in vManage and the CSR is created. We still have to do
some “certificate work”:
• Import the root CA certificate on the vBond orchestrator.

• Sign a certificate using the vBond CSR through the vManage shell.
• Import the certificate on the vBond orchestrator.
Let’s do it.
We can download the root certificate from the vManage controller using the request command.
Here’s what it looks like:
vBond1# request download scp://admin@10.1.0.1:/home/admin/ROOT-CA.pem

/usr/bin/download: line 33: /proc/sys/kernel/hung_task_timeout_secs:
Permission denied
The authenticity of host '10.1.0.1 (10.1.0.1)' can't be established.
ECDSA key fingerprint is SHA256:tDhYof1C8igzPm29fFlV5afe44qjJZAEDCNv9qQ2gPE.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.1.0.1' (ECDSA) to the list of known hosts.
viptela 19.3.0
admin@10.1.0.1's password:
ROOT-CA.pem 100% 1257 41.1KB/s 00:00
Permission denied
It throws an error but it does work. With another request command we can install the root CA
certificate:
vBond1# request root-cert-chain install /home/admin/ROOT-CA.pem

Uploading root-ca-cert-chain via VPN 0
Copying ... /home/admin/ROOT-CA.pem via VPN 0
Updating the root certificate chain..
Successfully installed the root certificate chain
Our vBond orchestrator now trusts the certificates that our root CA signs.
When we added the vBond orchestrator a CSR was generated. This is stored in the home folder.
You can see it here:
vBond1# vshell
vBond1:~$ ls -lh
total 40K
-rw-r--r-- 1 admin admin 24K Jul 8 14:44 master_root.crt
-rw-r--r-- 1 admin admin 43 Jul 8 14:44 root_ca_uuid_list
-rw-r--r-- 1 root root 1.2K Jul 8 14:45 vbond_csr
We need this CSR on the vManage controller so we can sign it there. You could use cat and
copy/paste it but copying is easier. From vshell, use the scp command like this:
vManage1# vshell
vManage1:~$ scp admin@10.1.0.2:/home/admin/vbond_csr .
ECDSA key fingerprint is SHA256:w5eOq3Q6ZVdXvnTLq9k3lO8aU2x2uUu6bJIhuGsfngo.
viptela 19.3.0
vbond_csr 100% 1220 40.5KB/s 00:00
Let’s sign a certificate using the CSR as input:
vManage1:~$ openssl x509 -req -in vbond_csr \

> -out vbond.crt -days 1826 -sha256
Signature ok
LLC/CN=vbond-a27e7e90-b266-448f-80be-942ee9a767b8-
Use cat to see the certificate and copy the output:
vManage1:~$ cat vbond.crt

MIIDlzCCAn8CCQCSxilWaQdcEzANBgkqhkiG9w0BAQsFADBQMQswCQYDVQQGEwJO
E3ZtYW5hZ2UxLmxhYi5ud2wuYWkwHhcNMjEwNzA4MTQ1MjEzWhcNMjYwNzA4MTQ1
MjEzWjCByjELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNV
aXB0ZWxhIExMQzFBMD8GA1UEAxM4dmJvbmQtYTI3ZTdlOTAtYjI2Ni00NDhmLTgw
YmUtOTQyZWU5YTc2N2I4LTAudmlwdGVsYS5jb20xIjAgBgkqhkiG9w0BCQEWE3N1
cHBvcnRAdmlwdGVsYS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQChgD9FPhIbvsuDWF+YhTYayWYTA0mE/LHW1qizIebIXrTuBox6XLzrxYP0OwuK
U+bEfkbs3QAEPbzUzA51Pzjx0FpZfd0tP9byjGziyeq3fO0ol9NO6uMQ6RQPwzHS
SxAD96Qg2RwZpqA080H44XW0tGZEJVD/+5XK3LZeIYl6iWu5/i1z6kQ4iOdw4DfQ
0p2HolH0JdhNx+zCUK8zmBEhh/opmt1ZtcKBa2sCN2wPxiUkIUNdw0GMXbBBNXc9
RuwSkwAj6UWnG6omdwwNMVQthghT+QmHZjH5priQpkm9d9/gmIDGEdImqGXongLn
LfTJlXS881AeY/6mf8els2HpAgMBAAEwDQYJKoZIhvcNAQELBQADggEBAE2Jiuvt
D9uIbi79DLCBUKDjq3CAtlPiigj16lYEdH9d6AH+1L02cE83dzhoVsFRZCBuPLbt
7kmMNgEXeXACRCgMTMz7W8G2lv0PsgRs+1xRgJzna1FObubgd7p6DOT6/BI7CrmB
ArIaaIBh4BBtC00m0bZZIEvL6VIDL/GoaC5xIod/o79yGGQaUrlBkRJqvUVTvr9q
JAm/eUiO2WC8eZfxTJI69FySMs4gDpX1ChJDsdIjqcOpResTFGwcOuaJ0ms/oORE
tLDonZUmGNm0UyplISwrh0tRB92hTH9jHr/gxlcADMjIgieMJhZEPf/EOZD4hSAX
BQoSPe5vc8dbzfM=
Go back to vManage and click on the Install Certificate button:

Paste the vBond certificate here:
Click on Install and wait a few seconds.
Verification
The vBond and vManage controllers are now connected. You can verify this through the GUI or
the CLI.
Using the GUI, go to Monitor > Network > WAN – Edge and click on vBond1. You’ll see this
screen:
In the output above, we see the connection between the two controllers. You can also verify this
from the CLI with the show control connections command on the vManage controller:
vManage1# show control connections

PEER
PEER PEER
PEER PEER PEER CONFIGURED SITE DOMAIN PEER
PRIV PEER PUB
INDEX TYPE PROT SYSTEM IP SYSTEM IP ID ID PRIVATE
IP PORT PUBLIC IP
PORT ORGANIZATION REMOTE COLOR STATE UPTIME
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
----------------------------------------------------------------
0 vbond dtls 172.16.1.102 172.16.1.102 0 0 10.1.0.2
12346 10.1.0.2 12346 nwl-sdwan-lab
default up 0:00:00:22
1 vbond dtls 0.0.0.0 - 0 0 10.1.0.2
12346 10.1.0.2 12346 nwl-sdwan-lab
2 vbond dtls 0.0.0.0 - 0 0 10.1.0.2
12346 10.1.0.2 12346 nwl-sdwan-lab
3 vbond dtls 0.0.0.0 - 0 0 10.1.0.2
12346 10.1.0.2 12346 nwl-sdwan-lab
Or you can use the show orchestrator connections command on the vBond orchestrator:
vBond1# show orchestrator connections
PEER PEER
PEER PEER PEER SITE DOMAIN PEER
PRIVATE PEER PUBLIC
ORGANIZATION
INSTANCE TYPE PROTOCOL SYSTEM IP ID ID PRIVATE
IP PORT PUBLIC IP PORT REMOTE COLOR STATE
NAME UPTIME
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
-------------------------------------
0 vmanage dtls 172.16.1.101 1 0 10.1.0.1
12346 10.1.0.1 12346 default up nwl-sdwan-
lab 0:00:06:38
0 vmanage dtls 172.16.1.101 1 0 10.1.0.1
lab 0:00:06:38
0 vmanage dtls 172.16.1.101 1 0 10.1.0.1
lab 0:00:06:57
0 vmanage dtls 172.16.1.101 1 0 10.1.0.1
lab 0:00:06:57
This completes the vBond configuration. Two down, one to go…
vSmart
The vSmart controller authenticates vEdge routers and pushes policies to vEdge routers. We take
the same steps as we did on the vBond orchestrator.
Let’s log in:
viptela 19.3.0
vsmart login: admin

Password:
admin connected from 127.0.0.1 using console on vsmart
Password:
Re-enter password:
vsmart#
We’ll start with a system configuration:
vsmart(config)# system
vsmart(config-system)# host-name vSmart1
vsmart(config-system)# system-ip 172.16.1.103
vsmart(config-system)# site-id 1
vsmart(config-system)# organization-name nwl-lab-sdwan
vsmart(config-system)# vbond 10.1.0.2
vsmart(config-system)# exit
The configuration above is similar to what we did with the vManage controller. Let’s configure
the VPN0 interface:
vsmart(config)# vpn 0
vsmart(config-vpn-0)# ip route 0.0.0.0/0 10.1.0.254
vsmart(config-vpn-0)# interface eth0
vsmart(config-interface-eth0)# ip address 10.1.0.3/24
vsmart(config-interface-eth0)# tunnel-interface
vsmart(config-tunnel-interface)# allow-service all
vsmart(config-tunnel-interface)# no shutdown
Commit everything and we are good to go:
vsmart(config-vpn-0)# commit
Commit complete.
Open the vManage GUI and go to Configuration > Devices > Controllers > Add Controller >
vSmart:
Type in the IP address, username, and password of the vSmart controller:

Leave the “Generate CSR” checkbox marked and click on Add.
Certificate
Let’s fix our certificates. First, we copy the root CA certificate from the vManage controller:
vSmart1# request download scp://admin@10.1.0.1:/home/admin/ROOT-CA.pem

Permission denied
ECDSA key fingerprint is SHA256:tDhYof1C8igzPm29fFlV5afe44qjJZAEDCNv9qQ2gPE.
viptela 19.3.0
ROOT-CA.pem 100% 1257 29.3KB/s 00:00
Permission denied
Then we install the root CA certificate:
vSmart1# request root-cert-chain install /home/admin/ROOT-CA.pem

Let’s sign a certificate for the vSmart controller. The CSR is in the home folder:
vSmart1# vshell
vSmart1:~$ ls -lh
total 36K
-rw-r--r-- 1 admin admin 24K Jul 8 15:20 master_root.crt
-rw-r--r-- 1 root root 1.2K Jul 8 15:20 vsmart_csr
Let’s use scp to copy the CSR to the vManage controller:
vManage1# vshell
vManage1:~$ scp admin@10.1.0.3:/home/admin/vsmart_csr .
ECDSA key fingerprint is SHA256:gv8oQ54VKEW4Kvivxf2btphPiRidY1kF+LncAJO3Ioc.
viptela 19.3.0
vsmart_csr 100% 1220 208.8KB/s 00:00
And sign a certificate:
vManage1:~$ openssl x509 -req -in vsmart_csr \

> -out vsmart1.crt -days 1826 -sha256
Signature ok
LLC/CN=vsmart-efe48082-e7f3-435d-8f96-d56f289e10be-
Use cat to see the contents of the certificate:
vManage1:~$ cat vsmart1.crt

MIIDmDCCAoACCQCSxilWaQdcFTANBgkqhkiG9w0BAQsFADBQMQswCQYDVQQGEwJO
E3ZtYW5hZ2UxLmxhYi5ud2wuYWkwHhcNMjEwNzA4MTUyNzI4WhcNMjYwNzA4MTUy
NzI4WjCByzELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNV
aXB0ZWxhIExMQzFCMEAGA1UEAxM5dnNtYXJ0LWVmZTQ4MDgyLWU3ZjMtNDM1ZC04
Zjk2LWQ1NmYyODllMTBiZS0wLnZpcHRlbGEuY29tMSIwIAYJKoZIhvcNAQkBFhNz
dXBwb3J0QHZpcHRlbGEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAx9QIKTy4rw2s5jDVD2HsjuB0yGbtX7sV2QUJNJijqZ+BlPBQPApFD8htYRYA
ykxnC3r2otBoxozQlekpz+vKxPnVC+FWt3e6FWqqLqlcyWxOEF5fRvzXZGqARXl5
SEfGQweiiBK0OHkMsDvLgBemNV8uU0ky/i0DZGHM2j15xdXLL7qHyloI3ASi8t0z
ydgm3MCYH/ZKU0kAo9oA8b60bgxgPRGQIMjoTfIx83pt1CUh98q5VV02eIMScZut
swMgTnWgpKg3NdBauxJcGkCyShYXr5ylHtu9kV4KYzkeohr9w9pns3EL6HjGoslg
PCASmr9bIOwciGz7Xnq9YaeP/QIDAQABMA0GCSqGSIb3DQEBCwUAA4IBAQCxWym3
+84ac7CHSN0ePhxnlSjF/bI/5RA0afxdnKMbBDYE9blZwmd89S+P3bNBzSJ1O1M+
y5bUKK3xDAoCpUuq+hYr9iDsaiNste7l1bnNkoaon/yp/I8ZyQ20PFbojGJB6Vch
zB1qSjRl4dxoZNhX2egV6tgZxjVqurnsxIe8yeK9oVjAZOuRA2ShEJUJM04gFDrZ
dFK0+sw+M7BDKCWDu1OSQLZQQJzmQzjjacI4TVQcUeGlTV3eCmcfBSSTieKterQM
O35dWiKAX/dDrVo7thc7NkKB2wcB/8+XSbIS1Pxzm0H0tqk1dyjMZ0p38Vp9VAHc
Vxl4KNmpfJuSlgsm
Go back to the vManage GUI and click on Install Certificate:
Paste the contents of the vsmart1.crt file:

and click on Install. This will take a few seconds.
Verification
Let’s verify our work. In the vManage GUI, go to Monitor > Network > WAN – Edge and
click on vSmart1. You’ll see this screen:
Above, you see the connection with the vSmart controller. You can also verify this from the CLI:
vManage1# show control connections

PEER
PEER PEER
PEER PEER PEER CONFIGURED SITE DOMAIN PEER
PRIV PEER PUB
INDEX TYPE PROT SYSTEM IP SYSTEM IP ID ID PRIVATE
IP PORT PUBLIC IP
PORT ORGANIZATION REMOTE COLOR STATE UPTIME
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
----------------------------------------------------------------
0 vsmart dtls 172.16.1.103 172.16.1.103 1 1 10.1.0.3
12346 10.1.0.3 12346 nwl-sdwan-lab
0 vbond dtls 172.16.1.102 172.16.1.102 0 0 10.1.0.2
12346 10.1.0.2 12346 nwl-sdwan-lab
1 vbond dtls 0.0.0.0 - 0 0 10.1.0.2
12346 10.1.0.2 12346 nwl-sdwan-lab
2 vbond dtls 0.0.0.0 - 0 0 10.1.0.2
12346 10.1.0.2 12346 nwl-sdwan-lab
3 vbond dtls 0.0.0.0 - 0 0 10.1.0.2
12346 10.1.0.2 12346 nwl-sdwan-lab
Or on the CLI of the vBond orchestrator:
vBond1# show orchestrator connections
PEER PEER
PRIVATE PEER PUBLIC
ORGANIZATION
INSTANCE TYPE PROTOCOL SYSTEM IP ID ID PRIVATE
IP PORT PUBLIC IP PORT REMOTE COLOR STATE
NAME UPTIME
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
-------------------------------------
0 vsmart dtls 172.16.1.103 1 1 10.1.0.3
lab 0:00:16:15
0 vsmart dtls 172.16.1.103 1 1 10.1.0.3
lab 0:00:16:15
0 vmanage dtls 172.16.1.101 1 0 10.1.0.1
lab 0:00:11:30
0 vmanage dtls 172.16.1.101 1 0 10.1.0.1
lab 0:00:11:30
0 vmanage dtls 172.16.1.101 1 0 10.1.0.1
lab 0:00:11:35
0 vmanage dtls 172.16.1.101 1 0 10.1.0.1
lab 0:00:11:33
This completes our configuration.
system
host-name vManage1
system-ip 172.16.1.101
site-id 1
organization-name nwl-sdwan-lab
vbond 10.1.0.2
!
vpn 0
interface eth0
ip address 10.1.0.1/24
tunnel-interface
allow-service all
!
no shutdown
!
ip route 0.0.0.0/0 10.1.0.254
system
host-name vBond1
system-ip 172.16.1.102
site-id 1
vbond 10.1.0.2 local
!
vpn 0
interface ge0/0
tunnel-interface
encapsulation ipsec
allow-service all
!
no shutdown
!
ip route 0.0.0.0/0 10.1.0.254
system
host-name vSmart1
system-ip 172.16.1.103
site-id 1
vbond 10.1.0.2
!
vpn 0
interface eth0
tunnel-interface
allow-service all
!
no shutdown
!
ip route 0.0.0.0/0 10.1.0.254
hostname DC1
!
ip cef
!
interface GigabitEthernet0/0
switchport access vlan 10
switchport mode access
!
!
!
no switchport
ip address 10.65.91.100 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 10.65.91.254
!
end
Conclusion
We did some important work. Our controllers are now up and running. If you go to
Configuration > Devices you’ll see the following overview:
We see that all controllers have a certificate and they are in sync. The mode is “CLI”. This is
because we did the original configuration through the CLI. This is something we’ll change in
another lesson when we look at our templates.
You have now learned how to:
• Create a basic system and VPN0 configuration for the vManage, vBond, and vSmart
controllers.
• Create a root CA so you can create your own certificates.
• Sign certificates for each controller and import them into vManage.
• Verify the controller connections.
Cisco SD-WAN Plug and Play Connect
Device Licenses
If you want to add vEdge or cEdge licenses to your Cisco SD-WAN network, you’ll need some
device “licenses”. In Cisco SD-WAN versions before 20.x, it was possible to skip this as I did in
the vEdge onboarding lesson. In version 20.x and later, you need to create these licenses on the
Cisco.com website and import them on your vManage controller.
In this lesson, I’ll show you how to generate these device licenses and download the license file.
Head over to https://software.cisco.com if you want to follow along.
Virtual Account
If you want to separate your lab licenses from your other licenses, you should create a virtual
account. Let me show you how to do this. Under Download and manage, and Manage Smart
Account, click on Manage account:
Click on Virtual Accounts:

Click on Create Virtual Account:
Add a name, set the access level to “private“, and click on Next:
We don’t have to add extra users so click on Next:
Click on Create Virtual Account:

Our new virtual account now shows up in the overview:
You now have a virtual account that you can use for your lab licenses.
Controller
We need to add our vBond controller that the device licenses will belong to. Head back to Cisco
Software Central and under Smart Licensing, look for Network Plug and Play, and click on
Manage devices:
On the top right, select the virtual account we just created:
Go to Controller Profiles and click on Add Profile:

Select Controller Type VBOND and click on Next:
Under settings, add a Profile Name, the Organization Name that you use in your lab, and the
IPv4 address of your vBond orchestrator:
Review the configuration and click on Submit:
Click on Done:
We now see the Controller Type in the overview:

vEdge and cEdge licenses
Time to create some device licenses. Under Devices, click on Add Software Devices:
Click on Add Software Device:
We’ll start with the vEdge devices. Enter VEDGE-CLOUD-DNA as the Base PID. I want 10
device licenses and the Controller Profile is the one we just created. Click on Save to continue:
You should be able to create 25 device licenses in total.
While we are at it, let’s add some licenses for the CSR1000V router as well. This can be useful if
you want to test the cEdge routers. Click on Add Software Device one more time to add licenses
for the CSR1000V router:
In the overview, you’ll see the device licenses that we want to create:
Click on Submit:
And you will see a message that a request has been recorded. Click on Done:
A short while later, you should receive an email that looks like this:
And the devices should show up as Provisioned in the overview:
Serial File
We can now download the file with the licenses. Go to Controller Profiles and click on
Provisioning File:
Select Controller Versions “18.3 and newer” and click on Download:

This downloads the serialFile.viptela file to your computer.
You can now add this file to the vManage controller and onboard a vEdge (or cEdge) router.
This is explained in the vEdge onboarding lesson.
Conclusion
You have now learned how to create device licenses for your vEdge or cEdge routers.
Cisco SD-WAN vEdge Onboarding
In the previous lesson, we configured site 1 with the vManage, vBond, and vSmart controllers.
This means we are now ready to onboard vEdge routers. That’s what we are going to do in this
lesson.
Configuration
Let me explain what we have:
• On the left side, we have site 1 with the controllers we configured previously.
• On the right side, we have site 2 with two vEdge routers.
• These routers are connected to the “biz-internet” and “public-internet” clouds:
o I use these clouds to simulate two ISPs.
o In reality, these are two VLANs on my local network with Internet access.
We are going to use the “biz-internet” connection to onboard the vEdge1 router with the
controllers. We will prepare the configuration of the “public-internet” connection so that we can
use it in later lessons.
I’ll also only explain how to onboard the vEdge1 router. If you can onboard one router, you
can onboard as many as you like. If you want to follow along with me, see if you can onboard
the vEdge2 router. Later, we’ll build upon this topology and add even more devices to create a
larger SD-WAN network.
This is what we have to do:
• Create a basic configuration:

o System settings
o VPN0 (Overlay network)
• Certificates
o Install the root CA certificate on the vEdge router
o Create a CSR and sign a certificate for the vEdge router
I’m using Cisco SD-WAN images version 19.3.0.
Let’s get started and open the console of the vEdge1 router:
viptela 19.3.0
vedge login: admin

Password:
admin connected from 127.0.0.1 using console on vedge
Password:
Re-enter password:
The first time you log in, you have to set a password. I’m using “admin” everywhere in my lab.
Basic Configuration
Before the vEdge router can join the controllers, we have to create a basic configuration. This is
similar to what we configured on the controllers.
System
Let’s start with the system configuration:
vedge(config)# system
vedge(config-system)# host-name vEdge1
vedge(config-system)# system-ip 172.16.1.1
vedge(config-system)# site-id 2
vedge(config-system)# organization-name nwl-lab-sdwan
vedge(config-system)# vbond 10.1.0.2
vedge(config-system)# exit
VPN0 (Overlay Network)
The VPN0 configuration is slightly different. The main reason is that we have two physical
interfaces to configure:
• Ge0/0 connects to the “biz-internet” cloud.

• Ge0/1 connects to the “public-internet” cloud.
Let’s take a look:

vedge(config)# vpn 0
vedge(config-vpn-0)# ip route 10.1.0.0/24 10.65.91.100
vedge(config-interface-ge0/0)# encapsulation ipsec
The first part is the same as what we have seen before. There is a new command that we have to
add under the tunnel-interface though:
vedge(config-tunnel-interface)# color ?
Description: Set color for TLOC
Possible completions:
<3g biz-internet blue bronze custom1 custom2 custom3 default gold gre en
lte metro-ethernet mpls public-internet red silver private1 private2 pri
vate3 private4 private5 private6>[default]
The color command sets the “color” for the TLOC. This is required to differentiate the two
WAN connections.
The word “color” and the options like “bronze”, “silver”, or “gold” might imply that this has something
to do with QoS (Quality of Service). Color however is nothing more but something to differentiate the
two WAN connections. It doesn’t have anything to do with QoS.
The ge0/0 interface connects to my “biz-internet” ISP so let’s set the color:
vedge(config-tunnel-interface)# color biz-internet

We configure the ge0/1 interface the same way:

vedge(config-tunnel-interface)# encapsulation ipsec
vedge(config-tunnel-interface)# color public-internet
The only difference is that the ge0/1 interface is connected to the “public-internet” ISP. Let’s
commit our configuration:
vedge(config-vpn-0)# commit
Commit complete.
Excellent. This is all we need for now.

Certificates
We need to do a couple of things to get our certificates in order:
• Install the root CA certificate on the vEdge router.

• Generate a CSR on the vEdge router.
• Sign the certificate on the vManage controller.
• Install the vEdge certificate on the vEdge router.
This process is almost the same as what we did with the controllers except for the CSR. Let me
show you.
Install Root CA Certificate
We’ll start with the root CA certificate. First, we download it from the vManage controller to our
vEdge router:
vEdge1# request download scp://admin@10.1.0.1:/home/admin/ROOT-CA.pem

Permission denied
viptela 19.3.0
vEdge1# admin@10.1.0.1's password:

ROOT-CA.pem 100% 1257 22.9KB/s 00:00
Permission denied
I’m not sure why it shows these errors. The file is copied anyway. Let’s install it:
vEdge1# request root-cert-chain install /home/admin/ROOT-CA.pem

That takes care of the root CA certificate.
vEdge Certificate
Time for our vEdge certificate. We create a CSR on the vEdge router:
vEdge1# request csr upload home/admin/vedge1_csr

Uploading CSR via VPN 0
Enter organization-unit name : nwl-lab-sdwan
Re-enter organization-unit name : nwl-lab-sdwan
Generating CSR for this vedge device ........[DONE]
Copying ... /home/admin/vedge1_csr via VPN 0
CSR upload successful
In the output above, you can see the vedge1_csr file is stored in the /home/admin folder. We
need to copy this file to the vManage controller:
vManage1# vshell
vManage1:~$ scp admin@10.65.91.1:/home/admin/vedge1_csr .
viptela 19.3.0
vedge1_csr 100% 1220 9.9KB/s 00:00
And we sign the certificate using the CSR:
vManage1:~$ openssl x509 -req -in vedge1_csr \

-CA ROOT-CA.pem -CAkey ROOT-CA.key -CAcreateserial \
-out vedge1.crt -days 2000 -sha256
Signature ok
subject=/C=US/ST=California/L=San Jose/OU=nwl-lab-sdwan/O=Viptela
LLC/CN=vedge-82ac8968-dd99-4ee7-a14c-d1c39dc49d56-
Let’s copy the vedge1.crt certificate file to the vEdge router:
vEdge1# request download scp://admin@10.1.0.1:/home/admin/vedge1.crt

Permission denied
viptela 19.3.0
vedge1.crt 100% 1306 27.9KB/s 00:00
Permission denied
And install the certificate:
vEdge1# request certificate install home/admin/vedge1.crt

Installing certificate via VPN 0
Copying ... /home/admin/vedge1.crt via VPN 0
Successfully installed the certificate
We are almost finished now.
Add vEdge router to vManage
We can now add the vEdge router to the vManage controller. There are two different ways to do
this. I’ll show you how to do this for Cisco SD-WAN versions below and higher than 20.x.
Before 20.x
The vEdge certificate is on the vEdge router but we need to import some of its details into the
vManage and vBond controllers. We need to grab the chassis number and serial number:
vEdge1# show certificate serial
Chassis number: 82ac8968-dd99-4ee7-a14c-d1c39dc49d56 serial number:
85B3AB796BC025AE
Copy these two values and paste them into the following command which we apply on the
vManage and vBond controllers:
vManage1# request vedge add chassis-num 82ac8968-dd99-4ee7-a14c-d1c39dc49d56

serial-num 85B3AB796BC025AE
vBond1# request vedge add chassis-num 82ac8968-dd99-4ee7-a14c-d1c39dc49d56
serial-num 85B3AB796BC025AE
You won’t see any output when you paste this command. Open the vManage GUI and log in:
Open Configuration > Certificates > WAN Edge List and click on Send to Controllers:
This pushes the list with serial numbers of our vEdge router(s) to the controllers. You can
see the progress below:
This only takes a few seconds. When it’s ready you’ll see “Success” under the Status column:
That’s all that we have to configure.
After 20.x
You can’t just add a vEdge router with the request vedge add command anymore. You need
to create device “licenses” on cisco.com and add a WAN edge list to the vManage controller.
To create the licenses, check out the Cisco SD-WAN Plug and Play Connect Device Licenses
lesson. Once you have done that, you can continue here.
WAN Edge List

We need to upload the “serialFile.viptela” file to the vManage controller. Go to Configuration >
Devices > WAN Edge List and click on Upload WAN Edge List:
Select the serialFile.viptela file. Make sure you check the “Validate the uploaded vEdge List and send to
controllers” checkbox and click on Upload:
You should see a message that the file is uploaded successfully. Click on OK:
Instead of uploading the WAN Edge List manually, you can also use the Sync Smart Account button to
automatically synchronize your licenses. I prefer doing this manually so you don’t have to enter your
Cisco.com credentials in a lab environment. Another reason is that your vManage lab controller might
not have Internet access.
You should now see a nice WAN Edge List with 10 vEdge Cloud licenses and 10 CSR1000v
licenses:
Go to Configuration > Certificates and make sure the licenses show up as Valid:
If you forgot to synchronize the WAN edge list with the controllers when you uploaded the file,
you can click on the Send to Controllers button here. The vBond orchestrator now has a list of
licenses that we can use. You can see it here:
vBond1# show orchestrator valid-vedges

orchestrator valid-vedges 4B1E43D6-F646-4989-498D-2AB4724BDC65
serial-number 285bd972314140a5ac048c6ade3ee135
validity valid
org nwl-sdwan-lab
hardware-installed-serial-number N/A
subject-serial-number 4B1E43D6-F6
orchestrator valid-vedges 546DA5D4-71A9-CAB8-4BAF-96AADCCBA458
serial-number 45c316dde0424e9c9778a5504da9a94d
validity valid
org nwl-sdwan-lab
subject-serial-number 546DA5D4-71
orchestrator valid-vedges 69BD2940-F953-6614-D3A2-F5F146902C0E
serial-number bbf65eba85e54d04b0b6a62dbda8a26c
validity valid
org nwl-sdwan-lab
subject-serial-number 69BD2940-F9
orchestrator valid-vedges 730C90FD-800D-0CE8-1F6D-0EF52934CAF3
serial-number b4dec2bfeb0246908516648d22c8a4fc
validity valid
org nwl-sdwan-lab
subject-serial-number 730C90FD-80
orchestrator valid-vedges 8B3D8D4C-E48A-D724-6733-9AC0657C7F18
serial-number 8d6c6338c2d34cc5940f17484f0afbe0
validity valid
org nwl-sdwan-lab
subject-serial-number 8B3D8D4C-E4
orchestrator valid-vedges 94FCDD51-DD15-8B03-9E9C-4422EA69F7F4
serial-number 4c16caf1ff8247289f55b14b24f09aa8
validity valid
org nwl-sdwan-lab
subject-serial-number 94FCDD51-DD
orchestrator valid-vedges AA4B0952-DD3D-29FA-CF9F-3034022D064F
serial-number fe67daaeb9fb449e9c625dbb8daefa04
validity valid
org nwl-sdwan-lab
subject-serial-number AA4B0952-DD
orchestrator valid-vedges B89C1FB2-1D50-2F5C-EDED-732E2EFF3C7F
serial-number 93c2e94ef6c3493bbe4bf74b1827d6c0
validity valid
org nwl-sdwan-lab
subject-serial-number B89C1FB2-1D
orchestrator valid-vedges CSR-27BF83A4-F364-8B7C-6631-2553ACC244C6
serial-number 53a05fb7dd2d4b738524675748878cf6
validity valid
org nwl-sdwan-lab
subject-serial-number CSR-27BF83A
orchestrator valid-vedges CSR-33F16298-9364-B213-737A-639E86B02791
serial-number 309e1e5299fd4290a975114f43e3aa53
validity valid
org nwl-sdwan-lab
subject-serial-number CSR-33F1629
orchestrator valid-vedges CSR-37993F0B-809D-3145-2285-0FD30C3D19CB
serial-number b8159222479c4af484b20f95d0f99f43
validity valid
org nwl-sdwan-lab
subject-serial-number CSR-37993F0
orchestrator valid-vedges CSR-8A734928-5B41-974D-3FD4-23769203C025
serial-number 299c42f5731d420c8d9912d0f696e79f
validity valid
org nwl-sdwan-lab
subject-serial-number CSR-8A73492
orchestrator valid-vedges CSR-B07F5740-223C-906C-5BB0-57ED913A6A80
serial-number e622cd8f2ed94dc4bbea1220ad1d604f
validity valid
org nwl-sdwan-lab
subject-serial-number CSR-B07F574
orchestrator valid-vedges CSR-C1594231-9D9F-9319-B1AB-85130ACD0D09
serial-number 661d9101e22b49c89f329ba2d1c34abc
validity valid
org nwl-sdwan-lab
subject-serial-number CSR-C159423
orchestrator valid-vedges CSR-D21CABFF-A2FE-277A-3CA6-1EE7571B6021
serial-number f1b2249cc8314ac681fe33eb27e4ddc5
validity valid
org nwl-sdwan-lab
subject-serial-number CSR-D21CABF
orchestrator valid-vedges CSR-D723444B-6DBD-90AD-9A99-531332124D33
serial-number faff736be7b94cf288017280227599b8
validity valid
org nwl-sdwan-lab
subject-serial-number CSR-D723444
orchestrator valid-vedges CSR-D936128A-F4F1-3522-117C-9C1E50DECA40
serial-number 6f171875e3ab4bdd8c602597784f12f5
validity valid
org nwl-sdwan-lab
subject-serial-number CSR-D936128
orchestrator valid-vedges CSR-E14F1A4E-D81A-C251-8AE3-1A392AC5443E
serial-number b3f0e8c598c14c2b8e37422ccc3e467e
validity valid
org nwl-sdwan-lab
subject-serial-number CSR-E14F1A4
orchestrator valid-vedges E57637BA-037A-C154-A1EC-2F63CA0A684E
serial-number 76877c8b694744948a2075955032e241
validity valid
org nwl-sdwan-lab
subject-serial-number E57637BA-03
orchestrator valid-vedges EC26AC90-3ECA-F022-E839-C3027B94387B
serial-number ebbedabd7839414d86faa6d5a135390d
validity valid
org nwl-sdwan-lab
subject-serial-number EC26AC90-3E
Now we can add a vEdge router. Go to Configuration > Devices > WAN Edge List. Copy the
Chassis Number and Serial No./Token for one of the vEdge licenses:
Go to your vEdge router and use the following command where you specify the two values:
vEdge1# request vedge-cloud activate chassis-num ec26ac90-3eca-f022-e839-

c3027b94387b token ebbedabd7839414d86faa6d5a135390d
After a short while, you should see the state change in the WAN Edge List overview:
That’s all there is to it.
Verification
To verify whether the vEdge router has been onboarded successfully, we can check the
connections:
vEdge1# show control connections
PEER PEER
CONTROLLER
PRIV PEER PUB
GROUP
TYPE PROT SYSTEM IP ID ID PRIVATE IP
PORT PUBLIC IP PORT LOCAL COLOR PROXY
STATE UPTIME ID
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
------------------------------
vsmart dtls 172.16.1.103 1 1 10.1.0.3
12446 10.1.0.3 12446 biz-internet No up
0:00:13:11 0
vbond dtls 0.0.0.0 0 0 10.1.0.2
12346 10.1.0.2 12346 biz-internet - up
0:00:13:11 0
vbond dtls 0.0.0.0 0 0 10.1.0.2
12346 10.1.0.2 12346 public-internet -
connect 0
vmanage dtls 172.16.1.101 1 0 10.1.0.1
12446 10.1.0.1 12446 biz-internet No up
0:00:13:11 0
The output above shows that we have a connection with all controllers.
In the output above, you can see that the state for the “public-internet” interface is “connect”. This is
because right now, we use the “biz-internet” connection to reach the controllers. Cisco SD-WAN will
attempt to reach the controller(s) using all WAN connections. This is something we’ll look into in
another lesson.
system
host-name vManage1
system-ip 172.16.1.101
site-id 1
vbond 10.1.0.2
!
vpn 0
interface eth0
tunnel-interface
allow-service all
!
no shutdown
!
ip route 0.0.0.0/0 10.1.0.254
system
host-name vBond1
system-ip 172.16.1.102
site-id 1
vbond 10.1.0.2 local
!
vpn 0
interface ge0/0
tunnel-interface
encapsulation ipsec
allow-service all
!
no shutdown
!
ip route 0.0.0.0/0 10.1.0.254
system
host-name vSmart1
system-ip 172.16.1.103
site-id 1
vbond 10.1.0.2
!
vpn 0
interface eth0
tunnel-interface
allow-service all
!
no shutdown
!
ip route 0.0.0.0/0 10.1.0.254
hostname DC1
!
ip cef
!
!
!
!
no switchport
ip address 10.65.91.100 255.255.255.0
!
no switchport
ip address 10.65.92.100 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 10.65.91.254
!
end
system
host-name vEdge1
system-ip 172.16.1.1
site-id 2
organization-name nwl-lab-sdwan
vbond 10.1.0.2
!
vpn 0
interface ge0/0
ip address 10.65.91.1/24
ipv6 dhcp-client
tunnel-interface
encapsulation ipsec
color biz-internet
allow-service all
!
no shutdown
!
interface ge0/1
ip address 10.65.92.1/24
tunnel-interface
encapsulation ipsec
color public-internet
allow-service all
!
no shutdown
!
ip route 10.1.0.0/24 10.65.91.100
Conclusion
You have now learned how to onboard a vEdge router with the controllers:
• We created a basic configuration with the system and VPN0 settings.

• We created and imported a certificate for the vEdge router.
• We verified the connections between the vEdge router and controllers.
Cisco SD-WAN Device and Feature
Templates
We used the CLI to configure all the devices in our Cisco SD-WAN controllers installation and
vEdge onboarding lessons. The CLI is a good way to configure something quickly. You
configure one device, and with a bit of copy/pasting, it’s easy to configure other devices. The
CLI, however, doesn’t scale. To configure a few devices it’s OK, but when you need to manage
dozens of devices, it takes too much time and is prone to errors.
A scalable alternate is templates. Everything that you can configure through the CLI, you
can also configure with templates. We create templates beforehand, and then you can apply
them to one or as many devices as you like. When you start with templates, there is a learning
curve, and it is time-consuming. However, once everything is set up, you will save time and
reduce the chance of configuration errors.
The controllers and vEdge routers which we configured are currently in CLI mode. We are
going to change this so that we can manage them with templates. When we create templates, we
have to convert the existing CLI configurations to templates. If you don’t do this, some
items in the configuration will be overwritten with default values.
Once the devices are managed through templates, you can’t configure them through the CLI
anymore. However, you can still use show commands.
In this lesson, I’ll show you how to create and attach templates to our vEdge routers.
CLI Mode
Go to Configuration > Devices and look at the WAN Edge List and Controllers tabs. You’ll
see that all devices are in CLI mode:
I’ll explain how to change the vEdge routers from CLI mode to vManage mode. When we finish
this lesson, you’ll have to manage them through templates from then on and you can’t make
any changes through the CLI anymore. But, of course, you can always detach templates from
a device and switch back to CLI mode.
Templates
There are two template types:
• Device template: For each device “type”, we create a device template. This is the template that
we attach to a device.
• Feature template: We create a feature template for each “feature” that you want to configure.
Some examples are the system configuration, VPN, VPN interface, OSPF, EIGRP, BGP, AAA, etc.
There is a “parent-child” relation between the device and feature templates. First, we create
feature templates and attach them to a device template. We then attach the device template
to a device, like a vEdge Cloud router.
Feature Templates
Let’s start with the feature templates. Below is the configuration of the vEdge routers which we
created in the vEdge onboarding lesson.
system
host-name vEdge1
site-id 2
vbond 10.1.0.2
!
vpn 0
interface ge0/0
ip address 10.65.91.1/24
ipv6 dhcp-client
tunnel-interface
encapsulation ipsec
color biz-internet
allow-service all
!
no shutdown
!
interface ge0/1
ip address 10.65.92.1/24
tunnel-interface
encapsulation ipsec
allow-service all
!
no shutdown
!
ip route 10.1.0.0/24 10.65.91.100
We’ll convert the above configuration into multiple feature templates. Open Configuration >
Templates > Feature and click on Add Template.
On the left side, choose the device type. I’m using vEdge Cloud:
On the right side, choose System:
System
We can configure almost all the parameters that you find in the “system” part of the vEdge router
configuration in the next screen. But, first, we give the template a name:
Below, there is a bunch of items we can configure, divided into four main sections:
• Basic Configuration
• GPS
• Tracker
• Advanced
Let’s take a look at the Basic Configuration Section:

Above, you see some familiar items like the Site ID and System IP. For each item we want to
configure, we have three options:
• Device Specific: (the icon with the radio)

• Default: (the blue checkmark)
• Global: (the green globe)
Let me explain these options.
Device Specific
We can use a feature template for multiple devices but some configuration items are specific to
the device. For example:
• We want to use site ID 2 on two vEdge routers and site ID 3 on another vEdge router.
• The system IP is unique on every device.
We can do this with the device-specific option, which uses variables:
In the screenshot above, you see these two items:
• [system_site_id]
• [system_system_ip]
These two are variables but are called “keys” in the template. Later, when we apply the
template, you’ll see that we have to manually fill these fields. If you want, you can change the
variable name:
Default
The default setting has some fields filled with default values. For example, the overlay ID or
Timezone. Other fields are empty by default.
Global
The global values apply to all devices that you use this feature template for. One example is
the Console Baud Rate:
If I use a global value for the Console Baud Rate, all devices using this feature template will
have their baud rate set to 115200.
Let’s save this system feature template as it is. The default settings look good to me.
VPN0
Let’s configure the VPN0 interface. Create another feature template and select VPN:
There are not many items that we have to configure here. I set the template name to “template-
vedge-vpn0” and the default VPN is already set to 0:
I do need to add a static route. The default is global, which is fine because all my vEdge routes
need this static route:
Click on + Add Next Hop and then once more on Add Next Hop:
The next hop is also a global value. That’s fine by me because the next hop is also the same for
all my vEdge routers. Click on Add to continue. You’ll see this overview:
Click one Add one more time, and the static route shows up like this:
I don’t have to configure anything else here for VPN0. Click on Save to save this feature
template.
Interfaces
We created the VPN0 template, but we also need the feature templates for the ge0/0 and ge0/1
interfaces.
Ge0/0 Interface
Create another feature template and select VPN Interface Ethernet:

Let’s look at all the settings. First, we set a name and description:
Under the basic configuration, add these settings:
Most of the configuration items are the same for all my vEdge routers. However, the IPv4
address is device-specific. I’ll use the “vpn_if_ge_0_0_ipv4_address” key here. Here’s the
tunnel configuration:
I enable the tunnel-interface option and set the correct color (biz-internet). I also allow all
services. Click on Save to store the template.
Ge0/1 Interface
The Ge0/1 interface is almost the same as the Ge0/0 interface. So, instead of creating this feature
template from scratch, I’ll copy our Ge0/0 template. Click on the three dots next to the template
we just created:
And click on Copy:
Give the template a new name:
And click on the Copy button. Now click on the three dots next to the new template and click on
Edit. Under the basic configuration, I change these items:
We need to change the interface name to ge0/1, and I use another key for the IPv4 address. Then,
under the tunnel settings, I change the color to “public-internet”:
Click on Update to save the template.
VPN 512
We are almost ready. The only thing left is a template for VPN 512. I’m not using this
management VPN, but if you don’t create a feature template for it, you will get an error when
you attach the device template to one of your devices. Because there is no configuration for VPN
512, the deployment tries to remove the eth0 interface from the vEdge router, which is not
permitted. If you want to see this for yourself, feel free to skip this part so you can see the error
when you attempt to attach the device template.
Create another VPN feature template:
This is the only thing we configure:

Click on Save to store the template.
Eth0 Interface
Create another feature template. This time it’s for the eth0 interface:
This is the only thing we configure here:
Click Save and store the template.
Banner MOTD
Let’s do one more thing. Thus far I’ve only recreated the system configuration and the VPNs.
Let’s add something new, perhaps a MOTD banner. Create another template and select Banner:
This template is easy to configure. Let’s set a MOTD message:

Awesome. We now have a bunch of feature templates that we can attach to a device template. If
you look at the overview of feature templates, you can see whether they are used in any device
templates and if they are attached to any devices:
It’s time to create a device template.
Device Template
All right, it’s time to pull everything together. Go to Configuration > Templates > Device >
Create Template > From Feature Template.
There is also the “CLI Template” option. This lets you paste CLI commands and use that as the device
template. You can even replace things like an IP address with variables.
Set a name, then take a look at all the defaults:

All the highlighted items above are default feature templates. These are fine for things we
don’t use at the moment, like AAA or Security. However, we do want to use the feature
templates we created ourselves. Let’s select the system feature template we created:
Under Transport & Management VPN, add the VPN and VPN interface templates we created.
Make sure it looks like this:
You can click on the VPN Interface link on the right side to add the extra ge0/1 interface for
VPN0 and the eth0 interface for VPN 512.
Under Additional Templates, select the banner feature template:
Click on Create, and our device template is ready.
Attach Device Template
In the templates overview, click on the three dots next to the device template and choose Attach
Devices:
In the Attach Devices screen, I suggest starting with a single vEdge router. If you mess
something up, you don’t have to fix all your vEdge routers. Select vEdge1, so it shows up on the
right side:
The vBond controller uses the vEdge cloud image, which is why it shows up in this list.
Click on Attach. In the next screen, you have to enter the variables that we created in the
feature templates:
Click Next to continue. In the next screen, we can see the actual configuration that our device
template generates:
Click on the device you want to see (vEdge1 in my example). Then, under Config Preview, we
see the new configuration. You can also see the difference between this configuration and the
running configuration under Config Diff. Here’s an example:
• Lines in red are removed.

• Green lines are added.
• White lines (not showing here) remain the same.
I already had a MOTD banner when I did some testing that says “Hello to my vEdge!”My old
banner will be removed and replaced with the “Welcome to the vEdge router!” banner we
created in our feature template. Click on Configure Devices to continue. In the next screen, we
can see the progress of the deployment:
After a short while, it should show Success:
Excellent. We now have a vEdge router which we manage through vManage. If you go to
Configuration > Devices > WAN Edge List, you can see this:
The output above shows that vEdge1 is now managed by vManage and the assigned template is
“template-vedge”. This is how you create and attach templates.
Conclusion
You have now learned how to manage your devices with device and feature templates.
• The CLI doesn’t scale and is prone to errors.

• Templates are scalable and make it easier to manage many devices.
• Creating and managing templates takes time, but pays off in the long run.
• When you manage a device through templates, you can’t use any CLI configuration commands
anymore. Show commands will work.
• There are two template types:
o Device template: one for each device type. We attach this template to one or multiple
devices.
o Feature template: this is where you add configuration items (features). The feature
template attaches to the device template.
• Within a feature template, you have three options for values:
o Device-Specific: values that are specific to one device. We use variables here.
o Default: these are default values in the template. Some values are empty.
o Global: global values that apply to all devices.
• When you attach a device template to devices, you have to specify the variables.
• Use the config preview and config diff to see what configuration will be applied to your device.
Cisco SD-WAN vSmart CLI Template
In this lesson, I’ll explain how to convert the vSmart controller from CLI mode to vManage
mode using a CLI template. If your vSmart controller is not in vManage mode and you try to
activate a centralized policy like the ones I used for the hub and spoke topology or application-
aware routing, you will get an error.
If you haven’t seen centralized policies before, you can skip this lesson if you want to. I’ll add a
link from the centralized policy lesson to this lesson in case you need it. If you want to see what
a CLI template looks like, please continue.
Go to Configuration > Policies > Centralized Policy and try to Activate any of your policies:
You get the “vSmarts are not in vManage mode” error:
This happens because the vSmart controller is in CLI mode. It has to be in vManage mode.
Let’s fix this.
Configuration
Go to Configuration > Devices > Controllers, and you can see the current Mode:
We have two options:
• Create device and feature templates as we did in this lesson.

• Use a CLI template.
The best option is to create a device template with the required feature templates because this is a
scalable solution. However, in a lab, with only a single vSmart controller, the quickest way is to
use the CLI mode. I haven’t shown the CLI mode yet in any of our lessons, so this will be a good
exercise.
Click on Configuration > Templates > Create Template > CLI Template. Select vSmart as
the Device Model, give the template a name, and paste in the configuration of your vSmart
controller:
Click on Add to continue.
In the Template screen, select the device template, click on the three dots, and select Attach
Devices:
Select the vSmart controller and click on Attach:
The output of the Config Preview should look familiar:

Next, click on Configure Devices and wait until the template is pushed to the vSmart controller.
Verification
Go to Configuration > Devices > Controllers, and you’ll see that the vSmart controller is now
in vManage mode:
Go back to Configuration > Policies > Centralized Policy and try to activate one of your
policies again:
This time, you don’t get an error, and you can click on the Activate button.
Conclusion
You have now learned how to create a CLI template to move your vSmart controller from CLI
mode to vManage mode. This solves the “vSmarts are not in vManage mode” error.
Cisco SD-WAN Service VPN
We have installed Cisco SD-WAN controllers, onboarded vEdge routers, and learned how to use
templates.
It’s about time we send traffic between sites. That’s what we can do with a service VPN. We can
configure service VPNs from the CLI or with templates. I’ll show you both options in this
lesson.
Configuration
This is the topology we have:
I have two vEdge devices, each on its own site. Behind each vEdge router is a switch. I’ll use
these switches to ping from one site to another.
system
host-name vEdge2
site-id 2
vbond 10.1.0.2
!
vpn 0
interface ge0/0
ip address 10.65.91.2/24
ipv6 dhcp-client
tunnel-interface
encapsulation ipsec
color biz-internet
allow-service all
!
no shutdown
!
interface ge0/1
ip address 10.65.92.2/24
tunnel-interface
encapsulation ipsec
allow-service all
!
no shutdown
!
ip route 10.1.0.0/24 10.65.91.100
system
host-name vEdge3
site-id 3
vbond 10.1.0.2
!
vpn 0
interface ge0/0
ip address 10.65.91.3/24
ipv6 dhcp-client
tunnel-interface
encapsulation ipsec
color biz-internet
allow-service all
!
no shutdown
!
interface ge0/1
ip address 10.65.92.3/24
tunnel-interface
encapsulation ipsec
allow-service all
!
no shutdown
!
ip route 10.1.0.0/24 10.65.91.100
hostname SW2
!
no ip routing
!
no switchport
ip address 10.2.0.102 255.255.255.0
!
ip default-gateway 10.2.0.254
hostname SW3
!
no ip routing
!
no switchport
ip address 10.3.0.103 255.255.255.0
!
CLI
We’ll start with the CLI option.
Create a new VPN, assign the ge0/3 interface to it and configure an IP address:
vEdge2(config)# vpn 10
vEdge2(config-vpn-10)# interface ge0/3
vEdge2(config-interface-ge0/3)# ip address 10.2.0.254/24
vEdge2(config-interface-ge0/3)# no shutdown
vEdge2(config-interface-ge0/3)# commit
vEdge3(config)# vpn 10
vEdge3(config-vpn-10)# interface ge0/3
vEdge3(config-interface-ge0/3)# ip address 10.3.0.254/24
vEdge3(config-interface-ge0/3)# no shutdown
vEdge3(config-interface-ge0/3)# commit
That’s all you have to configure. There aren’t any commands that you haven’t seen before. You
can pick any VPN number except 0 or 512.
Templates
Now let’s see how we can configure a service VPN with templates.
Feature Templates
This takes some more work. Go to Configuration > Templates > Feature and click on Add
Template.
VPN10
In the next screen, select the VPN feature template:

There are two items we need to change here. Under Basic Configuration, set the VPN to 10:
Then, underAdvertise OMP, enable Connected (IPv4):
Click Save to store the template.
Ge0/3 Interface
We need another feature template for the interface that connects to the switch. Click on Add
Template and select VPN Interface Ethernet:
Here are the changes we need:

This is what I changed:
• Shutdown: No
• Interface Name: ge0/3
• IPv4 Address: we use the variable “vpn_if_ge_0_3_ipv4_address”
Save the template when you are ready.
Device Template
We can now attach a device template with these new feature templates to our vEdge routers. We
have two options:
• Add these feature templates to the device template I already created in the templates lesson.
• Copy my existing device templates and edit the new device template.
Both will get the job done, but we have to think about our template design for a minute. If I add
these feature templates to my existing device template, then every device that uses this device
template will have service VPN 10. It might be better to copy the device template and attach the
new device template only to devices that require service VPN 10. Let’s do that. Click on the
three dots next to the template and select Copy:
Give the template a name:
Edit this template and scroll down to the Service VPN section. Add the VPN and VPN Interface
feature templates here:
Click on Update. Now click on the three dots next to our new template and select Attach
Devices:
Select the vEdge2 and vEdge3 routers and click on Attach. In the next screen, you have to fill in
the variables:
Click on Next, and you can look at the configuration preview or difference:
Click on Configure Devices if everything looks OK to you. You’ll see a warning that this will
affect two devices:
Mark the checkbox and click on OK. The templates are now pushed to the vEdges:
This takes a short while. When it’s ready, you’ll see the status “Success”.
Verification
Whether you used the CLI or templates to configure the service VPN, verification is the same.
Let’s take a closer look. Here’s our configuration:
vEdge2# show run vpn 10

vpn 10
interface ge0/3
description VPN10-LAN
ip address 10.2.0.254/24
no shutdown
!
omp
advertise connected
When I configured the service VPN through the CLI, I didn’t specify the advertise connected
command under omp. This is a default setting. We did have to include this in our feature
template. This setting advertises the directly connected routes through OMP. We can see it here:
vEdge2# show ip route

Codes Proto-sub-type:
IA -> ospf-intra-area, IE -> ospf-inter-area,
E1 -> ospf-external1, E2 -> ospf-external2,
N1 -> ospf-nssa-external1, N2 -> ospf-nssa-external2,
e -> bgp-external, i -> bgp-internal
Codes Status flags:
F -> fib, S -> selected, I -> inactive,
B -> blackhole, R -> recursive
PROTOCOL NEXTHOP NEXTHOP

NEXTHOP
VPN PREFIX PROTOCOL SUB TYPE IF NAME ADDR
VPN TLOC IP COLOR ENCAP STATUS
-----------------------------------------------------------------------------
----------------------------------------------------------------
0 10.1.0.0/24 static - ge0/0
10.65.91.100 - - - - F,S
0 10.65.91.0/24 connected - ge0/0 -
- - - - F,S
0 10.65.92.0/24 connected - ge0/1 -
- - - - F,S
0 172.16.1.2/32 connected - vmanage_system-
- - - - F
0 172.16.1.2/32 connected - system -
- - - - F,S
10 10.2.0.0/24 connected - ge0/3 -
- - - - F,S
10 10.3.0.0/24 omp - - -
- 172.16.1.3 biz-internet ipsec F,S
In the output above, you can see that vEdge2 learned prefix 10.3.0.0/24 through OMP. We see a
similar output on the vEdge3 router:
vEdge3# show ip route

Codes Status flags:

NEXTHOP
-----------------------------------------------------------------------------
----------------------------------------------------------------
0 10.1.0.0/24 static - ge0/0
10.65.91.100 - - - - F,S
0 10.65.91.0/24 connected - ge0/0 -
- - - - F,S
0 10.65.92.0/24 connected - ge0/1 -
- - - - F,S
0 172.16.1.3/32 connected - vmanage_system-
- - - - F
0 172.16.1.3/32 connected - system -
- - - - F,S
10 10.2.0.0/24 omp - - -
- 172.16.1.2 biz-internet ipsec F,S
10 10.3.0.0/24 connected - ge0/3 -
- - - - F,S
vEdge3 learned 10.2.0.0/24 through OMP. We can also verify this from the vSmart controller:
vSmart1# show omp peers
R -> routes received
I -> routes installed
S -> routes sent
DOMAIN OVERLAY SITE

PEER TYPE ID ID ID STATE UPTIME
R/I/S
-----------------------------------------------------------------------------
-------------
172.16.1.1 vedge 1 1 2 up 8:22:08:04
0/0/0
172.16.1.2 vedge 1 1 2 up 8:21:50:25
1/0/1
172.16.1.3 vedge 1 1 3 up 8:21:55:53
1/0/1
172.16.1.4 vedge 1 1 4 up 1:05:24:48
0/0/0
Above, you see that both vEdge2 (172.16.1.2) and vEdge3 (172.16.1.3) have received and sent a
route. Another useful command is show ipsec. You can use this to look at inbound and
outbound IPSec connections:
vEdge2# show ipsec outbound-connections

SOURCE SOURCE DEST
DEST REMOTE REMOTE AUTHENTICATION
NEGOTIATED PEER PEER
IP PORT IP
PORT SPI TUNNEL MTU TLOC ADDRESS TLOC COLOR USED
KEY-HASH ENCRYPTION ALGORITHM TC SPIs KEY-HASH SPI
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
--------------------------------------------------------------------
10.65.91.2 12346 10.65.91.3
12366 275 1441 172.16.1.3 biz-internet AH_SHA1_HMAC
*****9d4f AES-GCM-256 8 NONE 0
10.65.91.2 12346 10.65.91.4
*****f131 AES-GCM-256 8 NONE 0
SOURCE SOURCE DEST
DEST REMOTE REMOTE AUTHENTICATION
NEGOTIATED PEER PEER
IP PORT IP
PORT SPI TUNNEL MTU TLOC ADDRESS TLOC COLOR USED
KEY-HASH ENCRYPTION ALGORITHM TC SPIs KEY-HASH SPI
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
--------------------------------------------------------------------
10.65.91.3 12366 10.65.91.1
*****cf48 AES-GCM-256 8 NONE 0
10.65.91.3 12366 10.65.91.2
*****c30a AES-GCM-256 8 NONE 0
10.65.91.3 12366 10.65.91.4
*****f131 AES-GCM-256 8 NONE 0
In the two outputs above, you can see that there is an IPSec connection between vEdge2 and
vEdge3. Last but not least, let’s try to ping from SW2 to SW3:
SW2#ping 10.3.0.103
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.3.0.103, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 44/64/71 ms
This is working, great!
system
host-name vEdge2
site-id 2
vbond 10.1.0.2
!
vpn 0
interface ge0/0
ip address 10.65.91.2/24
ipv6 dhcp-client
tunnel-interface
encapsulation ipsec
color biz-internet
allow-service all
!
no shutdown
!
interface ge0/1
ip address 10.65.92.2/24
tunnel-interface
encapsulation ipsec
allow-service all
!
no shutdown
!
ip route 10.1.0.0/24 10.65.91.100
!
vpn 10
interface ge0/3
ip address 10.2.0.254/24
no shutdown
!
omp
advertise connected
!
vpn 512
interface eth0
shutdown
system
host-name vEdge3
site-id 3
vbond 10.1.0.2
!
vpn 0
interface ge0/0
ip address 10.65.91.3/24
ipv6 dhcp-client
tunnel-interface
encapsulation ipsec
color biz-internet
allow-service all
!
no shutdown
!
interface ge0/1
ip address 10.65.92.3/24
tunnel-interface
encapsulation ipsec
allow-service all
!
no shutdown
!
ip route 10.1.0.0/24 10.65.91.100
!
vpn 10
interface ge0/3
ip address 10.3.0.254/24
no shutdown
!
omp
advertise connected
!
vpn 512
interface eth0
shutdown
hostname SW2
!
no ip routing
!
no switchport
ip address 10.2.0.102 255.255.255.0
!
hostname SW3
!
no ip routing
!
no switchport
ip address 10.3.0.103 255.255.255.0
!
Conclusion
You have now learned how to configure and verify a service VPN using the CLI or with
templates.
Cisco SD-WAN OSPF Configuration
Cisco SD-WAN uses OMP in the overlay network for routing information, but within a site, it’s
possible that you need OSPF (or BGP) to advertise routes with non-SD-WAN devices. In this
lesson, I’ll explain how to configure OSPF on a vEdge router.
Configuration
This is the topology:
The two switches and the vEdge router are within a single site. SW1 and SW2 are Cisco IOS
switches. I preconfigured these two with OSPF. Next, we’ll configure the vEdge1 router using
device and feature templates. I’m using Cisco SD-WAN version 19.3.0.
system
host-name vEdge1
site-id 2
sp-organization-name nwl-lab-sdwan
vbond 10.1.0.2
!
omp
no shutdown
graceful-restart
advertise connected
advertise static
!
vpn 0
interface ge0/0
ip address 10.65.91.1/24
tunnel-interface
encapsulation ipsec
color biz-internet
allow-service all
!
no shutdown
!
interface ge0/1
ip address 10.65.92.1/24
tunnel-interface
encapsulation ipsec
allow-service all
!
no shutdown
!
ip route 10.1.0.0/24 10.65.91.100
!
vpn 10
interface ge0/3
no shutdown
!
interface ge0/4
no shutdown
!
omp
advertise connected
!
!
vpn 512
interface eth0
shutdown
hostname SW1
!
ip cef
!
interface Loopback0
ip address 11.11.11.11 255.255.255.255
!
no switchport
ip address 10.2.1.101 255.255.255.0
!
router ospf 1
network 10.2.1.0 0.0.0.255 area 0
network 11.11.11.11 0.0.0.0 area 0
!
end
hostname SW2
!
ip cef
!
interface Loopback0
ip address 22.22.22.22 255.255.255.255
!
no switchport
ip address 10.2.2.102 255.255.255.0
!
router ospf 1
network 10.2.2.0 0.0.0.255 area 1
network 22.22.22.22 0.0.0.0 area 1
!
end
OSPF Feature Template
Go to Configuration > Templates > Feature > Add Template and select OSPF:
I’ll make a couple of changes here. First, we make the router ID device-specific:
Next, we’ll configure the areas. Click on New Area:
We’ll start with area 0. Set the number and click on Add Interface:
Once again, click on Add Interface:

I’ll make the Interface Name device-specific:
For this example, I could have picked a global value. When you are doing labs, it’s tempting to create
new templates all the time and only use global values. This gets the job done, but if you think about
using device-specific variables, you’ll have a valuable exercise of how you can use templates in a
production network.
Click on Add to continue. In the Area overview, you see that we now have one interface
attached to area 0. Click on Add:
You now see this overview:
Click again on New Area to create area 1. Specify the area number and click on Add Interface:
Once again, click on Add Interface:
I’ll change the Interface Name so that it is device-specific:

Click on Add one more time so that you see this overview:
Good. We now have two areas, each with an interface. That’s all we’ll configure for now. Click
on Save to store the template.
Device Template
We can now attach the OSPF feature template to a device template. Go to Configuration >
Templates > Device and edit the device template, which is attached to vEdge1:
Scroll down to Service VPN and select OSPF under Additional VPN Templates:
Select our OSPF feature template and click on Update:

We have to set the variables for the router ID, area 0 interface, and area 1 interface:
In the next screen, we can check the Config Diff to see what OSPF commands will be added:
Click on Configure Devices and push the template to the vEdge1 router. This completes the
configuration.
Verification
Let’s verify our work. The CLI commands for OSPF are similar to what you know from Cisco
IOS. First, let’s check the neighbor adjacency:
vEdge1# show ospf neighbor

DBsmL -> Database Summary List
RqstL -> Link State Request List
RXmtl -> Link State Retransmission List
SOURCE
DEAD
VPN IP ADDRESS INTERFACE ROUTER ID STATE
PRIORITY TIMER DBsmL RqstL RXmtL
-----------------------------------------------------------------------------
--------------------------
10 10.2.1.101 ge0/3 10.2.1.101 full 1
35 0 0 0
10 10.2.2.102 ge0/4 10.2.2.102 full 1
37 0 0 0
We have two neighbors. Here we can see the routes we learned:
vEdge1# show ospf routes

ospf routes-table vpn 10 network 10.2.1.0/24
info ID 0
area-id 0
cost 10
path-type intra-area
dest-type network
next-hop 0.0.0.0
if-name ge0/3
info ID 0
area-id 1
cost 10
dest-type network
next-hop 0.0.0.0
if-name ge0/4
info ID 0
area-id 0
cost 11
dest-type network
next-hop 10.2.1.101
if-name ge0/3
info ID 0
area-id 1
cost 11
dest-type network
next-hop 10.2.2.102
if-name ge0/4
We can check the LSDB:
vEdge1# show ospf database

LSA LINK ADVERTISING
VPN AREA TYPE ID ROUTER CHECKSUM
AGE SEQ#
-----------------------------------------------------------------------------
--------------------
10 0 router 1.1.1.1 1.1.1.1 0x16a6
1618 0x80000005
10 0 router 10.2.1.101 10.2.1.101 0x8894
65 0x80000010
10 0 network 10.2.1.101 10.2.1.101 0xb726
1518 0x80000002
10 0 summary 10.2.2.0 1.1.1.1 0xfe41
1578 0x80000002
10 0 summary 22.22.22.22 1.1.1.1 0xc332
41 0x80000001
10 1 router 1.1.1.1 1.1.1.1 0x3683
1548 0x80000005
10 1 router 10.2.2.102 10.2.2.102 0x38ae
43 0x80000012
10 1 network 10.2.2.102 10.2.2.102 0xa82f
1360 0x80000002
10 1 summary 10.2.1.0 1.1.1.1 0xa37
1428 0x80000002
10 1 summary 11.11.11.11 1.1.1.1 0xbf62
64 0x80000001
And there is a command that gives an overview of the entire OSPF process:
vEdge1# show ospf process

ospf process vpn 10
router-id 1.1.1.1
rfc1583-compatible true
spf-delay 200
spf-holdtime 1000
spf-max-holdtime 10000
spf-hold-multiplier 1
spf-last-exec-time 59
lsa-refresh-interval 10
asbr-router true
external-lsa-count 0
external-lsa-checksum 0
number-areas 2
ignore-down-bit false
hello-received 708
hello-sent 680
dbd-received 4
dbd-sent 6
ls-req-received 2
ls-req-sent 2
ls-upd-received 20
ls-upd-sent 16
ls-ack-received 12
ls-ack-sent 13
area 0
backbone-area true
num-interfaces 1
num-full-adj-routers 1
spf-exec-count 6
lsa-count 5
router-lsa-count 2
router-lsa-checksum 40762
network-lsa-count 1
network-lsa-checksum 46886
summary-lsa-count 2
summary-lsa-checksum 115059
asbr-lsa-count 0
asbr-lsa-checksum 0
nssa-lsa-count 0
nssa-lsa-checksum 0
area 1
num-interfaces 1
num-full-adj-routers 1
spf-exec-count 6
lsa-count 5
router-lsa-count 2
router-lsa-checksum 28465
network-lsa-count 1
network-lsa-checksum 43055
summary-lsa-count 2
summary-lsa-checksum 51609
asbr-lsa-count 0
asbr-lsa-checksum 0
nssa-lsa-count 0
nssa-lsa-checksum 0
As you can see, there are plenty of show commands to verify OSPF.
system
host-name vEdge1
site-id 2
admin-tech-on-failure
no route-consistency-check
vbond 10.1.0.2
!
omp
no shutdown
graceful-restart
advertise connected
advertise static
!
vpn 0
interface ge0/0
ip address 10.65.91.1/24
tunnel-interface
encapsulation ipsec
color biz-internet
allow-service all
!
no shutdown
!
interface ge0/1
ip address 10.65.92.1/24
tunnel-interface
encapsulation ipsec
allow-service all
!
no shutdown
!
ip route 10.1.0.0/24 10.65.91.100
!
vpn 10
router
ospf
router-id 1.1.1.1
timers spf 200 1000 10000
area 0
interface ge0/3
exit
exit
area 1
interface ge0/4
exit
exit
!
interface ge0/3
no shutdown
!
interface ge0/4
no shutdown
!
omp
advertise connected
!
vpn 512
interface eth0
shutdown
hostname SW1
!
ip cef
!
interface Loopback0
ip address 11.11.11.11 255.255.255.255
!
no switchport
ip address 10.2.1.101 255.255.255.0
!
router ospf 1
network 10.2.1.0 0.0.0.255 area 0
network 11.11.11.11 0.0.0.0 area 0
!
end
hostname SW2
!
ip cef
!
interface Loopback0
ip address 22.22.22.22 255.255.255.255
!
no switchport
ip address 10.2.2.102 255.255.255.0
!
router ospf 1
network 10.2.2.0 0.0.0.255 area 1
network 22.22.22.22 0.0.0.0 area 1
!
end
Conclusion
You have now learned how to configure OSPF on a Cisco SD-WAN vEdge router.
Cisco SD-WAN BGP Configuration
Cisco SD-WAN routers use OMP for routing information on the overlay network. Within a site,
sometimes you need an IGP like OSPF or perhaps BGP.
This lesson will explain how to configure BGP between a Cisco IOS device and a Cisco SD-
WAN vEdge router. We’ll use feature and device templates to accomplish this.
Configuration
Nothing fancy. We only have our vEdge1 router and SW1. I pre-configured SW1 with BGP. I’m
using Cisco SD-WAN version 19.3.0.
system
host-name vEdge1
site-id 2
vbond 10.1.0.2
!
omp
no shutdown
graceful-restart
advertise connected
advertise static
!
vpn 0
interface ge0/0
ip address 10.65.91.1/24
tunnel-interface
encapsulation ipsec
color biz-internet
allow-service all
!
no shutdown
!
interface ge0/1
ip address 10.65.92.1/24
tunnel-interface
encapsulation ipsec
allow-service all
!
no shutdown
!
ip route 10.1.0.0/24 10.65.91.100
!
vpn 10
interface ge0/3
no shutdown
!
omp
advertise connected
!
!
vpn 512
interface eth0
shutdown
hostname SW1
!
ip cef
!
interface Loopback0
ip address 11.11.11.11 255.255.255.255
!
no switchport
ip address 10.2.1.101 255.255.255.0
!
router bgp 1
bgp log-neighbor-changes
network 11.11.11.11 mask 255.255.255.255
neighbor 10.2.1.1 remote-as 1
!
end
hostname SW2
!
ip cef
!
interface Loopback0
ip address 22.22.22.22 255.255.255.255
!
no switchport
ip address 10.2.2.102 255.255.255.0
!
router ospf 1
network 10.2.2.0 0.0.0.255 area 1
network 22.22.22.22 0.0.0.0 area 1
!
end
Let’s configure the vEdge1 router.
Feature Template: BGP
Go to Configuration > Templates > Feature and click on Add Template:
Specify a name:
Scroll down to NEIGHBOR and click on New Neighbor:
Fill in the Address and click on Add:

Our neighbor now shows up in the overview:
All the other settings are OK. Scroll down and click on Save.
Device Template
Go to Configuration > Templates > Device and edit the device template, which is attached to
vEdge1:
Scroll down to Service VPN and select BGP under the Additional VPN Templates:
Select the BGP feature template that we just created:
Click on Update to continue. In the next screen, we have to fill in the variables about the AS
numbers:
Click on Next, and we can check Config Preview or Config Diff. Below you can see what
configuration will be added to vEdge1:
Click on Configure Devices to push the device template to the router.
Verification
We can use a couple of show commands to check whether or not BGP is up and running. Let’s
check the neighbor adjacency:
vEdge1# show bgp summary

vpn 10
bgp-router-identifier 172.16.1.1
local-as 1
rib-entries 1
rib-memory 112
total-peers 1
peer-memory 4816
Local-soo SoO:0:2
ignore-soo
MSG MSG OUT PREFIX
PREFIX PREFIX
NEIGHBOR AS RCVD SENT Q UPTIME RCVD
VALID INSTALLED STATE
-----------------------------------------------------------------------------
----------------------------
10.2.1.101 1 14 12 0 0:00:09:13 1 1
1 established
Above, we see that we have a neighbor adjacency. If you want to take a closer look, use this
command:
vEdge1# show bgp neighbor
bgp bgp-neighbor vpn 10 10.2.1.101
as 1
msg-rcvd 11
msg-sent 10
outQ 0
uptime 0:00:07:13
state established
last-uptime "Fri Jul 30 12:48:52 2021"
address-family 0
afi ipv4-unicast
If you want to see, even more, add the detail parameter:
vEdge1# show bgp neighbor detail

bgp bgp-neighbor vpn 10 10.2.1.101
as 1
local-as-num 1
remote-router-id 10.2.1.101
last-read 45
keepalive 60
holdtime 180
cfg-keepalive 0
cfg-holdtime 0
adv-4byte-as-cap true
rec-4byte-as-cap true
adv-refresh-cap true
rec-refresh-cap true
rec-new-refresh-cap true
msg-rcvd 12
msg-sent 11
prefix-rcvd 1
prefix-valid 1
prefix-installed 1
outQ 0
uptime 0:00:08:07
state established
open-in-count 1
open-out-count 1
notify-in-count 0
notify-out-count 0
update-in-count 2
update-out-count 0
keepalive-in-count 9
keepalive-out-count 10
refresh-in-count 0
refresh-out-count 0
dynamic-in-count 0
dynamic-out-count 0
adv-interval 5
conn-established 1
conn-dropped 0
local-host 10.2.1.1
local-port 46679
remote-host 10.2.1.101
remote-port 179
next-hop 10.2.1.1
read-thread-on true
last-uptime "Fri Jul 30 12:48:52 2021"
Here we can see which routes we learned:
vEdge1# show bgp routes

bgp routes-table vpn 10 11.11.11.11/32
info 0
nexthop 10.2.1.101
metric 0
local-pref 100
weight 0
origin igp
as-path Local
path-status valid,best,internal
tag 0
Above, we see the vEdge1 router learned about 11.11.11.11/32.
Last but not least, let’s check the routing table:
vEdge1# show ip route bgp

Codes Status flags:

NEXTHOP
-----------------------------------------------------------------------------
----------------------------------------------------------------
10 11.11.11.11/32 bgp i ge0/3 10.2.1.101
- - - - F,S
These show commands provide everything that we might want to check.
system
host-name vEdge1
site-id 2
vbond 10.1.0.2
!
omp
no shutdown
graceful-restart
advertise connected
advertise static
!
vpn 0
interface ge0/0
ip address 10.65.91.1/24
tunnel-interface
encapsulation ipsec
color biz-internet
allow-service all
!
no shutdown
!
interface ge0/1
ip address 10.65.92.1/24
tunnel-interface
encapsulation ipsec
allow-service all
!
no shutdown
!
ip route 10.1.0.0/24 10.65.91.100
!
vpn 10
router
bgp 1
neighbor 10.2.1.101
no shutdown
remote-as 1
!
interface ge0/3
no shutdown
!
omp
advertise connected
!
!
vpn 512
interface eth0
shutdown
hostname SW1
!
ip cef
!
interface Loopback0
ip address 11.11.11.11 255.255.255.255
!
no switchport
ip address 10.2.1.101 255.255.255.0
!
router bgp 1
network 11.11.11.11 mask 255.255.255.255
!
end
hostname SW2
!
ip cef
!
interface Loopback0
ip address 22.22.22.22 255.255.255.255
!
no switchport
ip address 10.2.2.102 255.255.255.0
!
router ospf 1
network 10.2.2.0 0.0.0.255 area 1
network 22.22.22.22 0.0.0.0 area 1
!
end
Conclusion
That’s it. You have now learned how to configure and verify BGP on Cisco SD-WAN using
templates and the CLI.
Cisco SD-WAN Localized Data Policy Policer
Cisco SD-WAN offers a centralized policy (network-wide scope) and the localized policy
(single-device scope). There are two localized policy types:
• Localized control policy

• Localized data policy
The localized control policy affects the control plane. The vEdge routers have an overlay
network and use OMP to advertise routes, but you can also use “regular” routing protocols like
OSPF or BGP. With the localized control policy, you can affect routing.
The localized data policy controls the flow and data going in and out of interfaces and
interface queues. You can set DSCP or CoS values, and do things like policing, shaping, and
queueing.
In this lesson, I’ll explain how to configure policing with a localized data policy. We are going to
configure this in vManage with templates.
If you are familiar with configuring policing in Cisco IOS and new to Cisco SD-WAN policies,
this will be confusing. I’ll make sure to keep it as easy as possible. In Cisco IOS, we configure a
simple policer like this:
In a nutshell, here’s how it works:
• In the access-list we define the traffic we want to police.

• A class-map includes the access-list. Instead of an access-list, you could also match other items
in the class-map.
• A policy-map refers to the class-map and has the policer.
• We attach the policy-map to an interface on the router.
In Cisco SD-WAN, it’s different. The confusing part is that there is new terminology, and some
terminology has a different meaning than what you know from Cisco IOS. The
configuration is also different. Here is a visualization to help you through this:
This requires a lot of explanation. I explained the device and feature templates in this lesson, so
make sure you are familiar with those.
• Groups of Interest are things we can use in our policy. For example:
o Data Prefix-lists
o Policers
o Port mirrors
o And some other items.
• The access control list is not an access-list, as you know it. This is more like a route-map or
policy-map with sequence numbers where you configure:
o Match statements:
▪ DSCP value
▪ Packet length
▪ PLP
▪ Protocol
▪ Source or destination Data Prefix
▪ Source or destination port numbers
▪ TCP SYN
▪ Class (this is a queue)
o Action statements:
▪ Counter
▪ DSCP (change value)
▪ Log
▪ Next Hop (change the next-hop like we do with policy-based routing).
▪ Mirror List
▪ Class
▪ Policer
• The localized policy is where we configure items like:
o QoS Maps (queues)
o Access Control Lists
o Route Policy
o And some other items.
We have to attach the items we created above to each other. This is what it looks like:
• The groups of interest are attached to the access control list.

• The access control list is configured under the localized control policy and attaches to an
interface with a feature template.
• The localized policy is a global configuration item that we attach to a device template.
Don’t worry, I will show you how to configure all of this step by step. The visualization might
help to understand the steps when we go through all of this. Let’s do this!
Configuration
This is the exact same topology I used in the service VPN lesson and the templates lesson. I’m
using the same device and feature templates I created before. Service VPN 10 is configured on
the Gi0/3 interfaces of vEdge2 and vEdge3 so that I can send traffic between SW2 and SW3.
Our goal is to configure an inbound policer on the ge0/3 interface of vEdge2. Make sure you
understand how device and feature templates work before you continue with this lesson. We
build upon the knowledge from our previous lessons.
system
host-name vEdge2
site-id 2
vbond 10.1.0.2
!
vpn 0
interface ge0/0
ip address 10.65.91.2/24
ipv6 dhcp-client
tunnel-interface
encapsulation ipsec
color biz-internet
allow-service all
!
no shutdown
!
interface ge0/1
ip address 10.65.92.2/24
tunnel-interface
encapsulation ipsec
allow-service all
!
no shutdown
!
ip route 10.1.0.0/24 10.65.91.100
!
vpn 10
interface ge0/3
ip address 10.2.0.254/24
no shutdown
!
omp
advertise connected
!
vpn 512
interface eth0
shutdown
system
host-name vEdge3
site-id 3
vbond 10.1.0.2
!
vpn 0
interface ge0/0
ip address 10.65.91.3/24
ipv6 dhcp-client
tunnel-interface
encapsulation ipsec
color biz-internet
allow-service all
!
no shutdown
!
interface ge0/1
ip address 10.65.92.3/24
tunnel-interface
encapsulation ipsec
allow-service all
!
no shutdown
!
ip route 10.1.0.0/24 10.65.91.100
!
vpn 10
interface ge0/3
ip address 10.3.0.254/24
no shutdown
!
omp
advertise connected
!
vpn 512
interface eth0
shutdown
hostname SW2
!
no ip routing
!
no switchport
ip address 10.2.0.102 255.255.255.0
!
hostname SW3
!
no ip routing
!
no switchport
ip address 10.3.0.103 255.255.255.0
!
Create Localized Policy
First, we have to create the policy itself.
Go to Configuration > Policies > Localized Policy and click on Add Policy:
Groups of Interest
On the left side, you find the groups of interest. This is where you configure the items that you
can call in other items of the policy, like the access control lists.
Policer
Let’s create a policer. Select Policer and click on New Policer List:
We choose a name and configure the settings for our policer. It doesn’t matter too much what
you pick for a lab:
Click on Add, and you will see the new policer in the overview:
Data Prefix List
Let’s make sure that the policer only works for traffic sourced from 10.2.0.0/24 (site 2). We need
the Data Prefix group of interest for this:
Enter a name and add the correct prefix. Click on Add, and the prefix-list shows up in the
overview:
We now have all the required groups of interest. Click on Next to continue so we can create the
actual policy.
Access Control List
We don’t need a QoS map, so click on Next:
Click on Add Access Control List Policy and select Add IPv4 ACL Policy:
On the left side, we have two options:
By default, there are no sequences, so all traffic matches the default action. The default action
is set to drop. Let’s make some changes here. Click on Add ACL Sequence on the left side,
then click on Sequence Rule on the right.
Select Source Data Prefix and select the data prefix-list we just created:
Now click on Action and select our policer:
I also like to add a counter which should make it easier to see whether we get matches on this
policy. Add the counter, give it a name, and click on Save Match and Actions:
Below, you see the overview of what we configured:

We don’t want to drop any other traffic, so make sure you change the default action to Accept:
Click on Save Access Control List Policy to continue. The access control list policy shows up
in the overview:
Click Next to continue. We don’t need a Route Policy, so click Next one more time:
In the final screen, give your policy a name. I also like to check the Netflow and Application
checkboxes:
Netflow gives cflowd visibility, and Application allows the vEdge router to monitor the
applications. This doesn’t affect our policer and can be interesting to look at.
Click on Save Policy to finish this policy.
Attach Localized Policy to Device Template
The localized policy is ready, and I’d like to attach the access control list to an interface. Before I
can do that, the vEdge router requires the policy in its configuration.
I currently have a device template that is attached to vEdge2 and vEdge3. I could add the policy
here, but that means that vEdge3 also receives the policy. I only want to use my policer policy on
vEdge2. I’ll copy our current device template so that we can use a new template for vEdge2.
Go to Configuration > Templates, click on the three dots and click on Copy:
Give the new template a name and click on Copy:
Click on the three dots and select Edit. Scroll down to Additional Templates and select our
policy:
Click on Update to save the device template. Let’s attach this template to vEdge2. Click on the
three dots next to our template and click on Attach Devices:
Select vEdge2 and click on Attach:

We don’t have to change any variables, so in the next screen, click on Next as well:
The Config Preview and Config Diff screens are interesting. This shows the actual CLI
configuration:
Click on Configure Devices and wait until the configuration is pushed to vEdge2.
We now have the localized policy on vEdge2. It’s there, but not doing anything at the moment.
Attach Access Control List to Interface
The policy has been added to vEdge2. We can now add the access control list to an interface.
Head over to Configuration > Templates > Feature Templates.
I have a template for the ge0/3 interface in VPN 10, but it’s attached to multiple vEdge routers. I
only want to attach the policer policy to vEdge2, so we’ll copy the feature template. Click on
Copy:
Give the new template a name and click on Copy:
Click on the three dots next to the new template and select Edit:
Scroll down to ACL/QoS, enable the Ingress ACL, and set the access-list name:
Click on Update. Now we can attach the updated feature template to the device template.
Update Feature Template in Device Template
Go to Configuration > Templates > Device and edit our template-vedge2-vpn10 template once
more:
Scroll down to Service VPN and change the VPN Interface to use our new feature template:
Click on Update to continue. In the next screen where we can change variables, click Next as
well.
In Config Preview or Config Diff, we can see our access-list which will be attached to the ge0/3
interface under VPN 10:
Click on Configure Devices to continue. Wait for a few seconds until the template is pushed to
the vEdge2 router.
Verification
Great, our policer is in place. Let’s find out whether or not it works. A quick way to test the
policer is to send some packets from SW2 to SW3:
SW2#ping 10.3.0.103 repeat 30

!!!!!!!!!!!.!!!!!!!!.!!!!!!!.!
Some packets make it, others don’t. This is a good indicator that our policer works.
Let’s check the configuration of vEdge2. To be honest, I had some issues with the commands to
verify everything. Maybe this is related to the version I am using. Let’s take a look. We can see
the access-list is attached to the ge0/3 interface:
vEdge2# show running-config vpn 10 interface ge0/3

vpn 10
interface ge0/3
ip address 10.2.0.254/24
no shutdown
access-list SITE2-POLICER in
And we can see the access-list itself here:
vEdge2# show running-config policy access-list

policy
access-list SITE2-POLICER
sequence 1
match
source-data-prefix-list SITE2-PREFIX
!
action accept
count COUNTER1
policer POLICER
!
!
default-action accept
Above, we see the policer and counter. Here is the policer configuration:
vEdge2# show running-config policy policer

policy
policer POLICER
rate 15000
burst 15000
exceed drop
We can see the association between the policy, access-list, and interface here:
vEdge2# show policy access-list-associations
INTERFACE INTERFACE
NAME NAME DIRECTION
-----------------------------------------
SITE2-POLICER ge0/3 in
Our counter shows packets and bytes:
vEdge2# show policy access-list-counters
NAME COUNTER NAME PACKETS BYTES

------------------------------------------------------------
SITE2-POLICER COUNTER1 173 19722
default_action_count 202465 42834349
I would expect to see some numbers here:
vEdge2# show policy access-list-policers
POLICER OOS OOS

NAME NAME PACKETS BYTES
----------------------------------------------
SITE2-POLICER 1.POLICER 0 0
Or in the interface:
vEdge2# show interface detail ge0/3 | include policer

rx-policer-drops 0
cpu-policer-drops 0
tx-icmp-policer-drops 0
rx-policer-remark 0
Maybe this is a bug in version 19.3.0. If you do see something here, let me know. I didn’t try
version 18.x or 20.x in my lab. Anyway, this is how you configure a localized control policy.
system
host-name vEdge2
site-id 2
vbond 10.1.0.2
!
omp
no shutdown
graceful-restart
advertise connected
advertise static
!
banner
motd "Welcome to the vEdge router!"
!
vpn 0
interface ge0/0
ip address 10.65.91.2/24
tunnel-interface
encapsulation ipsec
color biz-internet
allow-service all
no allow-service bgp
allow-service dhcp
allow-service dns
allow-service icmp
no allow-service sshd
no allow-service netconf
no allow-service ntp
no allow-service ospf
no allow-service stun
allow-service https
!
no shutdown
!
interface ge0/1
ip address 10.65.92.2/24
tunnel-interface
encapsulation ipsec
allow-service all
no allow-service bgp
allow-service dhcp
allow-service dns
allow-service icmp
no allow-service sshd
no allow-service netconf
no allow-service ntp
no allow-service ospf
no allow-service stun
allow-service https
!
no shutdown
!
ip route 10.1.0.0/24 10.65.91.100
!
vpn 10
interface ge0/3
ip address 10.2.0.254/24
no shutdown
access-list SITE2-POLICER in
!
omp
advertise connected
!
!
vpn 512
interface eth0
shutdown
!
!
policy
app-visibility
flow-visibility
log-frequency 60
policer POLICER
rate 15000
burst 15000
exceed drop
!
lists
data-prefix-list SITE2-PREFIX
ip-prefix 10.2.0.0/24
!
access-list SITE2-POLICER
sequence 1
match
source-data-prefix-list SITE2-PREFIX
!
action accept
count COUNTER1
policer POLICER
!
!
default-action accept
!
!
system
host-name vEdge3
site-id 3
vbond 10.1.0.2
!
vpn 0
interface ge0/0
ip address 10.65.91.3/24
ipv6 dhcp-client
tunnel-interface
encapsulation ipsec
color biz-internet
allow-service all
!
no shutdown
!
interface ge0/1
ip address 10.65.92.3/24
tunnel-interface
encapsulation ipsec
allow-service all
!
no shutdown
!
ip route 10.1.0.0/24 10.65.91.100
!
vpn 10
interface ge0/3
ip address 10.3.0.254/24
no shutdown
!
omp
advertise connected
!
vpn 512
interface eth0
shutdown
hostname SW2
!
no ip routing
!
no switchport
ip address 10.2.0.102 255.255.255.0
!
hostname SW3
!
no ip routing
!
no switchport
ip address 10.3.0.103 255.255.255.0
!
Conclusion
You have now learned how to configure a localized control policy using vManage and templates.
Cisco SD-WAN Localized Control Policy
BGP
Cisco SD-WAN offers a centralized policy (network-wide scope) and a localized policy (single-
device scope). There are two localized policy types:
• Localized data policy

• Localized control policy
The localized data policy affects the data plane. You can influence the flow and data going in
and out of an interface (queues).
The localized control plane affects the control plane. Therefore, you can manipulate routing
decisions. In this lesson, I’ll explain how to configure a localized control policy so you can
influence the BGP local preference.
In a nutshell, this is what we have to configure:
In a nutshell, here’s what we have to do:
• We create a prefix list that matches the traffic we want to influence.

• We create a localized policy that includes a route policy.
• We create a route policy where we configure two items:
o Match condition: the prefix list.
o Action: we set a local preference value.
• We add the localized policy to a device template and push it to the vEdge router.
• We add the route policy to the BGP feature template and push it to the vEdge router.
Let’s get started!
Configuration
This is the topology we’ll use:
This is the exact same topology that I used in the Cisco SD-WAN BGP configuration lesson. We
are going to create a localized control policy to change the local preference for a prefix we
receive from SW1. I use Cisco SD-WAN version 19.3.0.
system
host-name vEdge1
site-id 2
vbond 10.1.0.2
!
omp
no shutdown
graceful-restart
advertise connected
advertise static
!
vpn 0
interface ge0/0
ip address 10.65.91.1/24
tunnel-interface
encapsulation ipsec
color biz-internet
allow-service all
!
no shutdown
!
interface ge0/1
ip address 10.65.92.1/24
tunnel-interface
encapsulation ipsec
allow-service all
!
no shutdown
!
ip route 10.1.0.0/24 10.65.91.100
!
vpn 10
router
bgp 1
neighbor 10.2.1.101
no shutdown
remote-as 1
!
interface ge0/3
no shutdown
!
omp
advertise connected
!
!
vpn 512
interface eth0
shutdown
hostname SW1
!
ip cef
!
interface Loopback0
ip address 11.11.11.11 255.255.255.255
!
no switchport
ip address 10.2.1.101 255.255.255.0
!
router bgp 1
network 11.11.11.11 mask 255.255.255.255
!
end
hostname SW2
!
ip cef
!
interface Loopback0
ip address 22.22.22.22 255.255.255.255
!
no switchport
ip address 10.2.2.102 255.255.255.0
!
router ospf 1
network 10.2.2.0 0.0.0.255 area 1
network 22.22.22.22 0.0.0.0 area 1
!
end
Localized Control Policy
Let’s start with the policy. Go to Configuration > Policies > Localized Policy and click on Add
Policy.
Prefix List
First, we’ll create a new prefix list:
This prefix list matches the loopback0 interface of SW1. Click on Add, and it will show up in the
overview:
Route Policy
Click Next until you reach the Route Policy overview. Click on Add Route Policy and then
Create New:
The route policy screen looks similar to the access control list. Enter a name and description,
then click on + Sequence Type and + Sequence Rule:
Click on Match, select Address, and select the prefix list we created:
Now click on Actions, Local Preference, set a value (it doesn’t matter what you pick in this
example), and click on Save Match And Actions:
Make sure the overview looks OK to you, then click on Save Route Policy:
We now have a route policy we can use. Click on Next:

In the final screen, give the localized policy a name and click on Save Policy:
Our localized policy is now ready:

Attach Localized Policy to Device Template
Before we can use the route policy in BGP, we have to push the localized policy to the router.
We’ll do this with the device template. Go to Configuration > Templates > Device and Edit the
device template:
Scroll down to Additional Templates and select the localized policy we just created:
Click on Update to continue. Click Next in the next screen:
In the Config Preview, we can see the actual configuration for the policy:
Click on Update Devices to push the policy to the vEdge1 router.

Attach Route Policy to BGP Feature Template
Once the device template with the policy is pushed to the router, we can edit our BGP feature
template to include the route policy. Go to Configuration > Templates > Feature and Edit the
BGP feature template:
Scroll down to Neighbor and click on the edit button:

Enable the Address Family and Route Policy In. Set the Policy Name to the name you picked
for the route policy (not the localized policy!):
Click on Update, so vManage will push the updated feature template to the router. We don’t
need to edit any variables, so click on Next:
In the Config Diff screen, we can see that two lines are added to the configuration:
Click on Configure Devices so that the configuration is pushed to the router. This completes the
configuration.
system
host-name vEdge1
site-id 2
vbond 10.1.0.2
!
omp
no shutdown
graceful-restart
advertise connected
advertise static
!
vpn 0
interface ge0/0
ip address 10.65.91.1/24
tunnel-interface
encapsulation ipsec
color biz-internet
allow-service all
!
no shutdown
!
interface ge0/1
ip address 10.65.92.1/24
tunnel-interface
encapsulation ipsec
allow-service all
!
no shutdown
!
ip route 10.1.0.0/24 10.65.91.100
!
vpn 10
router
bgp 1
neighbor 10.2.1.101
no shutdown
remote-as 1
address-family ipv4-unicast
route-policy BGP-LOCAL-PREFERENCE in
!
interface ge0/3
no shutdown
!
omp
advertise connected
!
!
vpn 512
interface eth0
shutdown
!
policy
!
lists
prefix-list SW1-L0-PREFIX
ip-prefix 11.11.11.11/32
!
route-policy BGP-LOCAL-PREFERENCE
sequence 1
match
address SW1-L0-PREFIX
!
action accept
set
local-preference 111
!
default-action reject
hostname SW1
!
ip cef
!
interface Loopback0
ip address 11.11.11.11 255.255.255.255
!
no switchport
ip address 10.2.1.101 255.255.255.0
!
router bgp 1
network 11.11.11.11 mask 255.255.255.255
!
end
hostname SW2
!
ip cef
!
interface Loopback0
ip address 22.22.22.22 255.255.255.255
!
no switchport
ip address 10.2.2.102 255.255.255.0
!
router ospf 1
network 10.2.2.0 0.0.0.255 area 1
network 22.22.22.22 0.0.0.0 area 1
!
end
Verification
The simplest way to verify whether this works is to check the BGP routes in the CLI:
vEdge1# show bgp routes
bgp routes-table vpn 10 11.11.11.11/32
info 0
nexthop 10.2.1.101
metric 0
local-pref 111
weight 0
origin igp
as-path Local
path-status valid,best,internal
tag 0
As you can see above, the local preference is set to 111. This is the value we specified in the
route policy.
Conclusion
You have now learned how to configure a localized control policy to influence the BGP local
preference on a vEdge router. I hope you enjoyed this lesson.
Cisco SD-WAN Hub and Spoke Topology
In a Cisco SD-WAN network, vEdge routers build a full-mesh topology with vEdge routers in
other sites. This is the default behavior, and it means that all devices within a service VPN can
communicate with each other. However, a full mesh topology is not always required, and with
many vEdge routers, it can even become a scalability issue.
This lesson will explain how you can use a centralized policy to configure a hub and spoke
topology. The hub site will be able to communicate with all spoke sites. However, spoke sites
can only communicate with the hub and not with other spoke sites.
This is the topology we’ll use:
We have three sites, and I assigned the Gi0/3 interfaces of all vEdge routers to service VPN 10.
We’ll do a “before and after” scenario so you can see the difference between the default (full
mesh) and a hub and spoke topology. I am using Cisco SD-WAN version 19.3.0.
system
host-name vEdge1
site-id 2
vbond 10.1.0.2
!
omp
no shutdown
graceful-restart
advertise connected
advertise static
!
banner
!
vpn 0
interface ge0/0
ip address 10.65.91.1/24
tunnel-interface
encapsulation ipsec
color biz-internet
allow-service all
!
no shutdown
!
interface ge0/1
ip address 10.65.92.1/24
tunnel-interface
encapsulation ipsec
allow-service all
!
no shutdown
!
ip route 10.1.0.0/24 10.65.91.100
ip route 10.1.0.0/24 10.65.92.100
!
vpn 10
interface ge0/3
ip address 10.2.0.254/24
no shutdown
!
omp
advertise connected
!
!
vpn 512
interface eth0
shutdown
!
!
system
host-name vEdge3
site-id 3
vbond 10.1.0.2
!
omp
no shutdown
graceful-restart
advertise connected
advertise static
!
banner
!
vpn 0
interface ge0/0
ip address 10.65.91.3/24
tunnel-interface
encapsulation ipsec
color biz-internet
allow-service all
!
no shutdown
!
interface ge0/1
ip address 10.65.92.3/24
tunnel-interface
encapsulation ipsec
allow-service all
!
no shutdown
!
ip route 10.1.0.0/24 10.65.91.100
ip route 10.1.0.0/24 10.65.92.100
!
vpn 10
interface ge0/3
ip address 10.3.0.254/24
no shutdown
!
omp
advertise connected
!
!
vpn 512
interface eth0
shutdown
!
!
system
host-name vEdge4
site-id 4
vbond 10.1.0.2
!
omp
no shutdown
graceful-restart
advertise connected
advertise static
!
banner
!
vpn 0
interface ge0/0
ip address 10.65.91.4/24
tunnel-interface
encapsulation ipsec
color biz-internet
allow-service all
!
no shutdown
!
interface ge0/1
ip address 10.65.92.4/24
tunnel-interface
encapsulation ipsec
allow-service all
!
no shutdown
!
ip route 10.1.0.0/24 10.65.91.100
ip route 10.1.0.0/24 10.65.92.100
!
vpn 10
interface ge0/3
ip address 10.4.0.254/24
no shutdown
!
omp
advertise connected
!
!
vpn 512
interface eth0
shutdown
!
!
hostname SW1
!
no ip routing
!
no switchport
ip address 10.2.0.101 255.255.255.0
!
!
end
hostname SW3
!
no ip routing
!
no switchport
ip address 10.3.0.103 255.255.255.0
!
!
end
hostname SW3
!
no ip routing
!
no switchport
ip address 10.4.0.104 255.255.255.0
!
!
end
Full Mesh Topology

The default is a full mesh topology. This means that all sites can reach each other. So, for
example, I can ping from SW3 to both SW1 and SW4:
SW3#ping 10.2.0.101
!!!!!
SW3#ping 10.4.0.104
!!!!!
SW4 can also ping SW1:
SW4#ping 10.2.0.101
!!!!!
We have full connectivity because each vEdge router advertises its prefix through OMP to the
vSmart controller. The vSmart controller advertises all prefixes to the vEdge routers.
In the show ip routes omp and show ipsec outputs below, I removed non-relevant columns to
keep it readable.
You can see the OMP routes below:
vEdge1# show ip routes omp | begin VPN

VPN PREFIX PROTOCOL TLOC IP COLOR
ENCAP STATUS
-----------------------------------------------------------------------------
----------
10 10.3.0.0/24 omp 172.16.1.3 biz-internet
ipsec F,S
10 10.3.0.0/24 omp 172.16.1.3 public-internet
ipsec F,S
10 10.4.0.0/24 omp 172.16.1.4 biz-internet
ipsec F,S
ipsec F,S
ENCAP STATUS
-----------------------------------------------------------------------------
----------
10 10.2.0.0/24 omp 172.16.1.1 biz-internet
ipsec F,S
ipsec F,S
10 10.4.0.0/24 omp 172.16.1.4 biz-internet
ipsec F,S
ipsec F,S
ENCAP STATUS
-----------------------------------------------------------------------------
-----------
10 10.2.0.0/24 omp 172.16.1.1 biz-internet
ipsec F,S
ipsec F,S
10 10.3.0.0/24 omp 172.16.1.3 biz-internet
ipsec F,S
ipsec F,S
In the output above, you can see that all prefixes are learned and installed. One for each WAN
connection.
This also means that all vEdge routers establish IPSec connections with each other. Between
TLOCs on one WAN interface and TLOCs of different WAN interfaces (if there is reachability
between the two WAN clouds). That is the case with two Internet connections like I have, but
not if you have a private WAN connection (like MPLS). You can see the IPSec connections
below:

SOURCE SOURCE DEST DEST REMOTE REMOTE
IP PORT IP PORT SPI TUN MTU TLOC ADDRESS TLOC
COLOR
-----------------------------------------------------------------------------
--------
10.65.91.1 12346 10.65.91.3 12346 259 1441 172.16.1.3 biz-
internet
10.65.91.1 12346 10.65.91.4 12346 256 1441 172.16.1.4 biz-
internet
10.65.91.1 12346 10.65.92.3 12346 259 1442 172.16.1.3
public-internet
10.65.91.1 12346 10.65.92.4 12346 256 1442 172.16.1.4
public-internet
10.65.92.1 12346 10.65.91.3 12346 259 1442 172.16.1.3 biz-
internet
10.65.92.1 12346 10.65.91.4 12346 256 1442 172.16.1.4 biz-
internet
10.65.92.1 12346 10.65.92.3 12346 259 1441 172.16.1.3
public-internet
10.65.92.1 12346 10.65.92.4 12346 256 1441 172.16.1.4
public-internet
COLOR
-----------------------------------------------------------------------------
---------
10.65.91.3 12346 10.65.91.1 12346 257 1441 172.16.1.1 biz-
internet
10.65.91.3 12346 10.65.91.4 12346 256 1441 172.16.1.4 biz-
internet
10.65.91.3 12346 10.65.92.1 12346 257 1442 172.16.1.1
public-internet
10.65.91.3 12346 10.65.92.4 12346 256 1442 172.16.1.4
public-internet
10.65.92.3 12346 10.65.91.1 12346 257 1442 172.16.1.1 biz-
internet
10.65.92.3 12346 10.65.91.4 12346 256 1442 172.16.1.4 biz-
internet
10.65.92.3 12346 10.65.92.1 12346 257 1441 172.16.1.1
public-internet
10.65.92.3 12346 10.65.92.4 12346 256 1441 172.16.1.4
public-internet
COLOR
-----------------------------------------------------------------------------
-----
10.65.91.4 12346 10.65.91.1 12346 257 1441 172.16.1.1 biz-
internet
10.65.91.4 12346 10.65.91.3 12346 259 1441 172.16.1.3 biz-
internet
10.65.91.4 12346 10.65.92.1 12346 257 1442 172.16.1.1
public-internet
10.65.91.4 12346 10.65.92.3 12346 259 1442 172.16.1.3
public-internet
10.65.92.4 12346 10.65.91.1 12346 257 1442 172.16.1.1 biz-
internet
10.65.92.4 12346 10.65.91.3 12346 259 1442 172.16.1.3 biz-
internet
10.65.92.4 12346 10.65.92.1 12346 257 1441 172.16.1.1
public-internet
10.65.92.4 12346 10.65.92.3 12346 259 1441 172.16.1.3
public-internet
Each vEdge router has 8 IPSec connections, and we only have three routers (with two WAN
interfaces). This can become a scalability issue with large topologies, especially if you have low-
end branch vEdge routers.
Configuration
Let’s change our topology from full mesh to a hub and spoke topology.
Centralized Policy
Go to Configuration > Policies > Centralized Policy and click on Add Policy:
Groups of Interest
We need to create two items:
• Site List: A list so we know which site will be the hub and which sites will be the spokes.
• VPN List: The VPN that we want to create a hub and spoke topology for.
Site List
Under Groups of Interest, add a New Site List:

We create two lists here:
• HUB: site 2.
• SPOKES: site 3 and 4.
Create the lists, so your overview looks like this:

VPN
Let’s create the VPN list. Under Groups of Interest, select VPN. Enter a name and the VPN
number (10) here:
Click on Add to continue. Then, under Topology, click on Add Topology and select Hub-and-
Spoke:
Give the policy a name, select the VPN List we created, and select the Hub and Spoke Sites.
Click on Save Hub-And-Spoke Policy to save the policy:
The policy now shows up in the overview. Click on Next:

We don’t need any Traffic Rules, so click on Next:
In the final screen, give the centralized policy a name and click on Save Policy:
Click on the three dots next to the policy and select Activate:
If you get an error that the vSmart controller is not in vManaged mode, take a look at this lesson.
Click on Activate:
The policy is now pushed to the vSmart controller:
That’s all we need to configure.
Verification
Let’s verify our work. First, I’ll try to ping the spoke sites from the hub site:
SW1#ping 10.3.0.103
!!!!!
SW1#ping 10.4.0.104
!!!!!
We can ping from the hub site to both spoke sites. However, I can’t ping between the spoke sites
anymore:
SW3#ping 10.4.0.104
UUUUU
Success rate is 0 percent (0/5)
What’s going on? Let’s take a look at OMP.
vEdge1# show ip route omp | begin VPN

VPN PREFIX PROTOCOL TLOC IP COLOR ENCAP
STATUS
-----------------------------------------------------------------------------
-----
10 10.3.0.0/24 omp 172.16.1.3 biz-internet ipsec
F,S
10 10.3.0.0/24 omp 172.16.1.3 public-internet ipsec
F,S
F,S
F,S
vEdge1 has entries for both spoke sites. Now take a look at the spoke routers:

STATUS
-----------------------------------------------------------------------------
-------
F,S
F,S
STATUS
-----------------------------------------------------------------------------
-------
F,S
F,S
Our spoke routers only know about the 10.2.0.0/24, which belongs to the hub site. The vSmart
controller doesn’t advertise the routes of spoke sites to spoke routers anymore.
Let’s check our IPSec connections again. Here is vEdge1:

COLOR
-----------------------------------------------------------------------------
-----
10.65.91.1 12346 10.65.91.3 12346 259 1441 172.16.1.3 biz-
internet
10.65.91.1 12346 10.65.91.4 12346 256 1441 172.16.1.4 biz-
internet
10.65.91.1 12346 10.65.92.3 12346 259 1442 172.16.1.3
public-internet
10.65.91.1 12346 10.65.92.4 12346 256 1442 172.16.1.4
public-internet
10.65.92.1 12346 10.65.91.3 12346 259 1442 172.16.1.3 biz-
internet
10.65.92.1 12346 10.65.91.4 12346 256 1442 172.16.1.4 biz-
internet
10.65.92.1 12346 10.65.92.3 12346 259 1441 172.16.1.3
public-internet
10.65.92.1 12346 10.65.92.4 12346 256 1441 172.16.1.4
public-internet
vEdge1 still has every possible IPSec connection to the spoke routers. Here are the spoke routers:

COLOR
-----------------------------------------------------------------------------
--------
10.65.91.3 12346 10.65.91.1 12346 257 1441 172.16.1.1 biz-
internet
10.65.91.3 12346 10.65.92.1 12346 257 1442 172.16.1.1
public-internet
10.65.92.3 12346 10.65.91.1 12346 257 1442 172.16.1.1 biz-
internet
10.65.92.3 12346 10.65.92.1 12346 257 1441 172.16.1.1
public-internet
SOURCE SOURCE DEST DEST REMOTE
REMOTE
COLOR
-----------------------------------------------------------------------------
--------
10.65.91.4 12346 10.65.91.1 12346 257 1441 172.16.1.1 biz-
internet
10.65.91.4 12346 10.65.92.1 12346 257 1442 172.16.1.1
public-internet
10.65.92.4 12346 10.65.91.1 12346 257 1442 172.16.1.1 biz-
internet
10.65.92.4 12346 10.65.92.1 12346 257 1441 172.16.1.1
public-internet
The output above shows that the spoke routers only have IPSec connections with the hub router.
Last but not least, you can see the policy on the vSmart controller:
vSmart1# show running-config policy

policy
lists
vpn-list SERVICE-VPN-10
vpn 10
!
site-list HUB
site-id 2
!
site-list SITE-2-3
site-id 2-3
!
!
control-policy control_718365493
sequence 10
match route
site-list SITE-2-3
!
action accept
!
!
sequence 20
match route
site-list SITE-2-3
!
action accept
!
!
sequence 30
match tloc
site-list SITE-2-3
!
action accept
!
!
default-action reject
And it is applied to the vSmart controller with this command:
vSmart1# show running-config apply-policy

apply-policy
site-list HUB
control-policy control_718365493 out
That’s all there is to it.
Conclusion
You have now learned how to configure a Cisco SD-WAN hub and spoke topology:
• By default, vSmart controllers advertise all prefixes to all vEdge routers.

• Routers establish full mesh IPsec connections using every possible TLOC, even between WAN
links if there is connectivity between the WAN links.
• With the hub and spoke topology, we reduce the number of IPSec connections and prevent
traffic between spoke sites.
Cisco SD-WAN Application-Aware Routing
(AAR)
If you have multiple connections, like an MPLS and a regular Internet connection, then
(depending on the OMP best path selection) both will probably be actively used. This might not
be the best solution. Your MPLS connection might support QoS while the Internet connection is
best effort. You might have a critical business application that requires QoS that should use the
MPLS link and web traffic that should only use the Internet connection.
What if the performance of the MPLS connection degrades? Temporarily switching over to the
Internet connection could offer a better end-user experience.
Another example is when you have multiple Internet connections. Perhaps through Fiber, Cable,
DSL, and 4G. It would be nice if you could always pick the best connection out of these options.
With Application-Aware Routing (AAR), we can decide which applications should use what
WAN connection, and we can failover based on criteria like packet loss, jitter, and delay.
AAR tracks network statistics from data plane tunnels between Cisco SD-WAN devices and uses
this information to calculate optimal traffic paths.
In this lesson, I’ll show you how to configure AAR and verify your traffic flows. This is the
topology we’ll use:
I have two sites with a single service VPN (10). The two sites are connected using two different
WAN links:
• biz-internet
• public-internet
We’ll take a look at how Cisco SD-WAN uses these two WAN connections if you don’t have
any policies.
Afterward, we’ll configure a centralized policy with Application-Aware Routing and two traffic
rules:
• Telnet traffic should use the “biz-internet” connection. When this traffic exceeds a certain
loss, latency, or delay, it should switch over to the public-internet link.
• An application list with multiple applications should use the “public-internet” link. When
this traffic exceeds a certain loss, latency, or delay, it should switch over to the biz-
internet link.
These two examples will help to understand AAR so you can create your own policies in the
future. I’m using Cisco SD-WAN version 19.3.0.
system
host-name vEdge1
site-id 2
vbond 10.1.0.2
!
omp
no shutdown
graceful-restart
advertise connected
advertise static
!
banner
!
vpn 0
interface ge0/0
ip address 10.65.91.1/24
tunnel-interface
encapsulation ipsec
color biz-internet
allow-service all
!
no shutdown
!
interface ge0/1
ip address 10.65.92.1/24
tunnel-interface
encapsulation ipsec
allow-service all
!
no shutdown
!
ip route 10.1.0.0/24 10.65.91.100
ip route 10.1.0.0/24 10.65.92.100
!
vpn 10
interface ge0/3
ip address 10.2.0.254/24
no shutdown
!
omp
advertise connected
!
!
vpn 512
interface eth0
shutdown
!
!
system
host-name vEdge3
site-id 3
vbond 10.1.0.2
!
omp
no shutdown
graceful-restart
advertise connected
advertise static
!
banner
!
vpn 0
interface ge0/0
ip address 10.65.91.3/24
tunnel-interface
encapsulation ipsec
color biz-internet
allow-service all
!
no shutdown
!
interface ge0/1
ip address 10.65.92.3/24
tunnel-interface
encapsulation ipsec
allow-service all
!
no shutdown
!
ip route 10.1.0.0/24 10.65.91.100
ip route 10.1.0.0/24 10.65.92.100
!
vpn 10
interface ge0/3
ip address 10.3.0.254/24
no shutdown
!
omp
advertise connected
!
!
vpn 512
interface eth0
shutdown
!
!
hostname SW1
!
no ip routing
!
no switchport
ip address 10.2.0.101 255.255.255.0
!
!
end
hostname SW3
!
no ip routing
!
no switchport
ip address 10.3.0.103 255.255.255.0
!
!
end
Simulate Flows
Before we configure anything, let’s look at the default behavior. Cisco vManage has a useful tool
to simulate flows and show traffic behavior.
Go to Monitor > Network > WAN – Edge and click on a vEdge router:
Scroll down to Troubleshooting and click on Simulate Flows on the right side:
We’ll try something simple to start with. I’ll specify a flow from source 10.2.0.101 with
destination 10.3.0.103. This is traffic from site 2 to site 3. The protocol number 6 is TCP, and the
destination port is 23 (telnet). Let’s fill in all fields and click on Simulate:
Take a look at the output below:
In the output above, you can see that the default behavior is to use both WAN links to send
traffic between the two sites. Once we have configured Application-Aware Routing, we’ll try
this again so you can see the difference.
Configuration
Let’s configure a centralized policy with Application-Aware Routing. Go to Configuration >
Policies > Centralized Policy and click on Add Policy:
Groups of Interest
First, we have to create some groups of interest:
• Application List
• Site List
• SLA Class
Application List
The application list contains one or more applications that we want to use in our policy. There
are two default application lists:
Each application list has a range of applications. We’ll create a new one so you can see what it
looks like. You probably have more applications than Microsoft or Google apps. Click on New
Application List, give it a name, and select some applications from the dropdown menu. Save
the list by clicking on the Add button:
Site List
Next up is the Site List. We’ll create a new list that defines our two sites (2 and 3). Select Site
and click on New Site List:
Give the Site List a name and add site numbers two and three:
Click on Add to store the Site List.
SLA Class List
The SLA Class List defines when the traffic has to switch over to another WAN connection. This
is where we define a threshold for packet loss, latency, and jitter. There are four default SLA
classes. Let’s create an SLA Class List. Click on New SLA Class List:
We’ll set some parameters. In a lab, it doesn’t matter what values you select:
Click on Add to store the SLA Class List.
Traffic Rules
We don’t need a Topology, or VPN Membership, so click on Next. Select Create New under
Configure Traffic Rules > Application-Aware Routing > Add Policy:
Telnet
Click on + Sequence Type, then select Protocol and Destination Port. Set the Protocol to 6
(TCP) and the destination port number to 23:
Click on the Actions tab and select SLA Class List. Choose the SLA Class that we just created
and set the Preferred Color to “biz-internet”:
Traffic that matches TCP destination port 23 will use WAN connection “biz-internet” by default.
When the traffic exceeds the values we configured in SLA class “SLA-TELNET”, the traffic
switches over to other WAN connections.
Click on Save Match And Actions.
When you select the “strict” checkbox, the traffic will only use this WAN interface and won’t failover to
another interface.
Application List
We’ll also add a sequence rule for the application list we created.
Click on + Sequence Rule one more time. Select Match and Application/Application Family
List. Select the Application List we created:
Now go to the Actions tab and select SLA Class List and “public-internet” as the Preferred
Color:
We’ll use the default SLA class this time. Click on Save Match And Actions. We now have two
sequence rules. Click on Save Application-Aware Routing Policy:
We are done with the Traffic Rules, so click on Next:
Application-Aware Routing
Give the centralized policy a name and select the Site List and VPN List that you want to apply
this policy to:
Click on Save Policy, and we are ready:
In the Centralized Policy overview, click on the three dots and select Activate:
If you get an error that the vSmart controller is not in vManaged mode, take a look at this lesson.
Click on Activate to push the centralized policy to the vSmart controller:
This completes the centralized policy configuration.

Verification
Let’s verify our work. Go back to Monitor > Network and click on vEdge1. Scroll down to
Troubleshooting and click on Simulate Flows.
Telnet
I’ll fill in the details that match TCP and destination port 23. Click on Simulate:
This shows us that telnet traffic will use the “biz-internet” WAN link. If this traffic exceeds the
values in our SLA class, it would switch over to the other WAN link.
Application List
Let’s try a test for the Microsoft applications. Select “ms-office-365” in the Application list and
click on Simulate:
This traffic now uses the “public-internet” WAN connection. When it exceeds the “default” SLA
class, it will switch over to the “biz-internet” WAN connection.
vSmart Controller
Let me also show you the CLI configuration of the policy on the vSmart controller:
vSmart1# show running-config policy

policy
sla-class Default
loss 25
latency 300
jitter 100
!
sla-class SLA-TELNET
loss 10
latency 500
jitter 200
!
app-route-policy _SERVICE-VPN-10_AAR
sequence 1
match
source-ip 0.0.0.0/0
destination-port 23
protocol 6
!
action
sla-class SLA-TELNET preferred-color biz-internet
!
!
sequence 11
match
source-ip 0.0.0.0/0
app-list MS-APPS
!
action
sla-class Default preferred-color public-internet
!
!
!
!
lists
vpn 10
!
app-list MS-APPS
app excel_online
app groove
app hockeyapp
app live_groups
app live_mesh
app microsoft
app ms-office-365
app ms-office-web-apps
app ms-rpc
app ms-services
app ms_onenote
app ms_planner
app ms_sway
app ms_translator
app msrpc
app office365
app office_docs
app outlook
app powerpoint_online
app windows_marketplace
app word_online
app yammer
!
site-list SITE-2-3
site-id 2-3
!
!
!
This is how the policy is applied:
vSmart1# show running-config apply-policy

apply-policy
site-list SITE-2-3
app-route-policy _SERVICE-VPN-10_AAR
!
!
Conclusion
You have now learned how to verify your traffic flows and how to configure a centralized policy
with Application-Aware Routing. I hope you enjoyed this lesson.

Introduction to SD-WAN: How It Saves Money by Combining Internet and Private WAN

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Introduction to SD-WAN: How It Saves Money by Combining Internet and Private WAN

Uploaded by

Copyright:

Available Formats

Introduction to SD-WAN

Software Defined WAN (SD-WAN) is hot nowadays. Why?

Cisco SD-WAN Solutions

Behind the scenes they use some familiar protocols:

• DMVPN with QoS

Cisco SD-WAN (Viptela)

• Viptela vEdge: 100, 1000, 2000, or 5000 series routers.

There are two options:

• Cloud onRamp SaaS

Build your own Lab

To run the Cisco SD-WAN images you need:

Image vCPU(s) RAM

The vManage 20.x image apparently requires 24GB of RAM.

The image types are VMWare, KVM, and Azure.

It’s possible, but I don’t recommend it.

Cisco Modeling Labs (CML)

Here’s an example of my EVE-NG Cisco SD-WAN lab:

• Downloading the required Cisco and EVE-NG images.

• Professional/Learning Center Version

I downloaded the ISO of the professional version because of two reasons:

• It’s the latest version.

Let’s create a virtual machine for EVE-NG.

Let’s create the port groups. Go to Networking in the Navigator:

Give your lab a name nd click on Save:

In the dropdown, you only have two options at the moment:

Cisco SD-WAN Images

Let’s create these folders.

The vEdge image:

And the vManage image:

# /opt/qemu/bin/qemu-img create -f qcow2 virtiob.qcow2 100G

And we need to set some permissions:

• Which images you need to download.

• Use one of the free Cisco Devnet sandboxes.

• System configuration: A basic configuration where we specify things such as a hostname,

Here is the topology we’ll use:

Let’s log in. The default username and password is “admin”:

vmanage login: admin

Available storage devices:

Allocating group tables: done

wall: cannot get tty name: Success

Broadcast message from root@vmanage (somewhere) (Thu Jul 8 13:36:31 2021):

vmanage login: admin

System Initializing. Please wait to login...

Let’s start with a basic system configuration:

And let’s configure the VPN0 interface:

The VPN0 configuration requires some explanation:

• The tunnel-interface command configures the eth0 interface as a tunnel interface.

Before the configuration becomes active, we have to commit it:

• Cisco IOS router.

Notice how the # changes to a $. We are now in the home folder:

Let’s generate a private key and call it ROOT-CA.key:

vManage1:~$ openssl genrsa -out ROOT-CA.key 2048

vmanage:~$ cat ROOT-CA.pem

Take a look at the contents of our home folder:

The CSR is saved automatically in /home/admin as vmanage_csr.

vManage1:~$ openssl x509 -req -in vmanage_csr \

Use cat to see the output:

vmanage:~$ cat vmanage1.crt

• We created a new root CA:

vBond is the orchestrator in our SD-WAN network.

Let’s log in for the first time:

vedge login: admin

Let’s continue with the VPN0 interface: