ABC of Cisco SDWAN Viptela

Today’s WAN Challenges

 The Viptela Solution

Step 1
• Separate transport from the service side of the network.

Step 2
• Centralize routing intelligence and enable segmentation.

Step 3
• Secure the network automatically.
 The Viptela Solution

Step 4
• Managed via Central managed engine vManage.

Step 5
• Influence reachability through centralized policy.

Step 6
• Cloud readiness
Agenda
Viptela Solution Overview
Lab Setup
Secure Control Plane Bring up
Secure Data Plane Bring up
Device Configuration Lab
vManage Dashboard Tour
Basic Feature Templates
OMP
TLOC
Policy
QoS
Troubleshooting
2 Viptela Solution Overview
SD-WAN Transformation Architectural Principles
Solution Elements Secure Extensible Network

•vManage Network Management System (NMS)—The vManage NMS is a centralized

network management system that lets you configure and manage the entire overlay
network from a simple graphical dashboard.
•vSmart Controller—The vSmart controller is the centralized brain of the Viptela solution,
controlling the flow of data traffic throughout the network. The vSmart controller works
with the vBond orchestrator to authenticate Viptela devices as they join the network
and to orchestrate connectivity among the vEdge routers.
•vBond Orchestrator—The vBond orchestrator automatically orchestrates connectivity
between vEdge routers and vSmart controllers. If any vEdge router or vSmart controller
is behind a NAT, the vBond orchestrator also serves as an initial NAT-traversal orchestrator.
•vEdge Routers—The vEdge routers sit at the perimeter of a site (such as remote offices,
branches, campuses, data centers) and provide connectivity among the sites. They
are either hardware devices or software, called a vEdge Cloud router, that runs as a
virtual machine. vEdge routers handle the transmission of data traffic.
vEdge-1000 Hardware
vEdge-2000 Hardware
vEdge 100 Hardware
vEdge 100m Hardware
Of these four components, the vEdge router can be a Viptela hardware device or
software that runs as a virtual machine, and the remaining three are software-only
components. The software vEdge router, vManage NMS, and vSmart controller software
runs on servers, and the vBond orchestrator software runs as a process (daemon) on a
vEdge router.
OUR LAB SETUP
 Branch Side vEDGEs
BR1-VEDGE1
0 ge0/1 ipv4 172.16.3.2/30 Up Up -
0 ge0/2 ipv4 10.20.20.2/24 Up Up -
0 ge0/3 ipv4 10.10.10.1/24 Up Up -
0 system ipv4 10.3.0.1/32 Up Up -
10 ge0/0 ipv4 10.3.0.2/24 Up Up -
20 Loopb 0 ipv4 20.20.20.20/32 Up Up - BR2-VEDGE1
30 Loopb 1 ipv4 30.30.30.30/32 Up Up - 0 ge0/0 ipv4 172.16.4.2/30 Up Up -
512 eth0 ipv4 198.18.134.104/18 Up Up - 0 ge0/1 ipv4 100.64.4.2/30 Up Up -
0 system ipv4 10.4.0.1/32 Up Up -
10 ge0/2 ipv4 10.4.254.10/24 Up Up -
BR1-VEDGE2 512 eth0 ipv4 198.18.134.106/18 Up Up
0 ge0/1 ipv4 100.64.3.2/30 Up Up - -
0 ge0/2 ipv4 10.20.20.1/24 Up Up -
0 ge0/3 ipv4 10.10.10.2/24 Up Up -
0 system ipv4 10.3.0.2/32 Up Up -
10 ge0/0 ipv4 10.3.0.3/24 Up Up -
512 eth0 ipv4 198.18.134.105/18 Up Up -
3 Introduction to Hands-on Labs
Bringup Sequence of Events
The entire system bringup process includes these steps:
1.Install hypervisor (KVM) on the server (preconfigured).
2.Spin-up virtual machines on the server (preconfigured).
3.Install images for vManage, vBond, vSmart and vEdges on the virtual machines
(preconfigured).
4.Create a minimal configuration for vManage (Deploy vManage section).
5.Create a minimal configuration for vBond (Deploy vBond section).
6.Create a minimal configuration for vSmart (Deploy vSmart section).
7.Enable connectivity between Controllers (Enable Inter-Controller Connectivity section).
8.Generate CSRs for each Controller (Overlay Connections section).
9.Sign certificates to validate and authenticate the Controllers. (Certificate Signature section).
10.Create a minimal configuration for vEdges and establish IP connectivity into the WAN circuits
(Deploy vEdge section).
11.Verify that vEdge routers are able to reach the Controllers (vEdge Connections section).
12.Authenticate each vEdge router (Certify vEdges section).
13.Register each vEdge router with vManage (Register vEdge section).
14.Verify that the vEdge are up in the vManage dashboard (Verify SD-WAN Connectivity
section).
Virtual Fabric Bringup Secure Control Channel: Control Elements
 WorkFlow

After the Viptela devices boot and start

running with their initial configurations, the
second part of the bringup process begins
automatically. This automatic process is led by
the vBond orchestrator, as illustrated in the
figure below. Under the leadership of the
vBond software, the Viptela devices set up
encrypted communication channels between
themselves. Over these channels, the devices
automatically validate and authenticate each
other, a process that establishes an operational
overlay network. Once the overlay network is
running, the Viptela devices automatically receive and
activate their full configurations from the vManage server.
 Secure Control Channel: vEdge
Establish vEdge Router Identity
Routers Connection to vBond
Orchestrator
Secure Control Channel: vEdge Routers Connection
to vSmart Controller and vManage

vSmart-2# show certificate installed

vSmart-2# show control connections

Please show me these from
vManage as well …
WoW Done with Control Plan , Let’s
check Data Plan
Traffic Encryption Unbreakable
Traffic Privacy

 Each vEdge advertises its

local IPsec encryption key

 Symmetric encryption keys

used asymmetrically
Optimal Network Utilization for
Application Traffic Path MTU
Discover
 Automatic and proactive
Network
 Path MTU Discovery
Support for Host Path MTU
Discovery
 TCP MSS adjustment
Path Liveliness and Quality
Measurements Bidirectional
Forwarding Detection
 Detects loss, latency, jitter and
max-MTU for the IPSec tunnels
between all vEdge routers in a
given virtual topology
 Helps take forwarding decisions
based on actual underlying
transport performance
 Bi-directionally echoes liveliness
messages
- No BFD neighbors
- High solution scale
Data (IPSec) Connections

Let us check this Via vManage ….

Configuration Elements in a Device
System Configuration
• System ip address (Unique)
• Site-id
• System Organization name
(This needs to be the same for all )
• vBond ip address
• Host-name (Unique)
Device Specific configuration
(Interface level)
• Tunnel-interface
VPN 0
• Management Interface
VPN 512
• Service Interface
VPN 1 – 511
CLI Configuration Example for vSmart
vSmart# Config t (Start the configuration mode)
Entering the configuration mode terminal (System entering into configuration mode)
vSmart(config)#
(system ready to accept configuration commands)
vSmart(config)# system
(starting System Mode)
vSmart(config-system)#system-ip 12.12.12.12
(Assign system-ip- it should be a unique value)
vSmart(config-system )# site-id 10
(Site-id’s can be shared with other devices on site
vSmart(config-system)# commit
(write the configuration changes to device Memory)
Commit complete (system wrote all changes to memory)

Check this Via CLI …

vEdge Configuration Components
SYSTEM
Configuration
Parameters

Transport &
Service VPN
Parameters
Just For Fun …

Can you go to any Vedge and

change the GPS under system and
view it over vManage 

Check the restriction as well if any ..

Lab Time , lets check our lab setup
#trouble ticket 1
Device Configuration Lab Objectives
Learning Objectives : Outcomes – Understand the basic device parameters by
reconfiguring the vEdge device.

• Current State – One vEdge is down

Working :
• Log into vManage using admin as the user name and password
• Look at vManage dashboard to evaluate which devices are down.
• Once the devices are identified, build a plan on how to bring the devices up.
(Hint – look at other similar devices or modify the basic parameters)
• SSH into the vEdge. Bring up the device so that it becomes available on
vManage(Remember the 5 parameters)
• Success: Devices should be up with both control and data connections.
vEdge Status .. Some linux Skills 
Step 1: Please execute the following commands to see the interface and control
connections status.

Show interface description

Show control connections

‘Show control connection-history’ provides the time at which the control connections were
established.

Step 2- For in-depth troubleshooting, Debugs can be turned on to view packet exchanges,
events etc.
Access debugs under /var/log/vdebug and for system level /var/log/dsyslog

Step 3: Turn on ’debug transport’ Clear control connections Go to /var/log/vdebug to check

the debug information