ASD - 9.04-v1.32 - Student and Lab Guide

INSTRUCTOR VERSION
Advanced SD-WAN Deployments (ASD)

Student and Lab Guide
for Instructor-Led (221a) and Self-Paced (221b) versions of the course
Version 1.31 - April 27, 2022

REALTIME O R K I N G op R A F T
Advanced SD-WAN Deployments Lab Guide

Version 1.3.1
This course is based on Orchestrator 9.0.4 and ECOS 9.0.6
Date: April 2022

Copyright © 2022 Silver Peak (acquired by Aruba, a Hewlett Packard Enterprise company, in 2020).
All rights reserved. Information in this document is subject to change at any time. Use of this documentation
is restricted as specified in the End User License Agreement. No part of this documentation can be
reproduced, except as noted in the End User License Agreement, in whole or
in part, without the written consent of Silver Peak (acquired by Aruba, a Hewlett Packard Enterprise
company, in 2020).
Trademark Notification
The following are trademarks of Silver Peak (acquired by Aruba, a Hewlett Packard Enterprise
company, in 2020): Silver Peak SystemsTM, the Silver Peak logo, Network Memory™, Silver Peak
NX-Series™, Silver Peak VX-Series™, Silver Peak VRX-Series™, Silver Peak Unity EdgeConnect™, Silver
Peak Orchestrator™, Aruba EdgeConnect™, Aruba Orchestrator™, and Aruba Boost™. All trademark
rights reserved. All other brand or product names are trademarks or registered trademarks
of their respective companies or organizations.
Warranties and Disclaimers
THIS DOCUMENTATION IS PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER
EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. SILVER
PEAK (ACQUIRED BY ARUBA, A HEWLETT PACKARD ENTERPRISE COMPANY, IN 2020). ASSUMES
NO RESPONSIBILITY FOR ERRORS OR OMISSIONS IN THIS DOCUMENTATION OR OTHER
DOCUMENTS WHICH ARE REFERENCED BY OR LINKED TO THIS DOCUMENTATION. REFERENCES
TO CORPORATIONS, THEIR SERVICES AND PRODUCTS, ARE PROVIDED “AS IS” WITHOUT
WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED. IN NO EVENT SHALL SILVER PEAK
(ACQUIRED BY ARUBA, A HEWLETT PACKARD ENTERPRISE COMPANY, IN 2020). BE LIABLE FOR
ANY SPECIAL, INCIDENTAL, INDIRECT OR CONSEQUENTIAL DAMAGES OF ANY KIND, OR ANY
DAMAGES WHATSOEVER, INCLUDING, WITHOUT LIMITATION, THOSE RESULTING FROM LOSS OF
USE, DATA OR PROFITS, WHETHER OR NOT ADVISED OF THE POSSIBILITY OF DAMAGE, AND ON
ANY THEORY OF LIABILITY, ARISING OUT OF OR IN CONNECTION WITH THE USE OF THIS
DOCUMENTATION. THIS DOCUMENTATION MAY INCLUDE TECHNICAL OR OTHER INACCURACIES
OR TYPOGRAPHICAL ERRORS. CHANGES ARE PERIODICALLY ADDED TO THE INFORMATION
HEREIN; THESE CHANGES WILL BE INCORPORATED IN NEW EDITIONS OF THE
DOCUMENTATION. SILVER PEAK (ACQUIRED BY ARUBA, A HEWLETT PACKARD ENTERPRISE
COMPANY, IN 2020). MAY MAKE IMPROVEMENTS AND/OR CHANGES IN THE PRODUCT(S)
AND/OR THE PROGRAM(S) DESCRIBED IN THIS DOCUMENTATION AT ANY TIME
Aruba, A Hewlett Packard Enterprise Company

6280 America Center Dr
Sunnyvale, CA 94089
http://training.silver-peak.com
ASD 9.04-9.03 v1.3 Student & Lab Guide Do Not Replicate Page 2 of 175
Table of Contents
LAB 1: LAB FAMILIARIZATION AND LICENSING DEVICES ............................................... 4
REVIEW #1: PATH AND ROUTE SELECTION & MONITORING ................................................. 18
REVIEW #2: POLICIES ................................................................................................................. 20
REVIEW #3: LOOPBACK INTERFACES ...................................................................................... 21
REVIEW #4: HIGH AVAILABILITY ................................................................................................ 22
LAB 2: CREATE ORCHESTRATED LOOPBACKS ............................................................. 23
LAB 3: CONFIGURING EDGEHA ........................................................................................ 29
REVIEW #5: INTERNET BREAKOUT AND TRAFFIC CLASSIFICATION.................................... 39
REVIEW #6: IP SLA ...................................................................................................................... 40
LAB 4: LOCAL INTERNET BREAKOUT .............................................................................. 41
REVIEW #7: BGP .......................................................................................................................... 71
LAB 5: BGP .......................................................................................................................... 72
REVIEW #8: OSPF ........................................................................................................................ 87
LAB 6: OSPF ........................................................................................................................ 88
REVIEW #9: ROUTE MAPS .......................................................................................................... 97
LAB 7: ROUTE MAPS .......................................................................................................... 98
REVIEW #10: REGIONS ............................................................................................................... 118
LAB 8: REGIONS ............................................................................................................... 120
REVIEW #11: SECURITY FEATURES ......................................................................................... 136
REVIEW #12: ZONE BASED FIREWALL ..................................................................................... 137
LAB 9: ZONE BASED FIREWALL ..................................................................................... 138
REVIEW #13: ASYMMETRY & FLOW REDIRECTION ................................................................ 153
LAB 10: SEGMENTATION (VRF) ....................................................................................... 154
APPENDIX A: CONNECTING TO READYTECH FOR INSTRUCTOR-LED TRAINING (ILT)
STUDENTS ............................................................................................................ 167
APPENDIX B: SOLUTIONS TO COMMON ISSUES ..................................................................... 168
APPENDIX C: 221 – ASD 9.X LAB TOPOLOGY ........................................................................... 174
APPENDIX D: TABLE OF USERNAMES AND PASSWORDS ..................................................... 175
LAB 1: Lab Familiarization and Licensing

Devices
Overview
In this lab you will familiarize yourself with the lab environment and license the Orchestrator
and the appliances and register them with the Silver Peak Cloud Portal.
Objectives
© Familiarize yourself with the lab environment.

© Verify Landing Desktop deployment by reviewing the virtual machines are all setup
© Confirm Orchestrator has deployed without any critical errors
© Run a script to license the Orchestrator and EdgeConnect appliances
IMPORTANT LAB NOTES:

a. The course lab instructions are precise.
b. Follow the Step-by-Step Instructions.
c. Please read all notes below the lab steps.
£ This will help you avoid common error conditions.

d. Screenshot examples will follow the written instructions, however,
£ Do not rely on screenshots for actual configuration.

£ If written instructions and the screenshot differ, follow the written
instruction
Instructor-Led (221a) vs Self-Paced Instructions
PLEASE NOTE: This lab guide is used for both the Instructor-Led Course (221a) and
the Self-Paced Course (221b).
Whenever instructions are specific to each course, you will see them separated in a Table as
shown below:
221a: INSTRUCTOR-LED STUDENTS 221b: SELF-PACED STUDENTS
Follow these instructions if Follow these instructions if

you are on Zoom with an you are watching the
INSTRUCTOR SELF-PACED VIDEOS
Task 1: Review Lab Topology
1. You can view the PDF of
the Lab Topology directly
from the Landing Desktop
2. The 3rd tab in Chrome
also opens the same file
by default
Task 1: Access the ReadyTech Lab Environment
221a: INSTRUCTOR-LED STUDENTS 221b: SELF-PACED STUDENTS
Connect to the ReadyTech Connect to the ReadyTech

Instructor-Led portal Self-Paced portal
1. The instructor will be generating lab 1. Follow the instructions from the Self-
codes for you and will paste them into Paced document “Accessing Remote
the Zoom Chat. Labs for Self-Paced Students”
a. Write your access code down a. This can be found in the
here: RESOURCES tab of the course
2. From your computer, navigate to

https://silverpeak.instructorled.training/
a. Appendix A has detailed
connection instructions if needed
Task 2: Log into the Landing Desktop

2. Click on the login panel.
£ Username: Administrator
£ Password: Speak-123
Note there are various viewing options from the Desktop drop-down menu such as Best fit, Scale
to fit, Detach window and Full screen mode. Try which works best for your display.
Other Lab Notes:
a. Use the Esc key to exit Full Screen mode.
b. If you need to enter commands in a VMware console window,

and you find that incorrect characters are displaying, you might
need to use the onscreen keyboard.
1) Use the menu shown and choose Enable Viewer Toolbar.
2) From the viewer toolbar, enable the onscreen keyboard.
3) Drag the keyboard over the console window. It may be
necessary to position the keyboard so the letter you want
to type is directly over the active area of the console
window.
Task 3: Verify all of the Virtual Machines are Set Up
3. On the Landing Desktop desktop, open Google Chrome by double-clicking on its

icon in the Task Bar or on the desktop.
4. A security screen might appear with

“Your connection is not private”:
a. This is the 1st browser tab for

VMware ESXi
b. Click Advanced.
c. Click Proceed to esxihost (unsafe).
£ You may need to scroll down a bit to see this one.
5. Login to VMware using the following:
£ Username: root
£ Password: Training1!
6. Click on Log in
7. At the top-left, if not yet expanded, Click on the
Navigator button
8. Below that, Click on Virtual Machines button.
a. You should see the number 18 to the right of it

in a grey box.
b. In pane to the right, Click on the Virtual machine
column of the table to Sort it until the first device listed is
Landing_Desktop.
9. Confirm the following:
a. 18 Virtual Machines are shown.
b. All Virtual machines are in the state

c. Confirm the following IP addresses are displayed
1. 192.168.1.4 is the IP address for ECV-1
6. 192.168.1.254 is the IP address for Orchestrator
221a: INSTRUCTOR-LED
221b: SELF-PACED STUDENTS
STUDENTS
If any of your VMs are not up, Take a break, then recheck the list in a little while.
inform the Instructor. Remember that a full deployment can take 3+ hours.
If the lab has not fully deployed after 4 hours, contact

ReadyTech support.
Click on Support in the navigation bar at the top of your

lab environment, or see the Appendix called Getting
Support at the end of this document for contact
information for ReadyTech.
If some are in the state, turn them on one at a time.
10. Select the checkbox next to

it’s name
11. Click Power on or the
button if needed
12. Repeat for any additional
VMs that need to be
Powered On
Task 4: Confirm Appliances have been Preconfigured
13. From the Chrome browser, Click on the

2nd tab, Orchestrator Login (or Privacy error) to Log into the Orchestrator.
14. Another security screen may appear

(like with the esxihost above) with
“Your connection is not private”:
a. Click Advanced.
b. Click Proceed to 192.168.1.254 (unsafe).
Again, You may need to scroll down a bit to see this one.
15. The login screen for Orchestrator will

then be displayed
16. Log into Orchestrator
£ Username: admin
Do this Step only if a security screen appears with

“This site can’t be reached”, or you cannot Log into the
Orchestrator,
a. If so, the VM may need to be rebooted or started
1) Return to VMware.
A) Select the checkbox next to it’s name
B) Click Power off button
C) Wait a few seconds
D) Click the Power on button
E) After about 4 minutes, refresh your browser window to make sure the
Orchestrator login screen is displayed.
Note: This would be a good time for a quick break
Refresh the browser as needed until you see the login screen on the Orchestrator tab in
your browser. Again, this can take several minutes after the VM reboot finishes while
background tasks bring up the Orchestrator web server.
17. If any software update or maintenance messages that

may pop up, you can close them.
18. Verify the following:
a. 3 Sites with the 0 appliances listed
£ Site 1: Singapore
£ Site 2: Mumbai
£ Site 3: Santa Clara
b. Preconfigure Appliances tab is open listing all 5
(five) devices
£ Their Status should be: Pending Discovery
c. The upper right side will not show any alarms
Task 5: Access the Landing Desktop with this Windows Navigation Tip
19. You can get to the desktop quickly by
Clicking on the desktop icon next to the
magnifying glass (beside the Windows
Start button).
20. This is a toggle button which will allow you to easily hide/unhide active windows to
view the lab topology.
21. Click on the icon to display the Landing PC Desktop
Task 6: Run the Setup Script

a. From the Desktop, double-click 221 – ASD Setup ONCE to run the
setup script.
æ Do not run this twice. It may take a few seconds to start.

You can only run this script once. It is disabled after the first run.
22. The script runs and generates a Command Prompt window.
a. Note: The script may take a several minutes to run.
23. When the script completes, it will display the ASD Lab 1 – Setup Log.txt file.
24. All the steps should show Success
25. Click on the black Command Prompt window and Press any key to continue.
a. Close the Notepad file.
Task 7: Go back to the Landing Desktop Chrome browser to verify the

registration
© For our lab, you need to do all configuration and steps in this Student and Lab
Guide on the Student Landing Desktop.
© If you haven’t noticed yet, the Windows Task Bar and application windows
are Orange, to help indicate you are actually working on the Landing Desktop
26. Return to Chrome on the Landing Desktop
27. Click on the Silver Peak Unity

Orchestrator tab (2nd one).
This is a visual clue that you are on the

Landing Desktop and not your own PC.
28. The Appliances Discovered button will appear,
but DO NOT click on it. It will disappear in a
moment.
29. Select the Preconfigure Appliances tab
30. Refresh the display by Clicking the refresh

icon next to Export
31. The Preconfiguration process will take about 5-15 minutes to complete.
Continue on with the next steps…

a. After a few minutes, the Preconfigure Appliances tab should now list all 5 (five)
device status as Finished
b. They may have various Alarm boxes and blue cloud icons next to each ECV in
Tree View
During the next 10+ minutes, Tree View will show the devices going through various
alarms from Cyan to Gold to Red. This is normal as the devices are establishing tunnels.
32. The 3 Sites will contain the following in Tree View:
£ Site 1: Singapore: ECV-1

£ Site 2: Mumbai: ECV-2, ECV-3
£ Site 3: Santa Clara: ECV-4, ECV-5
33. There should not be any tunnel errors
NOTE: If you see you can ignore it and move on.
34. After 10+ minutes, appliances will show Finished under the Status column, Close the
Preconfigure Appliances Tab
Task 8: Verify the Orchestrator can reach the Cloud Portal and is
Registered
35. Open the Cloud Portal Licensing tab
from the Search Menu bar next to the
Support tab: type lice
a. Click on the option for Orchestrator

à Orchestrator Server à Licensing
à Cloud Portal
Note: the Host may have been changed to portal.silverpeak.cloud which is valid
also.
36. It should show
£ Yes next to Registered

£ HTTPS Connected
£ WebSocket Connected
37. Click Generate New Key to update your Account

Key.
38. Click Generate New Key and Distribute
39. Click on the X to close the yellow success message
40. Click Close on the Cloud Portal Licensing window,
Task 9: Review the basic layout in Orchestrator

41. You are managing the 5 appliances that appear in the Tree View.
a. 3 Sites – Singapore, Mumbai, & Santa Clara
42. View Business Intent Overlays
a. Open the BIOs tab –

Configuration à
Overlays & Security à
Business Intent Overlays
£ We are using the 4 default overlays.
43. Click on Apply Overlays
£ Notice that all the appliances have all the overlays applied, except for ECV-2
which is missing one.
£ We will add the BulkApps overlay to ECV-2 in the next lab
REVIEW #1: Path and Route Selection &

Monitoring
1) What are the 3 protocols supported by Silver Peak appliances for exchanging routing
information?
2) T/F – Silver Peak can exchange routes with a Cisco Router via Subnet Sharing
3) T/F – In a subnet table, all else being equal, the route with the lowest metric is
preferred.
4) Will the packet to 10.110.30.5 be sent to appliance A or B?

10.110.0.0/16 Metric 40 Learned from A
10.110.30.0/24 Metric 50 Learned from B
5) Will the packet to 10.110.30.5 be sent to appliance A or the local interface?

10.110.30.0/24 Metric 40 Learned from A
10.110.30.0/24 Metric 50 Auto – (added by system)
6) Is it possible for a static route to only be applied to LAN-to-WAN traffic? If so, which
tag would it have?
7) T/F – It is possible for an appliance to advertise a route that it doesn’t actually use to
route traffic.
8) How can you determine if an appliance has a route to a destination without testing it
with traffic?
9) T/F – You should always use Reset All in the flow table to make sure a connection
gets reset
10) T/F – “Inbound’ traffic is coming from the LAN into the Silver Peak
11) T/F – An appliance uses the management routing table to route traffic between two
end devices at different sites
12) How do you make sure an appliance knows all the external IP addresses that can be
used to reach the Orchestrator
REVIEW #2: Policies

1) What are the Four Policy types and what do they do?
2) T/F: Built in optimization policies are in the 10,000 range and will be applied to
unboosted traffic.
3) What numeric range do Overlay created policies fall in?
4) What is the default rule number in any policy map?
5) Why would you create a manual route policy?
6) Is traffic matching an overlay that is boosted always treated exactly the same? If not,
why?
7) What is the default action for traffic flowing between two different security zones?
8) T/F: A built in route policy rule with a priority of 65506 will never be matched if there
is a manual policy with a priority of 999 that matches the traffic
REVIEW #3: Loopback Interfaces

1) T/F: Loopback interfaces are a hardware option only available on physical appliances
2) T/F: Loopback interfaces cannot be configured directly on appliances
3) Can more than one group of orchestrated interfaces be created with different interface
and security zone labels?
4) What must orchestrated loopback groups have in common?
5) If you decide to use a loopback interface for management, what do you need to do for
this to work properly?
6) Where will a loopback interface used to manage the appliance look for routes to direct
self-originated traffic?
REVIEW #4: High Availability
1) T/F – Local Internet breakout is not supported with H/A
2) T/F – Flow Redirection is not supported with Edge H/A
3) If appliance B were to lose its connection to the internet, could it route traffic to
appliance C via MPLS?
4) See animation – If appliance C were to lose its connection to the Internet, could it still
connect users to Office 365 via the one on device B (assuming it’s Internet connection
is up)?
5) When troubleshooting, what do you need to remember fortraffic that is going from
appliance A, across the HA interface to local internet breakout on appliance B?
6) If A and B both had Internet connections on the WAN, and one of the WAN
connections failed, would connections that had to move to the other appliance be
reset if: C
a) They were going in a tunnel to a server
attached to another Silver Peak peer?
Internet
b) They were broken out locally on the

remaining internet connection? MPLS
HA
Link
VRRP
A B
VIP
LAB 2: Create Orchestrated Loopbacks

Overview
This short lab illustrates how easy it is to create and automatically address loopback
addresses on all the appliances in your network using Loopback Orchestration.
© Orchestrator will create the interfaces and assign /32 addresses

from a user configured range. Each Appliance will then announce
a /32 route to its loopback into the SD-WAN fabric via subnet
sharing.
© These loopbacks can be used for many things including replacing

the management interfaces (which we will not do in this course).
We will use them to test connectivity from time to time in our lab,
useful because it creates a unique path to each appliance that
doesn’t overlap with any other address space.
Objective
© Learn how to create and distribute loopback addresses and use them to test
connectivity in a later lab.
Task 1: Clear Alarm Messages:

After about 30 minutes, all 5 sites should be configured with tunnels built to them with no
alarms, as shown above.
1. Go to Monitoringà à Summary à à Alarms

2. If you see either of these two alarms:
a. “tunnel state is down”

b. “Next-hop unreachable”
© 221a Students: Notify the instructor.
© 221b Students: Send an email to sp-training@hpe.com for assistance.
3. Click Select All in the upper right
of the Alarms page
4. Click Clear
5. Click Clear only
6. Close the Alarms tab
Task 2: Configure a Loopback Orchestration Range

7. In Orchestrator, select all appliances in in Tree View.
8. Go to the Loopback Orchestration tab

Configuration à Networking à Loopback
Orchestration.
9. Click on +Add Loopback Interface
10. Click on Add
11. Click on the address range 10.0.0.0/24 in the Loopback Pool
NOTE: By default, the 10.0.0.0/24 subnet is added for the Orchestrator to allocate
loopback addresses from. In 98% of cases you DO NOT want to accept this default
because that subnet is often already in use, so remember to change it to a range
appropriate for your network as demonstrated in this step, if needed.
12. Change the range of the Loopback Pool to 10.111.111.0/24 as shown
13. Click Update.

Important: There can be only one loopback
pool. If you add a second group of loopback
interfaces (e.g. with different security zones
or labels) it must use the same pool. If you
add a second group with a different pool, it
will change the first group’s addresses too!
14. Scroll to the bottom of the page and

Click Save.
15. In the upper right, Click on

Orchestration ETA
16. Watch and wait for Orchestration to complete, then close the window.
17. You should see Applied successfully appear at the bottom of the screen.
18. Click on the X to close the message.
19. Now open the Configuration à Networking à Loopback Interface tab.
Notice that the Orchestrator has created a loopback interface on every machine from the
configured range, and assigned a /32 IP address
As you can see, a loopback interface named lo20000 has been created on every
appliance and an IP address has automatically been assigned from the configured range.
Your addresses may have been assigned differently than shown here. The use of the
20,000 range for address numbering is consistent with other orchestrated objects like
route polices which fall in the 20,000 range.
Note: You cannot edit the assigned address for orchestrated interfaces, although it is
possible to manually add additional loopback interfaces with manually assigned
addresses.
20. Write down the loopback address you created for each appliance.
a. They will most likely NOT be in the same order as the appliance name.
b. For your reference enter them in one or Appliance Loopback Address Table
both of the following:
ECV-1
£ This table to the right
ECV-2
ECV-3
ECV-4
ECV-5
£ In the ASD-Topology & Logins PDF on the Landing PC

Desktop
Task 3: Test reachability between two of the loopback interfaces
21. Right-click on ECV-1 in Tree View and select

Appliance Manager
22. On the new tab that opens for ECV-1, go to

Maintenanceà Tools à Ping à Traceroute
23. Consult the table you filled in above to get the

loopback addresses of ECV-1 and ECV-5
a. Ping ECV-5’s loopback address from ECV-1’s

loopback address.
b. Ping between them 5 or 6 times then stop the ping
£ IP/Hostname: <ECV-5’s loopback IP address>
£ Options: -I <ECV-1’s loopack IP address>
LAB 3: Configuring EdgeHA

Overview
In this lab you will configure EdgeHA on two of the appliances. EdgeHA allows two
appliances to share each other’s WAN connections. Any traffic on one device that needs to
be routed to the WAN on the other device, goes over an HA connection between the two
appliances.
This HA connection uses a data path interface (LAN or WAN, not management port) on each
of the devices to establish a connection between them, and traffic is routed over this
connection.
Objectives
© Learn to configure an EdgeHA connection between appliances. Observe the

connections made between the devices and the tunnels built across the connection.
Task 1: Enable HA on ECV-2 and ECV-3

In this Task, we’ll edit the deployments for ECV-2 and ECV-3 to remove unneeded interfaces
and enable HA mode.
Note: EdgeHA mode can only be enabled from the

Orchestrator, not from the appliances.
1. Right-click on ECV-2
2. Select Deployment.
3. Check the box for

EdgeConnect HA.
a. Close any pop up

help screens that
display.
4. Select ECV-3 as a Peer.
5. Configure the needed changes for EdgeHA mode
a. Select wan2 for the HA Link on ECV-3
b. Click the ∑Calc link.
£ This will update the Total Outbound and Total Inbound at the bottom of the
page to 6,000 kbps. Each appliance needs to be able to handle the total
throughput for the outbound interfaces on both machines since they both have
access to all 3 WAN interfaces.
c. On ECV-2 near the top of the page, change the boost amount to 6,000 kbps
£ This is the total outbound bandwidth for both machines. In our case, we want to
be able to boost all the traffic on either device. We will update the boost amount
on ECV-3 in a moment – it must be done from ECV-3’s deployment screen.
6. Click Apply.
© Notice that in Tree View:
§ ECV-2 and ECV-3 show an HA link
§ Red critical alarms may appear until Orchestration

completes.
7. Right-click ECV-3 in Tree View
8. Select Deployment
9. Update the boost amount for ECV-3.

Note: When you view the same EdgeHA deployment by
right-clicking on ECV-3, that device (ECV-3) is now on top!
a. Change the boost amount on ECV-3 to 6,000

(now on top)
b. Click Apply
Note: Although we’ve applied enough boost licensing to cover all interfaces in our lab,
since LTE is strictly backup, and it wouldn’t be used unless the other interfaces were
down, you probably wouldn’t license it for boost in a production environment.
Task 2: Apply Bulk Apps Overlay to ECV-2

We want all the appliances to be part of all the overlay networks.
10. In Orchestrator, in Tree View, select all appliances
11. In Orchestrator, go to Configuration à

Overlays & Security à Apply Overlays
© Notice that ECV-2

doesn’t have the
BulkApps overlay
applied.
12. Select only ECV-2 in Tree View
13. Apply the BulkApps Overlay
a. Click the Add box

next to BulkApps
b. Click Apply
c. Click Apply Overlays
Task 3: Change the Site Name for ECV-2 and ECV-3
© In order to keep unnecessary tunnels from being built between the two devices in the
HA pair, you should make the site name the same on each appliance.
© Orchestrator will not build tunnels between two devices with the same site name.
14. Change the site name for ECV-2
a. Right-click on ECV-2 in Tree View and select
System Information
b. Click on the System Settings button
c. Change the Site Name to Mumbai

d. Press enter
e. Click Apply
15. Change the site name for ECV-3 the same way
a. Right-click on ECV-3 in Tree View and select System Information
b. Click on the System Settings button
c. Change the Site Name to Mumbai

d. Press enter
e. Click Apply
Task 4: Observe device status

16. In Tree View, Click on Site 2 – Mumbai to select only
ECV-2 and ECV-3.
17. In Orchestrator, go to the Deployment tab:

Configuration à Networking à Deployment
a. At the top left, click the Details button
b. Click refresh if needed. It may take a minute or two for the VLANs to get built.
c. Click on the top of the HA Interface column (you may need to scroll the browser
window to the far right) to Sort the interfaces by HA status (Hint: if you Click a 2nd
time, all the HA interfaces will come to the top of the list)
d. Notice that on ECV-2 and ECV-3, VLAN interfaces have been auto configured
(Interface column). VLANs 100, 101 and 102 are in use (e.g. wan1.102 on ECV-2).
One VLAN is in use for each WAN interface passthrough tunnel.
e. IP addresses have automatically been configured in 169.254.1.x/30 subnets.
f. Both ECV-2 and ECV-3 show interfaces with MPLS, LTE and Internet labels, one
making use of the physical wan0 and wan1 connections, and the other making use
of the HA connections (wan2.102, wan1.101, and wan1.100).
© Remember that only ECV-2 has a physical connection to the MPLS network, even
though ECV-3 shows MPLS1 on the wan2.102 interface. This is because a logical
connection has been created across the HA link so ECV-3 can access MPLS through
ECV-2. Similar connections have been made so ECV-2 can access the INET1 and
LTE on ECV-3.
7) Which interface on ECV-2 is used to access LTE? _________ INET1? _________
18. On the Orchestrator, open the

Interfaces tab Configuration à
Networkingà Interfaces
19. Click Dynamic.

The VLAN interfaces dynamically created by overlay manager show up here also.
Task 5: Observe Tunnel Formation

20. In Orchestrator, go to the Tunnels
tab Configurationà Networking à
Tunnels à Tunnels
21. Click on Underlay
22. Sort on Local IP:Port by Clicking on the column heading twice to bring the highest
numbered IP addresses to the top if needed.
Note all the tunnels with 169.254.1.x IP addresses at the top. These are tunnels built
across the HA interfaces to machines across the network, but they are reachable via the
other HA appliance’s WAN interfaces and are terminated on the local HA interface IP
address.
Also note the Remote IP:Port column to the right. This shows where the remote ends of
the tunnels are being terminated. Examine your topology diagram. You’ll see these are
WAN interface IP addresses on other appliances.
23. Click on Passthrough
24. Again Sort on Local IP by Clicking twice on the Local IP column heading to bring
the HA tunnels to the top.
Note that there are passthrough tunnels built for all the overlays terminating on the HA
interface addresses. There is one PT (passthrough) tunnel for each overlay to each WAN
interface on each of the machines in the HA pair.
If you are doing local internet breakout for traffic going over the HA interface to reach a
WAN interface on a neighboring HA device, it may use one of these passthrough tunnels.
We’ll be doing local internet breakout in a later lab.
© You should have answered that there is not a remote IP. This is because a
passthrough tunnel isn’t really a tunnel.
The way the feature was coded, in the early days, it utilized the same mechanisms as
the tunnels which is why it is inaccurately referenced as a tunnel.
© So, keep in mind, Traffic transiting a passthrough tunnel will be directed to the next
hop router on the local interface where the passthrough tunnel connects to the WAN
or LAN.
25. Close any tabs from this lab if you want to minimize clutter in your Orchestrator view.
REVIEW #5: Internet Breakout and

Traffic Classification
1) T/F – An EdgeConnect can snoop DNS lookups and cache the results for domain
based packet classification.
2) T/F – As part of its 1st packet classification strategy, Silver Peak appliances maintain
a cache of millions of domains and addresses that is dynamically updated.
3) What is used to determine internet reachability, and whether breakout should be

attempted by the appliance?
a b
4) What is the difference between the Policy Order A and B as shown?
5) T/F – It is necessary to choose at least two primary labels to load balance breakout
traffic across multiple internet service providers?
6) What is the difference between Waterfall and Balanced link Selection?
7) How does an appliance determine if traffic should be eligible for Local Breakout
(assuming all links are up)?
REVIEW #6: IP SLA
1) Can an IP SLA cause subnet sharing to stop if an interface goes down?
2) T/F – In an IP SLA Ping Address List with 3 destinations, if any one of the
destinations becomes unreachable the IP SLA will be marked DOWN, and the Down
Action will be performed.
3) T/F – It’s possible to configure an IP SLA to monitor reachability of a critical server via
Ping, and raise or clear an alarm, without taking any other action on the appliance.
4) What should you use if the website you’ve chosen to monitor for reachability blocks
ICMP traffic?
LAB 4: Local Internet Breakout

Overview
We have some traffic of different types destined
to hosts on the Internet. We don’t want to
backhaul all the traffic through the data center at
Site 3, since this can add latency and use
unnecessary bandwidth on our WAN links back
to the data center.
© The solution is to configure local Internet

breakout for these services through a
passthrough tunnel using the interface
connected to the Internet.
© Some of the traffic that matches the

DefaultOverlay will be backhauled to Site
3 where it could be inspected by a
firewall if needed.
© Our trusted host is UBU-1

(in the upper right corner of the diagram).
© Because the 10.110.x.x network is

isolated, not connected to the Internet, we use UBU-1 to simulate access to systems
on the Internet.
Objectives
© Learn to configure a Business Intent Overlay to break out traffic that doesn’t match
the subnets internal to your network.
Task 1: Test connectivity to a site in your network

1. In Orchestrator, select all appliances in Tree View
2. Go to the Flows tab.

Monitoring à Bandwidth à à
Flows à Active and Recent Flows
3. Click the Clear button to eliminate any current filters.
For instance, in this example Asymmetric is selected and we want to clear that filter
We’ll return to the flows table in a moment after generating some traffic.
4. From the taskbar of the Landing Desktop, launch the Remote

Desktop (RDP) client taskbar icon (also available on the Landing
PC’s Desktop)
a. Select TG-1011 for the Computer
b. Click Connect
5. Click on the for “Do you want to connect

despite these certificate errors?”
6. Click Yes
7. Click Ask Me Later
8. Ignore and close any Windows Activation,

warning messages, reboot reason messages etc.
9. Ping the LAN side addresses of ECV-2 and ECV-4
a. On TG-1011’s taskbar in the RDP window, open

a command prompt window.
£ You may need to scroll down in the RDP
window to see the taskbar.
10. Refer to your Loopback IP address table from the

end of Lab 3; Task 1 or on your Topology
Diagram if you recorded it there
a. Ping the loopback address on ECV-2
(10.111.111.x as you
recorded in your loopback address
table earlier)
b. Ping the loopback address on
ECV-4
Both should be reachable and show
replies.
11. On the Orchestrator. View the flows in

the flow table.
a. Click the Refresh icon.
You should see something like this:
Note: If you don’t see anything, use the clear button to clear any preselected filters in the
flow table, then refresh your view.
Task 2: Test connectivity to a site on the Internet

12. Ping UBU-1 from TG-1011 per the steps below:
a. Refer to your topology diagram to see where UBU-1 and TG-1011 exist in relation
to each other in the network.
b. Ping UBU-1 (11.1.1.11). We know from the network topology that the ping will
have to go through ECV-1.
13. Look at the flow in Orchestrator on the flows tab. Refresh if needed
a. In the Search field, type 11.1.1.11.
14. Refresh the flows as needed
15. Look at the outbound tunnel in the flow table – it says Policy Drop.
1) Which Overlay is the flow hitting? __________________________________
16. Open the flow detail by Clicking on the icon in the Detail column for the flow
The flow matched the Default Overlay, as we saw above, and was dropped due to
overlay internet policy. We will examine what that means below.
You can see it’s been classified as an Internet flow, but the WAN routing is Policy drop
17. Close the flow detail
18. Let’s look at the routing table on ECV-1.
a. Select only ECV-1 in Tree View
b. Go to the routes tab: Configuration

à Networking à Routing à Routes
19. In the Search bar, type 11.1.1.
© Note there is no route to the destination (11.1.1.) in ECV-1’s routing table.

20. Let’s summarize what we know:
£ There was no route to the 11.1.1.0 subnet known to ECV-1.

£ Yet, it was identified as an Internet Flow.
5) How did the appliance decide it was external?
Task 3: Let’s examine how routes are determined to be internal or

external.
21. Open the Internet Traffic Definition
tab: Configurationà Overlays &
Security à Internet Traffic
Note: The menu selection is misleading; it actually shows you a list of networks that are
considered “Internal”, not “Internet Traffic”
External networks are defined by because they are not on the list. Any subnets NOT
matching those on this list are considered external Internet traffic.
22. View the Internal Subnets list.

11.1.1.0 is not in the list of internal subnets, so it is
considered external.
6) Why wasn’t it sent out of one of the WAN interfaces

as local internet breakout traffic?
As we saw in the flow detail, the flow was dropped due to
overlay internet policy. Let’s explore what that means
more deeply in the next task.
23. Close the Internal Subnets list.
Task 4: Observe Current Overlay Configuration
© Remember that our ping to the device on the internet matched the DefaultOverlay, so
we’ll start by looking at that.
24. Open the Default Overlay by going to
Configuration à Overlays & Security à
Business Intent Overlays
25. Click on the Breakout Traffic to Internet & Cloud Services section of the
DefaultOverlay
26. You should see this
In the Preferred Policy Order column, the only policy is Backhaul Via Overlay
Internet breakout (Break Out Locally) is not implemented. It is still in the Available Policies
column.
© The flow was dropped because of this. As you can see, if backhaul fails, the policy
below it in the Preferred Policy order is Drop.
27. Scroll down the window and Click Cancel to close the DefaultOverlay configuration
panel.
Task 5: Configure Local Internet Breakout.
© We want to allow direct internet breakout from the branches for traffic matching the
RealTime, CriticalApps, and BulkApps overlays.
§ However, for the DefaultOverlay, we want to backhaul traffic from Sites 1 and 2
destined for the Internet to our data center at Site 3 (where there is an upstream
firewall on the internet link)…
§ Unless the connections to the data center are down. In that case, we want to allow
Sites 1 & 2 to break out locally using their own local internet connections for
DefaultOverlay Traffic.
28. Return to the Business Intent Overlays tab

Internet breakout is not configured for any of the overlays. With Backhaul as the only
choice, it means that traffic can only be sent to other sites with Silver Peak appliances.
29. Configure the RealTime Overlay
30. Click on the Backhaul policy icon for the RealTime overlay. This will bring up the
Breakout configuration screen for this overlay.
31. Drag the Break Out Locally

built in policy to the Preferred
Policy Order column above the
Backhaul Via Overlay policy.
It should now look like this:
32. The breakout interface configuration panel

should appear on the right.
a. Drag the INET1 label into the Primary
column.
b. This enables the INET1 labeled interface
to be used for internet breakout.
33. Click OK.
34. Configure Internet Breakout for the CriticalApps overlay the same way
a. Click OK to save.
35. Configure Internet Breakout for the BulkApps overlay the same way
a. Click OK to save.
THIS NEXT ONE IS DIFFERENT!

36. Configure Internet Breakout for the DefaultOverlay.
Remember we are going to backhaul internet traffic matching the DefaultOverlay unless
links to the data center are down so the Preferred Policy Order needs to be different
a. Drag the Break Out Locally policy and place it below the Backhaul Via Overlay
as shown below:
Break Out Locally is below Backhaul Via Overlay, unlike the previous BIOs. This should
cause traffic that matches this overlay to be backhauled (even internet breakout traffic) as
a 1st choice, and only broken out locally as a 2nd choice if there is no route or path to
backhaul it.
Note the changes to the Breakout Traffic to Internet & Cloud Services section.
The gold color boxes surrounding the new configuration selections on the right means the
changes are not yet applied.
37. Click Save and Apply Changes to Overlays in the upper left of the Business Intent
Overlays tab.
38. Confirm the changes, Click Save
39. In the upper right of the menu bar, a note

about estimated Orchestration time will
appear.
40. Click on it.
41. A list of the pending changes will pop up.

This is useful for monitoring progress. When the
orchestration for each site is complete, the list will go
blank. You can close it after the list is blank and all
changes are complete.
Task 6: Test Local Internet Breakout.

Now we will try to retest internet breakout by pinging UBU-1 on the Internet.
42. After the orchestration is complete in the step above, try the ping again.
a. Return to the RDP window you opened in Task 1 this lab for TG-1011.
b. Use the CMD (command prompt) window to retry the ping to 11.1.1.11
43. The Ping still fails,
what’s going on?
44. Return to the Orchestrator. Notice that light blue alarms have appeared next to each
of the appliances.
45. Mouse-over one of them…
Each of the Overlays uses an IPSLA to make

sure the Internet is up before trying to
breakout the traffic locally. The alarms are
saying the Internet is not reachable.
Let’s see why…
46. Open the IPSLA tab:

Configuration à TEMPLATES &
POLICIES à TCAs à IP SLA
47. View the IPSLA rules

Note all the rules are marked Down.
48. Click on the Monitor field for one of the rules. This will bring up a resizable Window
with information about the rule.
49. The heading tells us this was automatically generated by Overlay Manager.
The rule says it is testing connectivity by pinging sp-ipsla.silverpeak.cloud.
This destination is not actually reachable via our lab network. Instead we should be
pinging the IP addresses of the next hop routers (or WAN emulators in our case).
If you look at your topology diagram, these addresses are 10.110.104.1, 10.110.109.1 and
10.110.116.1.
50. Close the dialog box with IPSLA information in it
Task 7: Configure the IPSLA Rules with Correct Addresses
51. Return to the

Business Intent
Overlay tab
52. Click on any of the
breakout policies for
any Overlay
All overlays use the
same configuration
source, but in the
screenshot, we clicked
on the one for
CriticalApps.
53. Click the pencil icon next to Break Out Locally Using
These Interfaces
54. Delete sp-ipsla.silverpeak.cloud

55. Edit the rule to include 10.110.104.1, 10.110.109.1 and 10.110.116.1
a. Separate the addresses by
commas with no additional spaces.
NOTE: As mentioned above, this is a

global setting that affects all overlays.
56. Click Save
57. Click OK to close the Overlay

Configuration dialog window
58. Observe the Orchestration status like

you did above
59. View the status of the IPSLA rules after

Orchestration is complete
60. Return to the IPLSA tab
61. All the rules should have a Status of UP.
62. All the “ WARNING An IP SLA monitor…” alerts

should have disappeared
a. Use the refresh button if needed.
63. Return to the RDP

window you have
open on TG-1011
64. Retry the ping to

11.1.1.11.
It should work now.
Note: It may take a few

minutes for the Overlay
manager to become
aware of the routing to
changes due to IPSLA
change, and the ping
begin to succeed.
65. Look at the flow in the Flow table
If you don’t see the flow, retry the ping and refresh the display. It may be necessary to
Click the Clear button also to clear any cached search filters.
66. Click on the icon to open the flow detail
Checkpoint
7) Which Overlay is the flow matching? ____________________
8) Which tunnel is the flow tunnel taking? ____________________
The flow is going through a Passthrough tunnel associated with the DefaultOverlay to the
next hop router (10.110.104.1) on wan1.
Note: You should understand that in this case, no route to the destination was needed by
the appliance since the next hop router knew how to route the traffic and how to reach the
source subnet. This may not always be the case.
The note above also describes a potential problem for us.

Remember the configuration of the DefaultOverlay for internet
breakout?
It is supposed to backhaul traffic for the DefaultOverlay unless a

way to backhaul it is not available (e.g. peer is down).
9) Why do you suppose the traffic is not being backhauled?
Let’s do some troubleshooting…
Task 8: Verify Tunnels are up to the other sites
69. Go to the tunnels tab
70. Select Overlay tunnels
a. Overlay tunnels should be up

for all overlays to all the
other sites
Task 9: Verify that ECV-1 has a route to backhaul the traffic
71. Return to the Routes tab
a. Make sure you are viewing all routes

In the screenshot it is Sorted by the Additional Info column (descending)
Note that ECV-1 has no route to the 11.1.1.0 subnet or a default route (0.0.0.0/0) learned
from any other site. Because there’s no route or default route to another site / appliance
that can be used to reach that subnet, the local appliance can’t backhaul the traffic using
DefaultOverlay.
© Because there is no route to the destination network:

§ Local Internet breakout is working properly
§ ECV-1 will take the 2nd choice and break out locally instead of backhauling,
§ And it will use the INET1 interface (wan1) that we configured for breakout on the
DefaultOverlay
§ As a result, the traffic will be sent to the next hop router on wan1, which knows
how to get to the destination subnet (which might not always be the case).
In the next task, we will configure a default route at Site 3 so that the traffic can be
backhauled as we intended.
Task 10: Default Routes on The Data Center Routers
Let’s add a default route to ECV-5 to the next hop on the internet using the metric of 53.
72. From the Routes tab, select only ECV-5 in Tree View
73. Click the edit icon next to ECV-5 in one

of the items in the table
74. Click Add Route
75. Add the default Route
£ Subnet/Mask: 0.0.0.0/0
£ Next Hop: 10.110.116.1
This is the next hop on wan1 (INET1)
£ Interface: blank
£ Metric: 53
Not the default of 50 – we’ll
see why in a moment
£ Tag: ANY
76. Click Add
77. Click Apply on the Routes – ECV-5 dialog
78. The Route should appear in ECV-5 Routes table with a metric of 53.
79. Let’s test the Ping on TG-1011 again
a. Select all the appliances in

Tree View
b. Return to the RDP window you
have open on TG-1011
c. Retry the ping to 11.1.1.11.
It should work again, but with a
difference.
80. Let’s Return to the Flows tab to look at the flows in the flow table
81. Examine the flow details for each of the 3 flows:
© The flow is now going...
§ from ECV-1 through a DefaultOverlay tunnel to ECV-5 (shown in the top two flows)
§ then ECV-5 is breaking the flow out using a DefaultOverlay passthrough tunnel
(shown in the bottom flow)
§ The return traffic is coming back in through the passthrough tunnel on ECV-5
(bottom flow)
§ And being returned to ECV-1 through the overlay tunnels (top 2 flows)
82. In Tree View, select ECV-5 and let’s take another look at ECV-5’s routing table like we
did above
83. Sort on Subnet/Mask to get the default routes at the top
10) Why is ECV-5’s new static default route being used instead of the local default route?
11) Why does it have a metric of 53?
Answers: There are two reasons

a. The static route we added has a lower Administrative Distance (AD) 1 for a local static
route (subnet shared to the other sites) as opposed to system added default route with AD
of 250 – designed to be used as a last resort.
b. We wouldn’t use the Auto route even if the AD was the same because it has a tag that
says FROM_LAN, which means that it won’t apply to traffic arriving from another site over
the WAN.
Task 11: Add a default route on ECV-4 with a metric of 50

85. Click the edit icon next to ECV-4 in one of the items in the table
86. Click Add Route
87. Add the default route
£ Subnet/Mask: 0.0.0.0/0
£ Next Hop:
10.110.116.1
This is the next hop on wan1 (INET1)
£ Interface: blank
£ Metric: 50
Default of 50 – this is better than the
metric on ECV-5
£ Tag: ANY
88. Click Add
89. Click Apply on the Routes – ECV-4

dialog
90. The Route should appear in ECV-4 Routes table
91. Retry the Ping on TG-1011 again
a. Return to the RDP window you have open on TG-1011
b. Retry the ping. It should work again, but with a difference.
Let’s look, again, at the flows in the flow table
92. Select all appliances in Tree View
93. Go to the Flows tab
94. Examine the flow details for each of the 3 flows
© The flow is now going:
§ from ECV-1 through a DefaultOverlay tunnel to ECV-4 (shown in the top two flows)
§ then ECV-4 is breaking the flow out using a DefaultOverlay passthrough tunnel
(shown in the bottom flow)
§ The return traffic is coming back in through the passthrough tunnel on ECV-4
(bottom flow)
§ And being returned to ECV-1 through the overlay tunnels (top 2 flows)
12) Why is this flow now going through ECV-4 instead of ECV-5?
____________________
Answer: I hope you said because the metric from ECV-4 is better. If you view the
routes on ECV-1, you should see both routes, and the one to ECV-4 will have the
better metric of 50 (over 53).
Task 12: Observe Local Breakout for Other Overlays
© We have just demonstrated the internet traffic that matches the DefaultOverlay is
being backhauled. You saw that an ICMP echo request (Ping) from TG-1011 to UBU-
1 was backhauled before being broken out by the devices at Site 3.
© Now let’s make sure traffic that matches a different overlay is being broken out
directly on the local machine rather than backhauled first. We’ll initiate an FTP
connection from TG-1011 to UBU-1 in this task. FTP should match a different overlay.
95. Go to TG-1011’s RDP desktop
96. Double-click the FileZilla icon on the taskbar at the

bottom of the window next to the start menu
97. Log into UBU-1 (to reiterate from TG-1011’s RDP

Window)
£ Host 11.1.1.11
£ Username student
£ Password Speak-123
98. Click Quickconnect on the right
99. Highlight the Desktop directory on the Local Site
100. At the Remote site, you should see TestFile in its

remote directory (lower right)
101. Click and Drag it to the Local Site’s Desktop (lower left)
102. From Orchestrator ECV-1 in Tree View
103. Go to the Flows tab in Orchestrator.

104. Open the flow detail for the FTP flow (click on the icon in the Detail column)
13) Which overlay did it use? ___________________________
14) Which Tunnel did it use? ____________________________
© You should have answered BulkApps (not the DefaultOverlay like the Ping) and the
Passthrough_INET1_BulkApps tunnel. See the section of the flow detail you should
have opened below.
This FTP flow wasn’t routed to ECV-4 or

ECV-5 like our ping was. This is because
the BulkApps overlay policy order is set to
first Breakout locally, and second to
Backhaul.
105. Return to TG-1011’s Desktop

106. Close FileZilla on TG-1011’s desktop.
107. Delete the TestFile
REVIEW #7: BGP
1) T/F - Silver Peak appliances support only iBGP.
2) Do Silver Peak appliances propagate AS-Path information via subnet sharing?
3) Which learned prefixes will a BGP router advertise to an iBGP peer?
4) Which learned prefixes will a BGP router advertise to an eBGP peer?
5) What are the two Silver Peak BGP Peer types and what is the difference between
them?
6) On the Peer Configuration, what two other items should match the configured peer
type?
7) Which state indicates that a BGP peer has connected completely and an appliance
and can learn and advertise routes to it?
8) Is it possible to connect two Silver Peak appliances at different sites as BGP peers?
LAB 5: BGP
Overview
In this lab, you will configure the CSR router and appliances in the SANTA CLARA region to
be iBGP peers.
© The appliances will advertise subnets learned through subnet sharing between
appliances to the router and become the preferred path for traffic coming from
TG-3511 and TG-11411.
© If the appliances were to go down, then the routes would no longer be advertised to
the CSRs.
© In our lab, ECV-4 and ECV-5 will be iBGP peers with CSR-3x.
© We will use iBGP configuration to illustrate a few points throughout the rest of the
course.
Objectives
© Learn to configure BGP peering.

© Observe some possible problems you could encounter and learn how to avoid them.
Task 1: Test Connectivity on TG-3511 on
the LAN side
1. Right-click on ECV-5 & select appliance
manager
2. In the new browser tab that opens to ECV-5, go to

Maintenance à Tools à Ping/Traceroute
3. Ping TG-3511
£ IP/Hostname: 10.110.35.11
£ Options: -I 10.110.114.102
4. Click Start and let it run… it should fail.
5. Go to the Flows tab in Orchestrator
a. Click the Clear button
b. Click the Refresh button

6. Search for 10.110.35 to filter the only
rows that match that string. Output may also be blank
It’s only necessary to enter the partial subnet
address as shown below because that is
sufficient length for a unique matching string, but
you could enter the whole subnet, or use the
Filter by subnet field (which also requires a
mask).
7. Open the flow details on ECV-5 (click on in the Details column)
8. Reference the Topology Diagram
Do you notice anything strange?
10.110.116.1 is the next hop. Why is the ping going from ECV-5 , Passthrough using the
DefaultOverlay instead of going directly out ECV-5’s lan0 interface to the next hop router?
Let’s find out…
Task 2: Find Preferred Route of the

Ping
9. Go to the Routes tab
10. Click on the Edit button for ECV-5
11. Click on Find Preferred Route
£ IP address: 10.110.35.11
£ Direction: From LAN

£ Overlay Name: Any
b. Click Find
What is going on?
12. Close the window
13. Click the at the top-left to close ECV-5’s

Routes configuration page
14. In the Search field, type 10.110.35
What is going on?
a. The ping left ECV-5 through a tunnel to ECV-4
b. ECV-4 sent the ping to CSR-3x
c. CSR-3x sent the ping to the destination TG-3511
d. TG-3511 replied via CSR-3x
Task 3: Configure BGP on ECV-4
16. Select Site 3 – Santa Clara in Tree View
17. Go to the BGP tab: Configuration à Networking à BGP
18. Click the edit icon next to ECV-4
19. Click on the Enable BGP radio button
£ Autonomous System Number: 65001
£ Router ID: 192.168.1.7
£ AS Path Propagate: (checked)

This makes sure that AS Path information is sent to
EdgeConnect peers when the route is subnet shared
20. Click Add under BGP Peers to configure CSR-3x as a peer
21. Configure CSR-3x as a peer
£ Peer IP: 10.110.114.1

£ Local Interface: any
£ Peer ASN: 65001
£ Peer Type: Branch
£ Admin Status: UP
£ Next Hop Self: (checked)
£ Inbound route map:
default_rtmap_bgp_inbound_br
£ Outbound route map:
default_rtmap_bgp_outbound_br
22. Click Add
23. Back at the BGP information screen, click Apply under the BGP Peers table
Task 4: Configure BGP on ECV-5

24. From the BGP tab in Orchestrator click
the edit icon next to ECV-5
25. Click on the Enable BGP radio button
£ Autonomous System Number: 65001
£ Router ID: 192.168.1.8
£ AS Path Propagate: (checked)

This makes sure that AS Path information is sent to
EdgeConnect peers when the route is subnet shared
26. Click Add under BGP Peers to configure CSR-3x as a

peer
£ Peer IP: 10.110.114.1
£ Peer ASN: 65001
£ Admin Status: UP
27. Click Add
28. Back at the BGP information screen, click Apply under the BGP Peers table
Task 5: Observe Neighbor Connections

29. On the BGP tab, click the Peers button to view Peer information
a. Use the refresh button to update the peer status. It may take a minute or two.
30. In the Peer State column, both ECV-4 and ECV-5 should have connections to CSR-3x
in the Established state.
If this is not the case, recheck your configuration. A common error is to forget to select the
correct route maps for the peer causing the peer to remain in the IDLE state
Task 6: Understand BGP Peer State Details

31. If you need to troubleshoot, you can Click the Peer Detail icon (far right) to see
information about each appliance’s connection to this peer
1) What is the Router ID (not Peer IP) of CSR-3x?
2) What IP addresses did CSR-3x peer with to ECV-4?
3) How many routes were learned by ECV-4 from CSR-3x?
4) How many routes were advertised by ECV-4 to CSR-3x?
Task 7: Test and View BGP Routing information
Since both ECV-4 and ECV-5 are BGP peers with CSR-3x, they should now both be learning
routes that enable them to reach TG-11411 and TG-3511.
Let’s confirm that…

32. Return to ECV-5’s Appliance Manager window
where the Ping to TG-3511 is running.
Success! We now get a reply!
33. Go to the Flows tab in Orchestrator
a. Click the Clear button
b. Click the Refresh button
34. Again, search for 10.110.35 to filter the only rows that match that string.
35. Open the flow details on ECV-

5 (click on in the Details
column)
There it is! The ping is now being

sent directly to CSR-3X
(10.110.114.1) out the lan0
interface
36. Close the Flow Details
37. Return to the Routes tab on

the Orchestrator
38. Use CTRL-Click to select, ECV-1, ECV-4, and ECV-5 in Tree View
a. Filter on 10.110.35
© We can see in the Type column that the 10.110.35.0/24 routes were learned via IBGP
from CSR-3X (10.110.114.1) because they are BGP peers with it
© We now want to be advertising those routes via subnet sharing in the SD-WAN fabric
because ECV-1, ECV-2 and ECV-3 still need to learn those routes.
In the next task we will see a simple solution to this problem.
39. Stop the ping on ECV-5
Task 8: Redistribute BGP learned routes on ECV-4 into Subnet Sharing

40. Clear the Search box to view all routes
41. Click on the edit

button for ECV-4
42. Click on the icon to edit the

default_rtmap_to_subsh.
43. Click on the icon next to
Priority 65535 to edit the
BGP rule
44. Select the next to Permit

45. Click Update
46. Click the at the top-right to close the Route Map

47. Click Apply
Task 9: Redistribute BGP learned routes on ECV-5 into Subnet Sharing

48. Repeat the previous task on ECV-5
Task 10: View Subnet Shared BGP Routes

49. ECV-1, ECV-4, and ECV-5 should still be selected in Tree View.
50. Return to the Routes tab on the Orchestrator
51. Refresh the table.
52. Search on 10.110.35
53. Reference the screenshot below and look at the Type column
a. ECV-1 has two equal cost routes to 10.110.35.0/24. Each from ECV-4 & ECV-5
b. ECV-4 & ECV-5 also have additional subnet shared routes
Task 11: Use additional Subnet Sharing filters for BGP
© Hmmm… It would be useful if we could know the AS number the BGP routes
originally came from after being redistributed into Subnet Sharing .
54. Clear the Search box to view all routes
55. Click on the edit button for ECV-4
56. Check the following boxes
£ Filter Routes from SD-WAN Fabric with Matching Local ASN:
£ Include BGP Local ASN to routes sent to SD-WAN Fabric:
57. Click Apply
58. REPEAT last two steps for ECV-5
59. Use CTRL-Click to select, ECV-1, ECV-4, and ECV-5 in Tree View
60. Search on 10.110.35
© What do we see?
Note: it may take several minutes for the route filtering changes to take effect.
a. You can see that ECV-4 and ECV-5 now
£ only use the iBGP routes for the 10.110.35.0 subnet

£ exclude subnet shared routes in the same AS as themselves
b. ECV-1 is learning the 10.110.35.0 subnet via subnet sharing from both ECV-4 and
ECV-5.
c. ECV-1 now includes the AS# for 65001
© What did you just do?
§ Include BGP Local ASN to routes sent to SD-WAN Fabric

— causes the advertising appliance to include its local AS number when
advertising a BGP learned route into the SD-WAN fabric via subnet sharing.
§ Filter Routes from SD-WAN Fabric with Matching Local ASN

— causes an appliance learning a route via subnet sharing to filter out routes
which have an AS number that matches their own and not include them in the
routing table or routing decisions.
Since ECV-4 and ECV-5 are both in AS-65001, with the route map for BGP set
to permit, it means they both advertise the subnet shared route with 65001
attached, and since they are filtering out routes with AS number 65001
attached to the route, it has the effect of keeping them from learning local BGP
routes from each other via subnet sharing (which is technically a routing loop).
ECV-1, ECV-2 and ECV-3 are not in AS-65001 so they can learn these routes
over the SD-WAN fabric and use them to make routing decisions.
Note: Although this was a simple fix for this problem, as we’ll see later, there is more than
one way to solve this problem. In an upcoming lab, we’ll demonstrate a different way to
achieve our goal of causing routes learned directly from a local BGP peer to be preferred
over the subnet shared ones.
Task 12: View BGP routes on CSR-3x
61. Double-click on the PuTTY icon
on the Landing Desktop
or
Click on the icon from the

Taskbar
62. Highlight the Saved Session for CSR-3X
63. Click Open and a console window will open.
64. Click inside the window (anywhere in the black space)
65. Type the password: Speak-123

66. Type enable
67. Again, type the password: Speak-123
68. Type show ip bgp to display its BGP table.
69. Press the spacebar until you get back to the CSR-3x# prompt to display the entire
table.
CSR-3x is learning default routes from ECV-4 and ECV-5, but the one from ECV-4 has
the better metric (50 vs 53).
NOTE: If you are missing subnets from the other sites in CSR-3x’s routing table (e.g.
10.110.10.0 and 10.110.107.0) go back and make sure you selected the correct route
maps for the BGP peer in the appliance configurations. You should have selected the
route maps ending in ‘br’ (for branch) not ‘pe’ (for a provider edge router).
One other common error is to forget to check Next Hop Self on the BGP peer
configuration in Lab5, Task 1. This will cause learned routes not to be used by CSR-3x
because a route to the original next hop is not known. The next hop needs be ECV-4 or
ECV-5.
70. Type show ip route to see which routes are actually used by CSR-3x
© show ip route doesn’t show all the routes learned by the router. It shows only
the ones being used.
© In our example, although BGP was learning two default routes, only one is used – the
one from ECV-4 because it advertised the better metric (50 vs. 53).
221b: SELF-PACED STUDENTS ONLY
You have completed PART 1 of the LABs.

Resume watching the training videos starting with OSPF
REVIEW #8: OSPF
1) T/F: OSPF is a path vector protocol
2) Is it necessary to configure which OSPF neighbors you will connect to?
3) Which device becomes the Designated Router on a broadcast network (e.g.

ethernet)?
4) T/F: It is necessary to define which interfaces on an appliance will participate in OSPF
5) What metric is used by OSPF routers (and appliances) to determine the most
desirable path, and how is it determined?
6) How many OSPF Areas can an appliance be a member of?
7) Can an appliance be an ABR (Area Border Router) or ASBR (Autonomous System

Boundry Router?
8) What state in an OSPF peer adjacency indicates they have sent and received routing
information?
221b: SELF-PACED STUDENTS ONLY
Request a Voucher and License devices for

PART 2 of the ASD Lab
Task 1: Request a Voucher for the PART 2 ASD Image

1. Browse to https://silverpeak.find.training
2. Select 221b – Advanced SD-WAN Deployments 9.0.x

(PART 2 – May 2022)
3. Follow similar detailed instructions from the document
“Accessing Remote Labs for Self-Paced Students”
a. This can be found in the RESOURCES tab of the course
Task 2: Run the ASD Setup Script

4. From the Desktop, double-click 221 – ASD Setup ONCE to run the setup
script.
æ Do not run this twice. It may take a few seconds to start.

You can only run this script once. It is disabled after the first run.
5. The script runs and generates a Command Prompt window and may take a several
minutes to run.
6. When the script

completes, it will display
the ASD Lab 1 – Setup
Log.txt file again.
7. All the steps should

show Success
8. Click on the black Command Prompt window and Press any key to continue.
a. Close the Notepad file.
ASD 9.04-9.03 v1.3 Student & Lab Guide Do Not Replicate Page 87a of 189
LAB 6: OSPF
Overview
In this lab, you will configure the CSR-20 router and appliances in Mumbai to be OSPF peers.
© The appliances will advertise subnets learned through subnet sharing between
appliances to the routers, and become the preferred path to optimize traffic.
© If the appliances were to go down, then the routes would no longer be advertised to
the CSRs, and they would use their native L3 routing tables to forward traffic
accordingly.
© Because we will have equal cost paths through both appliances in our environment,
allowing packets for a single flow to be distributed across tunnels to ECV-2 and ECV-
3, we’ll see some asymmetry in this environment.
Note: OSPF is already configured on CSR-20, so you will only need to add the OSPF
configuration to ECV-2 and ECV-3.
Objectives
© Learn to configure OSPF peering.

© Observe some possible problems you could encounter and learn how to avoid them.
Task 1: Configure OSPF on ECV-2
1. In Orchestrator, select Site 2 – Mumbai in Tree View
2. Open the OSPF tab: Configuration à Networking à

Routing à OSPF
3. Click on the edit icon next to ECV-2 in the list to configure OSPF
4. Click on the toggle button to Enable

OSPF
£ Router ID to 192.168.1.5
£ Redistribute routes to OSPF,

select default_rtmap_to_ospf
5. Under Areas, Click the Add button.
£ Area ID: 0.0.0.0

£ Area Type: Standard
6. Click Add
7. Under Interfaces, Click the Add button
£ Interface: lan0
£ Area ID: 0.0.0.0
£ Admin Status: UP
£ Accept the other default values

8. Click Add
9. Click Apply to set the configuration
Task 2: Configure OSPF on ECV-3
10. Let’s do the same thing for ECV-3. Click on the edit icon to configure OSPF
11. Click on the toggle button to Enable

OSPF
£ Router ID to 192.168.1.6
£ Redistribute routes to OSPF,

select default_rtmap_to_ospf
12. Under Areas, Click the Add button.
£ Area ID: 0.0.0.0

£ Area Type: Standard
13. Click Add
14. Under Interfaces, Click the Add button
£ Interface: lan0
£ Area ID: 0.0.0.0
£ Admin Status: UP
£ Accept the other default values
15. Click Add
16. Click Apply to set the configuration
Task 3: Review the OSPF Configuration Screens
17. From the OSPF tab, click on the Summary button
a. Refresh the screen if needed. It may take a minute or two for the connections to
form.
— The summary screen shows information regarding the appliance configuration.

Note there are currently no routes being redistributed to, or from, OSPF as
indicated by the three redistribute columns on the right half of the table.
18. Click on the Interfaces button
— The Interfaces screen shows the status of each interface that is participating in
OSPF and the appliance’s interface state. In this case ECV-2 became the
backup designated router because it came up before ECV-3. This doesn’t
affect either device’s ability to transport traffic.
19. Click on the Details icon for ECV-2
§ You can see that the Designated Router is

10.110.107.1, which is the IP address of CSR-20 (see
your topology diagram). The Backup designated router
address is 10.110.107.101, which we already know is
the lan0 IP address of ECV-2.
20. Close the details screen.
21. Click on the Neighbors button
§ A state of Full indicates the connection to the neighbor is complete and they can
share link states with each other.
§ Here you can see the status of each Neighbor. ECV-2 and ECV-3 each have two
neighbors. One Neighbor is CSR-20 (RID 1.1.1.1), and the other neighbor is the
other appliance in the HA configuration.
— It’s important to understand that subnet sharing does not occur over the HA
connection between ECV-2 and ECV-3. They can share routes on the LAN
side through their OSPF connection, however.
22. Click on the Areas button
§ EdgeConnect appliances currently only support a single area. In our lab, both
ECV-2 and ECV-3 are in the Backbone Area 0 (0.0.0.0).
§ The EdgeConnect does not have to be in Area 0.0.0.0. It can be located at the
edge of the OSPF network in either a Standard Area or a Not-So-Stubby-Area
(NSSA).
Task 4: Check routes on ECV-2 and ECV-3 to make sure routing
information is getting exchanged
© We want to make sure that ECV-2 and ECV-3 are learning the 10.110.20.0 subnet
from CSR-20
24. Click on the OSPF button to filter the table for only OSPF routes
25. Type 10.110.20 in the Search field
Note that both ECV-2 and ECV-3 have learned about the 10.110.20.0 subnet.
© Why do you think the metric (2) is so low? ______________________

Answer: The OSPF metric comes from adding up the link costs. There are two links
between each ECV and the 10.110.20.0 network. Each appliance has a default link
cost of 1 for their lan0 interfaces. The CSR-20 also has a link cost for the interface
that connects to the destination subnet and these are added together by the
appliances.
Task 5: Check for learned routes on CSR-20
26. Double-click on the PuTTY icon on the Landing Desktop
27. Double-click on the Saved Session for CSR-20
Isn’t double-clicking on the Saved Session much faster

than highlighting it… then… clicking… Open? J
28. Type the password:

Speak-123
29. Type enable
30. Again, type the password:
Speak-123
31. Type show ip route to view the routes table
© OSPF learned routes are coded with a capital “O” to the left of the subnet entry
© As you can see from the displayed route entries:
§ A default route 0.0.0.0/0 was learned from ECV-2 and ECV-3
§ In fact, there are equal cost routes learned for subnets from Site 1 – Singapore
(10.110.10.0//24) and Site 3 – Santa Clara (10.110.35.0/24 and 10.110.114.0/24)
© Wait a second… Sites 1 and 3 are not configured for OSPF. How were those routes
learned?
Answer: If you said, Subnet Sharing, then you are correct!
REVIEW #9: Route Maps
1) What do route maps control on a Silver Peak appliance?
2) T/F: A route map can be configured on Orchestrator and pushed out to

the appliances which can use the route map.
3) What’s an Inbound Route Map?
4) What’s an Outbound Route Map?
5) T/F: OSPF uses inbound and outbound route maps Per Peer.
6) On a single appliance, how many active route maps can you have for:
a) Redistribution into OSPF?
b) Redistribution into Subnet Sharing?
c) Redistribution outbound into BGP?
d) Redistribution inbound from BGP?
7) T/F: Each rule in a route map must use the same Source Protocol
8) Is the choice of set actions the same for each of the rules in every Route Map?
9) T/F: The default outbound BGP PE route map allows you to redistribute subnet
shared routes into BGP into advertisements to that peer.
LAB 7: Route Maps

Overview
Route Maps control redistribution of routes between different routing protocols. On an
EdgeConnect appliance that means Subnet Sharing (SD-WAN fabric), BGP and OSPF.
© An inbound route map controls what is potentially being distributed into the SD-WAN
fabric and being subnet shared between Silver Peak appliances.
§ Route maps that control redistribution into Subnet Sharing (the SD-WAN fabric)
are found on the Routes pages for each appliance.
© An outbound route map controls what is being redistributed by an appliance (for

example ECV-2) into another routing protocol (e.g. OSPF, BGP) by that appliance.
§ Route maps that control the distribution into other protocols are found on the
configuration page for each protocol.
© BGP is slightly different from OSPF in that it contains inbound and outbound route
maps per Peer.
Note: BGP Peer type selection causes some filtering that is applied before the route
maps. An appliance can advertise subnet shared routes to a branch peer, but not to PE
peer. This is intended to reduce the risk of routing loops in the BGP routing domain.
Objectives
© Configure route maps and how they affect route redistribution and metrics.
© Configure route maps to tag and filter routes
© Adjust metrics for routes being redistributed by multiple appliances to cause adjacent
routers to prefer one over others
Task 1: Adjust the advertised metrics from Subnet Sharing into BGP
ECV-4 and ECV-5 currently both learn subnets from the other appliances and redistribute
them into BGP with unchanged metrics.
In this task, we’ll adjust the outbound advertised metrics for an appliance (ECV-4) to make
the BGP peer (CSR-3x) prefer the other appliance (ECV-5).
1. Go to (or reopen) the PuTTY window for CSR-3x
2. Type show ip bgp
Notice the equal cost routes for the networks from ECV-4 (10.110.114.101) and ECV-5
(10.110.114.102) have a metric of 50.
Best practice in network design is to have your routing be deterministic and predictable.
© We want CSR-3x to always prefer ECV-5 when forwarding routes.
3. Select Site 3 – Santa Clara in Tree View.
4. Return to the BGP tab
5. Click the edit icon for ECV-4 on the BGP tab.
6. Click the edit icon for the BGP Peer 10.110.114.1.
7. Click the edit icon for the Outbound route map.

Outbound means from the ECV to the BGP peer.
You can see that the default route map for the BGP
branch peer (the map name ends in _br) permits
advertising from all sources into BGP with no changes.
ECV-4 is learning all the routes from other sites via subnet
sharing (SD-WAN) and it is not running OSPF. Note that
while OSPF route maps had a single selection for all SD-
WAN sourced routes, the BGP route maps allow you to
have more granularity and treat routes that entered the
SD-WAN fabric from different sources (BGP, OSPF,
Local/Static) differently.
8. Edit 65505 (Local/Static) by Clicking the edit icon.
9. Check the Metric checkbox.
10. Set the metric to 70.

11. Click Update.
12. Repeat for the rule Priority 65515 (SD-WAN

Local/Static)
a. Check the Metric checkbox.
b. Set the metric to 70.

c. Click Update.
13. Confirm you have both rules modified with a metric of 70
14. Click Apply
15. Click on to
close any open
route map, peer
edit and ECV-4
BGP edit
windows.
16. From PuTTY for CSR-3x, type show ip bgp.
© Notice that:
§ all subnet shared prefixes from ECV-4 (10.110.114.101) now have a metric of 70
§ all lan side prefixes are learned except for 10.110.20.0/24
© Do we not need it; perhaps a default route is being used?
17. Type show ip route
© 10.110.20.0/24 isn’t there. Let’s try pinging TG-2011
18. Ping 10.110.20.11
© That doesn’t work either. What’s different about this particular subnet and how it was
learned?
Answer: It originated via OSPF

19. Return to the BGP tab on Orchestrator
20. Click on the edit icon for ECV-4 on the BGP tab.
21. Click the edit icon for the BGP Peer 10.110.114.1.
22. Click the edit

icon for the
Outbound route
map.
23. Look at Priority #65485 it says SD-WAN (OSPF) is allowed.
© What is happening?
ANSWER: If you said, it may have to do with the subnet
sharing route map, you’re probably right. Let’s confirm that.
24. Click on at the top right to close the Route Map screen
25. Close the Update Peer window
26. Click on at the top right to close the BGP Information screen
Task 2: Permit OSPF redistribution into Subnet Sharing on ECV-2

27. Select ECV-2 in Tree View
28. Click on the edit icon for ECV-2 on the Routes

tab.
29. Click the edit icon for default Subnet Sharing

route map (default_rtmap_to_subsh)
© We were right!
Although the inbound BGP route map allowed
OSPF learned routes, the Subnet Sharing (SD-
WAN Fabric) Route Map does not.
Let’s change that.
30. Click on the

edit icon
next to
Priority#
65525
31. Click on Permit
32. Click Update
33. Verify the rule has been set to Allow
34. Click Apply
35. Click on at the top right to close the SD-WAN Fabric Route Redistribution Maps
screen
36. Click on at the top right to close the Routes – ECV-2 screen
Task 3: Permit OSPF redistribution into Subnet Sharing on ECV-3

37. Repeat the steps in the previous task for ECV-3 as well
Task 4: Verify OSPF Routes are being Subnet Shared

38. Select All Appliances in Tree View
39. Return to the Routes Tab
40. Search on 10.110.20
© As you can see, we now get the 10.110.20.0/24 subnet being advertised via Subnet
Sharing. In fact there are equal cost routes because we configured both ECV-2 and
ECV-3 to redistribute them.
§ ECV-2 and ECV-3 learn it directly via OSPF
§ ECV-1, ECV-4, & ECV-5 learn one each from them which is why there are two
equal cost routes.
41. Return to the PuTTY session for CSR-3X.
42. Ping TG-2011 again. It should now work!
Task 5: View the routes on the appliances to verify they come from
OSPF
43. Click on the Routes tab in Orchestrator
44. Select Site 3 – Santa Clara from Tree View
45. Click on the OSPF button to view only OSPF originated routes.
46. Sort by the Subnet/Mask columns with 0.0.0.0/0 default routes at the top as shown.
© Notice that there are subnet shared routes for all the non-directly connected lan
subnets in our SD-WAN that originated from OSPF being learned from both ECV-2
and ECV-3.
© In fact, there are duplicates indicating ECV-2 and ECV-3 are advertising the same
subnets.
48. Select All Appliances from Tree View
49. Return to the Flows tab in Orchestrator and make sure

all appliances are selected
a. Clear out any filters
b. Search for 114.11 (it should be empty for now).

50. On the Landing Desktop, go to your RDP session to
TG-1011’s desktop (If it’s not still open, open a new one)
51. Open a command window on TG-1011 and ping TG-11411 at 10.110.114.11.
52. View the Flows tab in Orchestrator
53. Refresh the output.
54. From the Reset Flows dropdown, select Reset All Returned
55. Click the button to confirm you want to Reset Returned Flows
56. Repeat the previous 3 steps 5-10 times until you see the Ping go towards two
different Outbound Tunnels (ECV-4 and ECV-5)
57. Let’s review the flows in Orchestrator. You will get something similar to this:
© If you recall the route selection criteria, because there are equal cost routes, one will
simply be chosen at random.
59. View the Routes tab again.
a. Click on the All button
60. Search on 114.
© As you can see, ECV-1 has routes via all the other four ECV’s. However, ECV-1 is
forwarding traffic only to ECV-4 and ECV-5 because, even though they all have a
metric of 50, the administrative distance of subnet shared originated routes is 10,
which is better than subnet shared, ospf-originated routes AD of 15.
© Predictability is a good thing in networking. We want routing to be deterministic. While

there are simple methods like setting a peer priority, next let’s play with an example
using Route Maps to Tag subnet shared routes so we can be in direct control of which
paths will be used.
Task 6: Tag Subnet Shared routes redistributed into OSPF by ECV-2

In this task, we’ll tag subnet shared routes being redistributed into OSPF. This will provide a
way for us create filters based on those tags in the next task.
Note that the tags are just labels and are not metrics.
First, we will cause tags to be added to subnet shared routes redistributed to OSPF.
61. In Tree View, select ECV-2 and ECV-3.
62. Go to the OSPF tab in Orchestrator.
63. Click on the edit icon for ECV-2.
64. Click to edit the Redistribute routes to

OSPF Route Map.
65. Edit map 65515 to tag subnet shared

(SD-WAN) routes so they can be filtered.
66. Let’s add an OSPF route tag of 999 to all routes

that originated from subnet sharing
a. Check the box next to OSPF Tag.
b. Type the tag number 999.
c. Click Update.
67. Verify the tag was set in the Set Actions column
68. Click Apply
69. Click on at the top right to

close the OSPF Route
Redistribution Maps screen
70. Click on at the top right to
close the OSPF – ECV-2
screen
Task 7: Tag Subnet Shared routes redistributed into OSPF by ECV-3

71. Repeat the previous task for ECV-3 as well
Task 8: Filter and View Tagged Routes from OSPF to Subnet Sharing
74. Click the All button
75. Search on 999

Note: it may take a few minutes for the route tags to be propagated. Use the Refresh
button to check on this every few minutes.
© You can see there are 28/60 prefixes with a Route Tag of 999.
© These are essentially OSPF originated routes that ECV-2 and ECV-3 have shared
over the SD-WAN via subnet sharing (10.110.10.0, 10.110.35.0, 10.110.114.0 and
loopbacks).
76. Clear 999 from your Search filter.
Task 9: Configure Route Map to Filter on OSPF Tag 999 on ECV-2

Now that the OSPF routes that originated from the SD-WAN fabric are tagged with 999, we
will create filters to keep those from being redistributed back into subnet sharing.
77. From the Routes Table click the edit icon for ECV-2
78. Click to edit the route map for

Redistributed Routes into SD-
WAN Fabric.
79. Click Add Rule.
80. Create rule #65500 that Denies

OSPF routes with the tag 999.
£ Priority 65500
(so this rule is above others in the list)
£ Source Protocol: OSPF
£ OSPF Tag: (checked)
£ TAG value 999
£ Permit (unchecked)
81. Click Add
A Priority Rule 65500 should show at the top of the Route Map List
82. Click Apply.
83. Click on at the top right to close the SD-WAN Fabric Route Redistribution Maps
screen
84. Click on at the top right to close the Routes – ECV-2 screen
© Note this does not prohibit sharing other OSPF routes learned from CSR-20.
They will not have the 999 tag.
© It only filters routes that originated from the SD-WAN fabric (subnet shared) that are
tagged.
Task 10: Configure Route Map to Filter on OSPF Tag 999 on ECV-3
85. Repeat the previous task for ECV-3 as well
Task 11: Observe & Review Route Tag Effects

87. From the Routes tab search on 999
Again, it may take a few minutes for the route tags to be propagated. Use the Refresh
button if needed.
88. Clear 999 from the search field
© Let’s review... this diagram will help explain what you just accomplished in the last few
tasks.
A. ECV-2 added a tag (999) to subnet shared routes that were advertised into the
OSPF routing domain.
B. CSR-20 learns the routes from ECV-2 and adds them to its routing table.
C. ECV-3 also learns the routes from ECV-2 and adds them to its routing table.
D. CSR-20 advertises routes to ECV-2 and ECV-3,
E. ECV-3 adds these routes to the routing table.
F. ECV-3 DENIES routes learned from ECV-2, that originated from ECV-4 or ECV-5,
tagged with 999, and does not redistribute them to other appliances via subnet
sharing.
ECV-3 PERMITS routes learned from CSR-20 because they are untagged and
advertises them into the SD-WAN fabric via subnet sharing.
© The above covers what happens for routes advertised by ECV-2.

— Remember, we configured Tags on ECV-3 as well, so this also happens to SD-
WAN fabric (subnet shared) routes advertised by ECV-3 into the OSPF Fabric.
89. View at the routes on ECV-4 and ECV-5 on the Routes tab.
90. Search for only /24 prefixes
© If you select ECV-4 and ECV-5 in Tree View, you can see that the prefixes learned
for subnets at Site 3 are learned only from devices that have direct knowledge of
those subnets.
— 10.110.114.0: learned from CSR-3x (10.110.114.1) and from each other via SS
— 10.110.35.0: learned via BGP and SS
© 10.110.20.0 prefixes are still there because ECV-2 and ECV-3 are allowed to
redistribute those into the SD-WAN fabric. They were sourced from CSR-20 and were
not tagged with 999.
Takeaways:
© Route maps are powerful and flexible.

© Each route map rule has match criteria, including source protocol, subnet/address,
and other items that depend on the source protocol.
© Each rule can Permit or Deny routes to be distributed into a destination protocol
© Each rule has its own Set Actions applied to Permitted routes which vary by
destination protocol
© Each rule can be individually Enabled/Disabled (handy for troubleshooting and

testing)
REVIEW #10: Regions

1) T/F: Regional routing increases the number of tunnels required to connect
appliances in different regions
2) Is it possible for a device to be a hub in the RealTime overlay, and a spoke in the
DefaultOverlay?
3) T/F: In a region using an overlay configured with a Regional Mesh topology, non-
hub devices will only connect to Hubs in that region.
4) What must be enabled for hubs to readvertise routes?
Hub & Spoke

H1
S1
S2
H2
Hubs Spokes
5) In the diagram above, will H1 be able to advertise S2’s routes to H2?
6) In the same diagram above, will H1 be able to advertise S2’s routes to S1?
Region A Region B
A1 B1
Mesh
Hub A Hub B B2
A3 Spokes
7) Assume all devices use default subnet sharing metrics in this middle diagram and
regional routing is enabled:
a) With what metric will Hub A learn routes advertised by A1?
b) Will A1 learn routes advertised by A3? If so, with what metric? If not, why?
c) With what metric will Hub B learn routes advertised by A1?
d) Will B1 learn routes advertised by A3? If so, with what metric? If not, why?
e) Will B2 learn routes advertised by B1? If so, with what metric? If not, why?
8) In the diagram below, Region C looses its connection to Region B. Can traffic be
routed from devices in Region C to Region B via Region A?
A B
X
C
LAB 8: Regions
Overview
Regional routing when enabled, allows you to manage your SD-WAN fabric by dividing it up
into segments called regions. It involves intra-region (within a region) and inter-region
(between two regions) route distribution across the SD-WAN fabric.
© Regions within a network can represent geographical regions, administrative regions,

or a set of sites in the network that have common business goals. The organization is
up to you, but you must remember that adding devices to a region affects routing and
how routes are shared between appliances. Each region has one or more hubs.
Regions are only connected together by hubs, and routes are only shared between
regions by hubs in each region. All hubs are fully meshed by default.
© When regional routing is enabled, hubs can re-advertise routes learned from non-
hubs to other non-hubs that are also part of that region using subnet sharing. This is
very different than the way hubs behave when regional routing is disabled. When
regional routing is disabled, hubs will not advertise routes learned via subnet sharing
to other devices.
© You can provide different Business Intent Overlays for each region by enabling
regional routing and customizing BIOS per region.
Objectives
© Learn to configure and enable regional routing with 3 regions.

© Observe how this affects propagation of routes within and between regions
© Observe how the metric is affected on re-advertised routes.
Task 1: Create Region Labels

We will create regions that align with the site names already shown in
Tree View.
1. Open the Regions tab:

Configurationà Overlays
& Security à Regions
2. Click on Create Regions
3. Click on New Region
£ Region Name of Singapore
4. Click Save
£ Region Name of Mumbai
6. Click Save
£ Region Name of Santa_Clara
8. Click Save
The three Regions you just created now appear in the
Regions list.
9. Click Close
Task 2: Configure Hub sites

We will make ECV-1, ECV-2, ECV-3 and ECV-4 hubs.
© It’s important to remember that a hub is a hub in every overlay

that it is part of.
ECV-5 will NOT BE a HUB. Do not configure ECV-5 as a hub in

the steps below.
11. Click on Hubs
This will open the Hubs tab
12. Click in the dialog box to the left of the grayed out Add Hub button
13. Select ECV-1
14. Click Add Hub

Orchestrator will begin to configure the hub.
In the meantime…
15. Using the previous steps configure the remaining as Hubs
£ ECV-2
£ ECV-3
£ ECV-4
16. The four ECVs should now

appear in the list
Note: Do not configure ECV-5 as a

hub
Task 3: Convert Overlays to Regional Topologies

In this task, we will change the topology of the 4 overlays to Regional Mesh.
17. Go to the Business Intent Overlays tab:

Configuration à Overlays à Business
Intent Overlays
Task 4: Change the topology of the Business Intent Overlays

18. Click on the topology icon for the Realtime Overlay
19. Click on the topology icon
20. Select Regional Mesh

Along with the new Topology
shown, all the configured Hubs will
be displayed
21. Click OK
22. REPEAT for the CriticalApps overlay
23. REPEAT for the BulkApps overlay
24. REPEAT for the DefaultOverlay
25. Click OK
26. Click Save and Apply Changes to Overlays
27. Click Save to Confirm Changes
28. Click on Orchestration ETA at the top-right of the Orchestrator
29. Watch for the Orchestration to

complete
Notice that an alarm indicator has
appeared (this may take a minute
or more to resolve)
Click on the ‘1’ in the red box
30. Observe the alarm text

The warning is correct. We have not
added the hubs or appliances to any
regions yet.
31. Click the to close the alarm.
32. On the Business Intent

Overlays tab, Click the ‘+’
sign next to the word Hubs to
reveal the hubs column
information for each overlay
33. View the information in the column
Although each Hub we defined is part of each overlay,

none of the appliances has been added to any of the
regions we created yet. We will address this in the next
task.
Task 5: Add the appliances to Regions

34. Return to the Regions tab
36. Check the box next to Singapore in the Add

column
37. Click Apply
38. Click Apply Regions
39. REPEAT these steps to add ECV-2 and

ECV-3 to the Mumbai region
40. REPEAT these steps to add ECV-4 and
ECV-5 to the Santa_Clara region
41. Select all the appliances in Tree View to see a summary of what you have done
42. Return to the Business Intent Overlays tab
43. View the changes in the Hubs column

Each region now has a hub and each overlay
displays a summary of the hubs and regions
associated with that overlay.
44. Click the Regions link for the RealTime overlay
The RealTime overlay expands to show you

summary information for each region.
Although we are not going to do it in this lab, it is
possible to customize a version of each overlay
for each region.
For example, you could use a different topology,
primary interfaces and backups, QoS etc. for
each overlay in each region, making this feature
very flexible and powerful.
© Wait a second! ECV-5 is missing from the

list… It’s ok, it is not a hub.
Task 6: Observe the effects of regional topologies and hub designation

on the topology
We can see examples of some immediate effects on reachability due to the way Overlay
tunnels, Underlay tunnels, and subnet sharing have been affected.
45. In Tree View, Right-click on ECV-5
46. Select CLI Session
47. Typeping
10.110.10.11 -I
10.110.116.102 to ping
TG-1011 from wan1 on ECV-5
The ping should fail
48. Press <CTRL-C> to end the

ping
Why do you suppose the ping is failing? Let’s look at the routes on ECV-5:
49. Return to the Routes tab in Orchestrator
There is no longer a route to the 10.110.10.0 subnet (refresh if needed to see the update).
In fact, ECV-5 is not learning routes via subnet sharing from any other appliances
although it was previously learning routes from all of them.
It is only learning routes via BGP from CSR-3x.
© Why is this?
ANSWER: All the appliances are all still part of all overlays and all overlays use a
mesh topology. Let’s check on the effect on tunnel formation.
Task 7: Observe effects on Overlay tunnels
51. Return to the Tunnels tab
52. Confirm only ECV-5 is selected

in Tree View
53. Click on Overlay
ECV-5 now only has tunnels to
ECV-4.
54. Click on Underlay
Again there are only tunnels to
ECV-4. Does ECV-4 have routes
from other sites?
Now let’s look at connectivity on
ECV-4
55. Select only ECV-4 in Tree

View
56. Click on the Routes tab
ECV-4 is learning routes from all the other sites.
57. Look at the Type Column
a. ECV-4 is only learning routes from other Hub sites.
b. ECV-4 and ECV-5 are connected via tunnels and can subnet share.
1) Why hasn’t ECV-5 learned these routes from ECV-4?

Aren’t hubs in a region supposed to advertise routes to non-hubs in their own region?
Answer: This only happens if regional routing is enabled. Until regional routing is enabled,
no appliance will re-advertise any routes it learns from another appliance. We will enable
this in the next task.
Task 8: Enable Regional Routing
58. Return to the Regions tab
59. Click on Enable Regional Routing
60. Click the switch to Enable Regional Routing

61. Click Save
62. Wait for orchesration to finish
63. Click View Status
This takes you to the Audit Logs
64. Sort on the Start Time column to view most recent events at
the top.
You can see that enabling regional routing allows devices to redistribute subnets.
66. Return to the Routes tab
67. Click on the All button
68. ECV-5 isn’t learning any routes from the hub in the SANTA CLARA region (ECV-4)!
2) What could be wrong?
Remember when we checked these

two options on ECV-4 and ECV-5 to
avoid a BGP routing issue in lab 4?
§ Filter routes from SD-WAN Fabric with Matching Local ASN keeps the local
appliance from using the routes that it learns from other appliances if they include
the local ASN.
§ Include BGP Local ASN to routes sent to SD-WAN Fabric causes all routes (not
just BGP originated routes) to include the local ASN (65001 for ECV-4 and ECV-5)
© Therefore, ECV-4 is filtering routes it learns from the hub ECV-5 because they contain
the local ASN!
In the next task we will solve this problem and learn a way to use Admin Distance to
eliminate the BGP routing issue we solved with one of the checkboxes above.
Task 9: Stop Filtering Routes Based on ASN Number
We were using AS numbers to do filtering before, but now we will accomplish the same
objective by adjusting Administrative Distance.
69. Select only ECV-4 and ECV-5 in Tree View
70. Click on the Routes tab.
71. Edit the config on ECV-4
72. Uncheck the box for Filter Routes From SD-WAN Fabric with Matching Local
ASN
73. Click Apply
74. REPEAT this configuration on ECV-5
Task 10: Change the Administrative Distance for iBGP routes
© We were using AS numbers to do filtering before, but now we will accomplish the
same objective by adjusting Administrative Distance.
In this task, we will make the metric for BGP routes learned via subnet sharing less
preferred than the ones learned locally from the BGP peer. This solves the problem
we had in the BGP lab where the subnet shared routes were preferred over the routes
to the same prefixes learned directly from CSR-3x. It also allows ECV-4 and ECV-5 to
advertise BGP routes to each other. This is important because if either appliance
were to lose connectivity to CSR-3x (e.g. if lan0 on either appliance went down), then
it would still be able to reach the 10.11.35.0 and 10.110.114.0 subnets via the other
appliance.
75. Select Site 3 in Tree View
76. Click Admin Distance from the

Routes tab
77. Click the edit icon next to ECV-4
78. Change Subnet Shared – BGP Remote to 201

79. Click Apply
© It’s important to understand that there are three

possible administrative distances for BGP routes:
§ EBGP – These are for routes learned directly

from an eBGP peer
§ IBGP – These are for routes learned directly

from an iBGP peer
§ Subnet Shared – BGP Remote – These are for

route that originated via BGP, but were
redistributed into the SD-WAN fabric via
Subnet Sharing.
80. REPEAT this configuration on ECV-5
81. Verify that 201 is listed in the correct column
82. Select ECV-4 in Tree View
83. Return to the Routes tab in Orchestrator.
84. Type /24 in the Search box to view only subnets
85. Sort on the Subnet/Mask column header by networks with 10.110.10.0/24 at the top
Note that ECV-4 is now learning routes to the 10.110.35.0 and 10.110.114.0 prefixes both
from iBGP via CSR-3x and subnet sharing from ECV-5.
3) Question: ECV-5 is learning the routes from ECV-5 with a metric of 250 and from
CSR-3x with a metric of 250. Which route will be preferred by ECV-5?
Answer: The ones from CSR-3x with a metric of 250 because they have the lower
admin distance (200 vs. 201).
86. Let’s check the Routing Table for ECV-5. Select only ECV-5 in Tree View.
87. Click the SD-WAN Fabric button (top center) to show only routes learned via Subnet
Sharing.
© Note five things:

1. Subnets advertised by the regional hub (ECV-4) are now being learned
2. No subnets are being directly learned from other regions by ECV-5. Subnets from
other sites are all being readvertised to ECV-5 by ECV-4 (e.g. On ECV-5 the
10.110.10.0 subnet is not being learned from ECV-1 – it is being learned from
ECV-4)
3. The routing metric for those readvertised subnets has been increased by 50.
For example, if you look at the route to the 10.110.107.0 subnet on ECV-4, you will
notice that it was learned twice (from ECV-2 and ECV-3) with a metric of 50 and
60 respectively, but it has been readvertised to ECV-5 with a metric of 100
4. Although ECV-4 has learned the 10.110.107.0 and 10.110.20.0 from ECV-2 and
ECV-3 (two routes appear in ECV-4’s table for each subnet), ECV-4 is only
advertising a single route to ECV-5 for each of them and it is adding 50 to the
lowest metric.
5. ECV-4 is now learning the BGP routes from ECV-5 again, but it too will prefer
routes learned from CSR-3x because of the admin distance (200 versus 201)
For example, the 10.110.107.0 subnet was learned by ECV-4 with metrics of 50
and 60 from ECV-2 and ECV-3 respectively. When ECV-4 advertises the
10.110.107.0 subnet to ECV-5 it advertises it with a metric of 100 (50+50). If ECV-
4 was to stop learning the route via ECV-2, but still learn it with a metric of 60 from
ECV-3, then it would advertise the route to ECV-5 with a metric of 110 (50+60).
Important lesson:
© Remember back in BGP Lab 5, the appliances preferred the subnet shared BGP
routes to the ones learned directly from a peer.
To solve this, we just checked a couple of boxes (Filter Routes from SD-WAN Fabric
with Matching Local ASN and Include BGP Local ASN to routes sent to SD-WAN
Fabric) and got rid of the suboptimal routing we had.
That solution works pretty well where you have two fully meshed peers connecting to
all the appliances at other sites.
© However, once we introduced regional routing and those same two appliances (ECV-
4 and ECV-5) were no longer peered in the network in a full mesh – because ECV-4
is a hub and ECV-5 was not. ECV-5 now needs to learn routes from ECV-4, which the
Filter Routes from SD-WAN Fabric with Matching Local ASN option prevented.
Our original solution wasn’t wrong, it just no longer worked in our new regional
network topology. Regional routing changes the way the network operates, and you
need to be aware of the effects.
REVIEW #11: Security Features
1) T/F – If an interface leading to the internet is hardened, local traffic will need to be
backhauled to a data center through a tunnel to connect to Google.
2) T/F – No traffic of any kind is allowed into a hardened interface outside of an IPsec
tunnel.
3) Could an interface connected to the Internet and configured to be a Stateful Firewall,

allow local access to SalesForce.com?
4) T/F – All the appliances in a network can simultaneously change to a new IPsec
encryption key on a predetermined schedule.
5) Are ipsec_udp tunnels the only type available in Orchestrator?
6) Is it possible to limit the address spaces from which logins to Orchestrator are
allowed?
REVIEW #12: Zone Based Firewall
1) What is the default action taken for INTER zone traffic (between devices in different
zones)?
2) What zone are all interfaces in by default?
3) When all interfaces and overlays are in the default zone, will the default security
policies always permit traffic to flow between all interfaces and across the wan
through tunnels between appliances?
4) A device in zone A starts an FTP session to a device in zone B. A security policy

permits the SYN to be sent to the destination. What is required to permit the
SYN/ACK to be returned to device that started the session?
5) What is the priority of the default rule in a security policy?
6) You configure a new rule in a security policy. Some time later, a problem is reported.
What can you do to test whether your new rule caused the problem without deleting
it?
7) How can you tell which rule in a security policy was matched for a flow?
8) In the flow table, what’s a quick way to tell at a glance that a flow was dropped?
9) What’s quick way to find only those flows dropped by the firewall in the flow table?
LAB 9: Zone Based Firewall

Overview
In this lab you will learn to create zones, apply them to the network and define security
policies that emerge from a stated set of permissions requirements.
The various tasks in this lab are designed to show how the ZBF works within the constraints of
our lab environment, not necessarily illustrate best practices for a production network.
Objectives
© Create Zone Based Firewall Labels

© Configure security policies that permit certain traffic, but deny other traffic
Task 1: Familiarization with the ZBF lab topology

1) The LAN side of each ECV will be in a zone named the same as the region
2) All WAN side interfaces will be in the INTERNET Zone
Task 2: Create Zone Labels
The first step in setting up a ZBF is configuring the zone names / labels. We will configure the
following zones: Singapore, Mumbai, Santa Clara, and Internet
1. In Orchestrator, open the
Firewall Zones configuration
tab: Configuration à
Overlays & Security à
Security à Firewall Zones
2. Click Add Zone

Note: The zone ‘Default’ is created by the
system, and it is available as a selection for
interfaces and BIOs as we’ll see.
3. Type the first zone label: Singapore

4. Click Add Zone again
5. Add the following zones:
£ Mumbai
£ Santa_Clara
£ INTERNET
6. Click Save
Note: It’s important that you add your zones in the order shown so that later security policy
configuration tasks match what you see in this student guide. Failure to do so may make
your configuration tasks more difficult to match to the directions.
Task 3: Create a Security Policies Template

The next step is to create the security policies that permit or deny connections between a pair
of zones. We will use templates for these so we can apply them to all of our appliances. We
will create a new template group that includes only Security Policies
7. In Orchestrator, Open the Templates

Tab: Configuration à Templates &
Policies à Templates
8. Click Show All
9. Remove all policies from the Active Templates

column by dragging them to the Available
Templates column
10. Drag Security Policies from the right side to the

Active Templates column
If it does not appear, it may be further below; scroll down
the Available Templates list.
Note: Certain browser zoom settings may prevent the Available
Templates from displaying. If the Available Templates column appears
blank, try changing your browser zoom level
Your active templates list

should look like this:
Now we will save this as
a Security Template
group.
11. Click Hide
12. Click Save As
13. Name the Template group ZBF Policies

14. Click Save
The Security Policies matrix should now be visible
Task 4: Review Security Policy requirements:

The following are the specific conditions with which we will configure ZBF Policies in this lab.
If not specified, that traffic needs to be denied by default
© Santa_Clara Zone
1. Deny users at Santa Clara to access external FTP sites but allow everything else.
2. Allow users not at Santa Clara to access the TG-11411 FTP server but not the one
on TG-3511
© INTERNET Zone
1. Permit access for all protocols to connect to UBU-1
We will first focus on the Configuration and Policies for Santa Clara and Internet. The next
two Security Policy requirements are optional exercises; time permitting. Your instructor
will let you know if any or all of them should be completed in class.
© Mumbai Zone (optional)

1. Permit anything in the File Sharing application group to access all devices in TG-
3511’s subnet
2. Allow only hosts to reach any host on the Internet or at any other site
© Singapore Zone (optional)

1. Do not allow any pings outside the zone unless it is destined for one of the CSR
routers
2. Permit TG-1011 to ping CSR-3X
Note, the policies we create to satisfy the requirements of this lab are only one possible
way to solve the problem. There are many ways you accomplish the same thing. The
solution we’ll implement here is not necessarily considered a set of best practices, it is just
intended to illustrate how the ZBF works and some of the ways it can be used.
Task 5: Configure Policies for the Santa_Clara Zone
The first requirement is

to Deny users at Santa
Clara to access
external FTP sites but
allow anything else.
We will need to
configure two rules to
achieve this.
15. Click at the intersection

of From Santa Clara
and To INTERNET
16. Click Add Rule
© The Edit Rules screen appears. This creates two default rules for you.
— The first one (1000) matches everything and allows it.
— The second rule (65535) is a default Deny that matches everything.
— Any traffic that isn’t explicitly permitted by a previous rule will be dropped by
matching this one.
17. Click to edit rule #1000 - Match Everything

a. Select next to Application
b. Type ftp; the field will display all options
matching the string
c. Select Ftp from the dropdown
d. Click Save
Notice how the Match Criteria now shows FTP
18. Under the Action column, click on the dropdown for rule 1000 and change it to deny
19. Additionally, to meet the 2nd part of the requirement, change the action of the default
rule 65535 to allow
20. Click OK
A summary of the first two rules appears where From Santa_Clara and To INTERNET
intersect
© The second requirement is to allow users not at Santa Clara to access the TG-11411
FTP server but not the one on TG-3511. We should click on the same intersection,
right?
§ Actually no.
© Firewall rules are stateful, we need to configure a rule in the reverse direction.
21. Click on the intersection

of From INTERNET and
To Santa_Clara
22. Click Add Rule

The requirement is to be more selective towards particular hosts (TG-3511 and TG11411)
and not just for FTP to any device.
24. Click More Options
a. Select next to Application

b. Type ftp; the field will display all
options matching the string
c. Select Ftp from the dropdown
d. Select next to IP/Subnet
e. Select next to Source:Dest

£ Source: Any
£ Dest: 10.110.114.11/32
(TG-11411)
25. Click Save
© Refer back to the requirements for this zone pair. What is the next rule we need to
configure?
ANSWER: None, the only requirement was for sources on the Internet to be able to
reach TG-11411’s FTP server.
We don’t need a specific rule to deny FTP traffic to TG-3511. The existing implicit
policy, 65535 already covers that.
26. Click OK to close the Edit Rules screen.
The Security Policies matrix should now look like this
Task 6: Configure Policies for the INTERNET Zone
© What should be the FROM and TO Zones to meet this requirement?

ANSWER: We know that UBU-1 is in the INTERNET Zone itself based on our
topology. So that is the TO Zone
§ For the FROM Zone, there are should actually be three of them. Singapore,
Mumbai, AND Santa_Clara
This is because Policies are configured between a distinct, unidirectional pair of

zones.
© We will therefore need to create three rules in three separate Security Policies:
1) From Singapore To INTERNET
2) From Mumbai To INTERNET
3) From Santa_Clara To INTERNET
27. Click on the intersection of From Singapore and To INTERNET
28. Click Add Rule

a. Click More Options
b. Select next to IP/Subnet
c. Select next to Source:Dest

£ Source: Any
£ Dest: 11.1.1.11/32
(UBU-1)
30. Click Save
31. Click OK to close the Edit Rules screen.
32. REPEAT this task for Mumbai to INTERNET
33. For Santa_Clara to INTERNET it already Allows Everything and has a more specific
rule to Deny FTP.
a. You don’t need to do anything else.
b. When complete, your Security Policies Matrix should look similar to this:
34. Click Save to save the Security Policies we just configured to the
ZBF Policies Template Group
35. Click Save Template

Changes to confirm
36. Click Apply Template Groups
37. Select All Appliances in Tree View
38. Click the box to Add

ZBF Policies
39. Click Apply
40. Click Apply Templates to

confirm
Note: The security policies are not actually doing anything yet, because all the interfaces
and overlays are still in the zone ‘Default’. As a result, traffic is continuing to pass normally
because all intra-zone traffic (traffic between interfaces/overlays in the same zone)
is always permitted by default. That will begin to change in the next tasks when we
change the interface and overlay zones.
Task 7: FTP from TG-1011 to TG-2011

41. Return to the Remote Desktop session from your
Landing Desktop to TG-1011
a. If you closed it, simply reopen and connect to
TG-1011 again
42. Open Filezilla by clicking on its icon from the

Windows Taskbar
43. Connect to the FTP server on TG-2011
a. Use the following:
£ Host: 10.110.20.11
£ Username: anonymous
b. Click Quickconnect
The Directory listing should be successfu

l
Task 8: Apply Zone Labels to Interfaces
Now that we have Zone Labels created, we still need to specify what Zone each interface
belongs to.
44. Right-click on ECV-1 in Tree View

Notice, below, that now that Zone Labels are defined, a drop-down
option for the Firewall Zone becomes visible for both the LAN and
WAN interfaces
46. Configure all LAN and WAN interfaces for their security zone
as illustrated in the Topology Diagram.
a. LAN interfaces: (Zone is the same as Site Name)
£ ECV-1 Singapore
£ ECV-2 and ECV-3 Mumbai
£ ECV-4 and ECV-5 Santa_Clara
b. WAN interfaces: All in INTERNET Zone
47. Click Apply
48. In case it wasn’t clear above, or If you missed it, remember to

REPEAT this for the other 4 EdgeConnects
Task 9: Verify Security Policies are being used.
© Let’s validate that what we just configured

works. As a reminder, here are the
requirements àààà
49. Return to the Remote Desktop session from your Landing

Desktop to TG-1011
a. If you closed it, simply reopen and connect to TG-1011 again
50. Open Filezilla from the Windows Taskbar
51. Click Quickconnect
52. Click OK to abort previous connection.

It should no longer be able to connect.
53. Return to the Flows tab in Orchestrator
54. Click on the Clear button, in case you have any filters applied
55. Click on the refresh button to update the output
56. In the Flows table, search for ftp
Notice a flow in red should be displayed
57. Click on the Details icon
You can now see that the FTP traffic
action was Deny with a reason of Implicit
Policy. That is because the Source and
Destination Zones are different.
58. Close the Flow Details
OPTIONAL Exercises
© If you’d like to try and configure additional policies, try the following without any
instructions.
Task 10: Configure Policies for the Mumbai Zone (optional – time permitting)
1. Permit anything in the File Sharing application group to access all devices in
TG-3511’s subnets
¨ Open a CIFs shared network folder from on of the TG PCs Desktops
to TG-3511 to validate it works
2. Allow only hosts to reach any host on the Internet or at any other site
¨ Deny PING from the Cisco routers
Task 11: Configure Policies for the Singapore Zone (optional – time permitting)
3. Do not allow any pings outside the zone unless it is destined for one of the CSR
routers
¨ Test that TG-1011 can only ping CSR-20 and CSR-3X
¨ You should not be able to ping any of the other TG’s, Service
Provider Gateways (MPLS, Internet and 4G LTE) or WAN interfaces
of any ECV
REVIEW #13: Asymmetry & Flow Redirection
1) What is a TCP proxy?
2) Why must a flow be symmetric in order to be TCP accelerated?
3) T/F: With Flow Redirection the Silver Peaks tell the routers to redirect traffic to the
correct appliance
4) What information do Flow Redirection cluster peers exchange in their control

messages?
5) Do redirected packets traverse the same interfaces as the control messages in a

cluster?
6) T/F: Flow redirection peers should be in different subnets for high availability reasons.
7) Which device is the owner of a TCP flow in a Flow Redirection cluster?
8) Which interfaces can be used for Flow Redirection?
9) Flow redirection might fail in a properly configured cluster if

________________________________?
10) T/F: In Current Flows, redirected flows will be marked as such on the redirecting (non-
owning) peer.
LAB 10: Segmentation (VRF)

Overview
In this lab, you will enable segmentation, create segments, and assign LAN interfaces to
different segments.
Objective
© Learn to enable segmentation and configure your segmented network. After that, you
will learn how segmentation has affected routing and reachability, as mentioned in the
previous lab.
Task 1: Power Down ECV-5

We will not use ECV-5 in this lab.
1. Go to the VMWare ESXi tab in chrome
2. Select ECV-5 by clicking on the checkbox
3. Click on Power off
Task 2: Remove ZBF Policies Template from all Devices

Because each student may or may not have
done some of the optional exercises from the
Zone Based Firewall lab, we will remove the
ZBF Policies template.
4. Select all appliances in Tree View
5. Open the Apply Templates Groups tab: Configuration à TEMPLATES & POLICIES à
Apply Template Groups
6. Click on the box under the Remove column for ZBF Policies
7. Click Apply
Task 3: Reassign all Interfaces on all ECV’s to the Default Zone
8. Right-click on ECV-1 in Tree View
10. Configure all LAN and WAN interfaces for the Default zone
11. Click Apply
12. In case it wasn’t clear above, or If you missed it, remember to

REPEAT this for the other 4 EdgeConnects
Assign all interfaces to the Default FW Zone
13. Click
14. Repeat this for ECV-2
15. Repeat for ECV-3
16. Repeat for ECV-4
Task 4: Test connectivity from TG-11411 to TG-1011

17. Click on the Remote Desktop Icon from the
Windows Taskbar on your Landing Desktop,
18. Select TG-11411
19. Click Connect
20. Click on the Command Prompt icon from

the Windows Taskbar of TG-11411,
21. Ping 10.110.10.11
(TG-1011)
22. It should be successful
Task 5: Enable Segmentation on Orchestrator
NOTE: Even though we are using ECOS 9.0.6, which has Segmentation enabled by
default, the Segmentation feature has been disabled for the purposes of this class and lab
exercise.
23. Open the Routing Segmentation (VRF) tab:

Configuration à Networking à Routing à
Rouging Segments (VRF)
24. Click on the toggle

switch to enable
segmentation.
25. Click Save to

Confirm.
If you were doing this in a production network, you would definitely want to perform this
operation during a scheduled maintenance
window.
26. Return to the Routes tab on Orchestrator
27. Select the Default segment in the filter

field.
This is the filter selection for viewing the routes
in a particular segment.
© Notice that there is a new column called

Segment.
Right now there are

only routes in the
Default segment,
because we haven’t
created any other
segments yet.
© Until you change it, all interfaces, routes etc. are part of the same segment called
Default. This will not change until you add additional segments and change the
appliance configurations.
Important: Understand that a route is only part of one segment

So, it will only affect routing in the segment it is a part of.
Task 6: Create a Segment

28. Go back to the Routing Segmentation (VRF) tab.
29. Click +Add Segment
£ Segment Name: Seg_A

30. Click Save.
Keep in mind all appliances have interfaces only in the
default segment. No interfaces have been assigned to
other segments. Let’s do that next…
31. In the upper right corner Click on Orchestration ETA.
a. This time just wait until Done shows up for ECV-4,

then…
32. Click Close
Task 7: Assign ECV-1 and ECV-4 Interfaces to Seg_A

33. Hold the CTRL button and select both ECV-1 and ECV-4
34. Right-Click on ECV-4 in Tree View
35. Open the Deployment screen

Notice that there is a new field in the deployment profile for
each interface called ‘Segment’
36. Click Default to display the list of available segments.
37. Select Seg_A from the list to assign the lan0 interface to Seg_A.
Note that for the WAN interfaces, the segment selection is grayed out. WAN interfaces are
hardcoded to the Default segment and cannot be changed.
38. Click Apply.
39. REPEAT this Task for ECV-1
40. Wait for Orchestration to finish

again.
Task 8: Verify the Interfaces were added to Seg_A

41. In the upper right corner Click on Orchestration ETA.
a. Again, wait for Orchestration to finish (the list will go blank).
42. Close the window.
43. Click the refresh button.
Notice that there are now two appliances with interfaces in Seg_A.
The number of appliances with interfaces in Default

segment hasn’t changed. This is because ECV-4 still
has WAN interfaces in the Default segment.
44. If you followed the steps above, you have split

ECV-1 and ECV-4 into two segments:
a. Seg_A off of lan0
b. Default off of all wan interfaces
Task 9: Look at the routes in the Seg_A Segment

Remember the lan0 on ECV-4 is in the 10.110.114.0/24 subnet
45. Go back to the Routes tab in Orchestrator.
46. Highlight All in the Segment field at the top of the table.
47. Press the delete key
a. A list of all segments in the SD-WAN should display as well.
48. Select Seg_A

Clicking in the Segment filter field will allow you to display a specific segment from
the list of those that you’ve created (or All)
To emphasize: to select a different segment, you have to clear the field using the
delete or backspace keys to display the full list.
So what we just did was display all the segments configured by highlighting and deleting
the text in the field, then selecting Seg_A to see all the routes in that Segment of
interest. Refreshing the table is also a good idea, so…
49. Click on the Refresh icon

Now that we’ve filtered the Routes table to show only the Seg_A segment. We can
see that only ECV-4 has one interface (lan0) as a member.
Task 10: Re-test the Ping from TG-11411 to TG-1011

50. Ping from TG-11411 to TG-1011
a. Go back to the Remote

Desktop window for TG-
11411
b. Open a Command Prompt
session
c. Ping 10.110.10.11 -t
Why does it fail when it worked earlier in our lab? Segmentation you say?
Let’s ask our best friend…
51. View the Flows tab
As you probably expected, because we segmented ECV-1, lan0 and wan0 are in different
segments. So, as the Flows tab shows, there is NO ROUTE.
52. Let’s view the Flow Details. Click on

Notice, there is a Segments section now that appears.
53. Close the Flow details window.
Task 11: Fix Routing from Seg_A to the Default segment
Now that we’ve shown the 10.110.10.x subnet is in a completely different routing domain, just
like any other router, we need to configure a route for traffic to be forwarded
Did you notice the the 1 error next to ECV-4?
54. Hover over the error:

What happened to the BGP peer session? It was
ESTABLISHED before this lab.
55. Return to the Routes tab on Orchestrator
56. Click on the BGP button
57. Filter the Segment to show All segments

Remember you have to clear the entire field to display the list of configured segments
Recall we partitioned ECV-4 into two segments: One for

the Default segment and another for the Seg_A
segment.
You can see that the peer session to CSR-3X is in the

Default segment; which is off the wan interfaces.
We need to peer with CSR-3X on Seg_A
Task 12: Configure BGP for Seg_A

58. Click on the BGP tab.
59. Click on the Peers button.
Notice there is now a Segment column and it shows CSR-3X’s IP address in the Default
Segment.
60. Filter the Segment to show All segments

Remember you have to clear the entire field to display the list of
configured segments
61. Click on the Edit icon for ECV-4 Seg_A
62. Configure BGP Information
£ Enable BGP:
£ Autonomous System Number 65001
£ Router ID: 192.168.1.7

£ AS Path Propagate:
63. Click Add under BGP Peers
64. Configure Peer Parameters for CSR-3X
£ Peer IP: 10.110.114.1

£ Peer ASN: 65001
£ Admin Status: UP
65. Click Add
66. On the BGP Peers tab, click the Refresh icon
67. Wait until the Peer State on Seg_A is Established .
Task 13: Disable BGP for the Default Segment

68. Click on the Edit icon for ECV-4 Default
69. Click on the icon to Disable BGP for ECV-4 Default

70. Click Apply.

a. Go back to the Remote

Desktop window for TG-11411
b. Open a Command Prompt
session
c. Ping 10.110.10.11 -t
Why is the ping still failing?
72. On Orchestrator, go to the Flows tab
73. Hold the CTRL button and select both ECV-1 and ECV-4
74. Click the Refresh icon
© There is still NO ROUTE and ECV-1 is not seeing the flow at all.
75. Click on the Details icon
Remember with Segmentation, it is not only

separating physical routing, but also logical
transport domains. From the Flow Details we can
see that the Source and Destination Segments are
both Seg_A.
Let’s go back to basics.
© How do EdgeConnect Appliances share their locally connected networks?

Of course the obvious answer is Subnet Sharing! It is not automatically enabled on
new segments…
Task 15: Enable Subnet Sharing on Seg_A

76. Go to the Routes tab on Orchestrator
77. Click on the All button
78. Filter the Segment to show the Seg_A segment
79. Click on the Edit icon for ECV-1 Seg_A
© Notice Automatically advertise local LAN subnets is not checked!

80. Configure the Routes page as follows:
a. Click the following boxes:
£ Automatically advertise local LAN subnets

£ Redistribute routes to SD-WAN Fabric: default_rtmap_to_subsh
£ Filter Routes From SD=WAN Fabric With Matching Local ASN
£ Include BGP Local ASN to routes sent to SD-WAN Fabric

b. Click Apply
81. REPEAT THIS TASK for ECV-4

a. Go back to the Remote Desktop window for TG-11411
b. Open a Command Prompt session
c. Ping 10.110.10.11 -t
83. FINALLY SUCCESS!
Task 17: Validate Route and Flow Tables

84. Click Refresh on the Routes tab
© You can now see that ECV-1 and ECV-4 are learning their local routes from each
other in Segment Seg_A.
85. Go to the Flows Table
© Likewise, the Flows are now looking good
Nice Job!
You have completed all the labs in this course.
Appendix A: Connecting to ReadyTech for

Instructor-Led Training (ILT)
Students
1. The instructor will generate and assign Access Codes and will paste them in the Zoom
chat window or display them on screen.
2. Write down your access code here:
_______________________
3. You will need this code for the next two days
4. Connect to the lab portal at: https://silverpeak.instructorled.training
5. On the Login page enter the access code your instructor gave you.
6. Click Login
7. Enter your first and last name, then Click OK.
8. Click Lab at the top of the page.
Appendix B: Solutions to Common Issues

Restarting Orchestrator
Only do these steps if the Orchestrator fails to load in the browser. Ask your instructor for
assistance if needed.
1. Login to the VMware web Client.
2. Reboot the Orchestrator VM.

Note: Wait at least 3 minutes for the Orchestrator to reboot.
3. Refresh your browser to verify the Orchestrator login screen is displayed.

Note: Wait at least 3-5 minutes after the Orchestrator has finished its reboot to retest
connectivity as background process will still be bringing up the web UI
4. If the logon screen does not appear, contact your instructor.
Resolving Issues with Non-US Keyboards

1. The lab environment uses a US English keyboard by default.
2. The following directions will help you match the lab environment to your keyboard.
3. Log into the ReadyTech lab environment
4. Click on the Start on the Landing Desktop in the ReadyTech lab environment (not
your personal device).
5. In the Search box, type ‘keyboard settings’ then Click on ‘Change keyboards or other
input methods’
6. Note, Only if you can’t type ‘keyboard settings in the search box, do the following (if
you were able to search for keyboard settings, skip to the next step).
7. At the top of the ReadyTech browser window, Click ‘Desktop’, then ‘Enable viewer
toolbar’.
8. Mouse over the small tab that appears at the top of the page. It will expand. Under
‘Keys’, select ‘Open onscreen keyboard’.
9. Click Start again if
needed and then drag
the onscreen
keyboard over the
search menu. Click
on the keys to input
‘keyboard settings’ as
described above.
10. Click ‘Change

keyboards…’
11. Click Add
12. In this example we’ll add a French Keyboard
13. Scroll down to your language, in this case, French
14. Click “+” to expand the selection tree
15. Click on French under Keyboard
16. Click OK
17. Click Apply
18. Click OK
19. Click OK
20. Select your new keyboard
21. In the bottom right of the Landing Desktop in your browser window, Click on EN
22. Click to select your new language (in this case French)
23. Input should now be selected in your new language
INSTRUCTOR VERSION Template Version 2022.01 r1.4
Appendix C: 221 – ASD 9.x Lab Topology
192.168.1.x
192.168.1.x
192.168.1.x
192.168.1.x
192.168.1.x
INSTRUCTOR VERSION
Appendix D: Table of Usernames and Passwords
System/Platform User Password Notes
Landing Desktop Administrator Speak-123
VMware web Client root Training1!
TG-xxxx admin Speak-123 The PCs at the sites.
Kwanems K1-MPLS, K2-Internet, & K3-LTE root Speak-123
Orchestrator admin Speak-123
ECV-1, ECV-2, ECV-3, ECV-4, ECV-5 admin Speak-123 The default ID/PW is admin/admin
CSR-20, CSR-3x This password is used after

Speak-123
executing the enable command.
Windows hMail student@training.local Speak-123
UBU-1 student Speak-123 Use VMware console
202b - DST 9.0.x-9.0.x.RealTime.x SELF-PACED Lab Guide page 175 of 175

ASD - 9.04-v1.32 - Student and Lab Guide

Uploaded by

Copyright:

Available Formats

You might also like

ASD - 9.04-v1.32 - Student and Lab Guide

Uploaded by

Document Information

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

ASD - 9.04-v1.32 - Student and Lab Guide

Uploaded by

Copyright:

Available Formats

INSTRUCTOR VERSION

Advanced SD-WAN Deployments (ASD)

Version 1.31 - April 27, 2022

Advanced SD-WAN Deployments Lab Guide

Date: April 2022

Warranties and Disclaimers

Aruba, A Hewlett Packard Enterprise Company

LAB 1: Lab Familiarization and Licensing

© Familiarize yourself with the lab environment.

IMPORTANT LAB NOTES:

b. Follow the Step-by-Step Instructions.

c. Please read all notes below the lab steps.

£ This will help you avoid common error conditions.

£ Do not rely on screenshots for actual configuration.

Instructor-Led (221a) vs Self-Paced Instructions

221a: INSTRUCTOR-LED STUDENTS 221b: SELF-PACED STUDENTS

Follow these instructions if Follow these instructions if

Task 1: Access the ReadyTech Lab Environment

221a: INSTRUCTOR-LED STUDENTS 221b: SELF-PACED STUDENTS

Connect to the ReadyTech Connect to the ReadyTech

2. From your computer, navigate to

Task 2: Log into the Landing Desktop

Other Lab Notes:

a. Use the Esc key to exit Full Screen mode.

b. If you need to enter commands in a VMware console window,

3. On the Landing Desktop desktop, open Google Chrome by double-clicking on its

4. A security screen might appear with

a. This is the 1st browser tab for

c. Click Proceed to esxihost (unsafe).

£ You may need to scroll down a bit to see this one.

5. Login to VMware using the following:

8. Below that, Click on Virtual Machines button.

a. You should see the number 18 to the right of it

9. Confirm the following:

a. 18 Virtual Machines are shown.

b. All Virtual machines are in the state

If the lab has not fully deployed after 4 hours, contact

Click on Support in the navigation bar at the top of your

10. Select the checkbox next to

Task 4: Confirm Appliances have been Preconfigured

13. From the Chrome browser, Click on the

14. Another security screen may appear

15. The login screen for Orchestrator will

16. Log into Orchestrator

Do this Step only if a security screen appears with

B) Click Power off button

C) Wait a few seconds

D) Click the Power on button

17. If any software update or maintenance messages that

a. 3 Sites with the 0 appliances listed

Task 6: Run the Setup Script

æ Do not run this twice. It may take a few seconds to start.

a. Note: The script may take a several minutes to run.

24. All the steps should show Success

Task 7: Go back to the Landing Desktop Chrome browser to verify the

26. Return to Chrome on the Landing Desktop

27. Click on the Silver Peak Unity

This is a visual clue that you are on the