Swat Sd-Wan v2 Lab Guide

SDWAN-dCloud-LAB-GUIDE
1
Table of Contents
Requirements ...................................................................................................................................................................................................................................... 5
Get Started .......................................................................................................................................................................................................................................... 5
Network Details.................................................................................................................................................................................................................................... 6
Lab Topology ................................................................................................................................................................................................................................... 6
Device Credentials ........................................................................................................................................................................................................................... 7
IP Address Schema ......................................................................................................................................................................................................................... 8
Preconfiguration Summary ................................................................................................................................................................................................................ 10
Dynamic Service Side routing at the DC ........................................................................................................................................................................................... 11
Activity Verification ......................................................................................................................................................................................................................... 22
Dynamic Service Side Routing at Site 40 .......................................................................................................................................................................................... 26
Activity Verification and Remediation ............................................................................................................................................................................................. 36
Configuring Virtual Router Redundancy Protocol ............................................................................................................................................................................ 43
TLOC Extensions at Site 20 .............................................................................................................................................................................................................. 58
Updating the VPN and Device Templates...................................................................................................................................................................................... 74
Activity Verification ......................................................................................................................................................................................................................... 85
Configuring a Hub and Spoke topology ............................................................................................................................................................................................. 89
Creating the Policy ....................................................................................................................................................................................................................... 101
Activity Verification ....................................................................................................................................................................................................................... 117
Setting up a Regional Hub ............................................................................................................................................................................................................... 121
Verification ................................................................................................................................................................................................................................... 140
Implementing Custom Traffic Engineering ....................................................................................................................................................................................... 143
Verification ................................................................................................................................................................................................................................... 159
Implementing Direct Internet Access ............................................................................................................................................................................................. 163
Verification ................................................................................................................................................................................................................................... 173
Configuring Application Aware Routing ........................................................................................................................................................................................... 175
Viewing modified traffic flows and current network statistics ....................................................................................................................................................... 185
Verify Policer configured for network impairment ......................................................................................................................................................................... 187
Applying the Policer on the MPLS link ......................................................................................................................................................................................... 191
2
Viewing changed statistics and resultant traffic flows .................................................................................................................................................................. 196
Configuring Low Latency Queuing and QoS ................................................................................................................................................................................... 199
Apply the ACL and QoS Map ....................................................................................................................................................................................................... 215
Configuring a Zone Based Firewall for Guest DIA users ................................................................................................................................................................. 229
Creating a Security Policy ............................................................................................................................................................................................................ 237
Applying the Policy and Verification ............................................................................................................................................................................................. 251
Installing and Configuring the IPS module on cEdges ..................................................................................................................................................................... 256
Add the Security Policy ................................................................................................................................................................................................................ 258
Updating the Application List and Device Template ..................................................................................................................................................................... 265
Verifying installation and performing signature updates .............................................................................................................................................................. 271
Configuring URL Filtering ................................................................................................................................................................................................................ 277
Configuring AMP and TLS/SSL Proxy ............................................................................................................................................................................................. 286
Initial Configuration ...................................................................................................................................................................................................................... 292
Configuring NTP and DNS ........................................................................................................................................................................................................... 292
Setting up vManage as the CA .................................................................................................................................................................................................... 299
Enabling AMP and Testing........................................................................................................................................................................................................... 312
Configuring the Decryption Policy ................................................................................................................................................................................................ 316
Integrating Cisco SD-WAN and Umbrella ........................................................................................................................................................................................ 327
Enabling DIA For Site 40 VPN 30 ................................................................................................................................................................................................ 332
Life without Umbrella.................................................................................................................................................................................................................... 342
Configuring WAN Edge Umbrella Redirection ............................................................................................................................................................................. 347
Making Umbrella Ours ................................................................................................................................................................................................................. 366
Building a DNS Policy .................................................................................................................................................................................................................. 373
Pre-Work for Site 30..................................................................................................................................................................................................................... 396
Enabling Site 30 for DIA ............................................................................................................................................................................................................... 416
Setting up IPSEC Tunnels ........................................................................................................................................................................................................... 419
3
Configuring a Firewall Policy ........................................................................................................................................................................................................ 433
Configuring a Web Policy ............................................................................................................................................................................................................. 440
Dynamic On-Demand Tunnels ........................................................................................................................................................................................................ 452
Configuring a Control Policy for Dynamic Tunnels ....................................................................................................................................................................... 461
Configuring OMP Templates ........................................................................................................................................................................................................ 471
Enabling Dynamic Tunnels .......................................................................................................................................................................................................... 490
Inter VPN Routing and Service Chaining......................................................................................................................................................................................... 514
Setting up VPN Lists .................................................................................................................................................................................................................... 534
Inter VPN Routing Policies ........................................................................................................................................................................................................... 538
Inter VPN Routing Verification ..................................................................................................................................................................................................... 548
Policies for Service Chaining ....................................................................................................................................................................................................... 553
Configuring Cloud OnRamp for SaaS.............................................................................................................................................................................................. 567
Configuring Cloud OnRamp for SaaS .......................................................................................................................................................................................... 573
Verification and Testing................................................................................................................................................................................................................ 581
IMPORTANT! This content is community developed and is not subject to standard dCloud verification or support. Please contact dCloud Support for
more information.
4
Requirements
1. The following table outline the components required to execute the tests in this demonstration guide.
Required Recommended Optional
Laptop with browser Google Chrome^ Cisco AnyConnect*
* Incognito mode if seeing caching issues on the POC Tool UI.

* You can use the external public address provided in the session details if not using AnyConnect.
Get Started
2. Initiate your dCloud session by clicking on the lab link provided by your trainer and log in with your own CCO credentials.
3. On the dCloud page, click on My Hub => Sessions => Info
4. Navigate the Info section and find the external IP address of your POD. This will be your POD’s public IP address.
5. Launch the Google Chrome browser (incognito mode preferred), put the external IP address of your POD in the address bar and hit Enter.
6. If your organization has blocked access to POD’s public IP address, then use AnyConnect VPN to access your POD. AnyConnect credentials and POD’s internal IP
address are also given in Info section.
7. On Google Chrome, click through the security warning to ignore the certificate error (or add an exception for the site). Log into POC Tool using username
[email protected] and password C1sco12345.
8. As this is the first time you logged into your POD, wait here for approximately 10 minutes for all the devices to boot up. (Do not click on any button or icon)
9. After a wait of 10 minutes, click on the blue vManage icon at the top right corner. It will open vManage in another browser tab.
10.
11. Log into vManage using username admin and password admin.
5
Network Details
Table of Contents
Lab Topology
Device Credentials
IP Address schema
Lab Topology
Given below is the lab topology being used for the SWAT SD-WAN Labs
Note: There might be minor differences in the topology being used versus what you see here. We will keep this
updated as far as possible
Decoding the topology:
There are a total of 5 sites where we will have cEdges/vEdges deployed
All sites have Service VPNs associated with them.
Sites with vEdges have 2 service VPNs (VPN10 and VPN20)
Sites with cEdges have 3 service VPNs (VPN10, VPN20 and VPN30)
Some devices have dual uplinks (MPLS and Internet) while others have single uplinks (MPLS only or Internet only)
Site DC (Site ID 1) is running OSPF on the LAN. Site 50 is running EIGRP on the LAN
Site 20 will have TLOC Extensions set up and we will be peering with the MPLS side via eBGP
6
All devices have been on boarded for the participants.
Participants are required to configure templates for WAN Edge devices and vSmarts
Device Credentials
• For vManage, vSmarts, vBond => username admin and password admin
7
• For all WAN Edge Devices => username admin and password admin
• For Windows PCs => username admin and password C1sco12345
• For Ubuntu PCs => username ubuntu and password viptela
IP Address Schema
8
1
1000
9
Preconfiguration Summary
Certain parts of the topology have been preconfigured to save time, the preconfigured components and associated
knowledge is considered pre-requisite for this training, the preconfigured tasks include the following:
• All cEdges and vEdges are onboarded and have their control connections as up
• Feature templates for VPN0 and VPN0 interfaces for cEdges and vEdges on all sites have been pre-configured
• Device Templates for cEdges and vEdges on all sites have been preconfigured
• Some service-side VPNs for sites have been pre-configured
10
Dynamic Service Side routing at the DC
Summary: Implementing Dynamic Service Side Routing at the DC - OSPF
Table of Contents
Overview
Updating the vEdge Service VPN 10 with an

OSPF Template
Activity Verification
Task List
Overview
Updating the vEdge Service VPN 10 with an OSPF Template
Overview
Sites in Cisco SD-WAN will generally have an L3 device on the LAN other than the vEdges/cEdges. These devices might be
servicing LAN users and advertising their routes via an IGP of choice. We need to make sure that these routes are
advertised across the SD-WAN Fabric. While static routing can be used to achieve this, it is time consuming and extremely
prone to errors. Thus, running a Dynamic Routing Protocol between the WAN Edge devices and the L3 devices, is usually
preferred.
We will run OSPF on VPN 10 in the DC with an L3 Device (called the Central Gateway). The Central Gateway has been
configured with the corresponding OSPF configuration. Once OSPF neighborships are established between the Central
Gateway and our DC-vEdges, we will try to reach a route being advertised by the Central Gateway (10.0.0.1/32) from
vEdge30.
Given below is the section of the topology that we will be working on for this activity.
11
Task List
Overview

1. Go to Configuration => Templates and click on the three dots next to DCvEdge_dev_temp. Click on Edit
12
2. Under Service VPN, click on the three dots next to the vedge-vpn10 template and choose to Edit it
3. Click on OSPF under Additional VPN Templates to add an OSPF Template
4. Click on the OSPF drop down and click on Create Template to create a new OSPF Template. We are creating our
Templates on the fly over here, but could have created them before hand from the Feature Templates, if required
13
5. Give the template a name of DC-OSPF and a Description of OSPF Template for the DC. Click on New Redistribute
under the Redistribute section
14
6. No routes get redistributed into OSPF but we want to ensure that WAN Routes are advertised into the DC LAN. For
this purpose, choose OMP and click on Add. This will redistribute OMP routes into OSPF
7. Under the Area section, click on New Area
8. Set the Area Number as a Global value of 0. Our OSPF neighborships will be formed on Area 0. Click on Add
Interface
15
9. Click on Add Interface again to add the OSPF Interfaces
10. Specify the Interface Name as a Global value of ge0/2 and click on Add. This is our LAN facing Interface in VPN 10
16
11. Click on Add under the Area section to Add these details to the OSPF Template
12. Click on Save to save the OSPF template
17
13. This should take you back to the vedge-vpn10 Template configuration window. If it doesn’t, navigate to it manually and
populate the DC-OSPF template in the OSPF field. Click on Save
18
14. Make sure that the VPN 10 Service VPN has OSPF, VPN Interface tacked on to it and click on Update
19
15. We are taken to the configuration page for the individual devices at the DC. There is nothing that needs to
be configured, so we can click on Next
16. Review the side by side config diff (notice the OSPF configuration added) and click on Configure Devices.
Confirm this configuration change
20
This completes the OSPF related configuration on VPN 10 for the DC-vEdges.
21
Task List
Overview
1. On the vManage GUI, navigate to Monitor => Network. Click on DC-vEdge1 and then on Real Time. Enter OSPF
Neighbors in the Device Options and choose Do Not Filter, if prompted. You should see 2 OSPF Neighbors (Central
Gateway and DC-vEdge2)
2. Enter OSPF Routes in the Device Options and choose Do Not Filter if prompted
22
3. You should see a Route for the 10.0.0.1/32 network, among others
4. The same information can be verified via console. Log in to DC-vEdge1 and issue show ospf neigh, show ospf
route and show ip route ospf
23
5. Log in to console of vEdge-30 and issue a show ip route . You will notice that a route to 10.0.0.1/32 has been
learnt via OMP. Intra-Area and Inter-Area routes are injected into OMP by default
24
6. Issue ping 10.0.0.1 vpn 10 from vEdge30 to verify connectivity with the advertised LAN side route at the
The pings should be successful
25
Dynamic Service Side Routing at Site 40
Summary: Implementing Dynamic Service Side routing at Site 40 - EIGRP
Table of Contents
Overview
Updating the cEdge Service VPN 10 with an

EIGRP Template
Activity Verification and Remediation
Task List
Overview
Updating the cEdge Service VPN 10 with an EIGRP Template
Overview
We will run EIGRP on VPN 10 in Site 40 with an L3 Device. The L3 device has been configured with the corresponding
EIGRP configuration. Once EIGRP neighbourship is established between the L3 Device and cEdge40, we will try to reach a
route being advertised by the L3 Device (10.40.11.0/24) from the DC-vEdges.
Given below is the section of the topology that we will be working on for this activity
26
27
Task List
Overview

1. Go to Configuration => Templates and click on the three dots next to cEdge_dualuplink_devtemp. Click on Edit
2. Under Service VPN, click on the three dots next to the cedge-vpn10 template and choose to Edit it
3. Click on EIGRP under Additional Cisco VPN Templates to add an EIGRP Template
28
4. Click on the EIGRP drop down and click on Create Template to create a new EIGRP Template. We are creating our Templates
on the fly over here, but could have created them before hand from the Feature Templates, if required
5. Give the template a name of site40-eigrp and a Description of EIGRP Template for Site 40 cEdge. Populate the
Autonomous System ID as a Device Variable with a value of eigrp_as_num. Click on New Redistribute under the
Unicast Address Family => Re-Distribute section
29
6. No routes get redistributed into EIGRP but we want to ensure that WAN Routes are advertised into the Site 40 LAN.
For this purpose, choose OMP and click on Add. This will redistribute OMP routes into EIGRP
7. Under the Unicast Address Family section, click on the Network tab. Click on New Network and Enter a Global
Network Prefix of 10.40.10.0/24. Click on Add
30
8. Under Interface, click on Interface to add a new one. Enter the Interface Name as GigabitEthernet4 and click on
Add. This is our LAN facing interface in VPN 10 on cEdge40
9. Make sure the EIGRP template looks like the image given below and click on Save to save the template
31
10. This should take you back to the cedge-vpn10 Template configuration window. Populate the site40-eigrp template in
the EIGRP field. Click on Save
32
11. Make sure that the VPN 10 Service VPN has Cisco VPN Interface Ethernet, EIGRP tacked on to it and click on
Update
33
12. We are taken to the configuration page for the cEdge40. Enter the Autonomous System ID as 40 and click on Next
34
13. Review the side by side config diff (notice the EIGRP configuration added) and click on Configure Devices.
This completes the EIGRP related configuration on VPN 10 for the Site 40 cEdge.
Task List
Overview
35
1. Log in to the Console of cEdge40. The username and password are admin. Enter show ip eigrp vrf 10 40
neighbors to view the EIGRP neighbors in VPN 10, AS 40. We will see one neighbor (the L3 Device)
2. Run show ip route vrf 10 - you should see a 10.40.11.0/24 route learnt via EIGRP
36
3. Log in console to DC-vEdge1 and try to ping an IP in the 10.40.11.0/24 network. Type ping vpn 10 10.40.11.1 -
the pings should fail. Issue show ip route vpn 10 and you will notice that there is no route for the 10.40.11.0/24
subnet.
37
4. This is due to the fact that EIGRP routes aren’t advertised into OMP. To remedy this, we will need to modify our cEdge
Template. Go to Configuration => Templates => Feature tab and click on the three dots next to cedge-vpn10.
Choose to Edit
5. Navigate to the Advertise OMP section and set EIGRP to Global - On. Click on Update
38
6. Click Next on the Device page since we don’t have to update any values. Note that this change will be pushed to
multiple devices, even those that don’t have EIGRP configured (e.g., Site 50 Devices). We need to make sure that this
change is pushed to the Site 40 cEdge
7. Check the side by side configuration, noting that EIGRP routes will now be advertised into OMP. Click on Configure
Devices
39
8. Confirm the change (pushed to 3 devices) and click on OK
9. Wait for the change to successfully go through
40
10. Once successful, go to the CLI for DC-vEdge1 and issue show ip route vpn 10 again. You should see routes for
10.40.11.0/24
11. Run a ping to 10.40.11.1 via the CLI ping vpn 10 10.40.11.1 . It should be successful
41
This completes the EIGRP verification and remediation activity.
Task List
Overview
42
Configuring Virtual Router Redundancy Protocol
Summary: Using Configuration Templates to set up VRRP as a First Hop Redundancy Protocol at Site 50.
Table of Contents
Editing Templates to support VRRP
Verification and Testing
Task List


1. On the vManage GUI, navigate to Configuration => Templates => Feature Tab
43
2. Locate the cedge-vpn10-int template and click on the three dots next to it. Choose to Copy and name the copied
template cedge-vpn10-int-vrrp. Enter a Description of VPN 10 Interface Template for cEdges with VRRP. Click on
Copy
44
3. Click on the three dots next to the newly copied template and click on Edit
4. Navigate to the VRRP section and click on New VRRP. Update the parameters as shown in the table below, using the
image for reference. click on Add
Field Global or Device Specific (Drop Down) Value
Group ID Global 5
Priority Device Specific vpn10_if_vrrp_priority
Track OMP Global On
IP Address Global 10.50.10.100
45
5. Click on Update
6. Go to the Device tab in Configuration => Templates and locate the cEdge-single-uplink Device Template. Click on
the three dots next to it and click Edit
46
7. Scroll down to the Service VPN section and click on the three dots next to cedge-vpn10. Choose to Edit
8. Populate cedge-vpn10-int-vrrp for the Cisco VPN Interface Ethernet and click on Save
47
9. Back at the main Device Template screen, click on Update
48
10. Enter a Priority of 110 for cEdge50 and a priority of 100 for cEdge51. This will ensure that cEdge50 becomes the
MASTER, if available. Click on Next
49
11. Click on Configure Devices
12. Confirm the configuration change and click on OK
50
13. Once the configuration change goes through, log in to console of cEdge50 and cEdge51 via Putty and enter the
command show vrrp 5 Gig3 on both. We should see that cEdge50 is the MASTER and cEdge51 is the BACKUP
51
Task List


1. Log in to site50pc, Right Click on to the VM and select Console.
52
2. Log in to the Site50 PC. Search for terminal and click on the icon to open Terminal
3. Enter ping 10.100.10.2 . The pings should be successful. Let the pings run
53
4. Back at the console for cEdge50, enter the commands to reload this Router. In privilege mode, type reload and confirm.
This is happening since there is a short while when both Routers respond to the pings (since we’ve done a soft
reboot of the router)
54
5. Check the Console for site50-pc, you will notice Duplicate (DUP!) ping packets on the Terminal screen After a few seconds, the pings should stabilize and we’ll
receive a response from just cEdge51.
6. Issue show vrrp 5 Gig3 on the CLI of cEdge51 and you will notice that it is now the MASTER. Also, the priority of
cEdge51 has been set to 100 - this will play a role once cEdge50 comes up
55
7. Wait for cEdge50 to come up (approx. 5 minutes). Once you’re able to SSH to it, issue show vrrp 5 Gig3 - you will
notice it has taken the role of MASTER (look at the priority - it’s 110, meaning cEdge50 will always be the MASTER if
available). Had we left both the devices at the default priority of 100, cEdge51 would have continued being the
MASTER even after cEdge50 came back up.
Changing the priority of cEdge50 to a higher value and forcing it to be the MASTER might cause issues since it’s
possible that the LAN/VRRP side of the Router comes up post a reboot before the WAN/OMP side is ready. This
might lead to a few dropped packets
56
Thus, we have set up a First Hop Redundancy Protocol at Site 50. This completes our Verification and Testing.
Task List

57
TLOC Extensions at Site 20
Summary: Configuring TLOC Extensions for transport redundancy.
Table of Contents
Overview
Feature Templates for TLOC Extensions
Updating the VPN and Device Templates
Task List
Overview
Creating the VPN Interface Template for the TLOC-EXT interface
Creating the VPN Interface Template for the Tunnel interface
Creating the BGP Template for the MPLS link
58
Overview
A number of sites have a couple of routers in place, but transport connectivity to just one of the available transports. In the
event of a link failure, there is no mechanism for traffic to be redirected over the other transport. That’s where TLOC
Extensions come in.
TLOC Extensions allow vEdge/cEdge routers with a single transport to utilize the link on another vEdge/cEdge router at the
same site. Given below is a graphical representation of what we’re trying to achieve in this section of the lab.
59
vEdge20 is connected to the Internet transport whereas vEdge21 is connected to MPLS. If the Internet link goes down,
vEdge20 doesn’t have a way to utilize the MPLS link available at vEdge21. TLOC Extensions seek to remedy this.
vEdge/cEdge routers build IPSec tunnels across directly connected transports AND across the transport connected to the
neighboring vEdge/cEdge router to facilitate transport redundancy.
60
Without TLOC Extensions, the vEdges at Site 20 look something like the images below. Note that both have control
connections to the vSmarts and vManage via the directly connected transport, which can be checked using the CLI show
control connections
BFD sessions are established across the directly connected transport as well. Check via the CLI show bfd sessions
61
Task List
Overview

We will need to create a total of three Feature Templates for this section which will be applied to vEdge20 and vEdge21
Device Templates.
Towards the end of the lab, we will copy and modify the VPN 0 feature template used by the INET interface on vEdge20 to
allow for NAT. Both vEdges at Site20 use the same feature template for VPN 0 ge0/0 so making a change on one will impact
the other as well. Hence, we will be breaking off the vEdge20 VPN Interface template from the one being used. This new
template will be identical to the VPN 0 interface template being used at this Site, except for NAT being enabled on ge0/0.

1. On the vManage GUI, click on Configuration => Templates and go to the Feature tab. click on Add Template and
search for vedge. Select vEdge Cloud from the list and choose VPN Interface Ethernet to create an Interface
Template
62
2. Enter the details as shown in the table below. Use the images for reference. Click on Save once done
Section Field Global or Device Specific Value

(drop down)
Template NA Site20_TLOC_Ext_NoTunn
Name
Description NA Site 20 TLOC Extension Template without

Tunnel Configuration
Basic Shutdown Global No

Configuration
Basic Interface Device Specific if_name_notunn_tlocext

Configuration Name
63
Basic IPv4 Device Specific if_ipv4_address_notunn
Configuration Address
Advanced TLOC Global ge0/0

Extension
64
This completes configuration of the VPN Interface Template for TLOC Extension interfaces, without a Tunnel. Each
participating vEdge/cEdge will have an interface that will not have a Tunnel associated with it (but will have a TLOC
Extension association) and another one which will have a Tunnel (but won’t have a TLOC Extension associated with it).
Task List
Overview

1. Navigate to Configuration => Templates => Feature tab and search for tloc. You should get one template (the one
we just created). Click on the three dots next to it and choose Copy
2. Rename the Template to Site20_Tunn_no_tlocext with a Description of Site 20 Template with Tunnel Configuration no
TLOC-Ext. Click on Copy
65
3. Click on the three dots next to the newly created template and choose to Edit
4. Update the details as in the table below. Use the images for reference and click on Update when done
66
Section Field Global or Device Specific (drop Value
down)
Basic Shutdown Global No

Configuration
Basic Interface Device Specific if_name_tunn_notlocext

Configuration Name
Basic IPv4 Address Device Specific if_ipv4_address_tunn

Configuration
Tunnel Tunnel Global On

Interface
Tunnel Color Device Specific tloc_if_tunnel_color_value
Tunnel Restrict Device Specific tloc_if_tunnel_color_restrict
Tunnel - Allow All Global On

Service
Advanced TLOC Default

Extension
67
68
This completes the configuration of our second feature template.
69
Task List
Overview
- Creating the BGP Template for the MPLS link

We will now set up the BGP template for eBGP peering on the MPLS link. This is so that the TLOC extension subnet
(192.168.26.0/24 in this case) can be advertised to the MPLS network.
1. On the vManage GUI, go to Configuration => Templates => Feature tab. Click on Add Template and search for
vedge. Select vEdge Cloud and scroll down to the Other Templates section. Choose BGP
70
2. Enter the Template Name as vedge21_mpls_bgp_tloc and the Description as BGP Peering Template for TLOC
Extension on the MPLS link. Set Shutdown to a Device Specific variable of bgp_shutdown. Set AS Number to a
global value of 65534. This will be the AS number on our vEdge21 for BGP Peering
3. Under Unicast Address Family, set the Maximum Paths to 2. Click on the Network tab and click on New Network.
Enter the Network Prefix as a global value of 192.168.26.0/24 and click on Add. This is the subnet which will be
advertised in BGP
71
4. Under Neighbor, click on New Neighbor and enter details as per the table below. Click on Add (don’t miss this - far
right corner) to Add the Neighbor details and then click on Save (bottom-middle of the screen) to Save this template
Section Field Global or Device Specific (drop down) Value
Neighbor Address Global 192.0.2.9
Neighbor Remote AS Global 65535
Neighbor Address Family Global On
Neighbor Address Family Global ipv4-unicast
72
This completes the configuration of our BGP Template.
Task List
- Overview
73
Tip: We are setting many of the fields to Global values since this is a lab environment. In production, it is
recommended to set certain fields as Device Specific variables so that the templates can be re-used as and when
required, for disparate device configurations. The best-case scenario is to have as much common configuration
between devices/sites as is possible (global values) and then create Device Specific variables for the uncommon
parameters.

We will start by updating the existing VPN template for Site 20 (named Site20-vpn0) to include a default route with a next
hop to the corresponding TLOC Extension interface (i.e. to 192.168.26.21 on vEdge20 and 192.168.25.20 on vEdge21).
Device Specific variables will be used.
1. Navigate to Configuration => Templates => Feature tab on the vManage GUI. Search for site20 and you should see
the Site20-vpn0 template. Click on the three dots next to it and choose to Edit
2. Scroll down to the IPv4 Route section and click on the pencil icon next to 0.0.0.0/0 route to edit it
74
3. Click on 1 Next Hop in the Update IPv4 Route popup
4. Click on Add Next Hop and set the new hop address to Device Specific with a name of tloc_ext_next_hop_ip. Click
on Save Changes
5. Click on Save Changes again, making sure that the Update IPv4 Routes field now shows 2 Next Hop
75
6. Back at the VPN Feature template, make sure that the number 2 shows up under Selected Gateway Configuration
and click on Update
7. Populate the details for the Address (tloc_ext_next_hop_ip) for the two vEdges. vEdge20 should have 192.168.26.21
and vEdge21 should have 192.168.25.20 as the next hop IP. Click on Next
76
8. You can view the side by side configuration if needed, and click on Configure Devices. Choose the confirm the
changes and click on OK
77
9. To edit the Device Template and bring everything together, navigate to Configuration => Templates on the vManage
GUI. Make sure you’re on the Device tab and locate the vedge_Site20_dev_temp template. Click on the three dots
next to it and choose to Edit
78
10. Under Transport & Management VPN, click on BGP under Additional VPN 0 Templates. Click on VPN Interface
twice to add two VPN Interfaces over on the left-hand side. Populate the BGP template we created in the BGP field
(Named vedge21_mpls_bgp_tloc). Populate Site20_TLOC_Ext_NoTunn under the first VPN Interface and
Site20_Tunn_no_tlocext under the second VPN Interface. Click on Update
11. Click on the three dots next to vEdge20 and choose Edit Device Template. Enter the details as shown in the
table below, referencing the image and click on Update
Field Value
Interface Name (if_name_tunn_notlocext) ge0/4
IPv4 Address (if_ipv4_address_tunn) 192.168.26.20/24
Color (tloc_if_tunnel_color_value) mpls
Restrict (tloc_if_tunnel_color_restrict) Checked
79
Interface Name (if_name_notunn_tlocext) ge0/1
IPv4 Address (if_ipv4_address_notunn) 192.168.25.20/24
Shutdown (bgp_shutdown) Checked
12. Click on the three dots next to vEdge21 and choose Edit Device Template. Enter the details as shown in the table
below, referencing the image and click on Update and then click on Next
Field Value
Interface Name (if_name_tunn_notlocext) ge0/1
80
IPv4 Address (if_ipv4_address_tunn) 192.168.25.21/24
Color (tloc_if_tunnel_color_value) public-internet
Restrict (tloc_if_tunnel_color_restrict) Unchecked
Interface Name (if_name_notunn_tlocext) ge0/4
IPv4 Address (if_ipv4_address_notunn) 192.168.26.21/24
Shutdown (bgp_shutdown) Unchecked
81
13. View the side by side configuration (optional) and click on Configure Devices. Confirm the configuration change on 2
devices
Tip: It’s important to make another change to the Internet transport so that our TLOC Extension configuration
works as expected. We need to enable NAT on the VPN Interface associated with the Internet link. Unfortunately,
NAT can’t be enabled/disabled via Device Specific parameters so we will need to copy the VPN Interface
template, tweak it and then copy the Device Template to reference the new VPN Interface template. We will then
attach vEdge20 to this template.
14. From the vManage GUI, navigate to Configuration => Templates. On the Feature tab, search for vpn0. Locate the
82
site20_vpn0_int template and make a copy of it, renaming to site20_vpn0_int_nat and updating the description
accordingly
15. Click on the three dots next to the new site20_vpn0_int_nat template and choose to Edit. Set NAT to a global value of
On and click on Update
16. Make sure you’re on the Configuration => Templates Device tab and locate the vEdge_Site20_dev_temp template.
Make a copy of it, renaming to vEdge_Site20_dev_temp_nat and updating the description accordingly
83
17. Choose to Edit the newly created vEdge_Site20_dev_temp_nat via the three dots next to it and update the VPN
Interface field under Transport & Management VPN to reflect the VPN Interface template we created in step 14/15.
The name of the newly created VPN Interface template is site20_vpn0_int_nat. Click on Update
18. Click on the three dots next to the vEdge_Site20_dev_temp_nat device template and click on Attach. Choose the
vEdge20 device and attach it. Click Next/Configure Device as the prompts pop up (nothing will need to be populated
since we’re using a device template copied from before with NAT set to On)
84
This completes the configuration of TLOC Extensions at Site 20.
Task List
Overview
1. To verify that our configuration is working, log in to the CLI of vEdge20 and vEdge21. Issue the same commands as
before and compare with the output we had taken at the start of this section
Output of show control connections and show bfd sessions given below
85
Note: If you get output that looks like the image below for vEdge20 (i.e. there are 3 mpls TLOC control
connections and 2 public-internet connections, issue a clear control connections, wait for a couple of
minutes and run show control connections again. The output should match with what we see above.
86
2. Similarly, log in to vEdge21 and compare the output of the same commands (click here to compare the output).
Commands are again show control connections and show bfd sessions
We now see that the vEdges have established control connections over the transport connected to their counterpart at the
same site. BFD sessions are also established across the platform transports. Thus, we should see control connections and
bfd sessions across mpls on vEdge20 and across public-internet on vEdge21, along with their directly connected transport
connections/sessions.
87
Task List
Overview
88
Configuring a Hub and Spoke topology
Summary: Moving the SD-WAN topology from the default of full mesh to a Hub and Spoke for a particular VPN
while leaving the other VPNs in full mesh.
Table of Contents
Overview
Creating a new DC VPN 20 Feature

Template
Creating the Policy
Configuring Network Constructs
Task List
Overview
Creating a new DC VPN 20 Feature Template
Creating the Policy
Adding a Custom Control Policy
Overview
Cisco SD-WAN builds out a full mesh network between sites by default for all VPNs. This might not be desirable in some
cases, where there is a requirement of a Hub and Spoke or a partial mesh topology.
Cisco SD-WAN Policies allow us to enforce a custom topology, thereby controlling the data flow within our network. We will
be setting up a Hub and Spoke topology for VPN 20 at all Branch sites, steering data to the DC site, post which it will be
89
routed to its destination. Other VPNs in the network will retain full mesh connectivity. First, let’s check the current status of
the connectivity.
1. Log in to the vManage GUI and navigate to Monitor => Network
2. Click on vEdge20 and scroll down to Troubleshooting. Click on it and then choose Trace Route
90
3. Enter the Destination IP as 10.30.20.2, choose VPN as VPN - 20 and populate the Source/Interface as ge0/3. Click
on Start. You will notice that traffic is flowing directly between the two sites (i.e. Site 20 and Site 30) in VPN 20 (if
there are multiple hops shown in the image in your POD, run the test again)
4. Run another test, this time to the Destination IP of 10.40.20.2. Traffic again flows directly between the sites
5. Log in to the CLI of cEdge40 via Putty and issue a show ip route vrf 20 . We will see that routes point directly to
the sites, thereby facilitating full mesh connectivity
91
6. Log in to the CLI of vEdge20 and issue a show ip route vpn 20 . Once again, routes are pointing directly to the
corresponding site, which is expected behaviour (you will see routes on the mpls color as well). We will be looking at
changing this in the upcoming sections
92
Task List
Overview
Creating the Policy
Note: This section is optional. We will be testing just inter-site traffic so the changes in this section won’t come into
play, but if VPN 20 has to route all traffic through the DC, it might encompass Internet traffic as well. In this event, the
following configuration is needed to steer all unknown prefixes to the DC.
93
1. Go to Configure => Templates => Feature tab on the vManage GUI
2. Locate the vedge-vpn20 Feature Template and click on the dots next to it. Choose to make a Copy of this template
3. Rename the template vedge-vpn20-DC with a Description of VPN 20 Template for vEdges at the Data Center and
click on Copy
94
4. Click on the dots next to the newly created template and choose to Edit it. Make sure that the Template Name and
Description match and modify the Name field under Basic Configuration to a Global value of PoS
95
5. Under IPv4 Route click on New IPv4 Route. Enter a Prefix of 0.0.0.0/0 and set the Gateway as Null 0. Toggle Enable
Null0 to a Global value of On and click on Add. Click on Update to update this Feature Template
96
6. Go to Configuration => Templates => Device Tab and locate the DCvEdge_dev_temp. Click on the three dots to the
template and choose to Edit
7. Scroll to the Service VPN section, select the vedge-vpn20 Template and choose Remove VPN (don’t worry, we will
be adding it again, with the template we just created in steps 4 and 5)
8. Confirm removal of the VPN by clicking on Remove
9. Back on the Device Template, click on Add VPN under Service VPN. Move the vedge-vpn20-DC Template to the
Selected VPN Templates section and click on Next
97
10. Click on VPN Interface under Additional VPN Templates and populate vedge-vpn20-int in the VPN Interface drop
down. Click on Add. This should take you back to the Device Template page. Click on Update
11. Click on Next followed by Configure Devices in the ensuing pages (you can choose to check the side by side
configuration before choosing to Configure Devices)
98
12. Confirm the change on 2 devices (the DC-vEdges)
13. Once complete, go to console of vEdge20 via Putty and issue show ip route vpn 20 again. You should notice
default routes pointing to the DC-vEdges (at this point, site to site traffic will still not go via the DC-vEdges. For this, we
will need to implement control policies)
99
We have completed updating our Device Template to support a Hub and Spoke topology for VPN 20. Enforcement of the
Hub and Spoke topology will be done in the following sections.
100
Task List
Overview
Creating the Policy
Creating the Policy

We will now start enforcement of the Hub and Spoke topology via Control Policies. This is kicked off by creating a Policy
which encompasses various Network Constructs (like Site Lists, VPN Lists etc.) that are used within the Policy.

1. First, let’s create our overarching policy. Through this policy, we will create our Network Constructs. Click on
Configuration => Policies in the vManage GUI to start configuring the Policy
2. Click on Add Policy
101
3. We will first create a Site List. Click on Sites and then choose New Site List. Give it a name of Branches and enter
20,30,40,50 in the Add Site section. Click on Add
102
4. Three more Site Lists need to be created in a similar fashion. Some won’t be used right now, but it’s best to create
them while we’re here. Use the table and images below as reference points
Site List Name Add Site
DC 1000
Site30 30
Site40 40
Site List for the DC
103
Site List for Site 30
104
Site List for Site 40
5. Once all the Site Lists are configured, it should look like this
6. Click on VPN on the left-hand side and click on New VPN List. Specify the VPN List Name as Corporate and enter 10
under Add VPN. Click on Add
7. Repeat Step 6 two more times to create VPN Lists for PoS and Guest. They will have VPNs of 20 and 30 associated
with them, respectively
105
8. Click on TLOC on the left-hand side then click on New TLOC List. Give a List Name of DC-TLOCs. Specify the
following values (click Add TLOC 3 times - this will add the number of rows we need)
TLOC IP Color Encap
10.255.255.11 public-internet ipsec
10.255.255.11 mpls ipsec
10.255.255.12 public-internet ipsec
10.255.255.12 mpls ipsec
106
9. The DC-TLOCs list should look like the following image. Click on Next
107
We will pause here since configuration of the Network Constructs is complete for our Control Policy. These will be used as
building blocks for our policies. Configuration of the policy itself will continue in the next section (carrying on from the page
we’re at in the vManage GUI).
Task List
Overview
Creating the Policy
108
Continuing from the previous section, let’s build out our Custom Control Policy to enforce a Hub and Spoke Topology on
VPN 20
1. You should be at the Configure Topology and VPN Membership page after the previous section. Click on Add
Topology and choose Custom Control (Route & TLOC)
2. Specify a Name of HnS-VPN20 with a Description of Hub and Spoke for VPN 20 only. Click on Sequence Type and
choose to add a Route Control Policy
109
3. Click on Sequence Rule to add a new rule
4. Under Match click on Site and populate Branches in the Site List (this is one of the Site Lists we had created before)
110
5. Still under Match, click on VPN and choose PoS in the VPN List
Through these two match conditions, we have specified that this rule applies to the site list Branches (which contains
Site IDs 20, 30, 40 and 50) and to the PoS VPN (which has VPN 20 in it)
6. Move over to the Actions tab and click on Accept. Then click on TLOC and populate DC-TLOCs in the TLOC List.
Click on Save Match and Actions
111
7. Go to the Default Action and click on Accept. Click Save Match and Actions
8. The HnS-VPN20 policy should look like the image below. Click on Save Control Policy
112
9. Click on Next since we don’t want to add any more Policies and then Next again (since we aren’t doing any
Application Aware Routing, Data Policies or NetFlow policies as of now)
113
114
10. You should be presented with a screen which asks for a Policy Name, among other things. This can be a bit confusing
since we just gave a Policy Name before (called HnS-VPN20). The easiest way to wrap your head around this is think
of creating a Master Policy and before we can name this Master Policy, we are asked to create Sub-Policies in it. So
far, we have just created a Sub Policy and given it a name. At this point, we are being asked to give a name to our
Master Policy, which will then need to be applied.
Enter a Policy Name of Hub-n-Spoke-VPN20-only and give a Policy Description of Hub and Spoke policy for VPN 20
only. Click on New Site List under HnS-VPN20 and populate Branches in the Outbound Site List. Click on Add
Tip: Control Policies (such as the one you just built) are enforced by vSmart. Hence, the policy you just
created is from the perspective of vSmart. The application of this policy is enforced in an outbound direction
towards branch sites (i.e. Branches Site List). Think of how a BGP Route-Reflector would modify the next-hop of
routes it receives before sending them back out to neighbors.
Click on Save Policy
11. Back at the main Policy page, we should see the Hub-n-Spoke-VPN20-only Master Policy created. Click on the three
dots next to it and choose to Activate the policy
115
12. Confirm the activation by clicking on Activate
This completes our policy creation and activation. We will verify functionality in the upcoming section.
116
Task List
Overview
Creating the Policy
1. Log in to cEdge40 and run show ip route vrf 20 . When compared to the output of this command taken before we
applied our policy, we see that all routes are now pointing to the DC-vEdges. Check Step 5 of Overview for the earlier
output
117
2. On the vManage GUI, go to Monitor => Network and click on vEdge20. Scroll down on the left-hand side and click
on Real Time. Enter IP Routes in Device Options and choose to Filter. Filter on the basis of VPN ID 20. We will
notice similar output as what was seen for cEdge40
118
3. Go to Troubleshooting and choose Trace Route. Enter the Destination IP as 10.30.20.2 with a VPN of VPN - 20 and
a Source/Interface of ge0/3. Traffic is now reaching the destination via the DC-vEdge
4. Run the traceroute for 10.40.20.2 and we see that traffic is being routed through the DC-vEdge in this case as well
119
5. Try to do a traceroute to 10.40.10.2, changing the VPN to VPN - 10 and the Source/Interface to ge0/2 and we will
notice that VPN 10 still has full mesh connectivity
Thus, all traffic from VPN 20 in the Branches is being steered to the DC-vEdges in a Hub and Spoke topology, whereas
traffic still utilizes a Mesh topology for other VPNs.
120
Task List
Overview
Creating the Policy
Setting up a Regional Hub

Summary: Steering all traffic from Site 20 to a Regional Hub (Site 30).
Table of Contents
Pre-Configuration
Adding the Policy
Verification
121
Task List
Pre-Configuration
Adding the Policy
Setting up Site Lists
Adding Custom Control policies
Policy for Traffic from Site 20 to the Regional Hub
Policy for Traffic from the Fabric to Site 20
Saving and Activating the Policy
Verification
Pre-Configuration
In this section, we will ensure that whenever communication has to happen in/out of Site 20, it goes through Site 30. This
means there will be two parts to the configuration - how Site 20 talks to other sites, and how other sites talk to Site 20. Site
30 will function as a Regional Hub for Site 20. Given below is the traffic flow we’re looking to achieve.
122
Notice that all sites communicate to Site 20 via Site 30. Conversely, Site 20 punts all outbound traffic to Site 30.
1. We will first deactivate the Hub and Spoke policy created for VPN 20. On the vManage GUI, navigate to
Configuration => Policies and click on the three dots next to the Hub-n-Spoke-VPN20-only policy. Choose to
Deactivate it
123
2. Confirm the Deactivation
3. Verify that traffic for VPN 20 is now flowing per the default Mesh topology. Navigate to Monitor => Network and click
on vEdge20. Scroll down on the left-hand side to Real Time and enter IP Routes in the Device Options. Choose to
Filter on the basis of VPN ID 20
124
Task List
Pre-Configuration
Adding the Policy
Verification
Adding the Policy

1. Go to Configuration => Policies and click on Add Policy
125
2. Click on Site and choose to add a New Site List. Populate the Site List Name as Fabric and Add Site of 1000,40,50
(i.e. all the Sites other than the Regional Hub and Regional Spoke sites). Click on Add
3. Click on New Site List again and give this Site List a Name of Site20 with an Add Site of 20. Click on Add. Click on
Next to move on to the Configure Topology and VPN Membership page, which we will continue configuring in the
next section
126
4. Once all the sites are configured, it should look like this:
127
Task List
Pre-Configuration
Adding the Policy
Verification
Adding Custom Control Policies
We will be adding two policies in this section - one for traffic destined to the rest of the network from Site 20 and one for
traffic destined to Site 20.
1. Continuing from the previous section, click on Add Topology and choose to add a Custom Control (Route and
TLOC) topology
128
2. Give this Control Policy a Name of Site20-to-Reg and a Description of Site 20 to Regional Hub at Site 30. Click on
Sequence Type and choose TLOC
3. Choose to add a Sequence Rule and click on Site under Match. Populate the Site List as Site30
129
4. Go to the Actions tab and choose Accept. Click on Save Match and Actions
5. Click on Sequence Type again and this time choose Route
130
6. Click on Sequence Rule and go to the Actions tab. Click on Accept and click on TLOC. Click on the drop down for
selecting a TLOC List and click on New TLOC List
7. Enter Site30 as the List Name and choose to Add TLOC. This should give two rows. The TLOC IP is 10.255.255.31
(in both rows) and the Encap is ipsec. One row should have the color public-internet whereas the other row should
have mpls. Click on Save
131
8. Click on the drop-down for the TLOC List and choose the Site30 List we just created. Click on Save Match and
Actions
132
9. Make sure the configuration looks like the image given below and click on Save Control Policy. Note that there are
two Sequence Types - a TLOC and a Route, along with the Default Action
133
Continue with the next section for configuring another Control Policy.
Task List
Pre-Configuration
Adding the Policy
Verification
134
1. Back at the Configure Topology and VPN Membership page, click on Add Topology. We will add another Custom
Control (Route & TLOC) policy
2. Give this Control Policy a name of Fabric-to-Site20 with a Description of Fabric traffic to Site 20. Click on Sequence
Type and choose TLOC. Click on Sequence Rule and select Site under Match. Populate Site20 in the Site List. Click
on Save Match and Actions since the default of Reject Enabled is what we want for this Control Policy
135
3. Click on Sequence Type again and choose Route. Click on Sequence Rule and choose Site under the Match tab.
Populate Site20 in the Site List. Click on the Actions tab and choose Accept. Click on TLOC and populate Site30 from
the TLOC List drop down. Click on Save Match and Actions
136
4. Click on Default Action and choose Accept. Save Match and Actions to complete configuration of this Control Policy
and click on Save Control Policy
We will complete configuration of the Policy in the next section.
Task List
Pre-Configuration
Adding the Policy
Verification
137
1. Click on Next two times from the page you’re on at the end of the previous section (this should take you to the Apply
Policies to Sites and VPNs page). Enter the Policy Name as Site20-Regional-Hub-Site30 and the Description as
Regional Policy for Site 20 to Site 30. Click on New Site List and populate Fabric in the Outbound Site List for the
Fabric-to-Site20 Custom Control Policy. Click on Add
2. Under the Site20-to-Reg Custom Control policy, click on New Site List and populate Site20 in the Outbound Site List.
Click on Add and then click on Save Policy
3. Click on the three dots next to the Site20-Regional-Hub-Site30 policy and choose to Activate it
138
4. Confirm the Activation
This completes the configuration of our Policy for making Site 30 a Regional Hub to Site 20. We will verify the configuration
done in the next section.
139
Task List
Pre-Configuration
Adding the Policy
Verification
Verification
1. On the vManage GUI, navigate to Monitor => Network and click on vEdge20. Scroll down to Troubleshooting (on the
left-hand side) and click on Trace Route. Enter the Destination IP as 10.100.10.1 with a VPN of VPN - 10 and a
Source/Interface of ge0/2. Click on Start
Notice that the traffic destined for the DC Service Side VPN is going through Site30 (10.30.10.2) and then getting
routed over to the DC-vEdge.
140
2. Click on Tunnel on the left-hand side and notice that vEdge20 has a single Up tunnel with vEdge30 on public-internet
and one on mpls. Other tunnels are not up (as expected)
3. Click on Select Device in the top left-hand corner and choose vEdge21. You will notice a similar output here with
respect to the Tunnels
141
4. Go to Troubleshooting => Trace Route and enter the same details as before (i.e. a Destination of 10.100.10.1, VPN
of VPN - 10 and a Source/Interface of ge0/2). Click on Start
We see that traffic from vEdge21 destined for the DC-vEdge Service Side VPN traverses vEdge30 (10.30.10.2) before
being punted over to the DC-vEdge
5. To verify traffic flows towards Site20, choose Select Device from the top left-hand corner and select DC-vEdge1.
Enter the Destination IP of 10.20.10.2 with a VPN of VPN - 10 and a Source/Interface of ge0/2. Click on Start
Notice that over here as well, traffic from the DC-vEdge goes to Site20 through Site30.
This completes the configuration of our Regional Hub.
142
Implementing Custom Traffic Engineering
Summary: Influencing Path selection and facilitating custom traffic engineering in Cisco SD-WAN
Table of Contents
Overview
Deploying a Policy
Verification
Task List
Overview
Deploying a Policy
Setting up Groups of Interest and Traffic Rules
Applying and Activating the Policy
Verification
Overview
The Cisco SD-WAN solution builds a full mesh topology by default and there isn’t any traffic engineering that is in place out
of the box. The ability to steer application traffic per the network requirements via a specific path is something that can be
achieved via data policies. We can leverage data policies to match specific traffic and send it via the preferred transport. To
verify current functionality:
143
1. Log in to the vManage GUI and navigate to Monitor => Network
144
2. Click on vEdge30 and scroll down the list on the left-hand side to Troubleshooting
145
3. Click on Simulate Flows
146
4. Enter VPN - 10 as the VPN, ge0/2 as the Source/Interface and 10.0.0.1 as the Destination IP. Click on Simulate
We find that general traffic uses all possible available transports to send data to the other side.
147
5. Keep all details the same, but this time choose ftp under Application. Click Simulate
Once again, ftp traffic is also attempting to take all possible transports.
In our example, we will assume that the requirement is to send FTP traffic over the MPLS link (preferred).
Task List
Overview
Deploying a Policy
Verification
Deploying a Policy
We begin by creating a Policy and identifying Groups of Interest (or interesting traffic). The policy is then expanded to
encompass a Data Policy.
148
1. On the vManage GUI, navigate to Configuration => Policies.
2. Under Centralized Policy, click on Add Policy to create a new Policy

149
3. We will be making use of the Site30 Site List created before. Click on Next two times.
4. Make sure you are under Configure Traffic Rules. Click on the Traffic Data tab and choose to Add Policy. Click on
Create New
150
5. Given the policy a name of ftp-mpls and a description of FTP via MPLS. Click on Sequence Type and choose Traffic
Engineering as the Data Policy
6. Click on Sequence Rule and choose Application/Application Family List as the match condition. Click on the drop-
down for the Application/Application Family List and click on New Application List
151
7. Give the Application List Name as ftp and select File Transfer Protocol and File Transfer Protocol Data under the
Select Application drop down
152
8. Make sure the Application List looks like the image below and click on Save. We are defining the interesting traffic
over here via this Application List
153
9. From the Application/Application Family List drop down, choose the ftp Application List we just created
154
10. Click on the Actions tab and choose Accept. Select Local TLOC and choose the Local TLOC List: Color as mpls.
Set the Local TLOC List: Encapsulation to IPSEC. Click on Save Match and Actions
11. Choose Default Action on the left-hand side and click on the pencil icon to edit the default action
12. Select Accept and click on Save Match and Actions
13. Back at the Data Policy window, click on Save Data Policy
155
14. At the main Policy window, click on Next
Continue to the steps in the next section.
156
Task List
Overview
Deploying a Policy
Verification

Continuing from the Setting up Groups of Interest and Traffic Rules, we will now finalize our policy and activate it.
1. Give the Policy a name of traffic-engineering-ftp and a description of Traffic Engineering for FTP. Click on the Traffic
Data tab and click on New Site List and VPN List. Leave the From Service radio button selected and populate
Site30 in Select Site List and Corporate in the Select VPN List. Click on Add and then click on Save Policy
2. This should create our traffic-engineering-ftp policy. Click on the three dots next to it and choose Activate
157
Tip: At this point we have created multiple policies and are activating them as we go along. However, this is
not a standard practice. At a time, only one policy can be active so all our Policy requirements are generally
concatenated into a single policy. Separate policies have been created in the lab for simplicity.
3. Click on Activate
We have now deployed our Policy.
158
Task List
Overview
Deploying a Policy
Verification
Verification
In order to verify that traffic flows have changed, we will be comparing the output in the Overview section to output which
will be taken here.
1. On the vManage GUI, go to Monitor => Network and select vEdge30. Scroll down to Troubleshooting on the left-
hand side and click on Simulate Flows
159
160
2. Enter VPN - 10 for the VPN and ge0/2 for the Source/Interface. The Destination IP will be 10.0.0.1. Click on
Simulate
161
We can see that general traffic is still attempting to use all possible transports.
3. Set the Application to ftp and click on Simulate
FTP Traffic now flows via the MPLS transport, as per our requirement.
This completes the verification activity for this section.
Task List
Overview
Deploying a Policy
Verification
162
Implementing Direct Internet Access
Summary: Setting up a Direct Internet Access policy for Guest Users at Site 40
Table of Contents
Overview
Creating and Activating a Policy
Verification
Task List
Overview
Verification
Overview
We will now shift focus to setting up our DIA site at Site40. Guest users will connect on VPN 30 and we need to ensure they
have access to the Internet. We will first verify that the PC at Site 40 does not have Internet access. The WAN Interface at
Site 40 on public-internet will then be updated for NAT and a Policy will be applied (which will include a Data Prefix list and a
Data Policy) to allow users on VPN 30 to access the Internet.
163
1. Right click the site40pc and choose to stop, wait 30 seconds and then start (Sometimes the default gateway doesn't get populated
in the VM and a reboot fix that or you can run command “sudo ip route add default via 10.40.30.2”). Right Click on site40pc again, then click on console.
164
2. Open the Terminal
3. Type ping 8.8.8.8 and hit Enter. Pings should fail
We have thus verified that the Guest VPN user (with an IP of 10.40.30.21) doesn’t have internet access.
Task List
Overview
Verification
We will start by enabling NAT on the Internet interface and then continue with our Policy.
1. On the vManage GUI, navigate to Configuration => Templates => Feature Tab. Locate the cedge-vpn0-int-dual template created
before and click on the three dots next to it. Choose to Edit the template
165
2. Scroll down to the NAT section and set NAT to a Global value of On. Click on Update
3. Click on Next since we don’t need to change anything on the device settings and then click on Configure Devices.
You can view the side by side configuration if you want to
166
NAT should now be enabled on the public-internet transport
167
4. Navigate to Configuration => Policies on the vManage GUI and click on Add Policy
5. Select Data Prefix List on the left-hand side under Create Groups of Interest and choose New Data Prefix List. Give
it a name of Guest-Site40 and specify the Add Data Prefix as 10.40.30.0/24. Click on Add and then click on Next
(Please click on Add BEFORE clicking on Next else the Data Prefix List will not get added)
168
6. Click on Next on the Configure Topology and VPN Membership screen.
7. On the Configure Traffic Rules screen, click on the Traffic Data tab and choose Add Policy. Click on Create New
8. Give the Data Policy a name of Guest-DIA with a Description of Guest DIA at Site 40. Click on Sequence Type and choose Custom
169
9. Click on Sequence Rule and select Source Data Prefix under Match. Populate Guest-Site40 in the Source Data
Prefix List (we just created this Data Prefix list)
10. Click on the Actions tab and choose the Accept radio button. Select NAT VPN and click on Save
Match and actions
11. Click on Default Action over on the left-hand side and choose Accept. Click on Save Match and Actions
170
12. Click on Save Data Policy
13. Make sure the Data Policy we just added shows up and click on Next
171
14. Enter the Policy Name as Site40-Guest-DIA and a Description of DIA Policy for Site 40 Guests. Click on the Traffic
Data tab and choose New Site List and VPN List. Leave the radio button on From Service and choose Site40 under
Select Site List. Choose Guest under Select VPN List. Click on Add. Once added, click on Save Policy
172
15. Locate your Site40-Guest-DIA and click on the three dots next to it. Choose to Activate the policy
This completes the configuration of our DIA Policy.
Task List
Overview
Verification
Verification
1. To verify, log in to Console to the Site40 PC, as enumerated in the Overview section. On Terminal, enter
ping 8.8.8.8. The pings should succeed {These might fail due to dcloud FW policies not allowing ICMP}
173
2. Click on the Mozilla Firefox icon on the Site40 PC and try to browse to sdwan-docs.cisco.com (or any other website).
It should work
Task List
Overview
Verification
174
Configuring Application Aware Routing
Summary: Manipulate the path taken by traffic based on network parameters like latency, loss and jitter.
Table of Contents
Overview
Creating and Activating the AAR Policy
Viewing modified traffic flows and current

network statistics
Verify Policer configured for network

impairment
Applying the Policer on the MPLS link
Viewing changed statistics and resultant

traffic flows
Task List
Overview
Viewing modified traffic flows and current network statistics
Verify Policer configured for network impairment
Verify the Policer List
Verifying the IPv4 ACL Policy
Viewing changed statistics and resultant traffic flows
175
Overview
While we can use Traffic Engineering to steer traffic towards a particular preferred transport, Application Aware Routing
takes things to a different level by not only allowing us to punt traffic over a preferred path, but also define SLA parameters
for traffic to be redirected if network conditions aren’t favourable for the type of traffic.
To set a baseline, we will first see how traffic flows on VPN 10 (let’s assume that this VPN has Voice traffic in it). We will then
implement AAR and SLA Classes to route traffic out a preferred transport and switch the chosen transport if SLA
parameters are not met.
To check existing traffic flows, follow the steps below:
1. Navigate to Monitor => Network and select cEdge40 from the list. Scroll down on the left-hand side and click on
Troubleshooting. Choose Simulate Flows. Choose a VPN of VPN - 10 and a Source/Interface of GigabitEthernet4.
Enter the Destination IP as 10.100.10.2 and click on Simulate. Notice that traffic is attempting to use all available
transports. If you receive an error of "Failed to run service path" as shown in the second image below, log in to
vCenter and right click on the cEdge40 VM for your POD. Choose Edit Settings and uncheck the "Connected" check
box for Network Adapter 4. Click on OK. Wait for 10 seconds and check the same checkbox again. Now try to simulate
the flow
176
2. Click on Advanced Options and enter the DSCP value as 46 (i.e. VoIP RTP traffic). Click on Simulate. This traffic
also uses all possible transports, which might not be ideal for our network
177
Task List
Overview
Creating and Activating AAR Policy
Creating and Activating AAR Policy

We will now set up an AAR Policy for VoIP (i.e. DSCP 46) traffic.
1. On the vManage GUI, go to Configuration => Policies and click Add Policy. Click on Next twice (till you get to the
Configure Traffic Rules page) and click on Add Policy under Application Aware Routing. We thus have an
overarching Policy (let’s call it the Main Policy) and an application-aware routing policy within it. As of now, we will
configure the AAR routing policy. Towards the end, we will enter the details of the Main Policy
178
2. Give this AAR Policy a name of VPN10-AAR and a Description of Transport Preference for Traffic in VPN 10. Click on
Sequence Type and then click on Sequence Rule. Under Match, select DSCP and enter a DSCP value of 46 under
Match Conditions
179
3. Click on the Actions tab and choose SLA Class List. Click on the box under SLA Class and choose New SLA Class
List
4. Give the SLA Class a Name of Voice-SLA and specify the Loss % as 1. Enter 200 for the Latency and 15 for the
Jitter. Click on Save
180
5. Still under actions, select the Voice-SLA SLA Class that we just created and set the Preferred Color to mpls. Click on
Save Match and Actions
6. Ensure your App Route looks like the image below and click on Save Application Aware Routing Policy. Click Next
7. At the Apply Policies to Sites and VPNs page, give the Policy a Name of AAR-VPN10 and a Description of
Transport Preference for VPN 10. Click on the Application Aware Routing tab and click on New Site List and VPN List.
Under Select Site List choose Branches and DC. Under Select VPN List choose Corporate. Click on Add
181
8. Click on Save Policy in the lower middle part of the screen to save our AAR Policy
9. Click on the three dots next to the Site40-Guest-DIA policy created before and choose to Deactivate it (this needs to
be done due to a bug present in version 20.3.x of vManage, else Activation of the AAR policy we just created will give
an error of a "bad-element" in the configuration). Confirm the Deactivation. Once done, click on the three dots next to
the AAR-VPN10 policy we just created and choose to Activate it. Click on Activate again
182
183
Task List
Overview
184
To view the changes made by the Policy on our network, follow the steps below.
1. On the vManage GUI, go to Monitor => Network and click on cEdge40. Choose Troubleshooting from the left-hand
column and click on Simulate Flows. Enter the VPN as VPN - 10 and the Source/Interface as GigabitEthernet4. Set a
Destination IP of 10.100.10.2 and click on Simulate. We find that traffic is taking all possible transports, just like before.
This is expected since we haven’t defined anything for regular traffic
2. On the same screen, click on Advanced Options and set the DSCP to 46. Click on Simulate
VoIP Traffic is now traversing the MPLS link as the preferred route.
185
3. We will now check the current network statistics. Go to Monitor => Network => cEdge40 => Tunnel and put a check
mark against all the mpls Tunnel Endpoints. Click on Real-Time after scrolling up to the chart and make sure Packet
Loss/Latency is checked under Chart Options. We may see negligible packet loss occurring (let the chart run for 5
minutes before analyzing, it should get updated every few seconds)
Task List
Overview
186
In order to simulate impairment in the network (Packet Loss and Latency), we will use a Policer and a Shaper in this lab.
Over here, we will verify the policer list which is preconfigured, which will be applied to the MPLS link in order to simulate
Packet Loss.
Later on, we will leverage a Shaper to simulate Latency.

1. On the vManage GUI, navigate to Configuration => Policies. Click on Custom Options (top right-hand corner).
Under Localized Policy click on Lists
2. Verify the Policer name “AAR-Impair-Policer-PL” is pre-configured as per the following screen.
187
Task List
Overview

1. Go to the Localized Policy tab and click on three dots next to Policer-AAR-Impairment, and select view.
188
2. Click Access Control Lists Tab. Click on three dots next to Impair-PL-AAR and select View.
3. Verify how the policer is applied to all traffic, under match condition, since there is no statement, this means that all
traffic is going to be policed.
189
190
1. Navigate to Configuration => Templates => Feature Tab and locate the cedge-vpn0-int-dual_mpls VPN Interface
template. Click on the 3 dots next to it and choose to Copy
2. Rename it to cedge-vpn0-int-dual_mpls-impair and a Description cEdge VPN 0 Interface Template for Devices with a
dual uplink - MPLS with Impairment. Click on Copy
191
3. Click on the three dots next to this newly copied template and click on Edit
4. Navigate to the ACL/QoS section and modify the following fields. Click on Update
Field Global or Device Specific (drop down) Value
Ingress ACL - IPv4 Global On
IPv4 Ingress Access List Global Impair-PL-AAR
Egress ACL - IPv4 Global On
IPv4 Egress Access List Global Impair-PL-AAR
5. Under Configuration => Templates go to the Device tab and locate the cedge_dualuplink_devtemp template. Click
on the three dots next to it and choose to Edit
192
6. Under Transport & Management VPN, update the Cisco VPN Interface Ethernet from cedge-vpn0-int-dual_mpls to
cedge-vpn0-int-dual_mpls-impair. Make sure this is done on the VPN interface for the MPLS link
193
7. Scroll down to the Additional Templates section and update the Policy to Policer-AAR-Impairment. Click on Update.
Click on Next
8. You can choose to view the side by side or simply click on Configure Devices
194
This completes the implementation of our Policer on the MPLS link to simulate network impairment.
Task List
Overview
195
1. Navigate to Monitor => Network and click on cEdge40. Click on Tunnel on the left-hand side and make sure all the
MPLS Tunnel Endpoint entries are selected, with the public-internet entries being unchecked. Click on Real Time (top
right corner) and the Chart Options drop-down (top left corner) is set to Loss Percentage/FEC Loss Recovery Rate.
Let this run for a few minutes - you will notice a spike in Packet Loss
2. Head over to Troubleshooting (left-hand side, might need to scroll down) and click on Simulate Flows. Enter the
VPN as VPN - 10, the Source/Interface as GigabitEthernet4 and the Destination IP as 10.100.10.2. Click on
Simulate. There should be no change in traffic flow for General traffic, which will still use all available transports
196
3. Under Advanced Options, set DSCP to a value of 46 and click on Simulate. You will notice that VoIP traffic (i.e.
DSCP 46) is now taking the Internet path since MPLS doesn’t conform to the SLA requirements that we defined.
Compare the current traffic flow with the one in Step 2 over here
4. will now revert the configuration to what it was pre-impairment. Go to Configuration => Templates and locate the
cEdge_dualuplink_devtemp. Click on the three dots next to it and Edit. Change the Cisco VPN Interface Ethernet value
under Transport & Management VPN back to cedge-vpn0-int-dual_mpls and click on Update. Click on Next and Configure Devices
197
5. Wait for approximately 3 minutes and head over to Monitor => Network => cEdge40 => Troubleshooting => Traffic
Flows. Enter the same details as in Step 3 above and click on Simulate. VoIP traffic should traverse over the MPLS
link again
This completes the Application Aware Routing
198
Configuring Low Latency Queuing and QoS
Summary: SD-WAN allows configuration of various QoS strategies to better support your business. Configure
QoS with LLQ for VoIP traffic
Table of Contents
Create a Localized Policy
Apply the ACL and QoS Map
Task List

Add a Class List and a QoS Map
Configure the IPv4 ACL Policy
Complete and apply the localized policy
While Application Aware Routing allows us to choose the path taken by traffic and switch paths based on SLA parameters,
QoS strategies in SD-WAN allow packets to be marked with standard DSCP values which are then utilized to prioritize
packets accordingly.
Let’s assume that our Corporate VPN (VPN 10) has, among other traffic, VoIP packets flowing through it. We would want to
follow some QoS strategy to ensure that these VoIP (RTP, Video and Signaling) packets are placed in a Low Latency
Queue, with corresponding strategies for other types of traffic.
199
QoS in the SD-WAN world is implemented via Localized Policies. Differences in Localized and Centralized Policies can be
found over here .

1. On the vManage GUI, click on Configuration => Policies and choose the Localized Policy tab. Click on Add Policy
2. Under Create Groups of Interest click on Class Map on the left-hand side. Click on New Class List and specify the
Class as Voice. The Queue should be 0. Click on Save
200
This creates our Class List for VoIP traffic and puts the traffic in Queue 0.
3. Click on New Class List and create 3 more Class Lists, as shown below. Remember to hit Save after each Class List
is created
Class Queue
Video 1
BIZ-Data 2
Best-Effort 3
Once all the Class Lists are created, click on Next
201
4. The Class Lists are referenced in QoS Maps. Under Configure Forwarding Classes/QoS, make sure you’re on the
QoS Map tab and click on Add QoS Map
5. Give the QoS Map a Name of WAN-QoS and a Description of WAN QoS. Click on Add Queue. Specify the following
details and click on Save Queue
202
Queue Bandwidth % Buffer % Scheduling Drops Forwarding Class
1 30 30 Weighted Round Robin Tail Video (Auto Populated)

(WRR)
6. Click on Add Queue and add a couple more queues as per the table given below. Remember to click on Save Queue
after you’re done setting up the Queue
Queue Bandwidth Buffer Scheduling Drops Forwarding Class

% %
2 40 40 Weighted Round Robin Random BIZ-Data (Auto

(WRR) Early Populated)
3 10 10 Weighted Round Robin Random Best-Effort (Auto

(WRR) Early Populated)
203
Queue 2
Queue 3
204
7. The wagon wheel that shows Queue Bandwidth and Buffer allocation should change to reflect the settings in the
Queues that were just created
8. The QoS Map queues should look like the image below. Click on Save Policy to save your QoS Map and then click
on Next
205
Notice that the Queue 0 Forwarding Class is populated as Control. Control network traffic (not related to VoIP) is also
included in Queue 0 by default. Any traffic that’s mapped to Queue 0 is regarded as LLQ traffic.
This completes the QoS Map configuration. We will continue with building our Main Policy in the next section.
Task List

206
1. Continuing from the QoS Map which we just built, you show now be at the Configure Access Control Lists page. An
ACL Policy can be used for classification of traffic on the LAN. Click on Add Access Control List Policy and choose
to Add IPv4 ACL Policy
2. Give the ACL Policy a Name of LAN-Classification and a Description of LAN Classification. Click on Add ACL
Sequence and then click on Sequence Rule. Make sure you’re on the Match tab and click on DSCP. Enter a DSCP
value of 46. This specifies our match criteria
207
3. Click on the Actions tab and make sure the Accept radio button is selected. Click on Class and select the Voice
Class List which we created before. Click on Save Match and Action
208
4. Click on Sequence Rule and follow the same procedure to create rules as per the following table. Use the images
below the table for reference (the actions tab should always have the Accept radio button selected). Make sure that
you click on Save Match and Actions once done creating each rule
DSCP Class
34 Video
26 BIZ-Data
Leave Blank Best-Effort
Sequence Rule for Video
209
Sequence Rule for BIZ-Data
Sequence Rule for Best-Effort
5. Verify that the Access Control List Policy looks like the image below (i.e. you should see 4 sequence rules, one for
each Class List with the corresponding DSCP values as match conditions) and click on Save Access Control List
Policy
210
6. Click on Next twice and you should be at the Policy Overview page, which continues in the next section.
Task List

211
1. Continuing from the previous section, while on the Policy Overview page, give your policy a Name of QoS_Policy
and a Description of QoS Policy. Under Policy Settings, put a check mark next to Application and set the Log
Frequency to 30 (this will come into play if you are going through the SD-AVC configuration section). Click on Save
Policy
2. Navigate to Configuration => Templates and locate the cedge_dualuplink_devtemp Device Template. Click on the
three dots next to it and choose to Edit. Click on Additional Templates
212
3. Populate QoS_Policy in the Policy drop down. If you have gone through the Guest DIA configuration, note that this
will break Guest DIA functionality. In the real world, the QoS Policy we configured should be included within the same
policy. Click on Update
213
4. Click on Next and then Configure Devices. You can view the side by side configuration, if you want to
We have completed application of the QoS Policy for our Device. This will create the QoS Maps and
inject the corresponding Queues in the Scheduler.
Tip: vManage pushes the forwarding class names as Queue0, Queue1 etc. along with the created Class Names.
Queue0, Queue1 etc. are the ones which are actually used in the qos-map but the settings are based on the defined
class names (e.g. Voice, Video, BIZ-Data etc. for our lab). This is expected behaviour. Additionally, you will NOT see
Queue 2 in the QoS policy-map interface output since that is used for Best Effort traffic by default. However, if we were
to map the Queues to 0 for Voice, 1 for Video, 3 for BIZ-Data and 4 for Best-Effort, all 4 queues will show up.
214
Task List


We have created the QoS strategy for our network, the only thing that’s left is to apply and test our QoS configuration.
To apply the configuration, we will be modifying the Service VPN 10 interface such that traffic is classified on the basis of the
ACL we created, in the inbound direction.
The QoS Map will be applied in the outbound direction on the WAN interfaces (INET and MPLS)
1. Navigate to Configuration => Templates => Feature Tab and locate the cedge-vpn10-int Feature Template. Click on
the three dots next to it and choose to Copy the Template. Give a name of cedge-vpn10-int-qos to the copied
template with a Description of VPN 10 Interface Template for cEdges with QoS and click on Copy
215
2. Locate the newly copied cedge-vpn10-int-qos Feature Template and click on the three dots next to it. Choose to Edit
the template. Make sure the Description is updated and scroll down to the ACL/QoS section. Set Ingress ACL - IPv4
to a Global value of On and enter LAN-Classification as the IPv4 Ingress Access List. This needs to match with the
ACL we created (case sensitive). Click on Update
216
3. Navigate to the Device tab in Configuration => Templates and locate the cedge_dualuplink_devtemp. Click on the
three dots next to it and choose Edit
4. In the Service VPN section, click on the three dots next to the cedge-vpn10 Template and choose Edit
5. Change the template under Cisco VPN Interface Ethernet to cedge-vpn1-int-qos and click on Save
217
6. Click on Next and choose to Configure Devices. The side by side configuration can be viewed and we should see
the LAN-Classification ACL being applied on GigabitEthernet4 (Service VPN Interface for VPN 10) in the incoming
direction
218
7. Head back over to Configuration => Template => Feature Tab and locate the cedge-vpn0-int-dual template. Click on
the three dots next to it and click Edit. We will be updating the VPN 0 Internet interface with the QoS Map we created
before
8. Under the ACL/QOS section, specify the QoS Map as a Global value and enter WAN-QoS (case sensitive, should
match with the QOS Map we created before). Click on Update
219
9. Click on Next and then Configure Devices. If you want, inspect the side by side configuration before clicking on
Configure Devices and you will notice that the WAN-QoS Policy will be applied to GigabitEthernet2 (WAN VPN 0
Interface for INET)
220
10. Under the Configuration => Template => Feature Tab locate the cedge-vpn0-int-dual_mpls template. Click on the
three dots next to it and click Edit. We will be updating the VPN 0 MPLS interface with the QoS Map we created
before
11. Under the ACL/QOS section, specify the QoS Map as a Global value and enter WAN-QoS (case sensitive, should
match with the QOS Map we created before). Click on Update
221
12. Click on Next and then Configure Devices. If you want, inspect the side by side configuration before clicking on
Configure Devices and you will notice that the WAN-QoS Policy will be applied to GigabitEthernet3 (WAN VPN 0
Interface for MPLS). Check the configuration pushed by logging in to the CLI for cEdge40 via Console and issue show
running | sec interface Gig . We should see the WAN_QoS policy applied under GigabitEthernet2 and
GigabitEthernet3
222
This completes the configuration of our QoS Policy in VPN 10 at Site 40.
223
Task List
- Create a Localized Policy

1. Log in to the cEdge40 via Console and issue clear policy-map counters . Confirm that you want to clear the
counters. Now issue a show policy-map interface Gig2 and a show policy-map interface Gig3 . You will
notice the number of packets incrementing in Queue0 (this includes VoIP packets via configuration and Control
packets by default). Run the two commands given above multiple times and take notice of Queue3 and Queue0.
Queue3 should not increment, whereas Queue0 will keep incrementing
224
2. Locate VM site40-pc2 and open console.
3. Type ping 10.100.10.2. Let the pings run for a few seconds,
making note of how many packets did we receive a response for (look at the icmp_seq field) and then stop the pings
by pressing Ctrl + C. We let the ping run for 70 packets
4. Issue show policy-map interface Gig2 and show policy-map interface Gig3 again, on the cEdge40 CLI.
225
Queue3 in one of the outputs (depends on the path taken by the packets) should reflect an increment in the number of
packets
226
Thus, traffic is being matched as per our QoS strategy. However, we won’t be able to test other queues since ESXi (the
VMWare environment in which our lab is running) doesn’t allow packet tags to be propagated over Standard vSwitches (the
virtual switch). Queue0 shows up since this traffic is generated natively by the Router in question.
An extended ping directly from the Router yields unpredictable results, with traffic usually getting matched to class class-
default (optional - you can try this out).
This completes our QoS activity verification.

227
Task List

228
Configuring a Zone Based Firewall for Guest DIA
users
Summary: Implementing a Zone Base Firewall at Site 40 for Guest Direct Internet Access users
Table of Contents
Overview
Activate NAT DIA Policy
Setting up Lists
Creating a Security Policy
Applying the Policy and Verification
Task List
Overview
Setting up Lists
Configuring Zones
Configuring an Application List
Overview
Since we have users on the Guest network accessing the Internet through the DIA VPN, we might want to lock down what
229
they can/cannot access. Cisco SD-WAN has an in-built Zone Based Firewall which can perform Deep Packet Inspection,
allowing and/or blocking/inspecting traffic as need be. While this is a slightly stripped-down version of a ZBF, it is quite
robust in functionality and offers an intuitive GUI (in the form of vManage) for deploying Firewall Rules.
In this section we will be configuring and deploying a Zone Based Firewall in our network. Guest users will be able to access
most Web content but they won’t be able to access Web based emails (like Gmail). We will see the corresponding activity on
the ZBF in the CLI and on the GUI.
Task List
Overview
Setting up Lists
Configuring Zones

1. On the vManage GUI, go to Configuration => Policies and locate the Site40-Guest-DIA. Click on the three dots next
to it and choose to Activate. Confirm the Activation
230
2. Go back to the console for the Site40-PC and open Terminal. (Start => search for terminal => click on the icon).
Type ping 8.8.8.8 and hit Enter to verify Internet connectivity
*Pings are not allowed through dcloud environment, try “nslookup www.google.com” instead, this should succeed.
231
Setting up Lists
We start off by configuring a few Lists that form the building blocks of our ZBF. The following lists will be created
Zone List for identifying the Guest and Outside zones
Application List for identifying webmail traffic and allowing all other TCP traffic to ports 80 and 443
Configuring Zones
1. On the vManage GUI, go to Configuration => Security
232
2. Click on Custom Options in the top right corner of the screen and click on Lists
233
3. Click on Zones on the left-hand side and choose to create a New Zone List. Give the Zone List Name as Guest and
Add VPN as 30. Click on Add
4. Click on New Zone List again and give the Zone List Name as Outside. Specify the Add VPN as 0. Click on Add
234
5. Make sure that there are two Zone Lists in the configuration and move to the next section of the guide (while staying
on the same page)
Task List
Overview
Setting up Lists
Configuring Zones
235
1. From the previous section, click on Application in the top left corner of the screen after verifying that both the Zone
Lists are visible
2. Once Application is selected, click on New Application List and give the Application List Name of Guest-Inspect.
Choose Webmail from the drop down, making sure all the sub-items under webmail are selected as well
3. Click on Add to add this Application List
236
We have created an Application List which can potentially identify Gmail, Mail.ru etc. traffic. We will now create our policy.
Task List
Overview
Setting up Lists
Configuring Zones

1. On the vManage GUI, navigate to Configuration => Security and click on Add Security Policy
237
2. Choose Guest Access and click on Proceed
238
3. Under Firewall, choose to Add Firewall Policy. Click on Create New
239
4. Click on Apply Zone Pairs
240
5. Set the Source Zone as Guest and the Destination Zone as Outside. Click on Save
6. Ensure that Guest appears under Sources and Outside appears under Destinations. Give the Policy a name of Guest-
FW and a Description of Guest Traffic Firewall. Click on Add Rule
7. Click on Source Data Prefix and choose Guest-Site40 as the IPv4 Prefix List. Click on the Green Save button (be
careful, don’t click on the Blue Save button)
241
8. Click on Application List and select the Guest-Inspect list we created. Click on the Green Save button (again, please
don’t click on the Blue Save button)
242
9. Give the Firewall Rule a name of Drop Web App Guest and set the Action as Inspect. Note that over here no
matter what action we choose, the only one which gets applied whenever an application-based matching is done
is DROP, even though we have selected inspect (Inspect is the only action that can be selected). Click Save
(This time, we click the Blue Save button). Ensure that the Source Data Prefix and the Application List is populated
243
244
10. Click on Add Rule again and select the Source Data Prefix IPv4 Prefix List as Guest-Site40. Click on the Green
Save button
11. Click on Destination Ports and set the Destination Ports as 80 443 (there is a space between the port numbers).
Click on the Green Save button
245
12. Make sure the Firewall Rule looks like the image below and specify a Name of TCP Guest Pass Web. Specify the Action as Inspect.
Click on the Blue Save button.
246
13. Make sure the Firewall Policy looks as below and click on Save Firewall Policy
247
14. Click on Next and then Next again at the URL Filtering and TLS/SSL Decryption sections
248
15. At the Policy Summary page, give a Security Policy Name of Site40-Guest-DIA and a Description of Guest Policy for
Site 40. Under Additional Policy Settings set the TCP SYN Flood Limit to Enabled and 5000. Enable Audit Trail as
well and click on Save Policy
249
This completes the process of creating the Security Policy.
Task List
Overview
Setting up Lists
Configuring Zones
250
1. Go to Configuration => Templates and click on the three dots next to the cEdge_dualuplink_devtemp Device
Template. Choose to Edit it
2. Under the Additional Templates section, populate the Security Policy as Site40-Guest-DIA and click on Update
3. Choose Next and then Configure Devices to push the Security Policy to cEdge40
251
252
4. Open the Console session to the Site 40 PC and navigate to www.facebook.com. It should work indicating that Web
Traffic is allowed. Log in to the cEdge40 CLI via Putty and issue a show log. We should see some activity there.
253
5. Open up a few tabs on the Site 40 PC (2 to 3 of them) and try to access www.gmail.com on all tabs. This should fail
6. On the vManage GUI, navigate to Dashboard => Security and you should see spikes in the Firewall Enforcement
dashlet (continue with the lab and check back after approximately 15 minutes to see this)
254
Thus, our ZBF is working as expected, blocking webmail traffic on the Guest VPN while allowing other traffic on ports 80 and
443.
Task List
Overview
Setting up Lists
Configuring Zones
255
Installing and Configuring the IPS module on cEdges
Summary: Installing an IPS Engine on cEdges and testing signature detection for DIA Guest users
Table of Contents
Overview
Initial Configuration
Add the Security Policy
Updating the Application List and Device

Template
Verifying installation and performing

signature updates
Task List
Overview
Revert Site 40 PC changes and enable DIA
Upload Image to vManage
256
Firewall Policy Update
Add the IPS Policy and Finalize the Security Policy
Updating the Application List and Device Template
Verifying installation and performing signature updates
Overview
An Intrusion Prevention System (IPS) allows the network to detect anomalies based on known signatures and block/report
them. The IPS module in Cisco SD-WAN can be deployed on Cisco IOS-XE SD-WAN Devices, working in Detect or
Prevention mode. This solution is an on-prem on-box feature providing PCI compliance.
Snort is leveraged on Cisco SD-WAN IOS-XEW Devices for IPS and IDS capabilities.
Task List
Overview
257
A Security Policy will be applied to the Device Template for cEdge40 to trigger IPS installation and functionality. We will be
setting up the policy over here, including the previously created Firewall Policy in our overarching Security Policy.

1. On the vManage GUI, navigate to Configuration => Security and choose Add Security Policy. Select Custom and
click on Proceed
258
2. Under Firewall, click on Add Firewall Policy and choose Copy from Existing. We already have a Firewall Policy in
place but the Security Policy type chosen for it was Guest Access, which doesn’t have an option of including an IPS
policy. Hence, we will create a new custom policy which will include the Firewall Policy created before
3. Select Guest-FW as the Policy and specify the Policy Name as Guest-FW_concat. Give a Description of Guest Traffic
Firewall with IPS. Click on Copy
259
4. The Firewall Policy we just copied should show up. Click on Next
Configuration of the Security Policy continues in the next section.
260
Task List
Overview

1. Under the Intrusion Prevention page, click on Add Intrusion Prevention and choose Create New
261
2. Click on Target VPNs and enter a VPN of 30. Click on Save Changes
3. Under the Intrusion Prevention - Policy Rule Configuration, enter the following details and click on Save Intrusion
Prevention Policy
Policy Name Signature Set Inspection Mode Alerts Log Level
Guest-IPS Security Protection Info
262
4. Back at the main Security Policy page, click on Next 5 times
263
5. Enter the details as shown in the table below and click on Save Policy
Security Policy Name Security Policy Description TCP SYN Flood Limit Audit Trail
Guest-FW-IPS-DIA Guest Firewall and IPS DIA Enabled On

5000
This completes the configuration of our Security Policy.
264
Task List
Overview

The Application List attached to the Firewall Policy that we had earlier will need to be instantiated again before we can use
it. For that, we will make a dummy modification to the Application List
1. On the vManage GUI, go to Configuration => Security. Click on Custom Lists (top right-hand corner) and choose
Lists
265
2. Identify the Guest-Inspect Application List and click on the pencil icon on the right-hand side to edit it. Under Select
Application, check X Font Server (or any application that you want, this is a dummy entry)
3. Scroll down the list and uncheck Webmail, but check all the other Applications under Webmail
266
4. Click outside the box and choose to Save the Application List. Click on Activate, if prompted. Click on Next followed
by Configure Devices
267
5. Go to Configuration => Templates and click on the three dots next to cedge_dualuplink_devtemp. Click on Edit
6. Navigate to the Additional Templates section and populate the Security Policy field with the policy we just created -
Guest-FW-IPS-DIA. Click on Update
268
7. Click on Next and you can choose to view the side by side configuration. Click on Configure Devices. If you do
choose to view the configuration, notice the UTD related commands being pushed by vManage - they are for the IPS
module
8. The status of this change will show up as Done - Scheduled. This is expected since the IPS engine has to be
installed on the cEdge
9. Navigate to Configuration => Devices and locate the cEdge40 Device. You will notice that the Device Status is
Service Install Pending (might have to scroll to the right or remove columns to see this)
269
Since it takes approximately 5 minutes for the install process to go through, this will be a perfect time to grab a cup of
tea/coffee! We will validate the installation in the next section.
Task List
Overview
270
1. After you’re done with the cup of tea/coffee, check the Configuration => Devices page again. cEdge40 should now
be In Sync
2. Log in to CLI of cEdge40 via Console and enter the show utd engine standard status command. The Overall
system status should be Green and the Engine should be Running. If the Signature is version 29.0.c, proceed to the
next step else skip to Activity Verification
271
3. You should see file utd signature update file “UTD-STD-SIGNATURE- 29130-115-S.pkg” in flash of cedge40.
Run the command bootflash:UTD-STD-SIGNATURE-29130-115-S.pkg
Confirm the signature update
4. Run show utd engine standard status to check if the signature package version matches with the image below
272
Task List
Overview
273
1. Log in to console of Site40-PC in to your Site 40 PC again, like before.
Open Terminal typeping 8.8.8.8 to verify that Internet connectivity is still there {ICMP might be blocked by dcloud FW.}
2. Still in Terminal, run sudo apt update & sudo apt upgrade. Wait for them to complete and then run sudo apt install curl.
Once installed, type ./ips.sh to trigger a few HTTP connections which will trigger the IPS.
(If ./ips.sh is not executable, then type chmod 755 ips.sh or chmod a+x ./ips.sh)
3. Back at the cEdge40 CLI, issue show utd engine standard logging events . You should see alerts triggered as
a result of running the ips.sh file (this file attempts to download some simulated malware). Thus, our IPS engine is
working as expected
274
4. We can view this information on the vManage GUI as well. Go to Dashboard => Security and you should see some
Signature hits. The dashboard does take some time to get populated (it’s never too soon for another cup of
tea/coffee!)
275
This completes the verification activity.
Task List
Overview
276
Configuring URL Filtering
Summary: Configuring URL Filtering for DIA Guest Users
Table of Contents
Updating the Security Policy
Verification
Task List

Verification

URL Filtering allows networks to block traffic to certain sites by utilizing URL-based policies. It is implemented using the
Snort Engine.
1. On the vManage GUI, navigate to Configuration => Security. Locate the Guest-FW-IPS-DIA policy and click on the
three dots next to it. Choose to Edit the policy. We will add URL Filtering capabilities to the same policy which we
used for IPS deployment
277
2. Click on the URL Filtering tab and then click on Add URL Filtering Policy. Choose Create New
3. Click on Target VPNs and enter a Target VPN of 30. Click on Save Changes
278
4. Enter URLF-NoShopping for the Policy Name. Set the Web Categories to Block and add auctions and shopping to
the categories. Set the Web Reputation to High Risk
5. Specify This is not allowed! in the Content Body and make sure all the Alerts are selected. Click on Save URL
Filtering Policy
279
6. Make sure the URLF-NoShopping URL Filtering policy shows up and click on Save Policy Changes
280
7. Click on Next and choose to Configure Devices. You can check the side by side configuration if needed, making
note of the web-filter and block page-profile configuration being pushed by vManage. This is our URL-F
configuration
281
Task List

Verification
Verification
Wait for a few minutes before going through the verification steps enumerated below.
1. Log in to the Site40-PC, by Right Clicking on the Site40-PC and click on Console. Username and Password will be
viptela/viptela. Open an Incognito window in Chrome or a Private Browsing tab in Mozilla Firefox. Try to access
http://www.ebay.com. The page should get blocked, giving the message we had customized. If amazon.com is
accessed, we will get an SSL warning, however the CLI "show utd engine standard logging events" will show
amazon.com being blocked with a category tag of shopping:
282
283
2. Log in to the CLI for cEdge40 via console and issue show utd engine standard logging events . This will
show us amazon.com being blocked with a category of shopping attached to it
284
URL Filtering is working as expected in our lab environment.
Task List

Verification
285
Configuring AMP and TLS/SSL Proxy
Overview
Starting with IOS-XE 17.2.1r, the cEdges can function as transparent TLS/SSL Proxy devices. Encrypted traffic can be decrypted by the cEdge which is then analyzed by the
Unified Threat Defense (UTD) engine to identify risks hidden in encrypted traffic. Some of the benefits of a TLS Proxy are
• Transparent inspection of encrypted traffic for threats

• Threat and Malware protection for TLS traffic
• Security Policy enforcement on decrypted traffic
TLS proxy devices act as a man-in-the-middle (MitM) to decrypt encrypted TLS traffic traveling across the WAN, and send it to UTD for inspection. TLS Proxy thus allows
devices to identify risks that are hidden by end-to-end encryption over TLS channels. The data is re-encrypted post inspection before being sent to its final destination.
Pre-Work and Testing

We will first perform some initial testing without AMP and TLS/SSL Proxy functionality enabled.
1. Console in to the Site40-pcwin at Site 40 and click on Start. Search for Windows Security and click on the Windows Security icon
286
2. Search for Windows Defender on Windows Machine.
3. Select Tools > Options .
287
4. Select Real-Time Protection and uncheck real time protection. Hit Save.
288
5. Open Google Chrome and navigate to eicar.org/?page_id=3950. Scroll down and click on the eicar_com.zip HTTPS download link. This will initiate a
download of a sample malware file
289
6. The download will go through and we should see the eicar_com.zip sample malware file in the Downloads folder. Delete the file (press Shift + Delete
after clicking on the file to permanently delete it) since we will be performing this test multiple times
290
We thus saw that a known malware file was downloaded via HTTPS since:
• There is no malware protection mechanism in place
• The traffic is encrypted
291
SSL/TLS Proxy configuration requires a few pre-requisites to be in place. These are:

• TLS Proxy devices and the clients should have their times in sync
• A device will need to be set up as a CA. There are a few options: Enterprise CA, Enterprise CA with SCEP enabled, vManage as CA and vManage
as an Intermediate CA
• Traffic flows must be symmetric and pinned to a particular link, if there are multiple links
We will be setting up the vManage as the CA, along with configuring NTP and DNS for our network.
Configuring NTP and DNS

1. Log in to the vManage GUI. Navigate to Configuration => Templates and head over to the Feature tab. Click on Add Template
2. Search for csr and select the CSR1000v device. Click on Cisco NTP to create an NTP Feature Template for the cEdges
292
3. Populate the name and description per the table given below and click on New Server. Enter the details as per the table, screenshot given for reference.
Click on Add once all the server details have been populated and then click on Save to save the template
293
294
4. Enable Master, Enter the Stratum as 1 and hit save.
5. At the Feature Templates tab, locate the cEdge_VPN0_dual_uplink template and click on the three dots next to it. Choose to Edit the template
6. Populate the Primary DNS Address and Secondary DNS Address as 8.8.8.8 and 4.2.2.2 respectively. Click on Update
7. Click on Next and Configure Devices. You can choose to view the side by side configuration if needed
8. Go to Configuration => Templates and locate the cedge_dualuplink_devtemp Device Template. Click on the three dots next to it and choose
to Edit the template
295
9. Click on Cisco NTP to add an NTP Feature Template and populate the cedge40-ntp template we created. Click
on Update
10. Click on Next and Configure Devices

11. Once the configuration is pushed successfully, log in via Console to cEdge40 and issue a show ntp assoc to
verify DNS resolution of the NTP server and a state of sys.peer
296
12. Log in to the CLI of vManage via the console using the username and password given below. Enter the
commands enumerated here to update the DNS and NTP servers.
297
13. Run show ntp assoc after a few seconds to verify that the vManage is now sync’d .
298
Setting up vManage as the CA
We will now set up vManage as the CA and install the certificate on our client PC at Site 40.
1. Log in to the Windows PC at Site40pcwin and open Google Chrome. Navigate to https://100.100.100.2:8444 and log in to vManage, after accepting any
certificate errors
299
2. Go to Configuration => TLS/SSL Proxy
3. Select vManage as CA and enter the details as per the following table. Click on Save Certificate Authority
300
Field Value
Common Name tlsproxy
Organization swat-sdwanlab
Organizational Unit Cisco
Locality SJ
State/Province CA
Country Code US
Email [email protected]
Validity Period 10 years
301
4. Click on Download and download the root certificate, which we will be installing on the Site 40pcwin itself
302
5. Click on Start on the Site 40pcwin and search for mmc.exe.
303
6. Click File > Add/Remove Snap-in
7. Click on Certificates > Add > Click Ok

304
8. Click Computer Account and click Next
305
9. Click Local Computer and click Finish
306
10. Click OK
307
11. Click Trusted Root Certification Authority > Certificates > All Tasks > Import
12. Click Next
308
13. Click on Browse and set the File Type to All Files. Select Downloads and click on
the tlsproxy_vmanage.pem file we downloaded and click on Open
309
14. Click on Next and ensure that the certificate store is set to Trusted Root Certification
Authorities. Click on Next
310
15. Click on Finish and then OK once the import is successful
311
Enabling AMP and Testing
Advanced Malware Protection will be enabled in this section and we will try to download a sample malware file via HTTPS. Since the TLS/SSL Proxy
isn’t configured yet, we expect the file to be downloaded despite AMP being enabled. This is due to the fact that traffic is encrypted and AMP cannot
analyze encrypted communication.
1. Navigate to Configuration => Security on the vManage GUI and locate the Guest-FW-IPS-DIA policy. Click on the three dots next to it and
choose to Edit
2. Click on the Advanced Malware Protection tab and then on Add Advanced Malware Protection Policy.
312
Choose Create New
3. Enter the details enumerated in the table below and click on Save Advanced Malware Protection Policy. When
313
the Custom VPN Configuration radio button is selected, you will get a help walkthrough which will instruct you how
to specify custom VPNs. Click on Got It and then click on Target VPNs. Enter 30 as the Target VPN
Field Value
Policy Name amp-policy
VPN Custom VPN Configuration
Target VPN 30
AMP Cloud Region NAM
Alerts Log Level Info
File Analysis Disabled
4. Click on Next and then Configure Devices. You can choose to view the side by side configuration, if required
314
5. Go back to the Site40PCwin via the console. Open Google Chrome and use the Malware Test bookmark or
navigate to eicar.org/?page_id=3950. Download the eicar_com.zip sample malware file and you will notice that the
file gets downloaded successfully
We have enabled AMP in our SD-WAN environment and tested that HTTPS communication isn’t analyzed / blocked
by AMP due to its encrypted nature, despite downloading a known malware file.
315
Configuring the Decryption Policy
We will now configure cEdge40 as the TLS/SSL Proxy device.

1. Navigate to Configuration => Security and locate the Guest-FW-IPS-DIA policy. Click on the three dots next to it and choose to Edit the policy.
Click on the TLS/SSL Decryption tab and click on Add TLS/SSL Decryption Policy
2. Make sure that the vManage shows up as the CA and click on Enable SSL Decryption
316
3. Give the policy a name of vpn30-tls-decrypt and create a Network Rule by clicking on Add Rule
4. Set the name of the rule to decrypt-all-vpn30 and choose Decrypt for the Action. Click on Source VPN and set the
317
Source VPN to 30. Click on Save and then Save again in order to save this rule
318
5. Make sure that the policy has a Decrypt rule added and click on Save TLS/SSL Decryption Policy
319
6. At the main policy page, click on Save Policy Changes and then choose Next and Configure Devices. You can
view the side by side configuration if needed
320
1. Once the changes have been pushed successfully, log in to the CLI of cEdge40 via Console. Issue clear utd engine standard logging events and
then show sslproxy status. The SSL and TCP Proxy Operational State should be RUNNING and Clear Mode should be set to False
Username Password
admin admin
321
2. There should be some traffic being generated from Site40. Issue show sslproxy statistics and make note of
some connections being proxied. Run show utd engine standard logging events - there might be some events
logged, depending on what’s open on the Site 40 clients
322
3. Run clear utd engine standard logging events and then show utd engine standard logging events. We shouldn’t
see too much activity here, but some events will be logged automatically over time (like the dns.google events seen
before)
4. Open Google Chrome on the Site40PCWin VM (or navigate to eicar.com in a browser)
323
5. Wait for a few seconds (might need to refresh for the site to load) and issue show utd engine standard logging
events in the cEdge40 CLI. You should see some traffic now being analysed by AMP, being flagged with Unknown
Disposition. This traffic will be allowed
324
6. On Chrome at the Site40PCWin, click on the Malware Test bookmark or navigate to eicar.org/?page_id=3950 and
click on the eicar_com.zip hyperlink to download the file
7. You will notice that the file download is now blocked
325
8. From the CLI of cEdge40, issue show utd engine standard logging events and we will see the file download being
blocked
We have thus configured cEdge40 as a TLS/SSL Proxy device that is decrypting encrypted traffic, acting as a man-
in-the-middle.
Note: If you have done all steps correctly and still able to download the ecar_com.zip file, that means TLS proxy is not working due time synchronization
issue between vManage and site40pcwin. Time on vManage and site40pcwin should be same in order for TLS to work properly.
From the pod, right click on vManage and log into it’s console. Type show clock to see the time on vManage. Then compare it with time on site40pcwin.
If there is a time difference, change the time on site40pcwin to same as you see on vManage.
Once time on site40pcwin is set to same, then try to download the file. TLS proxy will work and you would not be able to download the file.
326
Integrating Cisco SD-WAN and Umbrella
Table of Contents
Overview
Pre-Work for Site 40
Enabling DIA for Site 40 VPN 30
Life without Cisco Umbrella
Basic Configuration for Umbrella
Making Umbrella Ours
API Keys and AD Configuration
Building a DNS Policy
Enabling DIA for Site 30
Setting up IPSEC Tunnels
Configuring a Firewall Policy
Summary: Cisco SD-WAN Security with Umbrella integration.
Overview
Cisco Umbrella offers flexible, cloud-delivered security when and how you need it. It combines multiple security functions into one solution, so you
can extend protection to devices, remote users, and distributed locations anywhere. Umbrella is the easiest way to effectively protect your users
everywhere in minutes.
327
In this section, we will deploy DNS Layer Security as an Umbrella feature on cEdge40. Then we will deploy IPSEC tunnels to Umbrella on vEdge30
and check Firewall and Web functionalities.
• DNS Layer Security (cEdge40)

• Cloud-delivered Firewall (IPSEC Tunnel) (vEdge30)
• Secure Web Gateway (IPSEC Tunnel) (vEdge30)
Task List
Overview
Configuring a Web Policy
We will need to deactivate the Centralized DIA policy for cEdge40 and update few settings with respect to DNS servers to ensure that Umbrella infrastructure is utilized by
the SD-WAN solution.
328
1. On the vManage GUI, go to Configurations => Policies. Search for Site40-Guest-DIA and deactivate the policy.
2. On the vManage GUI, go to Configuration => Templates => Feature. Search for cEdge_VPN0_dual_uplink template. Click on three dots and choose Edit.
329
3. In the DNS section, add the primary and secondary DNS values as 8.8.8.8 and 4.2.2.2 respectively as shown below. Click on Update.
4. Click Next => Configured Devices to save the configs on cEdge40.
330
331
Enabling DIA For Site 40 VPN 30
To facilitate communication to the Internet from Site 40, we will be enabling DIA at Site 40 for VPN 30.
1. On the vManage GUI, goto Configuration > Templates > Feature and search for cedge40-vpn30 template, click on three dots and click view.
332
2. The template with name of cedge40-vpn30 template is preconfigured with the following settings:
a. Primary and Secondary DNS Global values as 8.8.8.8 and 4.2.2.2
333
b. NAT DIA route for internet reachability
Next, we will attach this feature template to device template associated with cedge40.
334
3. Now we need to attach this new cedge40-vpn30 feature template to cEdge40 device template. Go to Configurations => Template => Device. Search for
cedge_dualuplink_devtemp and click on Edit
4. Go to Service VPN section. Check the button next to cedge-vpn30 and then click on Remove VPN. Click on Remove to confirm the process
335
5. Click on Add VPN. Choose cedge40-vpn30 and move it to right side. Click on Next
336
6. Click on Cisco VPN Interface Ethernet and choose cedge-vpn30-int interface template from drop down list. Click on Add
337
7. Click on Update => Next => Configured Devices to save the template on cEdge40
338
339
340
8. Now from your pod, right click on cEdge40 and log into the console. Make sure VPN 30 can reach the internet. Run a test, ping vrf 30 8.8.8.8
341
Life without Umbrella
As of now, Site 40 Windows PC has connectivity to the internet and is pointing to DNS servers 8.8.8.8 and 4.2.2.2. We will run a quick check from site40pcwin to
verify that we are not connected to Cisco Umbrella.
1. Access site40pc from the pod. Right click on site40pcwin and click on Console
2. Open Google Chrome and go to welcome.umbrella.com. The Umbrella page should display the image shown below. This is an indication that our
network isn’t protected by Umbrella (yet).
342
3. Access websites like www.amazon.com and www.ebay.com by typing them out in the browser. All the sites should be accessible since we don’t have any sort of access
control/filtering enabled as of now
343
344
4. Access internetbadguys.com by typing it out in the browser. This is a website that simulates a phishing attack. Since we aren’t protected, the website pops right up.
345
Life without Umbrella doesn’t look too good since we are open to the simplest of phishing attacks. We will be incorporating a fundamental layer of protection in our
network followed by a more elaborated DNS Policy.
346
Configuring WAN Edge Umbrella Redirection
In this section we will ensure that cEdge40 intercepts DNS queries and send them to Umbrella.
1. Access wkst1 from the dCloud screen and by clicking View on the right side. Log in to the Umbrella portal from your wkst1 by clicking on the Umbrella login shortcut on
the desktop and you should be logged in automatically.
347
2. Click on Admin in the left navigation bar and then on API Keys. Click Umbrella Network Devices and then click on Generate Token.
348
349
3. Open Notepad and copy-paste the Organization ID, Key and Secret. The Organization ID can be found in the URL (5584919 in this sample screenshot)
350
4. Now click Legacy Network Devices to expand the section. If you see a token then click Refresh. Copy-paste the token to Notepad. If the API Key for Legacy Network
Devices doesn’t exist, click on Generate.
351
5. Log in to vManage and navigate to Configuration => Security
352
6. Click on Custom Options in the top right corner and choose Umbrella Registration
353
7. Copy-paste the Organization ID, Umbrella Network Devices Key, Umbrella Network Devices Secret and Legacy Network Devices Token in the corresponding
fields. Click on Save Changes
354
8. Go to Configuration => Security and choose to Add Security Policy. Click on Custom and choose Proceed
355
9. Click Next till you’re at the DNS Security tab and click on Add DNS Security Policy. Click on Create New
356
10. Enter the Policy Name as dns-umbrella and select the Custom VPN Configuration radio button. Click Got It and then click on Target VPNs and enter the VPN as 30.
Click on Save Changes.
357
11. Make sure the DNS Policy has the Umbrella Registration Status as Configured and click on Save DNS Security Policy. Also ensure that VPN 30 is listed in the
configuration
358
12. Back at the main Security Policy, click Next till you’re at the Policy Summary page and give the Policy a name of cedge40-dns-sec with a Description of DNS Security
Policy for cEdge40. Click on Save Policy Changes.
359
13. We need to attach this DNS policy to cedge40 device template. Navigate to Configuration => Templates and locate the device template cedge_dualuplink_devtemp.
Click on the three dots next to it and choose to Edit the Template
360
14. Scroll down to the Additional Templates section, remove the Security Policy Site40-Guest-DIA which was used in ZBF task and add cEdge40-dns-sec as shown
below. Click on Update
361
15. Click on Next and then Configure Devices. You can view the side by side configuration if needed.
16. At this point, cEdge40 will register to the Umbrella portal as a Network Device. Log in to the Umbrella portal from wkst1 and go to Deployments => Network Devices.
You should see a device showing up over there, with the Device Name cEdge40 vpn30. The Status should be Active
362
17. Log in to CLI of cEdge40 via console. Run the command show umbrella device-registration. If you see a status as created and a valid device ID, that means device is
successfully registered with Umbrella, receiving a response code 201.
363
18. Access the site40pcwin from console. Open the command prompt. Run the command ipconfig /flushdns. Open Chrome and access internetbadguys.com. The site
should not load.
364
19. On the Umbrella portal on wkst1, navigate to the Overview page and scroll down. We should see a spike in Total Blocks and Security Blocks (takes 5 minutes to reflect)
20. Mouse over the latest spike and you should see the timestamp of it. Click on the spike to see details of it. Click on the three dots next to any of the blocks and choose
View Full Details
365
We thus see that although the Site40pc Client has got a DNS server pointing to 8.8.8.8 and 4.2.2.2, cEdge40 intercepts the DNS Query and redirects it to Umbrella,
potentially enforcing any Umbrella DNS Policies for that Organization.

To apply custom DNS policies, we will need to ensure that our setup can be uniquely identified by Umbrella, post which DNS Policies can be set up for the organization.
Umbrella can be used to identify traffic coming from a public IP/IP Range. This helps with creating custom policies for a particular organization. In our lab, multiple
devices will be talking to the outside world via the same Public IP, hence this approach will not work for us.
366
Instead, we can get extremely granular and apply a policy to a specific user/group of users based on identities used to uniquely identify them. We can also pinpoint
individual workstations by leveraging Cisco AnyConnect, thereby encompassing Roaming Computers in our DNS policies.
Three pieces of the puzzle that uniquely identify our Enterprise Network on Umbrella are given below:
Organization (this is a numeric string, allocated by Umbrella. Not to be confused with the SD-WAN organization name)
API Key
Secret
1. From your wkst1, click on the Umbrella shortcut and you will be logged in automatically.
Username Password
367
2. Once logged in, the URL will contain your Organization ID. It will vary per POD. Copy it in a notepad file on the jump host since we will be needing it later.
3. API Keys and the Secret needs to be generated on Umbrella. Navigate to Admin => API Keys. If the sidebar isn’t visible, click on the menu icon (three horizontal
lines) next to the Cisco Logo
368
4. Click on drop down arrow for Umbrella Management and click on Generate Token. This will generate the keys. Copy and paste the Organization ID, Key and Secret
to notepad.
369
370
371
Tip: If the key needs to be re-generated (usually required if the secret is misplaced), the Refresh button will allow you to generate a new API
Key and Secret.
372
Task List
Overview
Pre-Work For Site 40
1. From wkst1, navigate to Policies => Policy Components => Destination Lists on the Umbrella portal. You will notice a few default Lists already created
373
2. Click on Add in the top right-hand corner and give your List a name of BlockAmazon. Leave the This destination list is applied to field at DNS Policies
374
3. Scroll down to the Destinations in this list should be field and make sure it is set to Blocked. Type amazon.com in the Enter a domain or URL box and hit Enter (or
click on Add). This should place amazon.com in the list (blocked). Click on Save
375
4. Navigate to Policies => Management => DNS Policies and click on Add to add a new DNS Policy
12. Scroll down on the How would you like to be protected? page and click on Next without making any changes
13. On the What would you like to protect? page, click on Network Devices. Don’t click on the checkbox next to it, but on the actual phrase itself
376
..
5. Put a check mark next to cedge40 and it should show up in the right-hand window. Click on Next
377
6. Click Next in the Security Settings
378
7. Select Moderate on the Limited Content Access page and make note of the categories that are being blocked. Click on Next
379
8. Search for ebay in the Search Box on the Control Applications page under Applications to Control and put a check mark next to eBay. Make sure it is set to Block
and click on Next. Click on Proceed on the Application Control page
380
9. Put a check mark next o BlockAmazon on the Apply Destination Lists page. This will apply the List we created before to the policy being built right now. You should
see BlockAmazon on the right hand-side under 2 Block Lists. Applied. Click on Next
381
10. Click on Next on the File Analysis and Set Block Page Settings pages without making any changes
382
11. Once on the Policy Summary page, give your Policy a Name of DNSPolicy1. Click on Save
12. Our DNS Policy is now created. It might take 5 minutes for the policy to be applied. Click on the DNSPolicy1 policy and enable SSL Decryption. Scroll down and click on
Save
383
13. We are now going to test our DNS Policy, but before doing so, the Cisco Umbrella root certificate will need to be downloaded and installed on the site40pcwin. Double
click the Flush DNS icon on the Desktop or run ipconfig /flushdns from command prompt to clear the DNS cache
384
14. Log in to the Umbrella portal from your site40pcwin by navigating to login.umbrella.com in a browser. Enter credentials of [email protected]/C1sco@12345
and click on Log In. Navigate to Deployment => Root Certificate and download the Root Certificate on the Site 40 PC.
385
15. Expand Cisco Root Certificate Authority and download the root CA certificate
16. Click on Keep, if prompted and open the downloaded file. Choose Open in the Security Warning
17. Click on Install Certificate

386
18. Select Local Machine and click on Next
387
19. Choose the radio button next to Place all certificates in the following store and click on Browse. Click on Trusted Root Certification Authorities and hit OK
388
389
20. Click on Finish and then OK. If you see a security waring, click Yes to successfully install the certificate.
390
21. On the browser, go to yahoo.com. The page should open since we haven’t applied any policy for it.
391
21. Now try going to amazon.com. We will find that it is blocked with the text The site is blocked indicating this has been done by the administrator via a Block List. Amazon
was opening before, but our company policy doesn’t allow it and we have thus leveraged Cisco Umbrella’s DNS Policy functionality to block specific destinations
392
22. Try to browse to ebay.com. This will also be blocked but the text will read This site is blocked due to content filtering. This is because we blocked eBay in the Control
Applications section of our policy
393
23. Try to go to poker.com. This will also be blocked (with the same text as the previous step). Over here, our Limited Content Access level of Moderate is coming in to
play. Note the subtext mentioning This site was blocked due to the following categories: Gambling
394
This completes the DNS Security part of our configuration. We have successfully deployed a DNS Policy, blocking sites that are not allowed by our company policy.
395
Task List
Overview

So far, we have run through DNS policy which is the first layer of security in the network. For deeper packet inspection, we
can utilize Umbrella and SD-WAN’s SIG functionality which will create IPSEC tunnels between our vEdges/cEdges and
Cisco Umbrella. For this, we will use site 30. Traffic will be sent to Umbrella over the IPSEC tunnels and will be subject to
Firewall and Web policies. For that, first we need to enable DIA for site 30
1. Connect to the Site30PC and console to the PC and assign the following IP configuration on the active Network
Adapter 10.30.10.21, SM: 255.255.255.0, DG: 10.30.10.2, DNS: 8.8.8.8, 4.2.2.2
396
397
2. Click on Start and type cmd. Click on the Command Prompt App that pops up in the search results
398
3. Type ipconfig and Hit Enter. Also, type ping 10.0.0.1 and Hit Enter. The pings should work. On typing ping
8.8.8.8 , the pings should fail indicating that there is no Internet connectivity.( Please Enter the Address to Machine Manually , if not present)
399
4. Go to the vManage GUI and navigate to Configuration => Templates
400
5. Click on the Feature tab and locate the vEdge30-vpn0 Feature Template. Click on the three dots next to it and choose
to Edit
401
6. Scroll to the DNS section and update the Primary DNS Address (IPv4) to 8.8.8.8 and the Secondary DNS Address
(IPv4) to 4.2.2.2
7. Locate the IPv4 Route section and click on the pencil icon to edit the 0.0.0.0/0 route
402
8. Click on 2 Next Hop and remove the vpn0_mpls_next_hop option by clicking on the red minus icon
9. Click on Save Changes
403
10. Ensure that the Update IPv4 Route window shows 1 Next Hop and click on Save Changes
11. Click on New IPv4 Route and enter a Prefix of 192.0.2.0/24. Click on Add Next Hop
404
12. Click on Add Next Hop again
13. Enter a Global value of 192.0.2.13 in the Address field and click on Add
405
14. Click on Add again to add the route
15. We will be adding 2 more routes. Repeat steps 12 to 15 for the routes enumerated below, using the images as
reference. These routes and the ones in the previous steps are being added to maintain BFD sessions on the MPLS
link in our SD-WAN network and to ensure that the TLOC extension configured before works as expected (hence the
192.168.26.0/24 route shown below). The 192.0.2.0/24 and 192.1.2.0/24 routes being added correspond to our MPLS
subnets across the SD-WAN Network
406
Prefix Global 192.1.2.0/24
Add Next Hop - Address Global 192.0.2.13
Prefix Global 192.168.26.0/24
Add Next Hop - Address Global 192.0.2.13
407
16. Make sure there are 4 routes created, as shown below and click on Update
17. Click on Next and then Configure Devices. You can view the side by side configuration difference, if required. Notice
that the default route pointing to the MPLS next hop is being removed and 3 routes are being added in place of it
408
18. Navigate to the Configuration => Templates => Feature tab and click on the three dots next to vedge30_MPLS.
Click on Edit
19. Under Tunnel, set the Control Connection to Off and click on Update. Click on Next and then Configure Devices
409
20. Back at the Configuration => Templates => Feature tab, locate the vEdge30_INET Feature Template. Click on the
three dots next to it and choose to Edit. Set NAT to a Global value of On and click on Update. Click Next and
Configure Devices on the corresponding screens, viewing the side-by-side configuration difference if required
410
21. We will now add a VPN 10 Template for vEdge30 since there will be settings applicable just to this Site for Umbrella
connectivity. On Configuration => Templates => Feature tab locate the vedge-vpn10 Template. Click on the three
dots next to it and choose Copy
22. Rename the Template to vedge30-vpn10 and update the description accordingly. Click on Copy
411
23. Click on the three dots next to the newly copied template and choose to Edit
24. Update the DNS entries to 8.8.8.8 for the Primary DNS Address (IPv4) and 4.2.2.2 for the Secondary DNS
Address (IPv4). Click on Update.
412
25. On the vManage GUI, navigate to Configuration => Templates => Device Tab and locate the vEdge30_dev_temp
Template. Click on the three dots next to it and choose to Edit the template
26. In the Service VPN section, select the vedge-vpn10 Template Name entry and click on Remove VPN. Confirm the
removal
413
27. Click on Add VPN under Service VPN and move the vedge30-vpn10 Template to the right-hand side. Click on Next
28. Under Additional VPN Templates click on VPN Interface and select vedge-vpn10-int in the VPN Interface drop-
down. Click on Add
414
29. Back at the Device Template, click on Update followed by Next and Configure Devices
This completes the pre-work that we needed to do at Site 30.

415
Enabling Site 30 for DIA
To facilitate communication to the Internet from Site 30, we will be enabling DIA at Site 30 for VPN 10.
1. On the vManage GUI, edit the vedge30-vpn10 template with a VPN route to 0.0.0.0/0 VPN 0 and ensure the vEdge30-INET template for vEdge30 is enabled for NAT.
2. Go to IPv4 Route section and add route 0.0.0.0/0, choose gateway as VPN, enable VPN as Global value of On. Click on Add, Save Changes, Update and
Configured Devices to save the changes.
416
417
3. Go to the Site 30 PC open Command Prompt (Start => type Command Prompt). Type ping 8.8.8.8 and hit Enter. Pings should work. To
verify DNS resolution, type ping www.cisco.com and hit Enter
418
We have enabled DIA at Site 30 for VPN 10. We will now proceed with setting up Tunnels to Umbrella.
1. Open a browser and log in to Cisco Umbrella from your host. The main overview page will show that we no Active Network
Tunnels
419
2. Log in to the vManage GUI with the Username and Password given below. Navigate to Configuration => Templates
=> Feature Tab and click Add Template. Search for vedge and select the vEdge Cloud device. Click on SIG
Credentials under Other Templates
Username Password
admin admin
420
3. Put the Template Name as SIG-Creds and a Description of SIG Credentials. Enter the Organization ID, Registration
Key (i.e., API Key) and Secret copied and saved to notepad before. Click on Save
4. Back at the Templates page, make sure you’re still on the Feature Tab and click on Add Template. Search for vedge
and select vEdge Cloud. Click on Secure Internet Gateway (SIG) under VPN
421
5. Give it a Template Name of SIG-Template and a Description of SIG Template
422
6. Click on Add Tunnel and enter the details given in the table below. Click on Add once done
Parameter Global or Device Specific (Drop Down) Value
Interface Name (1 - 255) Global ipsec1
Source Interface Global ge0/0
Data-Center NA Primary
7. Click on Add Tunnel again to add a second IPSEC Tunnel. Enter the details given below and click on Add
Parameter Global or Device Specific (Drop Down) Value
Interface Name (1 - 255) Global ipsec2
Source Interface Global ge0/0
Data-Center NA Secondary
423
8. Populate ipsec1 under Active and ipsec2 under Backup. Click on Save
9. Log in to vEdge30 via the console. Enter ping global-a.vpn.sig.umbrella.com. Pings should be successful.
Press Ctrl + c to stop the pings
424
Username Password
admin admin
10. Back on the vManage GUI, navigate to Configuration => Templates. Under the Device tab, locate the
vedge30_dev_temp template and click on the three dots next to it. Choose to Edit the template
11. Go to the Transport & Management VPN section click on Secure Internet Gateway under Additional VPN 0
425
Templates. Select the SIG-Template from the drop down
12. Scroll down to the Additional Templates section and populate SIG-Creds for the SIG Credentials. Click on Update
13. Click on Next. You can view the side by side configuration if required. Make note of the secure-internet-gateway and
426
ha-pairs configuration
14. If you scroll down, interface ipsec1 and interface ipsec2 configuration can be viewed. Click on Configure Devices
show ipsec ike

15. Wait for a couple of minutes and log in to the Console session for vedge30. Issue the command
sessions . You will see 2 sessions which should be in a state of IKE_UP_IPSEC_UP. If the sessions are in any other
427
state, wait for a couple more minutes and issue the same command again
16. Log in to the Umbrella GUI from wkst1. On the main overview page, you should see Active Network Tunnels 2/2 Active
428
This is an indication that our IPSEC Tunnels to Umbrella are up.
17. Head over to Site 30 PC and open a web browser. Go to http://portquiz.net:444. The page should load correctly
429
18. Head back over to the vManage GUI and go to Configuration => Templates => Feature Tab. Locate the vedge30-
vpn10 template and click on the three dots next to it. Choose to Edit the template
430
19. Scroll down to the Service Route section and click on New Service Route. Enter a global Prefix for 0.0.0.0/0 and
click on Add. Click on Update followed by Next and Configure Devices
This will ensure that all the traffic hitting VPN 10 on vEdge30 is punted over the newly established IPSEC Tunnels to
Umbrella.
20. From wkst1, access the Umbrella GUI, click on Active Network Tunnels and you will see the naming convention
automatically populated for our 2 Tunnels. Both tunnels should be in an Active state (if the status is unknown, wait
for some time and revisit this page)
431
Tip: The naming convention can be broken down as the Site ID, followed by the word SYS (for System IP) and
then the System IP of the device in question with the dots replaced by x. The last few characters reference the
Interface (IF) followed by the Interface Name (ipsec1 and ipsec2 in our case).
We have completed IPSEC Tunnel configuration for our vEdge30 device. Through the Service Route, we have ensured that
all traffic is punted over the Tunnels to Umbrella (this is not in effect yet, more changes will be made to force traffic over the
Tunnels).
Task List
Overview
432

1. Log into Cisco Umbrella from wkst1 and click on the Umbrella shortcut which will log you in automatically.
Navigate to Policies => Management => Firewall Policy and click on Add in the top right-hand corner
2. Enter the rule name as block444. We will be blocking TCP traffic to port 444 via this Firewall Policy
433
3. Scroll down and set the Protocol to TCP. Set the Destination Ports to Specify Port and enter the port number 444
434
4. Set the Rule Action to Block Traffic and Enable Logging
5. Under Rule Schedule set the Start Date to the earliest available and make sure Does Not Expire is checked. Click
on Save
435
6. The Firewall Policy of block444 should show up above the Default Rule
7. Go to http://portquiz.net:444. The site will not load
436
8. Try to access http://portquiz.net:450 and the site should load right up, indicating that TCP connections to port 444 are
being blocked (in line with our Firewall Policy)
9. Other than using the Cloud Delivered Firewall to block specific ports, we can also block ICMP packets. Open a
command prompt on the Site 30 PC and type ping cisco.com . Hit Enter. The pings should be successful
437
10. Go to the Umbrella GUI and navigate to Policies => Management => Firewall Policy. Click on Add to add a new
policy and name it blockicmp
11. Set the Protocol as ICMP
438
12. Make sure the Start Date is the earliest available and the Rule Action is set to block traffic, with logging enabled.
Click on Save to save the firewall policy
13. Wait for approximately 5 minutes and try to ping cisco.com from the Site 30 PC again. Pings should now be blocked
439
We have thus used a Firewall Policy to block traffic to a particular destination port and block a certain protocol. This
completes our configuration of a Cloud Delivered Firewall.
Task List
Overview

We will now apply a Web Policy to all traffic traversing the IPSEC Tunnels.
1. From wkst1, click on the Umbrella shortcut which should log you in automatically. Navigate to Policies => Policy
Components => Destination Lists and click on Add. Name the list blockyahoo and make sure that the Blocked radio
button is selected. The This Destination List is applied to field should be Web Policies. Enter yahoo.com in the
Enter a domain, URL, IPv4 or CIDR box and click on Add. Once yahoo.com shows up in the lower half of the screen,
click on Save
440
2.
e
441
3. Go to Policies => Management => Web Policies and click on Add.
442
443
4. Click on Edit next to Ruleset Identities
444
5. Select Tunnels and click on Save
445
6. Click on Add Rule, give the rule a name of blockyahoo. Set the Rule Action as Block and click on Add Identity. Select the Network Tunnels as an
identity (note that we can also inherit the Ruleset identities) and click on Apply
446
7. C lick on Add Destination => Destination Lists and select the blockyahoo Destination List. Click on
Apply. Click on Save to save this rule Next
447
8. Click on Edit next to HTTPS inspection. Make sure the radio button next to Enable HTTPS inspection is selected and click on Save.
448
449
450
9. Wait for a few minutes and head over to the Site 30 PC. Click on the Flush DNS icon on the Desktop and open a new
browser window. Try to access yahoo.com. Traffic to Yahoo, which was working before, should now be blocked. Make
note of the subtext This site was blocked by the Cisco Umbrella proxy
We have completed integration and configuration of Umbrella with our SD-WAN environment.
451
Dynamic On-Demand Tunnels
Summary: Configuring Dynamic On-Demand Tunnels between Site 30 and Site 40 with DC as the backup route
Table of Contents
Overview
Exploring the current setup
Configuring a Control Policy for Dynamic

Tunnels
Configuring OMP Templates
Enabling Dynamic Tunnels
Task List
Overview
Configuring a Control Policy for Dynamic Tunnels
Overview
IPSEC tunnels are established between TLOCs in a full mesh fashion between devices in the SD-WAN overlay. This leads to multiple, potentially idle tunnels remaining up
between sites and an overhead of traffic traversing the WAN links (due to BFD).
With version 20.3 of vManage, Cisco SD-WAN allows the creation of on-demand tunnels between sites - i.e. tunnels will only be set up when there is traffic traversing the
452
sites.
The following configuration components come into play when setting up Dynamic On-Demand Tunnels:
Control Policies
OMP Templates (max path and ECMP limits) System
Templates (for configuring Dynamic Tunnels)
We will set up Dynamic On-Demand Tunnels between vEdge30 and cEdge40 with the DC-vEdges functioning as backup forwarding nodes.
Task List
Overview

0. Open a CLI session to vEdge30 using the Console . Log in via the credentials mentioned below and enter the command show
omp tlocs | tab . Notice that TLOC routes learnt from cEdge40 are Chosen, Installed and Resolved (C,I,R) or Chosen, Resolved (C,R)
Username Password
admin admin
453
454
2. Log in to cEdge40 via the console session. Use the same credentials as above and enter the command show sdwan omp tlocs . Look for the TLOC route entries
for 10.255.255.31 (vEdge30) and these are also Chosen, Installed and Resolved (C,I,R) or Chosen, Resolved (C,R)
455
456
457
3. Back at vEdge30, check the OMP routes for VPN 10 and VPN 20 subnets behind cEdge40. Run the commands show omp routes 10.40.10.0/24 and show
omp routes 10.40.20.0/24 . vEdge30 routes traffic for the subnets directly to cEdge40 (normal full mesh operation of SD-WAN)
458
459
4. Similarly, cEdge40 routes traffic for the vEdge30 VPN 10 and VPN 20 subnets directly to vEdge30. Run the commands show sdwan omp routes 10.30.10.0/24
and show sdwan omp routes 10.30.20.0/24 on cEdge40.
460
1. On the vManage GUI, navigate to Configuration => Policies
461
2. We will create a new policy for Dynamic On-Demand Tunnels. Click on Add Policy
462
3. Click on Site and then on New Site List to create a New Site List
4. Name the Site List Site30_40 and enter 30,40 in the Add Site field. Click on Add
5. Make sure the Site List looks like the image below and click on Next
463
6. Click on Add Topology and then on Custom Control (Route & TLOC) to create a new control policy
464
7. Give the control policy a Name of site30-40-dynamic-tunnels and a Description of Dynamic Tunnels between Site 30 and 40 with DC as a backup.
Click on Sequence Type and choose Route
8. Click on Sequence Rule and select Site. Populate the Site List Site30_40 and click on Actions
465
9. Set the Action to Accept and click on TLOC Action and TLOC. Populate TLOC Action as Backup and the TLOC List as DC-TLOCs. Click on Save Match and
Actions
466
10. Click on Default Action and then the pencil icon to change the default of Reject Enabled to Accept Enabled. Click on Accept and choose to Save. Make sure the
Default Action is set to Accept Enabled and click on Save Control Policy
467
11. Click Next till you’re at the Apply Policies to Sites and VPNs tab and give the policy a Name of Dynamic-Tunnels-Site30_40 with a Description of Dynamic Tunnels
between Site 30 and Site 40. Under Topology, click on New Site List for the site30-40-dynamic-tunnels policy and choose the Site30_40 Site List under Outbound
Site List. Click on Add and then click on Preview to view the CLI output of the policy
468
469
12. We will notice that the control policy is setting the TLOC of Site 30 and Site 40 OMP Routes to the DC-TLOCs TLOC list. It is also setting a tloc-action backup to
populate the ultimate tloc value in the OMP route, pointing to the other site TLOC (rather than punting traffic out the DC-TLOCs). Click on Save Policy
This completes the Control Policy required for Dynamic On-Demand Tunnels.
470
Task List
Overview

We will be applying OMP Templates to the vSmarts and the WAN Edges at Site 30 and Site 40.
1. On the vManage GUI, go to Configuration => Templates
471
472
2. Click on the Feature tab and then click on Add Template
3. Search for vSmart in the Select Devices section and select the vSmart Device. Click on OMP under Basic Configuration to start configuring an OMP Template for the
vSmarts
473
4. Give the template a name of vsmart-omp-dt with a Description of OMP modification for Dynamic Tunnels - vSmart. Set the Number of Paths Advertised per Prefix
to a Global value of 16 and click on Save
474
5. We will now apply this Feature Template to the vSmart Device Template. Go to the Device tab in Templates and locate the vSmart-dev-temp Device Template. Click
on the three dots next to it and choose to Edit the template
475
6. Under OMP, set the template to vsmart-omp-dt. Click on Update. Click on Next and Configure Devices
476
477
478
7. Confirm the configuration change and click on OK
479
8. Navigate to Configuration => Templates => Feature Tab and click on Add Template
9. Search for vedge and select vEdge Cloud. Click on OMP
480
10. Give the template a name of vedge-omp-dt with a Description of OMP modification for Dynamic Tunnels - vEdge. Set the ECMP Limit to a Global value of 16 and
click on Save
481
11. Navigate to Configuration => Templates => Feature Tab and click on Add Template. Search for csr and select CSR1000v. Click on Cisco OMP
482
12. Give the template a name of cedge-omp-dt with a Description of OMP modification for Dynamic Tunnels - cEdge. Set the ECMP Limit to a Global value of 16 and
click on Save
483
484
13. We will now attach the OMP templates just created to vEdge30 and cEdge40. Navigate to Configuration => Templates. While on the Device Tab, locate the
vEdge30_dev_temp template and click on the three dots next to it. Choose to Edit the template
14. Update the OMP template as vedge-omp-dt and click on Update. Click Next and Configure Devices to push the changes to vEdge30
485
15. Navigate to Configuration => Templates. While on the Device Tab, locate the cEdge_dualuplink_devtemp template and click on the three dots next to it. Choose to
Edit the template
486
16. Update the Cisco OMP template as cedge-omp-dt and click on Update. Click Next and Configure Devices to push the changes to cEdge40
487
488
489
This completes the configuration of our OMP Feature Templates for vEdge30 and cEdge40 to support Dynamic On-Demand Tunnels.
Task List
Overview

We will now add some basic configuration on the DC-vEdges and enable Dynamic On-Demand Tunnels via System templates.
1. Navigate to Configuration => Templates => Feature Tab and locate the DCvEdge-vpn0 Feature Template. Click on the three dots next to it and choose to Edit the
template
490
491
2. Scroll down to the Service section and click on New Service. Set the Service Type as TE and click on Add. Click on Update. Click on Next and Configure Devices.
Confirm the configuration change
492
3. On the vManage GUI, go to Configuration => Templates. Click on the Feature tab and then click on Add Template. Search for vedge in the Select Devices section
and select the vEdge Cloud. Click on System under Basic Configuration to start configuring a System Template for vEdge30
493
4. Give the template a name of vedge-system-dt with a Description of System modification for Dynamic Tunnels - vEdge. Under Advanced, set On-Demand Tunnel to a
494
Global value of On and the On-Demand Tunnel Idle Timeout (min) to 5. Click on Save
495
5. Go to Configuration => Templates. Click on the Feature tab and then click on Add Template. Search for csr in the Select Devices section and select the
CSR1000v. Click on Cisco System under Basic Configuration to start configuring a System Template for cEdge40
496
6. Give the template a name of cedge-system-dt with a Description of System modification for Dynamic Tunnels - cEdge. Under Advanced, set On-Demand Tunnel to a
Global value of On and the On-Demand Tunnel Idle Timeout (min) to 5. Click on Save
497
498
7. We will now attach the System templates just created to vEdge30 and cEdge40. Navigate to Configuration => Templates. While on the Device Tab, locate the
vEdge30_dev_temp template and click on the three dots next to it. Choose to Edit the template
499
8. Update the System template as vedge-system-dt and click on Update. Click Next and Configure Devices to push the changes to vEdge30
500
501
9. Navigate to Configuration => Templates. While on the Device Tab, locate the cEdge_dualuplink_devtemp template and click on the three dots next to it. Choose to
Edit the template
10. Update the Cisco System template as cedge-system-dt and click on Update. Click Next and Configure Devices to push the changes to cEdge40
502
This completes the configuration of our System Feature Templates for vEdge30 and cEdge40 to enable Dynamic On-Demand Tunnels.
503
Task List
Overview
2. Log in to the Console of DC-vEdge1 and DC-vEdge2. Use the credentials given
below. Issue clear control connections on both devices
Username Password
admin admin
504
3. Log in to the Console of vEdge30. Use the same credentials as above and issue show omp tlocs | tab . Notice that the TLOC Routes for cEdge40 are learnt
by vEdge30, but they are in an inactive state
4. Run the commands show system on-demand and show system on-demand remote-system on vEdge30. You will notice that vEdge30 shows itself as On-
Demand yes and Status Active. However, the Status of cEdge40 is inactive
505
5. Run the command show omp routes | tab on vEdge30. Notice that the OMP Routes for the VPN 10 subnet at cEdge40 (10.40.10.0/24) are in an Unresolved,
On-Demand Inactive state (U,IA)
506
6. On the vManage GUI, navigate to Configuration => Policies and locate the Dynamic-Tunnels-Site30_40 policy. Click on the three dots next to it and choose to
Activate this policy. Click on Activate and Configure Devices if prompted
507
7. Once the policy is active, go to the CLI of vEdge30 and run show omp routes | tab again. We now see that the traffic to the VPN 10 subnet at cEdge40
(10.40.10.0/24) is being routed via the DC-vEdges, with the direct routes to cEdge40 in an Installed, Unresolved and On-Demand Inactive state (I,U,IA)
508
8. Log in to the CLI of vEdge30 and run a Traceroute to 10.40.10.2 via the CLI traceroute VPN 10 10.40.10.2 . We will see that the initial path will traverse an IP in
VPN 10 at the DC-vEdges (10.100.10.3 in this example) and will then start going directly to cEdge40. This is because the initial packet takes the backup DC-vEdge
route after which the Tunnel between vEdge30 and cEdge40 is established. Run show system on-demand and show system on-demand remote and we will
see that the Tunnel to cEdge40 is now active, with the Idle timeout counting down from 300 seconds (i.e. 5 minutes, as we had configured in the System Template)
509
9. Subsequent traffic will go directly over the Tunnel between vEdge30 adn cEdge40, as long as the Tunnel is active. This can be verified by running traceroute vpn
10 10.40.10.2 on vEdge30
10. show omp routes 10.40.10.0/24 indicates that the Chosen, Installed, Resolved (C,I,R) route for the 10.40.10.0 subnet is the direct path to cEdge40
510
11. Wait for approximately 5 minutes and we will find that the Tunnel between vEdge30 and cEdge40 transitions to an inactive state after the Idle Timeout expires,
assuming there is no traffic between the two Sites
511
12. Once the tunnel is inactive, show omp routes 10.40.10.0/24 shows the traffic path traversing the DC-vEdges again, with the direct path to cEdge40 in I,U,IA
512
This completes the configuration and verification of Dynamic On-Demand Tunnels.
Task List
Overview
513
Inter VPN Routing and Service Chaining
Summary: Implementing Inter VPN Routing between Site 20 VPN 10 and Site 30 VPN 20, along with Service
Chaining (Firewall).
Table of Contents
Overview
Configure VPN 40 on DC-vEdges
Configuration Cleanup and Routing

Verification
Setting up VPN Lists
Inter VPN Routing Policies
Inter VPN Routing Verification
Policies for Service Chaining
Task List
Overview
Configuration Cleanup and Routing Verification
514
Overview
As of now, devices in different VPNs cannot communicate with each other. VPN 10 devices can talk to other VPN 10
devices but not to VPN 20. In this section, we will be setting up Inter VPN routing.
Additionally, there might be a requirement where we need to send traffic from one VPN to another through a firewall. This
feature is known as Service Chaining (other devices like Load Balancers can also be part of the Service Chain) and is used
widely in real-world SD-WAN Deployments.
We will be focusing on ensuring devices in Site 20 VPN 10 can communicate with devices in Site 30 VPN 20. Initially, this will
be direct communication between the two VPNs. A firewall will then be inserted in the path so that all traffic between the
VPNs traverses the firewall, which will be located at Site-DC in VPN 40.
Diagrammatically, our topology will look as below:
515
The Black arrow between Site 20 and Site 30 indicates the traffic flow when Inter VPN Routing
configuration is done for the first time. Traffic flows directly between the two Sites.
The Orange arrow is the traffic flow from Site 20 VPN 10 to Site 30 VPN 20 once Service Chaining is
configured.
516
Source IP: 10.20.10.2 or 10.20.10.3
Destination IP: 10.30.20.2
The Green arrow is the traffic flow from Site 30 VPN 20 to Site 20 VPN 10 once Service Chaining is
configured.
Source IP: 10.30.20.2

Destination IP: 10.20.10.2 or 10.20.10.3
Task List
Overview
VPN40 Template (dc-vedge-vpn40) and VPN40 interface template (dc-vedge-vpn40-int1) are preconfigured, we will simply review them and configure service insertion in dc-
vedge-vpn40 template.
1. Log in to the vManage GUI and browse to Configuration => Templates => Feature
517
2. Go to the Feature tab and edit dc-vedge-vpn40 template.
518
3. Review the Template, then Go to the Service section and click on New Service. Select the Service Type as netsvc1 and enter an IPv4 Address
of 10.100.40.1. Click on Add
4. Click on New Service again and select the Service Type as netsvc2. Enter an IPv4 Address of 10.100.40.5. Click on
Add then click on Save to save the VPN Template configuration
519
5. Review the dc-vedge-vpn40-int1 template under Configuration => Templates => Feature Tab
6. Go to Configuration => Templates on the vManage GUI and make sure you’re on the Device tab. Locate the
DCvEdge_dev_temp template and click on the three dots next to it. Choose to Edit the template
520
7. Scroll down to the Service VPN section and click on Add VPN. Move the dc-vedge-vpn40 template to the right-hand
side and click on Next
521
8. Click on VPN Interface under Additional VPN Templates and select dc-vedge-vpn40-int1 under the VPN Interface
drop down. Click on Add
9. Make sure the Service VPN section shows the addition of the VPN 40 Template and click on Update
522
10. Enter the IPv4 Address field for vpn40_if_ipv4_address as 10.100.40.2/30 (for DC-vEdge1) and 10.100.40.6/30 (for
DC-vEdge2). Click on Next
523
11. Click on Configure Devices. You can choose to view the side-by-side configuration, if required, noting the addition of
vpn 40 with the corresponding service addresses
12. Confirm the configuration change by clicking on the check box and clicking on OK
524
13. Once the configuration update goes through, log in to the CLI of DC-vEdge1 and DC-vEdge2 via Putty and issue the
following commands. You should see successful ping responses:
On DC-vEdge1 - ping vpn 40 10.100.40.1 On DC-vEdge2 - ping vpn 40 10.100.40.5
This completes the configuration needed for adding VPN 40 to the DC-vEdges.
Task List
Overview
525
1. On the vManage GUI, go to Configuration => Templates => Feature Tab. Locate the vedge-vpn20-DC template and
click on the three dots next to it. Choose to Edit the template
2. Scroll down to the IPv4 Route section and delete the route populated (it should be a null route) by clicking on the
trash icon. Click on Update. Click Next and Configure Devices to push the update out
3. To check the current routing tables for VPN 10 and VPN 20, navigate to Monitor => Network
526
4. Click on vEdge20
527
5. Go to Real Time in the left menu and enter ip route in the Device Options field. Click on IP Routes to see the current
routes and choose Show Filters
6. Enter a VPN ID of 10 and click on Search to filter the routes for VPN 10 on vEdge20
528
7. Since Inter VPN Routing hasn’t been configured yet, we will see routes that are part of VPN 10 only. Subnets from
other VPNs will not show up over here. We can thus infer that there won’t be inter VPN connectivity as of now
8. Click on Select Devices (top left-hand corner) and choose vEdge30 from the drop down. Click on Show Filters
529
9. Enter 20 in the VPN ID and click on Search
530
10. This shows all the routes learnt by vEdge30 in VPN 20. There aren’t any routes subnets in other VPNs, as of now
11. On the left-hand slide, click on Troubleshooting and select Traceroute (note that this is being done on vEdge30)
531
12. Enter a Destination IP of 10.20.10.2 and select VPN 20 from the VPN drop down. Populate the Source/Interface as
ge0/3 and click on Start
13. As expected, the traceroute should fail
532
14. Click on Select Device in the top left-hand corner and choose vEdge20. Run the traceroute again, changing the
Destination IP to 10.30.20.2, VPN to VPN 10 and the Source/Interface to ge0/2. Click on Start and this should fail
as well
533
We have established that Inter VPN communication is not happening between Site 20 and Site 30 as of now.
Task List
Overview

534
In order to facilitate inter VPN connectivity, we will be setting up VPN Lists that can be used in our Policies.
1. On the vManage GUI, go to Configuration => Policies
2.
3. Click on Custom Options in the top right-hand corner and click on Lists (under Centralized Policy)
535
4. Select VPN and click on New VPN List. Enter a VPN List Name of FW and put 40 for the Add VPN field. Click on
Add
536
5. Click on New VPN List again and Put a VPN List Name of Corp_FW. Put 10,40 in the Add VPN field. Click on Add
6. Click on New VPN List again and Put a VPN List Name of PoS_FW. Put 20,40 in the Add VPN field. Click on Add
7. Make sure that the following VPN lists show up, before proceeding
537
Task List
Overview

1. Navigate to Configuration => Policies and locate the Site40-Guest-DIA Policy. Click on the three dots next to it and
choose to Edit the policy
2. Click on the Topology tab (top of the screen) and click on Add Topology. Choose to add a Custom Control (Route &
TLOC) policy
538
3. Give the policy a Name of vpn10-inter-vpn20-40 with a Description of Control Policy for Inter VPN Routing from VPN
10 to VPNs 20 and 40. Click on Sequence Type and choose Route
539
4. Click on Sequence Rule and add a VPN match. Select Corporate from the VPN List drop down
5. Click on the Actions tab and select the Accept radio button. Click on Export To and select PoS_FW from the drop
down under Actions. Click on Save Match And Actions
540
6. Select Default Action on the left-hand side and click on the pencil icon to edit the Default Action
7. Click on Accept and then Save Match And Actions
8. Click Save Control Policy
541
9. Click on Add Topology and add another Custom Control (Route & TLOC) policy. Give it a Name of vpn20-inter-
vpn10-40 with a Description of Control Policy for Inter VPN routing between VPN 20 and VPNs 10 and 40. Click on
Sequence Type and select Route
542
10. Click on Sequence Rule and select VPN as the match. Select PoS from the VPN List
11. Click on the Actions tab and select the Accept radio button. Click on Export To and select the Corp_FW VPN list in
the Export To drop down under Actions. To save the rule, click on Save Match And Actions
543
12. Click on Default Action on the left-hand side and click the Pencil icon to edit the Default Action
13. Select Accept and click Save Match And Actions
14. Click on Save Control Policy
544
15. You should be back at the main policy screen. Click on the Policy Application tab and make sure you’re under the
Topology sub-tab (should not be under the main Topology tab). Click on New Site List under the entry for vpn10-
inter-vpn20-40 and select the Inbound Site List as Site20. Click on Add
545
16. Click on New Site List under the entry for vpn20-inter-vpn10-40 and select the Inbound Site List as Site30. Click on
Add. Click on Save Policy Changes
546
17. Click on Activate to push the changes to the vSmarts
We have set up the policies for Inter VPN Routing.
547
Task List
Overview
1. On the vManage GUI, navigate to Monitor => Network and click on vEdge20. Scroll down along the left-hand side
menu and click on Real Time. Enter IP Routes in the Device Options and select IP Routes when it pops up. Choose
Show Filters and enter a VPN ID of 10. Click on Search. The Routing Table for VPN 10 on vEdge20 should show
routes to subnets at Site 30 VPN 20
548
2. Click on Select Device in the top left-hand corner and click on vEdge30
3. Click Show Filters and enter a VPN ID of 20. Click on Search
549
4. You should see routes for Site 20 VPN 10
550
5. Click on Troubleshooting on the left-hand side and make sure you have vEdge20 as the selected device. Enter a
Destination IP of 10.30.20.2 with a VPN of VPN - 10. Select a Source/Interface of ge0/2 (once again, verify that
you’re at the vEdge20 device. If not, click on the Select Device drop down from the top left-hand corner and select
vEdge20). Click on Start. Notice that we now have direct Inter VPN connectivity from Site 20 VPN 10 to Site 30 VPN
20
551
6. Click on Select Device in the top left-hand corner and select vEdge30. Enter a Destination IP of 10.20.10.2 with a
VPN of VPN - 20 and a Source/Interface of ge0/3. Click on Start. Notice that we now have direct Inter VPN
Connectivity from Site 30 VPN 20 to Site 20 VPN 10
This completes the verification of our Inter VPN Routing configuration.
Task List
Overview
552

Direct connectivity between two VPNs might not be a desirable scenario. There might be a requirement to enforce certain
rules when two VPNs are communicating with each other. That’s where Service Chaining comes into the picture, where we
route Inter VPN traffic through an intermediary device (like a Firewall) to enforce our policies/rules. To reiterate, the traffic
flow should look like the diagram below at the end of this section vs. the direct connectivity that we have between VPNs right
now.
553
The Black arrow between Site 20 and Site 30 indicates the traffic flow when Inter VPN Routing
configuration is done for the first time. Traffic flows directly between the two Sites.
The Orange arrow is the traffic flow from Site 20 VPN 10 to Site 30 VPN 20 once Service Chaining is
configured.
554
Source IP: 10.20.10.2 or 10.20.10.3
Destination IP: 10.30.20.2
The Green arrow is the traffic flow from Site 30 VPN 20 to Site 20 VPN 10 once Service Chaining is
configured.
Source IP: 10.30.20.2

Destination IP: 10.20.10.2 or 10.20.10.3
1. On the vManage GUI, go to Configuration => Policies. Locate the Site40-Guest-DIA policy and click on the three
dots next to it. Choose to Edit the policy. Make sure you’re on the Topology tab and click on Add Topology. Choose
to add a Custom Control (Route and TLOC) topology
2. Give the Custom Control Policy a Name of site20-fw-site30 and a Description of Traffic from Site 20 to Site 30 via the
Firewall. Click on Sequence Type and choose Route
555
3. Click on Sequence Rule and select Site for a Match Condition. Click on the Site List drop down and choose Site 30.
Click on the Actions tab
4. Select the Accept radio button and choose Service. Under Actions select the Service: Type as Net Service 1 and
specify a Service: VPN of 40. Select an Encapsulation of IPSEC and click on Save Match And Actions to save this
rule
556
5. Click on Default Action on the left-hand side and click the pencil icon. Select Accept and then Save Match And
Actions. The Default Action should change to Accept Enabled. Click on Save Control Policy
6. Make sure you’re on the Topology tab and click on Add Topology. Choose to add a Custom Control (Route and
TLOC) topology. Give the Custom Control Policy a Name of site30-fw-site20 and a Description of Site 30 to Site 20 via
the firewall. Click on Sequence Type and choose Route
557
7. Click on Sequence Rule and then select Site. Choose Site 20 in the Site List under Match Conditions. Click on
Actions
8. Select the Accept radio button and choose Service. Under Actions select the Service: Type as Net Service 2 and
specify a Service: VPN of 40. Select an Encapsulation of IPSEC and click on Save Match And Actions to save this
rule
558
9. Click on Default Action on the left-hand side and click the pencil icon. Select Accept and then Save Match And
Actions. The Default Action should change to Accept Enabled. Click on Save Control Policy
559
10. Go to the Policy Application tab and locate the site30-fw-site20 and site20-fw-site30 entries. For site30-fw-site20,
click on New Site List and choose Site30 in the out direction. Click on Add. Similarly, for site20-fw-site30, click on
New Site List and choose Site20 in the out direction. Click on Add. Click on Save Policy Changes. Activate the
change when prompted to do so
Task List
Overview
560
1. Log in to the console of vEdge20 (username and password given below) and enter ping vpn 10
10.100.40.2 to test connectivity between Site 20 VPN 10 and Site DC VPN 40. The pings should fail
Username Password
admin admin
This is due to the fact that we haven’t set up inter VPN connectivity between VPN 10/VPN 20 and VPN 40. It is vital to
ensure that the source and destination VPNs can access the Service Subnet.
2. On the vManage GUI, navigate to Configuration => Policies. Click on Custom Options on the top right-hand corner
and select Lists (under Centralized Policy). Click on VPN in the left-hand menu and then New VPN List. Enter a VPN
List Name of Corp_PoS and put 10,20 in the Add VPN field. Click on Add
561
3. Go to Configuration => Policies and locate the Site40-Guest-DIA Policy. Click on the three dots next to it and choose
to Edit the policy. Click on the Topology tab (top of the screen) and click on Add Topology. Choose to add a Custom
Control (Route & TLOC) policy. Give the policy a Name of vpn40-inter-vpn10-20 with a Description of Control Policy for
Inter VPN Routing from VPN 40 to VPNs 10 and 20. Click on Sequence Type and choose Route
562
4. Click on Sequence Rule and add a VPN match. Select FW from the VPN List drop down
5. Click on the Actions tab and select the Accept radio button. Click on Export To and select Corp_PoS from the drop
down under Actions. Click on Save Match And Actions
6. Select Default Action on the left-hand side and click on the pencil icon to edit the Default Action. Click on Accept
and then Save Match And Actions. Click Save Control Policy
563
7. You should be back at the main policy screen. Click on the Policy Application tab and make sure you’re under the
Topology sub-tab (should not be under the main Topology tab). Click on New Site List under the entry for vpn40-
inter-vpn10-20 and select the Inbound Site List as DC. Click on Add. Click on Save Policy Changes. Click on
Activate to push the changes to the vSmarts
8. Head back over to the CLI of vEdge20 and type ping vpn 10 10.100.40.2. The pings should now be successful.
564
Type ping vpn 10 10.100.40.1 to ping the Firewall. This should also work
9. On the vManage GUI, go to Monitor => Network and select vEdge20. Click on Troubleshooting along the left-hand
menu and choose Traceroute. Enter a Destination IP of 10.30.20.2 and a VPN of VPN - 10. Set the
Source/Interface as ge0/2 and click on Start. We are thus doing a traceroute from Site 20 VPN 10 to Site 30 VPN 20
565
Notice that traffic doesn’t flow directly between the sites. Instead, it traverses the Firewall (IP of 10.100.40.1 in this
case) and then goes to Site 30 VPN 20.
10. Click on Select Device in the top left-hand corner and select vEdge30. Enter a Destination IP of 10.20.10.2 and a
VPN of VPN - 20. Specify a Source/Interface of ge0/3 and click on Start. We are doing a traceroute from Site 30
VPN 20 to Site 20 VPN 10
In this case as well, traffic traverses the Firewall (IP of 10.100.40.5) and then goes to Site 20 VPN 10.
This completes the Service Chaining lab activity.
Task List
Overview
566
Configuring Cloud OnRamp for SaaS
Summary: Implementing Cloud OnRamp for SaaS in Cisco SD-WAN
Table of Contents
Overview
Prerequisite configuration for Cloud

OnRamp
Task List
Overview
Prerequisite configuration for Cloud OnRamp
Overview
With the changing network landscape, the way in which applications are consumed has also undergone a massive overhaul.
Applications being hosted in the cloud (Public/Private) are a common occurrence, rather than the exception.
Cloud OnRamp for SaaS monitors widely used Cloud Applications and arrives at a vQoE score (Viptela Quality of
Experience). Loss and latency are used to calculate the vQoE score and based on this, the solution routes traffic to the
Cloud Application via the optimal path. The vQoE value is calculated periodically to ensure persistent optimal application
performance.
567
Task List
Overview

1. On the vManage GUI, navigate to Configuration => Templates => Feature Tab. Locate the vEdge30_INET template
and click on the three dots next to it. Choose to Edit the template
2. Scroll down to the NAT section and set NAT to a global value of On. Click on Update
568
3. Click on Next and Configure Device. There are no changes to be made here since we are simply enabling NAT on
the interface.
4. On the vManage GUI, go to Configuration => Templates => Feature Tab. Locate the DC-vEdge_INET template and
click on the three dots next to it. Choose to Edit the template
Note: This step is not required if you have gone through the WAAS Integration. Please skip to the next section if
WAAS integration has been done.
569
5. Scroll down to the NAT section and set NAT to a Global value of On. Click on Update. Click Next/Configure Devices
To finish the update to the devices. Confirm the change on two devices and click OK
570
6. On the vManage GUI, go to Configuration => Templates => Feature Tab. Locate the DCvEdge-vpn0 template
and click on the three dots next to it. Choose to Edit the template
Change the DNS to 8.8.8.8 and 4.2.2.2 and Click Update and OK.
571
572
We have enabled NAT on all the interfaces that will be communicating directly with the SaaS applications. There are other
prerequisites that need to be taken into consideration while deploying this in production (a few examples are devices should
be in vManage mode, DNS server details populated in VPN 0 etc.) but these have been fulfilled in our SD-WAN Network.
Task List
Overview

Go through the following steps in order to configure Cloud OnRamp for SaaS in our SD-WAN network.
1. On the vManage GUI, navigate to Administration => Settings
573
2. Locate the Cloud onRamp for SaaS section and click on Edit. Set the radio button to Enabled and click on Save.
Cloud OnRamp for SaaS needs to be enabled system wide before it can be used
574
3. Once enabled, click on the Cloud icon in the top right-hand of the screen and click on Cloud onRamp for SaaS
4. Click on Dismiss
575
5. Click on Manage Cloud onRamp for SaaS (top right-hand corner) and click on Applications
6. Specify a random application (example shows Amazon AWS, but you can choose something else like Oracle or
Google Apps) and populate a VPN of 10
576
7. Click on Cloud onRamp for SaaS (top right-hand corner) again and click on Direct Internet Access (DIA) Sites
577
8. Click on Attach DIA Sites and move Site 30 to the Selected Sites section. Click on Attach
9. Wait for the task to go through successfully. Once it is done, click on the Cloud icon in the top right corner and click
Cloud onRamp for SaaS
10. Click on Manage Cloud onRamp for SaaS and choose Gateways
578
11. Click on Attach Gateways and move Site 1000 to the Selected Sites. Click on Attach (Make sure you select Viptela OS)
579
12. If you go to Configuration => Cloud OnRamp for SaaS (or click the Cloud icon and go to Cloud onRamp for SaaS),
you should see the selected Application with 3 Devices attached to it. Click on the Application and the three Devices
should be tagged with a vQoE Status of Bad. Their vQoE score is 0.0, indicating that information hasn’t been collected
to arrive at a score. We will need to wait for some time (another tea/coffee?)
13. If you refresh the screen, you should notice devices gradually showing up with their vQoE score. Notice that vEdge30
is selecting a local path to the selected Application
Through the DIA configuration, we have provided vEdge30 with a local breakout to the Application and by adding Site
1 as the Gateway, traffic can be punted over the MPLS link to the DC site and sent out the Internet breakout there, in
the event of the local Site30 Internet breakout facing issues.
580
Task List
- Overview

1. Navigate to Configuration => Template Device and locate the vEdge30_dev_temp template. Click on the three dots
next to it and choose to Edit
581
2. Click on Additional Templates, select the Policy “Policer-AAR-Impairment” and click UPDATE. Click OK
3. Navigate to Configuration => Template => Feature Tab and locate the vEdge30_INET template. Click on the three
dots next to it and choose to Edit
582
4. Scroll down to the ACL/QOS section and specify the ACL (Impair-PL-AAR) as shown below with the name . This will
inject delay on our INET link connected to vEdge30. Click on Update
583
5. Click on Next/Configure Devices. You can check the side by side configuration to see that the shaping rate is applied
to interface ge0/0 ( It will take some time for the config to push through).
6. Wait for some time and traffic to the chosen Application from vEdge30 (check via Cloud icon => Cloud onRamp for
SaaS => click on the Application) should have a DIA status of gateway, indicating that the DC Gateway is being used
to contact Amazon AWS (in this example). The local/remote color is mpls with the system-ip of the gateway being
used
The vQoE score might vary, as shown in the image below (it usually takes approximately 15 to 20 minutes for the
expected results to show up)
This completes the Cloud OnRamp for SaaS lab.
Task List
Overview
584

Swat Sd-Wan v2 Lab Guide

Uploaded by

Copyright:

Available Formats

Swat Sd-Wan v2 Lab Guide

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Swat Sd-Wan v2 Lab Guide

Uploaded by

Copyright:

Available Formats

SDWAN-dCloud-LAB-GUIDE

* Incognito mode if seeing caching issues on the POC Tool UI.

Decoding the topology:

There are a total of 5 sites where we will have cEdges/vEdges deployed

All sites have Service VPNs associated with them.

Sites with vEdges have 2 service VPNs (VPN10 and VPN20)

Updating the vEdge Service VPN 10 with an

Updating the vEdge Service VPN 10 with an OSPF Template

3. Click on OSPF under Additional VPN Templates to add an OSPF Template

7. Under the Area section, click on New Area

12. Click on Save to save the OSPF template

Updating the cEdge Service VPN 10 with an

Activity Verification and Remediation

Updating the cEdge Service VPN 10 with an EIGRP Template

9. Wait for the change to successfully go through

Verification and Testing

Editing Templates to support VRRP

Editing Templates to support VRRP

Field Global or Device Specific (Drop Down) Value

Priority Device Specific vpn10_if_vrrp_priority

Track OMP Global On

IP Address Global 10.50.10.100

12. Confirm the configuration change and click on OK

Editing Templates to support VRRP

Verification and Testing

Editing Templates to support VRRP

Feature Templates for TLOC Extensions

Updating the VPN and Device Templates

Feature Templates for TLOC Extensions

Creating the VPN Interface Template for the TLOC-EXT interface

Section Field Global or Device Specific Value

Description NA Site 20 TLOC Extension Template without

Basic Shutdown Global No

Basic Interface Device Specific if_name_notunn_tlocext

Advanced TLOC Global ge0/0

Creating the VPN Interface Template for the Tunnel interface

Basic Shutdown Global No

Basic Interface Device Specific if_name_tunn_notlocext

Basic IPv4 Address Device Specific if_ipv4_address_tunn

Tunnel Tunnel Global On

Tunnel Color Device Specific tloc_if_tunnel_color_value

Tunnel Restrict Device Specific tloc_if_tunnel_color_restrict

Tunnel - Allow All Global On

Advanced TLOC Default

Creating the BGP Template for the MPLS link

Section Field Global or Device Specific (drop down) Value

Neighbor Address Global 192.0.2.9

Neighbor Remote AS Global 65535

Neighbor Address Family Global On

Neighbor Address Family Global ipv4-unicast

Updating the VPN and Device Templates

Interface Name (if_name_tunn_notlocext) ge0/4

IPv4 Address (if_ipv4_address_tunn) 192.168.26.20/24

Color (tloc_if_tunnel_color_value) mpls

Restrict (tloc_if_tunnel_color_restrict) Checked

IPv4 Address (if_ipv4_address_notunn) 192.168.25.20/24

Shutdown (bgp_shutdown) Checked

Interface Name (if_name_tunn_notlocext) ge0/1