ASD 9.2 Lab Guide v1.8

INSTRUCTOR VERSION
Aruba Advanced SD-WAN

Deployments (ASD)
Lab Guide
for
ASDInstructor-Led
9.2 v1.8 – and Self-Paced
December versions of the course
1, 2023
ASD 9.2. Student Lab Guide v1.8 Do Not Replicate Page 1 of 211
DRAFT
Advanced SD-WAN Deployments Lab Guide

This course is based on Orchestrator 9.2.2 and ECOS 9.2.2
Date: December 2023

Copyright © 2023 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 Drive
Sunnyvale, CA 94089
https://inter.viewcentral.com/events/cust/cust_tracks.aspx?company_login_id=aruba&pid=1&track_id=43
DRAFT
Table of Contents
HANDS-ON LABS - PART A (ELEARNING STUDENTS ONLY) ........................................................ 5
LAB 1: LAB FAMILIARIZATION AND LICENSING DEVICES ............................................ 13
REVIEW #1: PATH AND ROUTE SELECTION & MONITORING ................................................ 28
REVIEW #2: POLICIES ............................................................................................................... 30
REVIEW #3: LOOPBACK INTERFACES .................................................................................... 31
LAB 2: CREATE ORCHESTRATED LOOPBACKS ............................................................ 32
REVIEW #4: INTERNET BREAKOUT AND TRAFFIC CLASSIFICATION ................................... 39
REVIEW #5: IP SLA .................................................................................................................... 40
LAB 3: LOCAL INTERNET BREAKOUT............................................................................. 41
REVIEW #6: OSPF ..................................................................................................................... 70
LAB 4: OSPF ..................................................................................................................... 71
REVIEW #7: BGP........................................................................................................................ 81
LAB 5: BGP........................................................................................................................ 82
HANDS-ON LABS - PART B (ELEARNING STUDENTS ONLY) ...................................................... 98
REVIEW #8: IP SLA .................................................................................................................. 109
REVIEW #9: ROUTE MAPS ...................................................................................................... 110
LAB 6: ROUTE MAPS ...................................................................................................... 111
REVIEW #10: REGIONS ............................................................................................................. 132
LAB 7: REGIONS ............................................................................................................. 133
DRAFT
REVIEW #11: SECURITY FEATURES ....................................................................................... 150
REVIEW #12: ZONE BASED FIREWALL .................................................................................... 151
LAB 8: ZONE BASED FIREWALL .................................................................................... 152
REVIEW #13: ASYMMETRY & FLOW REDIRECTION ............................................................... 169
LAB 9: SEGMENTATION (VRF) ...................................................................................... 170
REVIEW #14: QOS SHAPER ...................................................................................................... 184
LAB 10: CONFIGURE THE QOS SHAPER........................................................................ 185
REVIEW #15: IDS/IPS................................................................................................................. 195
LAB 11: CONFIGURE IDS/IPS .......................................................................................... 196
APPENDIX A: CONNECTING TO READYTECH FOR INSTRUCTOR-LED TRAINING STUDENTS

............................................................................................................................. 199
APPENDIX B: SOLUTIONS TO COMMON ISSUES ................................................................... 200
APPENDIX C: GETTING SUPPORT ........................................................................................... 207
APPENDIX D: USERNAMES AND PASSWORDS LAB ACCESS CODE ................................... 209
APPENDIX E: SUMMARY OF ORCHESTRATOR AND EC-V APPLIANCES .............................. 210
APPENDIX F: ASD LAB TOPOLOGY.......................................................................................... 211
DRAFT
Hands-on Labs - PART A (eLearning Students

Only)
This section explains the process to obtain a lab voucher and access the lab environment for ASD -
Part A (Labs 1 – 5).
eLearning Students Only: Please read this section and perform tasks outlined below.
Important Considerations for Obtaining Lab Vouchers

Do not obtain a lab voucher unless you have dedicated time to complete the labs.
• After redeeming a lab voucher, a 24-hour timer starts.
Access to the lab expires when the 24-hour timer runs out.
• On average it takes 4 – 5 hours to complete the labs in Part A or in Part B.
• Labs must be completed within the 24-hour activation window.
• Additional lab vouchers may be requested using the process outlined on the following pages.
Do not order multiple vouchers at a time. Order each voucher one at a time as you intend to
take the labs.
Lab Support
Aruba EdgeConnect Training Support
• Support for issues with the lab, the lab guide and the Orchestrator and ECV virtual machines.
Examples: appliance not registered, tunnel(s) down, connections not forming, etc.
• EdgeConnect Training Support is available Monday – Friday, 9:00 AM – 5:00 PM US/Pacific.
Emails sent to the EdgeConnect training team outside of these hours will receive responses
the following business day.
• For help, send an email to sp-training@hpe.com. Be sure to include the following:
1. Lab # and Lab Title
2. Your lab Access Code
3. Page #, Task #, and Step # in the Lab
4. Brief description of the issue and screenshot if helpful.
ReadyTech Support
• Support for lab environment issues – inability to login to lab desktop, problems with
applications on the lab desktop, lab freezing, etc.
• ReadyTech support is available 24 x 7.
• For help, send an email to get-support@readytech.com. You may also contact ReadyTech
support using the Chat option in the support menu. The ReadyTech support team does not
have knowledge of the lab or lab guide and only supports the virtual environment.
Note that solutions to common lab issues may be found in Appendix A at the end of the lab guide.
DRAFT
Materials
You will use this guide for all 11 labs in the course. Unless you have multiple monitors, it will be
inconvenient to use the PDF to complete the labs, therefore it may be useful to print this guide.
Printing the manual will allow you to keep the lab on your screen while you are following directions
and take notes on the printed copy.
We have found that if you only have a single screen and don’t print this manual, labs can take 30%
longer to complete, and students make 50% more errors because they are constantly switching back
and forth between the manual and the lab environment.
Lab Environment
Labs for this course are implemented in the ReadyTech hosted training environment.
IMPORTANT NOTE:
In order to access the lab, follow the process in the video "Hands on Lab - Part A" to request
a lab voucher through the purchase portal. There is a link in the video you click on to
acknowledge that you understand the process and request a lab voucher.
DO NOT REQUEST MORE THAN ONE VOUCHER!
Task 1: Click on the link in the video to acknowledge and request a

voucher
DRAFT
1. Click the link on the video screen to go to the lab purchase portal.
2. You will be taken directly to Advanced Aruba SD-WAN Deployments v9.2 – PART A
(Catalog ID: ASD v9.2 – PART A)
3. Click Add to Advanced Aruba SD-WAN Deployments v9.2 – Part A
cart. Advanced Aruba SD-WAN Deployments v9.2 – Part A
ASD v9.2 - PART A

202b-DAST Labs 1-9
4. Click Check
out. Advanced Aruba SD-WAN Deployments
v9.2 – Part A
ASD v9.2 - PART A
5. Fill in your contact

information using the
same name and email
that you used to register
for the course.
DRAFT
6. Then click Next.

Note: A correct
email address is
required for you to
receive your
voucher.
Fill in your correct

First and
Surname
Fill in your
company name
Deploying Aruba SD-WAN Technologies v9.2 – Part A
Fill in the Email you
used to register Advanced Aruba SD-WAN Deployments v9.2 – Part A
for this course in

the Aruba
training portal
If this is incorrect it
will make it difficult
for you to get
support if needed.
7. Click Next
8. Check the
acknowledgement checkbox.
Aruba will be billed. Your cost is
$0.00 as shown
.
9. Click Place order.
ASD 9.2 – Part Advanced Aruba SD-WAN

10. A Purchase confirmation will A 2023.08 Deployments v9.2 – Part A
be displayed.
Close the window.
Task 2: Redeem the Lab

Voucher
DRAFT
Check your email. Find and open the email containing your voucher information.
11. When you are ready to start

the lab, click Redeem Now.
You will be taken to the training

lab environment.
Advanced Aruba SD-WAN Deployments v9.2 – Part A
12. Make sure to

select your local
time zone.
Aruba Advanced SD-WAN Deployments v9.2 – Part A

13. Click Redeem.
14. Fill in your personal information - Input the Email you used to register for this
course in the Silver Peak training portal.
a. If this is incorrect it will make it difficult for you to get support if needed.
DO NOT ENABLE PASSWORD PROTECTION!
DRAFT
15. Check the consent box in the lower

left
16. Click OK to activate the code.
You should now be in the Aruba

Self-Paced Training portal.
17. Watch the Getting Started Video for

a detailed description of features of
the lab environment.
Name: DAST v9.2 – Part A
18. When the video launches, Click

the icon in the lower right to
watch it full screen
19. Close the video when you are

done.
DRAFT
Name: ASD v9.2 – Part A
20. Select Lab on the top menu.
When you are ready to begin, click Start lab now.
You will have one day (24 hours) of access time beginning when you click ‘Start the
lab’. If you do not start the lab within a few hours, you will not have time to complete
it. All Aruba EdgeConnect labs are designed to be completed within 4-5 hours.
21. Click Start now.
DRAFT
Note: Although the message says it may take up to xxx minutes to start (150 in the screen
shot below), your wait should only be 5-10 minutes as machines are deployed from a hot
standby pool.
However: If demand is high and all the machines in the pool have been deployed, you may
have to wait the full length of time for your lab to fully deploy.
An Action in progress message will display.
22. Click Close.
An Action result message will

display.
23. Click Close.
The Status display should change to Up when

the lab is loaded and deployed. If it does not
change to up within 15 minutes, there is
probably a fresh server loading from scratch,
and it might be a couple of hours until it
changes to UP. You may see an interim status
of Partially Up. If it has not changed to UP
within 2 ½ hours, contact ReadyTech
support.
Note: The display of ‘UP’ does not necessarily mean the lab is fully deployed. It simply
means that login is possible. In a later step we will check to make sure all the virtual
machines required to complete the lab are fully deployed.
Do not click “Click here to connect”. Instructions to connect to the lab environment are in
the next lab.
DRAFT
LAB 1: Lab Familiarization and Licensing

Devices
Overview
In this lab, you familiarize yourself with the lab environment, license the Orchestrator and the
appliances, and register them with the Aruba Cloud Portal.
Estimated time: 20 minutes
Objectives
 Familiarize yourself with the lab environment.
 Verify the Landing Desktop deployment by reviewing the virtual machines.
 Confirm the Orchestrator and five EC-V appliances are powered on in the ESXi host.
 Run the setup 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 helps you avoid common error conditions.

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

 If written instructions and the screenshot differ, follow the written
instructions.
DRAFT
ASD Lab Topology
Another copy of the ASD Topology is located on the Landing Desktop in the ASD Lab Files
folder.
Task 1: Connect to ReadyTech

The instructor will generate lab codes for you and paste them into the Microsoft Teams chat.
1. Write your access code here:
2. From your computer, navigate to https://silverpeak.instructorled.training/
3. Appendix A has detailed connection instructions if needed.
Task 2: Review the Lab Topology

4. You can view the Lab
Topology PDF from the
Landing Desktop.
The third tab in Google
Chrome opens the same
lab topology diagram.
DRAFT
Task 3: Log in to the Landing Desktop

5. Click on the login panel. It shows the Administrator login page.
 Password: Speak-123
ReadyTech provides several viewing options from the Desktop drop-down menu such as Best fit,
Scale to fit, Detach window, and Full-screen mode. Use the one that works best for your display.
Other Lab Notes:

b. Use the Esc key to exit Full-Screen mode.
c. If you need to enter commands in a VMware console window

and find that incorrect characters are displaying, you might
need to use the onscreen keyboard.
1) Use the menu shown and select “Enable viewer toolbar.”
2) From the viewer toolbar, enable the onscreen keyboard.
3) Drag the keyboard over the console window. It might be
necessary to position the keyboard so the letter you
want to type is directly over the active area of the
console window.
DRAFT
Task 4: Verify All Virtual Machines Are Set Up
6. On the desktop of the Landing Desktop, open Google Chrome using its icon in the
taskbar or the desktop.
7. A security screen might appear with

“Your connection is not private”:
a. Open the browser tab for the

VMware ESXi.
b. Click Advanced.
c. Click Proceed to esxihost (unsafe).
 You might need to scroll down a bit

to see this.
8. Log in to the VMware ESXi host using the following:
 Log in as: admin

Speak-123
DRAFT
9. Click Log in.
10. At the top-left, if not yet

expanded, click the Navigator
button
11. Below that, click the Virtual Machines button.
a. You should see the number 18 to the right of it in a grey

box.
b. In the pane to the right, click the Virtual machine column
of the table to Sort it until the first device listed is
Landing_Desktop.
12. 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
DRAFT
If some are in the powered off state, turn them on one at a time.
13. Select the checkbox next to

its name.
14. Click Power on or the
button if needed.
15. Repeat for any additional
VMs that need to be
Powered On.
Verify that each VM has a green, powered-on icon, next to it. Use the refresh button after a
couple of minutes to verify all VMs have obtained IP addresses. If any of the VMs aren’t
powered on notify your instructor (instructor-led) or contact sp-training@hpe.com (self-paced).
DRAFT
Task 5: Confirm appliances have been preconfigured
16. From the Chrome browser, open a new tab and click the Orchestrator bookmark to
log in to the Orchestrator.
17. Another security screen might 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 might need to scroll

down to see this.
18. The login screen for Orchestrator will

then be displayed
19. Log in to Orchestrator:
 Log in as: admin

DRAFT
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 might need to be rebooted or started
1) Return to VMware.
A) Select the checkbox next to its name
B) Click the 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 suitable 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.
DRAFT
20. Click close, dismiss, or do not show me again for

any software update pop-ups.
21. Verify the following:
a. 3 Groups - 0 appliances in the Appliance Tree
 Site 1: Singapore
 Site 2: Mumbai
 Site 3: Santa Clara
b. Preconfigure Appliances tab lists all 5 ECVs
 Their Status should be: Pending Discovery

c. The upper right side will not show any alarms
Task 6: Access the Landing Desktop with this Windows navigation tip
22. You can get back to the desktop quickly
by Clicking on the desktop icon next to
the magnifying glass (beside the Windows
Start button).
This toggle button will allow you to easily hide/unhide active windows to view the lab
topology.
DRAFT
23. Run the ASD Setup located in the ASD Lab Files
folder on the Landing Desktop
24. Double-click ASD Setup ONCE to
run the setup script.
a. Do not try to run this twice. It
might take a few seconds to start.
b. You can only run this script
once. It is disabled after the first
run.
25. The script runs and generates a Command Prompt window.
a. Note: The script might take several minutes to run.
26. When the script completes, it will display the ASD Lab 1 – Setup Log.txt file.
27. All the steps should show Success
28. Click on the black Command Prompt window and Press any key to continue.
a. Close the Notepad file.
DRAFT
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 Lab Guide on the
Student Landing Desktop.
 If you haven’t noticed yet, the Windows Task Bar and application windows
are dark blue green, to help indicate you are working on the Landing Desktop
29. Return to the Chrome browser on the Landing Desktop
30. Click on the Aruba Orchestrator tab (second one).
This is a visual clue that you are on the Landing Desktop and not your PC.
31. The Appliances Discovered button will appear

but DO NOT click it. It will disappear in a moment.
32. Select the Preconfigure Appliances tab
33. Refresh the display by clicking the refresh

icon next to Export
34. The preconfiguration process will take about 8 -15 minutes to complete.
Continue with the next steps on the next page.
DRAFT
a. After 10+ minutes, appliances will show Finished under the Status column. Close
the Preconfigure Appliances Tab. There might be various Alarm boxes and blue
cloud icons next to each ECV in the Appliance Tree.
During the next 10+ minutes, the appliance tree will show the devices cycling through
various alarms from Cyan to Gold to Red. This is normal as the devices are establishing
tunnels.
35. the appliance tree will show 3 groups with 5 ECVs:
 Site 1 - Singapore: ECV-1

 Site 2 - Mumbai: ECV-2, ECV-3
 Site 3 - Santa Clara: ECV-4, ECV-5
Warning: Alarms / Errors may be seen after running the script to build the lab.
36. When Orchestration is complete, there should not be any tunnel errors.
NOTE: If you see you can ignore it and move on.
37. Due to a lab environment issue, you

may see a major alarm at site 2
(ECV-2 or ECV-3) stating the the
gateway 169.254.1.254 is
unreachable.
DRAFT
This alarm will

be accompanied
by a default
route route
down. The next
hop for the down
route is also
169.254.1.254.
You can safely ignore these alarms which will disappear when the deployments are
reconfigured to add labels on the LAN interfaces.
Task 8: Verify the Orchestrator can reach the Cloud Portal and is
registered
38. 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 might have been changed to portal.silverpeak.cloud which is valid
also.
39. It should show
 Registered: YES
 HTTPS: Connected
 WebSocket: Connected
40. Click Generate New Key to update your Account

Key.
DRAFT
41. Click Generate New Key and Distribute
42. Click on the X to close the yellow success

message
43. Click Close on the Cloud Portal Licensing window,
Task 9: Review the Basic Layout in Orchestrator

44. You are managing the 5 appliances that appear in the appliance tree.
a. 3 Sites – Singapore, Mumbai, & Santa Clara
45. View Business Intent Overlays
a. Highlight all 5 appliances in the

Appliance Tree
b. Open the BIOs tab – Configuration
→ Overlays & Security → Business
Intent Overlays
 We are using the 4 default overlays.
46. Click on Apply Overlays
Notice that all the

appliances have all the
overlays applied.
DRAFT
Task 10: Add Data label to LAN interfaces on all appliances.
47. Right-click on ECV-1

in the Appliance
Tree and click on
Deployment.
48. Click on the drop-
down for the LAN
interface label and
select Data.
49. Click Save.
50. Repeat this task on ECV-2, ECV-3, ECV-4 and ECV-5.
Note that after reconfiguring the LAN Labels, the gateway alarm and route down for
169.254.1.254 will disappear.
DRAFT
REVIEW #1: Path and Route Selection &

Monitoring
1) What are the 3 protocols supported by EdgeConnect appliances for exchanging
routing information?
Subnet Sharing, OSPF, and BGP
2) T/F – EdgeConnect can exchange routes with a Cisco Router via Subnet Sharing
FALSE (OSPF and BGP = True)
3) T/F – In a subnet table, all else being equal, the route with the lowest metric is
preferred.
TRUE
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
Appliance B – it is a longer match than A (Metric would only matter if both routes were identical)
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)
Appliance A (Routes are identical, the one with the lower metric is used)
6) Is it possible for a static route to only be applied to LAN-to-WAN traffic? If so, which
tag would it have?
YES – tag = “From_LAN”
7) T/F – An appliance can advertise a route that it doesn’t use to route traffic.
YES – An Advertise Only route (static route configured with no next hop)
8) How can you determine if an appliance has a route to a destination without testing it
with traffic?
Use the “Find Preferred Route” button in the Routes configuration screen.
9) T/F – You should always use Reset All in the flow table to make sure a connection
gets reset
FALSE – Reset only the flows that need it.
10) T/F – “Inbound’ traffic is coming from the LAN into the EdgeConnect
FALSE (Inbound = from WAN to LAN; Outbound = from LAN to WAN)
DRAFT
11) T/F – An appliance uses the management routing table to route traffic between two
end devices at different sites
FALSE – Management routes table used for self-generated traffic
12) How do you make sure an appliance knows all the external IP addresses that can be
used to reach the Orchestrator
Define the addresses and associated interfaces in Orchestrator Reachability
DRAFT
REVIEW #2: Policies

1) What are the Four Policy types and what do they do?
Route, QoS, Optimization, and Security
2) T/F: Built-in optimization policies are in the 10,000 range and will be applied to
unboosted traffic.
FALSE = Yes in that range, but not applied to unboosted traffic.
3) What numeric range do Overlay created policies fall in?

20XXX
4) What is the default rule number in any policy map?

65535
5) Why would you create a manual route policy?

If you have an exception to the policies automatically created by the BIO configurations
6) Is traffic matching an overlay that is boosted always treated the same? If not, why?
No, it is treated differently if it is internal (boosted through an SD-WAN tunnel) vs. external (no boost to the Internet)
7) What is the default action for traffic flowing between two different security zones?
Implicit Deny
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 same traffic.
FALSE – 65506 is a Built-in policy that will always be processed before any rules even if they have a lower priority.
DRAFT
REVIEW #3: Loopback Interfaces

1) T/F: Loopback interfaces are a hardware option only available on physical appliances.
FALSE – Logical/software interface available on any EC Appliance
2) T/F: Loopback interfaces cannot be configured directly on appliances.

FALSE – They can be configured directly on the appliance and then edited later. They can also be orchestrated, but then
cannot be edited later.
3) Can more than one group of orchestrated interfaces be created with different interface
and security zone labels?
YES, multiple Loopbacks can be orchestrated with different labels and FW zones – all will come from the same pool of
addresses.
4) What must orchestrated loopback groups have in common?

The same IP Subnet pool
5) If you decide to use a loopback interface for management, what do you need to do for
this to work properly?
You must disable/unplug the mgmt0 interface
6) Where will a loopback interface used to manage the appliance look for routes to direct
self-originated traffic?
The data-path routes table is used when managing in-band via loopbacks
DRAFT
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.
Estimate time: 15 minutes
▪ 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

20 - 30 minutes after running the ASD Setup script, all five sites should be configured with
tunnels built to them with no alarms, as shown above.
1. Go to Monitoring→ Summary→ Alarms
2. Click Select All in the upper right of

the Alarms page
3. Click Clear and confirm Clear Only.
DRAFT
4. Click Clear only
5. Close the Alarms tab
6. There will be a major alarm on ECV-2 or ECV-3 stating that gw: 169.254.1.254 is
unreachable. This is a cometic alarm that occurs in pour lab environment and can
safely be ignored
Task 2: Configure a loopback orchestration range

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

Configuration → Networking → Loopback
Orchestration.
9. Click on +Add Loopback Interface
10. Click on Add
DRAFT
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 nearly all cases you SHOULD CHANGE THIS DEFAULT
because that subnet is likely 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.
DRAFT
15. In the upper right, Click on the

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 Loopback

Interfaces tab: Configuration → Networking →
Loopback Interfaces.
Notice that the Orchestrator has created a loopback interface on every machine from the
configured range, and assigned a /32 IP address. Host address for the 5 appliances is
“.1” through “.5”. note that the addresses may not be assigned in sequential order on the
appliances.
DRAFT
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 might 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.
Addresses may not be sequential.
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 more of the following:
 This table to the right Appliance

Loopback
Address Table
 In the ASD-Topology & Logins ECV-1
PDF located in the ASD Lab
Files folder on the Landing ECV-2
Desktop
ECV-3
 In the Topology Diagram
ECV-4
located in Appendix F at the
end of this student guide ECV-5
DRAFT
Task 3: Test reachability between two of the loopback interfaces
21. Right-click ECV-1 in the appliance tree 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>
DRAFT
DRAFT
REVIEW #4: Internet Breakout and

Traffic Classification
1) T/F – An EdgeConnect can snoop DNS lookups and cache the results for domain
based packet classification.
TRUE – First Packet IQ
2) T/F – As part of its First Packet iQ classification strategy, EdgeConnect appliances

maintain a cache of millions of domains and addresses that is dynamically updated.
TRUE
3) What is used to determine internet reachability, and whether breakout should be

attempted by the appliance?
An IP SLA pinging an internet IP address / URL.
a b
4) What is the difference between the Policy Order A and B as shown?

A = First break out locally, if not possible, then backhaul; B = First try to backhaul, if not possible, then breakout locally
5) T/F – It is necessary to choose at least two primary labels to load balance breakout
traffic across multiple internet service providers?
TRUE – Cannot load balance over a single link.
6) What is the difference between Waterfall and Balanced link Selection?

Waterfall = Fill up best link first and then spill into second best. Balanced = load balance across the links per flow.
7) How does an appliance determine if traffic should be eligible for Local Breakout
(assuming all links are up)?
Deciding if the destination address is Internal or External
DRAFT
REVIEW #5: IP SLA

1) Can an IP SLA cause subnet sharing to stop if an interface goes down?
YES, one of the available actions is to stop subnet sharing
2) T/F – By default 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.
FALSE – By default the addresses are ORed so if one is reachable, it is considered up.
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.
TRUE – Raising/clearing alarms are among the available actions
4) What should you use if the website you’ve chosen to monitor for reachability blocks
ICMP traffic?
HTTP/HTTPS
DRAFT
LAB 3: Local Internet Breakout

Overview
We have diverse types of traffic 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.
Objective
 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 the appliance tree
2. Go to the Flows tab.

Monitoring → Bandwidth → Flows
→ Active and Recent Flows
DRAFT
3. Click the Clear button to eliminate any current filters.

For instance, 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.
a. Select TG-1011 for the Computer
b. Click Connect
5. If the Remote Desktop Connection security

pop up appears, click on the for “Do you
want to connect despite these certificate
errors?”
6. Click Yes
DRAFT
7. Click Ask Me Later
8. Ignore, cancel and close any Windows

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

a command prompt window.
 You might 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.
Note the IP addresses in the

screenshot to the right will be
different than your network.
DRAFT
11. On the Orchestrator. View the flows in the flow table.
a. Click the Refresh icon.

You should see something like the following:
Note: If you don’t see anything, use the clear button to clear any preselected filters in the
flow table, then refresh your view. Also, make sure you have all appliances highlighted in
the Appliance Tree.
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. From the command prompt on TG-1011, 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.
DRAFT
a. In the Search field, type 11.1.1.11.
14. Refresh the flows as needed
15. Look at the outbound tunnel for ECV-1 in the flow table – it says Policy Drop.
a. Which Overlay is the flow hitting? _DefaultOverlay_________________________________
16. Open the flow detail by Clicking 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.
DRAFT
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 the appliance

tree
b. Go to the Routes tab: Configuration

→ Networking → Routing → Routes
DRAFT
19. In the Search bar, type 11.1.1.11
 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.
a. 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 Definition
DRAFT
Note: The menu selection opens the Internal Subnets

table. Packets with a destination IP address in one of
these subnets will be sent via an overlay tunnel.
External networks are defined as not being 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.
a. 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 the
BIOs configuration tab: Configuration →
Overlays & Security → Business Intent Overlays
DRAFT
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.
DRAFT
 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 in 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)
▪ If the connections to the data center are down, then 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 EdgeConnect appliances.
29. Configure the RealTime Overlay
DRAFT
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.
c. Click OK.
DRAFT
33. Configure Internet Breakout for the CriticalApps overlay the same way
a. Click OK to save.
34. Configure Internet Breakout for the BulkApps overlay the same way
a. Click OK to save.
THIS NEXT ONE IS DIFFERENT!

35. 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:
b. Drag INET1 from Available Interfaces into the Primary interfaces field.
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 first choice, and only broken out locally as a second choice if there is no route or path to
backhaul it.
36. Click OK on the Default Overlay Configuration.
DRAFT
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.
DRAFT
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.
42. Close Orchestration Progress
Task 6: Test Local Internet Breakout.

Now we will try to retest internet breakout by pinging UBU-1 on the Internet.
43. 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
The Ping is now

successful.
To verify if Internet Breakout can take place, the appliance needs to know if the Internet is
reachable. The Global IP SLA is used to verify Internet reachability by pinging addresses on
the Internet. By default, three targets are used: isp-ipsla.silverpeak.cloud, 8.8.8.8 and
8.8.4.4. These targets may not work in your network or you may have a different target that
is cricitical to your business. You can edit the default values and enter the targets of your
choice. By default the target addresses will be “OR”ed – meaning that if any one of the
addresses is pingable, the Internet is considered reachable. You can choose the “AND”
option so that all targets in the list must reachable in order for the Internet to be considered
reachable. In the task below, you will add 11.1.1.11 to the ip address targets in the Global IP
SLA. 11.1.1.11 is the UBU-1 server which is located on the “lab Internet”.
DRAFT
Task 7: Configure the IPSLA rules with UBU-1 address
44. Return to the

Business Intent
Overlay tab
45. 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.
46. Click the edit icon next to Break Out Locally Using
These Interfaces
The default entries in the Global IP

SLA are: sp-ipsla.silverpeak.cloud,
8.8.8.8 and 8.8.4.4
ip-sla.silverpeak.cloud,8.8.8.8,8.8.4.4,
47. Add 11.1.1.11 to the list 11.1.1.11
a. Separate the addresses by a

comma with no additional spaces.
NOTE: As mentioned above, this is a

global setting that affects all overlays.
48. Click Save
49. Click OK to close the Overlay Configuration dialog window
DRAFT
50. Observe the Orchestration status as you did

above
51. Return to the RDP window you have open on

TG-1011
52. Retry the ping to

11.1.1.11.
The ping should again be
successful..
Note: It might take a few

minutes for the Overlay
manager to become aware
of the routing to changes
due to IPSLA changes.
53. Look at the flow in the Flow table
54. If you don’t see the flow, retry the ping and refresh the display. It might be necessary
to Click the Clear button also to clear any cached search filters.
DRAFT
55. Click on the details icon to open the flow detail
Checkpoint
Which Overlay does the flow match? ______________________________________
Which tunnel does the flow take? ___________________________

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 might not always be the case.
DRAFT
56. Close the flow detail
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).
a. Why do you suppose the traffic is not being backhauled?

There is no default route being learned from another EC-V
Let’s do some troubleshooting…
Task 8: Verify tunnels are up to the other sites
57. Select only ECV-1 in the appliance tree
58. Go to the tunnels tab:
Configuration → Networking →
Tunnels → Tunnels
59. Select Overlay tunnels
a. Overlay tunnels should be up

for all overlays to all the
other sites
The screenshot is sorted by

the Type column to get the
arrangement it shows.
DRAFT
Task 9: Verify if ECV-1 has a route to backhaul the traffic

60. Return to the Routes tab
a. Make sure you are viewing all routes

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
the DefaultOverlay.
 Because there is no route to the destination network:
▪ Local Internet breakout is working properly
▪ ECV-1 will take the second 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.
In the next task, we will configure a default route at Site 3 so that the traffic can be
backhauled as we intended.
DRAFT
Task 10: Default Routes on the data center appliances

Add a default route to ECV-5 to the next hop on the internet using the metric of 53.
61. From the Routes tab, select only ECV-5 in the appliance tree
62. Click the edit icon next to ECV-5 in

one of the items in the table
63. Click Add Route
DRAFT
64. 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
65. Click Add
66. Click Save on the Routes – ECV-5

dialog
DRAFT
67. The Route should appear in ECV-5 Routes table with a metric of 53.
68. Test the Ping on TG-1011 again
a. Select all the appliances in the

appliance tree
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.
69. Return to the Flows tab to look at the flows in the flow table
70. Examine the flow details for each of the 3 flows:
 The flow is now working...
▪ 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 two flows)
DRAFT
71. In the Appliance Tree, select ECV-5 and let’s take another look at ECV-5’s routing
table like we did above
72. Sort on Subnet/Mask to get the default routes at the top
a. Why is ECV-5’s new static default route being used instead of the local default
route?
b. 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 251 – designed to be used as a last resort.
b. We wouldn’t use the Auto (System) 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

74. Click the edit icon next to ECV-4 in one of the items in the table
DRAFT
75. Click Add Route
76. 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
77. Click Save
78. Click Apply on the routes – ECV-4 dialog
DRAFT
79. The Route should appear in ECV-4 Routes table
80. 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
81. Select all appliances in the appliance tree
82. Go to the Flows table and Filter the returned flow by entering “11.1.1.11” in the
Search field.
11.1.1.11
DRAFT
83. 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 two flows)
a. Why is this flow now going through ECV-4 instead of ECV-5?
Answer: This happens because the route via ECV-4 has a better metric..
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.
DRAFT
84. Go to TG-1011’s RDP desktop
85. Click the FileZilla icon on the taskbar at the bottom of the
window next to the start menu
86. Access UBU-1 (to reiterate from TG-1011’s RDP Window)
 Host 11.1.1.11
 Username student
 Password Speak-123
87. Click Quickconnect on the right
88. Highlight the Desktop directory on the Local Site
89. At the Remote site, you should see TestFile in its remote
directory (lower right)
DRAFT
90. Click and Drag TestFile to the Local Site’s Desktop (lower left
91. Highlight ECV-1 in Orchestrator’s Appliance Tree
You may need to click the Refresh button in the Flows tab to see the FTP flow.
92. Go to the Flows tab in Orchestrator.
93. Open the flow detail for the FTP flow (click the icon in the Detail column)
a. Which overlay did it use? ___________________________
b. Which tunnel did it use? ____________________________
DRAFT
 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.
94. Return to TG-1011’s Desktop
95. Close FileZilla on TG-1011’s desktop.
96. Delete the TestFile
DRAFT
REVIEW #6: OSPF
1) T/F: OSPF is a path vector protocol

FALSE = Link State protocol
2) Is it necessary to configure which OSPF neighbors you will connect to?

NO – only configure an interface and the neighbors will be discovered
3) Which device becomes the Designated Router on a broadcast multiaccess network

(e.g. ethernet)?
Usually the first one connected to the network (nobody else connected to vote against it). You can manipulate which router
is the DR using OSPF Priority.
4) T/F: It is necessary to define which interfaces on an appliance will participate in OSPF

YES – that is how neighbors are discovered
5) What metric is used by OSPF routers (and appliances) to determine the most
desirable path, and how is it determined?
Metric = Cost; cost is based on the bandwidth of the interface – but metrics can be reconfigured
6) How many OSPF Areas can an appliance be a member of?

Right now = 1 (area 0). Multi-area OSPF not currently supported
7) Can an appliance be an ABR (Area Border Router) or ASBR (Autonomous System

Boundry Router?
ABR = NO (multi-area not supported); ASBR = YES (one of your OSPF routers can also connect to the Internet
8) What state in an OSPF peer adjacency indicates they have sent and received routing
information?
FULL = neighbors are converged and ready to route.
9) Does turning on BFD on an appliance enable BFD for OSPF connections?

NO – BFD must also be enabled in the OSPF interface configuration
DRAFT
LAB 4: OSPF
Overview
In this lab, you will configure the appliances in Mumbai to form an OSPF adjacency with
AOS-CX-2.
 The appliances will advertise subnets learned through subnet sharing between
appliances to the Aruba AOS-CX switch 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 Aruba AOS-CX switch, 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 the Mumbai LAN router, AOS-CX-2. You will only
need to add the OSPF configuration to ECV-2 and ECV-3.
Objectives
 Learn to configure OSPF adjacencies.
 Observe some potential 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 the appliance

tree
DRAFT
2. Open the OSPF tab: Configuration →

Networking → Routing → OSPF
3. Click on the edit icon

next to ECV-2 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
DRAFT
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 Save to apply the configuration
DRAFT
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
 Accept the other default values
15. Click Add
DRAFT
16. Click Save to apply the configuration
Task 3: Review the OSPF configuration screens
17. From the OSPF tab, click the Summary button
a. Refresh the screen if needed. It might 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.
DRAFT
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 should be 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 drop-down arrow next to the refresh button and click on Refresh from
appliance to refresh the Interface State.
20. 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 AOS-CX-2 (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.
21. Close the details screen.
DRAFT
22. 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 AOS-CX-2 (RID 2.2.2.2), 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.
23. 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).
DRAFT
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 AOS-CX-2
24. Go to the Routes tab
25. Click on the OSPF button to filter the table for only OSPF routes
26. Type 10.110.20 in the Search field
Note that both ECV-2 and ECV-3 have learned the 10.110.20.0 subnet from AOS-CX-2
(10.110.107.1).
Why is the metric 101? ______________________________________________
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 uses a default link cost
of 1 for their lan0 interfaces. The AOS-CX-2 also uses a link cost of 100 for the interface
that connects to the destination subnet, and these are added together by the appliances
to determine the metric for the route.
DRAFT
Task 5: Check for learned routes on AOS-CX-2
27. Click the PuTTY icon on the taskbar of the Landing Desktop
28. Double-click the Saved Session for AOS-CX-2
Isn’t double-clicking on the Saved Session much faster

than highlighting it… then… clicking… Open? ☺
29. Log in to AOS-CX-2
• Log in as: admin
• Password: Speak-123
30. Type show ip ospf neighbor to view the adjacencies to ECV-2 and ECV-3.
DRAFT
31. Type show ip route ospf to view the routes learned from ECV-2 and ECV-3.
 There six are routes being learned from ECV-2 (10.110.107.101) and from ECV-3
(10.110.107.102) – each with the default OSPF Admin Distance (110) and the default
Subnet Sharing metric (50). The host address for the loopback networks
(10.111.111.X) have been obscured as the addresses in your network will be
different.
 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 the subnet from Site 1 – Singapore
(10.110.10.0//24). Wait a second… Sites 1 is not configured for OSPF. How were
these routes learned?
Answer: If you said, Subnet Sharing, then you are correct! Subnet shared routes
are redistributed into OSPF by default.
DRAFT
REVIEW #7: BGP
1) T/F – Aruba EdgeConnect appliances support only iBGP.

FALSE – both iBGP and eBGP
2) Do EdgeConnect appliances propagate AS-Path information via subnet sharing?

YES – this is a configurable option
3) Which learned prefixes will a BGP router advertise to an iBGP peer?

Locally attached prefixes and eBGP-learned prefixes
4) Which learned prefixes will a BGP router advertise to an eBGP peer?

Locally attached and prefixes learned from iBGP peers
5) What are the two BGP Peer types and what is the difference between them?
Branch – used to connect to a LAN site (iBGP or eBGP); PE = connects to Service Provider router (eBGP)
6) On the Peer Configuration, what two other items should match the configured peer
type?
Inbound & Outbound route maps
7) Which state indicates that a BGP peer has connected completely and an appliance
and can learn and advertise routes to it?
Established
8) Is it possible to connect two EdgeConnect appliances at different sites as BGP peers?

YES – use a Virtual Tunnel Interface
9) Where in the BGP configuration is BFD enabled?

In the Peer configuration
DRAFT
LAB 5: BGP
Overview
In this lab, you will configure the appliances in the SANTA CLARA site to iBGP peer with the
Aruba AOS-CX-3 switch.
Estimated Time: 60 minutes
 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
AOS-CX-3.
 In our lab, ECV-4 and ECV-5 will be iBGP peers with AOS-CX-3.
 We will use iBGP configuration to illustrate a few points throughout the rest of the
course.
 Currently, none of the appliances have a route to the 10.110.35.0/24 subnet on the
Site 3 LAN. AOS-CX-3 is the only one with a route to 10.110.35.0/24.
Objectives
 Learn to configure BGP peering.
 Observe some potential problems you could encounter and learn how to avoid them.
DRAFT
Task 1: Test Connectivity on TG-3511 on

the LAN side
32. Right-click on ECV-5 & select Appliance Manager
33. In the new browser tab that opens to ECV-5, go to

Maintenance → Tools → Ping/Traceroute
34. Ping TG-3511 (source = lan0 – 10.110.114.102)
 IP/Hostname: 10.110.35.11
 Options: -I 10.110.114.102
35. Click Start and let it run… it should fail.
Leave the ping running as you will make

configuration changes and come back to
verify if the pings are then working.
Task 2: Configure BGP on ECV-4

36. Select Site 3 – Santa Clara in the appliance tree
37. Go to the BGP tab: Configuration → Routing → BGP
38. Click the edit icon next to ECV-4
DRAFT
39. 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
40. Click Add under BGP Peers to configure AOS-CX-3 as a

peer
41. Configure AOS-CX-3 as a peer
 Peer IP: 10.110.114.1

 Local Interface: any
 Peer ASN: 65001
 Peer Type: Branch
 Next Hop Self: (checked)
 Inbound route map:
default_rtmap_bgp_inbound_br
 Outbound route map:
default_rtmap_bgp_outbound_br
42. Click Add
43. Back at the BGP information screen, click Apply under the BGP Peers table
DRAFT
Task 3: Configure BGP on ECV-5

44. From the BGP tab in Orchestrator click the edit icon next to ECV-5
45. 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
46. Click Add under BGP Peers to configure AOS-CX-3 as a

peer
 Peer IP: 10.110.114.1
 Peer ASN: 65001
47. Click Add
DRAFT
48. Back at the BGP information screen, click Save under the BGP Peers table
Task 4: Observe peer connections

49. Refresh the Peers button to view Peer status.
Note that refresh might not update the Peer State after configuring ECV-5. If this
occurs, close and then reopen the BGP tab to update the Peer State for ECV-5.
50. In the Peer State column, both ECV-4 and ECV-5 should have connections to AOS-
CX-3 in the Established state.
If this is not the case, recheck your configuration to verify the local ASN, peer ip
address and ASN, “…_br” route maps on peer configuration being used.
Note that after configuring BGP on ECV-5, you might not see the status change to
“Established” after clicking the refresh button several times. To see the status change
for ECV-5, click the drop-down arrow next to the Refresh button and click on “Refresh
from appliance.”
DRAFT
Task 5: Understand BGP peer state details
51. If you need to troubleshoot, you can Click the Peer Details icon in the far-right column
of the BGP tab to see information about each appliance’s connection to AOS-CX-3.
a. What is the Router ID (not Peer IP) of AOS-CX-3?

3.3.3.3
b. What IP addresses did AOS-CX-3 peer with to ECV-4?

10.110.114.101
c. How many routes were learned by ECV-4 from AOS-CX-

3?
1 – 10.110.35.0/24
d. How many routes were advertised by ECV-4 to AOS-CX-

3?
9 routes advertised by ECV-4
Task 6: Test and view BGP routing information

Since both ECV-4 and ECV-5 are BGP peers with AOS-CX-3, they should now both be
learning routes that enable them to reach TG-11411 and TG-3511.
Let’s confirm that…

52. Return to ECV-5’s Appliance Manager window
where the Ping to TG-3511 is running.
The output of the ping should now show

successful echo replies – you may need to
restart the ping.
53. Go to the Flows tab in Orchestrator
a. Click the Clear button
b. Click the Refresh button
DRAFT
54. Again, search for 10.110.35 to filter the only rows that match that string.
55. Open the flow details for the

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

sent directly to AOS-CX-2
(10.110.114.1) out the lan0
interface
 ECV-4 prefers ECV-5 for

those same subnets for the
same reason.
56. Close the Flow Details
57. Return to the Routes tab on the Orchestrator
58. Use CTRL-Click to select, ECV-1, ECV-4, and ECV-5 in the appliance tree
a. Filter on 10.110.35
DRAFT
 We can see in the Type column that the 10.110.35.0/24 routes were learned via IBGP
from AOS-CX-3 (10.110.114.1) because they are BGP peers with AOS-CX-3.
 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.
59. Stop the ping on ECV-5
Task 7: Redistribute BGP learned routes on ECV-4 into Subnet Sharing

60. On the Routes tab, Clear the Search box to view all routes
61. Click on the edit icon for

ECV-4
62. Click on the icon to edit the

default_rtmap_to_subsh.
63. Click on the icon next to

Priority 65535 to edit the
BGP rule
64. Select the next to Permit

65. Click Update
66. Click the at the top-right to close the Route Map

67. Click Apply
DRAFT
Task 8: Redistribute BGP learned routes on ECV-5 into Subnet Sharing

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

69. ECV-1, ECV-4, and ECV-5 should still be selected in the appliance tree.
70. Return to the Routes tab on the Orchestrator
71. Refresh the table.
72. Search on 10.110.35
73. 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 10: 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.
74. On the Routes tab, Clear the Search box to view all routes
75. Click on the edit icon for ECV-4

76. 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:
DRAFT
77. Click Save
78. Repeat Steps 72 – 74 on ECV-5.
79. Use CTRL-Click to select, ECV-1,

ECV-4, and ECV-5 in the appliance
tree
80. Search on 10.110.35
 What do we see?
Note: it might 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 if you still see that ECV-5 is learning the 10.110.35.0/24 network from
ECV-4 via Subnet Sharing including the AS# 65001?
If after 5 minutes you still see a second route on ECV-5 to 10.110.35.0/24 being learned
from ECV-4 with the AS 65001 in the Additional Info field, then you will need to
unconfigure and then reconfigure the ASN option boxes in ECV-4’s Routes config. See
steps below.
DRAFT
Perform the following steps ONLY IF ECV-5 is still learning a route to the
10.110.35.0/24 network from ECV-4 via Subnet Sharing that includes the AS#
65001.
A. Clear 10.110.35 from the search box in the routes table.
B. Click on the edit icon for ECV-4.
C. Uncheck the two ASN options that were checked in the previous steps.
D. Click Save.
E. Wait a moment and click on the edit icon for ECV-4.
F. Check the two ASN option boxes again.

G. Click Save.
H. Type 10.110.35 in the search box in the routes table. Both ECV-4 and ECV-5
should only be learning the 10.110.35.0/24 network via BGP from AOS-CX-3
(10.110.114.1).
 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).
DRAFT
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 11: View BGP routes on AOS-CX-3
81. Click on the PuTTy icon from the Taskbar
82. Double-click the Saved Session

for AOS-CX-3
83. Login as: admin

84. Password: Speak-123
DRAFT
show bgp ipv4 unicast neighbors

85. On the AOS-CX-3 switch, type:
10.110.114.101 advertised-routes to view the routes advertised to ECV-4.
show bgp ipv4 unicast neighbors

86. On the AOS-CX-3 switch, type:
10.110.114.102 advertised-routes to view the routes advertised to ECV-5.
AOS-CX-3 is advertising the 10.110.35.0/24 network to ECV-4 and ECV-5
DRAFT
87. Type show bgp ipv4 unicast 0.0.0.0/0 to view the BGP sources for the default route.
AOS-CX-3 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 AOS-CX-3’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
AOS-CX-3 because a route to the original next hop is not known. The next hop
needs be ECV-4 or ECV-5.
DRAFT
88. Type show ip route bgp to see which routes are actually used by AOS-CX-3
 show ip route bgp 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).
 The following step shows the command used to view all of the prefixes advertised
from each peer (ECV-4 & ECV-5) – this will show the best routes that are used in the
route table as well as redundant routes that do not appear in the BGP route table.
DRAFT
89. To view all paths learned from a ECV-4 type: show bgp ipv4 unicast neighbor
10.110.114.101 paths.
90. To view all paths learned from a ECV-5 type: show bgp ipv4 unicast neighbor
10.110.114.102 paths.
ECV-4
ECV-5
DRAFT
Hands-on Labs - PART B (eLearning Students

Only)
This section explains the process to obtain a lab voucher and access the lab environment for ASD -
Part B (Labs 6 – 11).
eLearning Students Only: Please read this section and perform tasks outlined below.
IMPORTANT NOTE:
In order to access the lab, follow the process in the video "Hands on Lab - Part B" to request
a lab voucher through the purchase portal. There is a link in the video you click on to
acknowledge that you understand the process and request a lab voucher.
(6 – 11)
Task 1: Click on the link in the video to acknowledge and request a

voucher for Part B – Labs 6 - 11
91. Click the link on the video screen to go to the lab purchase portal.
2. You will be taken directly to Advanced Aruba SD-WAN Deployments (ASD) v9.2 –
PART B
• (Catalog ID: ASD v9.2 – PART B)
DRAFT
3. Click Add to cart.

Advanced Aruba SD-WAN Deployments v9.2 – PART B
ASD v9.2 – PART

202b-DST LabsB1-9 2020.08
4. Click Check out. Advanced Aruba SD-WAN Deployments

v9.2 – PART B
DAST v9.2 – PART B
5. Open the email you received from

ReadyTech and click on the “Redeem
Now” link in the email.
Advanced Aruba SD-WAN Deployments v9.2 – Part B
DO NOT ENABLE PASSWORD PROTECTION!
6. Check the consent box in the lower left
7. Click OK to activate the code
DRAFT
Task 2: Connect to the ReadyTech lab

8. Select Lab in
the blue menu
bar at the top.
9. When you are ready to begin, click Start lab now.
You will have one day (24 hours) of access time beginning when you click ‘Start the
lab’. If you do not start the lab within a few hours, you will not have time to complete it.
All Aruba EdgeConnect labs are designed to be completed within 4-5 hours.
10. Click Start now.

Note: Although the message says it may take up to xxx minutes to start (150 in the screen
shot), your wait should
only be 5-10 minutes
as machines are
deployed from a hot
standby pool.
However: If demand is
high and all the
machines in the pool
have been deployed,
you may have to wait Schedule
the full length of time
for your lab to fully
deploy.
An Action in
progress message will display.
11. Click Close.
DRAFT
An Action result message will display.
12. Click Close.
13. Go to the Lab tab.

a. Verification: Your name and
code should be at the upper
right of your screen.
If not, you need to logout and log in
again…
• Click on the dropdown and
select Log out.
• Repeat steps to log in with
your correct code.
• Verify the lab status is “Up”.
14. Make sure Ready Tech Viewer (HTML) is selected.
15. Click the thumbnail image Connect to the lab.
16. The Windows login screen should open in the Administrator profile. This is called the
Landing Desktop.
Note: If you are having keyboard issues

with a non-US keyboard there are special
instructions in Appendix A. Speak-123
Task 3: Confirm Virtual Machines are Set Up and Powered On

17. From Chrome, go to the first tab: http://esxihost
• Username: admin
DRAFT
18. Click on the Navigator

button at the top left of the
screen
19. Click on Virtual Machines

a. There should be 18 devices listed
20. Ensure all VMs are Powered On

a. The icon next to the VM name
should be GREEN. If it is not,
check the box next to its name,
then click on Power on
Note: in the Status column next to ECV-3 is ok

.
Task 4: Register and Configure the Orchestrator and ECV-1, ECV-2, ECV-
3, ECV-4, and ECV-5 Using the Setup Script
Part B of this self-study lab is a continuation of Part A. You normally wouldn’t need to do the
following tasks in an existing network because all these machines would be licensed already.
DRAFT
In our training environment, the ASD Setup Part B script will generate new Account Name
and Account Key. It will also add them to the Orchestrator, ECV-1, ECV-2, ECV-3, ECV-4,
and ECV-5. This will associate all the devices with the same test account in the Cloud Portal
and allow Orchestrator to manage all the devices.
Note that it will take a few minutes for the script to run and then several more minutes for the
appliances to be added to the Orchestrator and then build the tunnels – take this time to read
through the remaining tasks.
Note that you will see many alarms appear and disappear. There should be no Critical
alarms when complete. You may clear any Warning alarms that remain.
21. From the ASD Lab Files folder on the ASD – Topology & Logins.pdf
Landing Desktop, open (double-click on)
ASD Lab Files ASD Setup
the ASD Setup icon from the desktop.
Warning: Only run the ‘ASD Setup’ script ONCE in this Lab!~
22. The script runs and a

Command Prompt
window will open.
a. DO NOT CLOSE this trainingDemoAccount1234567

trainingDemoAccount01234567
01213456789abcdefghijklmnopqrstuvwxyz
123456789abcdefghijklmnopqrstuvwxyz
window until you
have verified that the
Orchestrator Account
Name and Key match
the info in the top of
this output.
23. Upon completion, the

ASD_Log.txt file
will open in a Notepad
window.
24. Confirm the Orchestrator,

ECV-1, ECV-2, ECV-3, ECV-4
and ECV-5 show as
successfully registered.
If any of the steps show “FAILURE”, send email to sp-training@hpe.com. Describe the failure
and include a screenshot.
DRAFT
25. If the log reports every step is a “SUCCESS” then Close the ASD_Log.txt notepad
window.
Task 5: Verify the Account Name and Account Keys on the Orchestrator
26. From Google Chrome click on the second tab, Orchestrator Login.
27. Login to the Orchestrator using the

standard training lab credentials:
• User name: admin
28. Go to ORCHESTRATOR → LICENSING → Cloud Portal.
29. Confirm the Account

Name and Account Key
match with what is in the
ASD Setup script file on
the Landing Desktop. (Task
4, step 22)
a. Click on the padlock icon to unmask the

Account Key
b. Confirm the Status of the Registered field =
Yes
c. Close the Cloud Portal window
trainingDemoAccount1234567
123456789abcdefghijklmnopqrstuvqxyz
DRAFT
Task 6: Verify the Appliances are Licensed

30. Go to CONFIGURATION → OVERLAYS → LICENSING → Licenses.
Note: If you do not see the Licensing section at the bottom, expand
your browser window or adjust your Zoom level.
31. You should see a count of five EC Appliances.
a. Under the EC License Configured all 5 ECVs should

show 50 Mbps.
b. Under the EC License Granted column they should
show 50 Mbps.
Caution: If it lists anything other than “50 Mbps” proceed to Task 7, otherwise skip to Task 8
32. Close the Licenses tab
Task 7: Reapply Preconfiguration File (only if above fails)
Do this Task only if your License does not show as “Active” and you see any “Failed to
apply appliance preconfiguration” alarms:
33. Right Click on the appliance in tree view

a. Select Configuration Wizard
DRAFT
34. Right Click on the appliance in tree view

a. Select Configuration Wizard
35. Click Apply Preconfiguration
36. Click Close when the

preconfiguration completes
DRAFT
Task 8: Verify appliances in Tree View
37. Confirm the 5 appliances are listed in the Appliance Tree

• ECV-1 is listed in the Site 1 - Singapore group
• ECV-2 and ECV-3 are in the Site 2 – Mumbai group
• ECV-4 and ECV-5 are in the Site 3 – Santa Clara group
There should not be any red or gold errors next to them (you may need to refresh the browser)
Contact ReadyTech for the following Issues:

➢ Problems redeeming a voucher (instructions above)
➢ Lab never comes up after a few hours.
➢ Lab seems to have gone down or you cannot
reconnect.
➢ Pre-installed virtual machines that aren’t operating in
VMware ESXi when you first log into the lab.
Click on the Support link

Available options are:
• Email: getsupport@readytech.com
• Live Chat
• Contact by telephone
• 24x7 support
Contact Aruba EdgeConnect Support for questions on:
DRAFT
➢ Instructional videos
➢ Course material or Lab instructions
➢ Configuration of the Orchestrator or EdgeConnect VMs.
➢ Virtual machines, in VMware ESXi, that you installed per Student as part of an exercise.
Click to email: sp-training@hpe.com

A new email should open in your application
• Subject Line: replace TYPEissue with a short description of your issue
Examples:
➢ LAB HELP |ASD| Setup script fails
➢ LAB HELP |ASD| Can’t get IP Address on ECV-4
In the body, include your:

1. LAB ACCESS CODE
2. Position in lab guide:
• Lab#
• Page#
• Step#
3. Screenshot(s)
DRAFT
REVIEW #8: IP SLA
1) Can an IP SLA cause subnet sharing to stop if an interface goes down?

YES, one of the available actions is to stop subnet sharing
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.
FALSE – By default the addresses are ORed so if one is reachable, it is considered up.
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.
TRUE – Raising/clearing alarms are among the available actions
4) What should you use if the website you’ve chosen to monitor for reachability blocks
ICMP traffic?
HTTP/HTTPS
DRAFT
REVIEW #9: Route Maps
1) What do route maps control on an EdgeConnect appliance?

They control route redistribution
2) T/F: A route map can be configured on the Orchestrator and pushed out to
the appliances which can use the route map.
TRUE = In a template group
3) What’s an Inbound Route Map?

Controls traffic what traffic is being redistributed into Subnet Sharing
4) What’s an Outbound Route Map?

Controls what is being redistributed into OSFP or BGP from Subnet Sharing
5) T/F: OSPF uses inbound and outbound route maps Per Peer.
FALSE – Only BGP uses route maps on a per-peer basis
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
FALSE
8) Is the choice of set actions the same for each of the rules in every Route Map?
NO = Set actions can differ depending on the protocol
9) T/F: The default outbound BGP PE route map allows you to redistribute subnet
shared routes into BGP and then advertise them to the peer.
FALSE – Default denies subnet shared routes
DRAFT
LAB 6: 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 EdgeConnect 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.
DRAFT
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 (AOS-CX-3) prefer the other appliance (ECV-5).
1. Go to (or reopen) the PuTTY window for AOS-CX-3
2. Type show ip route bgp
This command will show the best BGP routes in its route table. Notice the equal cost
routes for the networks from ECV-4 (10.110.114.101) and ECV-5 (10.110.114.102) –
both have a metric of 50. Because they are equal cost, routes from both ECVs are
showing up in the output.
Best practice in network design is to have your routing be deterministic and
predictable.
 We want AOS-CX-3 to always prefer ECV-5 when forwarding routes.
3. Select Site 3 – Santa Clara in the appliance tree.
4. Return to the BGP tab
DRAFT
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.
DRAFT
8. Edit rule Priority 65505 (Local/Static) by Clicking the edit icon.
9. Check the Metric checkbox.
10. Set the metric to 70.

11. Click Update.
12. Repeat steps 9 – 11 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.
DRAFT
16. Go back to AOS-CX-3 and type: show ip route bgp
 Notice that:
▪ ECV-5 is the next-hop for most of the routes - advertising routes with a metric of
50. The only route learned directly from ECV-4 is its locally attached loopback
interface with a metric of 70.
▪ All LAN-side prefixes are learned except for 10.110.20.0/24
 Do we not need it; is a default route is being used?
DRAFT
17. Type show ip route
 10.110.20.0/24 isn’t there, but a default route is present with ECV-5 as the next-hop.
Let’s try pinging TG-2011
 Because they have a higher metric (70), the routes from ECV-4 will not show up in the
AOS-CX-3’s route table – only the best BGP routes will appear here. To verify the
routes are being learned from ECV-4, you can use the show bgp ipv4 unicast
neighbor 10.110.114.101 paths.
18. Ping 10.110.20.11
 That doesn’t work either. What’s different about this 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.
DRAFT
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 might have to do with the subnet

sharing route map, you’re right. Let’s confirm that.
24. Click on at the top right to close the Route Map screen
DRAFT
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 the appliance tree
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 the Permit checkbox
32. Click Update
DRAFT
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 the appliance tree
39. Return to the Routes Tab
40. Search on 10.110.20
DRAFT
 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 AOS-CX-3.
42. Type: show ip route to verify AOS-CX-3 is now learning the 10.110.20.0/24 network
from ECV-4 and ECV-5.
43. Ping TG-2011 again.

It should now work!
DRAFT
Task 5: View the routes on the appliances to verify they come from
OSPF
44. Click on the Routes tab in Orchestrator
45. Select Site 3 – Santa Clara from the appliance tree
46. Click on the OSPF button to view only OSPF originated routes.
47. 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.
DRAFT
48. Select All Appliances from the appliance tree
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, then 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. Note the tunnels being used and then Refresh the output.
54. From the Reset Flows dropdown, select Reset All Returned
DRAFT
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.
DRAFT
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 the appliance tree, select ECV-2 and ECV-3.
62. Go to the OSPF tab in Orchestrator.
63. Click on the edit icon for ECV-2.
DRAFT
64. Click the edit icon to edit the

Redistribute routes to OSPF Route Map.
(default_rtmap_to_ospf)
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
DRAFT
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
73. Go to the Routes tab
74. Click the All button at the top left of center
75. Search on 999

Note: it might 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 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
DRAFT
78. Click to edit the route map for

Redistributed Routes into SD-
WAN Fabric.
(default_rtmap_to_subsh)
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
DRAFT
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 AOS-CX-2.
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
DRAFT
Again, it might 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 what you just accomplished in the last few tasks.
A. ECV-2 added a tag (999) to subnet shared routes that were redistributed from the
OSPF routing domain.
B. AOS-CX-2 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. AOS-CX-2 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, tagged with 999 (originally learned
from ECV-4 or ECV-5) because it is already learning them directly from AOS-CX-
2. These 999 tagged routes will not be shared to other appliances via Subnet
Sharing.
ECV-3 PERMITS routes learned from AOS-CX-2 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 the routes on ECV-4 and ECV-5 on the Routes tab.
DRAFT
90. Search for only /24 prefixes
 If you select ECV-4 and ECV-5 in the appliance tree, 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.107.0: learned via SS from ECV-2 & ECV-3
 10.110.35.0: learned via BGP from AOS-CX-3
 10.110.20.0: learned via SS from ECV-2 & ECV-3
▪ because ECV-2 and ECV-3 are allowed to redistribute those into the
SD-WAN fabric. They were sourced from AOS-CX-2 and were not
tagged with 999.
 10.110.10.0: learned via SS from ECV-1
 Note: AOS-CX-2 applies a metric of 100 on the gigabit ethernet interface (1/1/2) for
OSPF routes. The ECVs use a metric of 1 for gigabit ethernet. The 10.110.20.0/24
routes reflect the AOS metric values.
DRAFT
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).
DRAFT
REVIEW #10: Regions

1) T/F: Regional routing increases the number of tunnels required to connect
appliances in different regions
FALSE – Regional Routing will reduce the overall number of tunnels.
2) T/F: In a region using a BIO configured with a Regional Mesh topology, non-hub
devices will only connect to Hubs in that region.
False = devices in a region will all connect to each other via Mesh. Hub will be used to connect to other regions.
3) H2 loses its connection to H4. Can traffic be routed from devices in Region B to
Region C via Region A?
No. Transit Regions not possible.
4) All devices use the default subnet sharing metric. What is it when:
a) H1 learns routes connected to A1?
50
b) A1 learns routes connected to A3?

50 direct from A1 and 100 via H1
c) A3 learns routes connected to B2?

150
d) H2 learns routes connected to C4?

100
DRAFT
LAB 7: 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 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
quite 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 three regions.
 Observe how this affects propagation of routes within and between regions
 Observe how the metric is affected on re-advertised routes.
DRAFT
Task 1: Create region labels

We will create regions that align with the site names already shown in
the appliance tree.
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
DRAFT
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
15. Click Confirm in the Add

Hub confirmation box.
Orchestrator will begin to
configure the hub.
In the meantime…
16. Using the previous steps configure the following as Hubs:
 ECV-2
 ECV-3
 ECV-4
DRAFT
17. 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 four overlays to Regional Mesh.
18. Go to the Business Intent Overlays tab:

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

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

Along with the new Topology
shown, all the configured Hubs will
be displayed
22. Click OK
23. REPEAT for the CriticalApps overlay
24. REPEAT for the BulkApps overlay
25. REPEAT for the DefaultOverlay
26. Click OK
27. Click Save and Apply Changes to

Overlays
28. Click Save to Confirm Changes
DRAFT
29. Click on Orchestration ETA at the top-right of the Orchestrator
30. Watch for the Orchestration to

complete
Notice that an alarm indicator has
appeared (this might take a minute or
more to resolve)
Click on the red box
31. Observe the alarm text

One of the critical alarms will
indicate that “At least one region is
missing a hub appliance”. Adding
the appliances to regions will resolve this alarm.
32. Click the X to close the alarm.
33. On the Business Intent

Overlays tab, Click the ‘+’
sign next to the word Hubs to
reveal the hubs column
information for each overlay
34. 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

35. Return to the Regions tab
37. Check the box next to Singapore in the Add

column
DRAFT
38. Click Apply
39. Click Apply Regions
40. REPEAT these steps to add ECV-2 and ECV-3 to the Mumbai region
41. REPEAT these steps to add ECV-4 and ECV-5 to the Santa_Clara region
42. Highlight all appliances in the appliance tree to see

a summary of what you have done
43. Return to the Business Intent Overlays tab
44. 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.
DRAFT
45. 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.
46. In the appliance tree, right-click ECV-5
47. Select CLI Session
48. Type ping 10.110.10.11

-I 10.110.114.102 to
ping TG-1011 from lan0 on
ECV-5
4
The ping should fail. 4
49. Press <CTRL-C> to end the

ping
Why do you suppose the ping is failing? Let’s look at the routes on ECV-5:
50. Return to the Routes tab in Orchestrator
DRAFT
51. Select only ECV-5 in the appliance tree.
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 AOS-CX-3.
 Why is this?
ANSWER: All the appliances are 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
52. Return to the Tunnels tab
53. Confirm only ECV-5 is selected in

the appliance tree
54. Click on Overlay
ECV-5 now only has tunnels to
ECV-4.
DRAFT
55. 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
56. Select only ECV-4 in the

appliance tree
57. Click on the Routes tab
ECV-4 is learning routes from all the other sites.
58. 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.
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.
DRAFT
Task 8: Enable Regional Routing

59. Return to the Regions tab
60. Click on Enable Regional Routing
61. Click the switch to Enable Regional Routing

62. Click Save
63. Wait for orchesration to finish
64. Click View Status
This takes you to the Audit Logs
65. 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.
67. Return to the Routes tab
68. Click on the All button
DRAFT
69. ECV-5 isn’t learning any routes from the hub in the SANTA CLARA region (ECV-4)!
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-5 is filtering routes it learns from the hub ECV-4 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.
DRAFT
Task 9: Stop filtering routes based on AS number

We were using AS numbers to do filtering before, but now we will accomplish the same
objective by adjusting Administrative Distance.
70. Select only ECV-4 and ECV-5 in the appliance tree
71. Click on the Routes tab.
72. Click the edit icon for ECV-4

73. Uncheck the boxes for Filter Routes From SD-WAN Fabric with Matching Local
ASN
74. Click Apply
75. Repeat steps 71 – 74 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.
DRAFT
 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 AOS-CX-3. 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 AOS-CX-3 (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.
76. Select Site 3 in the appliance tree
77. Click Admin Distance from the

Routes tab
78. Click the edit icon next to ECV-4
79. Change Subnet Shared – BGP Remote to 201
80. Click Save
 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.
81. Repeat steps 78 – 80 on ECV-5.
DRAFT
82. Verify that 201 is listed in the correct column
83. Select ECV-4 in the appliance tree
84. Return to the Routes tab in Orchestrator.
85. Type /24 in the Search box to view only subnets
86. 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 prefix both from iBGP via AOS-
CX-3 and subnet sharing from ECV-5.
Question: ECV-4 is learning the routes from ECV-5 with a metric of 250 and from
AOS-CX-3 with a metric of 250. Which route will be preferred by ECV-4?
Answer: The ones from AOS-CX-3 with a metric of 250 because they have the lower
admin distance (200 vs. 201).
DRAFT
87. Let’s check the Routing Table for ECV-5. Select only ECV-5 in the appliance tree.
88. On the Routes tab, 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, 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 AOS-CX-3 because of the admin distance (200 versus 201)
For example, the 10.110.107.0 subnet was learned by ECV-4 with a metric of 50
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).
DRAFT
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 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.
DRAFT
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.
TRUE = only SD-WAN traffic allowed through Harden (no breakout allowed)
2) T/F – No traffic of any kind is allowed into a hardened interface outside of an IPsec
tunnel.
FALSE – Cloud Portal DNS and DHCP traffic allowed
3) Could an interface connected to the Internet and configured to be a Stateful Firewall,

allow local access to SalesForce.com?
YES – connection must be initiated from the inside
4) T/F – All the appliances in a network can simultaneously change to a new IPsec
encryption key on a predetermined schedule.
YES – Key Rotation can be scheduled
5) Are ipsec_udp tunnels the only type available in Orchestrator?

NO – IPsec and GRE
6) Is it possible to limit the address spaces from which logins to Orchestrator are
allowed?
YES – use an Allowed List
DRAFT
REVIEW #12: Zone Based Firewall
1) What is the default action taken for INTER zone traffic (between devices in different
zones)?
Implicit Deny
2) What zone are all interfaces in by default?

“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?
YES, all intra-zone traffic allowed
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?
Nothing – The firewall is stateful
5) What is the priority of the default rule in a security policy?

65535
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?
Disable the rule without deleting it
7) How can you tell which rule in a security policy was matched for a flow?
Check the flow details
8) In the flow table, what’s a quick way to tell at a glance that a flow was dropped?
All dropped flows are displayed in red font
9) What’s quick way to find only those flows dropped by the firewall in the flow table?
Using the Firewall Dropped filter
DRAFT
LAB 8: 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 and apply Zone Based Firewall labels.
 Configure security policies that permit certain traffic, but deny other traffic.
Task 1: Familiarization with the ZBF lab topology

• The LAN side of each ECV will be in a zone named the same as the site.
• All WAN side interfaces will be in the INTERNET Zone
DRAFT
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 might 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 template that permits or denies connections
between a pair of zones. We will use templates for these so we can apply them to all 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
DRAFT
8. Click Show All
9. Remove all existing templates 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 might be further below; scroll
down the Available Templates list.
Note: Certain browser zoom settings might prevent the Available
Templates from displaying. If the Available Templates column appears
blank, try zooming out/in on the Landing Desktop Chrome browser.
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
DRAFT
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.
Any traffic not explicitly permitted will be implicitly denied.
 Santa_Clara Zone
1. Deny users at Santa Clara to access external FTP sites but allow everything else.
 Mumbai Zone
1. Allow access for all protocols to connect to UBU-1
2. Allow FTP access to TG-11411
 Singapore Zone
1. Allow access for all protocols to connect to UBU-1
2. Allow FTP access to TG-11411
The next Security Policy requirement is an optional exercise: time permitting.

Your instructor will let you know if any or all of them should be completed in class.
 Mumbai Zone (optional)

1. Allow anything in the File Sharing application group to access all devices in TG-
3511’s subnet.
Note, the policies we create to satisfy the requirements of this lab are only one feasible
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.
DRAFT
Task 5: Configure policies for the site zones
Santa_Clara Zone
15. Deny users at Santa Clara to access external FTP sites but allow everything else.
• The first requirement is to Deny users at Santa Clara to access external FTP sites but
allow anything else.
• The second requirement is to allow all other traffic.
16. Click on the intersection

of From Santa Clara
and To INTERNET
17. 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.
18. Click to edit rule #1000 - Match Everything
DRAFT
a. Click next to Application

b. Type ftp; the field will display
all options matching the string
c. You must click on Ftp in the
drop-down menu
d. Click Save
Notice that the Match Criteria

now shows FTP.
19. Under the Action column, click the drop-down for rule 1000 and change it to Deny
20. Additionally, to meet the Second part of the requirement, change the action of the
default rule 65535 to Allow
Based on these rules, FTP traffic will be denied and any other application will be allowed.
21. Click OK
Remember - Firewall rules are stateful, so return traffic is also allowed.
Mumbai Zone
16. There are two rules needed to fulfill the requirements for Mumbai.
• Allow access for all protocols to connect to UBU-1
• Allow FTP access to TG-11411
DRAFT
17. Click at the intersection

of From Mumbai and
To INTERNET
18. 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.
19. Click to edit rule #1000 - Match Everything
a. Click More Options
DRAFT
b. Click next to IP/Subnet

c. Enter 11.1.1.11/32
d. Click Save
Notice how the Match Criteria now shows 11.1.1.11/32.
20. Under the Action column, verify rule 1000 is configured to Allow
21. Additionally, verify the Default rule 65535 is configured to Deny
22. Click Add Rule to add an additional rule.
DRAFT
There should now be 3 rules in the list.
23. Edit rule 1010 to Allow FTP

access to 10.110.114.11/32.
24. Click Save on the Match Criteria

window
25. Click OK on the Rules Edit

window
There should now be 3 rules on From Mumbai – To INTERNET
DRAFT
Singapore Zone
26. Repeat steps 17 – 25 on the intersection From Singapore – to INTERNET
Note: No changes are required for Santa Clara. It is denied FTP access to INTERNET, but
the second rule allows it to access everything including 11.1.1.11 using any other application
(as long as it is not FTP).
Mumbai and Singapore have 2 “Allow” rules To INTERNET, and Santa_Clara has 1 “Allow” rule
To INTERNET.
Mumbai and The steps for the optional exercise are located in Task 9.
27. Click Save to save the Security Policies we just

configured to the ZBF Policies Template Group
28. Click Save Template Changes 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.
DRAFT
29. Select All Appliances in the appliance tree
30. Click Apply Template Groups
31. Click the box to

Add ZBF Policies
32. Click Apply
33. Click Apply Templates to confirm
DRAFT
Task 6: FTP from TG-1011 to TG-2011

34. 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
35. Open Filezilla by clicking on its icon from the

Windows Taskbar
36. Connect to the FTP server on TG-2011
a. Use the following:
 Host: 10.110.20.11
 Username: anonymous
b. or . . . click the Quickconnect drop-down and click on anonymous@TG-2011
The Directory listing should be successful.
DRAFT
Task 7: Apply zone labels to interfaces

Now that we have Zone Labels created, we still need to specify what Zone each interface
belongs to.
37. Right-click ECV-1 in the appliance tree
38. Select Deployment

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
39. 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
40. Click Apply
41. In case it wasn’t clear above, or If you missed it, remember to -

REPEAT steps 37 - 40 on the other 4 EdgeConnects so the LAN interface for
each is in the correct zone and all WAN interfaces are in the INTERNET zone.
DRAFT
Task 8: Verify security policies are being used.
42. Return to the Remote Desktop session on the Landing Desktop to TG-1011
a. If you closed it, simply reopen and connect to TG-1011 again
43. Open Filezilla from the Windows Taskbar
44. Click the Quickconnect drop-down and click on

anonymous@TG-2011
45. Click OK to abort previous connection.

It should no longer be able to connect.
46. Return to the Flows tab in Orchestrator
47. Click on the Clear button, in case you have any filters applied
48. Click on the refresh button to update the output
DRAFT
49. In the Flows table, search for ftp

Note: A flow in red should now be displayed indicating the flow is being dropped.
50. Click on the Details icon

Under Security in the flow details 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 and an explicit rule must be configured to allow it.
51. Close the Flow Details
OPTIONAL Exercise
 If time permits, try and configure additional policies.
Task 9: Configure policies for the Mumbai zone (optional – time permitting)
This time, you will allow anything in the File_Sharing application group to access all
devices in TG-3511’s subnets.
52. Click on the intersection From Mumbai and To Santa_Clara and add a new rule.
DRAFT
53. Edit rule 1010 to allow

File_Sharing apps to access
hosts on TG-3511’s subnet
(10.110.35.0/24).
54. Click on the Application Group

Checkbox and then enter
“file” in the Application Group
field.
55. Click on File_Sharing in the

drop-down menu.
You must click on File_Sharing
from the drop-down and not just
type the name in the box.
56. Click on More Options
57. Click the IP/Subnet checkbox

and enter 10.110.35.0/24
58. Click Save
59. Click OK in the Edit Rules

window
60. Open a CIFs shared network
folder from TG-2011 to TG-3511
to validate it works.
DRAFT
You should now see the new rule Allow: File_Sharing, 10.110.35.0/24
Task 10: Test the new security rule

61. Open Cifs_smb connection from TG-1011 to TG-3511
The connection should fail.
DefaultOverlay
Flow Details indicate the flow was dropped because of an implicit Deny for traffic From
Singapore – To Santa_Clara.
62. Open a Cifs_smb connection from TG-2011 to TG-3511
The connection should be successful.
DRAFT
REVIEW #13: Asymmetry & Flow Redirection
1) T/F: With Flow Redirection the EdgeConnect appliances tell the routers to redirect
traffic to the correct appliance.
FALSE – Appliances notify each other of what flows they own
2) What information do Flow Redirection cluster peers exchange in their control

messages?
Flow Table = who owns what flow
3) Do redirected packets traverse the same interfaces as the control messages in a

cluster?
YES
4) T/F: Flow redirection peers should be in different subnets for high availability reasons.
NO – must be on the same subnet
5) Which device is the owner of a TCP flow in a Flow Redirection cluster?

First one to receive a packet in a flow – the SYN
6) Which interfaces can be used for Flow Redirection?

Unused management interfaces
7) T/F: In Current Flows, redirected flows will be marked as such on the redirecting (non-
owning) peer.
FALSE – redirected flows only show up in the appliance that owns the flow
DRAFT
LAB 9: 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. Right-click ECV-5 in the Appliance Tree

and click Appliance Manager
2. Go to Administration > Reboot / Shutdown
3. Click on Shutdown in the

Reboot System window
DRAFT
4. Click Shutdown in the confirmation box. The appliance will then shutdown.
5. Verify in the ESXi host that the

ECV-5 VM is shutdown – ECV-
5 icon should be light blue.
Task 2: Remove ZBF policies template from all appliances

Because each student might or might not
have done some of the optional exercises
from the Zone Based Firewall lab, we will
remove the ZBF Policies template.
6. Select all appliances in the appliance tree
7. Open the Apply Templates Groups tab: Configuration → TEMPLATES & POLICIES →
Apply Template Groups
8. Click on the box under the Remove column for ZBF Policies
9. Click Apply
DRAFT
10. Right-click ECV-1 in the appliance tree and select Deployment
11. Reconfigure the Firewall Zone for LAN and WAN interfaces back to default.
12. Repeat Steps 9 – 10 for ECV-2, ECV-3 and ECV-4.
Task 3: Test connectivity from TG-11411 to TG-1011

13. Click on the Remote Desktop Icon from the
Windows Taskbar on your Landing Desktop,
14. Select TG-11411
15. Click Connect
16. Click on the Command Prompt icon from

the Windows Taskbar of TG-11411,
17. Ping 10.110.10.11
(TG-1011)
It should be successful
Task 4: Enable segmentation on Orchestrator

18. Open the Routing Segmentation (VRF) tab:
Configuration → Networking → Routing →
Rouging Segments (VRF)
DRAFT
19. Click on the toggle

switch to enable
segmentation.
20. 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.
21. After Orchestration completes, return to the Routes tab on Orchestrator
22. 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.
DRAFT
Task 5: Create a segment

23. Go back to the Routing Segmentation (VRF) tab.
24. Click +Add Segment
 Segment Name: Seg_A

25. 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…
26. In the upper right corner Click on Orchestration ETA.
a. This time just wait until Done shows up for ECV-1,

ECV-2, ECV-3 and ECV-4
b. Click Close on the Orchestration Process window
Task 6: Assign ECV-1 and ECV-4 interfaces to Seg_A

27. Hold the CTRL button and select both ECV-1 and ECV-4
28. Right-Click on ECV-4 in the appliance tree
29. Open the Deployment screen

Notice that there is a new field in the deployment profile for
each interface called ‘Segment’
DRAFT
30. Click Default to display the list of available segments.
31. 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.
32. Click Save.
33. REPEAT steps 28 – 32 on ECV-1
34. Wait for Orchestration to finish

again.
Task 7: Verify the interfaces were added to Seg_A

35. In the upper right corner Click on Orchestration ETA.
a. Again, wait for Orchestration to finish (the list will go blank).
36. Close the window.
37. Click the refresh button on the Routing Segmentatioin (VRF) tab.
Notice that there are now two appliances with interfaces in Seg_A.
DRAFT
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.
38. 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 8: Look at the routes in the Seg_A segment

Remember the lan0 on ECV-4 is in the 10.110.114.0/24 subnet.
39. Go back to the Routes tab in Orchestrator.
40. Click on the Segment drop-down and select

Seg_A. You might need to click the Refresh
icon if the table is not yet updated with the
changes.
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.
DRAFT
Task 9: Re-test the ping from TG-11411 to TG-1011

41. 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…
42. View the Flows tab
43. On the segment filter drop-down, click on Seg_A, then click Apply
Apply
Because lan0 on ECV-4 is in Seg_A, the existing BGP connection to AOS-CX-3 originally
configured in the Default segment is now down. Therefore, AOS-CX-3 no longer has a
route to the 10.110.10.0/24 subnet, so it doesn’t forward the flow to ECV-4. This is why
the flow doesn’t show up in the Flows table.
DRAFT
Task 10: 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 1 error next to ECV-4?
44. Hover over the error:

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

Remember you must 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 AOS-CX-3 is in the

Default segment, which is off the wan interfaces.
We need to peer with AOS-CX-3 on Seg_A
Task 11: Disable BGP for the default segment

48. Click on the edit icon for ECV-4 Default
49. Click on the icon to Disable BGP for ECV-4 Default

50. Click Save.
DRAFT
Task 12: Configure BGP for Seg_A

51. Click on the BGP tab.
52. Click on the Peers button.

Notice there is now a Segment column, and it shows
AOS-CX-3’s IP address in the Default Segment.
53. Filter the Segment to show All segments

Remember you must clear the entire field to display the list of
configured segments.
54. Click on the edit icon for ECV-4 Seg_A
55. Configure BGP Information
 Enable BGP:
 Autonomous System Number 65001
 Router ID: 192.168.1.7

 AS Path Propagate:
56. Click Add under BGP Peers
57. Configure Peer Parameters for AOS-CX-3
DRAFT
 Peer IP: 10.110.114.1

 Peer ASN: 65001
58. Click Add
59. Click Save on the BGP Information window.
60. On the BGP Peers tab, click the Refresh icon
NOTE: You may need to use the drop-down next

to the refresh button to Refresh from appliance.
61. Wait until the Peer State on Seg_A is Established .

a. Go back to the Remote

Desktop window for TG-11411
session
c. Ping 10.110.10.11 -t
Why is the ping still failing? Ping reply is
coming from AOS-CX-3 (10.110.114.1) –
Destination net unreachable.
63. Click on the PuTTY icon from the

tool bar on the Landing Desktop.
DRAFT
64. Double-click on AOS-CX-3 in Saved Sessions
65. Log into AOS-CX-3:
• Login as: admin

66. Enter “show ip route bgp”
 The flow is still not hitting ECV-4 because

AOS-CX-3 has no routes pointing to ECV-4.
After reconfiguring the BGP peer in Seg_A, the connection is again Established. Why
is AOS-CX-3 still not learning any routes from ECV-4?
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 14: Enable Subnet Sharing on Seg_A

67. Go to the Routes tab on Orchestrator
68. Click on the All button
69. Filter the Segment to show the Seg_A segment
70. Click on the Edit icon for ECV-1 Seg_A
 Notice Automatically advertise local LAN subnets is not checked!
DRAFT
71. 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 Save
72. REPEAT STEPS 67 - 71 for ECV-4.

a. Go back to the Remote Desktop

window for TG-11411
session
c. Ping 10.110.10.11 -t
74. FINALLY SUCCESS!
Task 16: Validate route and flow tables

75. 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.
DRAFT
76. Go to the Flows Table
 Likewise, the Flows are now looking good.
DRAFT
REVIEW #14: QoS Shaper
1) Where is the traffic class assigned?

In the BIO configuration
2) T/F – It is not a problem if the minimum bandwdith percentage for all traffic classes
adds up to more than 100%.
FALSE – can result in lowest priority class being starved
3) T/F: It is possible to configure the Shaper using only Excess Weighting values (no
minimum bandwidth assigned).
TRUE – no class is guaranteed a % of bandwidth, but bandwidth is always divided up according to the weights
4) What is the most effficient method to assign QoS Shaper policies to the individual
appliances?
Configure the Shaper template and apply template group to the appliances
5) What are the four default traffic classes?

RealTime, CriticalApps, BulkApps and Default
6) You can create custom traffic classes. What is the total number of traffic classes
allowed in the shaper configuration?
10
DRAFT
LAB 10: Configure the QoS Shaper

Configuration / database backups and software updates are critically important network
processes. Due to numerous backups and updates taking place, bandwidth for user
applications is impacted while these are occurring. You need to configure the QoS Shaper to
limit the amount of bandwidth backups and software updates can take. In this scenario,
backups and updates are the only file transfers that use FTP.
Estimated Time: 40 Minutes
Objectives
 Calculate the shaper requirements for all current traffic classes plus one more that will
be used for FTP traffic only.
 Create a custom traffic class in the Shaper that will be used by FTP traffic
 Enter minimum bandwidth and excess weighting shaper values for each traffic class
 Apply the Shaper configurations to the appliances
 Create a custom BIO that matches only FTP and uses the BackupUpdate traffic class
 Delete the FTP rule from the BulkApps overlay ACL
Task 1: Calculate Shaper values for each traffic class
In this exercise, you determine the minimum bandwidth and excess weighting values for each
of the traffic classes. It is assumed that only Backups and Software Updates use FTP.
Define Shaping Requirements

In the table below, you will configure the shaper based on this customer criteria:
Do not rate limit any of the traffic classes.
There are five traffic classes (Shown in priority order.):

• RealTime
• CriticalApps
• BulkApps
• Default
• BackupUpdate
BackupUpdate traffic class is used for backup and software update background jobs.
DRAFT
This pie chart shows baseline

SD-WAN usage during
business hours. You will edit
these values according to the
adjustments defined below.
Adjustments to the baseline values:

1. Minimum Bandwidth
a. Limit backups and software updates to 15%.
b. Provide RealTime and CriticalApps with an additional 5%.
2. Excess Weighting:
a. Default and BulkApps are equal weight—100 each.
b. RealTime should be ten times the excess weight of Default.
c. CriticalApps should be five times the excess weight of Default.
d. Backup has already met its needs. Give it the lowest excess weight
possible.
3. Fill out the table below based upon the criteria listed above. You will use this
information to configure the QoS Shaper template.
Traffic Class Priority Min Bandwidth Excess Weight Max Bandwidth
RealTime 1 100
CriticalApps 2 100
BulkApps 3 100
Default 4 100
BackupUpdate 5 100
DRAFT
Task 2: Create the BackupUpdate traffic class in the Shaper
There are four traffic classes created by default – one for each of the preconfigured BIOs.
You will create a fifth traffic class that will shape traffic for the BackupUpdate BIO that will be
created next.
It is possible to configure the QoS Shaper individually on each appliance. Since all
appliances will be using the same configuration settings, you will create a template group for
the QoS Shaper and use it to push the QoS configuration to all appliances.
4. Go to the Templates tab:

Configuratiion > Templates &
Policies > Templates. It will open on
the Default Template Group.
5. Click on ‘Show All’ to display
the Available templates.
6. Drag all templates currently in
Active Templates to Available
Templates.
7. In Available Templates, scroll
down and drag Shaper to the
Active Templates column.
8. Click to highlight Shaper in Active Templates – the Shaper configuration table will
appear to the right.
DRAFT
Note that the default values for the four traffic classes.
9. In row 5 click UNUSED5 in the Traffic Name column and change the name to
BackupUpdate.
Task 3: Configure shaping values for all traffic classes

10. In the RealTime traffic class click the Min Bandwidth % field and enter the value from
the Shaper table.
DRAFT
11. Next click the Excess Weighting field for the RealTime traffic class and enter the
value from the Shaper table.
12. Repeat Steps 10 – 11 for the CriticalApps, BulkApps, Deffault and BackUpdate
traffic classes.
13. BulkApps will not be rate limited. Click on the Max Bandwidth % field and change it
to 100 to match the Shaper table.
14. Click Save As
15. Name the template

group Shaper
Policies
16. Click Save
DRAFT
17. Ensure all appliances are highlighted in the Appliance Tree.
18. Click Apply Template Groups in the bottom left of the Template Groups window.
19. Click the Add checkbox for Shaper Policies.
20. Click Apply.
21. Click Apply Templates

in the confirmation box.
Task 4: Create BackupUpdate BIO
22. Open the Business

Intent Overlays tab on
the Orchestrator.
23. Click the +New button.
24. Name the BIO BackupUpdate

and click Add
DRAFT
25. Click on SD-WAN Traffic to Internal Subnets for the BackupUpdate BIO.
26. In the Match drop-down, click Overlay ACL.
27. Click on the Edit icon for the Overlay ACL in

the Match Criteria
28. Click Add to add a new rule
29. Click the Edit icon next to

Match Everything.
30. Check the Application box and enter

“ftp” in the application field.
31. Click Save.
32. Ensure the rule is set to Permit.
33. Click Save
DRAFT
34. Add a second rule

(Priority 1010)
that iwill deny
everything else.
35. MPLS1 and INET1 should be

the only Primary interfaces.
Drag any other interfaces into
Available Interfaces.
36. The Backup interface will use

LTE.
37. Ensure the High Quality Link Bonding

Policy is highlighted in blue font.
38. Click on the Boost drop-down and

select Enabled.
39. Change the Peer Unavailable Option
to Use Best Route
40. Using the Traffic Class drop-down
ensure 5(UNUSED5 / BackupUpdate)
is selected.
41. Click OK on the Backups BIO screen.
We don’t need to worry about setting the Breakout Traffic to Internet & Cloud Services
because all the backup and update traffic will be internal.
42. In the BIOs tab, click and hold the “=” just below 5 in the Priority column and drag
BackupUpdate up to priority 4. If left at priority 5, nothing would ever match as
everything matches the DefaultOverlay.
DRAFT
Task 5: Edit the BulkApps BIO.
Currently priority 1040 in the BulkApps Overlay ACL matches on FTP. Because the BulkApps
BIO has a lower priority than the BackupUpdate BIO none of the FTP traffic will reach the
BackupUpdate BIO. To allow the FTP traffic to be shaped using the traffic class in the
BackupUpdate BIO you must delete the FTP rule from the BulkApps BIO.
43. Remove FTP from the Overlay ACL in the BulkApps BIO.
44. Click on the BulkApps BIO.
45. Click on the Edit icon

next to the Overlay ACL
46. Click the X at the far right of

Priority 1040 to remove FTP.
47. Verfiy priority 1040 - FTP is no

longer present in the ACL.
48. Click Save in the Associate ACL
screen
DRAFT
49. Click OK on the BulkApps BIO

screen.
50. Click Save and Apply

Overlays
51. Click Save in the
confirmation box
Task 6: Verify the Shaper configuration on ECV-1
52. Right-click ECV-1 in the Appliance Tree and click Appliance Manager
53. Go to Configuration > System & Networking > Shaper
The settings should match what was used when the Shaper Template was configured.
In this lab the basics of creating a new traffic class, configuring shaper values and
applying the shaper policies to all appliances using a Template Group are covered.
Because high volumes of traffic cannot be generated in this lab, we are unable to view the
effects of the QoS configuration.
DRAFT
REVIEW #15: IDS/IPS
1) What is the difference between IDS and IPS?

IDS detects threats, IPS prevents threats from being executed.
2) What is the first step in enabling IDS/IPS on an appliance?

Apply the Advanced Security license to the appliance
3) T/F: After applying the Advanced Security license to an appliance, it is ready to start
inspecting traffic.
False – You must apply the IDS/IPS mode for the appliance
4) T/F: Like Boost, the Advanced Security license is optional and is applied in the same
manner as Boost licensing.
FALSE - Advanced Security licenses are enabled per appliance, not per BIO.
DRAFT
LAB 11: Configure IDS/IPS

The EdgeConnect appliances can perform Intrusion Detection and Intrusion Prevention when
an additional Advanced Security license is purchased. IDS/IPS allows traffic to be inspected
against a list of signatures that are updated automatically. The process below outlines
applying the Advanced Security license to an appliance and then assigning the appliance to
one of the IDS/IPS modes.
Estimated Time: 30 Minutes
Objectives
 Apply Advanced Security license to ECV-1
 Enable IPS mode on ECV-1
 Configure Security Policies to inspect traffic
Task 1: Apply Advanced Security license to ECV-1

In smaller deployments such as this lab environment, the EdgeConnect appliance VMs
running ECOS-9.2.2.X might be provisioined with 8GB of RAM. Note that 16GB of RAM
is required in order to enable IDS/IPS on an EdgeConnect appliance. If there is
insufficient RAM memory the status of the EdgeConnect will display a “Not Eligible” status
on the IDS/IPS screen. ECV-1 is the only appliance in this lab provisioned with 16GB of
RAM.
1. Go to the Licenses tab on the Orchestrator (Configuration > Overlays & Security >
Licensing > Licenses)
2. Click on the edit icon for ECV-1.

3. Ensure that EC-AS is showing in the bottom drop-down box. If it is not displayed, then
click the drop-down and select EC-AS.
DRAFT
4. Click Apply at the bottom of the Assign

Licenses to Appliances screen.
5. Click OK in the Confirmation box
A green band with the message “Changes

applied succesfully” will briefly appear at the
bottom of the Orchestrator screen.
6. With the All button selected, verify that the Advanced Security license has been
configured and granted for ECV-1.
7. Go to the IDS/IPS tab

(Configuration >
Overlays & Security >
Security > Intrusion
Detection/Prevention)
DRAFT
8. Highlight only ECV-1 in

the Appliance Tree.
9. Click the Apply
IDS/IPS on
Appliances button.
10. Click on the radio

button for IPS-
Performant.
11. Click Save.
The status will remain “Not Enabled” until the security policies are configured for
inspection.
Adding inspection rules to the ZBF Policies is not covered in this lab.
DRAFT
Appendix A: Connecting to ReadyTech for

Instructor-Led Training Students
1. The instructor will generate and assign Access Codes and will paste them in the
Teams 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.
DRAFT
Appendix B: Solutions to Common Issues

Issue #1: 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 login screen does not appear, contact your instructor.
Issue #2: 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’
DRAFT
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.
DRAFT
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
DRAFT
17. Click Apply
18. Click OK
19. Click OK
DRAFT
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
Issue #3: Unable to access EC-V after reboot following Initial

Configuration Wizard
Due to changes to the default deployment mode functionality, after you reboot an
EdgeConnect following the Initial Configuration Wizard, you can’t access it via HTTP/HTTPS
until you approve its registration from Orchestrator. If you applied the incorrect license
account name and / or account key, or you assigned the incorrect MAC addresses to the
EdgeConnect appliance’s interfaces, follow these steps:
24. From VMware ESXi, open a console window for the EdgeConnect.
25. Press F1 to start a command line interface (CLI).
 With some keyboards, you might need to enter the Fn (Function) key and the F1 key
together.
26. Enter the username admin and the password admin.
27. Enter enable at the command prompt.
28. Enter configure terminal.
29. Enter reboot empty-db.
 This command resets the EdgeConnect to factory default settings.
DRAFT
30. After the EdgeConnect is done rebooting, note the IP address at the top of the console
window.
 You need to wait about 2 minutes before the EdgeConnect accepts HTTPS connection
attempts.
31. Open a Google Chrome tab, enter the https:// followed by the IP address from step 7,
and then press Enter.
32. Click through any Google Chrome security warnings that might appear.
33. Log in to the EdgeConnect with these credentials:
a. User Name: admin
b. Password: admin
34. Click Login to open the Initial Config Wizard. If the Initial Config Wizard doesn’t
automatically appear after you log in, click Configuration > [System & Networking] >
Intial Config Wizard on the appliance’s menu to open it.
Issue #4: Lab Is Frozen

From time to time, there might be brief periods of unresponsiveness in the lab where the
screen is frozen and you are unable to change browser tabs. If the lab remains frozen for
more than a minute or so, or if there are continued periods of freezing that is impacting your
ability to do the labs, then you can reboot the entire lab.
1. You reboot the lab from the main Lab Portal screen using the menu in the blue bar at
the top. Click on Lab > Actions > Hard Reboot.
DRAFT
2. Click the checkbox next to the Lab name and and then click OK.
It will take approximately 15 minutes for the lab to reboot and become accessible again.
When rebooting, the status icon will change to a red downward pointing arrow. After a few
minutes, the status will change to up and green. You will want to wait 3-5 more minutes after
the status changes to up before attempting to access the lab again while the network
services are starting on the landing desktop. If you attempt to log in but end up back on the
main portal window, then the landing desktop is not yet ready. Try again in a few minutes.
DRAFT
Appendix C: Getting Support

Contact ReadyTech for:
ReadyTech Response Time
 Problems redeeming a voucher ReadyTech Support is
24
/7
available 24 hours, 7 days a
(instructions above) week. Questions are usually
responded to within a couple
of hours.
 Lab never comes up after a few hours.
 Lab seems to have gone down or you

cannot reconnect.
 Pre-installed virtual machines that aren’t

operating in VMware ESXi when you first
log into the lab.
35. Click on the Support link

a. Available options are:
 Email: getsupport@readytech.com
 Live Chat
 Contact by telephone
 24x7 support
Contact Aruba/EdgeConnect Team for:

Aruba/Silver Peak
Response Time
 Instructional videos
Expect a response within one
NEXT business day (Mon-Fri) during
 Course material or Lab instructions BUSINESS
DAY
normal business hours in
California, United States.
 Configuration of the Orchestrator or

EdgeConnect VMs.
 Virtual machines, in VMware ESXi, that

you installed per Student as part of an
exercise.
36. Click to email: sp-training@hpe.com

A new email should open in your application
DRAFT
Compose your email

37. In Subject: Replace TYPEissue with a short description of your issue
Example Subject Lines:
a. LAB# 98765432 - ASD – Setup script failed
b. LAB# 14377722 - ASD – Can’t get IP Address on ECV-4
c. In the body, include your:

 LAB ACCESS CODE
 Position in lab guide:
A) Lab#
B) Page#
C) Step#
 Screenshot(s)
INSTRUCTOR VERSION Template Version 2022.01 r1.4
Appendix D: Usernames and Passwords Lab Access Code
System/Platform User Password Notes
Landing Desktop Administrator Speak-123
VMware web Client admin Speak-123
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
AOS-CX-2, AOS-CX-3 This password is used after

admin Speak-123
executing the enable command.
Windows hMail student@training.local Speak-123
UBU-1 student Speak-123 Use VMware console
INSTRUCTOR VERSION
Appendix E: Summary of Orchestrator and EC-V Appliances

VMware ESXi Virtual Switch Next-hop IP
Virtual Machine MAC Address EC-V Interface IP Address
Network Adapter (Port Group) Address
Orchestrator 1 SW 01 - Management Automatic N/A 192.168.1.254/24 192.168.1.253
ECV-1 1 SW 01 - Management 00:50:56:01:01:01 mgmt0 192.168.1.4/24 N/A
2 SW 02 00:50:56:01:01:02 lan0 10.110.10.100/24 N/A
3 SW 03 00:50:56:01:01:03 wan0 10.110.103.100/24 10.110.103.1
4 SW 04 00:50:56:01:01:04 wan 1 10.110.104.100/24 10.110.104.1
5 SW 05 00:50:56:01:01:05 wan2 10.110.105.100/24 10.110.105.1
2 SW 06 00:50:56:02:02:02 lan0 10.110.20.101/24 N/A
3 SW 08 00:50:56:02:02:03 wan0 10.110.108.100/24 10.110.108.1
SW11 00:50:56:02:02:04 wan1 169.254.1.X/30
2 SW 06 00:50:56:03:03:02 lan0 10.110.20.102/24 N/A
3 SW 09 00:50:56:03:03:03 wan0 10.110.109.100/24 10.110.108.1
4 SW10 00:50:56:03:03:04 wan1 10.110.110.100/24 10.110.110.1
5 SW11 00:50:56:03:03:05 wan2 169.254.1.X/30
2 SW 13 00:50:56:04:04:02 lan0 10.110.35.101/24 N/A
3 SW 15 00:50:56:04:04:03 wan0 10.110.115.101/24 10.110.115.1
4 SW 16 00:50:56:04:04:04 wan1 10.110.116.101/24 10.110.116.1

2 SW 13 00:50:56:05:05:02 lan0 10.110.35.102/24 N/A
3 SW 15 00:50:56:05:05:03 wan0 10.110.115.102/24 10.110.115.1
4 SW 16 00:50:56:05:05:04 wan1 10.110.116.102/24 10.110.116.1
ASD 9.2. Student Lab Guide v1.8 Do Not Replicate page 210 of 211
INSTRUCTOR VERSION
Appendix F: ASD Lab Topology
ASD 9.2. Student Lab Guide v1.8 Do Not Replicate page 211 of 211

ASD 9.2 Lab Guide v1.8

Uploaded by

Copyright:

Available Formats

You might also like

ASD 9.2 Lab Guide v1.8

Uploaded by

Document Information

Original Description:

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.2 Lab Guide v1.8

Uploaded by

Copyright:

Available Formats

INSTRUCTOR VERSION

Aruba Advanced SD-WAN

Advanced SD-WAN Deployments Lab Guide

Date: December 2023

Warranties and Disclaimers

Aruba, A Hewlett Packard Enterprise Company

HANDS-ON LABS - PART A (ELEARNING STUDENTS ONLY) ........................................................ 5

LAB 1: LAB FAMILIARIZATION AND LICENSING DEVICES ............................................ 13

REVIEW #1: PATH AND ROUTE SELECTION & MONITORING ................................................ 28

REVIEW #2: POLICIES ............................................................................................................... 30

REVIEW #3: LOOPBACK INTERFACES .................................................................................... 31

LAB 2: CREATE ORCHESTRATED LOOPBACKS ............................................................ 32

REVIEW #4: INTERNET BREAKOUT AND TRAFFIC CLASSIFICATION ................................... 39

REVIEW #5: IP SLA .................................................................................................................... 40

LAB 3: LOCAL INTERNET BREAKOUT............................................................................. 41

REVIEW #6: OSPF ..................................................................................................................... 70

LAB 4: OSPF ..................................................................................................................... 71

REVIEW #7: BGP........................................................................................................................ 81

HANDS-ON LABS - PART B (ELEARNING STUDENTS ONLY) ...................................................... 98

REVIEW #8: IP SLA .................................................................................................................. 109

REVIEW #9: ROUTE MAPS ...................................................................................................... 110

LAB 6: ROUTE MAPS ...................................................................................................... 111

REVIEW #10: REGIONS ............................................................................................................. 132

LAB 7: REGIONS ............................................................................................................. 133

REVIEW #11: SECURITY FEATURES ....................................................................................... 150

REVIEW #12: ZONE BASED FIREWALL .................................................................................... 151

LAB 8: ZONE BASED FIREWALL .................................................................................... 152

REVIEW #13: ASYMMETRY & FLOW REDIRECTION ............................................................... 169

LAB 9: SEGMENTATION (VRF) ...................................................................................... 170

REVIEW #14: QOS SHAPER ...................................................................................................... 184

LAB 10: CONFIGURE THE QOS SHAPER........................................................................ 185

REVIEW #15: IDS/IPS................................................................................................................. 195

LAB 11: CONFIGURE IDS/IPS .......................................................................................... 196

APPENDIX A: CONNECTING TO READYTECH FOR INSTRUCTOR-LED TRAINING STUDENTS

APPENDIX B: SOLUTIONS TO COMMON ISSUES ................................................................... 200

APPENDIX C: GETTING SUPPORT ........................................................................................... 207

APPENDIX D: USERNAMES AND PASSWORDS LAB ACCESS CODE ................................... 209

APPENDIX E: SUMMARY OF ORCHESTRATOR AND EC-V APPLIANCES .............................. 210

APPENDIX F: ASD LAB TOPOLOGY.......................................................................................... 211

Hands-on Labs - PART A (eLearning Students

Important Considerations for Obtaining Lab Vouchers

DO NOT REQUEST MORE THAN ONE VOUCHER!

Task 1: Click on the link in the video to acknowledge and request a

3. Click Add to Advanced Aruba SD-WAN Deployments v9.2 – Part A

cart. Advanced Aruba SD-WAN Deployments v9.2 – Part A

ASD v9.2 - PART A

ASD v9.2 - PART A

5. Fill in your contact

6. Then click Next.

Fill in your correct

for this course in

ASD 9.2 – Part Advanced Aruba SD-WAN

Close the window.

Task 2: Redeem the Lab

11. When you are ready to start

You will be taken to the training

Advanced Aruba SD-WAN Deployments v9.2 – Part A

12. Make sure to