Migration

Learning
Objectives
Learning Objectives
Upon completion of this lab you, you will be able to:
Determine where to best insert SD-WAN devices in an existing network

Onboard SD-WAN devices and push configuration using templates
Configure routing so migrated sites can communicate with non-migrated sites
Perform IOS-XE to XE SD-WAN upgrade

Before you begin
Before you begin
Review these for a better lab experience
Using the lab guide

Launching the lab topology
How to access devices' consoles
Prerequisites for Lab 2
The lab's network topology
Using the lab guide
Using the lab guide
Some sections of this lab are done in a terminal window. For each configuration, there is a
command window in the guide displaying the necessary commands to complete each step. In the
upper right-hand corner of each command window, there is a Copy button. Please use this
button to avoid making any entry mistakes.
The following window is an example where you can practice:

This is a test window.
Press "Copy" in the right-hand corner to copy these words.
The navigation bar on the left correspond to major sections of the lab.
Note!
SD-WAN_Migration_Lab.pptx (presented at Spring 2019 Partner/SE VT) explains
material in this lab. Note the diagrams showing where prefixes are advertised and
filtered.

Launching the lab topology
Launching the Lab Topology
POC Tool (Test Drive UI)

Step 1: Use a browser (Chrome recommended) to get on POC Tool. Click the
button on the top right of this page to for access details.
The certificate error can be ignored, or an exception can be added for the site.
Step 2: Download migration_v1.tar.gz . Click "Import" and provide this file. If you have an existing
topology running and don't see the dialog box below, go to Settings -> Reset All.
Step 3: Select 19.1.0 as the version and click "OK"
Step 4: Click on "Master View" then "Deploy". This topology takes 60-65 minutes to deploy on a
dCloud VM.
Note!
Instead of deploying one site at a time, deploying from Master View brings up the control
plane and all undeployed or modified sites in succession.
Retrieve device tokens
Retrieve device tokens
Get the token (One Time Password) for the SD-WAN devices which will be used in this topology.
The POC Tool has automation to fully deploy these devices, but for this migration lab, the devices
will be manually added to the overlay.
Note!
OTP activation is required for SD-WAN platforms without a TPM chip (e.g. vEdge Cloud
and CSR1000v XE SD-WAN). In this POC Tool lab, the vManage VM is deployed from
scratch and will generate unique tokens for devices even if the uploaded serial file (WAN
Edge List) is the same across POC Tool instances.
Step 1: vManage can be accessed as soon as "Control Plane" gets deployed on POC Tool. On
vManage, go to "Configuration" -> "Devices"
Step 2: Search for the following devices and copy their corresponding tokens. You may have to
expand the column for the token string to display fully.
CSR-00741509-DF53-4346-A1C1-6BFB3070118E
CSR-13C1E07F-88DC-4BD2-98C8-CFFE80B836C4
CSR-212D9E25-AD84-4E18-9725-B3CDEABFE1A8
CSR-330E65C0-8D52-41B2-940A-398119726CCE
CSR-48AE423E-2125-4877-8D00-C224BE0C38B6
Save the tokens on a text editor. These will be used in the subsequent labs.

Device console
Device console
To access a device’s CLI, click the site on the left navigation bar, right click on the device’s icon,
and click on “Console”. On the image below, we are accessing dc1-sjc-cedge1.
A console will appear on the bottom right side of the browser. You may open consoles from
different devices at the same time. These will appear as tabs.
Note!
To resize the window, click-and-drag the edges.
Note!
Font size can be also be resized (Ctrl – "-“ or “=”, use cmd key for Mac) while focus is on
the window.
Lab 2 prerequisite
Lab 2 prerequisite
Important!
In Lab 2, an IOS-XE device (br3-lax-ce) will be upgraded into XE SD-WAN. The steps
below are required in order for Lab 2 to be executed properly. This lab can be skipped if
you prefer to delete the IOS-XE CSR1000v and use POC Tool's automation to deploy an
XE SD-WAN CSR1000v in its place.
Step 1: On the Test Drive UI, go to the “BR3-LosAngeles” site, right-click on “br3-lax-ce” then
select “Console”
Step 2: Copy this line then paste on br3-lax-ce's console. (right click + “Paste” isn’t supported on
web console yet, use shortcut key Ctrl/Cmd-“V”)
ssh -l cisco 192.168.150.1 "wget http://64.71.131.100:8888/poctool_labs/csr1000v-ucmk9.16.11.1a.SPA.bin ~
When prompted for password: cisco
Sample output:
br3-lax-ce#ssh -l cisco 192.168.150.1 "wget http://64.71.131.100:8888/poctool_labs/csr1000v-ucmk9.16.11.1a.S
Password: cisco
--2019-08-20 02:11:24-- http://64.71.131.100:8888/poctool_labs/csr1000v-ucmk9.16.11.1a.SPA.bin
Connecting to 64.71.131.100:8888... connected.
HTTP request sent, awaiting response... 200 OK
Length: 392928736 (375M) [application/octet-stream]
Saving to: ‘csr1000v-ucmk9.16.11.1a.SPA.bin’
csr1000v-ucmk9.16.11.1a.SPA.bin 100%[==================================================================
2019-08-20 02:11:35 (36.8 MB/s) - ‘csr1000v-ucmk9.16.11.1a.SPA.bin’ saved [392928736/392928736]
/home/cisco: Scheme missing.

FINISHED --2019-08-20 02:11:35--
Total wall clock time: 10s
Downloaded: 1 files, 375M in 10s (36.8 MB/s)
[Connection to 192.168.150.1 closed by foreign host]
Step 3: Copy the image to bootflash:
copy scp://cisco@192.168.150.1//home/cisco/csr1000v-ucmk9.16.11.1a.SPA.bin bootflash:
Sample output:
br3-lax-ce#copy scp://cisco@192.168.150.1//home/cisco/csr1000v-ucmk9.16.11.1a.SPA.bin bootflash:

Destination filename [csr1000v-ucmk9.16.11.1a.SPA.bin]?
Password: cisco
Sending file modes: C0664 392928736 csr1000v-ucmk9.16.11.1a.SPA.bin
!!!!!!!!!!!!!!!!!!!
<snip>
392928736 bytes copied in 232.531 secs (1689791 bytes/sec)
Copying the XE SD-WAN image into this device will take 4 minutes
Network Topology Diagram
Network Topology Diagram
This diagram can also be viewed by clicking the

icon on the top right corner of this lab guide.
Lab 1: DC Migration
DC Migration
Description
This lab is the equivalent of inserting new XE SD-WAN equipment as head-ends in the data
centers.
If the device being configured is already part of the network when it’s attached to a template, the
configuration is sent to the device immediately. If the device has not yet joined the network,
vManage pushes the configuration immediately after it learns that the device is present in the
network.
For dc1-sjc-cedge1, we’ll use CLI to join it the SD-WAN overlay (CLI mode). Once joined, it will
then be attached to a template and it becomes vManage mode.
dc1-sjc-cedge2 and dc2-fra-cedge1 will be attached to a template before they join the overlay,
and will pull configs as soon as their control plane comes up
As part of bringup, a root cert is manually installed. Virtual devices don’t have a TPM chip and
this lab is configured with Enterprise CA.
VPN0 transports are connected to both MPLS and Internet. VPN1 will be peered to DC core
routers via BGP and will receive routes from the underlay. These routes will be redistributed to
the overlay via OMP.
Filters will be configured from the DC core routers so only the default route and select prefixes
originating from the DC are advertised (and eventually redistributed on the overlay).
Objective
Apply CLI configuration on an XE SD-WAN device to have it join the network
Attach devices (ones which are already on the SD-WAN overlay and those yet to be
added) to a device template and see how configuration gets pushed.
Set devices’ configuration in a device template by uploading a CSV
Learn how to verify control plane and data plane using both vManage UI and the device’s
CLI
Modify the OMP and BGP templates to enable redistribution between these protocols
Understand redistribution between OMP-BGP and how routing occurs between the
underlay and overlay.
Before migration
After migration
Bring up first XE SD-WAN device in DC1
Bring up first XE SD-WAN device in DC1
Step 1: On the Test Drive UI, go to the “DC1-SanJose” site, right-click on “dc1-sjc-cedge1” then
Step 2: If booted up without configs, skip configuration dialog and terminate autoinstall. Go to
config mode. Note, it’s not “config t”
Sample output:
--- System Configuration Dialog ---
Would you like to enter the initial configuration dialog? [yes/no]: no

Would you like to terminate autoinstall? [yes]: yes
<snip>
User Access Verification

Username: admin
Password: admin
Router>enable
Router#config-transaction
Note!
If you can’t enter config mode, the SD-WAN processes on your lab device might still be
coming up. Try again in a few seconds.
Step 3: Copy the SD-WAN config block below (use the "Copy" button on the top right of the
widget to prevent formatting errors) then paste on dc1-sjc-cedge1's console. (right click + “Paste”
isn’t supported on web console yet, use shortcut key Ctrl/Cmd-“V”)
hostname dc1-sjc-cedge1
ip host vbond-test-drive 19.1.1.2
!
! FYI, below are the minimum 4 configs for PnP (which works only on
! physical devices). The PnP process starts once it reaches the vbond
system
system-ip 1.10.1.1
site-id 10
organization-name "Viptela-POC-Tool - 19827"
vbond vbond-test-drive
!
!
! configs for connectivity
!
interface GigabitEthernet1
ip address 10.1.254.10 255.255.255.252
no shutdown
!
ip route 0.0.0.0 0.0.0.0 10.1.254.9
!
!
! bring up the SD-WAN tunnel
!
interface Tunnel1
ip unnumbered GigabitEthernet1
tunnel source GigabitEthernet1
tunnel mode sdwan
!
sdwan
tunnel-interface
encapsulation ipsec
color public-internet
allow-service dhcp dns icmp sshd netconf ntp
!
Step 4: Enter "commit" to apply the configuration
Sample output:
Router(config-tunnel-interface)# commit
*Jun 9 14:11:02.690: %DMI-5-CONFIG_I: R0/0: nesd: Configured from NETCONF/RESTCONF by admin, transaction-id
*Jun 9 14:11:03.051: %Cisco-SDWAN-Router-OMPD-5-NTCE-400003: R0/0: OMPD: Operational state changed to UP
Commit complete.
dc1-sjc-cedge1(config-tunnel-interface)#
*Jun 9 14:11:03.399: %OSPF-6-DFT_OPT: Protocol timers for fast convergence are Enabled.
*Jun 9 14:11:03.623: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down
*Jun 9 14:11:07.787: %LINK-3-UPDOWN: Interface GigabitEthernet1, changed state to up
*Jun 9 14:11:08.788: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1, changed state to up
*Jun 9 14:11:12.643: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up
dc1-sjc-cedge1(config-tunnel-interface)# end
dc1-sjc-cedge1#
Step 5: Install the root cert (copied beforehand).
request platform software sdwan root-cert-chain install bootflash:cacert.pem
Sample output:
dc1-sjc-cedge1#$ware sdwan root-cert-chain install bootflash:cacert.pem

Uploading root-ca-cert-chain via VPN 0
Copying ... /bootflash/cacert.pem via VPN 0
Updating the root certificate chain..
Successfully installed the root certificate chain
dc1-sjc-cedge1#
Step 6: Activate the XE SD-SDWAN CSR1000v. (use the "Copy" button on the top right of the
widget). Append the token which was retrieved earlier (section Before you begin -> Retrieve
device tokens).
Note!
This step is not required on physical platforms as these authenticate using certificates in
built-in TPM chip. For software devices (vEdge Cloud and CSR1000v SD-WAN), the
chassis-number and token can be obtained from vManage's Devices page.
request platform software sdwan vedge_cloud activate chassis-number CSR-00741509-DF53-4346-A1C1-6BFB30701

Sample output:
dc1-sjc-cedge1#request platform software sdwan vedge_cloud activate chassis-number CSR-00741509-DF53-4346-A1

dc1-sjc-cedge1#
*Jun 9 14:18:06.207: %Cisco-SDWAN-dc1-sjc-cedge1-action_notifier-6-INFO-1400002: R0/0: VCONFD_NOTIFIER: Not
19 14:18:6 security-install-csr severity-level:minor host-name:default system-ip:1.10.1.1
19 14:18:13 security-install-rcc severity-level:minor host-name:default system-ip:1.10.1.1
19 14:18:27 security-install-certificate severity-level:minor host-name:default system-ip:1.10.1.1
*Jun 9 14:19:02.315: %OSPF-6-DFT_OPT: Protocol timers for fast convergence are Enabled.
*Jun 9 14:19:02.308: %Cisco-SDWAN-Router-OMPD-3-ERRO-400002: R0/0: OMPD: vSmart peer 1.1.1.3 state changed
*Jun 9 14:19:04.991: %Cisco-SDWAN-Router-OMPD-6-INFO-400002: R0/0: OMPD: vSmart peer 1.1.1.3 state changed
*Jun 9 14:19:05.005: %Cisco-SDWAN-Router-OMPD-5-NTCE-400002: R0/0: OMPD: vSmart peer 1.1.1.3 state changed
*Jun 9 14:19:05.005: %Cisco-SDWAN-Router-OMPD-6-INFO-400005: R0/0: OMPD: Number of vSmarts connected : 1
Step 7: Verify control plane connectivity on the CLI. It takes a few seconds for it to come up after
the previous command. Check what’s happening by monitoring the console and by using these
commands.
show sdwan control connection-history
show sdwan control connections
Step 8: Control plane connectivity can also be verified from the vManage dashboard (the home
page). On vManage, click on the arrow
Go to the right end, click on the three dots, select “Real Time”
Type “Control Connections” on the “Device Options” field and click “Do Not Filter” when prompted
See which devices it made control connections to.
Note!
What's missing? Once the SD-WAN edge device joins the network, it doesn't need to
maintain a control connection to this component.

Attach the DC devices to a template
Attach the DC devices to a template
Step 1: On Configuration -> Templates, look for the device template "Site-DC". Click on the 3
dots and select “Attach Devices”
Step 2: Attach the following devices:
dc1-sjc-cedge1 (the device we just brought up in the previous task)
CSR-13C1E07F-88DC-4BD2-98C8-CFFE80B836C4 – to be brought up as dc1-sjc-cedge2
CSR-212D9E25-AD84-4E18-9725-B3CDEABFE1A8 – to be brought up as dc2-fra-cedge1
You may use the search function and enter partial strings to help find chassis IDs.
Click "Attach"
Note!
If the device being configured is already part of the network when it’s attached to a
template, the configuration is sent to the device immediately. If the device has not yet
joined the network, vManage pushes the configuration immediately after it learns that
the device is present in the network.
Step 3: CSV makes it easy to configure multiple devices. Get the csv here: Site-DC-
migration.csv
Step 4: On vManage, click on the up arrow.

Step 5: Upload the CSV file
Then click "Next"

Step 6: Verify config which will be synced to the existing device in the overlay (dc1-sjc-cedge1)
Step 7: At the bottom of the page, click “Configure Devices”

Confirm then "OK"
Step 8: Monitor progress. How is the message different for the device which is already on the
network vs ones which aren’t?
Bring up XE SD-WAN devices in DC1 and DC2
Bring up remaining XE SD-WAN devices in DC1 and DC2
Warning!
Please make sure you are assigning the correct chassis-number to the correct device
Step 1: On site DC1-SanJose, console to dc1-sjc-cedge2. If prompted, user/pass is admin /

admin.
The base configs for connectivity has been added. We’ll just install the root cert and activate.
(use the "Copy" button on the top right of the widget). Append the token which was retrieved
earlier (section Before you begin -> Retrieve device tokens). Make sure you are entering this
command on dc1-sjc-cedge2
request platform software sdwan vedge_cloud activate chassis-number CSR-13C1E07F-88DC-4BD2-98C8-CFFE80B83
Step 2:
On site DC2-Frankfurt, console to dc2-fra-cedge1.
Base configs have been added here as well. Install the root cert and activate.
earlier (section Before you begin -> Retrieve device tokens). Make sure you are entering this
command on dc2-fra-cedge1
request platform software sdwan vedge_cloud activate chassis-number CSR-212D9E25-AD84-4E18-9725-B3CDEABFE

Step 3: Verify control plane connectivity of these devices. Follow similar steps as Task "Bring up
first XE SD-WAN device in DC1", steps 7 and 8
Verify data and control plane between sites
Verify data plane and control plane between sites
Note!
The vManage dashboard widgets may take a few seconds to update
Step 1: Now we have 2 sites in the overlay, we can verify data plane (BFD) connectivity between
them. Go to vManage console, look for the “Site Health” widget, then click on “Full WAN
Connectivity”
Select any device and “Device Dashboard”

Items of note are:
Note!
To which devices did it form data plane connections to, and over which circuits?
Step 2: Go to any XE SD-WAN edge device’s Real Time stats and go through various BFD
output.
Equivalent on CLI:
dc1-sjc-cedge1#show sdwan bfd ?
history Display sdwan bfd history
sessions Display sdwan bfd sessions
summary Display sdwan bfd summary
tloc-summary-list Display sdwan bfd tloc_summary_list
Note!
Do devices in the same site create BFD sessions between them?
Step 3: Let’s look at control plane. On dc2-fra-cedge1 -> Real Time, see what routes it received
via OMP. You’ll see dc1-cedges’ connected subnets, and the TLOC paths for each prefix (one via
mpls, another via public-internet)
Try this on CLI and understand the status codes (C, I, R, etc):
dc2-fra-cedge1# show sdwan omp routes "| tab"

Peer BGP from non SD-WAN devices in DC
Peer BGP from non SD-WAN devices in DC
Important!
Pay attention to the prefix-list and BGP filters
Step 1: On site DC1-SanJose, console to dc1-sjc-core1 and configure the following:

conf t
!
description to_dc1-sjc-cedge1
ip address 10.1.11.1 255.255.255.252
no shutdown
!
ip address 10.1.11.5 255.255.255.252
no shutdown
!
!
! only the default route and networks from this DC will be advertised
! to the SD-WAN edges.
!
ip prefix-list PL-DC1_TO_CEDGE-OUT seq 10 permit 10.1.100.0/24
!
!
! note the SD-WAN edges' AS no
!
router bgp 65010
neighbor 10.1.11.2 remote-as 65025
neighbor 10.1.11.2 description to_dc1-sjc-cedge1
neighbor 10.1.11.2 prefix-list PL-DC1_TO_CEDGE-OUT out
Note!
What prefixes do we want the SD-WAN devices to learn and install on the SD-WAN
overlay?
Step 2: On site DC1-SanJose, console to dc1-sjc-core2 and configure the following:

conf t
!
ip address 10.1.12.1 255.255.255.252
no shutdown
!
ip address 10.1.12.5 255.255.255.252
no shutdown
!
ip prefix-list PL-TO_CEDGE-OUT seq 10 permit 10.1.100.0/24
!
router bgp 65010
bgp log-neighbor-changes
neighbor 10.1.12.2 prefix-list PL-TO_CEDGE-OUT out
neighbor 10.1.12.6 prefix-list PL-TO_CEDGE-OUT out
Step 3: On site DC2-Frankfurt, console to dc2-fra-core1 and configure the following:

conf t
!
ip address 10.2.11.1 255.255.255.252
no shutdown
!
!
! only the default route and networks from this DC will be advertised
! to the SD-WAN edges.
!
!
!
! note the SD-WAN edge's AS no here in DC2
!
router bgp 65020
neighbor 10.2.11.2 description to_dc2-fra-cedge1
Step 4: Verify BGP routes from the SD-WAN devices. From Monitor -> Network, select any SD-
WAN device -> Real Time
Try the equivalent CLI:
dc1-sjc-cedge2#show bgp vrf 1

! vrf 1 is VPN 1
Modify the OMP feature template and verify
Modify the OMP feature template and verify
The OMP feature template will be configured to enable redistribution of BGP routes into OMP.
This will allow remote SD-WAN sites to learn these prefixes.
Step 1: (optional pre-verification) Select any device and see OMP routes it is receiving. If you
don’t remember how, refer back to Task "Verify data plane and control plane between sites" Step
3
Step 2: Back on the “Templates” page, under the “Feature” tab, select the “b_OMP” feature
template from the list. At the rightmost section, right-click on the three dots and select “Edit”
Step 3: Modify BGP to "On", and click “Update”

Step 4: Because this feature template is a) currently part of existing device templates, and b)
these device templates have devices attached, those devices will have their configurations
modified. Click “Next”
Step 5: To see the equivalent CLI configuration, click on the device at the left column, click
“Config Diff”, scroll down the diff window and find the green line. What OMP-related config do you
see?
Once found, click on “Configure Devices”.
Step 6: Check “Confirm” and click “OK” to finish.

Step 7: Select any device and see what OMP routes it is receiving. If you don’t remember how,
refer back to Task "Verify data plane and control plane between sites" Step 3
Note!
What routes were added?

Modify the BGP feature template and verify
Modify the BGP feature template and verify
The BGP feature template will be configured to enable redistribution of OMP routes into BGP.
This will allow the BGP peers in the legacy network to learn SD-WAN prefixes.
Step 1: (optional pre-verification) Console into any non SD-WAN device in the DCs (dc1-sjc-
core1, dc1-sjc-core2, or dc2-fra-core1) which has peering to an SD-WAN device and verify
received routes.
dc1-sjc-core1#show run | i (neighbor.*cedge)

dc1-sjc-core1#show ip bgp neighbors 10.1.11.2 routes
Is the non SD-WAN device receiving BGP routes from the SD-WAN device?
Step 2: Back on the “Templates” page, under the “Feature” tab, pick the “BGP” feature template
from the list. At the rightmost section, right-click on the three dots and select “Edit”
Step 3: Configure OMP redistribution

Step 4: Click “Update”
Step 5: Click “Next”

Step 6: Click “Configure Devices”. (Optional – select a device and find the config diff)
Then “OK”
Step 7: Console into any non SD-WAN device in the DCs (dc1-sjc-core1, dc1-sjc-core2, or dc2-
fra-core1) and verify received routes from the SD-WAN devices. Commands same as Step 1
above
Note!
Which prefixes go through the legacy network and which go through the SD-WAN?
Prefixes going to SD-WAN come from which AS? What loop prevention mechanisms are
in place?

Lab 2: Branch migration: in-place upgrade of single router
Branch migration: in-place upgrade of single router
Description
A site which has a compatible Cisco router can be migrated over to SD-WAN with just a
requirements check and a software image upgrade. There is a prescribed set of steps for an
upgrade to be successful.
Objective
Do software upgrade on an IOS XE device into XE SD-WAN
Determine how bootstrap configs are generated
Before migration
After migration
Attach the BR3 device to a template
Step 1: On Configuration -> Templates, look for the device template "b_Site-
SingleRtr_MPLSOnly". Click on the 3 dots and select “Attach Devices”
Step 2: Attach the following device:
CSR-330E65C0-8D52-41B2-940A-398119726CCE – to be brought up as br3-lax-cedge
Click "Attach"
Step 3: Get the csv here: Site-BR3.csv and upload to populate template values.
Step 4:
then
Upgrade the IOS XE device to XE SD-WAN
Upgrade the IOS XE device to XE SD-WAN
Step 1: The configuration file for on-site bootstrap is generated by vManage and will contain
settings from the template if the device is attached to it. It can then copied to a bootable USB
drive and plugged into the device, or copied directly the device’s bootflash. When the device
boots, it uses the information in the configuration file to come up on the network. Note that a
bootstrap file is not mandatory for IOS-XE to XE SD-WAN upgrade but will make provisioning
easier, especially if the device can’t do PnP (can’t call home to devicehelper.cisco.com, no DHCP,
etc)
On vManage, Configuration -> Devices, look for CSR-330E65C0-8D52-41B2-940A-

398119726CCE
Click the three dots and select “Generate Bootstrap Configuration”
Step 2: Look at the Bootstrap Configuration.

Note!
For convenience, the boostrap file has been downloaded in advance to a web server
and will be copied to the device in the next step.
Step 3: On the Test Drive UI, go to the “BR3-LosAngeles” site, right-click on “br3-lax-ce” then
Step 4: Download the bootstrap file to the device's bootflash
copy http://64.71.131.100:8888/poctool_labs/ciscosdwan_cloud_init.cfg bootflash:
Sample output:
br3-lax-ce# copy http://64.71.131.100:8888/poctool_labs/ciscosdwan_cloud_init.cfg bootflash:
Destination filename [ciscosdwan_cloud_init.cfg]?

Accessing http://64.71.131.100:8888/poctool_labs/ciscosdwan_cloud_init.cfg...
Loading http://64.71.131.100:8888/poctool_labs/ciscosdwan_cloud_init.cfg
br3-lax-ce#
Step 5: Modify the OTP from the downloaded bootstrap file. Get the OTP for this device as you
did in Lab 1.
Important!
This step is specific for this lab. The bootstrap config file with the current OTP could
have been downloaded from vManage then downloaded to the device, but we'd have
more steps (uploading to web server reachable from the lab network, etc).
Download the tcl script.
copy http://64.71.131.100:8888/poctool_labs/token.tcl bootflash:

Sample output:
br3-lax-ce# copy http://64.71.131.100:8888/poctool_labs/token.tcl bootflash:

Destination filename [token.tcl]?
Accessing http://64.71.131.100:8888/poctool_labs/token.tcl...
Loading http://64.71.131.100:8888/poctool_labs/token.tcl
Execute the tcl script and append the token which was retrieved earlier (section Before you
begin -> Retrieve device tokens) as the script's argument. The token/OTP will be different from
the sample output below.
br3-lax-ce# tclsh token.tcl 8933704457cf7b675ed02c620931fb61

Replacing otp : 614aa2a7c8a6193b7bc682b393062375 with 8933704457cf7b675ed02c620931fb61
Step 6: Erase existing XE config on br3-lax-ce then reload. (optional: check existing config, what
routes it's receiving, etc. before erasing)
br3-lax-ce# wr erase
Erasing the nvram filesystem will remove all configuration files! Continue? [confirm]
[OK]
Erase of nvram: complete
br3-lax-ce#reload
Proceed with reload? [confirm]
Note!
Hardware platforms will not require this reload step
Step 7: Skip configuration dialog and terminate autoinstall. Check the bootstrap config on the
device once it comes back up from reload.
Router# more flash:ciscosdwan_cloud_init.cfg
Content-Type: multipart/mixed; boundary="===============1328478663389811496=="

MIME-Version: 1.0
--===============1328478663389811496==
Content-Type: text/cloud-config; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="cloud-config"
#cloud-config
vinitparam:
- uuid : CSR-330E65C0-8D52-41B2-940A-398119726CCE
- vbond : vbond-test-drive
- otp : 614aa2a7c8a6193b7bc682b393062375
- org : Viptela-POC-Tool - 19827
- rcc : true
<snip>
* root cert was added on the config file as workaround in this virtual lab which doesn’t have an
Enterprise Root CA
Note!
On hardware platforms, the XE SD-WAN image looks for flash:ciscosdwan.cfg
Important!
The bootstrap config will only be read if the XE SD-WAN image comes up with no
existing config
Step 8: Boot the XE SD-WAN image.

Router#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#boot system flash bootflash:csr1000v-ucmk9.16.11.1a.SPA.bin
Router(config)#end
Router#write mem
Building configuration...
[OK]
Router#show bootvar
BOOT variable = bootflash:csr1000v-ucmk9.16.11.1a.SPA.bin,1;
CONFIG_FILE variable does not exist
BOOTLDR variable does not exist
Configuration register is 0x2102
Router#reload
Proceed with reload? [confirm]
It will come up on the network with no additional commands needed.
This step will take around 20 mins to complete in this lab environment. XE SD-WAN upgrade is
way faster on hardware platforms; virtual platforms are not meant to be upgraded--just directly
provision the image. While waiting, you may proceed to Lab 3.
Verify connectivity to other sites
Verify connectivity to both migrated and non-migrated sites
Note!
(This task is optional. You may come back here after finishing Lab 3)
Step 1: Ping a migrated site, DC1:
br3-lax-cedge#ping vrf 1 10.1.100.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.100.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 9/10/11 ms
Ping a non-migrated site, BR6 (non-migrated)
br3-lax-cedge#ping vrf 1 10.6.100.1

!!!!!
Step 2: Traceroute from this site’s VPN1 to DC1 LAN (migrated site)
br3-lax-cedge#traceroute vrf 1 10.1.100.1

Tracing the route to 10.1.100.1
VRF info: (vrf in name/id, vrf out name/id)
1 10.1.1.14 10 msec 12 msec 5 msec
2 10.1.11.5 12 msec 16 msec *
Traceroute from this site’s VPN1 to BR6 LAN (non-migrated site)

1 10.1.1.10 11 msec 11 msec 8 msec
2 10.1.11.1 7 msec 8 msec 7 msec
3 10.1.1.1 11 msec 11 msec 9 msec
4 10.10.0.1 9 msec 15 msec 13 msec
5 10.60.0.2 18 msec 28 msec *

Lab 3: Branch migration: retain CE, add SD-WAN
Branch migration: retain CE, add SD-WAN

(overlay/underlay routing at branch)
Description
We will add an XE SD-WAN device while retaining an existing CE. An Internet link is provisioned
to the site and will connect to the XE SD-WAN device.
In most cases, the existing CE is kept for MPLS connectivity for the SD-WAN device, and all site
traffic goes through the SD-WAN overlay. Overlay/underlay routing is still done at the DC or hub
site.
However, in this lab scenario, overlay/underlay routing is done at the branch site. This is NOT
recommended, but is discussed in this lab to show SD-WAN deployments can be flexible and be
suited to specific network requirements. This can also be an interim state before full site cut-over
to SD-WAN. There will be routing preference to prefer prefixes coming from the SD-WAN overlay
for the communicating with the migrated sites while preferring the CE router for communicating
with the non-migrated sites. Steps will be taken to prevent routing loops.
Before migration
After migration
Attach the BR4 device to a template
Step 1: On Configuration -> Templates, look for the device template "b_Site-
HA_overlay_underlay". Click on the 3 dots and select “Attach Devices”
Step 2: Attach the following device:
CSR-48AE423E-2125-4877-8D00-C224BE0C38B6 – to be brought up as br5-bcn-cedge1
Click
Step 3: Get the csv here: Site-BR5.csv and upload to populate template values.
Step 4: Once values are uploaded, click on the 3 dots and select “Edit Device Template” to verify.
Take note of the BGP AS #s. Refer again at the network topology diagram (click the
icon on the top right corner of this lab guide.)

Click "Cancel" or "Update" to close the dialog box.
Step 4: Click
then
Join XE SD-WAN device to overlay
Join XE SD-WAN device to overlay
Step 1: On site BR5-Barcelona, console to br5-bcn-cedge1. If prompted, user/pass is admin /

admin.
The base configs for connectivity has been added. We’ll just install the root cert and activate.
earlier (section Before you begin -> Retrieve device tokens).
request platform software sdwan vedge_cloud activate chassis-number CSR-48AE423E-2125-4877-8D00-C224BE0C3
Step 2: (optional) Verify control plane and data plane connectivity (your preference: from
vManage UI, or console CLI)
Stage the SD-WAN device
Stage the SD-WAN device
A staged SD-WAN device will not do routing.
Step 1: On vManage, go to Configuration -> Certificates
Step 2: Search for br5-bcn-cedge1 and click “Staging”. Click OK to confirm

Step 3: Click on “Send to Controllers”
Peer BGP from non SD-WAN devices in branch
Configure L3 and BGP on the non SD-WAN devices in this branch
Step 1: Console in the br5-bcn-rtr device (the site's existing LAN router) to configure the BGP
Peering towards br5-bcn-cedge1 device.
Step 2: Configure BGP and route filters on the L3 device (br5-bcn-rtr) to prevent
readvertisements from SD-WAN to non SD-WAN and vice versa.
conf t
ip address 10.5.2.2 255.255.255.252
description to_br5-bcn-cedge1
no shutdown
!
ip prefix-list PL-BR5PREFIXES-OUT seq 5 permit 10.5.1.0/24
!
router bgp 65054
bgp log-neighbor-changes
!
address-family ipv4
neighbor 10.5.1.1 prefix-list PL-BR5PREFIXES-OUT out
neighbor 10.5.2.1 prefix-list PL-BR5PREFIXES-OUT out
Step 3: (Optional: on either non SD-WAN peer, verify BGP output before performing this step and
see what validating SD-WAN device does).
On vManage, Configuration -> Certificates, validate br5-bcn-cedge1.

Click “Valid”, confirm, then “Send to Controllers”
Step 4: Verify BGP output on br5-bcn-rtr
Note!
What prefixes did it receive from the SD-WAN device? How will this LAN router route to
SD-WAN migrated and non-migrated sites?

Verify connectivity to sites
Verify connectivity to both migrated and non-migrated sites
Step 1: Ping a non migrated site from br5-bcn-rtr and perform traceroute. Verify the path is
through the CE device.
br5-bcn-rtr#ping 10.6.100.1
!!!!!
br5-bcn-rtr#traceroute 10.6.100.1
1 10.5.1.1 4 msec 4 msec 3 msec
2 10.50.0.1 [AS 65050] 3 msec 5 msec 4 msec
3 10.60.0.2 [AS 65000] 8 msec 8 msec *
Step 2: Ping the SD-WAN migrated site from br5-bcn-rtr and perform traceroute. Verify the path
is through the cEdge SD-WAN device.
br5-bcn-rtr#ping 10.2.100.1
!!!!!
br5-bcn-rtr#traceroute 10.2.100.1
1 10.5.2.1 3 msec 2 msec 2 msec
2 10.2.1.10 [AS 65020] 7 msec 20 msec 7 msec
3 10.2.11.1 [AS 65055] 11 msec 9 msec *
Lab 4: Policies
Policies
Description
The SD-WAN overlay is controlled by centralized policies.
The policies that dictate the network topology are called Control Policies. These policies
manipulate the advertisement of routes and TLOCs (Transport Location) information.
The policies are configured via the vManage GUI and applied to the vSmart controller. The
vSmart controller propagates the necessary information to the SD-WAN edge devices.
Objective
We will configure and verify a hub and spoke control policy.
Attach vSmart to template
Attach vSmart to template
The vSmart must be in vManage mode (attached to a template) in order to push centralized
policies.
Step 1: Copy the running configuration of vSmart. On "Configuration" -> "Devices", go to

"Controllers", click the three dots and select "Running Configuration"
Step 2: Copy everything then "Close"
Step 3: Create a CLI Device Template. On "Configuration" -> "Templates", click "Create
Template" and select "CLI Template"
Note!
This method of attaching the vSmart to a device template is just a quick procedure for
this lab. In actual deployments, it is recommended that the vSmarts are attached to a
device template with feature templates, or use variables on a CLI device template.
Step 4: Populate the Device Model, Name, and Description fields. On the CLI Configuration
section, paste the vSmart running configuration. Click "Add"
Step 5: Attach the vSmart to the device template.
Step 6: Click

Configure a control policy (hub and spoke)
Configure a control policy (hub and spoke)
By default, SD-WAN tunnels come up full mesh. To make the solution more scalable, a hub and
spoke topology can be created.
Currently, BR-LosAngeles can directly talk to BR-Barcelona. After applying Hub-and-Spoke

policy, these branches can only communicate via hub.
Step 1: Click on the Configuration tab and click Policies

Step 2: Click on Add policy
Step 3: We will define San Jose (site 10) and Frankfurt (site 20) as our hub sites. Click on "Site",
"New Site List", provide a name for the hub site list, add the site numbers, then click "Add".
Step 4: Do the same for spoke sites. Here, we're providing a range.
A good site numbering scheme help building policies easier.
Step 5: Click on "VPN". A VPN list was already pre-added for this lab. Click "Next"
Step 6: Click "Add Topology" then "Hub-and-Spoke"
Step 7: Add the name and description for the policy, and select the VPN List. Click "Add Hub
Sites" and select the hub site list. Do the same for Spoke Sites. Save.
Step 7: Click "Next"
Step 8: We are not adding Data Policies at this time. Click "Next"
Step 9: Provide a name and description for this policy then click "Preview"
Step 10: Look at the contents and click "Save Policy"

Apply and validate hub-and-spoke policy
Apply and validate hub-and-spoke policy
Step 1: Before we apply the policy, verify BFD tunnels from a branch site. Go to "Monitor"->
"Network" and select the br5-bcn-cedge1 device. Identify the tunnel to the other branch site.
Optionally, try traceroute from br3-lax-cedge to an IP in BR5-Barcelona
Step 2: Apply the Hub and Spoke policy. Go to "Configuration" -> "Policies" then Activate.
Step 3: Now that the policy is applied, again verify the BFD tunnels (see Step 1). What changed?
Optionally, try traceroute and see the path.

1 10.1.1.10 8 msec 6 msec 7 msec
2 10.5.102.2 11 msec 11 msec 15 msec
3 10.5.2.2 17 msec * 15 msec

Migration

Uploaded by

Copyright:

Available Formats

You might also like

Migration

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

Migration

Uploaded by

Copyright:

Available Formats

Learning

Upon completion of this lab you, you will be able to:

Determine where to best insert SD-WAN devices in an existing network

Before you begin

Review these for a better lab experience

Using the lab guide

Using the lab guide

Using the lab guide

The following window is an example where you can practice:

Launching the Lab Topology

POC Tool (Test Drive UI)

Retrieve device tokens

ssh -l cisco 192.168.150.1 "wget http://64.71.131.100:8888/poctool_labs/csr1000v-ucmk9.16.11.1a.SPA.bin ~

When prompted for password: cisco

2019-08-20 02:11:35 (36.8 MB/s) - ‘csr1000v-ucmk9.16.11.1a.SPA.bin’ saved [392928736/392928736]

/home/cisco: Scheme missing.

[Connection to 192.168.150.1 closed by foreign host]

Step 3: Copy the image to bootflash:

copy scp://cisco@192.168.150.1//home/cisco/csr1000v-ucmk9.16.11.1a.SPA.bin bootflash:

br3-lax-ce#copy scp://cisco@192.168.150.1//home/cisco/csr1000v-ucmk9.16.11.1a.SPA.bin bootflash:

Network Topology Diagram

This diagram can also be viewed by clicking the

Bring up first XE SD-WAN device in DC1

Would you like to enter the initial configuration dialog? [yes/no]: no

User Access Verification

Step 4: Enter "commit" to apply the configuration

Step 5: Install the root cert (copied beforehand).

request platform software sdwan root-cert-chain install bootflash:cacert.pem

dc1-sjc-cedge1#$ware sdwan root-cert-chain install bootflash:cacert.pem

request platform software sdwan vedge_cloud activate chassis-number CSR-00741509-DF53-4346-A1C1-6BFB30701

dc1-sjc-cedge1#request platform software sdwan vedge_cloud activate chassis-number CSR-00741509-DF53-4346-A1

show sdwan control connection-history

show sdwan control connections

Attach the DC devices to a template

dc1-sjc-cedge1 (the device we just brought up in the previous task)

CSR-13C1E07F-88DC-4BD2-98C8-CFFE80B836C4 – to be brought up as dc1-sjc-cedge2

CSR-212D9E25-AD84-4E18-9725-B3CDEABFE1A8 – to be brought up as dc2-fra-cedge1

Step 4: On vManage, click on the up arrow.

Then click "Next"

Step 7: At the bottom of the page, click “Configure Devices”

Bring up remaining XE SD-WAN devices in DC1 and DC2

Step 1: On site DC1-SanJose, console to dc1-sjc-cedge2. If prompted, user/pass is admin /

request platform software sdwan root-cert-chain install bootflash:cacert.pem

request platform software sdwan vedge_cloud activate chassis-number CSR-13C1E07F-88DC-4BD2-98C8-CFFE80B83

On site DC2-Frankfurt, console to dc2-fra-cedge1.

request platform software sdwan root-cert-chain install bootflash:cacert.pem

request platform software sdwan vedge_cloud activate chassis-number CSR-212D9E25-AD84-4E18-9725-B3CDEABFE

Verify data plane and control plane between sites

Select any device and “Device Dashboard”

dc2-fra-cedge1# show sdwan omp routes "| tab"

Peer BGP from non SD-WAN devices in DC

Step 1: On site DC1-SanJose, console to dc1-sjc-core1 and configure the following:

Step 2: On site DC1-SanJose, console to dc1-sjc-core2 and configure the following:

Step 3: On site DC2-Frankfurt, console to dc2-fra-core1 and configure the following:

Try the equivalent CLI:

dc1-sjc-cedge2#show bgp vrf 1

Modify the OMP feature template and verify