Cisco SD-WAN & Security Bootcamp 20.1

CISCO SD-WAN & SECURITY
BOOTCAMP
SWITZERLAND
20. – 22.9.2021
MICHAEL BEHRINGER <MBEHRINGER@NIL.SI>

Training Objective and Prerequisites
Objective:
▪ Gain skills and knowledge to design, deploy and demonstrate Cisco SD-WAN solutions
▪ Self-sufficient POC/POV delivery to customers
Prerequisites:
▪ Solid understanding of WAN technologies
▪ Understanding of Cisco SD-WAN (aka Viptela) solution
Agenda
Day 1 Day 2 Day 3

• SD-WAN Architecture • Configuring Templates • Application-Aware Routing
• Terminology • Service-Side Routing • Internet Breakout and NAT
Morning • SD-WAN NAT-T • Policy Basics • SD-WAN Lawful Intercept
session • Deploying Management and • Overlay Security
Control Plane • SD-WAN Security Overview
• Application Aware Firewall
Lunch
• Cloud Deployment Specifics • Centralized Policies • IPS
• ZTP and PnP • Localized Policies • URL Filtering
• Deploying WAN Edge Devices • Quality of Service (QoS) • AMP
Afternoon • High Availability and Scaling • DNS Security and Umbrella SIG
session • Migration from Traditional WAN • Security Policies
to SD-WAN • APIs
• Licensing
• Resources
Introductions
▪ Your Name
▪ Role
▪ Skills and experiences
▪ Objective
Lab Topology
Device Interface Username Password

Jump Host RDP student C!sco123
Windows PC RDP student C!sco123
KVM Server Linx KVM root VMware1!
CSR1000v CLI admin Cisco123
Everything CLI / admin admin
else: Web
Org-name: NIL Lab
Everything
defaults
here
Cisco SD-WAN Solution Overview
vManage
APIs
Management/
3rd Party
Orchestration Plane
vAnalytics
Automation
vBond
vSmart Controllers
Control Plane
MPLS 4G
INET
WAN Edge Routers
Data Plane
Cloud Data Center Campus Branch SOHO
Orchestration Plane
vBond Orchestrator
vManage
Main Characteristics
APIs ▪ Orchestrates control and
management plane
3rd Party
vAnalytics
Automation ▪ First point of authentication
▪ Distributes list of vSmarts /
vBond vManage to all WAN Edge
routers
vSmart Controllers
▪ Facilitates NAT traversal
▪ Requires public IP Address
MPLS 4G
[could sit behind 1:1 NAT]
INET
▪ Highly resilient
WAN Edge Routers
▪ Multitenant or single tenant

Management Plane
vManage
vManage
APIs ▪ Single pane of glass for Day0,
Day1 and Day2 operations
3rd Party
vAnalytics ▪ Centralized provisioning
Automation
vBond
▪ Multitenant or single tenant
▪ Policies and Templates
vSmart Controllers ▪ Troubleshooting and Monitoring
▪ Software upgrades
MPLS 4G
▪ GUI with RBAC
INET
▪ Programmatic interfaces (REST,
WAN Edge Routers
NETCONF)
▪ Highly resilient
Control Plane
vSmart Controller
vManage
APIs ▪ Facilitates fabric discovery
3rd Party ▪ Dissimilates control plane
vAnalytics
Automation information between WAN Edge
vBond ▪ Distributes data plane and app-
aware routing policies to the
vSmart Controllers WAN Edge routers
▪ Implements control plane policies
MPLS 4G ▪ Dramatically reduces control
INET plane complexity
WAN Edge Routers ▪ Highly resilient

Data Plane
WAN Edge Router

vManage Main Characteristics
APIs
▪ WAN edge router
▪ Provides secure data plane with
3rd Party
vAnalytics remote WAN Edge routers
Automation
▪ Establishes secure control plane
vBond with vSmart controllers (OMP)
vSmart Controllers
▪ Implements data plane and
application aware routing policies
▪ Exports performance statistics
MPLS 4G
▪ Leverages traditional routing
INET
protocols like OSPF, BGP and
WAN Edge Routers
VRRP
▪ Support Zero Touch Deployment
Cloud Data Center Campus Branch SOHO ▪ Physical or Virtual form factor
(100Mb, 1Gb, 10Gb, 20Gb+)
Cisco Enterprise Routing Portfolio
Branch Aggregation
ISR 900 ISR 1000 ISR 4000 ASR 1000
• WAN and voice module flexibility • Hardware and software redundancy

• Fixed and fanless • Integrated wired and wireless • High-performance service with hardware
access • Compute with UCS E
• IOS Classic based assist
• Integrated Security stack
• PoE/PoE+
• WAN Optimization
vEdge 5000
vEdge 100 vEdge 1000 & 2000
SD-WAN
• Modular
• 4G LTE & Wireless • Fixed/Pluggable Module • RPS
Virtual and Cloud
• Service chaining virtual functions

CSR 1000V • Cisco DNA virtualization
Cisco ENCS • Extend enterprise routing, security
• Options for WAN connectivity
& management to cloud
• Open for 3rd party services & apps
Cisco SD-WAN Platforms
Rich Services
Interface Flexibility, Adv. Security, Rich Services, X-Domain
Basic Services Cisco ISR and ASR

Transport Independence, Cloud Management, Analytics
Cisco vEdge or ISR1K
Multi-Domain:
Adv Security1: Rich Services2: Caching,
Integrated Border for
App FW, IPS, URL-F, AMP DRE, Integrated Voice:
Campus and DC fabric
and ThreatGrid SRST, FXO, FXS
(SDA, ACI)
Routing: App-Aware Routing, Full Mesh, Cloud and Analytics: CloudOnRamp for Voice Optimization: FEC, Packet
Basic Security: Next Gen FireWall
Dynamic Routing IaaS and SaaS, vAnalytics Duplication, TCP Optimization3
(1) Advanced Security only on ISRs (2) Integrated Voice Support only on ISRs (3) Voice Optimization on ISR and vEdge Only
Key 20.1 Features
•
•
•
•
•
•
•
•
•
•
•
•
Key Cisco IOS XE Release 17.2 Features
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Programmatic APIs
REST
vManage Main Characteristics
▪ Programmatic control over all
APIs
aspects of vManage
vAnalytics
3rd Party administration
Automation ▪ Secure HTTPS interface
vBond ▪ GET, PUT, POST, DELETE
methods
vSmart Controllers
▪ Authentication and authorization
▪ Bulk API calls
MPLS 4G
▪ Python scripting
INET
WAN Edge Routers

Analytics
vAnalytics
vManage
▪ Cloud-based analytics engine
APIs
▪ Optional solution element
3rd Party
vAnalytics
Automation ▪ Analyze fabric telemetry
▪ Capacity projections
vBond
▪ SLA violation trends
vSmart Controllers ▪ Utilization anomaly detection
▪ Application QoE
4G
▪ Carrier grading
MPLS
▪ Data anonymization
INET
WAN Edge Routers ▪ Opt-in customer model

vAnalytics Main Characteristics
Network Centric Application/Flow Centric

▪ Site Availability ▪ Based on DPI and cflowd
▪ Network Availability ▪ Bandwidth Usage
▪ Site Usage Analysis ▪ Top sources, destinations apps
▪ Top sites by bandwidth consumption ▪ Per-Site basis
▪ Historical bandwidth consumption ▪ Application Performance
▪ Carrier Performance ▪ Application to tunnel binding and performance
▪ Approute stats on a per-carrier basis information
▪ Carriers health ranking ▪ Anomaly Detection
▪ Baseline of application usage
▪ Anomaly detection based on overall application
usage (by application family, by site)
Terminology
▪ System-IP – Unique identifier of an OMP Endpoint

▪ 32 Bit dot decimal notation (an IPv4 Address)
▪ Logically a VPN 0 Loopback Interface, referred to as “system”
▪ Organization-Name – Defines the OU to match in the Cert Auth Process

▪ OU carried in both directions for authentication control and WAN Edge Router nodes
▪ Site-ID – Identifies the Source Location of an advertised prefix

▪ Configured on every WAN Edge Router
▪ Does not have to be unique, but then assumes same location
Terminology (Cont.)
▪ Transport Side – WAN Edge Router Interface

connected to the underlay network
▪ Always VPN 0
▪ Traffic Always tunneled/encrypted, unless split- vSmart
tunneling is used
MPLS INET Transport

▪ Service Side – WAN Edge Router interface Side
connected to customer/user network
▪ VPN 1-511 (512 Reserved for OOB) WAN Edge
▪ Traffic forwarded as is from original source

Connected
Service
Static Side
Dynamic
(OSPF/EIGRP/BGP)
Terminology (Cont.)
▪ OMP – Overlay Management Protocol

▪ TLOC – Collection of entities making up a transport side connection
▪ System-IP: IPv4 Address (non-routed identifier)
▪ Color: Type of WAN Interface on local WAN Edge router
▪ Private TLOC: IP Address on interface sitting on inside of NAT
▪ Public TLOC: IP Address on interface sitting on outside of NAT
▪ Private/Public are the same if connection is not subject to NAT
▪ …
▪ vRoute – Routes learnt/connected on Service Side
▪ vRoute tagged with attributes as it is picked up by OMP
Transport Colors
▪ TLOC Color used as static identifier for:

▪ TLOC Interface on WAN Edge router
▪ Underlay network attachment
▪ The specific color used is categorized as Private or Public
▪ Private Colors [mpls, private1-6, metro-ethernet]
▪ All other colors are public [red, blue,…, public-internet,…]
▪ Private vs Public color is highly significant
▪ Color setting applies to:
▪ WAN Edge to WAN Edge Communication
▪ WAN Edge to Controller Communication
Colors Type Significance
Public IP/Port Private IP/Port
1 Private Color to Private Color

IPsec Tunnel / BFD Session
2 Private Color to Public Color

3 Public Color to Public Color

Transport Colors
T3 T4 T1 T2
Internet1 Internet
T3 T4 T1 T2
T1 T3
T3 Edge Edge
T1
Edge Edge T2 T4
T2 T4
MPLS
T1, T3 – Internet Color T2, T4 – MPLS Color

Internet2
T1, T3 – Internet1 Color T2, T4 – Internet2 Color
T1 T3 T2 T4
T1 T3 T2 T4
T1 T4 T2 T3
T1 T4 T2 T3
Color restrict will prevent attempt to establish IPSec tunnel to TLOCs with different color
Control Operation Walk-Through
Add vBondpushes
vManage and vSmart
serial
to vManage via
numbers to vBond and
NETCONF/YANG.
vSmart.
Temporary DTLS/TLS Tunnel CA
Transient DTLS/TLS Tunnel .crt
NETCONF/YANG
CSR CSR CSR
.crt
vBond vManage vSmart
vEdge vSmart
Fabric Operation Walk-Through
OMP Update:
▪ Reachability – IP Subnets, TLOCs
vSmart
OMP ▪ Security – Encryption Keys
DTLS/TLS Tunnel
▪ Policy – Data/App-route Policies
IPSec Tunnel
OMP OMP
BFD Update Update
Policies
OMP OMP
Update Update
vEdge vEdge
Transport1
TLOCs TLOCs
VPN1 VPN2 Transport2 VPN1 VPN2

BGP, OSPF, BGP, OSPF,
Connected, Connected,
Static A B C D Static
Subnets Subnets
Full Cone NAT
vEdge1 (192.168.1.1) NAT (Full Cone) vBond (203.0.113.1) vEdge2 (198.51.100.1)
Src=192.168.1.1:12346 Src=192.0.2.1:12346,
Dst=203.0.113.1:12346 Dst=203.0.113.1:12346
Src=203.0.113.1:12346 Src=203.0.113.1:12346
Dst=192.168.1.1:12346 Dst=192.0.2.1:12346
Src= 198.51.100.1:12346 Src=198.51.100.1:12346

Dst=192.168.1.1:12346 Dst=192.0.2.1:12346
▪ Any external host can send packet to internal address:port by sending packet to external
address:port once the mapping has been created
Restricted Cone NAT
vEdge1 (192.168.1.1) NAT (Restricted Cone) vBond (203.0.113.1) vEdge2 (198.51.100.1)
Src=192.168.1.1:12346 Src=192.0.2.1:5678,
Dst=203.0.113.1:12346 Dst=203.0.113.1:12346
Src=203.0.113.1:12346 Src=203.0.113.1:12346
Dst=192.168.1.1:12346 Dst=192.0.2.1:5678
Src=198.51.100.1:12346
Src=192.168.1.1:12346
Dst=198.51.100.1:12346
X Src=192.0.2.1:5678,
Dst=198.51.100.1:12346
Dst=192.0.2.1:5678
Src=198.51.100.1:12346 Src=198.51.100.1:12346
Dst=192.168.1.1:12346 Dst=192.0.2.1:5678
▪ Any external host can send packet to internal IP address if the internal device initiates a
connection to the external host using previously created address mappings
Port Restricted Cone NAT
vEdge1 (192.168.1.1) NAT (Port Restricted Cone) vBond (203.0.113.1) vEdge2 (198.51.100.1)
Src=192.168.1.1:12346 Src=192.0.2.1:5678,
Dst=203.0.113.1:12346 Dst=203.0.113.1:12346
Src=203.0.113.1:12446
X Dst=192.0.2.1:5678
Src=203.0.113.1:12346 Src=203.0.113.1:12346
Dst=192.168.1.1:12346 Dst=192.0.2.1:5678
▪ Similar to Address restricted cone NAT with ports added to the mapping
Symmetric NAT
vEdge1 (192.168.1.1) NAT (Symmetric) vBond (203.0.113.1) vEdge2 (198.51.100.1)
Src=192.168.1.1:12346 Src=192.0.2.1:5678,
Dst=203.0.113.1:12346 Dst=203.0.113.1:12346
Src=203.0.113.1:12346 Src=203.0.113.1:12346
Dst=192.168.1.1:12346 Dst=192.0.2.1:5678
Src=192.168.1.1:12346 Src=192.0.2.1:9012,
Dst=198.51.100.1:12346 Dst=198.51.100.1:12346
Src=198.51.100.1:12346 Src=198.51.100.1:12346
Dst=192.168.1.1:12346 Dst=192.0.2.1:9012
Src=198.51.100.1:12346
X Dst=192.0.2.1:5678
▪ Request from the same internal IP address and port to a specific destination IP address and
port is mapped to a unique external source IP address and port
▪ Only an external host that receives a packet from an internal host can send a packet back
NAT Traversal Combinations
Side A Side B IPSec Tunnel Status

Public Public
Full Cone Full Cone
Full Cone Port/Address Restricted
Port/Address Restricted Port/Address Restricted
Public Symmetric
Full Cone Symmetric
Symmetric Port/Address Restricted
Symmetric Symmetric
Direct IPSec Tunnel No Direct IPSec Tunnel (traffic traverses hub) Mostly Encountered
NAT Traversal – Dual Sided Full Cone
vBond
NAT Detection ▪ vBond discovers post-NAT public
IP1’ IP2’ IP and communicates back to
Port1 Port2 vEdges
vSmart
▪ STUN Server
▪ vEdges notify vSmart of their
post-NAT public IP address
NAT Filter: NAT Filter: ▪ NAT devices enforce no filter
Any source IP/Port Any source IP/Port
▪ Full-cone NAT
IP1’ Full Full IP2’
Port1 Cone Cone Port2
IP1 IP2’ IP1’ IP2

Port1 Port2 Port1 Port2
vEdge1 vEdge2 ▪ Note: vEdge establishes initial
Successful IPSec connection connection with vBond at each
bootup.
NAT Traversal – Full Cone and Symmetric
vBond
NAT Detection ▪ vBond discovers post-NAT public IP
IP1’ IP2’ and communicates back to vEdges
Port1 Port2 ▪ STUN Server
vSmart ▪ vEdges notify vSmart of their post-
NAT public IP address
▪ Symmetric NAT devices enforce
NAT Filter: filter
NAT Filter: Only from vBond
Any source IP/Port From IP1’/Port1 ▪ Only allows traffic from vBond
IP1’ IP2’ ▪ vEdge behind symmetric NAT
Symmetric
Port1
Full Cone
Port2 reaches out to remote vEdge
▪ NAT entry created with filter to allow
remote vEdge return traffic
IP1 IP2’ IP1’ IP2 ▪ Remote vEdge will learn new
Port1 Port2 Port1 Port2 symmetric NAT source port (data
vEdge1 vEdge2 plane learning)
Successful IPSec connection

Port Hopping
▪ Port Hopping
▪ Adds increments from standard port to facilitate NAT-traversal
▪ Port Offset
▪ Configure a static offset from the standard port (+-20)
▪ Defaults:
▪ Base port 12346
▪ Port offset: 0
Flexible Deployment Options
Cisco Cloud Ops MSP Ops Team Enterprise IT
Deploy Deploy Deploy
vManage vManage vManage
vSmart vBond vSmart vBond vSmart vBond

Viptela MSP Private
Cloud Cloud Cloud
vManage Deployment
NIC0 NIC1
▪ Cloud or on-premise deployment
▪ Separate interfaces for control and
management
▪ Separate VPNs for control and
management
▪ Zone-based security
VPN0 VPN512
▪ Minimal configuration for bring-up
▪ Connectivity, System IP, Site ID, Org-
Name, vBond IP
Control Management
Interface Interface
ESXi, KVM, AWS, MS Azure

vBond Deployment
NIC0 NIC1
management
management
VPN0 VPN512 ▪ Zone-based security
Name, vBond IP (local)
Control Management
Interface Interface

vSmart Deployment
NIC0 NIC1
▪ Virtual machine or container
management
VPN0 VPN512 management
▪ Zone-based security
Name, vBond IP
Control Management
Interface Interface

Overview of Installation Steps - vManage
1. Obtain software and verify system requirements

2. Deploy OVF Template
3. Perform installation and initial configuration (hostname, NTP)
4. Configure System-IP, Site-ID, Organizational Name,
5. If using local CA, install root CA chain, resync the vManage DB
Verifying vManage System Requirements
Devices vCPUs RAM OS Volume Database Bandwidth vNICs

Volume
1-250 16 32 GB 16 GB 500 GB, 25 Mbps 2

1500 IOPS
251-1000 32 64 GB 16 GB 1 TB, 100 Mbps 2

3072 IOPS
1001 or more 32 64 GB 16 GB 1 TB, 150 Mbps 2

3072 IOPS
▪ SSD required for normal vManage performance

▪ Private lab setup for learning purposes will work with less resources
Deploying OVF Template
Deploying OVF Template (Cont.)
Adding Additional Resources to the VM
Defining Disk Type and Specifying Capacity
Selecting Correct Virtual Drive Type
Adding Additional Interface
Performing Database Installation
Performing Initial vManage Configuration
▪ System settings
▪ Management access
Performing Initial vManage Configuration (Cont.)
▪ Transport interface for

initial system bring up
▪ Time must be
synchronized between
all components – use
NTP.
vManage System Settings (Org-Name and vBond)
vManage System Settings (Root CA Chain)
vManage System Settings (Smart Account)
Overview of Installation Steps - vBond

4. Configure System-IP, Site-ID, Organizational Name, vBond local role, disable tunnel-interface
5. If using local CA, install root CA chain
Verifying vBond System Requirements
Devices vCPUs RAM OS Volume Bandwidth vNICs
1-50 2 4 GB 8 GB 1 Mbps 2
51-250 2 4 GB 8 GB 2 Mbps 2
251-1000 2 4 GB 8 GB 5 Mbps 2
1001+ 4 8 GB 8 GB 10 Mbps 2
▪ Only SSD based volumes are officially supported

Performing Initial vBond Configuration
▪ Local keyword in vbond

command enables vBond role
▪ Enabling management access

in VPN 512
Configuring Transport Interface for Initial Bringup
▪ Disable Tunnel interface for

initial system bringup
▪ Alternative approach: allow
netconf service under tunnel
interface
Tunnel Interface Lockdown for Controllers
vBond
Authenticated
Sources
vSmart vManage
CPU
vEdge Control Plane Policing:
▪ 500pps per flow
▪ 10,000pps
vManage
Packet
Forwarding
Unknown vSmart
Note: vBond control plane policing
Sources is the same as vEdge
Other
Deny except:
DHCP, DNS, ICMP, NETCONF
* Can manually enable: SSH, NTP, STUN, HTTPS (vManage)

DDoS Protection for WAN Edge Routers
Authenticated
Sources
vSmart vManage
CPU
Implicitly SD-WAN IPSec
Trusted
Sources Control Plane Policing:
vEdge ▪ 300pps per flow
▪ 5,000pps
Packet
Explicitly Forwarding
Defined
Sources
Cloud Security
Deny except:
Unknown 1. Return packets matching flow entry (DIA enabled)
Sources 2. DHCP, DNS, ICMP
* Can manually enable: SSH, NETCONF, NTP, OSPF, BGP, STUN
Other
Overview of Installation Steps - vSmart

4. Configure System-IP, Site-ID, Organizational Name,
Verifying vSmart System Requirements
Devices vCPUs RAM OS Volume Bandwidth vNICs
1-50 2 4 GB 16 GB 2 Mbps 2
51-250 4 6 GB 16 GB 5 Mbps 2
251-1000 4 16 GB 16 GB 7 Mbps 2
1001+ 8 16 GB 16 GB 10 Mbps 2
▪ Only SSD based volumes are official supported

Performing Initial vSmart Configuration
▪ Initial system settings
▪ Setting up management
interface
Performing Initial vSmart Configuration (Cont.)
▪ Setting up VPN 0
interface for initial system
bring up
Local CA - Overview
▪ Several options for local Certificate Authority:

▪ Customer‘s existing CA infrastructure
▪ Microsoft CA most commonly used within enterprise environments
▪ CA build only for PoC purpose:
▪ XCA
▪ TinyCA
▪ OpenSSL
— OpenSSL library is part of most Linux distribution by default
— Can be used for certificate generation, signing CSRs, etc.
▪ If using subordinate servers, make sure you export/import the full root-ca chain.
Generating Key and Self-signed Certificate Using
OpenSSL
▪ ca.crt is our new root

certificate
▪ You need to import root-ca
on all controllers and
vEdgeCloud instances
▪ Use –days parameter to set
root-ca validity to desired
length (default: 30 days!)
Setting up Local CA for CSR Signing
▪ Create custom OpenSSL configuration file

▪ Specify paths for new certs, db, serial
numbers, etc..
▪ Describe path to private key and certificate
▪ Specify validity (in days)
▪ Specify policy
Defining Folder Structure
▪ Structure must reflect configuration

settings defined in the previous step.
Signing CSR
Cisco PKI Certificates Authorization
▪ Introduced starting from 19.1.0 controllers software

▪ Two options possible:
▪ Cisco-Automated controller certificate authorization
▪ Manual (suitable for software-based devices as well with no SUDI)
Cisco PKI Certificates Authorization (Cont.)
▪ Manual Certificate Authorization: PnP portal

Control Plane Whitelisting and Trust
• Enterprise certificates can be used for on-

premise controllers deployment
• Need to install root-chain
• Cisco certificates can be used for on-premise

controllers deployment
• Need to contact Cloud Ops for approval for
cloud deployment
Controllers Identity and Trust
Controller Certificate ▪ Controller identity is provided by the Cisco

signed certificate
▪ Alternatively can use Enterprise CA. Requires
Enterprise Root cert on all other controllers
and vEdge routers
Root Chain Root Chain ▪ Avnet Root chain to authenticate vEdge

routers
▪ Embedded into software
▪ Viptela Root chain to authenticate vEdge
Cloud routers
Root Chain
▪ Provided by vManage. Multiple if cluster.
▪ Cisco Root chain to authenticate other
controllers
▪ Embedded into software
▪ Alternatively can use Enterprise Root chain
cEdge Router Identity
▪ All platforms except: ASR1002-X / ENCS /

ACT2
Chip CSR1000v
▪ Each physical WAN Edge router is uniquely
identified by the chassis ID and certificate
serial number (SUDI certificate)
▪ Certificate is stored in on-board Anti
Counterfeit Trusted Chip (ACT2)
Device Certificate
▪ Installed during manufacturing process
▪ Unique private key embedded in ACT2
▪ Certificate is signed by Cisco root CA
Root Chain
▪ Trusted by Control Plane elements
▪ Key Use Cases

▪ Verifying the integrity of a device’s identity
▪ Onboarding a new device – Secure Zero
Touch Provisioning
▪ Secure enrollment within an organization's
PKI
cEdge Router Identity: Example
vEdge Router Identity and Trust
TPM
During Manufacturing
Chip ▪ Each physical vEdge router is uniquely
identified by the chassis ID and certificate
serial number
▪ Each vEdge device has a serial number, which
is a 40-byte number that is included in the
device's certificate.
Device Certificate ▪ Certificate is stored in on-board Temper
Proof Module (TPM)
▪ Installed during manufacturing process
Root Chain
▪ Certificate is signed by Avnet root CA
▪ Trusted by Control Plane elements
▪ Cisco root CA chain of trust is used to
validate Control Plane elements
▪ Alternatively, Enterprise root CA chain of
In Software trust can be used to validate Control Plane
elements
Software Devices Identity
Signed by vManage ▪ ASR1002-X / ISRv / CSR1000v / vEdge-Cloud

(If cluster, each
member can sign)
▪ OTP/Token is generated by vManage
▪ One per-(chassis ID, serial number) in the uploaded
vEdge list
▪ OTP/Token is supplied router in Cloud-Init
during the VM deployment or via CLI
Device Certificate
▪ vManage signs certificate(s) for the router post
OTP/Token validation
▪ If vManage cluster, each member can sign
Root Chain
▪ vManage removes OTP to prevent reuse
▪ Cisco/Symantec root CA chain of trust is used to
validate Control Plane elements
▪ Alternatively, Enterprise root CA chain of trust can
be used to validate Control Plane elements
In Software ▪ Can be provided in Cloud-Init (installed on
bootflash: or mounted as cdrom)
Controllers Identity
▪ Controllers identity is provided by the Cisco

or Symantec CA signed certificate
▪ Alternatively can use Enterprise CA. Requires
Enterprise Root CA chain on all other
controllers and vEdge routers
▪ Cisco Root CA or Enterprise CA chain is
used to authenticate cEdge routers
▪ Avnet Root CA or Enterprise CA chain is
used to authenticate vEdge routers
▪ vManage intermediate CA chain is used to
authenticate software devices
▪ running on each vManage server member of a
cluster. Enterprise CA can be used as well
Control Plane Establishment
vEdge Appliance ⟺ vBond

Validate: Root trust, vEdge
certificate serial Whitelist ▪ Signed certificates are exchanged
org-name
▪ vBond validates:
vManage
vSmart ▪ Vedge Chassis & Serial Number against Whitelist
vBond
vEdge ▪ Trust for signed vEdge cert. against root
Root IP addr
▪ Certificate serial numbers against authorized white-list
(from vManage)
vSmart/vMgr
IP addr ▪ Org name (received OU) against locally configured one
▪ vEdge validates:
▪ Trust for vBond cert against root
▪ Org name (received OU) against locally configured one
vEdge
▪ Provisional DTLS/TLS connection comes up between
Signed
vEdge and vBond
▪ vEdge is a client
DTLS
Validate: Root trust, ▪ vEdge IP registered to Vmanage & vSmart
DTLS/TLS
org-name
▪ vSmart & vManage IPs registered to vEdge
▪ Provisional Tunnel is torn down
Control Plane Establishment
vEdge Appliance ⟺ vSmart, vManage

Validate: Root trust, Validate: Root trust,
certificate serial
org-name
certificate serial
org-name
▪ Signed certificates are exchanged
vEdge vEdge ▪ vSmart and vManage validate:
Whitelist vSmart vManage Whitelist
▪ Trust for signed vEdge cert. against root
Root Root ▪ Certificate serial numbers against authorized
white-list (from vManage)
▪ Organization name (received certificate OU)
against locally configured one
▪ vEdge validates:
▪ Trust for vSmart and vManage certificate against
root
vEdge
▪ Organization name (received certificate OU)
Signed
against locally configured one
▪ Persistent DTLS/TLS connection comes up
DTLS between vEdge and vSmart/vManage
Validate: Root trust,
org-name DTLS/TLS ▪ vEdge is a client
Cisco PKI Certificates Authorization – Automatic
Automatic Certificate Authorization - verify the following conditions are met:

1. vManage version 19.1.0 or higher
2. vManage is configured to use Cisco-Automated controller certificates.
▪ Administration> Settings> Controller Certificate Authorization > Cisco-Automated
3. vManage has connectivity to apx.cisco.com on TCP port 443 via VPN 0.
4. Verify the Organization Name has been configured on vManage
5. SA/VA has been set up and defined the vBond controller profile on PnP portal.
6. CCO account associated to the SA/VA is configured in vManage:
▪ Administration> Settings> Smart Account Credentials.
▪ Optional: configure a shorter Retrieve Interval, so that vManage checks more often for available
certificates:
▪ Administration> Settings> Controller Certificate Authorization > Certificate Retrieve Interval
Cisco PKI Certificates Authorization – Automatic (Cont.)
▪ Automatic Certificate Authorization: vManage > Administration > Settings

Adding vBond to vManage
Adding vSmart to vManage
Generating CSRs
Cisco PKI Certificates Authorization - Manual
▪ Manual Certificate Authorization: vManage > Administration > Settings

Cisco PKI Certificates Authorization – Manual (Cont.)
▪ Manual Certificate Authorization: PnP portal

Installing Signed Certificate (Cont.)
Installing Signed Certificate (Cont.)
Configuring VPN 0 for Operation
▪ Under VPN 0 interface enable

tunnel-interface configuration on
all three controllers.
▪ vBond requires specification of

tunnel-interface encapsulation
type
Verifying Control Connections
On-Prem Controllers Communication
1. Controllers’ NATed public IPs injected into MPLS

2 WAN Edge
2. WAN Edge points to the vBond public NATed IP
Data Center
Core Switch 1 3. WAN Edge communicates with vSmart and
vManage using public NATed IP addresses
MPLS 3 INET
2 WAN Edge
Firewall Data Center
DMZ Core Switch 1
MPLS 3 INET
vBond vSmart vManage 1:1 1:1 1:1

Firewall NAT NAT NAT
DMZ
1. Controllers’ public IPs injected into MPLS
2. WAN Edge points to the vBond public IP
3. WAN Edge communicates with vSmart and
vManage using public IP addresses vBond vSmart vManage
Troubleshooting Control Connections
Importing WAN Edge List
Importing WAN Edge List (Cont.)
Controller Deployment Models
• • •
• •
•
•
• •
Cloud Hosted Deployment - Recommended
▪ vSmart / vManage configured with elastic IP of

vBond to force communication to pass though
IGW (recording Private/Public)
▪ vManage / vSmart communicate locally on the
WAN segment after discovering each other
using vBond
▪ vManage / vSmart having different site-ids,
communication via IGW
▪ Controllers in other zones register with vBond
and are dynamically discovered
Controller Deployment in AWS
▪ vManage/vSmart are configured with elastic IP of vBond to force

communication to pass though IGW (recording Private/Public)
Cloud-Hosted Deployment
▪ Recommended mode of deployment

▪ Ease of deployment – Cisco orchestrated
▪ No On-Prem design considerations
▪ Easy to scale and to deliver redundancy / HA
▪ Requirements
▪ Internet connectivity from every site (unless using DirectConnect)
▪ If using MPLS Transport, Internet breakout required for Control Plane
▪ Challenge
▪ With a single Internet connection, no DirectConnect or Internet Breakout from MPLS – No Controller
Redundancy
Requirements for ZTP/PnP
▪ You will need Dynamic Host Configuration Protocol (DHCP) with DNS and a default gateway
for Cisco Network Plug and Play (PnP).
▪ An Internet connection should allow communication to devicehelper.cisco.com using ports 80
and 443 for PnP.
▪ Smart Licensing is required in order to use PnP during the software upgrade from standard
Cisco IOS XE to the SD-WAN Cisco IOS XE software image.
▪ You will need the router’s serial number and Secure Unique Device Identifier (SUDI). Some
devices, such as the ASR-1002-X and the ISRv virtual router, DO NOT have a SUDI.
▪ Note that the serial number displayed with “show license udi” can be different from the SUDI
displayed with “show crypto pki certificates.” You will need both for PnP.
What is SUDI?
▪ Secure unique device identification (SUDI) is a Cisco Trust Anchor Technology designed to
give customers the confidence that the product is genuine.
▪ The SUDI is part of the device certification, which will be used to authenticate and identify the
device, and is utilized by the DeviceAuthentication PnP Service.
▪ When a PnP Server wants to authenticate a device, it will send a Device-Authentication work-
request to the PnP Agent on that device. The Agent will rely on the SUDI API (platform
dependent implementation) to generate the work-response.
Zero Touch Provisioning – vEdge HW Appliance
Control and Policy

Elements
1 2 ▪ Delivered as-a-Service
3 4 5 ▪ Identities associated with overlay at
time of ordering
▪ Option1:
Full Registration
and Configuration ▪ DHCP on Transport Side (WAN)
▪ DNS to resolve ztp.viptela.com*
▪ Option2:
▪ Discover local addressing via ARP
▪ Google DNS: resolve ztp.viptela.com*
vEdge Router
Zero Touch Provisioning – vEdge Cloud
Control and Policy

vManage Elements
1
Cloud-Init
VM
Provisioning
3
5
Tool
2 Full Registration and
Configuration
4
▪ Assumption:
▪ DHCP on Transport Side (WAN)
vEdge Cloud
Zero Touch Provisioning - WAN Edge Router
▪ The PnP Connection Manager can

Control and Policy redirect to cloud-hosted or On-
Elements Prem controllers.
Connection ▪ New devices are linked to
Manager
organization using the Smart
Account when placing order.
▪ Additional devices can be
2 associated with the customer using
3 5 the PnP Connect portal on
Full Registration and https://software.cisco.com.
Configuration
1
4
▪ Assumption:
▪ DHCP on Transport Side (WAN)
▪ DNS to resolve
WAN Edge devicehelper.cisco.com
PnP Steps
PnP Steps (Cont.)
Here is the summary of all steps:

▪ Cisco IOS XE router contacts PnP Connect via devicehelper.cisco.com, presents its serial file,
and gets SD-WAN-related information (vBond IP, organization name, etc.).
▪ Cisco IOS XE router contacts vBond over a secure tunnel; after authentication, vBond sends the
vManage IP address to the Cisco IOS XE router.
▪ Cisco IOS XE Router contacts vManage over a secure tunnel; after authentication, vManage
sends the full configuration to the Cisco IOS XE router.
▪ Cisco IOS XE router contacts vSmart over a secure tunnel; after authentication, it will join the
SD-WAN fabric.
ZTP Orchestration Overview
Enabling On-Prem Enterprise ZTP Server
Additional on-prem vBond server can be configured to perform dedicated ZTP role. Required
steps:
1. Activate ZTP role
▪ vBond(config)# system vbond ip-address local ztp-server
2. Obtain signed certificate by trusted CA (Cisco)
3. Upload the chassis CSV file
▪ vBond# request device-upload chassis-file path
4. Configure local DNS server to resolve ztp.viptela.com with vBond IP
5. Define device templates
Example: ZTP CSV File
vBond# vshell Each row in the CSV file must

vm4vBond~$ cat ztp-chassis-file
12345,6789,valid,10.1.14.1,12345,viptela, contain the following
vBond:~$ exit information for each vEdge
exit
vBond request device-upload chassis-file /home/admin/ztp-chassis-file router:
Uploading chassis numbers via VPN 0
Copying ... /home/admin/ztp-chassis-file via VPN 0
▪ Chassis number
Successfully loaded the chassis numbers file to the database. ▪ Serial number
Uploading the serial numbers to the vedge-list ... ▪ Validity (either valid or
Uploading serial numbers via VPN 0
Copying ... /home/admin/vedge_serial_entries via VPN 0
invalid)
Successfully loaded the vEdge serial numbers ▪ vBond IP address
vBond# show ztp entries
ROOT ▪ vBond port number
CHASSIS SERIAL VBOND ORGANIZATION CERT
INDEX NUMBER NUMBER VALIDITY VBOND IP PORT NAME PATH (optional)
------------------------------------------------------------------------
1 12345 6789 valid 10.1.14.1 12346 NIL Training
▪ Organization name
▪ Path to the root
certification (optional)
ZTP Device Template
Overview of Installation Steps - vEdgeCloud

3. Perform initial configuration (hostname, NTP, system IP, site-id, Organizational Name, VPN0
interface)
5. Active vEdgeCloud by enrolling it into vManage
Verifying vEdgeCloud System Requirements
Performance vCPUs RAM Disk Volume vNICs
500 Mbps 2 2 GB 10 GB Min 3, max 8
1 Gbps 4 2 GB 10 GB Min 3, max 8
2 Gbps 8 2 GB 10 GB Min 3, max 8
Supported hypervisors:
▪ VMware ESXi 5.5 & 6.0
▪ KVM
▪ AWS
▪ Azure
Deploying vEdgeCloud OVF
vNIC Interface Default VPN DHCP State

enabled
1 eth0 512 Yes Enabled

2 ge0/0 0 Yes Enabled
3 ge0/1 No Disabled
4 ge0/2 No Disabled
Performing Initial vCloudEdge Configuration
▪ Setting up management
interface
▪ Initial system settings

Performing Initial vCloudEdge Configuration (Cont.)
▪ Setting up VPN0 interface

▪ Transfer root-ca (SCP,
copy/paste)
▪ Install root-ca
Activate vEdgeCloud/CSRv
▪ Generating bootstrap configuration to be able to extract UUID number and token for
vEdgeCloud activation
Activate vEdgeCloud/CSRv (Cont.)
▪ Local properties before vEdgeCloud activation

▪ Activating uuid and token
▪ Verification
Activate vEdgeCloud/CSRv - Verification
Connecting to Management Console
▪ vEdge 100 series support USB console port

▪ Default speed = 115200
Accessing the Console - Windows
▪ Use Device Manager to determine

which COM port is being used for
USB serial port.
▪ Use favorite terminal client, specify
correct COM port and speed.
Accessing the Console - Mac
▪ Installation of USB serial driver is needed

▪ Link to docs site to download drivers
▪ Launch Terminal utility
▪ From a terminal shell, access the console port with this command:
▪ $ screen /dev/tty.usbserial* 115200,cs8
cEdge Code Improvement
▪ Single image for Autonomous and Controller modes (17.2)

▪ Short term plan
▪ Autonomous mode (default)
▪ Controller mode – SDWAN
▪ Long term vision – SDWAN as configuration as opposed to mode.
▪ To have the SDWAN feature enabled/disabled at runtime like all other features.
▪ Prevent divergence, code, development and test duplication
▪ Each platform has cEdge and non-cEdge image variants
Unified Image (17.2) – Device Modes
Autonomous Mode (Default mode) Controller Mode
• IOS Source of Configuration • Source of configuration is Confd/CDB
• Configuration via IOS CLI, DMI and many • Only Yang based configuration (vManage,
other forms Yang-CLI)
• SDWAN is supported only in this mode
▪ Modes are inter-changeable via CLI

▪ Configuration will be lost/wiped (IOS or CDB) and services will be disrupted.
▪ Reload is required & start with Day-0 onboarding
Autonomous and Controller Mode
Feature Autonomous Mode (Default mode) Controller Mode
• Command Line Interface (CLI) • YANG-based configuration

• NETCONF • Cisco vManage
• NETCONF
• •
• •
•
•
• •
• •
• •
• •
• •
Deployment Workflow
Plug and Play Onboarding Workflow:

1. Place an order for the device in Cisco Commerce with Smart Account and Virtual Account
details of the customer.
2. The device information from Cisco Commerce like Device serial number, Smart Account, and
Virtual Account are added to the Plug and Play portal.
3. Add a vBond controller profile into the Plug and Play (PnP) portal for the same Smart
Account and Virtual Accounts.
4. Associate the new device to the vBond controller profile manually.
5. PnP sends all relevant information including vBond details, device serial number, organization
name, and network ID to Zero Touch Provisioning (ZTP).
6. Download the device serial number file (provisioning file) from PnP and upload it to Cisco
vManage. The devices are now available on Cisco vManage. You can also use the Sync Smart
Account option on vManage to sync the device with your virtual account and populate the
device in Cisco vManage.
Deployment Workflow (Cont.)
Boot up Mode Deployment On-boarding vBond Discovery Process Mode Change

Mode agent Orchestrator
Cisco DNA No Mode change
Deployment Steps Overview
▪ Prerequisites
▪ Infrastructure
▪ Pre-provisioning
▪ Software image upload
▪ Reboot
▪ Verification
Prerequisites
1. Supported router models, memory and interface modules

2. ROMMON version
3. Serial Number & SUDI, Smart Account for PnP
4. Download SD-WAN Software Image
Obtaining Chassis and Board ID Serial Numbers
If IOS-XE >16.6.1
▪ show crypto pki certificates
If IOS-XE SD-WAN
▪ show sdwan certificate serial
PnP Portal
▪ https://software.cisco.com
▪ Smart Account is required
PnP Portal – Adding Controller Profile
PnP - Adding Controller Profile Settings
PnP - Adding WAN Edge Devices
PNP - Providing Device Details
PnP – Downloading vManage License File
Converting ISR into SD-WAN WAN Edge Device on IOS
XE 17.2
▪ Verify software version is 17.2 or greater

▪ Change operation mode with „controller-mode enable“ command
▪ Device reloads and starts PnP Process
Converting ISR into SD-WAN WAN Edge Device before
IOS XE 17.2
▪ IOS XE version on device is <17.2

▪ Transfer IOS-XE SD-WAN image (USB, FTP/TFTP)
▪ Erase existing startup config (write erase)
▪ Set bootvar (make sure you remove previous entry)
▪ 2 reboots needed:
▪ 1st reboot - to switch from IOS XE to SD-WAN image
▪ 2nd Reboot: clearing internal IOS XE information
Converting ISR into SD-WAN WAN Edge Device
▪ Performing second reboot - clearing internal IOS XE information

▪ Use default credentials admin/admin to access the system

▪ For manual on-boarding without ZTP stop PnP process
▪ If PnP is not disabled

Performing Initial Configuration – System Settings
Performing Initial Configuration – WAN Interface
Tunnel Interface Mapping
▪ Tunnel Name = (Interface number without slashes) + (1000*subif number if subif present) +
(5000000 if serial interface) + (channel group * 1000)
▪ vManage templates automatically calculate needed tunnel number
Verification Commands
Installing Local Root CA
Checking Control Connections
▪ Control Up: Total number of

devices with the required number of
operational control plane
connections to a vSmart controller.
▪ Partial: Total number of devices
with some, but not all, operational
control plane connections to
vSmart controllers.
▪ Control Down: Total number of
devices with no control plane
connection to a vSmart controller.
Checking Control Connections on Individual Device
▪ If the device has multiple interfaces,

vManage NMS displays a graphical
topology of all control connections
for each color.
▪ Click the arrow to the left to view
the control connections for that
TLOC color.
▪ Click the checkbox to the left to
select and deselect control
connections.
Possible Causes for Control Connection Failure
• •
• •
• •
•
DTLS Connection Failure
• •
• •
•
•
Disabled TLOC
Probable causes:
▪ Clearing of Control Connections
▪ Changing the color on TLOC
▪ Change in System IP
▪ Change in any of the configs mentioned in the system block or in the tunnel properties
Challenge Response Rejected by Peer
▪ If the serial number is not present on the controllers for a given vEdge, the control connections
will fail
▪ Verify this by send to controllers option from vManage and / or show controllers [ valid-
vsmarts | valid-vedges ].
Certificate Verification Failed
▪ Certification verification failure is when certificate cannot be verified with the root cert
installed.
Organizational Name Mismatch
▪ For a given a overlay, the Org. Name has to match across all the controllers and vEdges so that
control connections can come up.
▪ If not, you will see “Certificate Org. name mismatch” as seen below in the “show control
connections” output.
Certificate Revoked/Invalidated
▪ The certificate will be revoked in case of controllers or vEdge serial number is invalidated
High Availability and Redundancy Overview
Site Redundancy Transport Redundancy
MPLS INET MPLS INET
VRRP OSPF/ OSPF/

BGP BGP
Network/Headend Redundancy Control Redundancy
vSmart Controllers
MPLS Control
Data
Center
INET Data MPLS
Site
INET
Redundancy - Site with LAN Bridging
▪ Redundant vEdge routers

SD-WAN ▪ VRRP between vEdge routers
Fabric ▪ Operates per-VLAN
▪ VRRP Active vEdge router responds to
ARP requests for the virtual IP
▪ In case of failover, new VRRP Active
A S A S
vEdge A VRRP Grp 1 vEdge B vEdge router sends out gratuitous ARP
to update ARP table on the hosts and
VRRP Grp 2 mac address table on the intermediate
VLAN 1 L2 switches
VLAN 2
Host Host
Redundancy - Site with LAN Routing
▪ Redundant vEdge routers

SD-WAN ▪ OSPF/BGP between vEdge routers
Fabric and site router(s)
▪ Bi-directional redistribution
between OMP and OSPF/BGP
▪ Loop prevention
vEdge A vEdge B ▪ Multipathing for remote
destinations across SD-WAN
Fabric
Site Router Site Router ▪ Can manipulate OSPF/BGP to
prefer one vEdge router over the
other
Host
Redundancy – Meshed Transports
▪ vEdge routers are directly connected to all the transports

▪ SD-WAN tunnels are built through all directly connected transports
Circuit Failure Transport Failure Router Failure
MPLS MPLS Internet MPLS

Internet Internet
Site Network Site Network Site Network

Extended Transports – TLOC Extensions
▪ Each vEdge router is connected to a given transports

▪ SD-WAN tunnels are built through local and remote transports
Circuit Failure Transport Failure Router Failure
Internet MPLS Internet MPLS Internet MPLS
Site Network Site Network Site Network

TLOC Extension Configuration Example
vpn 0 ip route 10.5.52.52/32 100.65.51.1 vpn 0

interface ge0/0 interface ge0/0
description MPLS tunnel description INET tunnel
ip address 100.65.51.1/30 ip dhcp-client
tunnel-interface Add route to reach vedge-52 nat
encapsulation ipsec mpls tunnel end-point !
color mpls restrict tunnel-interface
! encapsulation ipsec
interface ge0/2 color biz-internet restrict
MPLS INET
description INET tunnel !
ip address 10.5.51.51/24 interface ge0/2
! ip address 10.5.51.52/24
tunnel-interface tloc-extension ge0/0
encapsulation ipsec preference 100 no shutdown
color biz-internet restrict !
max-control-connections 1 ge0/0 ge0/0 interface ge0/3
! 100.65.51.1/24 dhcp description MPLS tunnel
interface ge0/3 ip address 10.5.52.52/24
ge0/2 ge0/2
ip address 10.5.52.51/24 tunnel-interface
10.5.51.51/24 10.5.51.52/24
tloc-extension ge0/0 encapsulation ipsec
no shutdown color mpls restrict
! max-control-connections 1
ip route 0.0.0.0/0 100.65.51.2 !
ge0/3 ge0/3 ip route 0.0.0.0/0 10.5.52.51
ip route 0.0.0.0/0 10.5.51.52
10.5.52.51/24 10.5.52.52/24
vedge-51 vedge-52
ge0/1 ge0/1
100.5.5.51/24 100.5.5.52/24
Redundancy – Path and Headend
▪ vEdge routers leverage BFD for

detecting end-to-end tunnel liveliness
Data Center
▪ If intermediate network path through
the SD-WAN fabric fails or if the
remote-end vEdge router (e.g. data
center) fails, BFD hellos will time out
and remote site vEdge router will bring
Internet MPLS down its relevant IPSec tunnels
▪ Traffic will be rerouted after the failed
condition had been detected
▪ BFD timers can be tweaked for faster
detection
Remote
Site
SD-WAN Controller Redundancy
vBond vBond ▪ No Shared State

▪ DNS FQDN to cover multiple vBonds (e.g.
No Shared State vbond.enterprise.com)
Active Active
▪ OMP Mesh amongst all active vSmarts

vSmart vSmart
▪ vSmart dynamic discovery via vBond
OMP ▪ No configuration Required
Active Active
vManage vManage ▪ Active / Standby Cluster Architecture

▪ Clusters are maintained from within
DB Sync vManage
▪ Database synchronization required b/t
Active Standby Active/Standby
Redundancy – vSmart Control Controllers
vSmart ▪ vSmart controllers exchange

Controllers OMP messages and they have
Control Plane identical view of the SD-WAN
Data Plane fabric
▪ vEdge routers connect to up to
three vSmart controllers for
Cloud redundancy
Data Center
▪ No impact as long as vEdge
routers can connect to at least
one vSmart Controller
Data Center
MPLS 4G ▪ If all vSmart controllers fail or
INET become unreachable, vEdge
routers will continue operating
Small Office on a last known good state for a
Home Office configurable amount of time
Campus ▪ No changes allowed
Branch
Redundancy – vManage System
vManage ▪ vManage servers form a cluster for

Cluster redundancy and high availability
Management Plane ▪ All servers in the cluster act as active/active
Data Plane nodes
▪ All members of the cluster must be in the same
DC / metro area
Cloud ▪ For geo-redundancy, vManage servers
Data Center operate in active/standby mode
▪ Not clustered
▪ Database replication between sites
Data Center
MPLS 4G
▪ Loss of all vManage servers has no impact on
INET
fabric operation
▪ No administrative changes
Small Office
Home Office ▪ No statistics collection
Campus
Branch
Controllers Connectivity and Scale
5400
vBond vSmart Con* vManage
1500 1500 1500 2000 2000 2000
Con Con Con 5400 5400 Dev Dev Dev
Con* Con*
x6 x6
x20
FQDN Networked Cluster
Hash
DNS 1 permanent connection Hash
per-transport
1 transient connection 1 permanent connection
WAN Edge * 8 Core with minimum 17.1 code

Controllers Regional Affinity (Optional)
AMER EMEA
vManage vBond Group2
Group1 vSmart
vSmart APAC
vBond Group3
vBond
Group 2,1
vSmart
FQDN AMER Group 1,2 FQDN EMEA
WAN Edge Group 3,2
WAN Edge FQDN APAC
WAN Edge
SD-WAN Controller Large Scale Deployment
Endpoint Affiliation using Affinity

vSmart:
vSmart:
system
system
Controller-group-id 2
vSmart:
system
EMEA
USA
system
max-omp-sessions 2
Controller-group-list 1 2 APAC
!
vpn 0 Affinity Logic
Interface ge0/0 1) Attach to # of vSmarts up to max-omp-sessions
2) Attach to # of vSmarts up to max-control-connections per TLOC
tunnel-interface
3) Prefer Group 1 and continue with Group 2 as allowed by session budget
max-control-connections 2
4) Never attach to Group 3
exclude-controller-group-list 3 5) If Group 1 and 2 are unavailable try any other available group except for 3
!
!
Data Plane Scale
250/1500/6000* 250/1500/6000* 250/1500/6000*

Tunnels Tunnels Tunnels
Equal Cost (x16)
T1 T2 Tn
ECMP
vEdge100 – 250
vEdge1000 - 1500
vEdge2000/5000 - 6000
IOS-XE SDWAN Expected Performance
No magic here
vManage ▪ It’s still the same forwarding
plane doing the work
▪ SDWAN XE calls on same
features as Cisco IWAN = same
performance impact.
▪ Expect performance in line with
vBond IWAN numbers
vSmart Controllers
MPLS 4G
INET
Routers with vEdge capability

Migration Sequence
Step 1: Choose the SD-WAN Controllers Deployment
model
On Premise Cisco Hosted

• Customer managed WAN • Customer managed WAN
• Mgmt-Plane: Customer • Mgmt-Plane: Cisco
• Control-plane: Customer • Control-plane: Cisco

Step 2: DC Migration
Regional DC1 CDC
Main DC - ZDC
DC Core DC Core
SW1 SW2
CDC-BR1 CDC-BR2 vBond, vSmart, vManage

SD-WAN Edge
PFR-MC
CE1 CE2
MPLS Internet
SDWAN Overlay Legacy Overlay

Legacy Sites
Step 2: DC Migration Detail
Non-SDWAN Site Migrated Site
MPLS Internet
▪ SD-WAN to non-SDWAN
Legacy
interoperability
SD-WAN
Overlay
Overlay ▪ DC becomes hub
▪ Per VRF routing
DC/non-SDWAN SD-WAN
▪ Core learns legacy
CE1
prefixes prefixes CE2 overlay routes and SD-
(OMP) (OMP)
WAN overlay routes
Non-SDWAN prefixes ▪ Route redistribution both
(OSPF/BGP)
VPN0 VPN0 ways
OMP-to-
DC/SDWAN
prefixes VPN1-N VPN1-N BGP/OSPF
(OSPF/BGP)
Core Switches
Step 3: Branch Migration
Traffic Flow Use Cases
▪ Between Migrated and Legacy Branches in Different Regions

▪ Between a Migrated Branch and DC

▪ Between Migrated Branches in Different Regions

▪ Between Migrated & Legacy Branches in Different Region via SD-WAN Overlay
Templates - Overview
▪ Templates consolidate configuration of SD-WAN devices

▪ Only one device template can be attached to individual device
▪ Same template can be attached to multiple devices
▪ Types:
▪ Device templates
▪ Feature templates
▪ CLI Templates
▪ Templates utilize variables:

▪ Default
▪ Global
▪ Device specific
▪ Defined via CSV
▪ Manually through UI
CLI Templates
Benefits:
▪ Reuse any Cisco vEdge-specific vManage feature templates for Cisco IOS XE Routers.
▪ Make multiple changes to a CLI template in a single edit.
▪ Use a single configuration across multiple devices of the same device models.
▪ Define custom length for variables in CLI Templates.
▪ Use any existing IOS-XE device intent configuration as input for CLI template.
▪ Content of a CLI template can be used across multiple IOS-XE device types (common CLIs like
VPN, VPN interface, BGP, OSPF and so on).
Limitations:
▪ Do not include commands for auxiliary ports, such as line aux 0.
Templates Migration
▪ Before Cisco IOS XE Release Amsterdam 17.2.1r, the same template was shared for both device
types:
▪ Cisco vEdge and Cisco IOS XE SD-WAN.
▪ Specified using Cisco vEdge commands.
▪ Converted, if required, for Cisco IOS XE devices.
▪ Some functionality was unavailable on Cisco IOS XE SD-WAN.
▪ Before Cisco IOS XE Release Amsterdam 17.2.1r, there are two types of shared templates:
▪ Shared feature templates: If you specify a Cisco IOS XE SD-WAN device when creating a feature
template, a shared feature template is created.
▪ Shared device templates: A device template that contains a shared feature template.
▪ In Cisco IOS XE Release Amsterdam 17.2.1r and onwards, the feature templates have been
separated for Cisco vEdge devices and Cisco IOS XE SD-WAN devices.
▪ Enable support for additional features.
▪ Cisco vManage can migrate your older, shared feature templates to the new templates.
List of Migrated Templates
List of Migrated Templates (Cont.)
Template Migration
Template Migration (Cont.)
Configuration Templates Structure
Features
System
Default Setting
Security System default value
vManage
Transport Global Variable
Same value on all attached devices
Service Device Specific variable

Per-device value using CSV or manual input
Routing
WAN Edge
Centralized Device Configuration via Templates
WAN Edge
▪ Centralized Feature Templates

▪ Configuration with variables
▪ Self-recover on misconfiguration
Feature Templates
▪ Device model specific

▪ Represent individual building blocks of configuration
▪ Attached to devices using Device templates
Device Templates
Device Templates (Cont.)
▪ Define device’s complete operational configuration

▪ Device Template references a number of feature templates
▪ Device Model specific – individual template for each device type
▪ No Device Templates are defined in new installation by default.
Creating a Device Template – Basic Information
Creating a Device Template – Basic Information (Cont.)
Creating a Device Template – System Settings
Creating a Device Template – Editing Templates
▪ Once feature template is defined through device template, you can only view it. For editing
navigate to Feature Templates.
BFD Custom Template
•
•
•
•
•
•
OMP Custom Template
•
•
•
Transport & Management VPN Templates
VPN Template
VPN Interface - Template
VPN Interface - Template (Cont.)
Service VPN Template
Service VPN Template (Cont.)
Applying the Device Template
Applying the Device Template – Attaching Devices
▪ Only devices that match device type are displayed

Applying the Device Template – Defining Variables
▪ Use CSV download icons to perform bulk edit

▪ Use Edit Device Template to edit parameters for individual device
Applying the Device Template – Manual Device Edit
Applying the Device Template – Bulk Edit
▪ CSV can be opened with favorite spreadsheet tool (Excel, Calc, etc)
▪ Values are separated using commas
▪ All previously defined variable values are preserved
Applying the Device Template – Uploading CSV
▪ When saving CSV file make sure you preserve the format
▪ Use upload button to import the configured values
Applying the Device Template – Provisioning
Example: Error in Variable Value
▪ IP address value must include subnet mask

▪ 172.16.0.21 == invalid value
▪ 172.16.0.21/16 == acceptable value
Validating Configuration Before Provisioning
Configuring Device Rollback Timer
Template Deployment Status
Configuration Mode: CLI vs vManage
Editing Device Templates
CLI Add-On Templates
▪ Any text can be replaced with a variable

▪ Allows additional configuration for features with no feature templates
vSmart Device Templates
▪ Applying Device Template to

vSmart converts it into
vManaged mode
▪ vManaged mode is required for
centralized policy deployment
▪ Alternative: CLI template
Template Creation Guidelines
▪ Plan for template creation and test out features to be deployed

▪ Allows for the optimization of template structure and maintenance
▪ Use a simple ”bootstrap” template for distributed devices that are not yet in production
▪ The device is then in a known state and vManaged
▪ Tracking events is easier if a logical name is applied
▪ The local configuration of the device can’t be changed
▪ The device can be moved to production (or any other state) at will from vManage
▪ The template can be changed at any time from within vManage
▪ Template Variables can be managed in several different ways:
▪ Entered manually at time of template attachment
▪ Stored in a .csv file that is referenced at time of template application
▪ Using the REST API (possibly in conjunction with other platforms such as Infoblox)
Routing Overview
Dynamic
Dynamic (OSPF/EIGRP/BGP) ▪ Supported dynamic routing
(OSPF/EIGRP/BGP)
Static
protocols on service side:
Static ▪ OSPF
Connected
Connected ▪ EIGRP
Site2 ▪ BGP
vSmart ▪ OMP learns and translates
Site1 routing information across
the overlay:
OMP ▪ OMP routes (vRoutes),
▪ TLOC routes,
Site3
▪ network service routes.
Site4
Connected
▪ OMP performs path selection,
Connected
loop avoidance and policy
Static implementation
Static Dynamic
Dynamic (OSPF/EIGRP/BGP)
(OSPF/EIGRP/BGP)
OMP Routes
▪ OMP automatically redistributes the following service side route types:

▪ Connected
▪ Static
▪ OSPF intra-area routes
▪ OSPF inter-area routes
▪ Redistribution of OSPF external and BGP routes requires explicit configuration
▪ For each service side VPN you individually configure the interfaces and routing protocols that
operate in that VPN.
OMP Best-Path Algorithm and Loop Avoidance
Next hop TLOC is reachable ▪ vSmart will advertise 4

ECMP paths by default
Prefer vEdge-sourced route over vSmart-sourced route ▪ Max 16 paths
▪ vSmart can send
Prefer OMP route with lower admin distance backup path for faster
reroute on vEdge
Prefer OMP route with higher route preference
Prefer OMP route with higher TLOC preference
Prefer highest origin

(Connected, NAT, Static, eBGP, OSPF Intra, OSPF Inter,
OSPF External, iBGP, Unknown/Unset)
Prefer route from higher Router-ID (System-IP)
Prefer highest TLOC private IP address

Configuring Service Side OSPF Using CLI
vpn 10
router
ospf
redistribute omp
area 0
interface ge2/0
exit
interface ge3/0
exit
exit
!
!
interface ge2/0
ip address 10.0.5.12/24
no shutdown
!
interface ge3/0
▪ Other common OSPF features are also supported:
ip address 10.0.2.12/24 ▪ Passive interfaces,
no shutdown ▪ Authentication,
!
▪ Hello and dead timer customization,
omp
advertise ospf external ▪ Default information originate,
▪ Summarization.
Configuring Service Side OSPF Using Template
Configuring Service Side OSPF Using Template (Cont.)
Verifying OSPF
vEdge# show ospf neighbor

DBsmL -> Database Summary List
RqstL -> Link State Request List
RXmtl -> Link State Retransmission List
INTERFACE IF DEAD
VPN ADDRESS INDEX NAME NEIGHBOR ID STATE PRI TIMER DBsmL RqstL RXmtL
------------------------------------------------------------------------------------------
-
10 10.0.5.13 0 ge0/2 172.16.255.13 full 13 36 0 0 0
10 10.0.5.21 0 ge0/2 172.16.255.21 two-way 0 36 0 0 0
20 10.2.2.12 0 ge0/0 172.16.255.12 full 1 36 0 0 0
vEdge# show ospf database

LSA LINK ADVERTISING
VPN AREA TYPE ID ROUTER AGE CHECKSUM SEQ#
-------------------------------------------------------------------------------------------------
10 51 router 172.16.255.13 172.16.255.13 622 0x2dd9 0x80000010
10 51 router 172.16.255.14 172.16.255.14 622 0xb6ad 0x80000004
10 51 network 10.0.5.13 172.16.255.13 623 0x8f7c 0x80000002
10 51 network 10.1.14.13 172.16.255.13 622 0xa134 0x80000001
20 0 router 172.16.255.12 172.16.255.12 699 0xce55 0x80000007
20 0 router 172.16.255.21 172.16.255.21 704 0x2238 0x80000003
20 0 network 10.2.2.12 172.16.255.12 700 0xf9ec 0x80000001
20 0 network 10.2.3.21 172.16.255.21 704 0xe6e2 0x80000001
Configuring Service Side EIGRP Using CLI
router eigrp eigrp-name

address-family ipv4 vrf 10 autonomous-system 10
af-interface GigabitEthernet5
hello-interval 5
hold-time 15
split-horizon
exit-af-interface
!
network 10.1.1.0 0.0.0.255
topology base
redistribute omp
exit-af-topology
!
exit-address-family
! ▪ Other common EIGRP features are also supported:
omp ▪ Authentication,
advertise eigrp
▪ Hello timer customization,
▪ Summarization.
▪ Routing Policies
Configuring Service Side EIGRP Using Template
Configuring Service Side EIGRP Using Template
Configuring Service Side EIGRP Using Template (Cont.)
Verifying EIGRP
vEdge# show eigrp neighbor
MSG MSG OUT AFI

VPN PEER ADDR AS RCVD SENT Q UPTIME STATE LAST UPTIME ID AFI
-------------------------------------------------------------------------------------------------------------
20 10.0.31.11 65002 3796 3799 0 0:01:03:17 established Thu Mar 3 09:33:24 2016 0 ipv4-unicast
vEdge# show eigrp routes vpn 20
INFO LOCAL AS
VPN PREFIX ID NEXTHOP METRIC PREF WEIGHT ORIGIN PATH PATH STATUS TAG
-------------------------------------------------------------------------------------------------------------
20 10.2.2.0/24 0 0.0.0.0 1000 50 0 incomplete Local valid,best 0
20 172.16.255.118/32 0 10.0.31.11 0 - 0 incomplete 65002 valid,best,external 0
Configuring Service Side BGP Using CLI
vpn 20
router
bgp 65001
neighbor 10.0.31.11
no shutdown
remote-as 65001
!
address-family ipv4-unicast
redistribute omp
propagate-aspath
!
!
omp
advertise bgp
overlay-as 65000
▪ Other common BGP features are also supported:

▪ Authentication,
▪ Holdtime and keepalive timer customization,
▪ Summarization.
Configuring Service Side BGP Using Template
Configuring Service Side BGP Using Template (Cont.)
Verifying BGP
vEdge# show bgp neighbor
MSG MSG OUT AFI

VPN PEER ADDR AS RCVD SENT Q UPTIME STATE LAST UPTIME ID AFI
-------------------------------------------------------------------------------------------------------------
20 10.0.31.11 65002 3796 3799 0 0:01:03:17 established Thu Mar 3 09:33:24 2016 0 ipv4-unicast
vEdge# show bgp routes vpn 20
INFO LOCAL AS
VPN PREFIX ID NEXTHOP METRIC PREF WEIGHT ORIGIN PATH PATH STATUS TAG
-------------------------------------------------------------------------------------------------------------
20 172.16.255.118/32 0 10.0.31.11 0 - 0 incomplete 65002 valid,best,external 0
Policy Overview
▪ Clear separation between control plane and data plane policies

▪ Clear separation between centralized and localized functions
vSmart Policy Architecture
Lists Policy Definition Policy Application
•Prefixes • Control Policies affect •An apply directive is

overlay routing used in conjunction
•Sites • Application Aware with site lists to
•TLOC Routing policy is used in enable specific
conjunction with SLAs policies at specific
•VPN to steer traffic
locations
•Colors • Data policies provide
VPN level policy based
•SLAs routing
Centralized policy definition configured on vManage and enforced across entire network
vSmart Policy Architecture (Cont.)
▪ vSmart Policies consist of these building blocks:

▪ Lists used for defining targets of policy application or matching
▪ Policies controlling aspects of control and forwarding
- Control Policy
- Application Aware Policy
- Data Policy
- cflowd-template
- vpn-membership-policy
▪ Policy Application to control towards what a policy is applied
- Site-oriented and defined by a site-list
vSmart Policy Constructs - Lists
policy ▪ data-prefix-list used in data-policy to define

lists prefixes for traffic matching
data-prefix-list app1 ▪ prefix-list used in control-policy to define
ip-prefix 10.1.1.1/32 prefixes for RIB matching
!
prefix-list pfx1 ▪ site-list used in control-policy and apply-policy
ip-prefix 10.2.2.0/24 ge 25 to match source sites or define sites for policy
! application
site-list branches ▪ tloc-list used in control-policy to define tlocs
site-id 100-150,155,160 for RIB matching and to apply redefined tlocs
! to vRoutes
tloc-list site1_tloc
▪ vpn-list used in control-policy to define
tloc 10.3.3.3 color mpls
prefixes for RIB matching, in data-policy and
!
vpn-list vpn123 app-route-policy to define VPNs for policy
vpn 1-3 application
!
!
vSmart Policy Constructs - Policies
policy ▪ Policy definition dictates type of policy and the appropriate

policy-type <name> syntax
vpn-list <vpn-list> ▪ VPN-list used by data-policy and app-route-policy to list the
sequence <n> VPNs for which the policy is applicable
match <route|tloc|vpn|other> ▪ Sequence defines each sequential step of the policy by
! sequence number
action <accept|reject|drop>
▪ Match decides what entity to match on in the specific policy
set <attribute> <value>
sequence
!
default-action <reject|accept> ▪ Action determines the action for the preceding match
! statement
! ▪ Default-action is the action to take for any entity that was not
! matched in any sequence of the policy (set to reject by default)
!
vSmart Policy Constructs – Policy Application
apply-policy ▪ Site-list determines to which sites a given policy is applied

site-list <name>
control-policy <name> <in|out>
▪ Direction applies only to control-policies
!
site-list <name>
data-policy <name> ▪ Policy Type and Name refers to an already configured
vpn-membership <name> policy to be applied towards sites specified in the site-list
! for the section
!
vSmart Policy Example – CLI Config
apply-policy
site-list site10 ▪ Apply the defined policy towards the sites in
control-policy prefer_local out site-list
!
policy ▪ Define the lists required for apply-policy and for
lists use within the policy
site-list site10
site-id 10
site-list site20 ▪ Define the actual policy to be applied
site-id 20
tloc-list prefer_site1
▪ Lists previously defined used within policy
tloc 10.1.1.1 color mpls preference 400
!
control-policy prefer_local ▪ Note: Items listed as presented in node
sequence 10 configuration. The order in which elements are
match route configured should be lists, control-policy then
site-list site20 apply-policy
!
action accept
set
tloc-list prefer_site1
!
!
!
vSmart Policy Processing
▪ Policies are processed sequentially. Order is important!
▪ When a match occurs, the matched entity is subject to the configured

action of the sequence and is then no longer subject to continued
processing.
▪ Any entity not matched in a sequence is subject to the default action for
the policy.
▪ In a multi-vSmart deployment, every vSmart acts independently to

disseminate information to other vSmarts and WAN Edges
▪ vManage acts as the entity to ensure all vSmarts are synchronized.

WAN Edge Routing Policy Architecture
▪ Routing Policies are traditional routing policies
▪ Attaches to BGP/OSPF/EIGRP locally on the WAN Edge
▪ Used in the traditional sense for controlling BGP/OSPF/EIGRP

- Information exchange
- Attributes
- Path Selection
Policy Framework
Centralized and Localized Policies
vManage
NETCONF/YANG
Device Configuration Device Configuration
Centralized Control Policy Local Control Policy

(Overlay Routing) (OSPF/BGP)
Centralized Localized
Centralized Data Policy Policies Policies Local Data Policy
(Overlay Data Plane) (QoS/Mirror/ACL)
Centralized App-Aware Policy

(Application SLA)
OMP
Centralized Data Policy Centralized App-Aware Policy

vSmart (Overlay Data Plane) (Application SLA) Edge
Centralized and Localized Policies
▪ The Cisco SDWAN policy software design provides a clear separation between centralized and localized policies.
Centralized policy is provisioned on the centralized vSmart controllers and the localized policy is provisioned on
WAN Edge routers
▪ With Localized Data policy, also called an access list, you can provision QoS to:
▪ Classify incoming data packets into multiple forwarding classes based on importance.
▪ Spread the forwarding classes across different interface queues.
▪ Schedule the transmission rate or weights for each queue
▪ With Centralized policies on vSmart controllers:

▪ Centralized Control policies affect routing policy to influence routing decisions on the WAN Edge routers. This
type of policy allows you to set preferences for the routes or paths on the vSmart controller and is reflected in
forwarding tables on the WAN Edge routers.
▪ Application-Aware routing policies select the best path for a given application based on SLA requirements.
These requirements include latency, packet loss, and jitter. Application-aware routing policies are configured
on vSmart controllers and are enforced by WAN Edge routers.
▪ Centralized Data policies are used for traffic classification, DSCP marking, path selection, service insertion,
policing, etc. Data policies are configured on vSmart controllers and enforced by WAN Edge routers.
Policy Distribution
Data Policy Control Policy Local Policies

App Aware Routing Policy VPN Membership Policy
vManage vManage vManage
NETCONF/YANG NETCONF/YANG NETCONF/YANG
vSmart vSmart vSmart vSmart vSmart vSmart
OMP OMP
WAN Edge WAN Edge WAN Edge

Policy Deployment
vManage vSmart
Centralized Direction
Deployment
Site-ID
Out In
Site-ID Control Policy
VPN SD-WAN
AAR Policy**
WAN Edge
(Site-ID)
Direction*
Site-ID VPN1 VPN2
VPN
Data Policy LAN1

LAN2
*from-service/from-tunnel
Overlay Management Protocol (OMP)
**from-service only
Packet Flow Through the WAN Edge Router
Best Practices for Policy Selection
▪ DPI based application recognition is not available in localized data policy.
▪ If matching criteria is same across large number of WAN Edges/sites, then

centralized data policy is a preferred over localized data policy.
▪ DSCP marking done by the localized data policy can be used for matching in app-
route policy and centralized data policy.
▪ Unconditional transport path selection for applications/flows can only be done via
centralized data policy.
▪ Unconditional transport selection based on prefixes should be done using

centralized control policy.
▪ App-route policy is used ONLY if SLA based routing is required.

Centralized Control Policies - Overview
▪ Control policies are configured on vManage, and enabled and enforced on vSmart controllers. They do
not get forwarded to WAN Edge routers.
▪ Control policies operate on OMP routing information received from or sent to WAN Edge routers. They
can filter OMP updates or modify various attributes.
▪ Control policies can be a very powerful tool for changing routing behavior of the entire SD-WAN fabric
▪ Control policies are used to enable many services, such as:

▪ Service Chaining
▪ Traffic Engineering
▪ Extranet VPNs
▪ Service and Path affinity
▪ Arbitrary VPN Topologies

Control Policy – Inbound vs Outbound Attachment
▪ Inbound Policy: determines which routes

are installed in the local routing database of
the vSmart controller.
▪ Outbound Policy: applied AFTER a route is
retrieved from routing database, but
BEFORE the vSmart controller advertises it.
▪ Important: you may apply single policy per
direction per individual site
Control Policy Operation
Creating a centralized policy
Define objects of interest
Define topology
Define traffic rules
Define data policies
Activating and editing policies
Control Policy Example – Arbitrary VPN Topologies
▪ Problem: Different VPNs must be provided with different connectivity based on
applications being serviced in each VPN
VPN 1: CRM System = Hub and Spoke, VPN 2: Voice = Full Mesh
▪ Solution: Deploy control policy to control VPN topology
Control Policy
Policy Details:
vSmart VPN1
Data Center VPN1 - vSmart advertises just the DC prefixes to
VPN1 VPN1 Spokes and denies everything else on VPN1.
Cisco SD-WAN VPN2 - No filter all the prefixes are advertised to

every node on VPN2
Site1 Site3
VPN2 Site2 VPN2
VPN1 VPN2
Control Policy Example – Arbitrary VPN Topologies
policy apply-policy
lists site-list Branches
site-list Branches control-policy ArbitraryTopology out
site-id 1-3
!
vpn-list CRM
Control Policy
vpn 1
!
vSmart VPN1
control-policy ArbitraryTopology Data Center
sequence 10
match route VPN1
VPN1
vpn-list CRM
site-list Branches
! Cisco SD-WAN
action reject
!
Site1 Site3
!
default-action accept VPN2 Site2 VPN2
VPN1 VPN2
Control Policy Example – Data Center Priority
▪ Problem: Prefer main data center over DR data center. If main data center fails, traffic should reroute
to DR data center.
▪ Solution: Deploy control policy to influence TLOC priority
Control Policy
Policy Details:
vSmart Main DR
DC DC Set higher preference on main data center
TLOCs than on DR data center TLOCs
Preference is set on all TLOC colors using
TLOC list
Cisco SD-WAN
Site3
Control Policy Example – Data Center Priority
policy Control Policy
lists
site-list Branches
site-id 3-10
tloc-list Main-DC-tlocs Main DR
tloc-id 10.1.1.1 gold vSmart DC DC
tloc-id 10.1.1.1 mpls
control-policy prefer-Main-DC
sequence 10
match tloc
tloc-list Main-DC-tlocs
action accept Cisco SD-WAN
set preference 50
apply-policy
site Branches
control-policy prefer-Main-DC out Site3
Control Policy Example – Shared Services
▪ Problem: Services residing in a VPN must be shared across users residing in multiple
other VPNs. Some VPNs don’t need access to shared services.
▪ Solution: Deploy control policy with route exports
Control Policy
Policy Details:
vSmart Export VPN2 and VPN3 routes into
VPN100
shared service VPN100, and vice versa
Site2 VPN1 cannot communicate with VPN2,
VPN3 or VPN100
VPN1
Cisco SD-WAN
VPN2
Site1
Site3
VPN2 Site4
VPN1 VPN3
Control Policy Example – Shared Services
apply-policy control-policy extranet
site-list all-extranet-sites sequence 10
control-policy extranet in match route
! vpn-list extranet-clients
action accept
Control Policy
export-to vpn 100
!
sequence 20
vSmart match route
vpn 100
VPN100
prefix-list extranet-srv-prefix
action accept
Site2 export-to vpn-list extranet-clients
!
!
VPN1
default-action accept
!
Cisco SD-WAN policy

lists
VPN2 site-list all-extranet-sites
site-id 1-4
Site1 !
Site4 Site3 vpn-list extranet-clients
VPN2
vpn-id 2-3
!
VPN1 VPN3
prefix-list extranet-srv-prefix
ip-prefix 10.1.1.1/32
Control Policy Example – Service Insertion
▪ Problem: Certain departments require Firewall protection when interacting with data center
networks, while other departments do not
▪ Solution: Deploy a service chained Firewall service per-VPN
Firewall
Control Policy
Policy Details:
Advertise Firewall Service Regional hub advertises
vSmart
Regional Hub availability of Firewall service
VPN1 - Protected
Bi-directionally modify TLOC
next hop attribute for VPN1
traffic between Site1 and Data
Cisco SD-WAN Center to point at regional hub
TLOCs
Data
Center VPN2 - Open
Site10
VPN1 - Protected VPN2 - Open

Control Policy Example – Service Insertion
! Applied on Regional Hub policy

vpn 1 lists
service netsvc1 address 10.0.1.1 site-list fw-inspected
site-id 10
!
Control Policy
Firewall
control-policy fw-service
Advertise Firewall Service sequence 10
vSmart match route
Regional Hub
vpn 1
VPN1 - Protected site-id 1
action accept
set service netsvc1 vpn 1
Cisco SD-WAN !
!
Data
Center VPN2 - Open
Site10 Site 1 apply-policy
site-list fw-inspected
control-policy fw-service out
!
Service Insertion (Cont.) – Returned Traffic
! Applied on Regional Hub policy

vpn 1 lists
service netsvc2 address 10.0.2.1 site-list dc
site-id 1
!
Firewall control-policy fw-service-return

Control Policy sequence 10
match route
Advertise Firewall Service
vpn 1
vSmart Regional Hub site-id 10
action accept
VPN1 - Protected set service netsvc2 vpn 1
!
Cisco SD-WAN !
apply-policy
Data
site-list dc
Center VPN2 - Open
Site10 control-policy fw-service-
Site 1
return out
!
Hierarchical Traffic Policy
Needed tasks:
▪ Limit BFD sessions to intra-region and between hubs
▪ Adapt routing to support desired topology
Cisco SD-WAN
Hierarchical Traffic Policy (Cont.) – Region 1 Policy
control-policy hub1 control-policy region1-spokes

sequence 1 sequence 1
match tloc match tloc
site-list region2-3-spokes site-list region2-3
action reject action reject
! !
sequence 5 sequence 5
match route match route
site-list region2-spokes site-list region2-3
action accept action accept
set set
tloc 10.0.0.2 color gold tloc 10.0.0.1 color gold
! !
sequence 10 default-action accept
match route
site-list region3-spokes
action accept apply-policy
set site-list hub1
tloc 10.0.0.3 color gold control-policy hub1 out
! site-list region1-spokes
default-action accept control-policy region1-spokes out
Defining Topologies in vManage
VPN Membership Policy
▪ The default behavior of the SDWAN OMP architecture is to advertise any configured
VPN to any node where it is configured
▪ This automatically establishes connectivity without unnecessary configuration and

operational overhead
▪ However, certain VPNs may be of a sensitive nature such that their membership must
be tightly controlled
▪ The VPN Membership Policy serves to restrict the distribution of VPN information from
vSmart to those that are explicitly approved
▪ Both Whitelist and Blacklist behavior can be established
▪ With a VPN Membership Policy, a node not explicitly allowed to participate in a VPN
may have the VPN configured but will only see local connectivity and routing
information
VPN Membership Policy Example
Policy Policy
lists vpn-membership acme_1
site-list sites_1 sequence 10
site-id site1 match vpn-list sites_1
site-id site2 action accept
! !
site-list sites_2 !
site-id site3 default-action reject
site-id site4 !
! vpn-membership acme_2
vpn-list sites_1 sequence 10
vpn 10, 20 match vpn-list sites_2
! action accept
vpn-list sites_2 !
vpn 30, 40 !
! default-action reject
! !
! !
vpn-lists define the VPN match data apply-policy

site-list sites_1
vpn-membership acts as either vpn-membership acme_1
whitelist or blacklist for VPN filtering !
apply-policy acts in both directions site-list sites_2
to determine which VPN(s) are vpn-membership acme_2
allowed from a given site !
!
Centralized Data Policy - Overview
▪ Data policies are configured on vManage, enabled on vSmart controllers and enforced
on WAN Edge routers
▪ Data policies act on application traffic characteristics such as source and destination
addresses, ports, protocol numbers and DSCP values
▪ A Data policy acts on an entire VPN and is not interface specific.
▪ Data policies are used to enable many services, such as:
▪ QoS Classification
▪ Service Chaining
▪ cflowd
▪ NAT
▪ Traffic Policing and Counting
▪ Transport Selection, TE
Centralized Data Policy Configuration
Step 1: Create a list of sites to which the Step 3: Create a data policy instance and associate it with a list of VPNs. Within
centralized data policy is to be applied the policy, create one or more numbered sequence of match–action pairs
policy policy
lists data-policy myDataPolicy
site-list mySites vpn-list myVPN
site-id 100-200 sequence 10
! match
app-list myApps
!
Step 2: Create lists of IP prefixes and action
VPNs, as needed accept
set
policy dscp 32
lists !
prefix-list myPrefixes
ip-prefix prefix/length
! Step 4: Apply the policy to one or more sites in the overlay network
vpn-list myVPN
vpn 1 apply-policy
! site-list mySites
app-list myApps data-policy myDataPolicy (all | from-service | from-tunnel)
app office365 !
app salesforce !
!
Specifying Data Policy - Overview
Data Policy Example – Application Firewall
▪ Task: Block FTP traffic between branch sites in VPN 2
VPN1 Data Center
VPN1 VPN1
Site1 Site3
VPN2 Site2 VPN2
VPN1 VPN2
Policy Example – Application Firewall
apply-policy
site-list branches
lists data-policy block_ftp all
site-list branches !
site-id 1-3
!
vpn-list corporate VPN1
vpn-id 2
!
app-list ftp Data Center
app ftp
VPN1 VPN1
data-policy block_ftp
vpn-list corporate
sequence 10
match
app-list ftp
action drop
! Site1
Site3
! VPN2
Site2 VPN2
VPN1 VPN2
Policy Example – Application Firewall - GUI
Policy Example – Application Firewall – GUI (Cont.)
Data Policy Example – Traffic Engineering
• Problem: Send critical applications over MPLS transport and non-critical applications over Internet transport
• Solution: Deploy data policy to set transport for relevant traffic
Data Policy
vSmart
Policy Details:
Bi-directionally set local
Site 2 TLOC for desired traffic
Override OMP routing
MPLS decision
Site 1 Cisco SD-WAN

Data Policy Fallback on overlay routing
if transport fails
INET
Data Policy
Policy Example: Traffic Engineering
data-policy prefer_mpls lists

vpn-list vpn10 data-prefix-list DC-Servers
sequence 5 ip-prefix 10.1.1.0/24
match data-prefix-list Clients
destination-data-prefix-list DC-Servers ip-prefix 10.10.1.0/24
source-data-prefix-list Clients !
! site-list Site1-2
action accept site-id 1-2
set !
local-tloc-list vpn-list vpn10
color mpls vpn 10
! !
sequence 10 !
match
destination-data-prefix-list Clients
source-data-prefix-list DC-Servers
action accept
set
local-tloc-list apply-policy
color mpls site-list Site1-2
default-action accept data-policy prefer_mpls from-service
Data Policy Example – Service Insertion
• Problem: Certain applications requires Firewall protection when interacting with data center networks
• Solution: Deploy a service chained Firewall service using Data Policy
Firewall
Data Policy

vSmart
Regional Hub
Policy Details:
HTTP traffic
Regional hub advertises availability
of Firewall service
Cisco SD-WAN
Selectively redirect traffic towards
advertised FW service
Data
Center Other traffic
Site10
HTTP traffic Other traffic

Data Policy Example – Service Insertion
! Applied on Regional Hub lists

vpn 1 vpn-list inspected_vpn
service FW address 10.0.1.1 vpn 1
site-list fw-inspected
site-id 10
Firewall data-policy fw-service

Data Policy vpn-list inspected_vpn
sequence 10
vSmart Regional Hub match
destination-ip 10.0.0.0/24
HTTP traffic
destination-port 80
action accept
set service FW vpn 1
Cisco SD-WAN !
Data
Other traffic apply-policy
Center site-list fw-inspected
Site10
data-policy fw-service from-service
HTTP traffic Other traffic
Note: policy example inserts service

only in one direction
Localized Control Policies
▪ WAN Edge Routing Policies are traditional routing policies
▪ Attaches to BGP or OSPF locally on the WAN Edge
▪ Used in the traditional sense for controlling BGP, OSPF and redistribution
▪ Information exchange
▪ Attributes
▪ Path Selection
▪ Commonly referred to as a local control policy
▪ Not all elements of configuration are available in vManage Template GUI
▪ CLI templates can be utilized

Defining Localized Control Policies
Localized Data Policies
▪ Configured in CLI or using CLI configuration template or via GUI using Localized Policy.
▪ Examples: ▪ DPI and Flow Visibility
▪ QoS Policy Configuration policy
▪ Access Lists app-visibility
flow-visibility
▪ Traffic mirroring
Example: Access Lists
policy
access-list sample_acl ▪ Protocol 6 = TCP
sequence 10
match
▪ 17 = UDP
action accept
!
sequence 20
match ▪ Default implicit deny at the end of ACL
protocol 6
destination-ip 172.20.0.0/16 ▪ Define default-action to modify
destination-port 80
!
action accept
!
! ▪ Attached to interface in inbound or
vpn 1
interface ge0/2 outbound direction
access-list sample_acl in
WAN Edge Router Device QoS Overview
QoS Configuration Steps - Localized Data Policy
1) Configure forwarding classes and mapping to output queues.
2) Configure the QoS scheduler forwarding classes.
3) Define QoS Map by grouping QoS Schedulers.
4) Apply the QoS map to the egress interface.
5) Classify Data Packets into appropriate Forwarding Classes.

Configuring FC and Mapping to Output Queues
▪ Per-Egress Interface Queuing

policy
class-map
▪ 8 queues (Q0-Q7)
class best-effort queue 3
▪ Q0 is LLQ
class bulk-data queue 2
class critical-data queue 1 ▪ WAN Edge control traffic (DTLS/TLS, BFD,
class voice queue 0
! routing protocols) goes into Q0
!
▪ Not subjected to LLQ policer
Configuring the QoS Scheduler for each FC
qos-scheduler be-scheduler qos-scheduler critical-scheduler

class best-effort class critical-data
bandwidth-percent 20 bandwidth-percent 40
buffer-percent 20 buffer-percent 40
scheduling wrr scheduling wrr
drops red-drop drops red-drop
! !
qos-scheduler bulk-scheduler qos-scheduler voice-scheduler
class bulk-data class voice
bandwidth-percent 20 bandwidth-percent 20
buffer-percent 20 buffer-percent 20
scheduling wrr scheduling llq
drops red-drop drops tail-drop
▪ Queue drop is RED (Q1-7) or tail-drop (Q0)

▪ If shaping is applied on the interface, shaped rate is used for bw % calculation.
▪ Match the buffer % to the bw % allocated for the FC (best practice).
Defining QoS Map and Applying it on Interface
policy
qos-map MyQoSMap
qos-scheduler be-scheduler
qos-scheduler bulk-scheduler
qos-scheduler critical-scheduler
qos-scheduler voice-scheduler
!
!
vpn 0
interface ge0/1
qos-map MyQoSMap
!
!
Classification Using ACL (Localized Data Policy)
policy sequence 40
access-list Classify-ACL action accept
sequence 10 class best-effort
match set
dscp 46 dscp 0
action accept
class voice
sequence 20
match vpn 1
source-ip 10.1.1.0/24 interface ge0/0
destination-ip 192.168.10.0/24 access-list Classify-ACL in
action accept
class bulk-data
set
dscp 12
sequence 30
match
action accept
class critical-data
set
dscp 32
Marking and Re-marking
Default Behavior
▪ Comply with service providers
provisioned classes of service
▪ Ingress Classification
▪ DPI or 6 tuple matching using
Egress Interface
Ingress Interface
centralized or localized data policy
▪ Ingress interface marks/re-marks inner
DSCP
DSCP
DSCP
DSCP bits
▪ Inner DSCP bits are copied to the outer
Modify with
DSCP bits
Modify with
ACL/Data Policy re-write rules ▪ Egress interface re-write rules remark
outer DSCP bits
Example: Re-marking
policy
rewrite-rule transport ▪ Rewrite rule to overwrite the DSCP field of
class af1 low dscp 3
class af1 high dscp 4 the outer IP header in egress direction
class af2 low dscp 5
class af2 high dscp 6
class af3 low dscp 7 ▪ Can rewrite based on the drop profile
class af3 high dscp 8
class be low dscp 1
class be high dscp 2
!
!
vpn 0
interface ge0/0
rewrite-rule transport
!
!
Queueing
▪ Classification
WAN Edge
▪ Flow match on 6-tuple (ACL, Data Policy)
Q0 ▪ Application match on DPI (Data Policy)
Egress Interface
Ingress Interface
Q1
Q2 ▪ Per-Egress Interface Queuing
▪ Q0 is LLQ
Q7 ▪ WAN Edge control traffic (DTLS/TLS, BFD, routing
protocols) goes into Q0
▪ Not subjected to LLQ policer
Classification Queuing ▪ Scheduling for Q1-Q7 is WRR*

▪ Bandwidth percent determines queue weight
▪ Unused Q0 bandwidth is distributed between other
* Weighted Round-Robin queues
** Random Early Discard
▪ Queue drop is RED** or tail-drop
▪ Linear drop probability, i.e. X% queue depth results
in X% drop probability
Shaping
▪ Shaping effective on egress physical interfaces

Rate
▪ Not supported on sub-interfaces or VLANs
Tokens
Token Bucket ▪ Forward traffic that conforms to configured
shape rate
▪ There are tokens in the bucket
Egress Interface
Ingress Interface
▪ Queue traffic that exceeds configured shape

rate
▪ There are no tokens in the bucket
▪ Weighted Round-Robin
▪ Configured in kbps
Shaping Queuing
vpn 0
interface ge0/0
shaping-rate 100000
Policing
▪ Ingress and Egress Policing

Rate ▪ Interface/Sub-Interface based
Tokens
Token Bucket ▪ DPI or 6 tuple matching using centralized or
localized data policy
Egress Interface
Ingress Interface
▪ Forward traffic that conforms to configured policer

rate
▪ There are tokens in the bucket
▪ Drop traffic that exceeds configured policer rate

Classification Policing Queuing ▪ There are no tokens in the bucket
▪ Configurable Burst Rate

▪ Token bucket depth
Example: Policers
policy ▪ Conditional policer for specific outbound traffic

policer p1
rate 1000000
burst 15000 ▪ Unconditional policer for outbound traffic
exceed drop
!
access-list acl1
sequence 1
match
source-ip 10.10.1.0/24
destination-port 80 policy
protocol 6 policer p1
action accept rate 1000000
policer p1 burst 15000
default-action drop exceed drop
! !
vpn 1 vpn 1
interface ge0/4 interface ge0/4
access-list acl1 out policer p1 in
Policing with Packet Loss Priority
Rate
Tokens ▪ Set PLP=High value for traffic that
Token Bucket exceeds configured policer rate
▪ There are no tokens in the
bucket
▪ Default is PLP=Low
▪ Data policy can match on PLP

TLOC Silver
Policing high value and set different local
TLOC
▪ Decision is taken on per-packet
level
▪ Non-conforming traffic spills over
to a different circuit
TLOC Red
Example: Policing with PLP
policy policy
policer bursty-traffic lists
rate 1000000 site-list branch100
burst 20000 site-id 100
exceed remark vpn-list wan-vpn
access-list policer-bursty-traffic vpn 10
sequence 10 data-policy highest-priority
match vpn-list wan-vpn
source-ip 10.1.0.0/24 sequence 10
action accept match
policer bursty-traffic plp high
default-action accept source-ip 10.1.0.0/24
! action accept
vpn 1 counter bursty-counter
interface ge1/0 set local tloc-color red
ip address 10.1.0.1/24 default-action accept
no shutdown apply-policy
access-list policer-bursty-traffic in site-list branch100
data-policy highest-priority from-service
QoS - vEdgeCloud Specifics
policy
cloud-qos
cloud-qos-service-side
▪ cloud-qos - Enables QoS scheduling and shaping for traffic that the vEdgeCloud
receives from transport-side interfaces
▪ cloud-qos-service-side - Enable QoS scheduling and shaping for traffic that the
vEdgeCloud receives from service-side interfaces
Critical Applications SLA
▪ WAN Edge Routers

continuously perform
path liveliness and
quality measurements
AAR Overview
▪ Poll Interval and Multiplier determine how quickly AAR policy will react
▪ Application-aware routing policy affects only traffic that is flowing from the service side
▪ If a single tunnel matches the SLA, data traffic is sent through that tunnel.
▪ If two or more tunnels match, traffic is distributed among them.
▪ If no tunnel matches the SLA, data traffic is sent through one of the available tunnels.
▪ Maximum of 4 SLA Classes defined per WAN Edge

Path Quality and Liveliness Detection
• Each WAN Edge router sends BFD hello packets

for path quality and liveliness detection
- Packets echoed back by remote site
• Hello interval and multiplier determine how many

BFD packets need to be lost to declare IPSec
tunnel down
• Number of hello intervals that fit inside poll interval

determines the number of BFD packets considered
for establishing poll interval average path quality
• App-route multiplier determines number of poll

intervals for establishing overall average path
quality
App-Route Algorithm
bfd bfd
app-route poll-interval hello-interval
bfd
app-route multiplier
App-route Policy Path Convergence
▪ Current Mean Latency is 20ms, when Latency jumps to 150ms as Bucket 1 collection starts
Application-Aware Routing Policy
▪ Application-aware routing consists of three components:

- Identify the applications of interest. To determine which applications are running on WAN Edge routers,
you enable application visibility on these devices. Then you configure an application-aware routing
policy on the vSmart controller, which defines the applications of interest and the data plane tunnel
performance characteristics required to transmit an application's data traffic. These characteristics are
called a service-level agreement (SLA). The controller automatically pushes the policy to the
appropriate WAN Edge routers.
- Monitor and measure data plane tunnel performance is done automatically and continuously by the
WAN Edge routers, by tracking BFD Hello packets. Application-aware routing periodically polls the
performance statistics to calculate the packet jitter and latency and packet loss information for each
tunnel. The default polling interval is good for most network situations, but you can modify it to meet
specific business needs.
- Map application traffic to a specific data plane tunnel is done on the WAN Edge routers, based on the
SLA requirements defined in application-aware routing policy and based on the real-time performance
of the WAN Edge routers' data plane tunnels. You can modify how often a WAN Edge router calculates
each tunnel's SLA and determines a tunnel's SLA classification.
Application Aware Routing
▪ An app-route policy is defined through the following steps:
▪ Define the required SLA classes
▪ Define the app-route-policy
▪ Apply the app-route-policy towards the applicable sites
▪ The SLA-class defines the required loss, latency and jitter thresholds for the application that is to go via the
overlay path
▪ The app-route-policy defines the traffic that is to belong to a defined class in a fashion similar to a data-
policy
▪ Configuring an app-route-policy includes a reference to a VPN-list to dictate which VPNs will benefit from
the policy at the listed sites
Application-Aware Routing Policy Configuration
Step 1: Create a list of sites to which the application-

aware routing policy is to be applied
policy Step 3: Create lists of applications, IP prefixes, and

lists VPNs to use in identifying application traffic of
site-list mySites interest (in the match section of the policy definition
site-id 100-200
!
policy
Step 2: Create SLA classes and traffic characteristics lists
to apply to matching application data traffic. vpn-list myVPN
vpn 10
!
policy
data-prefix-list approute-Prefixes
sla-class bulk-data-sla
ip-prefix 10.1.0.0/16
latency 150
!
!
app-list myApps
sla-class critical-data-sla
app office365
loss 5
app salesforce
latency 150
!
!
!
sla-class voice-sla
!
loss 1
latency 100
jitter 5
!
Application-Aware Routing Policy Configuration Cont.
Step 4: Create an application-aware routing policy Step 5: Within the policy, create one or more numbered sequence of match–action pairs
instance and associate it with a list of VPNs
policy
policy
app-route-policy myApproutePolicy
app-route-policy myApproutePolicy
vpn-list myVPN
vpn-list myVPN
sequence 10
!
match
!
app-list myApps
!
Step 6: Specify the default action for the policy action
sla-class critical-data-sla preferred-color mpls
!
policy !
app-route-policy myApproutePolicy sequence 20
vpn-list myVPN match
default-action sla-class bulk-data-sla dscp 46
! !
! action
! sla-class voice-sla preferred-color mpls
!
!
Step 7: Apply the policy to a site list: sequence 30
match
apply-policy destination-data-prefix-list approute-Prefixes
site-list mySites !
app-route-policy myApproutePolicy action
! backup-sla-preferred-color public-internet
! sla-class bulk-data-sla preferred-color biz-internet
!
Direct Internet Access
▪ Can use one or more local DIA exits or backhaul

traffic to the regional hub through the SD-WAN
fabric and exit to Internet from there
▪ Per-VPN behavior enforcement
▪ VPN default route* for all traffic DIA or data policy

for selective traffic DIA
▪ Network Address Translation (NAT) on the WAN

Edge router only allows response traffic back
▪ Any unsolicited Internet traffic will be blocked by IP
table filters
▪ For performance based routing toward SaaS

applications use Cloud onRamp
Directing Traffic to the Internet Using Data Policy
▪ Problem: Local Internet exit needs to be provided to guest WiFi users. Guest WiFi users need to be
isolated from corporate users.
▪ Solution: Deploy a data policy in guest VPN with a network address translation
Data Policy
vSmart
Internet Policy Details:
VPN1 – Corporate
Define NAT on transport side
interface
Cisco SD-WAN Data Policy
DIA
DIA NAT Force matching traffic in guest WiFi
Data
VPN2 – Guest
VPN through a locally defined NAT
Site Center on transport side interface
NAT
VPN1 – Corporate VPN2 – Guest
Data Policy
Example: Local DIA Using Data Policy
vpn 0 apply-policy
interface ge0/1 site-list wifi-sites
nat data-policy wifi-dia from-service
lists
vpn-list guest-wifi
Data Policy
vpn 2
site-list wifi-sites vSmart
site-id 10-15
Internet
data-policy wifi-dia VPN1 – Corporate
vpn-list guest-wifi
Cisco SD-
sequence 10 Data Policy
match WAN DIA
DIA NAT
destination-port 80 443
Data
action accept VPN2 – Guest
nat use-vpn 0 NAT Site Center
! VPN1 – Corporate VPN2 – Guest
Data Policy
DIA Using IP Prefix
vpn 0
interface ge0/1
nat ▪ Default NAT route cannot coexist with static
vpn 2
default route
ip route 0.0.0.0/0 vpn 0
vpn 2
router ▪ NAT route does not get redistributed into OMP
bgp 65000
address-family ipv4-unicast
redistribute nat
▪ Service side redistribution into OSPF or BGP is

vpn 2
router supported
ospf
redistribute nat
DIA Using IP Prefix (Cont.)
BR1-VEDGE1# show ip route vpn 2

Codes Proto-sub-type:
IA -> ospf-intra-area, IE -> ospf-inter-area, E1 -> ospf-external1, E2 -> ospf-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
-------------------------------------------------------------------------------------------------------------
2 0.0.0.0/0 nat - ge0/1 - 0 - - - F,S
2 0.0.0.0/0 omp - - - - 10.1.0.1 mpls ipsec -
2 0.0.0.0/0 omp - - - - 10.1.0.1 biz-internet ipsec -
2 0.0.0.0/0 omp - - - - 10.1.0.2 mpls ipsec -
2 0.0.0.0/0 omp - - - - 10.1.0.2 biz-internet ipsec -
2 10.2.0.0/24 omp - - - - 10.2.0.1 mpls ipsec F,S
2 10.2.0.0/24 omp - - - - 10.2.0.1 biz-internet ipsec F,S
2 10.2.0.0/24 omp - - - - 10.2.0.2 mpls ipsec F,S
2 10.3.0.0/24 connected - ge0/3 - - - - - F,S
2 10.10.10.0/24 omp - - - - 10.1.0.1 mpls ipsec F,S
2 10.10.10.0/24 omp - - - - 10.1.0.2 mpls ipsec F,S
NAT Overview
▪ Transport-side NAT
▪ 1:1 static NAT, which allow external connections to internal server is supported
since version 18.3
▪ Port forwarding
▪ Service-side NAT
▪ NAT pool interface + data policy
▪ Both dynamic and static NAT are supported
▪ Can translate internal or external source IP addresses
Tracking Transport Interface Status
system
▪ Tracking enables you to respond to
tracker dia
endpoint-ip 203.0.113.1 reachability status over WAN
interval 10
multiplier 1
vpn 0 ▪ When tracking destination is not

interface ge0/1
nat reachable, NAT route gets removed from
tracker dia
routing table
▪ Tracker uses HTTP probe!

Regional Internet Access
Internet ▪ Internet connectivity is provisioned in

the Regional Hubs
NAT NAT
vSmart
Firewall Firewall ▪ Regional Hub WAN Edge routers
advertise default route to remote site
WAN Edge routers
▪ Route originated by FW or static
VPN1 VPN1
Regional Regional ▪ NAT typically performed by FW
Hub Hub
▪ Control policy can constrain default

VPN1 MPLS 4G VPN1
INET
route to a given region
Branch Branch
▪ Region can have multiple hubs for
Traffic Path OMP Control Plane
redundancy and load-sharing
Cloud onRamp for SaaS – Internet DIA
▪ WAN Edge router at the remote site performs quality

probing for selected SaaS applications across each
local DIA exit
▪ Simulates client connection using HTTP ping
▪ Results of quality probing are quantified as vQoE

score (combination of loss and latency)
▪ Local DIA exit with better vQoE score is chosen to

carry the traffic for the selected SaaS application
▪ Initial application flow may choose sub-optimal
path until DPI identification is complete and
cache table is populated
Cloud onRamp for SaaS – DIA and Regional Gateway
▪ WAN Edge routers at the remote site and regional hub

perform quality probing for selected SaaS applications
across their local Internet exits
▪ Simulate client connection using HTTP ping
▪ Results of quality probing are quantified as vQoE score

(combination of loss and latency)
▪ HTTP ping for local DIA and App-Route+HTTP
ping for regional Internet exit
▪ Internet exit with better vQoE score is chosen to carry

the traffic for the selected SaaS application
▪ Initial application flow may choose sub-optimal
path until DPI identification is complete and cache
table is populated
▪ Automatic failover in case of performance degradation
▪ Fully Automated
Cloud onRamp for SaaS Quality Probing
▪ DNS resolution for the configured Cloud onRamp

DNS Server(s) SaaS applications
Loss/ ▪ Periodic quality probes toward the configured

Latency
Best ! Cloud onRamp SaaS applications

Performing ISP1 ISP2
▪ vQoE score is determined based on loss and

IF IF
latency reported by the quality probes
VPN0
▪ WAN Edge router determines best performing DIA
DNS Query
WAN Edge Router Quality Probe circuit toward Cloud onRamp SaaS applications
(remote site)
based on vQoE scores
vQoE
Score Color • Every site where SaaS application is enabled, is

8-10 Green classified as performing Good, Average or Bad
5-8 Yellow
0-5 Red
• Sites are color coded based on the performance
SD-WAN and Public Cloud
VPC VPC VNET VNET
VPC VPC
How to provide security,
VNET VNET
segmentation, QoS and
Cloud
Data Center
reliability to the cloud
workloads?
SD-WAN
Fabric
Campus
Remote Site
Branch
Cloud onRamp for IaaS – Attached Compute
▪ vEdgeCloud routers are instantiated in

Amazon VPCs or Microsoft Azure VNETs
Compute Compute
VPC/VNET VPC/VNET
▪ Posted in marketplace
▪ Use Cloud-Init for ZTP
Cloud
Data Center
▪ One vEdgeCloud router per VPC/VNET
▪ Redundancy is handled through cloud
SD-WAN provider
Fabric
Campus
Remote Site
▪ vEdgeCloud routers join the fabric, all fabric
services are extended to the IaaS instances,
e.g. multipathing, segmentation and QoS
Branch
▪ For multipathing, can combine AWS Direct
Connect or Azure ExpressRoute with direct
Internet connectivity
Cloud onRamp for IaaS – Gateway VPC/VNET
• Fully automated through

Standard IPSec + BGP vManage wizard
BGP <-> OMP
AZ1
R • Greatly simplifies brownfield
VGW integration
AZ2 IGW
AZ1 INET - No changes are required on
Host VPC vEdge GW
host VPCs
MPLS
AZ2 VGW Direct

vEdge GW Connect
• Multipathing, segmentation,
AZ1
R
Gateway VPC
QoS
VGW vManage instantiated and
AZ2 managed
• Fast failover
Host VPC
- Speed of BGP convergence
AWS Region vManage
Cloud onRamp for IaaS Dashboard
▪ Centralized provisioning wizard on vManage

▪ No need to operate marketplace
Lawful Intercept – Overview
▪ Lawful Interception is a process of

lawfully intercepting and storing
user traffic (voice and data).
▪ Lawful Intercept supports service

providers in meeting requirements
of law enforcement.
▪ Lawful Intercept requires a specific

LI license for vManage.
Lawful Intercept – Requirements
▪ Access to Cisco Lawful Intercept MIB should be restricted
▪ Mediation Device and System Administrators
▪ The Domain name of routers and mediation devices must be registered in DNS
▪ The Mediation Device must have an Access Function (AF) and Access
Function Provisioning Interface (AFPI)
▪ The Mediation Device must be part of an SNMP user group with access to
CISCO-TAP2-MIB
▪ SNMP must be enabled on the interfaces using the VPN interface feature
template
Lawful Intercept
Lawful Intercept – Installation
Step 1: Generate a license request
vManage# tools license request
Your org-name is: XYZ Inc
Your license-request challenge is:
Uwk3u4Vwkl8n632fKDIpKDEFkzfeJlhFQPOHopbvewmed0U83LQDgajO7GnmCIgA
Step 2: Contact Cisco Support and generate a license based on information from Step 1
Step 3: Install the license and reboot
vManage# tools license install file license.lic

License installed. Please reboot to activate.
vManage# reboot
Are you sure you want to reboot? [yes,no] yes
Broadcast message from root@vManage (somewhere) (Tue Jan 22 17:07:47 2019):
Tue Jan 22 17:07:47 UTC 2019: The system is going down for reboot NOW!
Connection to 10.0.1.32 closed.
Step 4: Verify LI license is installed
vManage# how system status

LI License Enabled True
Step 5: Create lawful intercept admin user using vManage

Secure Segmentation – VPNs
IF IF MPLS
Service Transport
(VPNn) (VPN0)
IF IF INET
▪ VPNs are isolated from each other, each VPN

Management has its own forwarding table
(VPN512)
▪ WAN Edge router allocates label to each of
it’s service VPNs and advertises it as route
IF attribute in OMP updates
▪ Labels are used to identify VPN in the
incoming packets
End-to-End Segmentation
vSmart
Route
Tables
A A
B B
C C
WAN Edge Router WAN Edge Router
IP UDP ESP LBL Original Packet
▪ Segment connectivity across fabric w/o reliance on underlay transport

▪ Interfaces and sub-interfaces (802.1Q tags) are mapped into VPNs
▪ WAN Edge routers maintain per-VPN routing table for complete control plane separation
▪ Labels are used to map packets into VPNs for complete data plane separation
Multi-Topology
▪ Arbitrary per-VPN topology

▪ Topology reflects desired
traffic forwarding patterns,
e.g. voice and video full-
mesh, business apps hub- vSmart
and-spoke Controllers
▪ vSmart controls VPN
App
topology through control Policies
plane advertisements
▪ vEdge routers can
participate in multiple
topologies at the same time
Control Plane
Data Plane Security Encryption
▪ Each WAN Edge advertises its local IPsec encryption keys as OMP TLOC attributes
▪ Encryption keys are per-transport
▪ Can be rapidly rotated
▪ Symmetric encryption keys used asymmetrically
vSmart
Controllers
OMP OMP
Update Update
Local
Local
Transport1
vEdge-A vEdge-B
Transport2
AES256-GCM
Control Plane
Remote
Remote
Traffic Encryption
▪ Each WAN Edge advertises its local IPsec encryption key

▪ Symmetric encryption keys used asymmetrically
vSmart
Controllers
Update Update
IPSec Security Associations IPSec Security Associations
vEdge vEdge
Router Router
Transports
Transports
Transports
Remote
Local IPsec
Remote
ESPv3 AES256 Local
Site 1 Site 2
Traffic Encrypted
Control Plane
with Key 2
DTLS/TLS
Traffic Encrypted
with Key 1
Control Plane Security
Traditional Branch Security
▪ Security enforcement at the branch is too costly, security enforcement at the data center is
too inefficient (for cloud)
▪ Segmentation over MPLS is underlay specific, segmentation over-the-top is operationally
cumbersome
▪ Per segment topology… forget about it! Cloud
VPN1 VPN2
Users Remote Site
VPN3
Data Center Firewall
Wide Area
Network
Users Remote Site
Why Security?
▪ Outside-in Threats
Corporate
Network ▪ Malware / Ransomware
Existing Security ▪ Phishing emails
Private Cloud
▪ Denial of Service
1. Avoid Backhauling
▪ Inside-out Threats
Benefit: Better use of WAN bandwidth
▪ Unauthorized access
Public ▪ Privilege escalation
2. Benefit Regional SaaS PoP MPLS INET Cloud
▪ Data Exfiltration
Benefit: Improves application performance
▪ Internal Threats
3. Better Application Performance
▪ Worm propagation
Benefit: Improves user experience No Security ▪ Unauthorized access
Branch WAN Edge
▪ Data Hoarding
4. Centralized Policy/Monitoring
Benefit: Consistent Security Policy & monitoring
Users
Threat Landscape and Types of Threats
Types of Threats
Threat Landscape
▪ Security bug / Vulnerability
▪ Cyber Warfare
▪ e.g.: Heartbleed, SMBv1 vulnerability, IKEv1
▪ Nation-State Sponsored vulnerability, SQL Injection, Buffer Overflow,
▪ Organized Crime / Targeted Attacks Cross-site request forgery, Cross Site Scripting
▪ Ransomware (XSS)
▪ Cryptojacking ▪ Malware
▪ Sextortion ▪ Viruses, Worms, Trojans
▪ Financially Motivated ▪ Phishing, Adware, Spyware, Scareware
▪ Keyloggers, Backdoors, Exploits, Rootkits
▪ Denial of Service
▪ e.g.: Dyn Attack (Oct 2016)
▪ Botnets
▪ e.g. : LinkedIn attack (Aug 2016), Deutsche
Telekom (Nov 2016)
High Profile Incidents and their Targets
▪ Denial of Service ▪ Malware

▪ Dyn attack (Network Infrastructure) ▪ Stuxnet (Industrial Control Systems)
▪ Mirai Botnet (IoT devices) ▪ IKEv1 Vulnerability (Network Devices)
▪ Ransomware (Application & Network) ▪ VPNFilter (Network Devices)
▪ CryptoLocker, CryptoWall ▪ Yahoo! Data breach (Users)
▪ WannaCry ▪ 3 billion user accounts (Web Application)
▪ Petya, Bad Rabbit, Nymaim, Sage
▪ Cryptojacking (User Endpoints)
▪ Cryptocurrency Miners
Layered Branch Security with SD-WAN
▪ Pick and choose the appropriate security controls

▪ Embedded DDoS protection
VPN1 Users
VPN2 Compliance
VPN3 DIA and Cloud
SD-WAN Basic Dedicated Cloud

Security Filtering Security Security
Use Case Based Platform Positioning
SD-WAN Security Overview
Orchestration Plane Management Plane Transport Security

vManage ▪ Control Plane Security
▪ Traffic between WAN
Edges & Controllers
▪ Data Plane Security
vBond ▪ Traffic between WAN
Edges
Data Plane Control Plane
vSmart Controllers Infrastructure Security
▪ WAN Edges
MPLS 4G ▪ Controllers
INET
vEdge Routers Threat Defense

▪ WAN Edges to Internet
Cloud Data Center Campus Branch CoLo

How is SD-WAN Threat Defense Delivered?
Internet Internet
Internet Internet
VPN FW URLF IPS AMP Cisco Umbrella
VPN FW URLF IPS AMP

Branch
Regional
Hub
VPN FW URLF IPS AMP Branch 1 Branch 2 Branch 1 Branch 2
Branch
Integrated Dedicated Service Chained Cloud Delivered

What is a Typical Security Stack that most vendors offer
as part of SD-WAN Security?
▪ Stateful Firewall (Layer 4 inspection)

▪ Application Control (Layer 7 inspection)
▪ IPS (Signature Detection)
▪ DNS/Web/Content Filtering (Application inspection)
▪ IP Reputation (Block known bad IPs)
▪ File Reputation (Block known bad Files)
▪ Anti-Malware / Anti-Virus (Signature / Heuristic Detection)
▪ Sandboxing Capabilities (Zero day threats)
▪ CASB (Cloud Access Security Broker) (Cloud Applications)
▪ TLS/SSL Decryption (Man in the Middle) (Encrypted Applications)
Combining Best of Breed in Security and SD-WAN
SD-WAN Security
vManage 19.1 – Security Support
Platforms / Ent FW Ent FW App IPS/IDS URL AMP/TG DNS/web-layer
Features Awareness Filtering Monitoring *
Viptela - (100, 1000, Y DPI using N/A N/A Y
2000 and 5000) Qosmos ** N/A
Cisco - CSR Y Y Y Y Y Y
Cisco – ENCS (ISRv) Y Y Y Y Y Y
Cisco – ISR4K (4451, Y Y Y Y Y Y

4431, 4351, 4331,
4321, 4221-X)
Cisco – ISR1K (1111X- Y Y Y Y Y Y

8P)
Cisco - ASR1K 1001-HX, Y Y N/A N/A NA Y
1002-HX, 1001-X,
1002-X)***
* Umbrella Subscription required for enforcement

** Stateful Firewall and DPI using QosMos are separate on the vEdge
*** Supported with default 4GB DRAM
Security App Hosting Profile & Resources
IPS / URL-F App Security Profile - Features Minimum Platform Platform Supported
Hosting Profile requirement
Default IPS + URLF (Cloud Lookup only) + 8GB Bootflash & ISR1K/4221X/4321
AMP (hash analysis) 8GB Memory 4331/4351/44xx
1 / 2 SP cores 4/8 vCPU CSR / ISRv
IPS + URLF (On-box DB + Cloud 16GB Bootflash &
High Lookup) + AMP (hash analysis) + 16GB Memory 4331/4351/44xx
Threat Grid (TG) 2 SP cores 4/8vCPU CSR/ISRv
▪ Enterprise FW and DNS/web-layer security will work with default 4 GB DRAM

SD-WAN Security Features – Order of Operation
IP Dest DNS
NBAR 2 VFR 4 CEF 5
Lookup 1 Security 3
▪ G0/0 – LAN facing
Ingress G0/0 ▪ G0/1 – WAN facing
• LAN to WAN
NAT DNS
FW IPS URL-F AMP NBAR Security
Egress G0/1
DNS Layer
VFR 2 NAT 3 CEF 4
1
Ingress G0/1
• WAN to LAN
FW IPS URL-F AMP DNS Layer NBAR
Egress G0/0
SD-WAN Security Overview
Use case: Use Case: Use Case: AMP in 2019

Cloud and DIA Industry Compliance Guest Services
DNS/web layer
Firewall security Firewall Firewall URL Filtering
IPS
vManage IPS
Direct Cloud Access SD-WAN
Cloud VPN1 VPN2 Data Center

Applications Applications
Employee Guest
Application Aware Firewall
▪ One or more VPNs are mapped to a

zone
Internet
▪ Intra-zone, inter-zone and zone to
DIA traffic policies
▪ Intra-zone and inter-zone traffic Inspect policy allows only Outside Zone
between multiple VPNs requires return traffic to be
route leaking allowed and drops any
new connections
▪ 1400+ layer 7 applications classified
▪ Block, pass or inspect traffic by WAN Edge
application category or specific
application
Users
▪ Supports 6 tuple matching Inside Guest
Users Zone Zone Devices
Service-VPN 1
Service-VPN 2 Service-VPN 3
Application Aware Firewall
▪ VPNs are applied to Zones, and Firewall Policies
are applied to zone pairs
▪ Zone policies are directional, provides directional
control of traffic
▪ Builds connections to allow return traffic
▪ TCP Enforcement
▪ First packet must be a SYN
▪ 3-way handshake must be completed before data
is transferred
▪ All subsequent traffic must fall within TCP window
▪ Stateful checking of traffic
▪ Examines Layer 4 header, Verifies TCP
Sequence and Acknowledgement numbers,
Verifies TCP flags
▪ Inspects traffic
▪ Examines Layer 7 header of packet
▪ Verifies packet conforms to application
specification
▪ Default drop policy
▪ Tight security for unreferenced traffic
Ent. Firewall App Aware: Intra-Zone Security
WAN Edge WAN Edge
Zone Zone
SD-WAN
VPN1 VPN1
Fabric
Default Action: D I P
Note:
Optional 5-tuple matching
Host Host Host Host
SD-WAN Site A SD-WAN Site B

Ent. Firewall App Aware: Inter-Zone Security
WAN Edge WAN Edge

VPN1-VPN2
Route Leaking
Zone Zone Zone
SD-WAN VPN1
VPN1 VPN2
Fabric
Default Action: D I P
Note:
Optional 5-tuple matching
Host Host Host Host
SD-WAN Site A SD-WAN Site B

Add Security Policy
Application Aware Firewall Provisioning
Application Aware Firewall Provisioning (Cont.)
Intrusion Prevention and Detection
▪ Snort IPS engine

▪ Runs in a service container on Cisco Internet
ISR4K Routers
Signatures
▪ Backed by global Threat Intelligence
(TALOS) signatures updated
automatically
▪ Inspects traffic in VPNs of interest
▪ Supports three levels of signature sets
▪ Connectivity—Less restrictive/better WAN Edge
performance (fewer rules)
▪ Balanced—Designed to provide protection
without a significant effect on system
performance Users Users
▪ Security—More protection/less performance
▪ Signature whitelist support
▪ Can run in detection mode
Snort IPS/IDS, URL Filtering & AMP Architecture
Snort
LXC
Control Plane
Virtual Ethernet
IOSd AppHosting Manager

Linux OS
Management VPG
Traffic VPG Virtual Ports (VPG)
Data Plane
Traffic Path
Data Plane
▪ IPS, AMP & URL Filtering services runs on a Linux Container (LXC), using control plane
resources
▪ Traffic is punted to Container using Virtual Port Group (VPG) interface
▪ Reserved CPU and memory for Container process enables deterministic performance
Intrusion Prevention and Detection Provisioning
Intrusion Prevention and Detection Provisioning (Cont.)
URL Filtering
▪ Runs in a service container on Cisco

ISR4K Routers
▪ Cloud lookup with local caching or
local lookup
▪ Local lookup downloads URL
database to the router
▪ 82+ Web Categories with dynamic
updates
▪ Inspects traffic in VPNs of interest
▪ Block based on Web Reputation
score
▪ Create custom Black and White Lists
▪ Customizable end-user notifications
URL Filtering Provisioning
URL Filtering Provisioning (Cont.)
URL Filtering Reporting
Advanced Malware Protection
▪ File reputation check powered

by Talos AMP
▪ Sandboxing and file analysis
for unknown signatures
powered by ThreatGrid Check
Signature
▪ Automated signature update
from ThreatGrid to Talos WAN Edge
Internet
▪ Inspects traffic in VPNs of
Check file
interest
▪ Leverages Snort engine to

identify file transfers
ThreatGrid
Malware Sandbox
Advanced Malware Protection Provisioning
Advanced Malware Protection Provisioning (Cont.)
DNS/Web-Layer Security
Cisco Umbrella
▪ Cloud-only DNS based inspection
▪ API Key registration

POP POP POP
▪ VPN-aware policies
▪ Global points of presence and

anycast IP for fastest response and
high availability
WAN Edge
▪ DNScrypt
▪ Local domain-bypass Users Users
▪ Intelligent Proxy
DNS DNS
DNS/Web-Layer Security Provisioning
DNS/Web-Layer Security Provisioning (Cont.)
DNS Security vs. URL Filtering
DNS Security URL Filtering
Looks only at DNS packets (preferred in Spain over URL-F) Looks within HTTP packet.
We have reporting (time, IP addr., domain browsed) in Umbrella portal Can whitelist/blacklist sub-domains.
(comes free with DNA license, user ID and password sent to customer via No reporting/visibility
email)
Refers to internal database to decide good/bad/unknown domain Reputation score
cloud On-prem
No memory 8GB or
16GB memory (if the URL-F database needs to be on-the-box)
Cisco Product Via Brightcloud/Webroot
• Comes with Umbrella at DNA-E/A (no enforcement, only monitoring) • Comes with DNA Advantage
• Enforcement with Umbrella Insights in DNA-P • Comes as part of embedded security in a IOSXE SD-WAN Cisco router
with 8GB memory
Configure Proxy CA
TLS/SSL Decryption Policy
TLS/SSL Decryption Policy (Cont.)
TLS/SSL Decryption Policy – Add Network Rule
TLS/SSL Decryption Policy – Add URL Rule
Transformation to Converged Cloud Security Service
Cisco Umbrella Evolution
Cisco’s Strategic Vision
Configure Umbrella SIG
▪ Configured as a
Feature
Template
▪ SIG Interface
▪ SIG Credentials
▪ Applied to
Device Template
Configure Umbrella SIG (Cont.)
Configure Umbrella SIG – Advanced Options
SD-WAN drives Security to Top-of-Mind
Customer Intent
• Protect Card Holder • Protect against liability • Trusted Cloud • Leverage the local
Data • Prevent guest users Applications internet path for all
• Protect Patient Data from disrupting • Provide better user Internet traffic
• Protect against data network experience • Protect against
breaches • Protect the enterprise potential threats from
branch coming in
Compliance Guest Access Direct Cloud Access Direct Internet Access
Transport Security: Application Control: Controlled Redirection: Application Control:

• IPsec VPN • AppAware Firewall • AppAware • AppAware
Attack Surface Attack surface
Attack Surface Attack Surface Attack Surface
Routing Firewall Risk
Perimeter Control: Segmentation: Exposure Exposure
Risk
Exposure Exposure Application Control: Attack Prevention: Exposure
• Firewall • VPN/FW Zone
• AppAware • IPS
Segmentation: Liability Protection:
Firewall Liability Protection:
• VPN/FW Zone • DNS/URL Filtering
Attack Prevention: • DNS/URL
Attack Prevention:
• IPS Filtering
• IPS
Malware Prevention: Malware Prevention:
• AMP • AMP
SD-WAN Security: vManage Provisioning Wizard
▪ Configuration > Security

SD-WAN Security: vManage Provisioning Wizard
▪ Create the required lists

▪ Applications
▪ IPS Signatures
▪ URL white/black lists
▪ Zones
▪ Integration with Cisco Umbrella
▪ Umbrella API Token
▪ Integration with Threat Grid
▪ Threat Grid API Token
The vManage REST API
▪ Goal: Programmability (not human

consumption)
▪ GUI is built on this API
▪ All (!) GUI operations available in API
▪ Documentation available on vManage
▪ REST (Representational State
Transfer) operations:
▪ GET
▪ POST
▪ PUT
▪ DELETE
The vManage REST API - Documentation
Example: Operations under “Device Inventory – Device”
Example: Get Device Details
(continued on next slide)

Example: Get Device Details - Parameters
(continued on next slide)

Example: Get Device Details – The Result
Example: Get Device Details – The Result
License & Limitations
Feature License Limitatons Comments

Level
Ent Firewall App Aware DNA E Applications to drop only. NBAR2 App Engine identifies 1400+ apps.
Stateful firewall is ZBFW.
IPS/IDS Needs min 8GB DNA E One global policy. Snort/TALOS signature updated automatically
RAM on router to No per vpn policy. by vManage and pushed to all devices.
run IPS/IDS/URL- No custom IPS signatures.
F/AMP/TG. No geo-IP address blocking.
URL-F DNA A One global URLF policy. Content filtering based on category &
No per vpn URLF policy. reputation score
AMP/TG DNA A TG has 200 files per day per org. Cloud lookup & cloud sandbox
limitations.
No private AMP/TG support.
10MB file limit for TG export.
DNS Monitoring DNA E No Enforcement, only Cloud based
monitoring and visibility. Need
separate license for
enforcement.
Stateful Firewall DNA E Not application aware. For vEdges, uses Qosmos DPI
Cisco DNA Licensing for SD-WAN
Simplified Packaging
DNA Premier
DNA Advantage Advanced Cloud Security Use-
Cloud-Scale SD-WAN Cases
DNA Essentials Use-Cases
Comprehensive Malware
Standard SD-WAN Malware Protection and URL-Filtering2 Protection w/ Sandboxing
Use-Cases (<50 Sites)
Application-based SLA Application Optimization for Multi-Cloud Umbrella Insights
Branch Security with Firewall and IPS Multi-Domain End-End Policy and Segmentation3
Includes Advantage
WAN Automation and Ease of Management Rich Services - Integrated Voice and Wan Opt4
Voice Optimization Analytics for Performance and Troubleshooting
FEC,
Full Mesh Basic Telemetry Unlimited Single Automated
Packet Dup
Hub Spoke, Visibility Segmentation, Orchestration for AMP, URL Service Stitching
Application FW,
Dynamic Routing (vManage) Fabric Multicast Cloud, Branch & Filter for Cisco and 3rd
IPS1
Support Colo Party VNFs
Includes Essentials
(1) (2) (3)(4) Capabilities supported only on ISR and CSR
Cisco DNA SD-WAN Licensing
Capability Based Packaging
Cisco DNA Essentials Cisco DNA Advantage Cisco DNA Premier

Simplified management & security protection for Advanced SD-WAN with enhanced security for feature- Advanced SD-WAN security will mitigate the most
the cost-conscious customer rich & valued branch deployment models sophisticated threats to your business
Enterprise firewall with Talos- Cisco AMP with SSL proxy

powered IPS and app controls Cisco Basic URL filtering Cisco Umbrella SIG Essentials®
Umbrella DNS Monitoring Cisco Umbrella app discovery (Full URL Filtering | Granular App
Control | File-type Controls | AMP |
Application-based SLA Cloud OnRamp for IaaS, SaaS, and Colo Threatgrid | L3 – L4 Cloud Firewall |
Basic WAN & path optimizations AppQoE & WAAS RTU Roaming User Protection With
AnyConnect)
Single centralized management Integrated border plus orchestration
console in the cloud or on-prem for campus, branch & DC NEW ‘Buy More’
DNA Premier SIG
Forward Error Correction (FEC) Seats
Integrated voice/UC gateways
Packet duplication
Flexible topology & dynamic routing

vAnalytics
(hub/spoke, partial/full mesh)
Cisco DNA Advantage
Up to 50 Device Overlay Cisco DNA Essentials Cisco DNA Essentials
*Each SIG seat equals about 50kbps of bandwidth traffic

Use-Case Based Packaging
Flexible Connectivity Application Optimization Security Multi-Cloud / Analytics

Comprehensive Malware
Premier
Protection w/ Sandboxing2 Advanced Cloud Security
Umbrella Insights
Fabric Multicast Integrated Voice Support (SRST Unlimited Segmentation SaaS Optimization
/FXO/ FXS)
Advantage
Automated Service Stitching for3rd Web Caching for WAN URL-Filtering2 Cloud OnRamp for IaaS (AWS and
Party VNF Optimization Azure)
Integrated Border for SDA and ACI Advanced Malware Protection2 WAN Analytics (vAnalytics)
DRE for WAN Optimization
Application-Aware Routing Voice Optimization (FEC) Application Aware FW

Essentials
Dynamic Routing Protocols (IPv4

and IPv6) TCP Optimization Snort Based IPS
Flexible Topology (Full Mesh) Packet Duplication Umbrella DNS Monitoring
(1) (2) (3)(4) Capabilities supported only on ISR and CSR

Bandwidth Licensing
▪ Bandwidth entitlement* on vEdge is the

sum of peak bandwidth (either upstream
or downstream) across all WAN circuits.
▪ Example: If a 50Mbps bandwidth license
MPLS 3G/4G/LTE Internet is purchased the sum of peak circuit
bandwidth (either upstream or
downstream) across Circuits 1, 2 and 3
must be less than or equal to 50Mbps.
▪ Bandwidth entitlement also includes
Circuit 1 Circuit 2 Circuit 3
▪ Split tunnel (Direct Internet Breakout)
▪ Traffic offloaded to 3rd party cloud
services i.e zScaler.
TLOC ▪ TLOC extension interface bandwidth is
extension not included in bandwidth entitlement.
Note: Entitlement assumes the peak
bandwidth usage 95% of the time. This
Branch
accommodates traffic bursts that might
happen.
SD-WAN Security – External Resources
▪ Deployment Guide:
https://community.cisco.com/t5/networking-documents/sd-wan-security-deployment-guide/ta-
p/3709936
▪ Configuration Guide:
https://www.cisco.com/c/en/us/support/routers/sd-wan/products-installation-and-configuration-
guides-list.html
▪ Troubleshooting Guide:
https://community.cisco.com/t5/networking-documents/sd-wan-security-troubleshooting-guide/ta-
p/3735301
▪ Cisco SD-WAN Validated Design:

https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/SDWAN/CVD-SD-WAN-Deployment-
2018OCT.pdf
Survey
▪ Evaluation survey for feedback

https://learning.nil.com/misc/evaluations/sdwa
nb-course-evaluation-webex-australia-july-26-
aug-6-2021
5 – Everything was OK
▪ 4 – There were problems out of everyones
control (connectivity issues, …)
▪ 3 - There were problems within instuctors
control (non-engaging content, failure to
answer questions, …)
▪ 2 – Major problems were occuring
▪ 1 – Critical problems, course didn’t finish

Cisco SD-WAN &amp; Security Bootcamp 20.1

Uploaded by

Document Information

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

Cisco SD-WAN &amp; Security Bootcamp 20.1

Uploaded by

Copyright:

Available Formats

CISCO SD-WAN & SECURITY

MICHAEL BEHRINGER <MBEHRINGER@NIL.SI>

Day 1 Day 2 Day 3

▪ Skills and experiences

Device Interface Username Password

Org-name: NIL Lab

Cloud Data Center Campus Branch SOHO

Cloud Data Center Campus Branch SOHO

WAN Edge Router

• WAN and voice module flexibility • Hardware and software redundancy

Virtual and Cloud

• Service chaining virtual functions

Basic Services Cisco ISR and ASR

Cisco vEdge or ISR1K

Cloud Data Center Campus Branch SOHO

Cloud Data Center Campus Branch SOHO

Network Centric Application/Flow Centric

▪ System-IP – Unique identifier of an OMP Endpoint

▪ Organization-Name – Defines the OU to match in the Cert Auth Process

▪ Site-ID – Identifies the Source Location of an advertised prefix

▪ Transport Side – WAN Edge Router Interface

MPLS INET Transport

▪ Traffic forwarded as is from original source

▪ OMP – Overlay Management Protocol

▪ TLOC Color used as static identifier for:

Public IP/Port Private IP/Port

1 Private Color to Private Color

2 Private Color to Public Color

3 Public Color to Public Color

T1, T3 – Internet Color T2, T4 – MPLS Color

T1, T3 – Internet1 Color T2, T4 – Internet2 Color

vBond vManage vSmart

VPN1 VPN2 Transport2 VPN1 VPN2

vEdge1 (192.168.1.1) NAT (Full Cone) vBond (203.0.113.1) vEdge2 (198.51.100.1)

Src= 198.51.100.1:12346 Src=198.51.100.1:12346

vEdge1 (192.168.1.1) NAT (Symmetric) vBond (203.0.113.1) vEdge2 (198.51.100.1)

Side A Side B IPSec Tunnel Status

Full Cone Full Cone

Full Cone Port/Address Restricted

Port/Address Restricted Port/Address Restricted

Full Cone Symmetric

Symmetric Port/Address Restricted

IP1 IP2’ IP1’ IP2

Successful IPSec connection

Cisco Cloud Ops MSP Ops Team Enterprise IT

Deploy Deploy Deploy

vManage vManage vManage

vSmart vBond vSmart vBond vSmart vBond

ESXi, KVM, AWS, MS Azure

ESXi, KVM, AWS, MS Azure

ESXi, KVM, AWS, MS Azure

1. Obtain software and verify system requirements

Devices vCPUs RAM OS Volume Database Bandwidth vNICs

1-250 16 32 GB 16 GB 500 GB, 25 Mbps 2

251-1000 32 64 GB 16 GB 1 TB, 100 Mbps 2

1001 or more 32 64 GB 16 GB 1 TB, 150 Mbps 2

▪ SSD required for normal vManage performance

▪ Transport interface for

1. Obtain software and verify system requirements

Devices vCPUs RAM OS Volume Bandwidth vNICs

▪ Only SSD based volumes are officially supported

▪ Local keyword in vbond

▪ Enabling management access

▪ Disable Tunnel interface for

Cisco SD-WAN & Security Bootcamp 20.1

Cisco SD-WAN & Security Bootcamp 20.1