ASD Self-Paced 8.1.6 Lab Manual v2.14 PDF

Silver Peak
Advanced SDWAN
Deployments
Self-Paced Lab Guide

Version 2.14
Advanced SDWAN Deployments Self-Paced Lab Guide
Date: November 2017
Copyright © 2017 Silver Peak Systems, Inc. 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 Systems, Inc.
Trademark Notification
The following are trademarks of Silver Peak Systems, Inc.: 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™, and Silver Peak Orchestrator™. 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 SYSTEMS, INC. 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 SYSTEMS, INC. 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 SYSTEMS, INC. MAY MAKE IMPROVEMENTS AND/OR CHANGES IN THE
PRODUCT(S) AND/OR THE PROGRAM(S) DESCRIBED IN THIS DOCUMENTATION AT ANY TIME.
Silver Peak Systems, Inc.

2860 De La Cruz Boulevard, Suite 100
Santa Clara, CA 95050
1.877.210.7325 (toll-free in USA)

+1.408.935.1850
http://www.silver-peak.com/support
Page 2 of 164 Do Not Replicate ASD Self-Paced 8.1.6 Lab Guide v2.14
Table of Contents
Initial Instructions ............................................................................................................. 6
Materials 6
Lab Environment 6
Task: Print your lab guide 6
LAB 1: License Orchestrator and Appliances ................................................................. 7

Task 1: Familiarization with the lab topology 7
Task 2: Connect to the ReadyTech lab environment 8
Task 3: Check to make sure all VMs are deployed. 17
Task 4: Run the setup script to prepare your lab environment 18
Task 4: Log into Orchestrator and dismiss notifications 21
Task 5: Review the current deployment 21
Lab 2: Observe and Correct Tunnel Formation ............................................................. 24

Task 1: Observe unwanted tunnels between ECV-2 and ECV-3 24
Task 2: Change the site name on ECV-2 and ECV-3 25
Task 3: Observe corrected tunnels 26
Lab 3: Overlay Behavior, Stateful Firewall and WAN Hardening ................................... 27

Task 1: Observe the effects of Peer Unavailable Action and WAN interface hardening 27
Task 2: Observe the effect of interface hardening 38
Task 3: Observe the operation of traceroute 41
Task 4: Reconfigure the DefaultOverlay 45
Task 5: Configure ECV-2 and ECV-3 to advertise local subnets to branch offices 46
Task 6: Test FTP from Site 1 to Site 2 51
LAB 4: Internet Breakout & Passthrough Tunnels ......................................................... 55

Task 1: Test connectivity to a site on the Internet 56
Task 2: Change ECV-1 wan1 to Stateful+SNAT 57
Task 3: Observe automatically created Passthrough tunnels 58
Task 4: Configure an Internet Breakout Business Intent Overlay 58
Task 5: Check connectivity to UBU-1 61
Task 6: Configure the IP SLA destinations for the DefaultOverlay 63
Task 7: Close the connection on TG-1011 66
Access Labs 5 and 6 ..................................................................................................... 67

Task 1: Obtain a voucher and login 67
ASD 8.1.6 Self-Paced Lab Guide v2.14 Do Not Replicate Page 3 of 164
Task 4: Log into Orchestrator 78
Lab 5: BGP .................................................................................................................... 79

Task 1: Remove existing static routes from the CSRs and create loopback addresses 79
Task 2: Configure eBGP on the CSRs 81
Task 3: Configure eBGP on ECV-2 and ECV-3 84
Task 4: Configure ECV-2 and ECV-3 not to advertise local LAN routes 93
Task 5: Add the ECVs as neighbors on the CSRs 95
Task 6: Check BGP operation on the appliances 95
Task 7: Check BGP operation on the routers 96
Task 8: Configure ECV-1 to only advertise the LAN-side subnets 100
Task 9: Verify correct route propagation on the appliances 102
Task 10: Verify the configuration 103
LAB 6: Configure Flow Redirection on ECV-2 and ECV-3........................................... 107

Task 1: Configure Flow Redirection 107
Task 2: Check for Flow Symmetry and Boost 110
Access Labs 7 and 8 ................................................................................................... 114

Task 1: Obtain a voucher and login 114
Task 4: Log into Orchestrator 126
Lab 7: Configure PBR & VRRP ................................................................................... 128

Task 1: Configure VRRP on the appliances 128
Task 2: Configure PBR on the CSRs 130
Task 3: Test Redirection 134
LAB 8: Configure HA on ECV-2 and ECV-3 ................................................................ 139

Task 1: Disable BGP neighbors between CSRs 139
Task 2: Disable Flow Redirection 141
Task 3: Temporarily remove default overlay 141
Task 4: Enable All VLANS for the vSwitch Portgroup used by the HA Interfaces 142
Task 5: Enable HA on ECV-2 and ECV-3 145
Task 6: Observe device status 147
Task 7: Reapply the overlay 148
Task 8: Observe tunnel formation 149
Task 9: Test data flow over the HA Link 150
Appendix 1: What to do if the setup script doesn’t complete successfully ................... 157
Lab Topology Diagrams: ............................................................................................. 161
Login Information ......................................................................................................... 164
Initial Instructions
Overview
This section explains the process to access the lab environment. Please read this section
and perform tasks outlined in the Task below.
Materials
You will use this guide for all 8 labs in the course. It is inconvenient to use the PDF to
complete the labs, therefore it is best that you print this guide.
Lab Environment
Labs for this course are implemented in the ReadyTech hosted training environment. The
network architecture is discussed in a lesson. There are three separate lab environments.
Each represents the same class network at different stages of completion.
• Labs 1-4: Lab familiarity, tunnel formation details, troubleshooting connectivity and
local Internet Breakout (D2N: direct-to-net).
• Labs 5-6: BGP and Flow Redirection
• Labs 7-8: PBR, VRRP, and HA
You will request each when you are ready to complete the labs. Once you connect to the lab
environment, you will have 20 hours to complete that set of labs.
Task: Print your lab guide

1. Print this lab guide. (See “Materials” above for details.)
LAB 1: License Orchestrator and
Appliances
Overview
In this lab you will familiarize yourself with the lab topology, then license the
Orchestrator/GMS and the appliances and register them with the cloud portal.
Objective
Learn how the environment is set up for this course, connect to the remote lab, and license
your machines to prepare them for the rest of the lab tasks.
Task 1: Familiarization with the lab topology

Familiarize yourself with the lab environment.
Topology:
Note: A larger diagram along with device userids and passwords is on the last two pages of
this lab manual. Tear it out (or print it) for reference throughout this course
Topology Details:
• There are 2 sites. Each site has two connections to the WAN; one over an MPLS
network and one over Internet (each network is actually a WAN emulator). Site 2 is set
up like a data center with redundant Silver Peak appliances.
• All the Silver Peaks, including those at Site 2, are in ILRM (inline router mode).
o At site 2, traffic passes into lan0 of the appliances via the routers through
vSwitch 10
• All masks are 24 bit.
• CSR-1 has a default route that points to 10.110.32.1 on the MPLS network.
• CSR-2 has a default route that points to 10.110.42.1 on the Internet network.
• The wan emulators have routes to all the data path subnets.
• There is an out of band management network (dotted line) using the 192.168.1.0
subnet.
• Most devices have a connection in the management network, and in at least one other
subnet. When you connect to devices from the Student PC, you will use the
management network. When you connect devices over the data path, you’ll be using
one or more of the 10.110.x.x networks.
• Addressing Notes:
o The default gateway (DG) address for the management network is
192.168.1.253.
o The DNS server address is 8.8.8.8, reachable via the DG. If your lab is
deployed in the US, an alternate DNS server is available at 10.0.1.25.
o The NTP server address is 192.168.1.251 (resides in K1-MPLS VM).
DHCP on the management network will assign addresses to new devices if

needed, and inform them of the DG and DNS server address. This will allow
them to resolve the default name of the Silver Peak Cloud Portal
(cloudportal.silver-peak.com) so they can register themselves with the portal.
A physical appliance would be able to use its unique burned in serial number to register
since the Cloud Portal is aware which serial numbers are associated with which accounts.
Virtual appliances (such as we use in this course) must be given an account name and
account key in order to register and be associated with the correct account. The Cloud
Portal will generate a serial number and assign it to each registering virtual appliance and
associate the new serial number with the account.
Task 2: Connect to the ReadyTech lab environment

1. Go to http://silverpeak.find.training/
2. Click “Advanced SDWAN Deployments (ASD) Labs 1-4” to select it.
Please make sure you select the correct lab as there are many to choose from and
each image is different.
Note: The number one cause of student support requests for problems with the
self-paced labs is students picking the first lab in the list instead of reading the
directions, and choosing the correct lab. If you choose the wrong one, you will
get the wrong image, and will not be able to follow the lab instructions.
3. Click on Add to cart.
4. Click Check out.
5. Fill in your contact information using the same name and email that you used to
register for the course. Then click Next.
Note: A correct email address is required for you to receive your voucher.
6. Checkout.
a. Make sure the correct labs are shown in the Payment window.
b. Check the acknowledgement checkbox. (Silver Peak will be billed. Your cost is
$0.00 as shown).
7. Click Place order.
A Purchase confirmation will be displayed.
8. Close the window.

9. Check your email. Find the email containing your voucher information (see screenshot
below) and open it.
10. When you are ready to start the lab, click Redeem Now.
11. You will be taken to the training lab environment. Click Redeem.
12. Fill in your personal information and click Redeem.
13. Click OK to activate the code.
You should now be in the Silver Peak Self-Paced Training portal.

14. Select the Lab menu.
15. When you are ready to begin, click Start lab now.
You will have one day 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 Silver
Peak labs are designed to be completed within 2-4 hours.
16. Click Start now.
Although the message says it may take up to xxx minutes to start (144 in the screen
shot above), your wait should only be 5-10 minutes as machines are deployed from a
hot standby pool.
Note: The only time that you should have to wait the full length of time is when
demand is high and all the machines in the pool have been deployed.
17. A message will display. Click Close.
18. 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. If it has not changed
to UP within 2 ½ hours, contact ReadyTech support.
19. To access the lab, click Click here to connect.
20. Login.
a. You should be connected to the remote desktop, which will show a larger
version of the thumbnail image and fill the browser window. Click on the login
icon and login as Administrator using the password Silverpeak1.
b. It is possible to go full screen with your browser window by selecting it from the
dropdown menu. Detaching the window can also gain useful space.
21. Other Lab Notes:

a. DO NOT update, upgrade or register anything in the lab environment unless
explicitly told to do so in the lab instructions.
b. Use the Esc key to exit Full Screen mode.
c. If you need to enter commands in a VMware console window, and you find that
incorrect characters are displaying, you might need to use the onscreen
keyboard.
i. Use the menu shown above and choose Enable Viewer Toolbar.
ii. From the viewer toolbar, enable the onscreen keyboard.
iii. Drag the keyboard over the console window. It may be necessary to
position the keyboard so the letter you want to type is directly over the
active area of the console window.
Task 3: Check to make sure all VMs are deployed.
Note: It’s always possible that you have logged in at a time of high demand, and because
a fresh environment is in the process of being deployed, your lab might not be completely
ready. When this happens, if you log in before the lab is fully deployed, some VMs may be
partially deployed, or missing altogether until the deployment scripts complete, which can
take up to 2 hours. This step is to make sure that your lab is fully deployed. In this case a
fresh machine will need to be deployed for you.
1. On the Student PC desktop, open the VMware vSphere Client by double-clicking on the
desktop icon.
2. Login as root/training.
3. Check the checkbox to Install this certificate… and click Ignore. Ignore any other
warnings.
4. If you see this message, click Yes, otherwise skip to the next step.
5. Click the ‘+’ symbol to expand the list of VMs installed in the esxihost.
6. Match the list of deployed VMs to the list below:
If the list is incomplete, your lab is probably still deploying. Take a break, get some
coffee/tea, or something to eat, then recheck the list in a little while. Remember that a full
deployment can take up to 2 hours.
Task 4: Run the setup script to prepare your lab environment

1. Once all the VMs have deployed, double-click the Chrome browser icon on the desktop.
Four tabs will open by default:

a. Orchestrator (192.168.1.254)
b. ECV-1’s management address (192.168.1.4)
c. ECV-2’s management address (192.168.1.5)
d. ECV-3’s management address (192.168.1.6)
2. Verify the login screen for Orchestrator can be displayed.
a. You may need to click past any browser security warning screens.
i. Click Advanced.
ii. Click Proceed to 192.168.1.254 (unsafe).
b. You should see the login screen. If you see the screen below, skip to step 3.
c. Do this step only if you DO NOT SEE the screen above, the VM needs to be re-
booted.
i. Return to VMware.
ii. Select the Orchestrator.
iii. Click the restart icon:
Again, only do this if you DID NOT see the logon screen in Chrome.
iv. Refresh your browser window to make sure the Orchestrator login screen is
displayed.
Note: This may take a few minutes. Refresh as necessary.
3. Once the browser login screen has displayed, on the Student PC desktop, double-click
the ILT ASD 8.1.6 Setup to run the setup script.
4. The script will run and generate a Command Prompt window.
Note: The script may take a several minutes to run.

5. When the script completes, it will display the ASD Setup Log file.
6. If the log reports each and every step is a “SUCCESS”, close the txt file and command
prompt.
Note: If the setup script does not complete as shown, Do NOT try to rerun the
script. Go to Appendix 1 at the end of this document just before the topology diagrams.
Follow the directions there, which will walk you through some steps that you need to
complete before rerunning the setup script.
7. Close the Setup Log.
8. Close the command window that opened to run the script.
Task 4: Log into Orchestrator and dismiss notifications

1. Return to the Chrome browser.
2. Login to Orchestrator using admin/admin.
3. Dismiss any software release announcements.
You will probably see some announcements regarding recently released software. They
may be for different releases than those shown here. All software used in this course is
already loaded. Click Dismiss to close out any dialog boxes.
Task 5: Review the current deployment

Now that you have licensed the Orchestrator and appliances, it’s important to understand the
current state of the network as we start the other labs.
1. In Orchestrator, go to the Apply Overlays tab (Configuration[Overlay Prerequisites]

Apply Overlays).
2. Observe the applied Overlays.
ECV-1, ECV-2, and ECV-3, are all part of the mesh fabric created by a Business Intent
Overlay called “DefaultOverlay”, which matches all traffic.
3. Go to the Business Intent Overlays tab (ConfigurationBusiness Intent Overlays)
4. Select the DefaultOverlay.
5. Examine the Overlay.
Underlay and Overlay Tunnels connect the appliances together with a Link Bonding
Policy of “High Throughput”, which load balances.
Note: This DefaultOverlay has been changed from the one that is part of a fresh 8.2.0
Orchestrator ova install. It has been updated to demonstrate certain properties in of
overlays for this course.
6. Review the network topology diagram below. Key elements are:
a. The appliances are all in ILRM (Inline Router Mode).
Local, LAN-side packets arrive on lan0, tunnels exit wan0 (MPLS) and wan1
(Internet).
b. The two Cisco routers (CSR-1 and CSR-2) at Site 2 have default routes that point
to their respective MPLS or Internet wan emulators as a next hop. Each has a
static route that points to other router for local subnets that are not directly
connected. Neither is currently configured for any routing protocol. Neither router
does any traffic redirection to either of the EdgeConnect appliances at Site 2, so
any traffic destined to Site 1 that reaches either router will be forwarded directly
across the wan until we configure a traffic redirection method in later labs.
c. At site 2, each has a lan0 interface connected to portgroup 10 on the vSwitch.
Each has two wan interfaces, one connected to each CSR on portgroups 7 and 8.
Lab 2: Observe and Correct Tunnel
Formation
Overview
This short lab illustrates that the Orchestrator built some extra tunnels. You’ll identify these
and the underlying cause.
Objective
Increase your understanding of how mesh networks are built and how to use site names to
obtain a desired result.
Task 1: Observe unwanted tunnels between ECV-2 and ECV-3

1. In Orchestrator, select all appliances in the Training group in the Tree View.
2. In Orchestrator, go to the Tunnels tab (Configuration[Tunnels] Tunnels).
3. The overlay manager should have built two overlay tunnels for each of our wan
connections from ECV-1ECV-2 and ECV-1ECV-3, for a total of 4 overlay tunnels
(including one in the reverse direction from ECV-2ECV1 and ECV-3ECV-1. We
can see that this was done. Note: Make sure Overlay is selected.
However, we can see that ECV-2 and ECV-3 also each have 2 tunnels: one back to
ECV-1 as expected, and tunnels from ECV-2ECV-3 and ECV-3ECV-2 (highlighted
in the picture).
Since ECV-2 and ECV-3 are in the same network, and at the same site in London at
the same street address, it makes no sense to have tunnels between them.
The overlay manager is smart enough to omit building tunnels between two appliances
at the same site if it knows that they are indeed at the same site. Even though the
street address is the same in London, the appliances could be in separate networks,
so street address by itself is not enough information.
This happened because of one detail. There is a field called Site Name that wasn’t
filled in for these appliances. Let’s fix this.
Task 2: Change the site name on ECV-2 and ECV-3

1. Change the site name on ECV-2.
a. In the Tree View, mouse over ECV-2, and click the menu icon.
Note: If IP addresses do not display next to the host name, click the gear icon
above Tree View, check the Show IP checkbox, and close the dialog.
b. Select Modify Appliance.
c. In the dialog window that appears, add Site Name “London”.
d. Click OK.
2. Change the site name on ECV-3.

a. In the Tree View, mouse over ECV-3, click the menu icon.
b. Select Modify Appliance.
c. In the dialog window that appears, add Site Name “London”.
d. Click OK.
Task 3: Observe corrected tunnels

1. As the overlay manager works to correct the network configuration, the appliances
should resync (indicated by the colored boxes that appear around the appliance
names in Tree View).
Note: As of 8.1.10 the resync may happen quickly enough that you may miss it.
2. When the process completes, the unwanted tunnels between ECV-2 and ECV-3 will
be removed as in the picture below. It may be necessary to click the refresh icon
to see the updated information.
Lab 3: Overlay Behavior, Stateful Firewall
and WAN Hardening
Overview
In this lab, you’ll learn some techniques that will help you debug problems in your network
when traffic doesn’t behave as expected.
Objective
Learn how overlays handle packets that match a Business Intent Overlay Traffic Access
policy when no route to the destination is known. Observe the effects of WAN hardening and
stateful firewall settings on a WAN interface, and learn how it can affect the ability of devices
to establish a session.
Task 1: Observe the effects of Peer Unavailable Action and WAN

interface hardening
1. In Orchestrator, view flows for ECV-1.
a. In the Tree View, select only ECV-1.
b. In Orchestrator, select Monitoring[Flows] Active & Recent Flows.
In the step below, you’ll start a ping and then come back to this page to see the
status of the flow.
2. From the Student PC desktop, open a Remote Desktop connection to TG-1011.
a. On the desktop of the Student PC, launch Remote Desktop.
b. Log into TG-1011 (192.168.1.10). The password is Silverpeak1.
3. Ignore and close any warning messages, reboot reason messages etc.
4. Ping TG-3311 from TG-1011 per the steps below:
a. Refer to your topology diagram to see where TG-3311 and TG-1011 exist in
relation to each other in the network.
b. On TG-1011’s desktop in the RDP window, open a command prompt window.
c. Ping TG-3311 (10.110.33.11). We know from the network topology that the ping
will have to go through ECV-1.
The ping should fail. While it is running, look for the flow on ECV-1 as described
below.
5. Observe the flow in the flow report on Orchestrator.
a. Return to Orchestrator and go to the Flows tab (Configuration[Flows]
Active & Recent Flows).
b. Click the refresh button . You should see a flow like the one below.
Notice Outbound Tunnel is “Policy Drop”. In this case it may mean that the
flow matched a BIO but was dropped. We can find out which one. See the next
step.
Note: If the flow has already timed out and doesn’t appear in the table, repeat
the ping in the command window on TG-1011 and then come back to the flow
table and click the refresh button. Alternatively, you can click the selector to
show flows that have ended in the last 5 minutes.
Also, you can usually ignore any flows from an appliance source address with a
destination port (port 2) of 443. These are just the data path interfaces of the
appliances periodically trying to connect to the cloud portal.
c. Click the Flow Detail icon in the column labeled Detail. You can see in the
Route section that it matched a route map with the priority of 20000 and the Tx
Reason is “Auto-opt – I/F drop”.
d. Close the Flow Detail window.

6. To view which BIO created that entry, make sure ECV-1 is selected in Tree View, then
go to the Route Policies tab (Configuration[Policies] Route Policies).
7. This will show you the configured route policies on ECV-1.
The entry with the priority of 20000 was created by the Business Intent Overlay called
“DefaultOverlay” (see the Destination column). The policy matches the ACL called
“AnyTraffic”, which matches everything, controls the traffic access for the
“DefaultOverlay” Business Intent Overlay.
At this point, you might be wondering, if it matched the overlay, why didn’t ECV-1 put
the flow in a tunnel that goes to one of the EdgeConnect appliances at the other site
where TG-3311 is?
Perhaps it hit the Peer Unavailable Action in the overlay. This could happen under
certain conditions which we’ll explain below.
Note: ‘Peer Unavailable Action’ was called ‘Overlay Down Action’ in earlier versions of
code. In either case, it means that no path was available via this overlay’s tunnels to
the destination.
8. Change the Peer Unavailable Action to temporarily work around the above issue.
a. In Orchestrator, go to the Business Intent Overlays tab
(Configuration[Overlay Prerequisites] Business Intent Overlays).
b. Select the DefaultOverlay.
c. Change the Peer Unavailable Action to Pass Through.
This will cause packets to be sent out of wan0 unencapsulated if the destination
subnet is not reachable via the overlay connections, rather than being dropped.
d. Click Save All, then click Save to confirm.
The changes to to overlay will be pushed out to the appliances. When they
have finished resynchronizing, go to the next step.
e. Return to TG-1011.
f. Retry your ping from TG-1011 to TG-3311 as instructed above. Do you think it
might work now?
g. The ping now works. We proved also that the Peer Unavailable Action was
responsible. Why?
h. Return to Orchestrator.
i. Go to the Flows tab and refresh the display (ping again if needed and
refresh once more).
The outbound tunnel has changed to pass-through and the reply arrives the
same way.
As we mentioned above, the Peer Unavailable Action might be applied to some

of the traffic even though the overlay itself is up and able to pass traffic.
One possible reason is that the overlay wasn’t able to find a destination for a
packet that matched the Traffic Access policy for the overlay. We’ll see if this
might be the reason in upcoming steps.
9. Let’s try to determine if ECV-1 had a route to the destination subnet (10.110.33.0).
a. Return to Orchestrator.
b. Go to the Subnets tab (Configuration[Networking] Subnets).
c. Verify only ECV-1 is selected in the Tree View.

d. You should see ECV-1’s subnet table.
Notice there is no entry for the 10.110.33.0 subnet. Refer to your topology
diagram and notice that this subnet is not directly connected to either of the
appliances at Site 2, so neither of them is advertising it by default.
This explains why the ping failed. It matched the Traffic Access Policy (all
traffic) for the DefaultOverlay overlay, but there was no known route to the
destination so the packet was dropped. For that particular packet, the overlay
had failed to find a tunnel that would reach the destination, so it executed the
Peer Unavailable Action and dropped the packet.
See the diagram below…
When we changed the Peer Unavailable Action to Pass Through, instead of

being dropped, the packet was forwarded to the first next hop WAN-side router
(10.110.11.1) on wan0, which forwarded the packet across the network to its
destination. The next hop router knew a path to the destination and forwarded
the ping request. On the return path, the reply to the ping from TG-3311 went to
CSR-2, which forwarded it back to Site 1 over the Internet link through wan1 on
ECV-1.
10. Now ping from TG-3311 to TG-1011.

Note: This is the same ping, but in the reverse direction.
a. On the desktop of the Student PC, launch Remote Desktop.
b. Connect to TG-3311’s management interface at 192.168.1.30. Logon as

Administrator/Silverpeak1.
c. Open a command window on TG-3311’s desktop.
d. Ping TG-1011’s data path interface (10.110.10.11). Does it work?
This fails. But this is caused by a different issue.

Note: If the ping works, you probably have existing icmp flows between the two
systems. To correct this, go to all TG desktops, close all command prompts,
then reset flows in Orchestrator, then restart the ping from TG-3311 to TG-
1011.
11. Why is it possible to ping from TG-1011 to TG-3311 and have the ping succeed, but
when it is initiated from TG-3311 to TG-1011 it fails?
a. Examine the Deployment for ECV-1.
i. In Orchestrator, right-click ECV-1 in the Tree View.
ii. Select Deployment.
Notice the connection to the wan1 interface labeled Internet was

Stateful. In our network, the routing is currently set up in such a way that
the traffic from TG-3311 will be directed over the Internet link (CSR-2 has
a default route that points to 10.110.42.1), and the Internet WAN
emulator has routes to the 10.110.1x.0 networks via 10.110.12.100. This
means that the ping from TG-3311 will be directed to the wan1 interface
which is configured as a Stateful Firewall. Interfaces configured as a
stateful firewall will drop an inbound ping originating from a network
outside the local site.
iii. Close the Deployment page.
b. Explore the diagram of your earlier (working) ping.
In the topology diagram above, the green line shows the path the outbound ping
you initiated from TG-1011TG-3311 took. The return path is shown by the red
line. The ping from TG-1011TG-3311 succeeded because the ping was
initiated by TG-1011, and because ECV-1 knew the ping originated on the local
network, the ping reply was allowed in.
c. Explore the diagram of your current (failing) test.
When you initiated a ping from TG-3311TG-1011, it failed. The packet

initiating the ping outbound from TG-3311 travelled over the same red path, but
because the flow was initiated by TG-3311, when it reached the Stateful
Firewall on the wan1 interface on ECV-1, it was dropped because the flow
didn’t originate from within the local network at Site 1.
Important Lesson: From this behavior you should learn that if you initiate an
ICMP ping request from a device on a local network that is forwarded out
through a stateful firewall WAN interface outside a tunnel, the ICMP ping replies
will be allowed back in even though they arrive outside the tunnel. ICMP ping
requests that arrive at a stateful firewall interface outside of a tunnel will be
dropped when they are initiated from the WAN-side. Any pings that flow through
a tunnel will not be affected by the firewall. This is important to remember when
you are troubleshooting connectivity problems.
Task 2: Observe the effect of interface hardening
Now we’ll change the configuration of the wan1 interface on ECV-1 to ‘Harden’ and observe
the difference.
1. Go back to the Deployment page On ECV-1 (if you do not still have it open, in Tree
View, right-click on ECV-1 and select Deployment).
2. Change the configuration for wan1 from Stateful to Harden.
3. Click Apply.
4. Ping from TG-1011TG-3311.
a. Go to the RDP window you have open to TG-1011 at 192.168.1.10 (remember
you have two windows open, make sure to choose the correct one and not the
one to TG-3311).
b. Go to the command prompt widow.
c. Ping TG-3311 (10.110.33.11). We know from the network topology that the ping
will have to go through ECV-1.
The ping should now fail. While it is running, look for the flow on ECV-1 as
described below.
5. Return to Orchestrator and go to the Flows tab.
6. Click the refresh button . You should see a flow like the one below.
The ping is sent out passthrough, but the reply is dropped on the return path.
Important Lesson: If you initiate an ICMP ping request from a device on a local
network that is forwarded outside a tunnel, the ICMP ping replies will be dropped when
they arrive at the hardened interface inside or outside the tunnel. As you would expect,
any ICMP ping requests that arrive at a hardened interface outside of a tunnel will be
dropped when they are initiated from the WAN-side. Any pings that flow through a
tunnel will not be affected by the firewall.
7. Now ping from ECV-1’s wan1 interface.
a. Go to the browser tab opened in Chrome for ECV-1.
b. Click the Login button.
c. Login using admin/Training#1.
Note: This should be cached.
d. On ECV-1, go to the Ping/Traceroute page (Maintenance[TOOLS]
Ping/Traceroute).
e. Ping from ECV-1 wan1 (10.110.12.00)  TG-3311 (10.110.33.11). Make sure

you used the ‘-I’ option to specify the address of the wan1 interface
(10.110.12.100 – the hardened interface).
The ping succeeds! This is the same ping over almost the same path.
Important Lesson: If you want to troubleshoot connectivity that involves a

hardened interface, you need to ping from the hardened interface to the remote
device. Replies to pings that don’t originate from the appliance interface will be
dropped.
Note: In earlier versions of 8.1 that didn’t include the stateful firewall feature,
replies to pings originating from a local wan and outbound through a hardened
interface were allowed back in (somewhat mimicking stateful firewall interface
behavior, but only for pings). That behavior has been changed as you saw
above.
Also, if you retry the ping and check the flow table, you’ll notice it doesn’t
appear in the flow table. Be aware that outgoing pings initiated from the
Ping/Traceroute dialog won’t appear in the flow table because they were never
parsed as incoming flows.
8. Change the Internet interface back to Stateful.
a. On ECV-1, go to the Deployment configuration screen
(Configuration[Networking] Deployment).
b. Change the setting for the wan1 interface back to Stateful.
c. Click Apply.
d. Save your changes .
Task 3: Observe the operation of traceroute

1. Do a traceroute from TG-1011TG-3311.
Note: Windows abbreviates the ‘traceroute’ command as ‘tracert’.
a. Go back to your RDP window in TG-1011.
b. Open a command prompt window.
c. Type: tracert 10.110.33.11 and press enter.
2. Notice in step 4 there is nothing but a row of asterisks, but in step 5 the tracert is
successful. What’s going on?
Note: Tracroute/tracert works by sending packets to the destination device address

with an incrementing TTL (time to live). Three packets are sent for each increment,
and in the case of MS Windows, this is done via an ICMP ping request. Each device
that receives a packet decrements the TTL. When an intermediate device receives a
packet and the TTL becomes 0 (zero), it sends a TTL_expired message back to the
sending device.
The sending device receives the TTL_expired, and displays the source of the reply
and the elapsed time since the packet was sent, so you see the addresses of the
intermediate hops and the latency per hop in milliseconds.
If no reply is received, an asterisk ‘*’ is displayed for that TTL increment (e.g. step 4
above).
The end device gets the ICMP request and simply replies to it (step 5 above).
You should be aware that although Windows uses ICMP packets, some devices use
UDP, and in many cases (depending on the device type) you can choose by using an
option flag.
Let’s summarize what’s happening in our network as each device receives an ICMP
packet and the TTL is decremented to 0:
1. The ECV-1 replies – the path is direct across ECV-1 lan0
2. The next hop router replies – the path is through ECV-1 wan0 (set to ‘Allow All’)
3. CSR-1 replies – the path is through ECV-1 wan0
4. CSR-2 replies – the path is through ECV-1 wan1, which is set to Stateful
Firewall. The displayed output is recording 3 asterisks (***) however, indicating
that TG-1011 never received them. Where did they go?
5. The ping reply from TG-3311 is received by TG-1011 – the path is through
ECV-1 wan1
What’s going on: Because ECV-1 wan0 is set to allow all, the TTL_expired
messages are reaching TG-1011 when they are received through that interface.
In step 4, when the TTL_expired is received through wan1 (set to Stateful), the
TTL_expired messages from CSR-2 (10.110.30.2) are dropped and asterisks
are displayed. This is because the source address in this case, didn’t match the
stored state for the expected endpoint addresses of TG-1011 and TG-3511 (in
other words, the reply didn’t come from 10.110.33.11, it came from 10.110.30.2,
which wasn’t a destination that ECV-1 had cached for the flow). In step 5, the
ICMP reply from the destination device (TG-3311) is permitted through wan1,
because the ping originated from TG-1011 on lan0 of ECV-1 and the source
address of the reply (10.110.33.11 from TG-3311) matched the expected
source and destination addresses for the conversation.
The Lesson: Here’s another reminder that the firewall setting on the interface
can affect your troubleshooting.
3. The flows for the traceroute above, should look something like this:
This shows the replies that show up in the tracert command output.
4. Observe Traceroute when initiated from the appliance maintenance menu.

a. In ECV-1, go to the Ping/Traceroute page (Maintenance[TOOLS]
Ping/Traceroute).
b. Initiate a traceroute from ECV-1 to TG-3311.
Notes: The appliance uses UDP by default.

i. Specify a destination of TG-3311 (10.110.33.11)
ii. You need to specify -s <address> to specify the data path source
address of the desired WAN interface
(in our case wan1 - Internet - 10.110.12.100)
i.e.
iii. Click the Stop button to stop the traceroute after 6 hops or so.
The traceroute failed. Why?

By default, Silver Peak uses UDP to test path for traceroute functionality.
UDP is connectionless; no state can be stored. The traceroute will fail

because even if any interim hops reply w/ TTL expired messages, the
reply source address won’t match stored state for the conversation, and
neither will the reply from the end device.
Note: The default UDP protocol usage works properly if the outgoing
interface is set to ‘Allow All’ and the path is symmetric.
We’ll show you how to change the protocol in the next step.
c. Using the -I option will cause the appliance to use ICMP, and the ICMP reply
from the destination will be allowed in, although interim TTL expired replies will
still be dropped.
Why not just use a ping? Well, that’s fine if you just want to establish
reachability, but in this case, you established reachability, but also learned how
many hops away the destination was.
Note: if the outbound interface had been set to ‘Allow All’, all the hops would
show up instead of asterisks.
Task 4: Reconfigure the DefaultOverlay

Recall that a ping from TG-1011 to TG-3311 failed above because it hit the Peer
Unavailable action (which was set to drop) for the DefaultOverlay. Here we’ll add routes
so the branch knows how to reach the subnets and avoid the condition that caused them
to match the Peer Unavailable condition.
First, we need to reconfigure the Business Intent Overlay called DefaultOverlay. Since we
are simulating connection to the Internet over the Internet network, and we don’t want
unencrypted traffic to flow onto the Internet, we want to change our Peer Unavailable
Action back to ‘Drop’ for the Business Intent Overlay called DefaultOverlay.
1. In Orchestrator, go to the Business Intent Overlays tab

2. Select DefaultOverlay in the list of overlays.
3. Change the Peer Unavailable Action back to Drop.
Note: This returns this parameter to its original configuration—the one that did not
allow a ping. The tracert we did above will fail now also, although a reply will be
received from the first hop ECV-1 because it is from lan0, and has not hit the overlay
yet.
4. Click Save All and confirm the save.
Task 5: Configure ECV-2 and ECV-3 to advertise local subnets to

branch offices
In our network, we want the branch offices have a route to all of the subnets at Site 2 Data
Center. We’ll now add routes so the branch knows how to reach the subnets and avoid the
condition that caused them to match the overlay down condition.
1. Add routes to local subnets to ECV-2.

a. In the Tree View in Orchestrator, select all appliances.
b. Go to the Subnets tab (Configuration[Networking] Subnets).
c. Click the edit icon next to ECV-2 in the list
d. Click Add new subnet two times to add two new subnets..
i. First Subnet:
1. Subnet/Mask: 10.110.33.0/24
2. Metric: 60
3. Is Local: ✓
4. Advertise to Silver Peak Peers: ✓
5. Advertise to BGP Peers: ✓
ii. Second Subnet:
1. Subnet/Mask: 10.110.35.0/24
2. Metric: 50
3. Is Local: ✓
5. Advertise to BGP Peers: ✓
e. Click Apply.
2. Add two new subnets to ECV-3.
a. In the Tree View, select ECV-3.
b. On the Subnets tab, click the edit icon next to ECV-3.
c. Add two new subnets.
i. First Subnet
1. Subnet/Mask: 10.110.33.0/24
2. Metric: 50
3. Is Local: ✓
ii. Second Subnet
1. Subnet/Mask: 10.110.35.0/24
2. Metric: 60
3. Is Local: ✓
d. Click Apply.
Note: We added the same subnets to each of the appliances at Site 2, but used
different metrics. Looking at your topology diagram, you will realize that by
adjusting the advertised subnet metrics on each of the Silver Peaks at Site 2, we
will cause traffic going to TG-3511 on the 10.110.35.0 subnet to prefer ECV-2, and
traffic going to TG-3311 on the 10.110.33.0 subnet to prefer ECV-3.
3. Retry the ping from TG-1011 to TG-3311 (remember that we changed the Peer
Unavailable Action back to ‘Drop’, which had previously caused a ping initiated from
TG-1011TG-3311 to fail).
a. In the Tree View, select all appliances.
b. Go to the Flows tab so we can observe the flow when we start the ping in the
next step.
c. Go back to your RDP window open to TG-1011’s management address
(192.168.1.10).
d. In the open command window, ping TG-3311 (10.110.33.11).
e. The ping is successful now, even though we are back to our original Peer
Unavailable Action of Drop. We’ll see why in the next step.
f. Return to Orchestrator.
g. Click the refresh button on the Flows tab. Retry the ping if the flow has already
timed out and refresh again.
Note the flow originating from TG-1011, instead of being dropped, is placed in
an outbound tunnel called to_ECV-3_DefaultOverlay. Because ECV-1 now
knows how to get to the destination subnet, the packet is placed in the tunnel to
the destination.
The inbound tunnel is pass-through. This indicates that the flow in the return
direction arrived outside a tunnel.
On ECV-3 The inbound tunnel is the one called to_ECV-1_DefaultOverlay. This

is the other end of the same tunnel it was sent out on. The Outbound Tunnel is
None. This means that ECV-3 never saw the packets in the return direction.
(This is because we are not redirecting traffic at Site 2 yet. We’ll start doing that
in Lab 5.) The diagram below will show that path that the ping took on the
topology diagram.
In the diagram above, we can see the path the ping took. In the outbound
direction (green arrow) it went through a tunnel to ECV-3. ECV-3 forwarded the
packet to the next hop router (CSR-2), which forwarded it to TG-3311. In the
reverse direction (red), the ping response went to CSR-2, which forwarded it
across the WAN to its destination. It arrived outside the tunnel at ECV-1, but
because the ping originated inside the network at Site 1, it was permitted back
in through the wan1 interface which is configured as a stateful firewall.
h. In the Tree View, select only ECV-1.

i. Go to the Subnets tab.
ECV-1 has learned the subnets from ECV-2 and ECV-3, so the pings no longer
hit the Peer Unavailable Action. A route to the destination subnet is now known
to ECV-1, so the packet doesn’t need to be dropped. Instead, it can be put in
the tunnel to ECV-3 (which has the preferred metric to the 10.110.33.0 subnet),
which is exactly what we saw above.
Task 6: Test FTP from Site 1 to Site 2

1. Return to TG-1011, and open the FileZilla (an FTP client) application on the desktop.
2. Connect to TG-3511.
3. Click the down arrow next to Quickconnect and choose 10.110.35.11 (TG-3511’s data
path address)
4. If the connection is successful, you should see something like this:
On the right side, the directory listing at the remote site will appear.
5. In Orchestrator, go to the Flows tab and refresh it. You should see something like this:
The Outbound Tunnel from ECV-1 is to_ECV-2_DefaultOverlay. This is because our

FTP traffic is matching the Business Intent Overlay called DefaultOverlay, and the
appliance is choosing a tunnel to ECV-2 because the subnet metric to reach the
subnet TG-3511 is on will cause it to choose a tunnel to ECV-2.
The Inbound Tunnel on ECV-1 is passthrough, meaning the traffic arrived outside a
tunnel. This is because the Silver Peaks at Site 2 are out of path, and in the return
direction, the traffic from TG-3511 first hits CSR-1 which isn’t redirecting traffic to ECV-
2 or ECV-3 (we’ll set this up in an upcoming lab).
The pictures above illustrate the path travelled outbound from site 1 (red) and the
return path (green).
Note: If you don’t see any flows, go to the FileZilla window, and in the directory listing
for the remote site, right-click and select ‘Refresh’ as below, then go back to the Flows
tab and refresh your view there.
6. If you choose to, copy the test123.txt file to the TG-1011 desktop.
7. Examine the Flows tab for ECV-2. You should see something like this:
This reflects what we discussed above. Traffic is arriving through the tunnel from ECV-
1 as we can see the Inbound Tunnel is to_ECV-1_DefaultOverlay as expected, and
the Outbound Tunnel is “None”, because the return traffic is never being redirected to
ECV-2 by CSR-1.
8. On TG-1011, close your FileZilla connection.
9. Erase Network Memory to prepare for the next labs.
Note: You would probably not want do this in a production network because it
will negatively affect performance until the disk cache is rebuilt. We are using it
as a tool for establishing baseline performance against which the performance of a
populated disk cache can be measured. Doing this here will prepare for the next
baseline transfers.
10. Return to Orchestrator.
11. In the Tree View, select all appliances.
12. Clear the Network Memory.

a. Select AdministrationTOOLS: Erase Network Memory.
b. A list of appliances about to be affected by the command will be listed.
c. Click Erase Network Memory.

d. Click Close when the function is complete and the status indicates the clear
was successful.
LAB 4: Internet Breakout & Passthrough
Tunnels
Overview
We have some traffic destined to a trusted host on the Internet that we don’t want to backhaul
through the data center, since this can add unnecessary 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.
Our trusted host is UBU-1 (in the upper right corner of the diagram). Notice the IP address is
in the RFC 1918 private address space we use for the rest of our lab. It uses an actual
private IP address, although the host, and our data path, is not actually on the Internet and is
only reachable in our lab.
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 on the Internet
1. In Orchestrator, go to the Flows tab
2. On TG-1011, if you don’t have one open already open a cmd window
3. Ping 11.1.1.11 (UBU-1)
4. Look at the flow in Orchestrator.

a. Look at the outbound tunnel in the flow table – it says “Policy Drop”.
b. Look at the Flow Detail.
What’s going on?
5. Look in the Subnet tab for ECV-.
ECV-1 has no route to the destination, but the site is on the Internet and uses a public
IP address. In order to reach it, we would need for the packet to be sent
unencapsulated out of the wan1 interface labeled ‘Internet’ and configured as a
stateful firewall. In fact, any IP address on the Internet we want to get to would need
the same thing.
We’ll configure this in the next few steps.
Task 2: Change ECV-1 wan1 to Stateful+SNAT

Note: In a production network, an Internet facing interface set up as a stateful firewall
would probably have a public IP address on the Internet and connections from the
local lan, which uses private IP addresses, would need to be NAT’d. We’ll perform that
function here by enabling the appliance to perform Source NAT (SNAT) in addition to
the stateful firewall function, since this branch office doesn’t have a local upstream
router or firewall to perform this function.
1. In the Tree View in Orchestrator, right-click ECV-1 and select Deployment.

2. Select Stateful+SNAT for wan1.
3. Click Apply.
Task 3: Observe automatically created Passthrough tunnels
Passthrough tunnels are used to send traffic directly to the WAN outside of tunnels. This can
be useful for sending traffic directly to the Internet in order to access sites like Office360 or
SalesForce.com, for example. Starting in 8.1.10, Orchestrator creates these tunnels
automatically, although no traffic is sent through them unless you specify it.
1. In the Tree View, select only ECV-1.

2. Go to the Tunnels tab (Configuration[Tunnels] Tunnels).
3. Click Passthrough to view only Passthrough tunnels.
4. Notice there are passthrough tunnels for each wan interface on the appliance. We’ll
make use of these in a few minutes when we change the BIO to allow local Internet
breakout.
Note: The term ‘passthrough’ tunnels is somewhat misleading. They are not tunnels at
all since the traffic is forwarded unencapsulated, but internally, the appliances make
use of the tunnel forwarding mechanisms to direct traffic to the correct interface.
Task 4: Configure an Internet Breakout Business Intent Overlay

This overlay is used to break out Internet traffic to the interface labeled ‘Internet’ on the
appliances.
1. In Orchestrator, go to the Business Intent Overlays tab (Configuration[Overlay
Prerequisites] Business Intent Overlays).
2. Select the DefaultOverlay.
3. Scroll down (if needed) to Internet Traffic section.
4. Configure Internet breakout.
a. Drag the Break Out Locally icon from the Policies column and position it over
Backhaul to Overlay in the Preferred Policy Order column.
b. Select Internet in the Primary column of the Break Out Locally Using These
Interfaces section.
c. Notice the message at the bottom of the screen. We’ll do this in the next step.
d. Ensure all subnets used internally are configured
i. Click the pencil icon next to Internet Traffic
ii. Examine the pop up dialog showing Internal Subnets.
The list of Internal Subnets should include all the subnets in your network
that will be reachable via overlays. This is a global list that affects all
overlays, not just this one.
Traffic with a destination subnet address in the list will be sent to an

overlay. If you have enabled local breakout, traffic destined to any
subnets NOT in the list, will be broken out instead of being sent to an
overlay.
The default list contains all the RFC 1918 private IP address ranges.
This works fine for our lab, but if you use other address spaces in your
network you want to connect together using overlays, you need to
include them in this list. Upload of a comma separated subnet list is
possible.
iii. Click Close to close the dialog box.

e. Click Save All at the bottom of the page. and confirm the save.
Note: This will cause the appliances to which this overlay is applied to first
check the traffic to see if it is going to one of the internal networks, and if not,
then break it out to the interface labeled ‘Internet’ as passthrough traffic. The
traffic wil be sent through the stateful firewall, and source NAT’d.
It is also possible to reverse the order of the local subnet check by positioning
‘Breakout Locally’ before ‘Backhaul Via Overlay’ in the policy list. You can also
create your own policies and tunnels. See the inline documentation.
Task 5: Check connectivity to UBU-1

1. ping from TG-1011UBU-1 (11.1.1.11)
If you are quick enough, you might see this… (otherwise see below…)
If you see the above, wait one minute; then retry the ping.
You should get get this:
2. Look at the Flows tab to see if it indicates why the ping is failing.
The traffic is still being policy dropped. What is going on?
3. Notice there are some warning alerts for the appliances. Mouse over ECV-1 to see the
warning.
Note: A cosmetic bug in this beta version of code causes some of these alerts to
never clear when the error condition goes away. You need to check the IPSLA page to
see the current status. We’ll do that in the next step. The alarm can be cleared
manually on the Alarms page, by selecting one or more of the alarms and clicking the
clear button. If the error re-occurs, a new alarm will be displayed.
4. Check the IP SLA configuration in Orchestrator.
b. Go to the IP SLA tab (Configuration[Policies] IP SLA).
c. There are three IP SLAs and they are all marked ‘Down’.
Some important notes on these IP SLAs:

i. The Business Intent Overlays configure IP SLAs by default when you
configure traffic to be broken out locally as we did above. It will create a
policy for each appliance and wan interface to which the overlay is
applied.
ii. These default IP SLAs will check that the Internet is reachable so that
traffic will not be broken out if it is not. They try to reach a pingable site
(sp-ipsla.silverpeak.cloud) that should always be reachable, and may
resolve to different addresses depending on where you are on the planet
earth. Our lab data path network does not have connectivity to the
Internet, so the destination is marked down. If your ping worked at first,
then stopped, it was because the SLA took a little while to mark the
destination down.
iii. If the destination is marked down, the traffic will be dropped and the
destination will show as ‘Policy Drop’ in the Flows tab.
iv. You can modify these rules to something that suits your network. We’ll
do that in the next step.
Task 6: Configure the IP SLA destinations for the DefaultOverlay
1. Reconfigure the overlay to monitor the next hops on wan0
Look at your topology diagram. In our lab network we’ll reconfigure the overlays to
check the next hop in the Internet (10.110.12.1 for ECV-1 and 10.110.42.1 for ECV-3).
If that next hop is reachable, the appliance will break out traffic to the Internet as
passthrough.
Note: we won’t be monitoring Internet access for ECV-2 because of changes we’ll
make in the HA section of the labs.
a. Go to the Business Intent Overlays tab in Orchestrator and make sure the
DefaultOverlay is selected.
b. Click the pencil icon next to Break Out Locally Using These Interfaces.
c. Add ECV-1’s wan1 next hop to the IP SLA, and an upstream address for site 2.
i. In the IP SLA rule destination(s) list,

1. Add a comma separator as shown
2. Add the address of ECV-1 wan1’s next hop (10.110.12.1).
3. Add a comma separator as shown
4. Also add the address that ECV-3 will use to monitor Internet
accessability (10.110.42.1) as shown.
ii. Ping Interval: 1
iii. Mark Up after X Pings: 3
iv. Mark Down after X Pings: 5
v. Monitor Sampling Interval: 5
vi. Click Save.
Meanings of the fields:

We put the definitions here, since they don’t seem to be in the help yet.
IP SLA rule destinations – One or more comma separated. Can be IP
or name (if a name, obviously DNS has to be working).
An SLA is created automatically by the overlay for each int. Default is the
host above (sp-ipsla.silverpeak.cloud), which you may not have a hole
punched for. If you want to use this, you’ll need to allow conectivity in
your network or add other destinations like we are doing in this lab.
Ping Interval – Ping all IPs/names in the list at the configured interval.
Mark Up after X Pings – The number of pings (not seconds) any single
site in the list has to respond to to mark a destination up. Only one site
has to reachable to take the up action for the SLA (destinations are
OR’d).
Mark Down after X Pings – The number of pings each and every site in
the list has to fail to reply to mark a destination down. All sites have to be
down to take the down action for the SLA.
Monitor Sampling Interval – (the SLA polling interval) The number of

seconds between polls by higher level processes (e.g. overlays). If the
‘down threshold’ is shorter than ‘Interval’, the destination will be marked
down, but the overlays, for example, wouldn’t find out until this timer
expires and the SLA status is checked.
2. Return to the IP SLA tab.
a. Note the status has changed to Pending 1st Poll. (If you take too long you will
miss this and the status will change to Up as in the next step).
b. After a few seconds, Click the refresh icon .
c. The status should change to Up.
3. In Orchestrator, return to the Flows tab and reset all flows.
4. Retry your ping to 11.1.1.11 on TG-1011. You should see this
If not, you may need to go the Flows tab and reset the flow and retry it.
5. Look at the flow in the Flows tab.
Notice the traffic is now using the passthrough tunnel for the Internet interface.
6. Open an FTP connection to UBU-1
a. Go to the RDP window you have open in TG-1011
b. Double-click the Filezilla icon on the desktop.
c. Connect to UBU-1.
i. Host: 11.1.1.11
ii. Username: student
iii. Password: silverpeak
iv. Click Quickconnect.
d. The connection is successful if you see the file named ‘testfile’ in the directory
listing on UBU-1.
7. Check the flow.
a. Go to the Flows tab in Orchestrator and refresh the display.
b. The inbound and outbound tunnel is Passthrough_Internet_DefaultOverlay, the

default passthrough tunnel created by Orchestrator for DefaultOverlay traffic to
exit D2N (Direct to Net) via the interface labled Internet.
Note the source address of TG-1011 in the flow (10.110.10.11)
c. Click the Flow Detail icon
d. Go to the NAT Info (Passthrough) tab.
Note: Your port numbers may differ from those shown.
Remember we configured Stateful+SNAT for our firewall policy on wan1 of

ECV-1. This shows us that TG-1011’s source address of 10.110.10.11 has
been source NAT’d to 10.110.12.100 (the IP address of the wan1 interface on
ECV-1). The source port has been left unchanged, but might have been
mapped to a different port if that one was unavailable.
Task 7: Close the connection on TG-1011

1. Go to the RDP window you have open on TG-1011.
2. Close the Filezilla FTP session window
Note: If there are any warning alarms for SLA monitors displaying, go to the IP SLA tab in
Orchestrator and if all the SLAs there show ‘Up’, you can manually clear the alarms on
Orchestrator Alarms tab (MonitoringAlarms) by selecting them and clicking clear. This is
due to the cosmetic bug in this beta release we mentioned earlier.
STOP HERE and do not move on until the course material directs you to the
next lab.
Access Labs 5 and 6
Task 1: Obtain a voucher and login
2. Click “Advanced SDWAN Deployments (ASD) Labs 5-6” to select it.
4. Click Check out.
register for the course. Click Next.
Note: A correct email is required for you to receive your voucher.
6. Checkout.
b. Check the acknowledgement checbox. (Silver Peak will be billed. Your cost is
$0.00 as shown).
7. Click Place order.
A Purchase confirmation will be displayed

below) and open it.
13. Click OK.
hot standby pool.
19. To Access the lab, click Click here to connect.
20. Login
panel and login as Administrator using the password Silverpeak1.

keyboard.

desktop icon.
warnings.


i. Click Advanced.
booted.
displayed.
prompt.
7. Close the Setup Log.
Task 4: Log into Orchestrator

5. Login to Orchestrator using admin/admin.
Lab 5: BGP
Overview
In this lab, you will configure the CSR routers and appliances at Site 2 to be eBGP peers.
The appliances will advertise subnets learned through subnet sharing between appliances to
the routers, and become the preferred path to optimize traffic. If the appliances were to go
down, then the routes would no longer be advertised to the CSRs, and they would use their
native L3 routing tables to forward traffic accordingly.
Because we will have equal cost paths through both appliances in our environment, allowing
packets for a single flow to be distributed across tunnels to ECV-2 and ECV-3, we’ll see
some asymmetry in this environment, which we’ll correct.
Objectives
Learn to configure BGP peering. Observe some possible problems you could encounter and
learn how to avoid them. Learn to correct asymmetry with flow redirection.
Task 1: Remove existing static routes from the CSRs and create
loopback addresses
In the steps below, we are removing a preexisting static route from each CSR router. It will no
longer be needed because BGP will advertise needed routes to peers.
Also, we are adding a loopback interface to use as a router id for BGP. Although the routers
will automatically choose a router id tied to an existing interface ip address, if an interface
were to go down for some reason, then a network disruption could occur. Recommended
best practice is to use an interface that can’t go down, like a loopback interface, and statically
configure the router to use that address for a router id. The interface will not be used for any
traffic and the addresses will not be advertised. Its sole use in this case is as a stable router
id. We’ll assign a /32 host address.
1. Log into the vSphere client.

Note: Since you logged in earlier, you may still have the vSphere client open. If so,
skip to step 2.
a. On the Student PC desktop, double-click to open the VMware vSphere Client
application.
b. Login as root/training.
Note: If you see a notice saying this is an evaluation version of VMware that will
expire in xx days, you can close it.
c. Check the checkbox to Install this certificate… and click Ignore. Ignore &
close any other warnings.
d. Click Yes.
e. Click the ‘+’ symbol to expand the list of VMs installed in the esxihost.
2. Remove the static route from CSR-1 and create a loopback.
a. Right-click on CSR-1 and select Open Console.
b. Click in the console window (press enter if needed to make the command
prompt visible).
c. Type: enable
configure terminal
no ip route 10.110.33.0 255.255.255.0 10.110.30.2
interface loopback 0
ip address 1.1.1.1 255.255.255.255
end
write memory
Note: Use <ctrl><alt> to leave the console window.
3. Remove the static route from CSR-2 and create a loopback.
a. Right-click on CSR-2 and select Open Console.
b. Login to CSR-2’s console in VMware as above.
c. Type: enable
configure terminal
no ip route 10.110.35.0 255.255.255.0 10.110.30.1
interface loopback 0
ip address 1.1.1.2 255.255.255.255
end
write memory
Task 2: Configure eBGP on the CSRs

We are configuring eBGP here, meaning we will establish a BGP session between CSR-1
and CSR-2, and they will have different AS numbers.
When a BGP session is between devices using the same AS number, it is considered iBGP
(Interior BGP). Routes learned from one iBGP peer are not advertised to other iBGP peers.
When a BGP session is between two devices in different Autonomous Systems (different AS
numbers), it is considered eBGP (Exterior BGP). Routes learned from an eBGP peer can be
advertised to iBGP or eBGP peers.
1. Configure BGP on CSR-1.
a. In the vSphere client, go to the console window for CSR-1.
b. Type: enable
configure terminal
router bgp 65001
bgp router-id 1.1.1.1
neighbor 10.110.30.2 remote-as 65004
address-family ipv4
network 10.110.35.0 mask 255.255.255.0
end
write memory
Note: BGP will not open a session with another device without a corresponding
‘neighbor…’ config statement. No networks will be advertised to neighbors
without a corresponding ‘network…’ statement.
2. Configure iBGP on CSR-2.

a. Go to the console window for CSR-2.
b. Type: enable
configure terminal
router bgp 65004
bgp router-id 1.1.1.2
address-family ipv4
network 10.110.33.0 mask 255.255.255.0
network 10.110.42.0 mask 255.255.255.0
network 11.1.1.0 mask 255.255.255.0
end
write memory
Note: The last two network statements allow: CSR-2 to advertise a path to the
IPSLA ping destination.
3. Add a static route on CSR-2 to 11.1.1.0. Since we don’t actually have an upstream
router to advertise the 11.x.x.x subnet, we need to be able to simulate this by
advertising it statically.
configure terminal
ip route 11.1.1.0 255.255.255.0 10.110.42.1
end
write memory
4. On CSR-2, check BGP operation.
a. Type: show bgp  This displays the BGP routing table.
b. You should see the local subnets 10.110.33.0 and 10.110.42.0, and the remote
subnet 10.110.35.0 it learned from its peer CSR-1, with a next hop address of
10.110.30.1. Note the Path is from AS 65001. You will also see the remote
network we are advertising from CSR-2, 11.1.1.0.
If you don’t see this, recheck your work.

5. On CSR-1, check BGP operation.
a. Type: show bgp
You should see the local subnet 10.110.35.0, and the remote subnet
10.110.33.0 it learned from its peer CSR-1, with a next hop address of
10.110.30.2. You should also see the 11.1.1.0 and 10.110.42.0 subnets that
CSR-1 learned from CSR-2. Note the Path for the eBGP routes from 65004.
If you don’t see this, recheck your work.
Task 3: Configure eBGP on ECV-2 and ECV-3

1. In Orchestrator, go to the BGP tab (Configuration[Routing] BGP).
2. Configure ECV-2.
a. Click the edit icon for ECV-2.
b. Configure BGP parameters.
i. Enable BGP: ✓
ii. AS Router: 65002
iii. Router ID: 192.168.1.5 this is the mgmt0 ip address
iv. Redistribute learned BGP routes to Silver Peak peers: ✓
Note: Redistribute learned BGP routes to Silver Peak peers is
checked so the appliances at site 2 (ECV-2 and ECV-3) can advertise
those same subnets to ECV-1.
v. Click Add to add CSR-1 as a peer.
1. Peer IP: 10.110.30.1

2. Peer ASN: 65001
3. Enable Imports: ✓
4. Peer Type: Branch
5. Admin Status: UP
6. Local Preference: 100 (default)
7. MED: 0 (default)
8. AS Prepend Count: 0 (default)
9. Keep Alive Timer: 30 (default)
10. Hold Timer: 90 (default)
11. Route Export Policies: ✓ All (defaults)
12. Click Add.
vi. Click Add again to add CSR-2 as a peer.
1. Peer IP: 10.110.30.2

2. Peer ASN: 65004
5. Admin Status: UP
7. MED: 0 (default)
11. Route Export Policies: ✓ All (defaults)
12. Click Add.
Notes:
Enable Imports is checked so the appliances can automatically learn
about the 10.110.33.0 and 10.110.35.0 subnets (or any other non-
attached subnets) from the routers.
Route Export Policies: Boxes are automatically selected based on

the peer type.
You can override these if you need to, but if you choose to do so, you
need to think about the implications of each of these checkboxes
when you do your network design and configuration. Sometimes (as
we’ll see in a minute) enabling or disabling a feature can have
unintended consequences.
vii. Click Apply.
3. Configure ECV-3.
a. Click the edit icon for ECV-3.
b. Configure BGP parameters.
i. Enable BGP: ✓
ii. AS Router: 65003
iii. Router ID: 192.168.1.6 this is the mgmt0 ip address
iv. Redistribute learned BGP routes to Silver Peak peers: ✓
v. Click Add to add CSR-1 as a peer.
1. Peer IP: 10.110.30.1

2. Peer ASN: 65001
5. Admin Status: UP
7. MED: 0 (default)
11. Route Export Policies: ✓ all
12. Click Add.
vi. Click Add again to add CSR-2 as a peer.
1. Peer IP: 10.110.30.2

2. Peer ASN: 65004
5. Admin Status: UP
7. MED: 0 (default)
11. Route Export Policies: ✓ all (defaults)
12. Click Add.
4. Click Apply.
5. Check the status on the Silver Peaks.

a. Click the refresh icon on the BGP tab in Orchestrator to see current status.
It may take a minute or two to become active.
The BGP State for both appliances should be Active.

b. Click the Peers button.
The state for both peers for ECV-2 and ECV-3 is Active. This indicates the
appliances are trying to start a session with the CSRs, but we have not yet
configured the CSRs to have the appliances as neighbors yet, so the session
can’t reach the Established state.
Task 4: Configure ECV-2 and ECV-3 not to advertise local LAN routes
Since the appliances are going to be using BGP to learn about the local subnets (10.110.33.0
and 10.110.35.0) from the CSRs, we don’t need the static subnets we configured earlier on
ECV-2 and ECV-3. In this task, we’ll remove them.
1. In the Tree View, select all three appliances.

2. Remove the Static Routes from ECV-2.
a. Go to the Subnets tab.
b. Click the edit icon next to one of the ECV-2 entries.
c. Click x to remove each of the subnets we added earlier.
d. Click Apply.
3. Remove the Static Routes from ECV-3
a. Go to the Subnets tab.
b. Click the edit icon next to one of the ECV-3 entries,
c. Click x to remove each of the subnets we added earlier.
d. Click Apply.
Task 5: Add the ECVs as neighbors on the CSRs
1. Configure CSR-1 to add both ECVs as eBGP neighbors.
a. Go to the vSphere console window for CSR-1.
b. Type: enable
configure terminal
router bgp 65001
end
write memory
2. Configure CSR-2 to add both ECVs as eBGP neighbors.
b. Type: enable
configure terminal
router bgp 65004
end
write memory
Task 6: Check BGP operation on the appliances

1. In Orchestrator, go to the BGP tab (Configuration[Routing] BGP).
2. Make sure Peers is selected
3. Refresh from appliance if needed to get current status.
4. The Peer State for each peer should be “Established”. If not, check your
configuration for errors.
Note: It may take a couple of minutes for the peers to move their session to the
“Established” state.
Task 7: Check BGP operation on the routers
1. Show BGP routing on CSR-1.
Type: show bgp
You should see something like the screen shot below. The networks learned by ECV-2
and ECV-3 through subnet sharing from ECV-1, have been advertised to CSR-1 by
the Silver Peaks and now appear in the list of known BGP routes.
Note: Use the up arrow to retrieve the previous command (show bgp) and press
Enter to repeat the command as needed until you see the routes displayed in the
next two steps. All the routes will not fit on one page so use the spacebar to page.
2. Display the L3 routing table used by CSR-1.
Type: show ip route
You should see something like the below.
Note: Use your spacebar to display the whole routing table.
3. Return to Orchestrator and observe periodic alarms.

You will begin to see Alarms appearing and the clearing themselves in the
Orchestrator. These can take 2 or 3 minutes to appear. When you see a(n) alarm(s)
next to a device in Tree View, you can mouse over the number next to the device
which indicates how many alarms the device is reporting. You’ll see a summary similar
to what’s below.
It can be difficult to catch the alarms because they can appear and clear quickly.
Luckily there is a way to view them more reliably.
Note: If you don’t see the alarms within 2 minutes, they may be clearing too quickly
for you to see. Skip directly to the next step.
5. Go to the Alarms tab (Montoring[SUMMARY] Alarms).
6. The Alarms Tab will appear.
If there are currently no alarms showing, click the All button. You should see a number
of alarms from all the appliances indicating the tunnel peers are unreachable.
7. Return to the CSR-1 console.
8. Show the routes on CSR-1.
Type: show ip route  Do this multiple times
Hint: You can use the up arrow on the CSRs to retrieve past cli commands, and then
just press enter to execute the command that is displayed.
Notice the path to the subnets at site 1 (10.110.10.0, 10.110.11.0 and 10.110.12.0).
We have routes to Site 1, why are the tunnels down?
What’s going on???
Remember 10.110.11.100 and 10.110.12.100 are the data path addresses for the
WAN-side of ECV-1. These are the addresses that the tunnels must terminate on.
When the routes to the 10.110.11.0 and 10.110.12.0 subnets are learned by the CSRs
from the local ECVs at site 2, the ECV’s become the best route to those subnets. As a
result, tunnel packets from ECV-2 or ECV-3 that are addressed to ECV-1, are sent by
the ECVs to the CSRs, and the CSRs then send them back to the ECVs. This is a
routing loop.
When the tunnels go down, the subnets are no longer shared from ECV-1 to the
devices at Site 2 (and vice-versa). The CSRs then use their default routes and forward
the tunnel packets across the Internet and MPLS networks properly. Then the tunnels
come back up and the cycle starts over.
Task 8: Configure ECV-1 to only advertise the LAN-side subnets
1. Go to the Subnets tab (Configuration [Networking] Subnets).
2. Click the edit icon next to a route on ECV-1.
3. Change the configuration.
a. Uncheck Automatically include local WAN subnets.

This will prevent ECV-1 from advertising all the locally connected WAN side
subnets and get rid of the routing loop.
b. Click Apply.
4. Now observe the devices in Orchestrator. The alarms should go away and the tunnels
should stay up.
5. Look at the routing tables in CSR-1 and CSR-2.
a. Type: show bgp
You should see something like this for show bgp:
Note only the LAN-side subnet (10.110.10.0) from ECV-1 shows up in the BGP
routing table now. The WAN-side subnets (10.110.11.0 and 10.110.12.0) do not
appear.
b. Type: show ip route
You should see something like this:
Again, only the LAN-side subnet from ECV-1 shows up in the routing table now.
Note: A default route on each CSR is used to point it to the wan emulators for
unknown routes.
Task 9: Verify correct route propagation on the appliances
2. In Orchestrator, go to the Subnets tab (ConfigurationNetworking: Subnets).
3. Click the ‘Learned’ button to filter on subnets learned via subnet sharing.
(Click the refresh icon if needed to display the routes)
Note: The order of the subnets may be different in your display. It might be helpful to
click the column heading for Subnet/Mask. This will cause the table to be sorted in the
order shown here.
a. ECV-1 should be learning the following:
i. The 10.110.33.0 and 10.110.35.0 networks from ECV-2 and ECV-3.
ii. The Route Types will be BGP-Branch, indicating they were originally
leaned by ECV-2 and ECV-3 from a BGP peer with a type of Branch.
They show up in this list because ECV-1 learned them via subnet
sharing, not BGP.
iii. You’ll notice it has also learned a route to the 11.1.1.0 subnet. ECV-1 will
not use this route unless Internet breakout goes down (breakout is ahead
of backhaul in the business intent overlay policy order we configured).
b. ECV-2 and ECV-3 are learning the 10.110.10.0 subnet from ECV-1
4. Click the BGP Learned button to filter on routes that were learned via BGP
a. ECV-2 and ECV-3 should both be learning the 10.110.33.0 and 10.110.35.0
networks via BGP from the CSRs with a route type of BGP Branch. The
‘Learned from Peer’ column specifies the BGP-Branch peer address they were
learned from. You can mouse over truncated entries to see the whole address.
b. Notice that no routes appear for ECV-1 now. That is because it learned all of its
routes from ECV-2 and ECV-3 via subnet sharing, not BGP.
Task 10: Verify the configuration

2. Go to the Flows tab (MonitoringActive & Recent Flows).

3. Open an RDP window to TG-1011.
a. On the desktop of the Student PC, double-click the RDP icon.
c. Ignore and close any warning messages, reboot reason messages etc.
4. Start CIFS sessions from TG-1011 to TG-3511 and TG-3311 to verify that connections
are working and traffic is being optimized and accelerated. In your RDP window to TG-
1011, open a CIFS connection to TG-3511
a. On the desktop, double-click the icon to open a CIFs connection to TG-3511.
b. A CIFS fileshare window should open to TG-3511.
5. Start a second CIFS session from TG-1011 to TG-3311. In your RDP window to TG-
1011, open a CIFS connection to TG-3311.
a. On the desktop, double-click the TG-3311 Files icon to open a CIFs folder.
b. A CIFS fileshare window should open to TG-3311.
c. In Orchestrator, go to the Flows tab.
d. Observe the flows. If everything is working correctly, you should see something
like the image below, which shows CIFS and Netbios flows:
Note: If you don’t see all the expected flows, some of them might have timed
out. Go back to the open CIFs windows on TG-1011 and right-click in the right
side of the window, then select Refresh
6. Examine the Asymmetry.

a. Look at the Flows tab. Some of the flows show clear signs of Asymmetry.
i. Notice that some of the flows using the same pair of port numbers
between the same pair of IP addresses,
1. show an outbound tunnel but no inbound, or
2. show an inbound tunnel but no outbound
3. If you mouse over the blue bars on the right in the last column,
you see byte counts incrementing in only one direction (a clear
indication of asymmetry)
4. The summary counter above the Flows tab shows you there are
asymmetric flows
b. Click the Flow Details button for the flows that look asymmetric. You will
probably see something like one or more of the following:
These indicate that the flow cannot be boosted (TCP accelerated) because of
asymmetry. We’ll fix this problem in the next Lab.
7. Close both CIFS windows that you have open on TG-1011

8. Reset all flows in the Flows tab and make sure there are no CIFS flows.
LAB 6: Configure Flow Redirection on
ECV-2 and ECV-3
Overview
In this lab you will configure flow redirection between ECV-2 and ECV-3 to eliminate
asymmetry and make sure that Boost functions like TCP acceleration can do their job.
Objective
Configure a flow redirection cluster. Learn how to configure and monitor flow redirection.
Task 1: Configure Flow Redirection

Refer to your topology diagram. The mgmt1 interfaces of ECV-2 and ECV-3 are connected to
each other via port group 11. We will configure flow redirection on their mgmt1 interfaces in
the following steps.
1. Check the status of the interfaces in Orchestrator.

a. In the Tree View, select ECV2 and ECV-3.
b. Go to the Interfaces tab (Configuration[Networking] Interfaces).
c. The mgmt1 interfaces for both appliances should show that they are up with the
correct IP addresses.
d. Look at your topology diagram and notice these interfaces connect to each other
over vSwitch 11 (we preconfigured the vSwitch and interfaces for you in this lab).
2. Configure Flow redirection on ECV-2.
a. Go to the browser tab you have open directly to the appliance ECV-2 and login if
necessary (admin / Training#1).
b. In ECV-2, go to the Flow Redirection tab (Configuration[POLICIES] Flow
Redirection).
c. Enable Flow redirection and add a peer.
i. Enable: ✓
ii. Click Add Peer.
iii. Peer IP: 10.110.34.2
iv. Click Apply.
v. Click Save Changes
3. Configure Flow Redirection on ECV-3.
a. Go to the browser tab you have open directly to the appliance ECV-3 and login if
necessary (admin / Training#1).
b. In ECV-3, go to the Flow Redirection tab (Configuration[POLICIES] Flow
Redirection).
c. Enable Flow Redirection and add a peer.
i. Enable: ✓
ii. Click Add Peer.
iii. Peer IP: 10.110.34.1
iv. Click Apply.
v. Click Save Changes
4. Wait a few seconds, then refresh the page.
Note: You may need to refresh more than once.
The status should change to OK, indicating that the flow redirection peers (ECV-2 and
ECV-3) are talking to each other successfully and will be able to redirect traffic.
Task 2: Check for Flow Symmetry and Boost

1. Open an RDP window to TG-1011 if you don’t have one open.
a. On the desktop of the Student PC, click the RDP icon.
2. Start CIFS sessions from TG-1011 to TG-3511 and TG-3311 to verify that connections
are working and traffic is being optimized and accelerated.
a. In your RDP window to TG-1011, open a CIFS connection to TG-3511
b. On the desktop, double-click the icon to open a CIFs connection to TG-3511
c. A CIFS fileshare window should open to TG-3511.
3. Start a second CIFS session from TG-1011 to TG-3311.

a. In your RDP window to TG-1011, open a CIFS connection to TG-3311.
b. On the desktop, double-click the icon to open a CIFs connection to TG-3311.
c. A CIFS fileshare window should open to TG-3311.
4. In Orchestrator, go to the Flows tab.
5. Observe the flows. If everything is working correctly, you should see something like the
image below, which shows CIFS and Netbios flows:
Verify traffic is symmetric and accelerated.
a. In Orchestrator, go to the Flows tab. You should see something like this for the
pair of CIFS connections:
The flows are now symmetric. (You can ignore unidirectional netbios flows)
b. Click the Flow Detail icon for each of the flows. In the optimization section, verify
that the transfer is being accelerated.
c. Look for Redirected Flows From value. While looking at the flow details, look at
the Routes section of the flows, and you will probably see something like the
indication below although the address may be different depending on which
appliance is doing the redirecting:
6. Monitor redirection.
a. Go to the ECV-2 tab in your browser.
b. In ECV-2, go to the Flow Redirection tab (Monitoring[STATUS] Flow
Redirection).
c. If any flows are redirected, either inbound or outbound counts will increment.
Note: Your flow/packet counts may be different from shown.

d. If you open an appliance manager session to ECV-3, and go to Flow Redirection
tab (Monitoring[STATUS] Flow Redirection), you should see something
similar.
7. Go to the RDP session to TG-1011 and close all open CIFS sessions on TG-1011
8. Go to the flows table in Orchestrator and reset all flows.
STOP HERE and do not move on until directed by your course material.
Access Labs 7 and 8
Task 1: Obtain a voucher and login
2. Select “Advanced SDWAN Deployments (ASD) Labs 7-8” by clicking on it.
4. Click Check out.
register for the course. Then click Next.
Note: A correct email address is required for you to receive your voucher
6. Checkout.
b. Check the acknowledgement checkbox. (Silver Peak will be billed. Your cost is
$0.00 as shown).
c. Click Place order.
7. A Purchase confirmation will be displayed

below) and open it.
13. Click OKto activate the code.
You should now be in the Silver Peak Self-Paced Training portal.
hot standby pool.
19. To access the lab, click Click here to connect.
20. Login.
panel and login as Administrator using the password Silverpeak1.

keyboard.

desktop icon.
warnings.


i. Click Advanced.
booted.
displayed.
prompt.
7. Close the Setup Log

Task 4: Log into Orchestrator

2. Login as admin/admin.
Lab 7: Configure PBR & VRRP
Overview
In this lab, you will create a VRRP group. Each ECV will belong to the group, but only one will
become the master at any given time. Each CSR router will use PBR to forward traffic to the
VIP.
Objective
Learn to configure and monitor VRRP on the Silver Peak appliances. Learn to configure PBR
on a router with an SLA to track the condition of the next hop (in this case a VIP of a VRRP
group), and verify the operation using CLI commands.
Task 1: Configure VRRP on the appliances

In this task, we will enable VRRP on each ECV. We will configure each appliance to
participate in the VRRP group, which has a VIP in a subnet attached to each CSR. In a later
step, we’ll configure each CSR to forward traffic to the VRRP group using its associated vIP.
1. Log in to Orchestrator (admin / admin) in the open browser window.

2. Make sure all appliances are selected in tree view.
3. In Orchestrator, go to the VRRP tab (Configuration[Routing] VRRP).
4. Configure VRRP on on ECV-2.

a. Click the edit icon next to ECV-2.
b. Click Add VRRP.

i. Group ID: 1
ii. Interface: lan0
iii. Virtual IP: 10.110.30.254
iv. Priority: 129
v. Preemption: ✓
c. Click Apply.
5. Configure VRRP on on ECV-3.
a. Click the edit icon next to ECV-3.
b. Click Add VRRP.

i. Group ID: 1
ii. Interface: lan0
iii. Virtual IP: 10.110.30.254
iv. Priority: 128
v. Preemption: ✓
c. Click Apply.
6. Check the status of VRRP groups on the ECVs.
a. Select Refresh from appliance to get current status from the devices.
b. Check the State column.
i. ECV-2 should be the master for group 1 using a VIP of 10.110.30.254.
ii. ECV-3 should be backup for group 1
Task 2: Configure PBR on the CSRs

1. Configure PBR on router CSR-1 interface gi 4 to direct traffic to a VRRP address
shared by redundant SPs which use flow redirection.
a. In the VMware vSphere Client, go to CSR-1 and open a Console window.
i. Right click on CSR-1 in the tree view list of VMs in the Vsphere client.
ii. Select Open Console.

iii. Click in the console window that opens and press ‘Enter’.
b. Enter enable mode on the router, then enter configuration mode.
Type:
enable
configure terminal
c. Create an access list to match traffic to be redirected
Type:
access-list 101 permit ip any 10.110.10.0 0.0.0.255
Note: These rules will match all traffic from any source address to the
destination subnet connected to ECV-1 lan0 at Site 1, or UBU-1 on the Internet
d. Create an sla and tracker to monitor the VIP of the vrrp group.
Type:
ip sla 1
icmp-echo 10.110.30.254
threshold 250
timeout 1000
frequency 2
ip sla schedule 1 life forever start-time now
track 1 ip sla 1 reachability
e. Configure a route map and redirection on the router.
Type:
route-map silverpeak permit 10Create route map named ‘silverpeak’
match ip address 101  Match ACL 101 (for redirection)
set ip next-hop verify-availability 10.110.30.254 1 track 1
 Redirect traffic to the VRRP VIP
and track reachability
exit
f. Apply redirection to the gi 4 interface on the router.
Type:
interface gigabitEthernet 4  Select the interface
ip route-cache policy  Enable fast switched PBR
ip policy route-map silverpeak  Apply route-map
g. Save your config.
Type:
end
write memory
h. Verify your configuration.
Type:
show running-config  Page through the config
i. Check the status VIP reachability.
Type:
show ip sla summary
A Return Code of “OK” indicates the VIP is up.
Note: To regain cursor control outside the console, use <ctrl>+<alt>
2. Configure PBR on router CSR-2 interface gi 4 to direct traffic to a VRRP address
shared by redundant SPs which use flow redirection.
a. In the VMware vSphere Client, open a console window to CSR-2
i. Right click on CSR-2 in the tree view list of VMs in the Vsphere client
ii. Select Open Console.
iii. Click in the console window that opens and press Enter.
b. Enter enable mode on the router, then enter configuration mode.
Type:
enable
configure terminal
c. Create an access list to match traffic to be redirected
Type:
Note: This rule will match all traffic from any source address to the destination
subnet connected to ECV-1 lan0 at Site 1.
d. Create an sla and tracker to monitor the VIP of the vrrp group.
Type:
ip sla 1
icmp-echo 10.110.30.254
threshold 250
timeout 1000
frequency 2
ip sla schedule 1 life forever start-time now
track 1 ip sla 1 reachability
e. Configure a route map and redirection on the router.
Type:
route-map silverpeak permit 10Create route map named ‘silverpeak’
match ip address 101  Match ACL 101 (for redirection)
set ip next-hop verify-availability 10.110.30.254 1 track 1
 Redirect traffic to the VRRP VIP
and track reachability
exit
f. Apply redirection to the gi 4 interface on the router.
Type:
interface gigabitEthernet 4  Select the interface
ip route-cache policy  Enable fast switched PBR
ip policy route-map silverpeak  Apply route-map
g. Save your config.
Type:
end
write memory
h. Verify your configuration.
Type: show running-config  Page through the config
i. Check the status of the VIP.
Type: show track brief
A State of Up indicates the VIP is reachable.

j. Now let’s get some more detail with a different command:
Type: show track 1
Task 3: Test Redirection

1. In Orchestrator, view all flows for all appliances.
a. Return to Orchestrator.
b. In the Tree View, select all three appliances.
c. Go to the Flows tab.
2. Open an RDP window to TG-3511
a. On the desktop of the Student PC, launch RDP.
3. In the RDP window you have open on TG-3511, open an FTP session to UBU-1.
a. Double-click the FileZilla icon on the desktop.
b. Log into UBU-1.
i. Host: 11.1.1.11
ii. Username: student
iii. Password: silverpeak
iv. Click Quickconnect.
c. You should see the file called TestFile in the lower right pane in FileZilla when
you connect to UBU-1
4. In Orchestrator, go to the Flows tab, and click the refresh button . You should see a
flow like the one below.
Note that the flow is unidirectional (0 inbound bytes).
5. This is because the return path through CSR-2 is not redirected to an appliance and
goes directly to TG-3511.
The solid line shows the outbound path, which is redirected via PBR to the VIP (ECV-2
is master), and then passthrough to the Internet (via Internet breakout in the overlay).
The return path (dashed) goes directly from CSR-2 back to TG-3511 bypassing the
appliances (which is ok).
6. In the RDP window, close Filezilla.
7. Open a CIFS session to TG-1011.
a. In Orchestrator, filter on CIFS traffic.
i. In the application field, type cifs_smb.
Note: The exact spelling is important.
ii. Click the Refresh icon.

b. On the desktop of TG-3511, double-click the TG-1011 Files icon to open a
CIFS connection to TG-1011.
c. Observe the flows in the Flows tab. Refresh if needed.
The flow may take a path only through ECV-2 and ECV-1, or you may see
something like the above where the return flow through ECV-1 routed the traffic
to ECV-3. In this case, the flow detail of one of the flow table entries will show
that the flow was redirected.
8. Verify that packets are being redirected on both of the CSRs
b. Type: show route-map silverpeak
Note: Your packet and byte counts may be different than those shown.
c. Repeat the command show route-map silverpeak on CSR-2.
Note: If your flow did not go through CSR-2, there may not be any redirected
packets.
d. Notice the field labeled Policy routing matches. You should see redirected
packets and an associated byte count (it might be slightly different than the one
shown. This shows that packets are being redirected by the router according to
matches associated with the route-map named silverpeak, and forwarded to the
next-hop 10.110.31.254 (the VIP of VRRP group 1).
9. Delete cifs_smb from the Application field to clear the filter.
10. In the RDP window, close your CIFS window.
LAB 8: Configure HA on ECV-2 and ECV-3
Overview
In this lab we’ll configure HA between ECV-2 and ECV-3. We’ll delete the wan1 interfaces on
each of the appliances and make use of the lan1 interfaces connecting the devices to
establish an HA connection. We will still be in ILRM on both appliances with BGP redirection.
Objective
Learn the configuration steps required to set up and verify an HA connection.
Task 1: Disable BGP neighbors between CSRs

In this lab, we want to simulate connecting to two different ISP routers that are not peered, so
we’ll remove the neighbor relationship between them.
1. Remove CSR-2 as CSR-1’s Neighbor.

a. Open console to CSR-1 if needed (you may still have a window open).
b. Remove the neighbor statement for CSR-2.
enable
configure terminal
router bgp 65001
no neighbor 10.110.30.2 remote-as 65004
end
write memory
2. Remove CSR-1 as CSR-2’s Neighbor.
a. Open console to CSR-2.
b. Remove the neighbor statement for CSR-1.
enable
configure terminal
router bgp 65004
no neighbor 10.110.30.1 remote-as 65001
end
write memory
Task 2: Disable Flow Redirection
Flow redirection is not compatible with HA, so we need to disable it.
1. Disable Flow Redirection on ECV-2.

a. Go to the browser tab open for ECV-2
b. Login as admin / Training#1.
c. Open the Flow Redirection page (Configuration[Policies] Flow
Redirection).
d. Click ‘x’ to remove the peer.
e. Uncheck Enable.
f. Click Apply.
g. Click Save Changes.
2. As above, disable Flow Redirection on ECV-3.
a. Go to the browser tab for ECV-3.
b. Login as admin / Training#1.
c. Open the Flow Redirection page.
d. Click ‘x’ to remove the peer.
e. Uncheck Enable.
f. Click Apply.
g. Click Save Changes.
Task 3: Temporarily remove default overlay

1. Return to Orchestrator.
3. Go to the Apply Overlays tab (Configuration[Overlay prerequisites] Apply
Overlays).
4. Check the remove checkbox next to DefaultOverlay and click Apply.
5. Click Apply.
Task 4: Enable All VLANS for the vSwitch Portgroup used by the HA
Interfaces
Consult the topology diagram above for reference if needed.
The lan1 interfaces on ECV-2 and ECV-3 are connected to Portgroup 12 on vSwitch6. Since
HA makes use of multiple VLANs, we need to enable this feature on the Portgroup.
1. Open the vSphere client.
2. In the Tree View, select esxihost.
3. Go to the Configuration tab.
4. Click Networking.
5. Configure vSwitch 6 Portgroup 12.
a. Scroll down to vSwitch6 in the Networking view.
b. Click Properties…
c. Select Portgroup 12, then click Edit.
d. Select a VLAN ID of All (4095) from the dropdown menu.

e. Click OK.
f. Click Close.
Task 5: Enable HA on ECV-2 and ECV-3

In this step, we’ll edit the deployments for ECV-2 and ECV-3 to remove unneeded interfaces
and enable HA mode.
Note: In this release, enabling HA mode can only be done from the Orchestrator Deployment
tab, not on the appliances, and not by right-clicking on the appliances in Tree View.
1. In Orchestrator, go to the Deployment tab (Configuration[Networking]

Deployment)
Note: Don’t select the similar sounding Deployment Profiles under Overlays
2. Click the edit icon next to ECV-2
3. Configure as follows:
a. Check the box for EdgeConnect HA
b. Close the help screen that automatically opens (feel free to read it if you’d like).
c. Select ECV-3 as an HA Peer.
d. Click the x next to each of the wan1 interfaces to remove the interfaces.
We are deleting the Internet labeled interface from ECV-2, and the MPLS labled
interface from ECV-3. With HA enabled, the devices will make use of each
other’s connections as we’ll see, so they won’t lose functionality.
e. The topology will change as shown below.
f. Change the HA Link interfaces on both appliances to lan1.

g. Change the Firewall setting for wan0 on ECV-3 (lower) to Stateful+SNAT.
4. Click Apply to apply the new deployment.
Task 6: Observe device status

1. In Orchestrator, go to the Deployment tab.
2. Click Details and refresh if needed. It may take a minute or two for the VLANs to get
built. Use the refresh button if needed…
a. Notice that on ECV-2 and ECV-3, VLAN interfaces have been auto configured
for lan1 (lan1.100 and lan1.101).
b. IP addresses have automatically been configured in 169.254.1.0/30 subnets.
c. Both ECV-2 and ECV-3 show interfaces with MPLS and Internet labels, one
making use of the wan0 connection, and the other making use of the lan1 HA
connection.
3. On the Orchestrator, open the Interfaces tab (Configuration[Networking]
Interfaces).
a. Click Dynamic.
b. The VLAN interfaces dynamically created by overlay manager show up here.
They also show up as dynamic interfaces on the appliances on the interfaces
config page.
Note: The interface at the top of the list shown above for ECV-2 is the VRRP
virtual interface. Remember ECV-2 is currently master.
Task 7: Reapply the overlay

We’ll add the DefaultOverlay back on to all appliances.
1. Go to the Apply Overlays tab (Configuration[Overlay Prerequisites] Apply

Overlays).
3. Add the DefaultOverlay to all 3 appliances.
a. In the Add column, check the box next to DefaultOverlay.
b. Click Apply.
c. Click Apply again to verify the changes.
Task 8: Observe tunnel formation
Reapplying the overlay will cause tunnels to be rebuilt.
1. In Orchestrator, go to the Dashboard tab.

2. The tunnels should be rebuilt in the topology.
3. Examine the tunnels.

b. Go to the Tunnels tab (Configuration[Tunnels] Tunnels).
c. Click Overlay to observe the overlay tunnels.
There are tunnels between ECV-1 and ECV-2/ECV-3

d. Click Underlay.
Notice there MPLS-MPLS and Internet-Internet tunnels built to ECV-1 at site 1

from ECV-2 and ECV-3, even though ECV-3 has no MPLS connection of its
own and ECV-2 has no Internet connection of its own. They are making use of
the HA connection to build the tunnel.
e. Click Passthrough to view additional passthrough tunnels.
There are 3 passthrough tunnels each on ECV-2 and ECV-3. One local each for
MPLS and one for Internet. They also have one each that makes use of the HA
connection called Passthrough_MPLS_ForHA (ECV-2) and
Passthrough_Internet_ForHA (ECV-3).
Task 9: Test data flow over the HA Link

We’ll start an FTP session between TG-3511 and UBU-1. Remember, ECV-2 has no direct
connection to the Internet over a wan interface now. It should use the HA connection through
ECV-3 to reach the Internet and UBU-1.

2. Set up a filter to view only FTP traffic
a. Go to the Flows tab.
b. Click in the Application field, enter ftp and press enter.
3. Open an RDP window to TG-3511.

Note: You probably already have one open. If so, go to it, otherwise login as shown.
a. On the desktop of the Student PC, launch RDP.
4. In the RDP window to TG-3511, open an FTP session to UBU-1.
a. Double-click the FileZilla icon on the desktop.
b. Use the list under Quickconnect to log into UBU-1 (11.1.1.11).
i. Click the down arrow next to Quickconnect.

ii. Select student@11.1.1.11.
c. You should see the file called TestFile in the lower right pane in FileZilla when
you connect to UBU-1.
5. Observe the flow in Orchestrator.

a. Go to the Flows tab and click the refresh button.
The flow has been redirected via PBR/VRRP on CSR-1 to ECV-2 (ECV-2
should be VRRP master).
b. Click the Flow Detail button for the flow through ECV-2
i. The flow shows the inbound and outbound tunnels as

Passthrough_Internet_DefaultOverlay, but what path is it actually taking?
ii. Go to the NAT Info (Passthrough) tab.
You can see that 10.110.35.11 (which initiated the FTP session) is being
SNAT’d to 169.254.1.1 and the source port of 49217 is being preserved.
You might remember (see above) that the 169.254.1.x subnet was used
to establish the HA connection between ECV-2 and ECV-3.
iii. Close the Flow Detail.
c. Now let’s look at the flow through ECV-3.
i. Notice there’s a matching incoming flow on ECV-3 with a source address

(IP1) of 169.254.1.1 with a destination address (IP2) of 11.1.1.11.
ii. Open the Flow Detail for this flow.
iii. It’s making use of the Passthrough_Internet_ForHA connection, but on

the outbound side it’s actually being sent out of wan0. How do we know
this?
iv. Go to the NAT Info (Passthrough) tab.
v. Note the source address has been translated again to 10.110.41.101,

and once again the source port has been preserved (Note: if the original
source port had been in use, another would have been chosen).
10.110.41.101 is the IP address of the wan0 interface on ECV-3.
6. Let’s look at the complete path the flow is taking.
Note: Solid line is the session initiation, reply path is the dotted line. Numbers 1-12 in
the diagram match the steps below.
1. TG-3511 (source IP 10.110.35.11 source port 49217) initiates an FTP session with
UBU-1 (destination IP 11.1.1.11 destination port 21). It sends the packet to its default
next hop router, CSR-1.
2. CSR-1 matches the incoming packet to ACL 101, and used by a route-map called
silverpeak, causing the packet to be redirected to 10.110.30.254 (the VIP of VRRP
group 1) using PBR. The source and destination addresses are unchanged.
3. The VRRP master is ECV-2 (it has the higher priority and preemption is enabled), so it
processes the packet.
a. The incoming traffic is matched to the BIO called DefaultOverlay, which has
local breakout enabled for external addresses (like 11.1.1.11), and it determines
the packet should be sent passthrough on an interface labled ‘Internet’
b. The interface that is labeled ‘Internet’ is actually wan0 on ECV-3 so the HA link
will need to be used by ECV-2 to direct the packet there.
c. All traffic going across the HA link will be SNAT’d to the local link address.
ECV-2’s side of the lan1 HA connection uses 169.254.1.1, so the source
address of 10.110.35.11 is translated to 169.254.1.1 with a source port of
49217 and the same destination IP of 11.1.1.11.
Note: We’ll start using the convention ‘IP address:port #’ so if you see an
address followed by number after a colon, that’s the port associated with that
address. E.g. 1.1.1.1:25 would be IP 1.1.1.1 with port 25.
4. The traffic arrives at ECV-3 over the HA interface.
a. ECV-3 determines the packet is to be sent passthrough over the interface
labeled Internet
b. The interface labeled as Internet (wan0) is configured as Stateful+SNAT,
meaning any passthrough traffic will be SNAT’d using the wan0 IP address.
c. The packet has its source address translated again, this time to 10.110.41.101
with the same source port of 49217 (it was available), and the destination
address and port of 11.1.1.11:21 are unchanged.
d. The packet is sent to ECV-3’s next hop on wan0, CSR-2.
5. CSR-2 consults it’s routing table and forwards the packet to the next hop on the
Internet (10.110.42.1), which forwards the packet to its destination.
6. UBU-1 recieves the packet initiating the FTP session.
7. UBU-1 replies with a source address of 11.1.1.11:21 and destination of
10.110.41.101:49217.
8. The packet is received by CSR-2 and forwarded to the destination address of
10.110.41.101 (wan0 on ECV-3)
9. The packet arrives at ECV-3 where a lookup in the flow table matches the incoming
flow.
a. ECV-3 translates the destination IP address of 10.110.41.101:49217 back to
169.254.1.1:49217. The source address of the reply – 11.1.1.11:21 is
unchanged.
b. The packet is placed in the HA tunnel and sent to ECV-2.
10. ECV-2 receives the packet does a lookup and matches the flow to one in its flow table
a. It translates the destination address from 169.254.1.1:49217 to
10.110.35.11:49217. This is of course the local IP address of TG-3511. The
source of 11.1.1.11:21 is unchanged.
b. ECV-2 forwards the packet to the next hop router, CSR-1.
11. CSR-1 forwards the packet to its destination.
12. TG-3511 receives the reply to its request for an FTP session.
…and the session communication proceeds as above…
Congratulations. You have finished the labs in this course.
Appendix 1: What to do if the setup script
doesn’t complete successfully
A script failure in our lab environment is often caused by an Orchestrator VM that didn’t
launch properly, had network problems when it tried to connect to the Cloud Portal, or
became corrupted for some reason. You’ll need to revert it to its initial state, then reboot it to
get it back into the correct state before the setup script can be re-run.
If you don’t do this, and attempt to rerun the setup script, it may appear to work, but the
Orchestrator will look like a duplicate to the cloud portal (for reasons beyond the scope of this
discussion) and will not be able to manage appliances.
1. Go to the list of VMs in the vSphere esxi client
2. Select the Orchestrator.

3. Click the Stop button (square red button) to shut down Orchestrator.
4. Click Yes.
5. Once the Orchestrator is stopped (the icon next to Orchestrator will change) make
sure the Orchestrator VM is still selected in tree view as shown below.
6. Click on the Snapshot Manager icon.
7. The base snapshot will be selected by default, click the Go to button to reload the
base snapshot.
8. Click Yes on the pop up confirmation window
9. Click Close.
10. Make sure the Orchestrator VM is selected, then click the Power On button
11. Go get a cup of coffee/tea. Wait at least 5 minutes for Orchestrator to fully reboot.
There are some internal housekeeping tasks that have to run, and these take a little
while to complete even after the login prompt has displayed in the console window.
12. Go back to the lab step just before the one that sent you here, and rerun the setup
script as described there.
Lab Topology Diagrams:
ASD Lab Guide v1.0 page 161 of 164

With VRRP/PBR:
With HA & VRRP/PBR
ASD Lab Guide v1.0 page 163 of 164

Login Information
System/Platform User Password Notes
Virtual Lab The access code is provided by

your instructor.
http://silverpeak.instructorled.training (primary)
http://backup.instructorled.training (backup) Access Code:
____________________
http://silver-peak.instructorled.training (alternate)
https://silverpeak.hostedtraining.com (alternate)
Student PC Administrator Silverpeak1
VMware vSphere Client root training
TG-0x Administrator Silverpeak1 The PCs at the sites.
Kwanems K1-MPLS and K2-Internet Root silverpeak
Orchestrator admin admin
ECV-1, ECV-2, ECV-3 admin Training#1 The default ID/PW is

admin/admin
Cisco CSR 100v Routers CSR-1 and CSR2 This password is used after
executing the enable
command.
Windows Live Mail student@training.local training
UBU-1 student silverpeak Use VMware console

ASD Self-Paced 8.1.6 Lab Manual v2.14 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ASD Self-Paced 8.1.6 Lab Manual v2.14 PDF

Uploaded by

Copyright:

Available Formats

Silver Peak

Self-Paced Lab Guide

Date: November 2017

Warranties and Disclaimers

Silver Peak Systems, Inc.

1.877.210.7325 (toll-free in USA)

LAB 1: License Orchestrator and Appliances ................................................................. 7

Lab 2: Observe and Correct Tunnel Formation ............................................................. 24

Lab 3: Overlay Behavior, Stateful Firewall and WAN Hardening ................................... 27

LAB 4: Internet Breakout & Passthrough Tunnels ......................................................... 55

Access Labs 5 and 6 ..................................................................................................... 67

Lab 5: BGP .................................................................................................................... 79

LAB 6: Configure Flow Redirection on ECV-2 and ECV-3........................................... 107

Access Labs 7 and 8 ................................................................................................... 114

Lab 7: Configure PBR & VRRP ................................................................................... 128

LAB 8: Configure HA on ECV-2 and ECV-3 ................................................................ 139

Lab Topology Diagrams: ............................................................................................. 161

Login Information ......................................................................................................... 164

Task: Print your lab guide

Task 1: Familiarization with the lab topology

DHCP on the management network will assign addresses to new devices if

Task 2: Connect to the ReadyTech lab environment

3. Click on Add to cart.

8. Close the window.

13. Click OK to activate the code.

You should now be in the Silver Peak Self-Paced Training portal.

19. To access the lab, click Click here to connect.

21. Other Lab Notes:

6. Match the list of deployed VMs to the list below:

Task 4: Run the setup script to prepare your lab environment

Four tabs will open by default:

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

7. Close the Setup Log.

Task 4: Log into Orchestrator and dismiss notifications

Task 5: Review the current deployment

1. In Orchestrator, go to the Apply Overlays tab (Configuration[Overlay Prerequisites]

2. Observe the applied Overlays.

5. Examine the Overlay.

Task 1: Observe unwanted tunnels between ECV-2 and ECV-3

2. In Orchestrator, go to the Tunnels tab (Configuration[Tunnels] Tunnels).

Task 2: Change the site name on ECV-2 and ECV-3

b. Select Modify Appliance.

2. Change the site name on ECV-3.

Task 3: Observe corrected tunnels

Task 1: Observe the effects of Peer Unavailable Action and WAN

b. In Orchestrator, select Monitoring[Flows] Active & Recent Flows.

b. Log into TG-1011 (192.168.1.10). The password is Silverpeak1.

d. Close the Flow Detail window.

7. This will show you the configured route policies on ECV-1.

c. Change the Peer Unavailable Action to Pass Through.

As we mentioned above, the Peer Unavailable Action might be applied to some

c. Verify only ECV-1 is selected in the Tree View.

See the diagram below…

When we changed the Peer Unavailable Action to Pass Through, instead of

10. Now ping from TG-3311 to TG-1011.

b. Connect to TG-3311’s management interface at 192.168.1.30. Logon as

d. Ping TG-1011’s data path interface (10.110.10.11). Does it work?

This fails. But this is caused by a different issue.

Notice the connection to the wan1 interface labeled Internet was

When you initiated a ping from TG-3311TG-1011, it failed. The packet

e. Ping from ECV-1 wan1 (10.110.12.00)  TG-3311 (10.110.33.11). Make sure

Important Lesson: If you want to troubleshoot connectivity that involves a

Task 3: Observe the operation of traceroute