0% found this document useful (0 votes)
487 views

Cisco SD-WAN (Viptela) Features Lab Guide

Uploaded by

JuanTancara
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
487 views

Cisco SD-WAN (Viptela) Features Lab Guide

Uploaded by

JuanTancara
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 80

Cisco SD-WAN (Viptela) Features Guide

Last Updated: 06-JULY-2018

Created in partnership with the Solutions Readiness Engineers.

About This Solution


Legacy networking technology has become increasingly expensive and complex, and it cannot scale to meet the needs of today's
multisite enterprises. The Viptela Secure Extensible Network (SEN), which is based on time-tested and proven elements of
networking, offers an elegant, software-based solution that reduces the costs of running enterprise networks and provides
straightforward tools to simplify the provisioning and management of large and complex networks that are distributed across
multiple locations and geographies. Built in to the Viptela SEN are inherent authentication and security processes that ensure the
safety and privacy of the network and its data traffic.

The Viptela SEN represents an evolution of networking from an older, hardware-based model to a secure, software-based, virtual
IP fabric. The Viptela fabric, also called an overlay network, forms a software overlay that runs over standard network transport
services, including the public Internet, MPLS, and broadband. The overlay network also supports next-generation software
services, thereby accelerating your shift to cloud networking.

The SD-WAN (Viptela) SEN is a Software-Defined WAN (SD-WAN). What separates the Viptela SEN from other SD-WANs is that
it re-imagines the WAN for a new generation of enterprise networks, separating the data plane from the control plane and
virtualizing much of the routing that used to require dedicated hardware.

The virtualized network runs as an overlay on cost-effective hardware, whether physical routers, called vEdge routers, or virtual
machines in the cloud, called vEdge Cloud routers. Centralized controllers, called vSmart controllers, oversee the control plane of
the Viptela fabric, efficiently managing provisioning, maintenance, and security for the entire SEN overlay network. Another device,
called the vBond orchestrator, automatically authenticates all other Viptela devices when they join the SEN overlay network.

This division of labor allows each networking layer to focus on what it does best. The control plane manages the rules for the
routing traffic through the overlay network, and the data plane passes the actual data packets among the network devices. The
control plane and data plane form the warp and weft of a flexible, robust fabric that you weave according to your needs, on your
schedule, over existing circuits.

The Viptela vManage NMS provides a simple, yet powerful, set of graphical dashboards for monitoring network performance on all
devices in the overlay network, from a centralized monitoring station. In addition, the vManage NMS provides centralized software
installation, upgrade, and provisioning, whether for a single device or as a bulk operation for many devices simultaneously.

The Viptela SEN is ideally suited to the needs of cloud networking. Viptela's virtual IP fabric supports software services that
streamline and optimize cloud networking, allowing you to take full advantage of the power of the overlay network for individual
cloud applications.

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 1 of 80
Figure 1. SD-WAN abstraction of Control, Data and Management Plane

About This Lab


The main activities in this lab are:

• Understanding the various components of the SD-WAN solution and how they communicate with each other

• Understanding ZTP and bringing up a site by leveraging ZTP

• Understanding & Creating Device & Feature Templates using vManage NMS for vEdge Devices

• Creating Centralized and Localized Policies using vManage NMS

• Understanding Segmentation and creating Control policies per VPN

• Service Insertion using Control Policies through vManage

• Application Firewalling using centralized Data Traffic Policies

• Application Aware Routing – Best path selection based on recognized application traffic

• Cloud Express (Cloud On-Ramp for SaaS)

Lab Profile and Contact Link


In this lab, you will be leveraging a pre-existing demo platform on dCloud (www.dcloud.cisco.com). This platform was originally
meant for demo purposes only, however, within this guide you will take a much deeper look at some of the features and
configurations of the SD-WAN solution. Since the platform was being purposed for demonstrations, a lot of the templates and
policies which you will configure today already exist. But, you will be building them from scratch instead of just implementing them.

Specifically, you will configure and review the following scenarios.

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 2 of 80
Exercise 1 – An overview of the SD-WAN vManage dashboard and discussion around Zero Touch Provisioning (ZTP) capability.
Branch site routers, with design best practices, can easily be provisioned by leveraging automation through zero touch provisioning
and centralized configuration. Centralized configuration utilizes the templates that can be pre-configured before device
deployment. You will also see how to do basic “System” level configurations through the CLI to bring up a vEdge device from
scratch.

Exercise 2 – Bidirectional Forwarding Detection (BFD) is used to check path liveliness and quality measurements. BFD packets
are also used to determine tunnel path MTU details. In this scenario you will be modifying a Feature Template to change some
BFD attributes on a vEdge device. You will then make similar changes through the CLI on another vEdge device. This will also
help you better understand the relation between a Feature and a Device Template.

Exercise 3 - Use the Hybrid WAN connectivity over multiple WAN transport connections. Show connectivity could be established
over any kind of transport, application steering over any transport. Use IP as transport to create flexible data plane topologies from
full-mesh to Hub-n-Spoke to any arbitrary topologies. Deploy policy to create a strict Hub-n-Spoke topology for Corporate and
IOT/PCI VPN segment. For GuestWiFi VPN in branches, only allow DIA.

Exercise 4 – Demonstrate with centralized policy to create different connectivity model/topologies per VPN segment.

• Corporate VPN – Full Mesh

• IOT/PCI Segment – Hub-n-Spoke

• GuestWiFi – Only DIA and no site-to-site communication

Exercise 5 – Demonstrate business defined insertion of services (FW, IPS, IDS, etc) utilizing centralized policies. Cisco SD-WAN is
a flexible architecture where services can be deployed in any of the site(s) irrespective of the physical topology. Simple policy
activation can make selected applications and sites go through the required service.

Exercise 6 – Show the simplicity of using application firewalling policies centrally. Various applications and/or flows would not be
allowed between sites. Simple centralized policy activation would enforce such policies to any site on the overlay.

Exercise 7 - Use the Application aware routing along with arbitrary topology networking to show the business policy driven view of
application classification, connectivity and QoS provisioning. Discuss Application Performance settings while highlighting the ability
of the network to dynamically switch paths to preserve a consistent application experience.

Exercise 8 – CloudExpress provides performance based path selection when multiple exits are available. Enable CloudExpress for
a given SaaS application on the Branches.

NOTE: In this demonstration we are not focusing on the standard SD-WAN use cases e.g. standard device level QoS, standard
routing protocols, standard network management interfaces, etc. The goal is to show advanced SD-WAN capabilities primarily
based on centralized control and policies.

NOTE: Cloud On-Ramp (IaaS solution) is not demonstrated due to limitation of the topology.

Contact Links
As of the writing of this document, the current relevant documentation could be found on:

https://docs.viptela.com
https://dcloud.cisco.com
Cisco Sales Connect

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 3 of 80
Cisco Live Videos on Demand
This lab was constructed using the following software and platform:

• The SD-WAN code 17.2 – https://viptela.com

• The dCloud’s : Cisco 4D SD-WAN (Viptela) v2

• MPutty – For SSH sessions to various vEdge cloud devices

Solution Components
Key components of the solution

• Orchestrator to orchestrate secure communication among all SD-WAN components (vBond)

• Central management and provisioning system (vManage)

• Centralized controller for routing and policy (vSmart)

• Data Plane routers (vEdge)

Notes on the Platform


This guide is intended to demonstrate some of the key functions within Cisco’s SD-WAN, this includes Zero touch provisioning,
Performance based Application path selection, Regional and Direct Internet Access, Policy based topology creation, and vManage
(Management, orchestration).

This demo is built in dCloud as a scheduled demo environment and is comprised of:

• Demo for ZTP, vManage, App aware routing

• Static simulated data

o Data cannot be modified

o Allows the effect of application of device provisioning or other changes

o Simply used to showcase some of the advanced SD-WAN use cases

This demo is intentionally limited in scope. Cloud Express is in this demo. Cloud On-Ramp for IaaS is not part of the demo.

Cisco Intelligent SD-WAN delivers an uncompromised user experience over any kind of transport, allowing the business to right
size their network with operational simplicity while lowering costs. Now, IT can fully utilize their WAN investments with the highest
performance, reliability, and security while ensuring that all next generation WAN capability requirements to avoid unexpected
expenses, unplanned downtime and unforeseen complications are accounted for.

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 4 of 80
Table of Contents
About This Solution ............................................................................................................................... 1
About This Lab ....................................................................................................................................... 2
Lab Profile and Contact Link ................................................................................................................... 2
Contact Links .................................................................................................................................................. 3
Solution Components ............................................................................................................................ 4
Notes on the Platform..................................................................................................................................... 4
Requirements ........................................................................................................................................ 7
Recommended Prerequisite Knowledge ................................................................................................................. 7
Disclaimer ............................................................................................................................................. 7
Topology ............................................................................................................................................... 8
Get Started ...........................................................................................................................................11
Exercise 1. Introduction to SD-WAN & ZTP Site Bring Up ..................................................................13
Solution Elements and Functional Roles................................................................................................................13
SD-WAN basic Fabric Terminology ........................................................................................................................14
ZTP using Feature Template ..................................................................................................................................14
Manually Configure System Parameters ...............................................................................................................24
Verify Branch 2 Network Connectivity ...................................................................................................................28
Exercise 2. Editing BFD Attributes using a Feature Template.............................................................32
BFD Overview .........................................................................................................................................................32
Configure BFD Feature Template...........................................................................................................................33
Exercise 3. Strict Hub and Spoke Topology .......................................................................................37
Understanding SD-WAN Policies............................................................................................................................37
Verify Existing Topology .........................................................................................................................................38
Create the Hub-n-Spoke Centralized Control Policy ..............................................................................................41
Policy Activation and Testing .................................................................................................................................51
Exercise 4. Multi-Topology/Different Topology per VPN ...................................................................55
Challenge ...............................................................................................................................................................55
Benefits – Reduce Cost and Complexity ................................................................................................................55
Objective ................................................................................................................................................................55
Steps .............................................................................................................................................................56
Exercise 5. Service Insertion FW .......................................................................................................60
Challenge ...............................................................................................................................................................60
Steps .............................................................................................................................................................61
Exercise 6. Application Firewalling using Centralized Policies ...........................................................63
Challenge ...............................................................................................................................................................63
Benefits – Reduce Cost and Complexity; Reduced Risk .........................................................................................63
Objective ................................................................................................................................................................63
Steps .............................................................................................................................................................64
Exercise 7. Application Aware Routing .............................................................................................67

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 5 of 80
Challenge ...............................................................................................................................................................67
Benefits – Reduce Cost and Complexity ................................................................................................................67
Objective ................................................................................................................................................................67
Steps .............................................................................................................................................................68
Exercise 8. Cloud OnRamp for SaaS (CloudExpress) ..........................................................................74
Objective ................................................................................................................................................................74
Steps .............................................................................................................................................................75
.............................................................................................................................................................80

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 6 of 80
Requirements
The table below outlines the requirements for this preconfigured demonstration.

Table 1. Requirements

Required Optional

● Laptop ● Laptop with Cisco AnyConnect

This lab was designed to run on Workstation 1 within the dCloud pod. If you desire to run this lab on your own laptop, the following
set up should be performed/confirmed prior to commencing with the lab:

• Windows (7 or 10) PC with Internet access

Recommended Prerequisite Knowledge

A basic understanding of Software Defined Networks is not mandatory but helpful

An understanding of Overlay solutions such as VPN, GRE, DM-VPN, etc.

Some understanding of IPSec is also appreciated

Disclaimer
This Guide is intended to demonstrate one way to create centralized Control and Data Policies through vManage, to meet the
specified requirements of each example. There are various ways that this might be accomplished, depending on the situation and
the customer’s goals/requirements. Please ensure that you consult all current official Cisco documentation before proceeding with
a design or installation. This lab is primarily intended to be a learning tool, and may not necessarily follow best practice
recommendations at all times , in order to convey specific information. This guide is not intended to be a deployment guide. It is
intended for learning purposes only.

In addition, this guide covers a subset of all available Device & Feature templates, Centralized and Localized Policies, Control and
Data Policies, Deployment techniques, etc. Detailed information can be found at www.cisco.com and/or www.docs.viptela.com

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 7 of 80
Topology
The topology includes 2 Data Centers and 2 Remote Branches. The topology has 3 different VPN/VRF Segments.

1. Corporate VPN (VPN 10)


Requires full mesh connectivity across ALL sites.

2. IOT/PCI Segment (VPN 20)


Requires Hub-n-Spoke between the DC and the Branches.

3. GuestWifi (VPN 40)


Not needed in the DCs. From the branches require DIA. No Site-to-Site communications.

Figure 2. dCloud Lab Topology VPN 10

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 8 of 80
Figure 3. dCloud Lab Topology VPN 20

Figure 4. dCloud Lab Topology VPN 40

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 9 of 80
OSPF is running in the DCs and Branch 2 in VPN 10. All other segments are using static routing/VRRP.

Table 2. Host IPs for testing data plane connectivity

Corporate PCI/IOT Guest Wifi Service Insertion

Site Site-ID VPN10 (Test IP) VPN20 (Test IP) VPN40 (Test IP) FW in VPN10
DC1 100 198.18.133.21 10.1.20.10 X 198.18.130.1

DC2 200 10.2.0.21 10.2.20.10 X 10.2.0.1

Branch 1 300 10.3.0.21 10.3.20.10 10.3.40.10 X


Branch 2 400 10.4.0.21 10.4.20.10 10.4.40.10 X

Corporate PCI/IOT Guest Wifi Service Insertion

Table 3. Device Addresses

Device System IP Interface IP


● vBond1 ● 11.11.11.11 ● 198.18.1.11

● vBond2 ● 21.21.21.21 ● 198.18.1.21

● vSmart1 ● 12.12.12.12 ● 198.18.1.12

● vSmart2 ● 22.22.22.22 ● 198.18.1.22

● vManage ● 10.10.10.10 ● 198.18.1.10

Table 4. Device Credentials

Device Username Password


● vBond1 admin admin

● vBond2 admin admin

● vSmart1 admin admin

● vSmart2 admin admin


● vManage admin admin
● vEdges admin admin

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 10 of 80
Get Started
BEFORE LAB PRACTICE

Cisco dCloud strongly recommends that you check the Lab Topology in this document on active session prior to Lab. This will
allow you to become familiar with the structure of the document and content.

It may be necessary to check all Device access prior to performing Lab.

PREPARATION IS KEY TO A SUCCESSFUL LAB DEPLOYMENT.

Follow the steps to schedule a session of the content and configure your presentation environment.

4. Initiate your dCloud session. [Show Me How]

NOTE: It may take up to 10 minutes for your session to become active.

5. For best performance, connect to the workstation with Cisco AnyConnect VPN [Show Me How] and the local RDP client on
your laptop [Show Me How]

Figure 5. Cisco AnyConnect

Figure 6. Cisco AnyConnect credentials

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 11 of 80
• Workstation 1: 198.18.133.36

Username: dcloud\administrator

Password: C1sco12345

NOTE: You can also connect to the workstation using the Cisco dCloud Remote Desktop client [Show Me How]. The dCloud
Remote Desktop client works best for accessing an active session with minimal interaction. However, many users experience
connection and performance issues with this method.

NOTE: In order to demonstrate the stats from the vManage dashboard, the dCloud session has to be up for more than 30 minutes.
Please plan accordingly.

PROCTORED LABS

If you are participating in a proctored lab, your instructor will provide you with your Cisco AnyConnect VPN [Show Me How]
credentials. You will continue to use the local RDP client on your laptop [Show Me How] and RDP to:

• Workstation 1: 198.18.133.36, Username: dcloud\administrator, Password: C1sco12345, Domain: dcloud

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 12 of 80
Exercise 1. Introduction to SD-WAN & ZTP Site Bring Up
Bandwidth augmentation does not have to be a simple point-to-point connectivity but also a flexible connectivity over any kind of
transport. This helps with lowering costs, maximizing investments, improving the application experience and delivering innovative
services across the organization with agility. Technology leaders are eager to lower operational complexity as they embrace SD-
WAN as a part of the overall business strategy.

Management solutions are a crucial part of making Fast IT into a reality. The Cisco SD-WAN solution can effectively be managed
on premise, in the cloud or with provider-managed offerings. One should not have to sacrifice critical solution capabilities based on
the desire for a simplified control point. vManage provides a single pane of glass to manage and operate your network efficiently.
vManage also provides open Northbound REST APIs that drive core network automations solutions and efficient operation.

Additionally, the vEdge routers also support a number of South-bound protocols that will enable your team to extend benefits to
both Greenfield and Brownfield environments.

Let’s see how SD-WAN can deliver branch agility with zero touch provisioning and centralized policy control.

This exercise provides an overview of the Manage Branch Sites component to show how devices are securely detected and
provisioned leveraging automation through ZTP.

NOTE: vManage periodically polls the statistical data from the devices. In order to display the graphical data properly on vManage
Dashboard, please let the dcloud session run for at least 45 minutes before conducting the demo.

The same would be true with bringing up the BR2-vEDGE1 for the first time. It may take up to 20-30 minutes to display the Flow
and DPI graphical data on the Device Dashboard.

Solution Elements and Functional Roles

vBond orchestrator

- Primary authenticator for all SDWAN components

- Facilitates discovery of the control elements by the vEdge routers

- Notifies vEdges of their public IP, if behind NAT

vManage is the network management system, a single pane of glass, for the entire SD-WAN fabric

vSmart controllers:

- Distribute reachability and security information between the vEdge routers

- Distribute data and app-route policies from vManage to vEdges. Enforce control policies.

- Perform best-path calculation for non ECMP routes and advertise best route to the vEdges (second best too, if
configured)

vEdge routers sit at the perimeter of an SD-WAN site and provide connectivity across the fabric. vEdge routers handle the

transmission of data traffic.

vEdge routers are offered as pre-integrated appliance or as a software-only virtual machine for ESXi, KVM, AWS and Microsoft
Azure platforms

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 13 of 80
SD-WAN basic Fabric Terminology

Before you begin with the initial exercise, it is crucial for you to know some of the basic terminology which is used throughout this
lab guide. The list is below with brief descriptions.

Overlay Management Protocol – Control plane protocol distributing reachability, security and policies throughout the fabric.

Transport Locator (TLOC) – Transport attachment point and next hop route attribute.

Color – Control plane tag used for IPSec tunnel establishment logic.

Site ID – Unique per-site numeric identifier used in policy application.

System IP – Unique per-device (vEdge and controllers) IPv4 notation identifier. Also used as Router ID for BGP and OSPF.

Organization Name – Overlay identifier common to all elements of the fabric

VPN – Device-level and network-level segmentation. Can be directly co-related to a Virtual Route Forwarding (VRF).

ZTP using Feature Template

1. RDP to Workstation 1 (198.18.133.36) and login with Username: dcloud\administrator and Password: C1sco12345.

Figure 7. Remote Desktop to Workstation 1

2. Launch the vManage GUI through a shortcut on Google Chrome and login using Username/Password: admin/admin.

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 14 of 80
Figure 8. Login to vManage

Figure 9. Open vManage GUI

3. Here, you will notice that the vManage GUI displays all the vEdges and the controllers in the top most ribbon. As you can see,
there are:

• 2 vSmart controllers – Deployed as an Active-Active cluster

• 2 vBond controllers – Deployed as an Active-Active cluster

• 6 vEdge Cloud devices

• 1 vManage management controller

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 15 of 80
Figure 10. vManage GUI displays the active SD-WAN components

4. Review the details displayed on the rest of the Dashboard:

• Control Status: Displays if the Overlay Management Protocol (OMP) running devices are up (2 X vSmarts and 6 X
vEdge)

• Site Health View: Displays the connectivity health between al SD-WAN sites

• Transport Interface Distribution: Displays the links which we have in the network and their speeds

• vEdge Inventory: Displays how many total vEdge devices is the vManage licensed for and how many are deployed

• vEdge Health: The vManage monitors the device health of all vEdge devices at each site

• Transport Health: Monitors if the underlay transports (MPLS, Internet, LTE) are up and running

• Top Applications: Displays top applications in terms of usage of the SD-WAN fabric

• Application Aware Routing: Displays SLAs like Latency, Jitter and Delay across all vEdge TLOCs (Transports)

Figure 11. Review Dashboard

5. The first task at hand is bring up the BR2-VEDGE1. This device is licensed for in the vManage whitelist (Serial Number and
Chassis List), however has not been brought up. You will learn how to bring up the device using 2 mechanisms:

• ZTP: You will simulate ZTP by associating a centrally configured Device Template with this vEdge device. The
vManage will push the configuration down to the vEdge through NETCONF/YANG. To completely simulate ZTP, the
only thing you need to do is access the vEdge and run a “no shutdown” on its primary WAN interface.

• CLI provision: Although, one of the primary business and technical reasons to use SD-WAN is its capability of ZTP,
you should still know about the basic System configuration. The System configuration is the basic configuration
needed on a vEdge for it to successfully register with the controllers. Therefore, you will revert the changes made and
then configure the BR2-VEDGE1’s System parameters manually.

Click on the vEdge option from the ribbon up top on the vManage Dashboard. This will display the currently active and
provisioned vEdge devices.

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 16 of 80
Figure 12. Currently active and provisioned vEdge devices

6. Before you associate the pre-configured template with the BR2-VEDGE1 device and bring the device up, access the device
through SSH and confirm that you have a backup of current configuration. This is made possible because an OOB
management interface is pre-configured on the vEdge device.

From the Task bar at the bottom of the RDP, launch MPutty . Once it opens, double click on the BR2-VEDGE1
and launch the session.

Figure 13. Connect with the BR2-VEDGE1

7. Access the Configuration Mode on the vEdge CLI and run the following command:
vedge# config terminal
vedge(config)# system
vedge(config-system)# host-name BR2-VEDGE
vedge(config-system)# commit
Commit complete.
BR2-VEDGE(config-system)#

This will force the system to write a new Startup configuration file and save it to the NVRAM. This step is important to create a
“Rollback” configuration file which you will use towards the latter half of this exercise.

You can view this rollback configuration option using the following command.
BR2-VEDGE(config)# rollback configuration ?

8. Mark the configuration “0” from the list of possible configurations to revert from later. Make sure that the file is configured by
“admin via cli” and not “system via system”.

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 17 of 80
Figure 14. Mark Possible 0

NOTE: The date and time on Possibility 0 in your lab pod might differ, however the idea is to choose the latest configuration file
configured by the admin cli (Step 7), so make sure to mark that one and that one only.

9. Now that you know which configuration file to revert to, navigate back to the vManage GUI and click on Configuration icon
and select Templates from the drop-down menu.

Figure 15. Navigate to Configuration Template

10. Various templates are shown. You will select the template named BranchType2 for this remote site. This preconfigured
template is how a customer would setup a template to use in the process of rolling out new branches.

Click on the three dots (…) in the right most column for BranchType2Template. From the drop down, select the option
Attach Devices.

Figure 16. Click on the three dots to open Template options

11. From the left pane labeled Available Devices, find the device with chassis-id/UUID of ddd801b2-8cbe-4394-abd1-
3b71e39886e3.

Move the selected device to the right pane labeled Selected Devices by clicking on the right arrow button

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 18 of 80
Figure 17. Attach device with Template

12. Once the device is moved to the right pane, click on Attach button. This will take you to the next configuration page.

13. Click on the dots (…) in the right most column and select Edit Device Template.

Figure 18. Template associated

Figure 19. Edit Device.

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 19 of 80
Figure 20. View the Update Device Template option

Click the Cancel button to go back to the previous page.

These values which you just viewed in the Edit Device Template Menu can be updated from the GUI, but for the purpose of this
lab, a CSV file has been created which will automatically fill out these values in the templates.

14. Click on the upload icon ( ) for uploading the CSV file. Click on Choose File. A Prebuilt CSV file named
“BranchType2Template.csv” is located in the folder \Desktop\SD-WAN Demo\csvConfigFiles on Workstation 1.

Figure 21. Upload CSV to vManage

15. Click on the Open button. Click Upload.

NOTE: You can copy the CSV file over to your own machine and view its contents. You will see that the CSV file contains the
“System” configuration parameters as well as some other configuration parameters which will be provisioned on the BR2 Vedge
device.

16. The values for the variables populate based on the uploaded CSV file. Click on Next.

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 20 of 80
Figure 22. Values populate based on the CSV

17. Click on the tab in the left column with BR2-VEDGE1 label to see the full CLI configuration for validation. Click on Configure
Devices.

Figure 23. View configuration preview before deploying

Wait for few seconds until the device Status changes from In Progress to Done – Scheduled.

Figure 24. Status changes to Done-Scheduled

18. Click on vManage dashboard icon. The dashboard icon shows that ONLY 6 vEdges are operational.

Figure 25. Only 6 vEdges

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 21 of 80
19. To simulate the device to be connected to the transport for ZTP, you will do no shut on the interface connected to Internet
transport in the lab [interface ge0/0].

20. Navigate back to the open MPutty session with BR2-VEDGE1 and issue the following command
show run system

Figure 26. Show run system

Note the default configuration for the system block with vbond pointing to ztp.viptela.com and no system-ip, site-id and
organization name.

21. Execute the following command


show run vpn 0
show run vpn 10

Notice that the Interface ge0/0 is in the shutdown state. You need to bring it up so that it can reach out to the vBond.

Figure 27. Interface is shutdown

From the output, you will see that the device has the default configuration for transport VPN 0 and no configuration for
service/LAN side VPN 10.

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 22 of 80
22. Now you will enable the interface so that the router can do the ZTP simulation.
config
vpn 0
interface ge0/0
no shut
commit
end

23. Return to the vManage dashboard. The BR2-VEDGE1 will come up and the dashboard will show total of seven (7) vEdges
are operational.

Figure 28. 7 vEdges operational

24. Click where it says 7 vEdge devices and on the pop up window you should now see the newly configured “BR2-VEDGE1”.

Figure 29. BR2-VEDGE1

NOTE: Pay attention to the fact that the hostname has now been overwritten to what you configured from the GUI. Also, the
system-IP, site-ID, etc have been configured in accordance to the CSV file which was uploaded.

25. Back on the SSH session, run the command “show run system” and observe the changes in the system configuration.
show run system

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 23 of 80
Figure 30. Show run system

- The hostname has changed to “BR2-VEDGE1”.

- The Latitude and Longitude has changed as per the CSV file.

- The system-ip is now configured to 10.4.0.1

- The site-id is now configured to 400

- The Organization Name is now configured to “Cisco Sy1 – 19968”

- Finally, the vBond server is changed to “vbond.cisco.com” from “ztp.viptela.com”

Manually Configure System Parameters

In the last section you successfully brought up the Branch vEdge at BR2 using the pre-configured template. Now in this section,
you will revert those changes and bring the vEdge back to its original state. Then, you will manually configure the system specific
parameters through the vEdge CLI and connect it to the controllers successfully.

26. To achieve the above, you must now rollback the BR2-VEDGE1 to the configuration you had saved in step 7. To do this, run
the following command:
BR2-VEDGE1(config)# rollback configuration ?

From the list of available configuration files, choose the one which has the same time-stamp as that from step 8. This is the
configuration you had saved before the vEdge was provisioned by the vManage.

Figure 31. Choose the one which matches the time-stamp

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 24 of 80
27. Run the following command to roll back the configuration.
BR2-VEDGE1(config)# rollback configuration 7
BR2-VEDGE1(config)# commit
Commit complete.
BR2-VEDGE(config)#

NOTE: The possible configuration number in your case could vary, be sure to match the time-stamp when revering.

28. Run the following commands to verify that the configuration has been reverted back.
BR2-VEDGE# show run system
BR2-VEDGE# show run vpn 0

Figure 32. Confirm configuration rollback

Figure 33. Show run vpn 0

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 25 of 80
29. Now go to vManage -> Configuration -> Devices, find BR2-VEDGE1.

• Then on the right side 3 dots, select “Decommission vEdge”, then confirm

• Then on the same 3 dots, select “Generate Bootstrap Configuration” -> Select “Cloud-Init”

• You should see the Cloud-Config file with OTP (token) and UUID (chassis-number)

This generates the unique OTP (token) against this license entry for a vEdge Cloud router. You will now manually provision
the BR2-VEDGE1 with this OTP and UUID and point it to the vBond for provisioning. Copy the details of this file to a notepad
on Workstation 1.

30. Go back to the vEdge SSH type the following from command prompt:

• request vedge-cloud activate chassis-number UUID token OTP (copy/paste from notepad)

• Example: vedge# request vedge-cloud activate chassis-number dxxxxxxx-8xxx-4xxx-axxx-3xxxxxxxxxx3 token


ffexxxxxxxxxxxxxxxxxxxxxxxxxxxx0

Note : UUID and OTP will be specific to each Pod , thus you need to replace them in above command.

Figure 34. Manually configure the vEdge with the OTP and the UUID

31. You will now manually configure the system parameters starting with bringing up the GE0/0 interface in VPN 0. Run the
commands below.
vedge# config terminal
vedge(config)# vpn 0
vedge(config-vpn-0)# interface ge0/0
vedge(config-interface-ge0/0)# no shut
vedge(config-interface-ge0/0)# commit
Commit complete.
vedge(config-interface-ge0/0)# exit
vedge(config-vpn-0)# exit

Run the command “show run vpn 0” to verify that the interface is indeed up.

Figure 35. The interface ge0/0 is now up

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 26 of 80
32. Now access the system specific configuration mode on the vEdge CLI and run the following commands.
vedge(config)# system
vedge(config-system)# system-ip 10.4.0.1
vedge(config-system)# site-id 400
vedge(config-system)# vbond 198.18.1.11
vedge(config-system)# organization-name "Cisco Sy1 - 19968"
vedge(config-system)# commit
Commit complete.

Figure 36. Manually configure the system parameters

NOTE: Be careful with the organization-name, there are white spaces, and case sensitive

33. You can now confirm that the vEdge is now connected to the vManage and the vBond controllers by running the command:
vedge# show control connections

PEER PEER CONTROLLER


PEER PEER PEER SITE DOMAIN PEER PRIV PEER PUB GROUP
TYPE PROT SYSTEM IP ID ID PRIVATE IP PORT PUBLIC IP PORT LOCAL COLOR STATE UPTIME ID
------------------------------------------------------------------------------------------------------------------------------------------------
vbond dtls 0.0.0.0 0 0 198.18.1.11 12346 198.18.1.11 12346 default up 0:00:08:25 0
vmanage dtls 10.10.10.10 10 0 198.18.1.10 12446 198.18.1.10 12446 default up 0:00:08:25 0

Figure 37. Show control connections

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 27 of 80
NOTE: A few commands to help you troubleshoot if connection did not come up *Contact proctor

show control connections-history

show control local-properties

show run vpn 0

show run system

show ip route vpn 0

ping vpn 0 198.18.1.11

34. Finally, attach the vEdge to the template “BranchType2Template” just like you did in the previous section (follow steps 9
through 17). The vEdge will be provisioned with all the details of the CSV file.

35. Once the configuration has been pushed to the vEdge, you should see the below result.

Figure 38. Successfully attach the template with the BR2-VEDGE1

Verify Branch 2 Network Connectivity

36. From the vManage menu, select Monitor > Network.

37. Select BR2-VEDGE1 from the list. The device dashboard for BR2-VEDGE1 displays.

Figure 39. Select BR2-VEDGE1 from monitor

38. From the menu, click on Control Connections. Validate control sessions are established to vSmart and vManage.

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 28 of 80
Figure 40. Control connections with the vManage and vSmart

NOTE: At this time, there is no policy defined for the overlay and hence we have full-mesh connectivity across all three VPNs (10,
20, 40).

39. To validate the IP connectivity, from the menu click on Troubleshooting. Click Ping under Connectivity. Use the following
IP addresses for validating IP connectivity.

To change to a different VPN, first change the Source/Interface back to Choose/Reset selections. As the network is
segmented with different VPNs (a.k.a. VRFs), you must ping destinations and use interfaces within the same VPN.

40. Enter destination

a) For DC1 Ping 198.18.133.21 with source VPN -10.

b) For DC2 Ping 10.2.0.21 with source VPN -10.

c) For Branch 1 Ping 10.3.0.21 with source VPN -10.

41. Select VPN 10 (the Corporate VPN) from the drop-down menu and select Source Interface from drop down menu. Click on
Ping button.

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 29 of 80
Figure 40. Go to Trouble shooting.

42. Return to Monitor > Network and select BR2-VEDGE1 from the list.

43. Click on DPI.

Figure 41. Verify Data

44. Click on Flows. This displays the IPFIX flow records.

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 30 of 80
Figure 42. Verify data flows

45. Click on Interfaces to see utilization of the links on the vEdge.

Figure 43. Verify interface mapping

Below is the table showing how the interfaces are mapped to different functions on different devices.
VEDGES Internet TLOC MPLS TLOC VPN10 Interface VPN20 Interface VPN40 Interface
DC VEDGES ge0/2 ge0/1 ge0/0 ge0/3 N/A
BR1-VEDGE1 ge0/1 ge0/0 ge0/3 ge0/4 ge0/5
BR1-VEDGE2 ge0/0 ge0/2 ge0/3 ge0/4 ge0/5
BR2-VEDGE1 ge0/0 ge0/1 ge0/2 ge0/3 ge0/4

This concludes this exercise.

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 31 of 80
Exercise 2. Editing BFD Attributes using a Feature Template
In this section, you will understand how multiple Feature Templates come together to complete a Device Template which is then
associated with a device and ends up configuring all its important attributes. You will learn this through an example; by changing
the parameters for Bidirectional Forwarding Detection (BFD) using a Feature Template.

BFD Overview

BFD is the path liveliness and quality measurement detection protocol. It determines if a Tunnel between two vEdge devices is Up
or Down, what is the loss/latency/jitter and in addition to that also determines the IPSec tunnel MTU.

It runs between all vEdge devices and vEdge Cloud routers in the topology. It runs inside the IPSec tunnels. It is automatically
invoked after each IPSec tunnel establishment. And it cannot be disabled.

Figure 44. Understanding BFD

To understand the figure above consider the following:

• Each vEdge router sends BFD hello packets for path quality and liveliness detection

• The packets are echoed back by the remote site and the RTT is noted.

• 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

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 32 of 80
Configure BFD Feature Template

In this exercise you will complete the following tasks:

• Create a new BFD Feature Template for BR2-VEDGE1 and change the:

o App-Route Multiplier to 3

o And the Poll Interval to 10000

o Finally associate it with the BR2-VEDGE1 Device Template, “BranchType2Template”

46. Navigate to the Configuration menu and select the Template option. From here select Feature Template.

Figure 45. Select Feature Template

There are multiple feature templates which already exist. These feature templates come together to form the attributes of a device
template. They help you automate configurations such as OSPF, BGP, BFD, TLOCs, Interface configurations, VPN configurations,
Service Insertions, etc.

47. Click on the Add Template button.

Figure 46. Click on Add Template

48. Select the type of device that this new feature template will be associated with, choose vEdge Cloud.

Figure 47. Select vEdge Cloud

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 33 of 80
49. Next, you will be asked to choose the template type. Choose “BFD”.

Figure 48. Choose template type as BFD

50. Configure the Template Name as “BranchType2BFD”. And assign a befitting description.

51. Change the Multiplier to 3 and the Poll Interval to 10000. Use the type as Global when configuring these values. Then click on
Save.

Figure 49. Add the BFD Template Attributes

52. You will now associate this Feature template with the BR2-VEDGE1 Device template. Navigate back to Device Templates and
select the template you need to edit.

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 34 of 80
Figure 50. Select the Device Template

53. There is already a BFD feature template associated with this device template. Change that to the one you just created.

Figure 51. Change the BFD template

54. Click on Update. You will be navigated to the Device Template association page. Click on Next and then on the next screen,
click on Configure Device.

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 35 of 80
Figure 52. Device configuration.

55. Wait till the configuration push changes from “Scheduled” to “In progress” then it go to “Success”. Then go back to the SSH
session for BR2-VEDGE1.

Figure 53. Configuration successfully updated

56. On the SSH session run the command:


BR2-VEDGE1# show running-config bfd app-route

Figure 54. The BFD App-Route stats have changed

This concludes this exercise.

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 36 of 80
Exercise 3. Strict Hub and Spoke Topology
Enterprises may not need a full mesh topology and would like to have a pure Hub-n-Spoke IPSec/BFD topology. This will provide
the scalability and simplicity for the branches. A simple centralized policy creation and activation will convert full mesh connectivity
to Strict Hub-n-Spoke.

In this case, you will create a fabric with IPSec tunnels only getting established between the spokes and the DCs. Based on policy
you will not establish any IPSec tunnels between the Branches.

For corporate VPN 10, you will only advertise the Branches’ routes to the DCs and not to other Branches. The DCs are
advertising default routes and hence when a branch needs to talk to other branches, they will take the default to the DCs. The DC
vEdges then route the traffic back to the other remote Branches.

For the PCI/IOT segment (VPN 20), you will advertise the routes between the Branches by setting the next-hop pointing to the
DCs TLOCs. This is being done to provide Hub-n-Spoke communication between the Branches through the DCs as there is no
default route being advertised from the DCs.

For guest WiFi VPN 40, you don’t need any communication between the branches. We will restrict the route exchange between
sites for VPN 40. There will be only one static default route in VPN 40 providing direct internet access.

The objective therefore is to use centralized control policy to create a Hub-n-Spoke IPSec/BFD topology while maintaining branch-
to-branch communication for VPN 10 and VPN 20.

Understanding SD-WAN 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 vEdge routers

Figure 5. Policies in SD-WAN

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 37 of 80
• 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 vEdge 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 vEdge 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 vEdge 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 vEdge routers.

Verify Existing Topology

57. Go to vManage. Click on the Monitor > Network.

58. Select BR2-VEDGE1.

Figure 6. Select BR2-VEDGE1

59. Select Tunnel from the left column.

60. The next screen shows IPSec tunnels are established to the DCs and the remote Branch-1 (full mesh).

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 38 of 80
Figure 7. Full Mesh Topology

61. Select Troubleshooting from the left column.

62. Select Trace Route under Connectivity.

63. Enter 10.3.0.21 as the destination IP for Branch1.

64. Select VPN 10 and leave source interface unselected from the drop down menu. Click Start.

Figure 8. Run traceroute from BR2 to BR1 in VPN 10

65. It shows direct connectivity between the Branch1 (10.3.0.21) and Branch2.

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 39 of 80
Figure 9. Shows direct connectivity

66. Do the same for VPN 20 with Destination IP of 10.3.20.10.

67. Click on Select Device and select BR1-VEDGE1.

68. Select Trace Route.

69. Enter destination IP of 10.4.0.21, select VPN 10 and leave the source interface unselected.

70. Click Start.

Figure 10. Run traceroute

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 40 of 80
71. Enter destination IP of 10.4.20.10 and select VPN 20.

Figure 11. Run in VPN 20

Create the Hub-n-Spoke Centralized Control Policy

You will now create a centralized control policy which will, as described at the start of the exercise, force all traffic for both VPN 10
and 20 through the DC vEdges.

To configure centralized policies, use the vManage policy configuration wizard. The wizard consists of four sequential screens that
guide you through the process of creating and editing policy components:

• Create Applications or Groups of Interest—Create lists that group together related items and that you call in the match
or action components of a policy.

• Configure Topology—Create the network structure to which the policy applies.

• Configure Traffic Rules—Create the match and action conditions of a policy.

• Apply Policies to Sites and VPNs—Associate policy with sites and VPNs in the overlay network.

In the first three policy configuration wizard screens, you are creating policy components or blocks. In the last screen, you are
applying policy blocks to sites and VPNs in the overlay network. For a centralized policy to take effect, you must activate the policy.

72. From the menu, select Configuration > Policies.

NOTE: There are pre-existing policies for all the following exercises in your dCloud pod. You can choose to activate them directly
and view the results or you can create them from scratch. In this exercise, the guide will show you how to create one from scratch.

73. Stay under Centralized Policy and click on Add Policy. You will be taken to the Create Group of Interest page. You are not
required to create a group of interest for this exercise as the required ones are already created for you beforehand. The ones
which you will be using for this exercise are:

• Data Prefix Group – RFC1918Plus. It contains all known addresses in the topology.

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 41 of 80
Figure 12. Data Prefix Group

• Site Group – AllBranches & AllDC. Contain the groupings of all branch site IDs and DC site IDs respectively.

Figure 13. Site Group

• TLOC Group – DC-TLOCS. Contains all the TLOCs from the two DC vEdge devices.

Figure 14. TLOC Group

• VPN Group – corpVPN, pciVPN & guestVPN. Contains the individual VPNs of 10, 20 and 40 respectively.

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 42 of 80
Figure 15. VPN Group

74. Click Next to move onto “Configure Topology and VPN Membership”. Here, you will add a new Custom Control topology.

75. A custom control topology will allow you to manipulate the OMP and TLOC routes on the vSmart. Click on “Add Topology”

76. You need to choose “Custom Control” from drop down menu.

77. Give your new topology a name. You can name it “SRE-Hub-n-Spoke”. Also assign it a description.

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 43 of 80
Figure 16. Name the new custom topology

78. Click on “Sequence Type” and from the pop up select TLOC.

Figure 17. Add TLOC sequence type

79. Double click on the newly added sequence type and rename it to “AllowAllDC”.

Figure 18. Rename sequence type

80. Click on “Sequence Rule” and under “Match” click on “Site”. Choose the “AllDC” site group from the drop down.

Figure 19. Match AllDC Site Group

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 44 of 80
81. Under the “Actions” change from default value of Reject to Accept. Click on “Save Match and Action”.

Figure 20. Change action to Accept

This Sequence type will allow the vSmart to accept and learn about all TLOCs being advertised by the vEdges at the two
DCs.

82. You will now create another TLOC Sequence Type. This time your match condition will be blank and your action will be to
reject. This will let the vSmart controllers know to reject all other TLOC updates other than the ones allowed in the last rule.
Name this sequence type as “RejectAllOther”.

Figure 21. Reject all other TLOC advertisements

NOTE: Create the Sequence Types and Rules in the same order as the guide as the order is very important.

83. Next, you will create an OMP type sequence which will configure the vSmarts to reject any OMP update from the Branch sites
for the VPN 10 (Corp VPN).

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 45 of 80
Figure 22. Add OMP Sequence Type

84. Name this rule “RejectCorp”. Under match condition, you will be matching on two conditions: The Site group and the VPN
group as shown below. The action will be to reject. Click on “Save Match and Action” once done.

Figure 23. Reject OMP updates from All Branches for Corp VPN

85. Now, you need to create one last rule which will tie all OMP updates received from branch sites for VPN 20 (PCI VPN) to the
DC vEdge TLOCs. Thereby, making the DC vEdges as the next hop for those OMP routes. Name this sequence
“RoutesPCISetNHOP”.

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 46 of 80
Figure 24. Create another OMP sequence to tie VPN 20 updates with DC TLOCs

86. Lastly, you need to change the “DefaultAction” in the sequence list to “Accept” so that any unmatched traffic is allowed. This
will allow the default route through the DC to be advertised.

Figure 25. Change Default Action to Accept

87. Click on “Save Control Policy”.

88. Next, you must create a “VPN Membership” to define the scope of the rules which just created as part of the Topology
configuration. Since these rules are only applicable to the Corp and PCI VPN and only on the Branch sites, that is what your
scope will be. Configure the membership as shown below.

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 47 of 80
Figure 26. Configure VPN Membership for VPN 10 & 20 at the Branch sites

89. Click Next. This will take you to the “Configure Traffic Rules” page which allows you to create policies to manipulate Data or
Application specific traffic. Here you only have to create to a single “Traffic Data” rule which you will later apply to VPN 40.
This rule will block access to any IP from the VPN 40 (Guest VPN) services/LAN side.

Figure 27. Create Traffic Data policy

90. Give your traffic data rule the name “Deny1918” and a description as shown below. Add a “Application Firewall” sequence
type.

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 48 of 80
Figure 28. Application firewall sequence rule

91. Create the details of the rule as shown in the figure below.

Figure 29. Drop based on destination prefix

92. Make sure to change the “Default Action” here to Accept from the default value of Drop as that will block all traffic.

Figure 30. Change default action to accept

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 49 of 80
93. Click on Save Data Policy.

94. Back on the policy configuration page, click on Next. Finally, you now must define the overall scope of the entire policy and in
which direction will it be applied.

Control policies can be applied in one of two directions:

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.

95. Under the name of your custom created Topology, click on “New Site List”. This will now let you select the direction of your
policy. Based on the rules which were created, this will be an Outbound Policy applied on All Branch sites as shown below.

Figure 31. Add the outbound topology

96. Click on Add. As soon as you do that, you will see that the associated VPN Membership list also gets allocated.

Figure 32. VPN membership gets allocated

97. You will now have to associate the data policy which was created to the Guest VPN 40. To do this, click on “Traffic Data” from
the same page. You will see your “Deny1918” data policy appears under this option. It just needs to be assigned to a Site and
VPN list. Configure it as shown in the figure below.

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 50 of 80
Figure 33. Associate the data policy with site and vpn

98. Give your policy a name and description.

99. Finally, click on Save Policy.

Policy Activation and Testing

Activating a centralized policy sends that policy to all connected vSmart controllers. To activate a centralized policy:

100. Navigate to Configuration Policies and you will see the policy which you just created.

101. Click on the three dots all the way to the right to open the menu. Once open, click on “Activate”.

Figure 34. Activate policy

102. A pop up window will ask you to confirm activation on the two vSmart controllers. Click on Activate.

103. Wait until the policy activation Status changes to Success.

NOTE: The policy is applied to the vSmart controllers. vSmart will push the policies to the appropriate vEdge routers.

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 51 of 80
Figure 35. Policy successfully configured

104. Validate Hub-n-Spoke topology by selecting Monitor > Network.

105. Select BR2-VEDGE1.

106. Select Tunnel from the left column. The tunnels between the two branches are no longer up.

Figure 36. Select tunnel from the left panel

107. Select Troubleshooting from the left column.

108. Select Trace Route.

109. Trace the route from BR2 to BR1 by entering 10.3.0.21 as the destination IP for Branch1.

110. Select VPN 10 and leave source interface unselected from the drop down menu. Click Start.

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 52 of 80
Figure 37. Run the traceroute again to see the flow

The inter-branch traffic path now traverses the DC for VPN 10.

111. Trace the route from BR2 to BR1 by entering 10.3.20.10 as the destination and selecting VPN 20.

Figure 38. Run the traceroute in VPN 20

The inter-branch traffic path now traverses the DC for VPN 20.

112. To de-activate the policy, select Configuration > Policies.

113. Highlight the Hub-n-Spoke policy and click the three dots to the right of the policy name.

114. Select Deactivate.

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 53 of 80
Figure 39. Deactivate policy

115. The policy status will change from In Progress to Success, and the policy is successfully removed from vSmart-1 and
vSmart-2. Full mesh connectivity has been restored.

This concludes this exercise.

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 54 of 80
Exercise 4. Multi-Topology/Different Topology per VPN
Enterprises may have multiple VPN segments and may need different connectivity models/topologies. The default in Cisco SD-
WAN is to have full mesh for all VPNs. In scenario 2 we demonstrated how you can restrict ALL VPNs to be Hub-n-Spoke.

In this scenario we will demonstrate the following topologies for different VPNs using policies.

Corporate VPN 10 – Full Mesh

PCI/IOT VPN 20 – Hub-n-Spoke

GuestWiFI VPN 40 – DIA ONLY in Branches

Challenge

• Arbitrary topology creation and management is a complex task and may require touching all the branches and/or involving
the provider.

Benefits – Reduce Cost and Complexity

• Simple activation of policy from central vManage. Results in simpler operations, reduced cost and reduction in time/effort.

Objective

Create different connectivity topologies per VPN

• Corporate VPN 10 – Full Mesh Topology

• IOT/PCI VPN 20 – Hub-n-Spoke

• GuestWiFi VPN 40 – DIA Only in Branches

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 55 of 80
Steps
116. Go to vManage. Click on the Monitor > Network

117. Select BR2-VEDGE1.

118. Select Troubleshooting from the left column.

119. Select Trace Route.

120. Enter 10.3.0.21 as the destination IP.

121. Select VPN10 from drop down menu.

122. Click on Start button. It shows direct path between Branch 1 and Branch2 for VPN 10.

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 56 of 80
123. Do the same for VPN 20 using the destination IP of 10.3.20.10.

NOTE: This shows direct connectivity between Branch1 and Branch2 for VPN 20.

124. From the menu, select Configuration > Policies.

125. Click on the three dots to the right of MultiTopologyPolicy.

126. Click on Activate.

127. When the policy has successfully been pushed to the VSmarts, the activation status changes to Success.

128. From the menu, select Monitor > Network.

129. Click BR2-VEDGE1.

130. Select Troubleshooting from the left column.

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 57 of 80
131. Select Trace Route and enter 10.3.0.21 as the destination IP.

132. Select VPN 10 from drop down menu.

133. Click on Start button to display the direct path between Branch1 and Branch2 for VPN 10.

134. Do the same for VPN 20 using the destination IP 10.3.20.10 to display the connectivity between Branch1 and Branch2 through
the DC.

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 58 of 80
135. To de-activate the policy, select Configuration > Policies.

136. Highlight the policy and click the three dots to the right of the policy name.

137. Select Deactivate.

138. Click Deactivate.

139. The policy status will change from In Progress to Success, and the policy is successfully removed.

This concludes this exercise.

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 59 of 80
Exercise 5. Service Insertion FW
When new branches are added from an acquired entity, the enterprise may initially want the direct branch to branch
communication to go through the FW in the DC or a Colo/Regional facility hosting FW services.

Using Cisco SD-WAN one can place services anywhere in the network and, based on policies, can make certain flows/sites have
traffic go through those services.

Zone-based firewalls are a type of localized data policy that allows stateful inspection of TCP, UDP, and ICMP data traffic flows.
Traffic flows that originate in a given zone are allowed to proceed to another zone based on the policy between the two zones. A
zone is a grouping of one or more VPNs. Grouping VPNs into zones allows you to establish security boundaries in your overlay
network so that you can control all data traffic that passes between zones.

Zone configuration consists of the following components:

• Source zone—A grouping of VPNs where the data traffic flows originate.

• Destination zone—A grouping of VPNs where the data traffic flows terminate. A VPN can be part of only one zone

• Zone-based firewall policy—A data policy, similar to a localized data policy, that defines the conditions that the data traffic
flow from the source zone must match to allow the flow to continue to the destination zone. Zone-based firewalls can match IP
prefixes, IP ports, and the protocols TCP, UDP, and ICMP. Matching flows can be accepted or dropped, and the packet headers
can be logged. Nonmatching flows are dropped by default.

• Zone pair—A container that associates a source zone with a destination zone and that applies a zone-based firewall
policy to the traffic that flows between the two zones.

Matching flows that are accepted can be processed in two different ways:

• Inspect—The packet's header can be inspected to determine its source address and port. The address and port are used
by the NAT device to allow traffic to be returned from the destination to the sender.

• Pass—Allow the packet to pass to the destination zone without inspecting the packet's header at all. With this action, the
NAT device blocks return traffic that is addressed to the sender.

Challenge

• Arbitrary topology creation and management is a complex task and may require touching all the branches and/or
involving the provider. Previously, FW or any other service had to sit in path but with service insertion the FW could
sit in any of the enterprise locations.

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 60 of 80
Steps
140. From the menu, select Configuration > Policies.

141. Click the three dots to the right of the policy named MultiTopologyPlusFWInsertion.

142. Select Activate.

143. Click Activate.

144. Wait until the policy is successfully pushed to vSmarts.

145. From the menu, select Monitor > Network.

146. Click on BR2-VEDGE1.

147. From the left column, select Troubleshooting.

148. Select Trace Route.

149. Enter the destination IP 10.3.0.21 in VPN 10.

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 61 of 80
You will see traffic going through FW (198.18.130.1 or 10.2.0.1) sitting in DC1 and DC2 respectively

150. Repeat the same with BR1-VEDGE1 using the destination IP of 10.4.0.21

NOTE: Quickly change device context by using the blue Select Device drop down menu located in the top left.

151. From the menu, select Monitor > Policies.

152. Click the three dots to the right of the MultiTopologyPlusFWInsertion policy.

153. Select Deactivate.

154. Click Deactivate.

155. The policy status will change from In Progress to Success, and the policy is successfully removed from the vSmarts.

This concludes this exercise.

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 62 of 80
Exercise 6. Application Firewalling using Centralized Policies
There are cases where an enterprise would like to implement security/packet filtering policy on demand based on network
anomalies and/or business requirements. In this scenario we don’t want the PCI segment (VPN 20) in Branch1 and Branch2 to be
able to communicate with each other. We do want the PCI segment to talk to the servers in the DCs.

This policy will be implemented as a centralized data policy where based on source and destination prefix match, traffic between
BR1 and BR2 is dropped in VPN 20. The PCI/IOT segment only requires connectivity to DC from remotes. More granular matches
can be done to limit certain applications and allow other applications to flow between the Branches.

Challenge

• Implementation and maintenance of router based FW/ACL rules requires touching all the Branch routers. This is a manual
and complex task, prone to human errors and may require significant time/effort.

Benefits – Reduce Cost and Complexity; Reduced Risk

• Simple activation of policy from central vManage. Results in simpler operations, reduced cost and reduction in time/effort.

• Consistent and Centralized policy deployment reduces the risk of missed policy application and human error.

Objective

Deploy additional data policy to drop traffic between Branch 1 and Branch 2. The Multi-Topology control policy has to remain in
place.

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 63 of 80
Steps
156. From the menu, select Monitor > Network.

157. Select BR2-VEDGE1.

158. Click Troubleshooting.

159. Select Ping.

160. Validate connectivity from BR2-VEDGE1 to the test host in Branch3 in VPN 10 by entering the destination IP 10.3.0.21.

161. Click Ping.

162. Validate the connectivity from BR2-VEDGE1 to the test host in Branch3 in VPN 20 using the destination IP of 10.3.20.10.

163. From the menu, select Configuration > Policies.

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 64 of 80
164. Click the three dots to the right of the MultiTopologyPlusACL policy.

165. Select Activate.

166. Click Activate.

167. Wait until the policy is successfully pushed to both the vSmarts.

168. From the menu, select Monitor > Network.

169. Select BR2-VEDGE1

170. Click Troubleshooting.

171. Select Ping.

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 65 of 80
172. Validate connectivity from BR2-VEDGE1 to the test host in Branch1 in VPN 10 by entering the destination IP 10.3.0.21.

173. Click Ping.

174. Validate there is no connectivity from Branch2 in VPN 20 using the destination IP of 10.3.20.10

175. From the menu, select Configuration > Policies

176. Click the three dots to the right of the MultiTopologyPolicy policy.

177. Select Activate.

178. Click Activate.

179. Wait until the policy is successfully pushed to both the vSmarts.

180.

This concludes this exercise.

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 66 of 80
Exercise 7. Application Aware Routing
Talk about the fast deployment model for flexible topologies, any type of circuit could be deployed, which provides the ability to
direct different types of traffic over different types of links. Video could go over the internet, mission critical applications can go over
MPLS. LTE could be circuit of last resort. This provides path diversity and high availability.

Talk about the importance of new application delivery models, having the capability to move traffic based on application
performance.

In this demonstration, some of the applications have already had SLAs defined and are pinned to the MPLS (interface ge0/0 on
BR2-VEDGE1). Some applications have been pinned to the internet transport (interface ge0/1 on BR2-VEDGE1).

The policy is applied to ALL sites, so the policy has impact on all the traffic received and sent by BR2-VEDGE1. More traffic is
received than sent by the BR2-VEDGE1. Look at the traffic received by BR2-VEDGE1 on the mpls interface (ge0/0) and the
internet interface (ge0/1).

You will observe the traffic received switch from the mpls interface to internet interface after the latency impairment on the MPLS
transport.

Challenge

• Dynamic path selection based on transport performance is complex to deploy and hard to update policies on demand.

Benefits – Reduce Cost and Complexity

• Simple activation of policy from central vManage. Results in simpler operations, reduced cost and reduction in time/effort.

Objective

Define SLA based policies and re-route traffic as the transport network conditions change.

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 67 of 80
Steps
181. From the menu, select Configuration > Policies.

182. Click the three dots next to the MultiTopologyPlusAppRoute policy.

183. Select Activate.

184. Click Activate.

185. Wait until the policy is successfully pushed to both the vSmarts.

NOTE: The device dashboard for BR2-VEDGE1 displays the current performance measurement on both the transports.

Figure 40. This concludes this exercise.

186. From the menu select Monitor > Network.

187. Click BR2-VEDGE1.

188. Select Real Time.

189. Search for App Routes Statistics using the Device Options search.

190. Select App Routes Statistics and click Do Not Filter on the pop up.

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 68 of 80
NOTE: These values are much lower than the SLA definitions defined for the app-route policies.

191. Scroll to the right to see the columns showing (Mean and Average) Latency, Loss and Jitter for each of the tunnels on
MPLS and Internet.

NOTE: Simulate Flows provides a simulation on what IPSec tunnels will used for the defined flow based on policies and transport
performance measurements.

192. Select Troubleshooting.

193. Click Simulate Flows.

194. Select VPN 10.

195. Select the source interface.

196. Enter 10.3.0.10 as the destination IP address.

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 69 of 80
197. Click Advanced Options.

198. Enter the DSCP value of 46.

199. Click Simulate.

NOTE: This shows that the traffic class with DSCP of 46 will go over MPLS as it meets the SLA (latency <= 50msec) and is the
preferred color.

200. Open a new tab in your Chrome browser, click the WANem (Wan Emulator) bookmark.

201. Click Basic Mode.

202. Select Bridge br1.

203. Enter a value of 200 msec for delay for interface 2, which will introduce latency of 100msec on BR2-VEDGE1 on MPLS.

204. Click Apply Settings.

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 70 of 80
NOTE: Bridge br1 is connected to the MPLS transport.

205. Return to the vManage dashboard.

206. Select Monitor > Networks.

207. Select BR2-VEDGE1.

208. Select Real Time.

209. Filter by App Routes Statistics and click Do Not Filter in the pop up.

NOTE: You will observe high latency on MPLS IPSec Tunnels with no change on Internet tunnels.

The policy has an SLA definition of up to 5% packet loss and 50 msec latency for voice / video applications with preferred path of
MPLS.

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 71 of 80
210. From the menu, select Monitor > Network.

211. Select BR1-VEDGE1.

212. Click Interface.

NOTE: If the display defaults to 24 hours, change it to reflect the 1-hour or real time range for the traffic.

The BW chart shows that most traffic is going over MPLS path (ge0/1).

213. Return to WANem (Wan Emulator) tab.

214. Select br1 bridge and click Select Bridge.

215. Add 100 msec delay on both interfaces and apply the changes.

216. From the menu, select Monitor > Network.

217. Select BR1-VEDGE1.

218. Click Interface.

219. Click Real Time at the top right. The traffic switches from MPLS (ge0/1) to Internet Transport (ge0/2).

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 72 of 80
220. Return to the WAN Emulation tab and remove latency from the WAN Emulation tool.

221. From the menu, select Configuration> Policies.

222. Click the three dots to the right of the MultiTopologyPlusAppRoute policy.

223. Select Deactivate.

224. Click Deactivate.

225. The policy status will change from In Progress to Success, and the policy is successfully removed from the vSmarts.

This concludes this exercise!

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 73 of 80
Exercise 8. Cloud OnRamp for SaaS (CloudExpress)
Enterprises are increasingly making use of SaaS applications including Office365, Salesforce, Dropbox, Google Applications etc.
The primary method of connecting to these applications is through internet direct from the Branch using Direct internet Access
(DIA) or internet access provided from regional Hub or DC locations. A Branch may have multiple DIA exits as well.

The user experience is impacted by the loss, latency and jitter experienced on these internet exits. In the past, the connectivity to
SaaS application was static in nature and never accounted for the application performance and/or user experience based on real
time performance profile of these paths.

Cisco SD-WAN provides a method to run application probes for each one of these applications and computes the Viptela Quality of
Experience (vQoE) score for each one of the paths (DIA or regional Hub/DC internet exits). vEdge routers then, based on vQoE
scores, pick the best optimal path for a given SaaS application.

udExpress service optimizes the performance of Software as a Service (SaaS) cloud applications based on network loss and
latency. CloudExpress service provides clear visibility of the performance of individual applications and automatically chooses the
best path for each one.

CloudExpress service calculates a value called the Viptela Quality of Experience (vQoE). The vQoE value weighs loss and latency
using a formula customized for each application. For example, email applications tolerate latency better than video applications,
and video applications tolerate loss better than email applications. The vQoE value ranges from zero to ten, with zero being the
worst quality and ten being the best. CloudExpress service computes vQoE values for applications and paths, and then assigns
applications to the paths that best match their vQoE value. CloudExpress service periodically recalculates vQoE values for paths to
ensure ongoing optimal application performance.

CloudExpress Requirements

You can enable CloudExpress service in your Viptela overlay network on sites with Direct Internet Access (DIA) and on DIA sites
that access the internet through a secure web gateway such as Zscaler or iboss. You can also enable CloudExpress service on
client sites that access the internet through another site in the overlay network, called a gateway site. Gateway sites can include
regional data centers or carrier-neutral facilities. When you enable CloudExpress service on a client site that accesses the internet
through a gateway, you also enable CloudExpress service on the gateway site.

Objective

Add a new Application (Office365) in Corporate VPN 10 for CloudExpress.

Enable Cloud Express on the newly added site (BR2-VEDGE1).

CloudExpress is off by default in Cisco SD-WAN. All aspects of configuration and visibility are done from vManage GUI portal.

The first step to enable CloudExpress is to enable it in vManage Settings. For this demo, it is already enabled for the two DCs and
Branch-1

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 74 of 80
Steps
226. From the menu, select Administration > Settings.

227. Click Edit for CloudExpress.

228. Press Cancel to exit.

229. Go to CloudExpress Dashboard by clicking on the CloudExpress icon or selecting Configuration -> CloudExpress.

NOTE: CloudExpress dashboard will show you all the applications that are enabled for CloudExpress, number of sites and number
of devices.

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 75 of 80
230. Click on an application panel to view details for that application.

NOTE: The application dashboard shows the list of devices and the reported Viptela Quality of Experience (vQoE) score for the
application.

If you get a blank screen at this step, make sure that VPN10 is selected.

231. Click on the graph icon ( ) to display historical vQoE score graph for any device.

232. To add in a new application to the list, click on the Manage CloudExpress pull down and select Applications.

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 76 of 80
233. Click Add Applications and VPN.

234. Type Office in the applications box and select Office 365 in the drop down.

235. Enter Corporate VPN number (10).

236. Click Add.

237. Click Save Changes.

238. Wait until the new application configuration of the device is successful.

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 77 of 80
239. From the menu, select Configuration > Cloud Express.

240. Click on Manage CloudExpress and select Direct Internet Access (DIA) Sites.

241. Click Attach DIA Sites.

242. Select BR2-VEDGE1.

243. Click the right arrow key to move the device into the right hand column.

244. Click on the link Add interfaces to selected sites.

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 78 of 80
245. In the Select Interfaces box, select ge0/0 (internet) interface on BR2-VEDGE1 (10.4.0.1).

246. Click Save Changes.

247. Wait until the CloudExpress configuration push to BR2-VEDGE1 is successful.

248. Click Configuration > CloudExpress. The new Office 365 application and is provisioned and operational.

This concludes this exercise and the guide!

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 79 of 80
© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 80 of 80

You might also like