Welcome

Welcome to the Walk-In Self-Paced Labs for Cisco SD-

WAN

Viptela joined Cisco in July 2017. Cisco SD-WAN’s Software-Defined WAN (SD-WAN) Fabric
uses the Overlay Management Protocol (OMP) to enable secure, unified connectivity over any
transport (MPLS, Broadband, LTE, VSAT, etc.). Cisco SD-WAN provides simplified operations
with centralized management, policy control and application visibility across the enterprise.

This year, we are excited to offer students two labs, each covering a wide-range of Cisco SD-
WAN topics.

Introductory Cisco SD-WAN Topics - Zero-Touch Deployment and Configuration

Templates: In this lab, students will learn how to use Zero-Touch Provisioning (ZTP) to
deploy and register a Cloud vEdge on the CSP-2100. From there, students will be
introduced to vManage where they will create and attach Device Templates to manage
and configure their vEdge.
Advanced Cisco SD-WAN Topics - Topology Independent WAN Design using the
Overlay Management Protocol: This lab will provide participants with the GUI guidance
needed to successfully verify transport and service topologies. The goal of this session is
to provide participants with a primer on the Overlay Management Protocol and its
mechanisms for creating and maintaining an extensible, resilient SD-WAN fabric that is
transport agnostic and that provides end-to-end simplicity.

Once the Lab Proctor has confirmed the lab environment is ready, students are welcomed to

begin. Please use following information to get started:

Students who are only completing Introductory Cisco SD-WAN Topics, please start with
LABCRS-1005.
Students who are only completing Advanced Cisco SD-WAN Topics, please start with
LABCRS-2000.
Students who are completing both Introductory Cisco SD-WAN Topics AND Advanced
Cisco SD-WAN Topics, please start with LABCRS-1005 and continue through with
LABCRS-2000.

Students can use the panel on the left to navigate to their desired lab. For students interested in
learning more about Cisco SD-WAN before completing the labs, click on NEXT to read
Introduction to Cisco SD-WAN

Thank you for participating! We hope you enjoy our labs, and please do
not forget to leave feedback when you are finished.
 Lab Connection Instructions

Lab Connection Instructions

The AnyConnect client may have to download an update. This will take a few seconds!
Please feel free to continue onto the lab page that matches the selection you made at the kiosk -

or, for a brief introduction to Cisco SD-WAN, please click Next.

 Introduction to Cisco SD-WAN

Introduction to Cisco SD-WAN

Cisco SD-WAN is a cloud-delivered network fabric that is secure, scalable, open and simple to
deploy. Cisco SD-WAN Fabric enables an Enterprise to extend its network footprint to all
infrastructure elements using a single platform. This includes branches, campus, remote sites,
cloud and data center.

The enterprise network has evolved significantly as a result of users, devices, and things needing
to connect to applications in the cloud. The requirements of the network have significantly
evolved as a result. There are pressing requirements both new and old on the current network
architecture.

What is SD-WAN?
SD-WAN is a service that enables enterprises to dynamically route traffic across a hybrid WAN
based on current network status.

In SD-WAN, traditional branch routers are replaced with physical appliances or cloud-based
images that assess and utilize different transport technologies based on their performance,
allowing enterprises to route large portions of their traffic over cost-effective services, such as
broadband. As needed, voice, video, or other sensitive traffic can be routed over MPLS
connections. In addition, most solutions involve a centralized control plane for management,
orchestration, and the provisioning of the SD-WAN solution. Each device is centrally managed,
with routing based on application policies and security rules created by managers that can be
updated in real time as network requirements change.

What is Cisco SD-WAN?

Cisco SD-WAN has taken a fundamental, grounds-up approach to building the Cisco SD-WAN
Fabric. The Cisco SD-WAN Fabric is built on using of time-tested and proven principles of
networking but the sophistication is wrapped in a simplified delivery model.

Separation of control, data, management and orchestration layers

Integrated routing, security and policy for optimal connectivity
Built-in optimization techniques for network and applications

Plane Name Description

Orchestration vBond Cisco vBond Orchestrator is a multi-tenant element of the Cisco

SD-WAN fabric. It facilitates the mutual discovery of the control
and management elements of the fabric by leveraging a zero-
 and management elements of the fabric by leveraging a zero-
trust certificate-based white-listed model. It automatically
distributes list of vSmart controllers and the vManage system to
the vEdge routers during the bring-up process. For situations
where vSmart controllers, vManage system or the vEdge routers
themselves are behind NAT, vBond orchestrator facilitates the
function of NAT traversal, by allowing elements to learn their

public (post-NAT) and private (pre-NAT) IP addresses. The

discovery of public and private IP addresses allows establishing
connectivity across public (Internet, 4G) and private (MPLS,
point-to-point) WAN transports. vBond orchestrator itself should
reside in the public IP space or reside on the private IP space
with 1:1 NAT.

Management vManage Ultimately, Cisco vManage provides single pane of glass for
Day0, Day1 and Day2 operations. Its multitenant web-scale
architecture caters to the needs of the enterprises and the
service providers alike. Some of it’s key functions include
centralized provisioning, centralized policies and device
configuration templates, ability to troubleshoot and monitor the
entire environment and perform centralized software upgrades
on all the fabric elements. vManage GUI allows segregated
administrative access by implementing RBAC for proper roles
and responsibilities. It’s programmatic interfaces enable DevOps
operations. These interfaces can also be used to extract
performance statistics collected from the entire fabric.
Performance statistics can be exported into external systems or
to Cisco vAnalytics tool for further processing and deeper insight.

vSmart Control Cisco vSmart controllers are a scale-out control plane functions
of the Cisco SD-WAN fabric. vSmart controllers facilitate fabric
discovery by running the Overlay Management Protocol (OMP)
between themselves and between themselves and the vEdge
routers. Together with vEdge routers, vSmart controllers act as a
distribution system for the pertinent information required to
establish the data plane connectivity directly between the vEdge
routers. This information includes service (LAN) side reachability,
transport (WAN) side IP addressing, IPSec encryption keys, site
identifiers and so on. vSmart controllers also distribute data plane
and application aware routing policies to the vEdge routers for
enforcement. Control policies acting on the control plane
information are locally enforced on the vSmart controllers. These
control plane policies can implement service chaining, various
types of topologies and generally influence the flow of traffic
across the fabric.

Data vEdge Cisco vEdge routers are the data plane elements of the Cisco
SD-WAN fabric. They are in essence WAN edge routers
positioned everywhere SD-WAN fabric needs to be extended to.
vEdge routers are responsible for encrypting and decrypting
application traffic between the sites. As mentioned earlier, vEdge
routers establish control plane relationship with vSmart controller
to exchange pertinent information required to establish the fabric
and learn centrally provisioned policies. Data plane and
application aware routing policies are implemented on the vEdge
routers. vEdge routers export performance statistics, as well as
alerts and events to centralized vManage system for a single
pane of glass operations. vEdge routers leverage standards
based OSPF and BGP routing protocols for learning reachability
information from service (LAN) side interfaces and for brownfield
integration with non-SDWAN sites. vEdge routers have very
mature full-stack routing implementation, which accommodates
simple, moderate and complex routed environments. For Layer2
redundant service (LAN) side interfaces, vEdge routers
implement VRRP first-hop redundancy protocol, which can
operate on a per-VLAN basis.

How does it work?

The Cisco SD-WAN solution starts with the initial deployment and configuration of the controller
nodes; the vManage, the vSmart and the vBond. These controller nodes establish DTLS/TLS
control connections between themselves, thus allowing the vBond to build a mapping table of all
controller nodes in the network. This mapping table is what allows for the discovery and
onboarding of vEdges, as well as providing vEdges with a NAT traversal information (public and
private IP addresses) of deployed vEdges, if applicable. For a secure control plane, the
controllers generate the necessary encryption keys and certificates for the establishment of
controllers generate the necessary encryption keys and certificates for the establishment of
DTLS/TLS tunnels. Additionally, the controller nodes get configured with a list of serial numbers
of all connecting vEdges (to allow for the initial vEdge device onboarding).

When a vEdge is initially deployed, it is configured with the vBond IP address (in addition to basic
information such as site ID and organization name). The vEdge then registers (authenticates and
is checked against the whitelist) with the vBond, where it retrieves the controller nodes'
information for the establishment of DTLS/TLS control connections. Once onboarded, the vEdge
joins the Overlay Management Protocol (OMP), where it downloads the fabric control information

such as routing information, encryption keys and certificates, which allows it to establish the data
plane IPSec connections to other vEdges on the network.

LABCRS-1005

Introduction

Introduction to LABCRS-1005

During Introductory Cisco SD-WAN Topics, students will be deploying a vEdge Cloud on
"Branch 2" of the WISP Environment. The WAN interfaces on this vEdge Cloud will be connected
to biz-Internet (INET1) and public-internet (INET2). The vEdge will use biz-internet to
communicate with vManage, vBond and vSmart. Once the vEdge Cloud is deployed, and
students have verified their device successfully registered with vBond and vManage, they will
learn how-to use a combination of CLI commands and Device Templates to configure the end-
device. Students will copy, modify and attach a Master Branch Template that configures OSPF
on the LAN interface, enabling routes to be redistributed into the Overlay Management Protocol
(OMP).
(OMP).

Student Number

This student pod is Student 01. Whenever the lab guide instructs students to input configuration
values, please use the student number in place of the X. Generally, configurations and naming
conventions adhere to the following structure: s(0)X. The (0) indicates that the 0 is not required
EXCEPT for students 01-09. While the guide does explicitly outline (in text) the individual
configurations for each pod, please note the screenshots are often not entirely accurate -
EXAMPLES are marked as such!

Devices and Topology

Each student will deploy and configure their own vEdge. In order to accomplish this, students will
only need to interact with the web portals for WISP-CSP2 and vManage. The previous hyperlinks
can be used to automatically open new tabs in Chrome. While every student will be working with
their own vEdges, there is only one vManage. Also, there are only 4 CSPs - this student is on
WISP-CSP2 (10.1.60.26).

The following screenshot is a diagram of the relevant topology used in this section of the lab.
Students will be deploying the bottom-most vEdge, which will be connected to INET1 and INET2.
Using Day0 Configuration files, the vEdge will come online and automatically start communicating
with vBond and vManage via INET1.

Students will not necessarily need to worry about this information, but it is worth pointing out that
VLAN11 is for INET1, while VLAN12 is for INET2; MPLS is VLAN15.

Note!
The FULL topology diagram (for both labs) can be accessed by clicking the "stacked-
squares" icon in the right-hand corner of this lab guide. Connection Information can
accessed by clicking the <-> button. Both of these overlays can be accessed anytime
during the lab.

We hope you enjoy the lab! Please Begin

 Deploying the vEdge Cloud

Warning!
If you are doing LABCRS-1005 and LABCRS-2000, our setup scripts automatically
deployed a second vEdge named s01b3-vEdge. This vEdge will NOT be used until
LABCRS-2000. If you are only doing LABCRS-1005, this vEdge will not be used.

Deploying the Cloud vEdge

The first step to setting up your very own Cisco SD-WAN network, is to deploy a vEdge Cloud.
Cisco vEdge Cloud is a software router platform that supports an entire range of capabilities
available on the physical vEdge router platforms. The vEdge Cloud router is offered as a virtual
machine that can be deployed in the variety of private, public, and hybrid cloud computing
environments. It is supported on all major hypervisor platforms.

Students will be deploying their vEdge Clouds onto a CSP-2100. The CSP-2100 is a KVM
hypervisor based on RHEL 7.3 and ConfD. It can be managed via GUI, REST API, NETCONF or
ConfD Cisco CLI. The CSP-2100 supports several different image types, including QCOW2, ISO
and OVA, and can utilize Day0 Configuration Files to expedite service deployment and
configurations. Because the CSP-2100 is based on Cisco C-Series Servers, the hardware and
the software of CSP-2100 is capable of changing and scaling as the UCS product portfolio grows.
While the CSP-2100 is more popular in data centers and colocation facilities - where Cisco SD-
WAN also operates - it has found success in the branch due to it's small form factor, flexible
configuration options and it's aggressive price:performance ratio.

STEP 1: Open a new browser window/tab in Chrome and navigate to WISP-CSP2 (10.1.60.26).
When prompted, login to the CSP-2100 with "student/Cisc0123#". Chrome may present a
certificate error - click ADVANCED and then Proceed ... to bypass the warning.
The page will reload and display the CSP-2100's Dashboard. The Dashboard gives users a top-
down view of their VNFs, providing them with usage data around cores, memory and disk drives.
Depending on the number of people currently using the lab environment, the usage metrics
displayed may vary slightly.

STEP 2: In the top-right corner, click on Configuration > Services.

STEP 3: Once the Service page loads, click on the plus symbol (+) to open the Create Service
Wizard. If there are other services running, please do not inconvenience other students by
interacting with them.

STEP 4: Students will be using Service Templates to create their Service with pre-populated
configuration. Select the "Create Service using Template" radio button and then select
student-vEdge.tmpl from the drop-down.

Warning!
Once a template is selected, only interact with the items and fields listed in the next
step. Clicking on other fields, such as Target Host Name, will reset some of the pre-
configiured options to their defaults. If this happens, reload the wizard by reselecting the
template.

STEP 5: Students will need to complete the following items. The screenshot below can be used
for reference:

Change Name to s01b2-vEdge - This is VERY important!

Select viptela-edge-17.2.4.qcow2 for the Image Name
Select and attach s01b2-vedge-bootstrap.iso for the Day Zero Config
Select the Resize Disk checkbox
Create one additional VNIC for VLAN101 on po106 for the LAN interface of the vEdge

(Click picture to enlarge)

STEP 6: Before proceeding to deploy the vEdge Service, ensure the Create Service Wizard
matches the output below. However, as mentioned during the Introduction, each input should
have been replaced with the correct student number (01) and the Network Name should be

po106. If the outputs match, click Deploy.

STEP 7: The following pop-up will appear to indicate a successful deployment. Click Close. The
vEdge will take approximentally 3 minutes to deploy and register. Please wait a few minutes
before proceeding to the next section.

This completes Deploying the Cloud vEdge

This completes Deploying the Cloud vEdge

Verifying the vEdge Registration

Verifying the vEdge Registration

During service creation and initizilation, the vEdge Cloud is bootstrapped with the Day Zero
Config provided in the Create Service Wizard. This ISO file was automatically generated for
students by a python script created speficially for this WISP lab. The bootstrap file enables the
vEdge Cloud to come online with the necessary configurations to communicate with vManage
and vBond for the registration process.

The bootstrap ISO contains a file, formatted in YAML, called user_data In this file, there are two
main sections - #cloud-config and #cloud-boothook

#cloud-config

This section of the bootstrap ISO is responsible for configuring the vEdge Cloud with a UUID and
a OTP. For the vEdge Cloud, the UUID is similar to a serial number - it is a unique value used to
identify the virtual machine in vManage. The OTP is a token that authorizes and associates the
UUID to a specific vManage Domain. The configuration information for #cloud-config is obtained
by generating a bootstrap configuration in vManage. It can generated from the GUI (pictured
below) or programmatically.

#cloud-boothook

This section of the bootstrap ISO contains the actual device configuration for the vEdge Cloud.
This section of the bootstrap ISO contains the actual device configuration for the vEdge Cloud.
Besides the system configuration - which contains the hostname, system-ip, site-id,
organization-name(s), etc. - the most important part of the #cloud-boothook is the interface
configuration. In order for the registration process to complete, the vEdge Cloud must be able to
communicate with vManage and vBond over VPN0. If this communication is not possible, the
vEdge Cloud registration process will fail and will need to be re-submitted manually.

#cloud-boothook

system
personality vedge
device-model vedge-cloud
host-name s01b2-vEdge
system-ip 10.1.61.101
domain-id 1
site-id 101
no route-consistency-check
sp-organization-name "Cisco Sy1 - 19968"
organization-name "Cisco Sy1 - 19968"
vbond 11.11.11.252 port 12346

vpn 0
interface ge0/0
ip address 11.11.11.101/24
ipv6 dhcp-client
tunnel-interface
encapsulation ipsec
color biz-internet
allow-service all
!
no shutdown
!
ip route 0.0.0.0/0 11.11.11.1
!

vpn 512
name "Mgmt"
interface eth0
ip address 10.1.61.101/23
no shutdown
!
ip route 0.0.0.0/0 10.1.60.1
!

STEP 1: Open a new browser window/tab in Chrome and navigate to vManage (10.1.60.61).
When prompted, login to vManage with student/Cisc0123#. Chrome may present a certificate
error - click ADVANCED and then Proceed ... to bypass the warning.
The page will reload and display the vManage Dashboard. The Dashboard gives users a top-
down view of the vManage Domain, providing them with an overview of the SD-WAN fabric.
Depending on the number of people currently using the lab environment, the usage metrics
displayed may vary slightly.

STEP 2: In the left-hand navigation panel, hover over the small gear icon and select Devices
from the pop-up menu.

STEP 3: Once the list of vEdges loads, use the search function to locate your recently deployed
student vEdge. Type s01b2-vEdge into the input field and press Enter. The search function
should only return one result. Verify the vEdge Cloud is registered and in-sync by checking the
local configuration.

STEP 4: In the left-hand navigation panel, hover over the small wrench icon and select SSH
Terminal from the pop-up menu.

STEP 5: Once the SSH Terminal window loads, locate and select your vEdge Cloud in the left-
hand panel - the search function can be used to filter the results. Selecting the vEdge Cloud will
automatically start a SSH session with the vEdge Cloud in the main-panel of the vManage GUI.
Login to the vEdge with admin/admin. If there are other vEdge Clouds running, please do not
inconvenience other students by interacting with them.

Note!
The following code snippets were copied (and modified) from the SSH Terminal.
Students should type commands their command directly into the vManage GUI.

STEP 6: The command show certificate validity is another way to check the installation and
registration of the vEdge Cloud. The command actually displays how long the certificate is

considered valid./p>

s01b2-vEdge# show certificate validity

The certificate issued by e7c9e105-654c-42b5-8250-312f2c52af8e is valid from May 18 02:55:08 2018 GMT (Current date is Fri May 18 16:23:03 GMT 2018) & valid until May 15 02:55:08 2028 GMT

STEP 7: The vSmart controller establishes and maintains a control plane connection with each
vEdge router in the overlay network. In a network with multiple vSmart controllers, a single
vSmart controller may have connections only to a subset of the vEdge routers, for load-balancing
purposes. The control connection, which runs as a DTLS tunnel, is established after device
authentication succeeds. The DTLS connection between a vSmart controller and a vEdge router
is a permanent connection. The command show control connections displays the Control
Connections for a specific vEdge device.

s01b2-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
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
vsmart dtls 10.1.60.63 30 1 11.11.11.253 12446 11.11.11.253 12446 biz-internet up 0:13:12:27 0
vbond dtls 0.0.0.0 0 0 11.11.11.252 12346 11.11.11.252 12346 biz-internet up 0:13:12:27 0
vmanage dtls 10.1.60.61 30 0 11.11.11.251 12446 11.11.11.251 12446 biz-internet up 0:13:12:27 0

This completes Verifying Device Registration

Configuring the vEdge with CLI

 Configuring the vEdge with CLI

The CLI is one of the ways you can configure and monitor Cisco SD-WAN devices, physical or
virtual. The CLI provides various commands for configuring and monitoring the software,
hardware, and network connectivity of the vSmart controllers and the vEdge routers. The CLI is
loosely based on Cisco IOS-XE.

The CLI has two modes:

Operational Mode for monitoring the state of the Cisco SD-WAN device. When you log in
to the CLI, you are in operational mode. In this mode, you view device status, monitor and
troubleshoot the device and network connectivity, enter into configuration mode, and
control the CLI session parameters.
Configuration mode for changing the operational parameters of the Cisco SD-WAN
device. You enter configuration mode by issuing the configure command in operational
mode. This mode has a number of submodes for manipulating different parts of the
configuration.

STEP 1: In the same SSH Terminal, use the CLI to enter Configuration Mode and configure a
Banner.

s01b2-vEdge# config terminal

Entering configuration mode terminal
s01b2-vEdge(config)# banner login ? <---------- Just like Cisco IOS-XE, '?' can be used to check for 'Possible Completions'
Possible completions:
<string, min: 1 chars, max: 2048 chars&rt;
s01b2-vEdge(config)# banner login "Welcome to CLUS18"
s01b2-vEdge(config-banner)# top <---------- This command will return the prompt to the top level
s01b2-vEdge(config)# show configuration <---------- This command shows the current, uncommitted configuration
banner
login "\"Welcome to CLUS18\""
!
s01b2-vEdge(config)# commit ? <---------- There are several options available when commiting a configuration
Possible completions:
comment Add a commit comment
label Add a commit label
persist-id Specify a persist-id
save-running Save running to file before performing the commit
---
abort Abort a pending commit
and-quit Commit current set of changes and exit configuration mode
check Validate current configuration
confirmed Commit current set of changes with a timeout
no-confirm Commit current set of changes, do not query user
s01b2-vEdge(config)# commit comment "Banner Config"
Commit complete.
s01b2-vEdge(config)# do show run banner
banner
login "Welcome to CLUS18"
!
s01b2-vEdge(config)# show history <---------- This command will return the last 100 lines (by default) of configuration
05-21 13:47:53 -- banner login "Welcome to CLUS18"
05-21 13:47:57 -- top
05-21 13:48:01 -- show configuration
05-21 13:48:20 -- commit comment "Banner Config" <---------- There are several options available when committing a configuration

STEP 2: Configurations on the vEdge are Transactional. This enables users to Rollback specfic
configurations by using the transaction number. In the SSH Terminal, rollback the banner
configuration.

s01b2-vEdge(config)# rollback ?
Possible completions:
configuration Roll back database to last committed version
selective Apply a single rollback delta
s01b2-vEdge(config)# rollback configuration ?
Possible completions:
0 2018-05-21 13:48:20 by admin via cli comment Banner Config <---------- Use the number to indicate which transaction to rollback
s01b2-vEdge(config)# rollback configuration 0
s01b2-vEdge(config)# commit check <---------- This command validates the current configuration before committing
Validation complete
s01b2-vEdge(config)# commit
Commit complete.
s01b2-vEdge(config)# do show run banner
% No entries found.

This completes Configuring the vEdge with CLI

Configuring the vEdge with Templates

 Configuring the vEdge with Templates

While the CLI remains a powerful tool for troubleshooting, most Cisco SD-WAN deployments will
utilize vManage to manage and configure their Cisco SD-WAN devices.

Device Templates define a device's complete operational configuration. Device Templates

consist of a number of Feature Templates. Each Feature Template defines the configuration for
a particular Cisco SD-WAN software feature. Some Feature Templates are mandatory, indicated
with an asterisk (*), and some are optional. Each mandatory Feature Template, and some of the
optional ones too, have a Factory-Default Template. Templates can be created and combined
as required, as well as copied and renamed for reusability.

Before Device Templates are attached to vEdges, users are prompted to complete necessary
configurations as dictated by the Device Template. When the template is attached, this
configuration will "overwrite" the current configuration on the device. For example, for the
Transport & Managment VPN section, users are required to configure both interfaces belonging
to VPN 0:

In this section of the lab, students will be copying and editing a pre-configured Master Branch
Template. This Device Template was created specifically for vEdges deployed in branch

environments with two Transport Interfaces and one Service Interface. Once the template is
copied, students will be enabling OSPF on the Service Interface with a Feature Template.
Students will then attach the template to their device and verify the configuration changes.

Copying and Editing Templates

STEP 1: In the left-hand navigation panel, hover over the small gear icon and select Templates
from the pop-up menu.

STEP 2: Once the list of Device Templates loads, identify Master_Branch_Template and select
Copy from the sub-menu. When the pop-up appears, change the Template Name and
Description to s01b2_Device_Template. Click Copy to complete the process.

STEP 3: Locate s01b2_Device_Template and select Edit from the template's sub-menu.

STEP 4: Once the template loads, scroll down and find the section entitled Service VPN. Service
VPNs connect to local or branch networks that are generally located at the same site as the
vEdge router. These interfaces carry data traffic throughout the overlay network. On right-hand
side, click on OSPF. This will enable a drop-down from which OSPF_Master_V01 can be
selected. Students are welcomed to click View Template to view the OSPF configuration being
enable by the Feature Template. Once completed, click Update to save your changes and return

to the list of Device Templates.

Attaching Templates

STEP 5: Once the list of Device Templates loads, locate s01b2_Device_Template and select
Attach Devices from the template's sub-menu. When the Attach Devices Wizards appears, use
the search function to locate your student vEdge. Type s01b2-vEdge into the input field and
press Enter. Selecting your student vEdge will cause the -> to change colors. Click on the -> to
move the vEdge from Available Devices to Selected Devices. Click Attach to proceed to
configuration.

Important!
Please ensure you are selecting the correct vEdge. Selecting the wrong vEdge will
result in configuration errors and the inability to complete the lab.

STEP 6: Select Edit Device Template from the sub-menu to open the Update Device Template

Wizard. Complete the wizard as shown in the screenshot below; the table is populated with your
pod-specific inputs. The entire wizard needs to be completed, however, the items in grey are the
same for every pod, while the items in orange need to have the variable (x) replaced with your
student number (01). Click Update and then Next to complete the configuration and move onto
the verification wizard.

Field Input

Hostname s01b2-vEdge

System IP 10.1.61.101

Site-ID 101

INET1 Default Route 11.11.11.1

INET2 Default Route 12.12.12.1

Ge0/0 IP Address 11.11.11.101/24

Ge0/1 IP Address 12.12.12.101/24

eth0/0 IP Address 10.1.61.101/23

Ge0/2 IP Address 10.1.101.1/24

(Click picture to enlarge)

STEP 7: On the next page, students can review the pending configuration changes side-by-side
with the existing configuration on the device. On the left-hand side, there should be a single UUID
listed under Device List. Selecting the device will automatically display the config preview. On
the right, config diff displays the differences (Inline Diff or Side by Side Diff) between the current
configuration and the pending changes. Students are welcomed to scroll down to verify the
configuration changes being made.

STEP 8: Click Configure Devices to save the configuration. From here, vManage will run
through a series of checks before attempting to attach the template to the vEdge. If the
attachment is successful, the Push Feature Template Configuration will read Validation
Success and the log output below (click on the > arrow to open the drop-down) will end with a
Template successfully attached to device .

Verification

STEP 9: In the left-hand navigation panel, hover over the small PC icon and select Network
from the pop-up menu. When the main panel refreshes, locate and click on the name (s01b2-
vEdge) of your vEdge. This will open the Network Monitor Dashboard. From here, users can
display detailed information about individual devices. Students are welcomed to explore the
display detailed information about individual devices. Students are welcomed to explore the

Network Monitor - items of interest are highlighted with an orange circle.

STEP 10: In order to verify the OSPF configuration, students can use Real Time Monitoring to
display statistics directly from the vEdge. Click on Real Time to open the monitoring tool and use
the (top) search function to retreive the OSPF routing information. When the pop-up appears,
click on Do Not Filter to open the complete list of routes being learned via OSPF. Through VPN
100, each student vEdge should be learning 11 external type-2 routes from the CSRv.

STEP 11: And finally, students can also view the routes as they are being advertised into the
Overlay Management Protocol. Remember, the OMP is the routing protocol that responsible for
sharing routes across the SD-WAN Fabric. Once again, use the (top) search function to retrieve
the OMP Advertised Routes - as done previously, click Do Not Filter to proceed. The output
below indicates that external OSPF routes are being learned via VPN 100, and they are being
advertised, through OMP, to vSmart (10.1.60.63). The routes are associated with a TLOC IP,
which indicates from what vEdge the routes are being learned. This locator can be used by other
vEdges to make routing decisions.

This completes Configuring the vEdge with Templates

 Thank You

This page indicates the END of LABCRS-1005. If you are

CONTINUING on to LABCRS-2000 please click Next below to begin
the next lab.

THANK YOU for completing our WISP lab at Cisco Live US

2018!

As SD-WAN customers look for methods to ease network management and design, zero-touch
deployment and robust application/transport policy come to the forefront of any solution
requirement. Through the use of the Overlay Management Protocol (OMP), customers can shift
design-thought away from traditional DMVPN deployments to that of an extensible WAN fabric
enabled by the Cisco SD-WAN solution. Whether an enterprise requires full-mesh, pure
hub/spoke, or an arbitrary topology, customers have the tools to centralize policy from the
datacenter to the branch using the vManage GUI, Software Defined Policy Framework, and a
fully extensible fabric.

We really hope you enjoyed our lab, and we hope you enjoy the rest of your conference
experience. Participants are welcomed to stay in-touch with the lab proctors via email.

Please Remember to complete your surveys!

Visit us at getsvs.cisco.com!
 LABCRS-2000

Introduction

Introduction to LABCRS-2000

During Advanced Cisco SD-WAN Topics, students will be configuring vEdge Clouds on "Branch
2" and "Branch 3" of the WISP Environment. The WAN interfaces on the vEdge Cloud at "Branch
2" will be connected to biz-Internet (INET1) and public-internet (INET2). The WAN interfaces
on the vEdge Cloud at "Branch 3" will be connected to MPLS (MPLS) and public-internet
(INET2). Notice that the vEdge at "Branch 1" has connections to INET1 and MPLS respectively.
For those of you coming from LABCRS-1005, these changes demonstrate topology independent
policy and communication.

The vEdge devices will use biz-internet to communicate with vManage, vBond and vSmart. Once
the vEdge Clouds have been deployed, and students have verified their device successfully
registered with vBond and vManage, they will learn how-to use Policy and Feature Templates to
configure their end-devices. Students will copy, modify and attach a Master Branch Template
that configures OSPF on the LAN interface, enabling routes to be redistributed into the Overlay
Management Protocol (OMP).

Student Number

This student pod is Student 01. Whenever the lab guide instructs students to input configuration
values, please use the student number in place of the x. Generally, configurations and naming
conventions adhere to the following structure: s(0)x. The (0) indicates that the 0 is not required
EXCEPT for students 01-09. While the guide does explicitly outline (in text) the individual
configurations for each pod, please note the screenshots are often not entirely accurate -
EXAMPLES are marked as such!

Devices and Topology

Each student will deploy and configure their own vEdge. In order to accomplish this, students will
only need to interact with the web portal for vManage. If necessary, the previous hyperlink can be
used to automatically open a new tab in Chrome.

The following screenshot is a diagram of the relevant topology used in this section of the lab. Our
setup scripts will automatically deploy the vEdge devices in Branch 2 and 3, which will be
connected to INET1, INET2, and MPLS respective to the diagram. Our setup scripts use Day0
Configuration files to configure the vEdges on deployment, allowing them to start communicating
with vBond and vManage via INET1.

Students will not necessarily need to worry about this information, but it is worth pointing out that
VLAN11 is for INET1, while VLAN12 is for INET2; MPLS is VLAN15.
class="text-center">

Note!
The FULL topology diagram (for both labs) can be accessed by clicking the "stacked-
squares" icon in the right-hand corner of this lab guide. Connection Information can
accessed by clicking the <-> button. Both of these overlays can be accessed anytime
during the lab.

We hope you enjoy the lab! Please Begin

Verifying vEdge Registration & Reachability

Verifying vEdge Registration and Reachability

There are several ways to verify that a vEdge device is deployed and communicating with
vManage and vSmart. In this lab, because each vEdge device was pre-provisioned via Python
setup scripts, students will need to ensure each vEdge successfully registered with vSmart,
indicating device "reachability".

Step 1: Open a new browser window/tab in Chrome and navigate to vManage (10.1.60.61).
When prompted, login to vManage with student/Cisc0123#. Chrome may present a certificate
error - click ADVANCED and then Proceed ... to bypass the warning.


Step 2: Managing vEdge devices is easy in the GUI of Cisco vManage. The vManage
Dashboard can be used to navigate and configure objects in the SD-WAN Fabric. Near the top
of the Dashboard, click on the box with the vEdge icon. This will open a table displaying every
vEdge device registered to vManage.

Note!
Before opening the vEdge table, notice how the Site Health View has several partially
connected sites, and several sites with no connectivity. Over the course of this lab
students will be implementing policy to ensure full-site connectivity. It should be noted
that Reachability and Connectivity States are NOT mutually exclusive.

Step 3: In the vEdge pop-up, click on the column header Hostname to filter and locate your
vEdge devices. Students can also use the search bar to filter the results with their student
number (s01). The following screenshot shows an example for student01:
Step 4: Device Reachability can also be seen in the Network Monitor. Close the pop-up window
displaying the vEdges, and in the left-hand navigation panel, hover over the small PC icon
(Monitor) and select Network from the pop-up menu. Using the (top) search function, filter the
list with your student number (s01) to display the network status of your vEdge devices. In this
table, the column Reachability should show Reachable, indicating the vEdges are live and are
being managed by vManage.

After verifying the status of your vEdge devices in Branch 2 and Branch 3, students will now
verify the configurations on b2-vEdge, ensuring the pre-provisioning scripts correctly deployed
and attached templates to the vEdge devices.

This completes Verifying vEdge Registration and Reachability

Verifying Configuration & Certificate Status

Verifying Configuration and Certificate Status

When new vEdge devices are brought online and registered to vManage, they boot with a
common running configuration - much like how a Cisco router comes out of the box. However
once the device is successfully registered - features, protocol, and policy information can be
automatically pushed to the device from vSmart. In this lab, each vEdge was configured when
copies of the Master_Branch_Template were configured and then attached to each device.

The Master_Branch_Template is also responsible for configuring Centralized Policy. Using OMP
centralized control, data and application aware policies are communicated to vSmart and, in
case of data and application aware routing policies, further down to the vEdge routers. All policies
follow match and action structure which, in this lab, means they match on Site-ID before
accepting or rejecting flows.
Before creating their own local policy, students will need to verify the following:

Successful certificate installation on each vEdge

Successful attachment of cloned device templates for each vEdge
Successful push of centralized policy to running configuration on each vEdge

Step 1: In the left-hand navigation panel, hover over the small gear icon and select Devices
from the pop-up menu. When the main panel refreshes, use the search function to locate your
vEdges. Type s01 into the input field and press Enter.

Students are recommended to pause here and take note of the various "State" available for a
vEdge device in vManage. If the State column shows a green ribbon, the vEdge device has
been completely deployed, bootstrapped, licensed, and registered with vSmart and vManage. If
the State column shows a green dotted-line circle with a key in the center, the vEdge device
does not have a certificate installed, nor is it able to register with vSmart.

In addition to the State, students can also confirm whether or not their devices have a template
attached. The Assigned Template column dictates which template is currently attached. This will
be further explored in later sections of the lab.

Step 2: In the main panel, click on the three horizontal dots to open the sub-menu for s01b2-
vEdge, and select Running Configuration. (Pictured Above)

(Click picture to enlarge)

Step 3: From this view, students can easily scan through and analyze the current running
configuration on the vEdge device. Specifically, students should ensure the setup scripts attached
the right template, successfully configuring the default policies for OMP. Students should perform
the same check on s01b3-vEdge.
the same check on s01b3-vEdge.

This completes Verifying Configuration and Certificate Status

Creating Local Router Policy

Creating Local Router Policy

The Cisco SD-WAN policy framework is a powerful set of tools that allow administrators to
implement intent. Policies are defined on vManage and are communicated to either vSmart
controllers or directly to the vEdge routers.

Local Control Policies perform control-plane functions for dynamic routing protocols running on
the service (LAN) side of the vEdge routers. Since vEdge routers have mature full-stack
implementation of OSPF and BGP, these functions include both establishing protocol adjacencies
as well as various forms of route manipulations and filtering. Local data policies perform variety of
functions on the application traffic passing through the vEdge router, with QoS, ACL and mirroring
being the most notable ones.

Students will now create a Local Policy in vManage for s01b2-vEdge and initiate the policy
installation directly from vManage.

Step 1: In the left-hand navigation panel, hover over the small gear icon and select Policies
from the pop-up menu. When the main panel loads, select Localized Policy near the top of the
screen.

For the purposes of the lab, a Local SD-WAN Policy was already created for the
Master_Branch_Template. Click on the three horizontal dots to open the sub-menu for
default_sdwan_local_policy and select View.

(Click picture to enlarge)

Step 2: Once the policy has been reviewed, students going to create their own policy in order to
make changes and demonstrate local policy updates via OMP. If you have not done so already,
click Cancel to close the window for default_sdwan_local_policy. When the main panel refreshes,
click on Add CLI Policy. Name the new policy s01_Local_OSPF_Branch_2.

In the large input box under CLI Configuration, students are going to input the same CLI
configuration from default_sdwan_local_policy. For convienence, the CLI configuration from
default_sdwan_local_policy is copied below. Copy this configuration into your CLI Policy.

<

policy
flow-visibility
cloud-qos
lists

class-map
class Critical queue 0
class Business queue 1
class BestEffort queue 2
class Bulk queue 3

qos-scheduler BestEffort
class BestEffort
bandwidth-percent 5
buffer-percent 5
drops red-drop

qos-scheduler Bulk
class Bulk
bandwidth-percent 20
buffer-percent 20
 drops red-drop

qos-scheduler Business
class Business
bandwidth-percent 70
buffer-percent 70
drops red-drop

qos-scheduler Critical
class Critical
bandwidth-percent 5
buffer-percent 5
scheduling llq

qos-map EGRESS-QOS
qos-scheduler BestEffort
qos-scheduler Bulk
qos-scheduler Business
qos-scheduler Critical

Step 3: Before clicking Add to create this CLI Policy, students are going to add a simple route-
policy to the configuration. Copy the following configuration, and paste it into the appropriate spot
(lines 6-10), as shown in the picture below. Once completed, click Add to finish the creation
process.

route-policy s01-ospf
sequence 10
action accept
set
ospf-tag 100

With the local policy configured, students will then apply the policy to Branch 2 vEdge.

This completes Creating Local Router Policy

Assigning OSPF Policy to Feature Template

Assigning OSPF Policy to Feature Template

In order for the OSPF Router Policy to make changes on the vEdge AND be redistributed through
OMP to vSmart, students must first attach a Feature Template, referencing the OSPF Route
Policy, to a Device Template that is attached to s01b2-vEdge.

Step 1: In the left-hand navigation panel, hover over the small gear icon and select Templates
from the pop-up menu. When the main panel loads, select Feature near the top of the screen.
Filter the long list of templates by searching for "ospf".

Step 2: Students are going to need to copy OSPF_Master_GE0/2_V01, in order to make

changes that do not affect other students. Click on the three horizontal dotted lines and select
Copy from the sub-menu. Name your copy s01_OSPF. Click Copy to complete the process.

Step 3: When the main panel refreshes, click on the three horizontal dots for s01_OSPF, and
select Edit from the sub-menu.

Step 4: Students need create a Redistribute Rule for the policy to use. Either scroll down, or click
Redistribute, to find the right section in the GUI. Select New Redistribute. For the Protocol
drop-down select OMP. This indicates the protocol our route policy is being redistributed INTO.
For Route Policy, students need to type the name of their policy, s01-ospf (It is a "-" not "_"),
into the empty field. Also, before continuing, please ensure the field is configured as Global,
which is indicated by the small green wire-frame globe to the immediate left of the drop-down.

Note!
Remember, this policy is from the CLI configuration students copied and pasted into the
CLI Configuration when creating s01_Local_OSPF_Branch_2.
Step 5: Click Add to add the new Redistribute section to the Feature Template, and then click
Update to save the changes.

This completes Creating Local Router Policy

Applying Local Router Policy

Applying Local Router Policy

Students have now created a Local Router Policy for CLI Configuration on Branch 2, as well as
created a Feature Template to enable redistribution. Students must now apply each of these
objects to the Device Template.

Step 1: Navigate to Configuration > Templates. When the main panel refreshes, filter the
results with your student number s01. From the sub-menu for s01b2-_Device_Template select
Copy and name your new Device Template s01b2_Device_Template_V02.

Step 2: Once the new template is created, open the sub-menu for s01b2_Device_Template_V02

and select Edit from the drop-down. (Pictured Above)

Step 3: Students will need to change the OSPF configuration under Service VPN. From the
drop-down next to OSPF, select s01_OSPF. This attaches our redistribution rule for OMP into the
Running Configuration.

Step 4: Students will need to re-configure Policy under Additional Templates in order to attach
the Redistribution Policy responsible for advertising routes into OMP. From the drop-down next to
Policy, select s01_Local_OSPF_Branch_2.
Click Update to save your changes.

Step 5: With the new Device Template created and modified, it now needs to be attached to
s01b2-vEdge. Once again, in main panel search for s01 and click on the three horizontal dots to
open the sub-menu for s01b2_Device_Template_V02 and select Attach Devices.

When the pop-up appears, students will need to filter and select s01b2-vEdge and click the green
arrow in the center to "select" the device.

Step 6: On the next page, click Next. Students can then proceed to review the pending
configuration changes side-by-side with the existing configuration on the device. On the left-hand
side, there should be a single UUID listed under Device List. Selecting the device will
automatically display the config preview. On the right, config diff displays the differences (Inline
Diff or Side by Side Diff) between the current configuration and the pending changes.

Step 7: In the Config Diff view, ensure the right-hand side shows your redistribution configuration
under router ospf. In addition, ensure the route-policy s01-ospf is listed in the policy section.
Once confirmed, students can select Configure Devices to start the configuration process.
Step 8: If the configuration was successful, students will see green check marks to indicate the
configuration was validated and applied.

This completes Applying Local Router Policy

MPLS versus INET Policy Review

MPLS versus INET Policy Review

Given the short duration of this lab session, we want to avoid giving students too many policies to
create. However, we DO want to show students how the Cisco SD-WAN Policy Framework can
be used to craft an Enterprise WAN Strategy.

Our goal is for students to remember these three things:

1. Data policies are primarily used to override fabric routing behavior with specific
instructions in regard to next-hop, outbound transport, service insertion, etc.

2. Application-Aware Routing Policies can enforce/prevent application traffic of interest

from being sent down the tunnels that do not satisfy the loss, latency or jitter SLA
thresholds as defined by the administrator.

3. Control Policies reside on the vSmart controllers, and as such, cannot act on actual
application traffic, since application traffic never passes through the controllers. Instead,
control policies act on the OMP control-plane advertisements sent-to or received-
from the vEdge routers.
Step 1: Lets review the Enterprise SD-WAN Policy. In the left-hand menu, navigate back to
Configuration > Policies > Centralized Policy and VIEW the policy (DO NOT EDIT OR
DELETE).

There are several sections of this policy that the studend should digest and remember for later
reference. Scroll down and find the following items in the policy:

site-lists for MPLS and INET

MPLS Control Policy
INET Control Policy
apply-policy clause for MPLS sites

lists
vpn-list LAN_VPN
vpn 100
!
site-list MPLS <---------- Site ID's 200 through 299 are defined as MPLS sites
site-id 200-299
!
site-list INET <---------- Site ID's 100 through 199 are defined as INET sites
site-id 100-199
!
site-list DC
site-id 10
site-id 20
!
<...snipped for brevity...>
control-policy MPLS-Control-Policy
sequence 1
match tloc <---------- Sequence 1 matches on the DC site list (site-id 10 and 20)
site-list DC
!
action accept <---------- The action of 'Accept' will allow control through the DC
!
!
sequence 11
match tloc <---------- Sequence 11 matches on all other site lists
!
action reject <---------- The action of 'Reject' will disable traffic between all other site-ids
!
!
default-action accept
!
apply-policy
site-list MPLS
control-policy MPLS-Control-Policy out <---------- Finally, the MPLS policy is applied to all MPLS sites
data-policy Corporate_QOS all
app-route-policy MPLS_APP_ROUTE
cflowd-template CFLOWD
!
site-list INET
data-policy Corporate_QOS all
app-route-policy INET_APP_ROUTE
cflowd-template CFLOWD
!

Note!
 Note!
The following explanations use the line numbers in the CLI output on the vManage GUI
as reference.

Step 2: Whereas Lines 253-257 allow the Site-IDs from the DC to be permitted inbound via
MPLS, the Lines 260-263 break full-mesh connectivity as it rejects all other Site-IDs and TLOCs
(hub-and-spoke). Notice how there isn't an INET Control Policy - by default, because there is
not a policy explicitly stating otherwise, the INET sites are in full-mesh.

control-policy MPLS-Control-Policy
sequence 1
match tloc
site-list DC
!
action accept
!
!
sequence 11
match tloc
!
action reject
!
!
default-action accept
!

Step 3: Students can review app-route definitions on Lines 96-211 which allow an Enterrpise
Architect to craft when, where, and how specific flows traverse the network. It is important to
highlight examples of this so that we can make some assumptions in our last section.

<...EXAMPLES...>
app-route-policy MPLS_APP_ROUTE
vpn-list LAN_VPN
sequence 10
match
dscp 46
!
action
sla-class Critical preferred-color mpls
!
!
sequence 20
match
dscp 31 41
!
action
sla-class Business preferred-color mpls
!
!
sequence 30
match
dscp 11 21
!
action
sla-class Bulk preferred-color biz-internet
!
!
sequence 40
match
dscp 0
!
action
sla-class Bulk preferred-color biz-internet
!
!
sequence 1000
action
sla-class BestEffort preferred-color biz-internet
!
app-route-policy INET_APP_ROUTE
vpn-list LAN_VPN
sequence 10
match
dscp 46
!
action
sla-class Critical preferred-color biz-internet
!
!
sequence 20
match
dscp 31 41
!
action
sla-class Business preferred-color biz-internet
!
!
sequence 30
match
dscp 11 21
!
action
sla-class Bulk preferred-color public-internet
!
!
sequence 40
match
dscp 0
!
action
sla-class Bulk preferred-color public-internet
!
!
sequence 1000
action
sla-class BestEffort preferred-color public-internet
!

This completes MPLS versus INET Policy Review

 Demonstrating OMP Control for Branches

Demonstrating OMP Control for Branches

Recall the topology that we are working with (See Below) - Branch 2 is connected DC 1 and 2 via
two INET connections; Branch 3 is a hybrid-site, connected to one INET and one MPLS
connection; and finally, Branch 1 mimics the connection types of Branch 3, while Branch 4 mimics
the connection types of Branch 2.

Step 1: Students need to confirm that both Branch 2 and Branch 3 are receiving routes from the
data center vEdges. Sudents can use the Real Time View of the Device Monitor to easily verify
learned OSPF routes locally. Navigate to Monitor > Network and filter the list of devices by your
student number (s01). Click on s01b2_vEdge to open the device page.
Step 2: On the left-hand side, select Real Time and filter the Device Options with "OSPF
Routes", as shown in the screenshot below. Select Do Not Filter when prompted.

Branch 2 is learning multiple OSPF routes from the data center through VPN100. Students
should see local OSPF routes from the southbound router (CSRv), as well as external routes
from the northbound testing device (STCv). The 172.16.1.x/28 routes are being advertised by
STCv, which is an OSPF peer with the data center vEdges. And remember our INET Policy ... or
rather, lack thereof? This information demonstrates full-mesh communication between the
vEdges via INET1 and INET2, as we are learning /28s from both DC1 and DC2.

Step 3: Now show the OSPF Routes for Branch 3. Near the top-left of the main panel, click on
Select Device and choose s01b3-vEdge. Once again, use Device Options to filter for "OSPF
Routes".

When the main panel refreshes with the routing information for Branch 3, students should see a
single route to DC2. This is by design, as we constructed the MPLS policy to filter traffic from all
other Site-IDs besides DC1 and DC2.

Step 4: This traffic pattern can be confirmed with a Trace Route. Use Select Device and
navigate back to s01b2-vEdge. On the left-hand side, select Troubleshooting. When the main
panel refreshes, select Trace Route.
Step 4: Students are going to view the path from Branch 2 to Branch 4, since both vEdges are
connected to INET circuits. Use the information in the table below to complete the Traceroute
Tool. Once completed, click Start:

Field Input Note

Destination 10.1.150.1 This is the IP address of the LAN interface on Branch

IP 4 vEdge

VPN VPN - 100

Source ge0/2 - ipv4 - This is in the LAN interface on Branch 2 vEdge

Interface 10.1.101.1

What does the trace route show? The result should only have one hop, which confirms our full-
mesh topology. Further, this confirms that Branch 2 and 4 can communicate spoke-to-spoke.

Note!
If for some reason VPN-100 cannot be selected, use s29b2-vEdge and s29b3-vEdge to
demonstrate control using traceroute. With so many students on the same environment,
we have seen a corner case where interfaces are indeed up/up, however, vManage
sees them as down and does not populate an option for VPN - 100 in real time. PS. This
would not happen in a production environment with multi-tenancy or strict RBAC.

Step 5: Use Select Device to once again change the view to s01b3-vEdge. Here students are
going to perform a similar trace route with Branch 1. However, remember this vEdge is a MPLS
hybrid site just like Branch 1.

Field Input Note

Destination 10.1.200.1 This is the IP address of the LAN interface on Branch

IP 1 vEdge

VPN VPN - 100

Source ge0/2 - ipv4 - This is in the LAN interface on Branch 3 vEdge

 Interface 10.1.201.1

What does the trace route show? Surprised?Here, students should see a clear path through
DC2 (10.1.200.1), indicating that we indeed have hub-to-spoke communication. In other words,
we have successfully forced Branch 1 and 3 to communicate through the data center before
hopping to its final destination.

Important!
Control Plane policies can enforce different VPN topologies, prevent communication
between sites or performing service insertion. You may notice that data and control
policies can sometimes achieve the same results by using different methods. The use of
one method versus the other is often evaluated during the time of policy creation. Even
though at times achieving the same results, certain requirements will determine which
type of policy should be used. For example, if the requirement is to match on DPI
signatures, only data policies can be used. However, if the requirement is to build hub-
and-spoke topology and not full-mesh topology, control policies are desired for their
simplicity.

This completes Demonstrating OMP Control for Branches

Using cFlowd and App-Aware Routing

Using cFlowd and App-Aware Routing

​In the Cisco SD-WAN Overlay Network, you configure Cflowd using Centralized Data Policy.
Cflowd monitors traffic flowing through vEdge routers in the overlay network and exports flow
information to a collector, where it can be processed by an IPFIX analyzer.

In its current state, the STCv instance is sending flows to your branches with DSCP 34 marked
traffic (AF41).

Step 1: In order to visualize the flows traversing Branch 2, once again navigate to Monitor >
Network and jump into the Real Time view of s01b2-vEdge

Step 2: Filter the Device Options for "cFlowd Flows". When prompted, select >Do Not Filter"

Note!
When the main panel loads, students may see some existing EF traffic. This is most
likely from CPU processes like NTP, BFD, etc.
Why are there so many ingress and egress differences? That is, why are there are different
ingress and egress port combinations for DSCP 34 flows...>

If you recall or review the application aware policies (Step 3 in MPLS versus INET Policy Review)
that were created for MPLS and INET alike, we did NOT have explicit clauses for AF41 (or DSCP
34) traffic types. In this case, the behavior defaults to best-effort and we effectively begin to load-
balance flows across interfaces. If the traffic was using an app-aware DSCP mapping, students
would expect to see unique traffic steering. This is being illustrated by the screenshot above.

This completes Using cFlowd and App-Aware Routing

Thank You

This page indicates the END of LABCRS-2000.

As SD-WAN customers look for methods to ease network management and design, zero-touch
deployment and robust application/transport policy come to the forefront of any solution
requirement. Through the use of the Overlay Management Protocol (OMP), customers can shift
design-thought away from traditional DMVPN deployments to that of an extensible WAN fabric
enabled by the Cisco SD-WAN solution. Whether an enterprise requires full-mesh, pure
hub/spoke, or an arbitrary topology, customers have the tools to centralize policy from the
datacenter to the branch using the vManage GUI, Software Defined Policy Framework, and a
fully extensible fabric.

THANK YOU for completing our WISP lab at Cisco Live US

2018!



We really hope you enjoyed our lab, and we hope you enjoy the rest of your conference
experience. Participants are welcomed to stay in-touch with the lab proctors via email and WebEx
Teams.

Please Remember to complete your surveys!

Visit us at getsvs.cisco.com!

Test
 Test2

Title

This is my first sentence.

Warning!
This is my first sentence.

1. This is my first sentence.

This is my first sentence.

This is my first sentence.