SADM6 - 5 eLabExercises v02

Table of Contents
eLab Overview................................................................................................................................................................ 2
Group # __................................................................................................................................................................... 2
Pre-Exercise: Using the Riverbed Training eLab............................................................................................................3
Using & Managing Your eLab Pod............................................................................................................................... 5
Exercise 1: In-path Deployment...................................................................................................................................... 8
Exercise 2: Measure Performance (In-Path).................................................................................................................18
Exercise 3: Perform a Tcpdump to Look for Probes......................................................................................................21
Exercise 4: Out-of-Path Deployment............................................................................................................................. 24
Exercise 5: Measure Performance (Out-of-Path)..........................................................................................................27
Exercise 6: NetFlow....................................................................................................................................................... 29
Exercise 7: Configure Logical In-Path Network (Physically Out-of-Path)......................................................................32
Exercise 7A: WCCP Redirection of All Traffic & LAN/WAN Auto-discovery...............................................................41
(Optional) Exercise 7B: WCCP Redirect Lists, WAN-side Fixed-target Rules, & LAN-only Redirection....................46
(Optional) Exercise 7C: WCCP Adding Dynamic (User-configurable) Service Groups, WAN-side Fixed-target Rules,
& LAN-only Redirection................................................................................................................................................. 50
Exercise 8: Upgrade...................................................................................................................................................... 52
Exercise 9: RSP Installation & Configuration................................................................................................................54
Exercise 10: HS-TCP.................................................................................................................................................... 64
Exercise 11: Agentless Prepopulation...........................................................................................................................68
(Optional) Exercise 11a: RCU 2.x.................................................................................................................................. 70
Exercise 12: Quality of Service..................................................................................................................................... 75
Appendix A Topology Diagrams.................................................................................................................................. 85
2008-2011 Riverbed Technology 1

eLab Overview
The Riverbed On-Demand eLab lets you perform advanced lab exercises designed to simulate
real-world customer networks and troubleshooting scenarios. Before proceeding with the lab
exercises, familiarize yourself with the eLab and its components.
The eLab consists of three core components:
1. eLab Gateway. Provides access to all the hardware and software management platforms
used during these exercises.
2. eLab Management Center. The intuitive eLab Management Center lets you activate
network topologies, clear terminal lines, and reboot devices.
3. eLab Pod. Contains all the necessary devices to complete the labs.
Your instructor will guide you in determining how the class will be broken into groups. Please
place your group number on the line below. We will use this number for your pods IP addresses
throughout the labs.
Group # __
Requirements
Before logging into the eLab, you will need:
4. An Internet connection that allows https access over port 443.
5. Web browser, such as Internet Explorer or Firefox.
6. Java Runtime Environment (1.4 or greater).
If you are unsure if you meet these requirements, please ask your lab instructor.
Tips
7. Work with a partner.
8. Read the entire exercise before starting.
9. Experiment with different options.
10. Please listen to any additional instructions from your lab instructor.
11. Replace all instances of X with your group number.
2 2008-2011 Riverbed Technology

Pre-Exercise: Using the Riverbed Training eLab
Login and connect to the eLab
1. Open the following URL in your web browser (the instructor will provide the URL as this
could change depending on which eLab you will be accessing).
Example: https://elabsf1.riverbed.com
A Welcome page displays prompting you for your user name and password.
Figure 1: Riverbed eLab Login Page
2. Type the user name and password provided by the instructor and click Sign In.
3. Accept the security question (if necessary) by clicking on Allow.
Figure 2: Security Question
4. Once you are logged in, a list of devices in your eLab pod displays as well as the variety
of connection methods for them.

Figure 3: eLab Pod Menu
5. Connect to the eLab Management Center by clicking the eLab Management Center link
(at the bottom of the list). The eLab Management

Center lets you select your lab topology, power cycle your pod devices, or clear a stuck
line on a terminal server for a console session. The eLab Gateway tunnel launches and
allows for connectivity to your pod devices. A new window appears and a new icon
displays in the system tray of your desktop.
Figure 4: eLab Management Center Login
6. Log into the eLab Management Center (user name and password are case sensitive):
1. User name = groupX, where X is your group number (for example, group4)
2. Password = password
The eLab Management Center interface displays.

Figure 5: Management Center Lab Topologies
Using & Managing Your eLab Pod

Connectivity to your pod devices varies depending on the device type.
12. To access the client PCs (A or B) or the Shared Server:
1. The Remote Desktop (RDP) application automatically launches when you select
either PCxA or PCxB, or the Shared Server links from the eLab Gateway.
13. To access your group Steelheads:
1. Either console session through the Serial console to Branch Steelhead link, or
2. After the Steelhead management IP addresses have been configured,
1. SSH using the Branch Steelhead link , or

2. HTTP using Web Bookmarks at the top of the screen and selecting the Branch
Steelhead link .
14. To access the WAN simulator:
1. Can only be configured using a console connection and can be accessed using the
Serial console to WAN Simulator link, which automatically launches the terminal
client.
In the eLab Management Center, there are three main tasks:
15. The Lab Selection screen of the eLab Management Center automatically reconfigures
the underlying network to support the topology illustrated by the diagrams appropriate to
the lab scenario.
16. The Power Control page lets you reset the power on several core pod devices and lets
you watch the boot processes on a console session or force reboots.
17. The Terminal Control page lets you clear active or stuck line sessions.

To learn how to use the eLab Management Center, follow these steps.
1. In the eLab Gateway, have one member of your group click the Serial console to WAN
Simulator link. Once the session launches, the management interface for the WAN Simulator
appears. If not, press the Escape key to view the display.
Figure 6: WAN Simulator Menu
2. To highlight the Terminal Control functionality of the eLab Management Center, assume
that your lab partner opened a terminal session to the network simulator and was unable to
close the session properly. If this happens, nothing will appear on the screen in the console
window if the simulator console session is re-launched.
To clear the line and make the console session accessible, in the eLab Management Center,
click the Terminal Control link and then click the Clear Connection link associated with
the WAN Simulator.
Figure 7: Terminal Server Connections

3. Select the Clear Connection link on the eLab Management Center. You will see the
connection disconnected.
4. Go back to the main eLab browser. The eLab pods include two computers for your group to
use as clients and/or servers. You can connect to these group PCs using the PCxA and PCxB
links in the eLab Gateway. Decide with your lab partner which PC you would like to use and
then click the link as shown here.
Figure 8: Terminal Sessions
5. You will be presented with an RDP session showing a standard Microsoft Windows logon.
Until you have configured your lab topology enter administrator for the user name and
password for the password. Select TRAINING in the Log on to drop-down menu and click
OK.
NOTE: After your topology is configured you will enter either userXa or userXb for the
user name and password for the password.
Figure 9: Terminal Session Login
6. Once you have logged into your group PC, the remote PC window fills your screen. You can
use the window control buttons at the top of the screen to minimize it or reduce the window
size so that you can continue to use the eLab Gateway and the eLab Management Center.
END OF PRE-EXERCISE

Exercise 1: In-path Deployment
Task 1: Setup topology
In this exercise, you configure a simple in-path deployment based on the information provided in
the Topology 1 diagram in Appendix A. We recommended that you remove this appendix page
and keep it as a reference as you will refer to it often.
Since the eLab is set up for two students per pod (groupX), remember that one student will be
configuring the branch side and the other will be configuring the data center side.
1. Log into the eLab Management Center (groupX, password) and click the Activate link for
Topology 1.
Figure 10: Lab Topologies
Task 2: Configure your simulated WAN

1. One student in your group needs to configure the WAN simulator with 500 Kbit/s of
bandwidth, 100 ms of latency, configure IP Routing Mode, and set the Management IP
address as shown in the topology diagram.
a. Click the WAN Simulator link to open the WAN simulator management interface.
b. Click the Device Settings tab.

c. Configure the Management interface:
- Enter the Device Name (linktropy-miniX)
- Enter the MGMT Interface IP address (192.168.99.22X)
- Enter the MGMT Interface Subnet mask (255.255.255.0)
- Enter the MGMT Interface Default gateway (192.168.99.1)
d. Click the Apply Changes button.

Figure 11: Device Settings
e. Click the Bridge/Route tab.

f. Configure the interfaces for IP Routing.
- If the WAN simulator is in Bridging Mode, click the switch to IP Routing Mode link
.
- LAN A IP address: 10.1.x.25
- LAN A Interface Netmask: 255.255.255.224
- LAN A Interface Gateway: 10.1.x.25
- LAN B IP address: 10.1.41.x
- LAN B Interface Netmask: 255.255.255.0
- LAN B Interface Gateway: 10.1.41.x
Figure 12: Bridge/Route
g. Click the Apply Changes button.

h. Click the Link Emulation tab.
i. Configure the WAN bandwidth setting.
- Enter 500 in the Bandwidth field and select Kbps from the drop-down menu for both
LAN A > LAN B and LAN B > LAN A.
j. Configure the latency setting.
- Enter 100 in the Delay field for both LAN A > LAN B and LAN B > LAN A (leave
the radio buttons on Constant).

Figure 13: Link Emulation
k. Click the Apply Changes button.

2. Close the browser window to exit the WAN simulator management interface.
Task 3: Configure your branch office and data center Steelheads

1. Select the appropriate links to configure either the branch office Steelhead or the data center
Steelhead. For example, click the Serial console to Branch Steelhead link for the branch
office Steelhead or the Serial console to Server Steelhead link for the data center Steelhead.
We will be configuring both so it does not matter which one you access first.
2. Ensure that you have access to the console of the Steelhead by pressing Enter on your
keyboard. A login screen displays.
Figure 14: Telnet Session
3. Enter the login name admin and password password. The configuration wizard starts and
the auto-configure prompt appears.
- NOTE: If you do not see the configuration wizard, you can reset the system back to
factory defaults by typing the CLI command reset factory reload in
configuration mode (en, then con t).
- NOTE: To launch the configuration wizard, enter configuration mode and type
configuration jumpstart or con j for short.

4. In the Serial Console session window you should see:
Riverbed Steelhead configuration wizard.
Do you want to auto-configure using a CMC?
5. Enter n and press Enter. The configuration wizard prompt appears.

Do you want to use the wizard for initial configuration?
6. Enter y and press Enter. Answer the questions in the wizard to configure your Steelhead
according to the Topology 1 diagram, replacing your group number for the X as in the
example below. Your interaction should be similar to the following:
Step 1: Hostname? [amnesiac] shXbranch (or shXdc for DC)
Step 2: Use DHCP on primary interface? [yes] no
Step 3: Primary IP address? 10.1.x.30 (10.1.41.2x for DC)
Step 4: Netmask? [0.0.0.0] 255.255.255.224 (255.255.255.0 in the DC)
Step 5: Default gateway? 10.1.x.25 (10.1.41.x for DC)
Step 6: Primary DNS server?
Step 7: Domain name?
Step 8: Admin password?
Step 9: SMTP server? []
Step 10: Notification email address?
Step 11: Set the primary interface speed? [auto]
Step 12: Set the primary interface duplex? [auto]
Step 13: Would you like to activate the in-path configuration? [no] yes
Step 14: In-Path IP address? 10.1.x.20 (or 10.1.41.1x for DC)
Step 15: In-Path Netmask? [0.0.0.0] 255.255.255.224 (255.255.255.0 in the DC)
Step 16: In-Path Default gateway? 10.1.x.25 (10.1.41.x for DC)
Step 17: Set the in-path:LAN interface speed? [auto]
Step 18: Set the in-path:LAN interface duplex? [auto]
Step 19: Set the in-path:WAN interface speed? [auto]
Step 20: Set the in-path:WAN interface duplex? [auto]
7. When prompted, press Enter to save your configuration.

8. Repeat the same steps to configure your data center Steelhead according to the Topology 1
diagram.
9. Configure the AUX interfaces of the Steelheads. Recall that the AUX interfaces can be used
for out-of-band management and are used in the eLab as such.
a. To configure the AUX interface, log in to the Steelhead through its Console interface. If
you are not already logged into your Steelheads, login to configure the AUX interface.
Login: admin
Password: password
b. Enter enable mode, so youll be able to use privileged commands.

shxbranch > en
shxbranch #
c. Enter configuration mode and configure the AUX interface with the desired IP address as
shown in your topology diagram (192.168.99.2##). Please read the topology diagram
closely.
shxbranch # con t
shxbranch (config)# interface aux ip address 192.168.99.2## /24
d. Save the configuration and restart the optimization service.

shxbranch (config)# wr mem

shxbranch (config)# restart
10. Repeat the steps to configure the data center Steelhead using the appropriate IP address
shown in the topology diagram.
11. Verify access to the Management Console of each Steelhead using either the Branch
Steelhead or Server Steelhead links in the Web Bookmarks section at the top of the page.
This connects you to the Steelheads using the AUX interfaces that you configured. You can
log into each device using the admin user name and password for the password.
Task 4: Configure the date and time

1. Return to the Serial Console session of each Steelhead.
2. Now we need to configure the date and time on your system. Enter into configuration
mode if you are not already:
shxdc > en
shxdc # con t
3. NTP is enabled. In most cases, you will want to use NTP but since this lab is closed off to
the Internet, and there is no local NTP server, we will need to turn off NTP.
shxdc (config)# ntp disable
4. Verify:
shxdc (config)# show ntp (notice that it is disabled)
5. Now configure the clock to your local time zone so that you can view the current time on
your RDP sessions. You MUST configure your system to this time for future lab
functionality.
shxdc (config)# clock timezone America North United_States Pacific
shxdc (config)# clock set yyyy/mm/dd hh:mm:ss
6. Verify the clock setting:

shxdc (config)# show clock
Task 5: Check software version and licenses

1. Use the show version command to verify the RiOS versions on your Steelheads.
1. What versions are running?
1. Branch Office:_____________
2. Data Center:_______________
2. Use the show license command to verify that you have the correct licenses on your
Steelheads.
1. Do you have a license for the RSP (Riverbed Services Platform Multi Instance)? If
not, please contact the instructor.
Task 6: Verify connectivity

1. Verify connectivity by pinging from Steelhead to Steelhead.
2. Verify connectivity by pinging from the client to server and vice versa. You should be
able to ping from PC to PC.
3. You may exit the Serial Console session of both Steelheads.

Task 7: Verify networking settings and use Help
1. In the Management Console of the branch office Steelhead, navigate to Configure >
Networking > Host Settings.
2. Verify your hostname and date and time settings. These are the settings you configured
initially using the wizard in the CLI.
3. Select the Base Interfaces sub-tab (just below the menu bar).
4. Verify your Primary and Auxiliary interface settings. Again, these are the settings you
configured in the wizard and CLI.
5. If you have any questions regarding any of the settings on a particular page, click the
button next to the navigation page listing. A Help page for the settings on that page will
display.
Figure 15: Online Help
6. Close the Help page.
Task 8: Configure system settings

1. Navigate to Configure > System Settings > Announcements.
2. In the Login Message field, change the default message to whatever you like.
1. Example: Pod 1 Branch
3. In the MOTD (Message of the Day) box, enter a message that you want to display when
someone logs into the Steelhead.
1. Example: Welcome to Riverbed Training!

Figure 16: Announcements Configuration
4. Click the Apply button.

5. Verify your changes
1. Logout of the Management Console.
2. View the login screen.
3. Login back into your system and notice the new Home page message.
Task 9: Set up a student role-based account (RBA)

1. Navigate to Configure > Security > User Permissions.
2. Click the Add a New User tab.
3. Complete the configuration of your new student account:
1. Account Name: studentX.
2. Verify that the Enable Account and Use a Password checkboxes are checked.
3. Enter a password in the Password and Password Confirm fields (minimum of six
characters). For the purpose of these labs we recommend using password as the
password.
4. Allow read/write privileges for all settings by clicking on the Select All column
header for the Read/Write column.
5. Click the Add button.

Figure 17: User Permissions
4. Click the icon on the menu bar. Notice that your active configuration date
changes and the Save icon on the menu bar is no longer highlighted.
5. Log out of the Management Console and then log back in as your new student user.
6. Verify your account in the right-hand side of the header.
Figure 18: Student Login Home Page
7. Click on the studentX link in the upper right hand corner and verify the permission
settings.
Task 10: Configure web settings

1. Navigate to Configure > Security > Web Settings.
2. Change the Web Inactivity Timeout (minutes) field to 0. This will keep you logged in to
the Management Console during your session.
Figure 19: Web Settings

4. Save your changes.
Task 11: Check connections

1. In the Management Console of the data center Steelhead, navigate to the Reports >
Networking > Current Connections page.
2. You will not have any connections listed since we are using the eLab. However, it is best
practice to check this report for client optimizations. Note particularly the Connection
Summary table at the top and that, by default, only the optimized connections are listed.
You may change the type of connections listed using the Connections of Type drop-
down menu.

Figure 20: Current Connections Report
Task 12: Verify network connectivity with the Health Check report
1. Navigate to the Reports > Diagnostics > Health Check page.
2. Select the Gateway Test and Cable Swap Test by clicking in the checkbox and then click
the Run Selected button. Observe the results in the Status column. Since we are using an
eLab the Cable Swap test may have an undetermined status.
3. Click the VIEW TEST OUTPUT box for the Cable Swap Test and view the results.
Figure 21: Health Check Report
4. Feel free to run any additional tests that you wish.
Task 13: Backup the configuration on all Steelheads

1. Access the Management Console of your branch Steelhead and navigate to Configure >
Configurations.
2. Save a copy of this completed in-path configuration into a file called backup-branch on
your branch Steelhead.
Figure 22: Save Configuration

3. Change the active configuration back to initial.
Figure 23: Initial Configuration
4. Do the same for the server-side and call it backup-server. Remember to change the active
configuration back to initial.
5. Optionally, click on your backup configuration to view the configuration. Do you have
permission? Since you are still logged in as the student user and not admin you will not have
the required permissions to view the configuration. Log out and relog back in as admin to
view the configuration.
Figure 24: Backup Configuration
END OF EXERCISE 1
If you have finished early, feel free to practice familiarizing yourself with the Management
Console. However, please do not make any additional changes to the configuration.

Exercise 2: Measure Performance (In-Path)
In this exercise, you will compare the performance of operations over the WAN with and without
the benefit of Steelhead optimization. You also learn how operations can be performed in either
the Management Console or CLI interface of the Steelhead.
1. Disable Steelhead optimization for baseline runs.
a. From Management Console of the branch office Steelhead:
- Navigate to Configure > Maintenance > Services.
- Click the Stop button.
Figure 25: Disable Service
b. From the administrative CLI of the data center Steelhead (Serial console to Server
Steelhead) enter the following command in enable mode:
shxdc # no service enable
Terminating optimization service.......
2. A Windows share called share is available on the Shared Server workstation. Map a
network drive on the PCx workstation to the share on the Shared Server workstation.
a. Open a terminal services session from either PCxA or PCxB
- Login: userXa or userXb
- Password: password
- Domain: TRAINING
b. Right-click on My Computer.
c. Select Map Network Drive.
d. In the Folder field, enter the IP address and folder name as in the following example.
- \\10.1.41.70\share

Figure 26: Shared Server
3. On the PCx workstation, time how long it takes to drag-and-drop a file from the mapped
network drive to the desktop.
NOTE: You may find various types of files in the dataset folder on the shared server. For
example, there are case files in the ppt folder.
1. Unoptimized transfer time: ________
4. Disconnect the mapped drive on PCx once you have completed your baseline test by clicking
Tools Disconnect Network Drive, select the drive to disconnect, and click OK.
5. Enable Steelhead optimization.
a. From Management Console of the branch office Steelhead:
- Click the Start button.
b. From the administrative CLI of the data center Steelhead enter the following command:
shxdc # service enable
Relaunching optimization service.
6. Wait 20 seconds, and then follow these steps to confirm that the Steelhead software has fully
started.
a. From Management Console of the branch office Steelhead, navigate to Home.
- You should see a status of to the right of the menus at the top of the screen.
b. From administrative CLI of the data center Steelhead enter the following command:
shxdc # show info
2. You should see Status: Healthy.
7. Re-establish your connection to the network share (now optimized) by mapping the drive as
described in step 2.
8. Confirm that the Steelheads are optimizing the CIFS connection.
a. From the Management Console of the branch office Steelhead, navigate to the Reports >
Networking > Current Connections page.

Figure 27: CIFS Connection from PC
3. You should see a connection from Source 10.1.x.10 or 10.1.x.11 to Dest

10.1.41.70.
4. The label under the App column should say CIFS.
5. Yellow-colored icons listed under Notes should indicate SDR and Compression
are enabled for the connection.
2. If for some reason you see a pre_existing connection (grayed out in italics), the old
CIFS connection may not have fully closed before you attempted to access the
network drive again through the Steelheads. Unmap the drive and keep checking the
Current Connections page until no connections are listed, then remap the drive and
check again.
3. Another way to eliminate pre_existing connections is by enabling kickoff mode. In
the Management Console, navigate to Configure > Optimization > General Service
Settings and check the box for Reset Existing Client Connections on Start Up,
click the Apply button at the bottom of the screen, click on the menu bar, and
then restart the Steelhead service. This will ensure that any existing TCP connections
are reset and optimized whenever the Steelhead service restarts. This configuration
may not be advised in a production environment, but may be ideal for your lab
exercises.
4. Alternatively, from administrative CLI of the data center Steelhead enter the
following command:
shxdc # show connections
1. You should see a connection from Source 10.1.x.10 or 10.1.x.11 to Dest
10.1.41.70.
2. The label under the T column should say O (for Optimized).
3. The label under the App column should say CIFS.
2. On the PCx workstation, time how long it takes to drag-and-drop a file from the mapped
network drive to the desktop. This is the first time the Steelheads are optimizing this
traffic, so it should be somewhat faster than the unoptimized run.
1. Cold transfer time: ________
3. On the PCx workstation, delete the local copy of the file you just copied and time how
long it takes to drag-and-drop the file again from the mapped network drive to the
desktop. This is the second time the Steelheads are optimizing this traffic, so it should
complete very quickly.
1. Warm transfer time: ________
4. Make some modifications to your local copy of the file, change the filename, and copy it
back to the network share.

1. Warm transfer time: ________
5. Disconnect the mapped network drive from the PCx workstation.
END OF EXERCISE 2

Exercise 3: Perform a Tcpdump to Look for Probes
In this exercise, you will use the tcpdump functionality of the Steelhead to verify that the
Steelhead probes your connection. You will repeat steps in Exercise 2 to start a connection.
1. Connect to your Steelhead via the RDP connection or HTTP GUI link.
2. Turn on packet tracing with the TCP Dump feature of the branch office Steelhead:
1. Navigate to Reports > Diagnostics > TCP Dumps.
2. Click on the Add a New TCP Dump box.
3. Alternatively, name your capture in the Capture Name field.
4. Select the lan0_0 and wan0_0 interfaces.
Figure 28: Add a New TCP Dump
Figure 29: TCP Dump Added

3. Initiate a TCP connection by connecting to the remote Steelhead. For example, if you are
on the branch side, connect to the data center Steelhead. If you are the data center side,
connect to the branch office Steelhead.
4. Verify your connection is optimized in the Current Connections list.
5. Turn off packet tracing (if necessary):
1. Navigate to Reports > Diagnostics > TCP Dumps.
2. Verify that the tcpdumps have completed.
1. If not, in the TCP Dumps Running section, click on the checkbox that refers to
your currently running trace.
2. Click on Stop Selected Captures to stop the trace.
Figure 30: TCP Dump Results
6. Download these traces to your laptop by clicking on the filename.

7. Open the files with either Wireshark or another .cap-file compatible viewer.
8. Demonstrate the following:
1. Open both traces corresponding to lan0_0 and wan0_0 in two separate instances of
Wireshark.
2. On the lan0_0 trace, filter out only the TCP conversation corresponding to your
Steelhead web traffic TCP connection corresponding to Step 3 of Exercise 2.
3. On the wan0_0 trace, filter out on TCP Options Field by looking for 0x4c to display
all communications between Steelheads (filter on tcp.options contains 4c). This will
enable you to view 0x4c easily. If you want to view every communication, filter out
based on IP (filter: ip contains 10.1.xx.xx).
Figure 31: Wireshark WAN TCP Options Filter

4. Compare the TCP SYN packets and identify the Riverbed specific bytes in the header.
9. What you captured was a packet trace for Correct Addressing (CA). Go back and repeat
steps 2 7 for Port Transparency (PT) and Full Transparency (FT).
1. NOTE: You will have to create Auto-discover rules in order to take packet traces
for PT and FT.
Optional
If you have enough time, do the above again but via the CLI.
In the event the GUI is not available, it is best practice to know how to collect traces via the CLI.
END OF EXERCISE 3

Exercise 4: Out-of-Path Deployment
In this exercise you re-deploy your pod using Lab Topology 2 as shown in Appendix A. For easy
reference remove the appendix during the lab configuration process. Note: Per the Topology 2
diagram, your Steelhead will be out-of-path.
The only way to get your packets to the data center Steelhead is with a fixed-target rule;
otherwise all connections on the branch Steelhead will pass through.
After activating your pods Topology 2 link you will notice your data center Steelheads in-path
interface is no longer functional. The switch your system is connected to is made up of VLANs,
and in Topology 2 the VLAN for your in-path interface has been disabled.
Your instructor should have discussed the out-of-path methodology with you.
1. Log into the eLab Management Center (groupX, password).
2. Click the Lab Selection link if necessary, and then click the Activate link next to Topology 2
as shown below.
Figure 32: Lab Topology 2
3. With out-of-path connectivity, you should NOT have to re-configure the network simulator.
Verify your Topology 2 design. If your WAN simulator configuration is NOT identical to
Topology 2, configure it.
4. You can verify the above configuration by attempting to ping your in-path interface IP
address (10.1.41.1x). Then ping your Primary IP address (10.1.41.2x). You will notice the in-
path IP address (10.1.41.1x) no longer pings while the Primary IP is still pingable.
5. Verify that simplified routing is turned off on both Steelheads.
a. Navigate to Configure > Networking > Simplified Routing.
b. Confirm or change the Collect Mappings From field is set to None.

Figure 33: Simplified Routing
c. Click the Apply button.

6. On the data center Steelhead, set your deployment method to out-of-path.
a. Navigate to Configure > Optimization > General Service Settings and uncheck the
Enable In-path Support box and select the Enable Out-of-Path Support box.
Figure 34: General Service Settings
b. Click the Apply button.

c. Save your configuration and restart the optimization service when prompted.
The last step to having a functional out-of-path deployment is to add a fixed-target rule to your
branch office Steelhead. The order of the rules is very important.
7. For the benefit of doing a side-by-side comparison of optimized versus unoptimized traffic,
add a rule so any traffic destined to the shared servers secondary IP address (10.1.41.71)
should pass through the Steelhead.
a. On the branch office Steelhead, navigate to Configure > Optimization > In-Path Rules.
b. Click on Add a New In-Path Rule.
c. Add a Pass Through rule to the end of the list for traffic from all source addresses
(0.0.0.0/0) destined to the unoptimized host address for the server (10.1.41.71/32).
Figure 35: In-Path Rules

d. Click the Add button.
- Note that rules are applied in the order that they appear in the list. Since you will
ensure all Pass Through rules appear first, pass through traffic is excluded before the
all-encompassing Fixed-Target rule that you will add next has any effect.
- Determine how you would have added the same rule using the administrative CLI
(Hint: Start by entering configuration mode and use the in-path command. You can
use the question mark (?) on the command line to work your way through the
options).
e. Add a Fixed-Target rule to the end of the list for all traffic and redirect it to the server-
side Steelhead. Remember that because we are configuring a default out-of-path
deployment we will use the default destination TCP port 7810.
Figure 36: Configure Fixed-Target Rule
f. Click the Add button.

8. Save your configuration.
END OF EXERCISE 4

Exercise 5: Measure Performance (Out-of-Path)
In this exercise, you compare the performance of operations over the WAN with and without the
benefit of Steelhead optimization. Youll access a central, shared server used by all groups in the
class. The shared server includes a file server, web server, and FTP server.
1. Clear the Steelhead data stores.
a. From the Management Console of the branch office Steelhead:
- Click the checkbox for Clean the Data Store.
- Click the button to Restart the service.
Figure 37: Restart Services
b. From the administrative CLI of the data center Steelhead enter the following command:
shxdc # restart clean
Terminating optimization service.....
Relaunching optimization service.
2. Measure performance of file operations.

a. Map a network drive on each workstation PC to a share on the shared server via the
optimized network path.
- Map to UNC pathname \\10.1.41.70\share.
- User Name: userXa or userXb
- Password: password

Figure 38: Shared Server
b. Map a network drive on each workstation PC to a share on the shared server via the
unoptimized network path.
- Map to UNC pathname \\10.1.41.71\unshare.
c. In the Management Console and CLI, confirm that you see Optimized connections to
10.1.41.70 and Passthrough connections to 10.1.41.71. Make sure to change the
Connections of Type field to All.
Figure 39: Current Connections
- Note that you will not see passthrough connections on your data center Steelhead.
Why do you think this is?
d. Compare several file operations on the client PCs.
e. Confirm that a drag-and-drop performed by one client warms up the Steelheads,
making operations with the same files faster for the other client.
f. On the group workstation, time how long it takes to complete repeated drag-and-drop file
transfers between each network drive and the desktop.
3. Measure performance of web operations.

a. On each group workstation, clear your web browser cache. For example, in Internet
Explorer, click Tools Internet Options General and click the Delete Files button.
b. From one client PC, access files on the web server through the unoptimized network
path: http://10.1.41.71.
c. From the other client PC, access files on the web server through the optimized network
path: http://10.1.41.70.
d. Use the Management Console and CLI to confirm you see both Optimized and
Passthrough connections.
e. Compare the performance via the unoptimized network path with performance via the
optimized network path. Clear your browser cache after each operation to ensure that
files are always being pulled across the WAN.
4. In the Management Console, navigate to Reports and browse through the Optimization
reports.
END OF EXERCISE 5

Exercise 6: NetFlow
In this lab exercise, you will explore the deployment of the Steelheads NetFlow capabilities.
There are a myriad of available NetFlow Collectors and Analysis tools available both
commercially and freely. For the purpose of this lab, we will use an open source NetFlow
Collector and Analyzer called nTop. While not as fully featured as some of the commercially
available tools, this tool suits the purpose of this lab and demonstrates the configuration of
NetFlow as it pertains to Steelheads.
Prior to beginning this lab, you must be deployed in an out-of-path topology.
1. From each client RDP session, ensure that you can connect to the nTop NetFlow Collector by
pointing a web browser in PCxA or PCxB to port 3000 on the shared server
(http://10.1.41.70:3000).
Figure 40: NetFlow Collector
2. Move the cursor over the All Protocols menu in the nTop management interface and choose
Traffic. This window shows a list of hosts as well as the amount of data sent and amount of
each traffic type. It also shows if NetFlow packets are sent from the Steelhead to the
collector.
3. From the data center Steelhead, navigate to Configure > Networking > Flow Export.
4. Enable NetFlow export by clicking the Enable Flow Export checkbox and then clicking the
Apply button.

Figure 41: NetFlow Configuration
As the data center Steelhead runs in server-side out-of-path, the only interface with relevant
traffic to capture on that side is its Primary interface. As such, this interface will be both the
export interface, as well as the capture interface.
5. The NetFlow Collector has been configured to listen on the shared server IP address on port
2055. Add a new Flow Collector entry set to capture all traffic on the data center Steelheads
Primary interface and export it to the Primary interface to the server on port 2055 as shown
here.
Figure 42: Add a NetFlow Collector

7. Click the Save button.

8. Pass traffic through the in-path interface of your data center Steelhead so that its NetFlow
data can be sent to the collector. This can be done by mapping a drive from one (or both) of
the group PCs to the shared server to the folder called share and transfer some files, or even
by simply pinging the shared server from the client PC.
9. Return to the nTop management interface and refresh the All Protocols Traffic link. You
should see your group PC IP addresses as well as the amount of traffic sent. If you do not see
your group PC IP addresses in the list, ensure that you have properly configured the port and
collector IP address.
Additionally, as NetFlow data is sent at specific intervals dependent on the flow type
(reference the active and inactive flow timeout settings on the NetFlow Exporter), it may be
necessary to wait a few minutes for the data to appear.
Figure 43: NetFlow Data
10. Once you see your data flows, explore some of the other NetFlow information available
through nTop.
END OF EXERCISE 6

Exercise 7: Configure Logical In-Path Network (Physically
Out-of-Path)
In this exercise you re-deploy your pod using Lab Topology 3 as shown in Appendix A. For easy
reference remove the Appendix during the lab configuration process. Note: From the diagram,
your Steelhead will be logically in-path, physically out-of-path. As we will not be using Fixed-
Target rules to redirect, the only way to get your packets to the Steelhead is to configure WCCP
or PBR on the router; otherwise all connections will be routed normally to the server. There are
no other changes to your Network Diagram.
Your instructor should have discussed the logical in-path, physically out-of-path deployment
methodology with you.
1. Log into the eLab Management Center (groupX, password).
2. Click the Lab Selection link if necessary, and then click the Activate link next to
Topology 3.
Figure 44: Lab Topologies
3. With logical in-path connectivity, re-configure the WAN simulator to bridge mode. You may
want to refer to the tasks you accomplished in the previous lab, but this time use the settings
from the Topology 3 network diagram.
NOTE: Once you configure your WAN simulator in bridge mode you will only be able to ping
the routers 10.1.x.85 interface on the data center side until the Steelhead and PCxB are
reconfigured. You can access your server Steelhead via its serial console connection.

Figure 45: Logical In-Path Network Diagram
As mentioned in the Lab Overview by your instructor, you will be working with a partner. One
partner will be the Client (PCxA) and the other will become the Server (PCxB). The logical
connectivity and IP addressing scheme used in all the WCCP labs in this manual are shown in the
above diagram. It is important to note however, that this diagram does not represent the physical
connectivity or even all the hardware used in the labs. When considering the flow of packets
throughout the network, the above diagram should serve as a reference point for all devices
involved in the layer 3 forwarding process.
For connectivity to the router, each group is assigned a set of sub-interfaces on the router. The
sub-interfaces are logical interfaces, and are able to forward packets as shown in the diagram
shown above through the use of VLANs (virtual LANs) and trunking (the ability to carry
multiple VLANs on a single link, this is also known as tagging).
While performing your configuration on the shared router, it is important to only modify the sub-
interfaces belonging to your group. The proctor of the lab has performed the basic configuration
of the lab switch and lab router (including IP addressing) allowing you to focus on the core
topics covered in the lab.
A Compound Lab Diagram is provided on the next page to more thoroughly detail the packet
flow.

Figure 46: Compound Lab Diagram

Pre-lab Configuration
Note: Replace all Xs in the IP addresses and VLAN information in the Lab Diagram with your
group number.
Task 1: Interface configuration
1. Reconfigure PCxB so that it becomes part of its own separate network connected on the
server-side.
a. RDP into PCxB as the Administrator. Password is password.
Figure 47: PC Login
b. Navigate to the Start Settings Network Connections (also available through the
Control Panel), and right-click to disable the Primary Lan interface.
c. Once the Primary Lan interface has been disabled, enable the Secondary Lan interface.
Enable Disable
Figure 48: Network Connections
2. Verify your success by typing the ipconfig command from a command prompt, you should
see something similar to the following:

Figure 49: ipconfig on PC1B in WCCP Exercise
3. Note all cabling and wiring have already been done for you in this virtual setting. By clicking
on the topology setup, all appropriate VLANs have been provisioned.
a. Recall that the Router is shared by all lab groups.
b. Both the Lab Router and Lab Switch have been pre-configured to allow for basic IP
connectivity and routing across the pod, and for telnet access from your eLab Main Page.
4. You should have already configured the WAN simulator to bridged mode. If you havent
done this already, please do so now.
Task 2: Steelhead configuration

1. Due to the many configuration changes accomplished, it is recommended that the Steelheads
are reverted to a basic in-path configuration.
a. If you have copied a base in-path configuration (as in Exercise 1), load it now, rename it
to branch-wccp/server-wccp and restart the optimization service. Then, change the IP
addressing to match the network diagram and proceed to Task 5 (Simplified Routing).
b. If there is no saved in-path configuration on your Steelhead, it is recommended you issue
the command reset factory reload and proceed to the next step. Remember,
without the reload portion, the reset factory command halts your Steelhead and
will then need to be manually powered up.

Steelhead. For example, click the Serial console to Branch Steelhead link for the branch
office Steelhead or the Serial console to Server Steelhead link for the data center Steelhead.
keyboard. A login screen displays.

3. Enter login admin and password password. The configuration wizard starts and the auto-
configure prompt appears.
Note: If you do not see the configuration wizard, can you reset the system back to factory by
typing reset factory reload from enable mode.
Do you want to auto-configure using a CMC?
4. Type n and press Enter. The configuration wizard prompt appears.

5. Enter y and press Enter. Answer the questions in the wizard to configure your branch office
Steelhead according to the Topology 1 diagram, using your group number for the boxes as in
the example below. Your interaction should be similar to the following:
Step 1: Hostname? [amnesiac] shxbranch (or shxdc for DC)
Step 2: Use DHCP on primary interface? [yes] no
Step 3: Primary IP address? 10.1.x.30 (10.1.x.90 for DC)
Step 4: Netmask? [0.0.0.0] 255.255.255.224
Step 5: Default gateway? 10.1.x.25 (10.1.x.85 for DC)
Step 9: SMTP server? []
Step 10: Notification email address?
Step 13: Would you like to activate the in-path configuration? [no] y
Step 14: In-Path IP address? 10.1.x.20 (10.1.x.80 for DC)
Step 15: In-Path Netmask? [0.0.0.0] 255.255.255.224
Step 16: In-Path Default gateway? 10.1.x.25 (10.1.x.85 for DC)

diagram.
8. Configure the AUX interfaces of both Steelheads.

a. Log into the Steelhead through its Console interface, if you are not already.
b. Enter configuration mode and configure the AUX interface with the desired IP address as
shown in your topology diagram (192.168.99.2##). Please consult the AUX IP addressing
table in the topology diagram section at the back of this lab guide.
c. Save the configuration and restart the optimization service.

shxbranch (config)# write memory
9. Access the Management Console of each Steelhead using the Branch Steelhead or Server
Steelhead links in the eLab Gateway to confirm connectivity. This connects you to the
Steelheads using the AUX interfaces that you configured.

1. Remain in the administrative CLI of the data center Steelhead and enter configuration
mode if you are not already. Alternatively, you may configure the data and time settings
in the Management Console under Configure > Networking > Host Settings.
2. Disable NTP.
3. Configure the clock to your local time zone so that you can view the current time on your
RDP sessions. You MUST configure your system to this time for future lab functionality.

5. Repeat the setting of the clock for the branch office Steelhead.
Task 5: Turn off Simplified Routing on all Steelheads

1. Disable Simplified Routing (set to None) on the Steelheads and save your configuration.
HINT: The setting can be found under Configure > Networking > Simplified Routing.
2. After disabling Simplified Routing you may see a warning appear "Warning: vlan-conn-
based enabled without SR set to "all" or "dest-only"". As the warning implies, the vlan-conn-
based setting is dependent on Simplified Routing but may be safely ignored for this exercise.
Task 6: Router Configuration

1. From the eLab Management Center, click on the Telnet to Router 2 link.

Figure 51: Telnet to Router
2. From this mode, you can type show run. Look to see if your interfaces are configured as
in these examples. Remember that the xs below represent your Group number.
HINT: You can press the space bar when you see --More-- to proceed to the next page
of configuration if you do not see your interfaces.
# This is for the client-side connecting to the server-side
interface FastEthernet0/1.2x
encapsulation dot1Q 22x
ip address 10.1.x.25 255.255.255.224
# This is for the server-side connecting to the client-side

ip address 10.1.x.85 255.255.255.224
3. Should you need to configure either of your interfaces, enter into configuration terminal
mode by issuing the config t command. You should see configuration terminal
prompt: R2(config)#.
4. From the config mode prompt (shown as R2(config)#), configure your interface per
the server-side or client-side example above.
5. Once you configure your interface, type Ctrl+Z or exit until you see the R2# prompt.
6. Verify your configuration by typing show run at the prompt.
7. In addition, you can enter the show ip route command, which should display router
and subinterface information similar to this example:

R2#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
1.0.0.0/24 is subnetted, 1 subnets

C 1.1.1.0 is directly connected, Loopback0
C 192.168.99.0/24 is directly connected, FastEthernet0/0
10.0.0.0/27 is subnetted, 16 subnets
C 10.1.8.0 is directly connected, FastEthernet0/1.28
R2#
8. With the router, PCs, and Steelheads correctly configured you will be able to ping all
interfaces on both sides of your network with the exception of the data center Steelheads
in-path interface. Make sure you can ping all applicable interfaces in the diagram from
both directions: client-side to server-side, and server-side to client-side.
Why arent you able to ping the data center Steelheads in-path interface?
When you are successfully able to ping all these interfaces, then you are ready to proceed with
the next exercise. If you are unable to successfully ping these interfaces then review your
physical connectivity and configuration. Make sure you verify the proper interfaces are active on
the client and/or server, WAN simulator is in bridge mode, and the router is properly configured.
Do NOT proceed until you have end-to-end connectivity.
END OF EXERCISE 7

Exercise 7A: WCCP Redirection of All Traffic & LAN/WAN
Auto-discovery
In this lab our goal is to use WCCP to redirect all traffic to and from the data center servers while
using the default auto-discovery functionality of the Steelheads.
Figure 52: Logical In-Path Network Diagram Redirection
Instructions
1. Configure the branch office Steelhead using a physical in-path configuration as shown in
the above diagram.
2. Configure the data center Steelhead to be virtually in-path (physically out-of-path) using
the information in the above diagram.
1. Physically, only the wan0_0 interface is required to be plugged in. Internally it is still
bridged to the logical inpath0_0 interface that has the layer 3 (IP) information.
2. The basic configuration for virtual in-path is almost identical to a physical in-path
configuration with the addition of checking Enable L4/PBR/WCCP/Interceptor
Support in the Configure > Optimization > General Service Settings menu.
Figure 53: General Service Settings

3. Configure WCCP on the data center Steelhead (remember to turn OFF Simplified
Routing).
1. Navigate to Configure > Networking > WCCP.
2. Enable WCCP v2 Support by checking the box and then clicking the Apply button.
1. RiOS software changes can result in User Interface changes. The screenshots
below are of RiOS 6.5.0. The RiOS version on your Steelheads may be a different
version from these examples. Please make sure to configure the appropriate
options.
Figure 54: WCCP Configuration
3. Click the Add New Service Group tab and enter the necessary parameters as shown
in the example below, using your own group number instead of an X wherever
applicable (there is no password; leave the other parameters with their default values).
Figure 55: WCCP Groups
4. Click on Add when complete.

5. Save the configuration changes you made. Once the WCCP Service Group has been
added, you are ready to move on to the router specific WCCP configuration.
4. Telnet into the router using the Telnet to Router 2 link.

5. From the enable mode prompt (shown as R2#), type show run to view the current
running configuration. While viewing the running configuration, look for the router
interfaces assigned to your group; also, look for the route associated with your group
number allowing the router to forward traffic from the 10.1.x.64/27 subnet to the
10.1.x.0/27 subnet.
ip address 10.1.x.25 255.255.255.224
ip address 10.1.x.85 255.255.255.224
6. Enable WCCP on the router for your service group:

R2#config t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)# ip wccp 9x
7. Enable WCCP redirection for the traffic coming into the data center from the branch
office for your interface.
R2(config)#interface FastEthernet0/1.2x
R2(config-subif)#ip wccp 9x redirect in
R2(config-subif)#exit
R2(config)#interface FastEthernet0/1.22x
R2(config-subif)#ip wccp 9x redirect in
8. Verify that WCCP is properly communicating with the Steelheads.

R2(config-subif)#end
R2#show ip wccp 9x
Global WCCP information:

Router information:
Router Identifier: 1.1.1.1
Protocol Version: 2.0
Service Identifier: 9x
Number of Cache Engines: 1
Number of routers: 1
Total Packets Redirected: 0
Redirect access-list: -none-
Total Packets Denied Redirect: 0
Total Packets Unassigned: 0
Group access-list: -none-
Total Messages Denied to Group: 0
Total Authentication failures: 0
Total Bypassed Packets Received: 0
R2#show ip wccp 9x detail

WCCP Cache-Engine information:
Web Cache ID: 10.1.x.80
State: Usable

Initial Hash Info: 00000000000000000000000000000000
00000000000000000000000000000000
Assigned Hash Info: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
Hash Allotment: 256 (100.00%)
Packets Redirected: 0
Connect Time: 00:09:38
Bypassed Packets
Process: 0
Fast: 0
CEF: 0
R2#show ip wccp 9x view
WCCP Routers Informed of:
1.1.1.1
WCCP Cache Engines Visible:

10.1.x.80
WCCP Cache Engines NOT Visible:

-none-
9. Verify that the entire configuration works and that traffic is properly being optimized by
mapping a drive from the client PC to the server. When mapping the drive to the server
(PCxB) use the format PCxB/userXa (or userXb). In the Current Connections report
on the Steelhead you should see the connection from the client to the server being
optimized.
Note: On both PCs, there are shared drives under the c:\class directory. By default there
should be /share and /unshare.
10. Re-run the commands in step 8, and be sure to look for the total number of packets
redirected:
R2#show ip wccp 9x

Router information:
Router Identifier: 1.1.1.1
Number of routers: 1
Total Packets Redirected: 258
11. Finally, we want to verify that all traffic is being redirected for optimization. For this
purpose, you will require another TCP-based service (that is not passed through using one
of the default rules) such as FTP, HTTP, and/or CIFS. You should have 3CDeamon
installed on both your systems. Run 3CDeamon on the Shared Server. Connect from
PCxA or PCxB to the Shared Server via FTP. While the connection should be successful,
viewing the connections in the Steelhead should reveal that it is passed through. (Use
anonymous for the username and 1234 for the password.) Also, make sure you place

something in the directory of the FTP server so you can pull it down if something isnt
there already.
1. From your PC command prompt:
C:\>ftp 10.1.x.70
Connected to 10.1.x.70
220 3Com 3CDaemon FTP Server Version 2.0
User (10.1.x.150:(none)): anonymous
331 User name ok, need password
Password:
230 User logged in
ftp> ls
200 PORT command successful.
150 File status OK ; about to open data connection
.
..
steelhead-v6.1.img
226 Closing data connection
ftp: 180 bytes received in 0.00Seconds 1800.00Kbytes/sec.
ftp>
1. Note: There are files on the FTP server, please select any large file to pull down.
The above is just an example.
END OF EXERCISE 7A

(Optional) Exercise 7B: WCCP Redirect Lists, WAN-side
Fixed-target Rules, & LAN-only Redirection
In this lab we introduce a method using redirect lists that allows us to control what traffic gets
redirected to the Steelhead. Redirect lists are implemented on the router via ACLs (access control
lists) and allow you to specify what traffic to redirect based on layer 3 (IP source or destination
address) and/or layer 4 information (TCP port numbers). We also use fixed-target rules between
the Steelheads instead of auto-discovery simply for conceptual demonstration. Since the data
center Steelhead is not physically in-path, we still need a method to redirect traffic initiated from
the data center, or returning from a data center server, to the data center Steelhead.
Figure 56: Logical In-Path Network Diagram Fixed-Target Rules
Instructions
Note: This exercise will require you to have an FTP daemon running on PCxA or PCxB. If there
is not one installed on either PC, please ask the proctor for the location of 3CDaemon to install.
1. Ensure your Steelhead configurations match those in Steps 1 through 4 in Exercise 7.
2. Before creating a fixed-target rule telling our Steelheads to redirect traffic, we need to
make sure we only apply the Fixed-Target rule to traffic that will match our redirect lists.
To do this, we will create a port label, specifying the same ports that we will list in our
redirect list (ports 139 and 445). Since the data center Steelhead will only receive traffic

that will be redirected to it from the router, this only needs to be done on the branch
office Steelhead.
1. Navigate to Configure > Networking > Port Labels.
2. Click on Add a New Port Label.
3. Enter the information below.
1. Name: CIFS
2. Ports: 139, 445
Figure 57: Port Labels

3. Now we are ready to apply the Fixed-Target rules using the port label we just created.
1. From the Configure > Optimization > In-Path Rules page, add a Fixed-Target rule
on the branch office Steelhead sending desired traffic to the data center Steelhead as
shown below:
1. Why should you use port 7800 for the Target Appliance?
Figure 58: In-path Rules

4. Add a Fixed-Target rule on the data center Steelhead so that any traffic initiated from the
data center back to the branch office (matching our WCCP redirect list on the router) will
be optimized. Notice how this rule can have the all ports label because the data center
Steelhead will never get packets from the router that were not intended for it to optimize.
1. Should this rule also use port 7800 for the Target Appliance service port?
Figure 59: In-path Rule Configuration
2. Click the Add button and save your configuration.

5. Telnet back into the router and remove the WCCP configuration from the WAN interface:
R2#config t
R2(config)#interface FastEthernet 0/1.22x
R2(config-subif)#no ip wccp 9x redirect in
R2(config-subif)#exit
6. Create an access-list for use in our redirect list (again, be sure to replace the X with your
group number).
R2(config)#access-list 10x permit tcp any any eq 445
R2(config)#access-list 10x permit tcp any any eq 139
R2(config)#access-list 10x permit tcp any eq 445 any
R2(config)#access-list 10x permit tcp any eq 139 any
7. Add a redirect list to your service group, specifying the access-list you created in the
previous step as a parameter.
R2(config)#ip wccp 9x redirect-list 10x

R2(config)#exit
8. Verify that you have properly configured the redirect list using the WCCP show
command.
R2#show ip wccp 9x
Router information:
Router Identifier: 10.1.-.-

Redirect access-list: 10x
9. Once you have configured your redirect list, check to see if the correct packets are being
redirected. The ports selected (445 and 139) are those used by the CIFS protocol. Try
establishing a share from the client to the server, and check either Steelhead to see if the
connection is being optimized.
10. Finally, we want to verify that traffic that should not be redirected is not being optimized.
For this purpose, you will require another TCP-based service (that is not passed through
using one of the default rules) such as FTP. Once you have installed the FTP daemon on
the Shared Server, try to FTP to it from the client. While the connection should be
successful, viewing the connections in the Steelhead should reveal that it is passed
through. (Use anonymous for the username and 1234 for the password.) Also, make sure
you place something in the directory of the FTP server so you can pull it down.
1. From your client PC command prompt:
C:\>ftp 10.1.x.70
Connected to 10.1.x.70
220 3Com 3CDaemon FTP Server Version 2.0
User (10.1.x.10:(none)): anonymous
331 User name ok, need password
Password:
230 User logged in
ftp> ls
150 File status OK ; about to open data connection
.
..
case1.ppt
226 Closing data connection
ftp: 180 bytes received in 0.00Seconds 1800.00Kbytes/sec.
ftp>
1. Note: There are files on the FTP server, please select any large file to pull down.
The above is just an example.
END OF EXERCISE 7B

(Optional) Exercise 7C: WCCP Adding Dynamic (User-
configurable) Service Groups, WAN-side Fixed-target Rules,
& LAN-only Redirection
In the previous lab, we learned how to specify what traffic will get redirected with WCCP to the
Steelhead on the router itself. In this lab, we will fulfill the same requirement, however, rather
than control what traffic will be redirected on the router we will instead have the Steelhead
inform the router of what traffic we would like it to receive.
Figure 60: Logical In-Path Network Diagram Fixed-Target Rules 2
Instructions
1. This lab assumes the same basic configuration as performed in the previous lab, however
we will need to remove the redirect list that we added on the router (this command will
disable WCCP for now):
R2#conf t
R2(config)#no ip wccp 9x
The WCCP service is now disabled but remains configured on at least one
interface.
R2(config)#
2. Next, we need to configure the data center Steelhead to inform the router of which TCP
ports the router should forward to it.

1. Navigate to Configure > Networking > WCCP.
2. Click on the 9x service group you created earlier to enter the service group
configuration page.
3. In the Ports Mode drop-down menu, select Use Source Ports.
4. In the Ports text box, enter 139, 445.
Figure 61: WCCP Groups

3. Now that the data center Steelhead is configured, we need to re-enable WCCP on the
router.
R2(config)#ip wccp 9x
R2(config)#exit
4. Once WCCP is re-enabled, run through the WCCP show commands and verify that the
Steelhead and router are properly communicating.
5. Finally, on the client PC, map to a folder residing on the server and verify that the
connection is being optimized.
END OF EXERCISE 7C

Exercise 8: Upgrade
In this exercise, you will upgrade the software image of your Steelheads.
1. Revert back to the backup-branch and backup-server configurations you saved in
Exercise 1 on both your Steelheads.
2. Activate Topology 1 in the eLab Management Center.
3. Change back into router mode on the WAN simulator. It may be beneficial to lower the
latency and increase the bandwidth on the WAN simulator to speed up the transfer.
4. Obtain a RiOS image from the instructor. The image is on the Shared Server, usually in
the unshared or shared directories.
1. Copy the image to a location on the client PC (PCxA or PCxB).
5. In the Management Console, install the image on your branch office Steelhead.
1. Navigate to Configure > Maintenance > Software Upgrade.
2. Click the Local File button and Browse to select the image file on your client PC.
Figure 62: Install Upgrade
3. Click on Install.
4. To boot the Steelhead into the new software, navigate to Configuration >
Maintenance > Reboot/Shutdown or just click on the Reboot/Shutdown tab and
click the Reboot button.
1. Note that your configuration is preserved when upgrading from an older version
to a newer version.
6. On your data center Steelhead, install the image using the Steelhead administrative CLI.
1. Check if the image is in the FTP directory of the central server. If it is not, place it
there.
2. Fetch the image from the FTP server to the data center Steelhead. The [image.img]
name shown in the example below may be different from the image you are
upgrading to. Use the exact image name as seen in the FTP directory.
shxdc # image fetch ftp://10.1.41.70/[image.img]
3. Confirm that the image file is present locally on the Steelhead.

shxdc # image install ?
<image filename>
image.img
4. Observe the current boot configuration. Below is an example. Your boot partitions
may be different.

shxdc # show boot
Installed images:
Partition 1:
rbt_sh 6.5.0 #84_25 2011-02-29 09:55:37 x86_64 root@brno:svn://svn/mgmt
/branches/canary_84_fix_branch
Partition 2:
Last boot partition: 2

Next boot partition: 2
5. Notice that you cant install into the booted image partition.
shxdc # image install image_rbt_sh_6_5_0_n84_25_x86_64.img 1
% Cannot install to same partition just booted from.
6. Install the image to the available partition.

shxdc # image install image_rbt_ sh_6_5_0_n84_25_x86_64.img 2
7. Change the default boot partition to the newly installed partition.

shxdc # config t
shxdc (config) # boot system 2
shxdc (config) # exit
shxdc # write mem
8. Confirm that the Steelhead will boot to the set partition. Below is an example.
shxdc # show boot
Installed images:
Partition 1:
Partition 2:
Last boot partition: 2

Next boot partition: 1
9. Reboot the Steelhead into the new software.

shxdc # reload
END OF EXERCISE 8

Exercise 9: RSP Installation & Configuration
Task 1: Lab setup
1. Verify you are still in Topology 1 on the eLab Management Center.
2. Log into your RDP group PC (PCXA or PCXB) as administrator with the password of
password. You need to be logged in as an administrator for certain privileges. For
example:
Figure 63: Admin login to PCxA or PCxB
3. Verify that you have a mapped drive to the optimized Shared Server.
4. The files we will be using will be in the class software folder. The two files we need are:
1. The RSP image in the rspimage folder.
2. The pfSense RSP package in the rsppackage folder.
3. Download these files to your group PC.
5. Log into the branch office Steelhead via the browser and verify or install an RSP license.
If there is not a valid RSP license installed please contact your instructor. Or, in the CLI:
license install <license text>.
Figure 64: RSP License
Task 2: Install and start the RSP

1. Navigate to Configure > Branch Services > RSP Service.

Figure 65: RSP Service Page
2. If the RSP software is already installed (RSP Installed: Yes) please skip to the next Task.
3. Select Local File from the Install RSP From drop-down list.
4. Click the Browse button and select the RSP image that was obtained from the instructor.
Note: The file below is just an example. We may update the file version as needed. Look
for the file on the shared server under share. Your instructor will place the latest copy. It
should have rsp in the file name.
Figure 66: RSP Image Install
5. Click the Install button. Next to the install button you should see the installation status. It
will take some time to transfer the RSP image onto the Steelhead. After the transfer, RiOS
will install the RSP image this will take a few minutes.
Figure 67: RSP Being Installed
6. Start the RSP service by clicking the Start button. RSP state will change from
initializing to running. This will take about 30 seconds.
Figure 68: RSP Start

Task 3: Add your package to the RSP
1. Navigate to Configure > Branch Services > RSP Packages or just click on the RSP
Packages tab. There may be some packages already installed on your branch office
Steelhead. Below is just an example.
Figure 69: RSP Packages Page
2. If the pfSense package is already installed you may either select the package and click
Remove Selected Packages or skip the next step. Select Add a Package.
3. Select From Local File and Browse to locate pfSense-X.X_RSP.pkg. The file should
have been copied in step 1. Below is just an example. The file names change so verify
that you are installing the proper file.
Figure 70: pfSense Package
4. Click the Add Package button. You will see the status next to the Packages section
header.
Figure 71: Fetching Package
5. After the package is added, verify it has been added.

Figure 72: RSP Package Added
Task 4: Load package

You will now load the package into slot 1 and allocate 128MB of memory. Do not enable the slot
yet as we have to configure the VNIs for Data Flow.
1. Click on either the RSP Slots link or the RSP Slots tab.
2. Expand slot 1 by clicking on either the magnifying glass or the number to show the
details.
3. Change the slot name to something more appropriate (for example, pfSense).
4. Select your previously installed package by name from the drop-down list for Package
File Name.
Figure 73: Slot
5. Click the Install button. This process can take 5 minutes to complete.
6. Verify that the slot was installed and that Slot 1 information has been updated for your
package.
Figure 74: pfSense Installed in Slot
7. Expand the pfSense slot.

8. Click on the VNIs tab to verify the LAN and WAN Virtual Network Interfaces (VNIs).

Figure 75: pfSense LAN/WAN VNIs
9. Click on the Watchdog Settings tab.

10. Verify that the VNI Policy on Failure field is set to Bypass on failure.
11. Enable ping monitoring and set the watchdog IP to your branch office Steelheads in-path
interface. When complete, click the Update Slot button.
Figure 76: Configure Watchdog
Task 5: Configure the proper VNI Data Flow

1. Navigate to Configure > Branch Services > RSP Data Flow or click the RSP Data
Flow tab.
Figure 77: RSP Data Flow

2. Click on RiOS0_0 in position 1 and verify that VNI for RIOS0_0 is set to redirect in the
Action column.
Figure 78: VNI for RIOS0_0
3. Click on Add a VNI.

Note: You are adding a VNI so the traffic can come into the slot where the VM instance
resides. This is used to redirect traffic to your package.
4. Add pfSense:LAN at the end of the flow and click the Add button.
Figure 79: Data Flow for inpath0_0 LAN
5. Repeat this process for adding pfSense:WAN (to the end).
Figure 80: Data Flow for inpath0_0 WAN
Note the not-effective state. This should clear when the slot is enabled in the next step.
6. Now Enable Slot for Slot 1 (pfSense) under the Configure > Branch Services > RSP
Slots menu.
1. Expand the details for the slot named pfSense.
2. Click the Enable button in the Slot Operations tab.
3. Verify that the slot pfSense is enabled.

Figure 81: RSP Package Enabled
7. Verify that the interface states are clear in Configure > Branch Services > RSP Data
Flow.
Figure 82: Data Flow for inpath0_0

9. After the slot is fully booted, make sure your network LAN connection on your client PC
is set to obtain an IP address automatically. It will obtain an IP address via DHCP from
the pfSense firewall. Do this by configuring the PRIMARY IP. Please DO NOT
CHANGE the Management IP.
Figure 83: DHCP for Primary IP
10. Access http://192.168.1.1 with account admin and password pfsense to start the
configuration for your network.
Figure 84: Login to pfSense
11. Go to Interfaces and select the LAN.
Figure 85: Interfaces LAN

12. Configure your IP address for your management interface as 10.1.x.15/27 and configure
the WAN as bridge. Save the configuration BUT do NOT apply it yet.
Figure 86: pfSense IP Configuration
13. Navigate to Services DHCP server and change the range of IP addresses it uses. Also
specify the Gateway as 10.1.x.25. Below is just an example.
Figure 87: DHCP Server
14. Save your settings.

15. Navigate back to Interfaces and select LAN.
16. Click the Apply changes button.
17. Navigate back to the Primary interface on your PC and re-IP your system
(ipconfig /release and then ipconfig /renew).
18. You should now be able to connect to your pfSense via the newly configured IP via your
web browser (http://10.1.x.15). Remember that the login is admin and pfSense. All IP
addresses are now on the same network as your Steelheads and WAN simulator.

Figure 88: pfSense System Overview
Task 6: Use pfSense to block traffic to .71 network access from the LAN port
1. From the web interface of pfSense, navigate to Firewall: Rules.
2. Click on the LAN tab.
3. Click on the upper right most + icon to add a new rule.
Figure 89: Firewall: Rules
4. For this new rule, set Action to Block.

5. Set the destination to 10.1.41.71.

6. Save the new rule and apply your changes. You will be returned to the LAN tab.
Figure 90: Block Traffic
7. Verify the firewall is functioning by trying to access http://10.1.41.70 and

http://10.1.41.71. 10.1.41.71 should be blocked.
8. Return to your previous Primary LAN IP address on the client PC. Use the Topology 1
diagram if you forgot your PCxA or PCxB address.
9. Disable the pfSense RSP slot. Verify that the pfSense slot is disabled before proceeding
to the next lab.
Figure 91: Disable pfSense RSP slot
END OF EXERCISE 9

Exercise 10: HS-TCP
In this lab, you will be simulating a satellite network. You will need to configure your WAN
simulator to 600 milliseconds of latency and the bandwidth at 6 Mbps.
Figure 92: New WAN Sim Settings
Activity Procedure
Task 1: Configure HS-TCP on your branch office and data center Steelheads
1. On the branch office Steelhead, navigate to Configure > Optimization > Transport
Settings.
2. Select Enable HighSpeed TCP. This is only a screenshot; the BDP must still be done.
Figure 93: Performance Page
3. Configure the BDP. Verify the calculation using your WAN simulator parameters as
indicated in the introduction.
Figure 94: BDP Calculator

5. Navigate to Configure > Optimization > Performance.

6. Select SDR-Adaptive. Keep everything else as default.
Figure 95: Adaptive Data Streamlining

8. Save the configuration and restart the optimization service.
9. Repeat the steps for the data center Steelhead.
Task 2: Disable dynamic water markings

This task is only done via the CLI.
1. Serial console into both Steelheads.
2. Enter configuration mode.
3. Type the following command: protocol connection wan dyn-wat 0
4. Save the configuration using the command write memory.
5. Restart the service on both branch office and data center Steelheads by using the
command restart.
Figure 96: Disabling Dynamic Water Markings
Activity Verification
Verify you still have a pass-through rule for .71. If you dont have one, make sure to place an in-
path rule as pass-through for 10.1.41.71 before you proceed.
Figure 97: Pass-through Rule Verification
1. Measure performance of web operations. Make sure to grab sizable files or entire
directories. This test could take time to accomplish.
1. On each client PC, clear your web browser cache. In Internet Explorer, this is done
by clicking Tools > Internet Options > General, and then clicking the Delete Files
button.

2. From one client PC, access files on the web server through the unoptimized network
path.
1. URL: http://10.1.41.71
3. From the other client PC, access files on the web server through the optimized
network path.
2. URL: http://10.1.41.70
4. Use the Management Console and CLI to confirm that you see both optimized and
pass-through connections.
5. Compare the performance via the unoptimized network path with performance via the
optimized network path.
3. Clear your browser cache after each operation to ensure that files are always
being pulled across the WAN.
2. Measure performance of FTP operations.
1. Open a Windows command prompt on each client PC and run ftp.
4. This is recommended instead of using ftp:// URLs in Windows Explorer because
the command-line FTP does not do any local caching.
2. From one client PC, open a connection to the server via the unoptimized network
path.
ftp> open 10.1.41.71
Connected to 10.1.41.71.
5. User: anonymous
6. Password: <anything>
3. From the other client PC, open a connection to the server via the optimized network
path.
ftp> open 10.1.41.70
Connected to 10.1.41.70.
4. From the Management Console and CLI, confirm that you see both optimized and
unoptimized connections.
5. Via the optimized network path, upload a file that you had downloaded during one of
the previous tests.
7. You may need to use the lcd command to change your local directory to where
the files are saved. Example: ftp> lcd "\Documents and
Settings\Administrator\Desktop"
8. Transfer in binary mode, and enable hash marks to provide a visual of how
quickly the file is transferring. For example:
ftp> bin
200 Type set to I.
ftp> hash
Hash mark printing On ftp: (2048 bytes/hash mark) .
ftp> put <filename>
150 Opening BINARY mode data connection for '<file>'.
##########
. . .
9. Because the Steelheads are warmed from your previous tests, you should receive
warm speed performance despite the fact that this is the first time the file has
ever been transferred using the FTP protocol.
6. From both client PCs, perform additional put and get operations to upload and
download files.

10. Note the differences in performance between unoptimized, cold, and warm
operations.
3. In the Management Console, browse the Reports menu and study the appropriate ones.
END OF EXERCISE 10

Exercise 11: Agentless Prepopulation
RiOS includes a facility for proactively warming Steelhead appliance data stores with contents
from remote file shares. Using the Management Console, proactive warming can be initiated on a
real-time or scheduled basis. You no longer need to install a prewarming server-side agent for
data store warming. Contents from file shares residing on Windows, Network Appliance, or
EMC servers can be pushed to a Steelhead data store, eliminating the cold hit that occurs when
the Steelhead appliance has not seen the data before.
1. A Windows share named prepop is available on the Shared Server. This share points to
the /share/dataset directory.
2. Configure your branch office Steelhead for prepopulation.
1. From the Management Console of your branch office Steelhead, click Configure >
Optimization > CIFS Prepopulation.
2. Click the Enable button.
Figure 98: Enable Prepopulation
3. Click on Add a New Prepopulation Share.

1. Add the prepop share from the Shared Server.
Figure 99: Add a New Prepopulation Share
2. Once you have added the share, it should look similar to the screen below.

Figure 100: Prepop Share 1
3. Save the configuration.

4. Click on the share name (which is link into the share configuration screen). In the
Editing Prepopulation Share section check the Enable checkbox and click Apply to
have the share start synchronizing with the directory on the server.
Figure 101: Prepop Share 2
5. Click back on the share name to see the synch progress. For example:
Figure 102: Synch in Progress
4. Alternatively, you can do the above via the CLI.

1. Click the link and add the share you want to mount.
1. From the CLI, the procedure would be done like this:
shxbranch (config) # prepop share configure remote-path
\\\\10.1.41.70\\ server-account Administrator server-password password
interval 300 start-time '2010/07/01
Share registration in progress ...
2. Once the prepopulation has completed, have the client PC mount the share drive from
the server and pull down the files. The files should transfer as if they were warm.
END OF EXERCISE 11

(Optional) Exercise 11a: RCU 2.x
In this exercise, you use the RCU utility to perform Transparent Prepopulation as well as host-to-
host folder mirroring. In order to complete this optional module, you will have to use Topology
4. You will be using the same Topology 4 with QoS lab.
Task 1: Reconfigure interfaces
1. From the eLab Management Center, select Topology 4.
server-side. No shared server in this lab. PCxB will be the server in this lab. Note: This
procedure is ONLY done on PCxB.
a. Navigate to the Start Settings Network Connections (also available through the
Control Panel)
b. Right-click to disable the Primary interface.
c. Enable the Secondary Lan interface.
Enable Disable
Figure 103: Network Connections
view the following:
Figure 104: ipconfig Command

1. Note that the Router is shared by all lab groups.
2. Both the Lab Router and Lab Switch have been pre-configured to allow for basic IP
connectivity and routing for basic access from your eLab Main Page.
5. Ensure that the WAN simulator is in routing mode and set the IP addressing for its interfaces
Net1 and Net2 as identified in the Topology 4 diagram.

1. Before starting this portion, it is recommended you issue the command reset factory
reload. Remember, this command halts your system. You will need to reboot your system
in order for it to power up.
We are commending this part due to the all the configuration changes done in the prior
lab. If you have copied a base configuration before starting any labs, load it now to
prevent the remaining steps. Go to Task 5 if you loaded a previous base configuration.

Steelhead.
keyboard a few times.
4. Go to eLab Management Center to reboot your system.
Use a CMC to auto-configure your appliance?

according to the Topology 4 diagram, using your group number for the boxes as in the
Step 2: Use DHCP on primary interface? [no]
Step 3: Primary IP address? [169.254.169.254] 10.1.x.30 (10.1.x.90 for DC)
Step 4: Netmask? [255.255.0.0] 255.255.255.224
Step 5: Default gateway? 10.1.x.25 (10.1.x.85 for DC)
Step 9: SMTP server:
Step 10: Notification email address:
Step 14: In-Path IP address? 10.1.x.20 (10.1.x.80 for DC)
Step 15: In-Path Netmask? [0.0.0.0] 255.255.255.224
Step 16: In-Path Default gateway? [10.1.x.25] (10.1.x.85 for DC)


diagram.
9. Configure the AUX interfaces of the Steelheads. The AUX interfaces are typically used for
out-of-band management and are used in the eLab for SSH and HTTP GUI access to the
Steelheads.
closely.
shxbranch # conf t

d. Repeat the steps to configure the data center Steelhead using the appropriate IP address
e. Access the Management Console to each Steelhead using the Branch Steelhead or
Server Steelhead links in the eLab Gateway. This connects you to the Steelheads using
the AUX interfaces that you configured. You can log into each device using the admin
user name and password for the password.
10. Remain in the Serial console to Server Steelhead.

1. Now we need to configure the date and time on your system. Enter configuration mode.
2. Disable NTP.
your RDP sessions. You MUST configure your system to this time for future lab
functionality.

5. Repeat the setting of the clock for the branch Steelhead.
Task 5: Install RCU

1. Install the RCU installation file on your system from c:\Share\class software\additional
software\.
2. Copy the RCU executable to c:\windows\system32.

3. Verify that you copied the file by opening a command prompt and type the following
command: rcu.
Figure 105: rcu Command
Task 6: Configure your branch office Steelhead for Transparent Prepopulation

The end result of this configuration change is the opening of a TCP port 8777 to which RCU can
send data. If you performed the previous exercise you may skip to the next task.
1. From the Management Console of your branch office Steelhead, navigate to Configure >
Optimization > CIFS Prepopulation.
2. Select the Enable button for Prepopulation.
3. Select the Enable Transparent Prepopulation Support checkbox.
Figure 106: CIFS Prepopulation Page
4. Click the Apply button and then save the configuration.
Task 7: Prepopulate the contents of a folder on the Shared Server to the branch office
Steelhead and test performance
1. Clear the data stores of both your Steelhead appliances and make sure the service is Healthy
on both.
2. On the Shared Server, become acquainted with the many available RCU options.
C:\> rcu
. . .

3. Prepopulate the contents of your c:\share\class software directory to the branch office
Steelhead.
C:\> rcu /prepop C:\share\class software 10.1.x.30
- In the Management Console of your branch office Steelhead, you should see a
connection to port 8777 on the Shared Server.
- This operation could occur off-hours as a Windows Scheduled Task, allowing the
contents of very large folders to be prepopulated nightly for the maximum
performance of branch office users.
4. From the client PC, create a mapped drive to the share on the Shared Server.
5. On the client PC, copy one of the files in the share to the desktop. You should expect to see
warm performance despite the fact that this is the first time you are accessing the data via
CIFS since the Steelhead data stores were cleaned.
6. Perform a mirror operation from the client PC to the Shared Server.
a. On the Shared Server, create a folder that will be used as a backup destination for files
(such as c:\backup).
b. Within a command prompt, cd to the backup folder and run the RCU in server mode.
c:\> cd \backup
c:\backup>rcu /server
c. On the client PC, find a folder that contains data to be backed up (such as c:\temp).
d. Within a command prompt, run RCU in mirror mode.
c:\> rcu /mirror c:\temp 10.1.x.70 tempbackup
- In the Management Console of your branch office Steelhead, you should see a
connection to port 8777 on the Shared Server.
- On your Shared Server, within the c:\backup folder, you should see a sub-folder
called tempbackup that begins to fill with data.
- A customer that has retained some servers in a branch office could use RCU in this
way to perform a nightly mirror to a server in the data center that could then be
backed up to tape.
7. Perform a monitored mirror operation from the client PC to the Shared Server.
a. On the client PC, within a Command Prompt, run RCU in monitored mirror mode.
c:\> rcu /monitor /mirror c:\temp 10.1.x.70 tempbackup
b. Copy a file into c:\temp and confirm that it is automatically mirrored to the remote side.
Verify the file is there on the server.
END OF EXERCISE 11a

Exercise 12: Quality of Service
In this lab exercise, we introduce how to configure and monitor Quality of Service on Riverbed
Steelhead appliances.
As this lab is done remotely, it would be difficult to perform a user perception test on something
as subtle, yet detrimental, as network jitter. As such, we will use a traffic generation tool called
IPerf (with a GUI wrapper called JPerf) to help quantify and graph the results.
The scenario we simulate has a service provider connection that has been saturated by UDP
traffic (which does not play nicely on the WAN), while we also expect two voice calls (simulated
by more UDP traffic) at 40kbit/sec each (80kbit/s total) to go through this line with as little
packet loss and jitter variation as possible.
If you did the optional RCU exercise, proceed to Task 5.
Task 1: Reconfigure interfaces
1. From the eLab Management Center, select Topology 4. For reference, the Topology 4
diagram is located in the back of this lab guide.
server-side. PCxB will act as a server in this lab. Note: This interface change procedure is
ONLY done on PCxB.
a. On PCxB, navigate to the Start Settings Network Connections and right-click to
disable the Primary interface.
b. Once the Primary interface has been disabled, enable the Secondary Lan interface.
Enable Disable
Figure 107: Workstation Interfaces
see the following as an example:

Figure 108: ipconfig Page
a. Note that the Router is shared by all lab groups.
b. Both the Lab Router and Lab Switch have been pre-configured to allow for basic IP
connectivity and routing for basic access from your eLab Main Page.
5. Ensure that the WAN simulator is in routing mode and set the IP addressing for its interfaces
Net1 and Net2 as identified in the Topology 4 diagram.

1. Before starting this portion, it is recommended you issue the command reset factory
reload. Remember, this command halts your system. You will need to reboot your system
in order for it to power up.
We are commending this part due to the all the configuration changes done in the prior
lab. If you have copied a base configuration before starting any labs, load it now to
prevent the remaining steps. Go to Task 5 if you loaded a previous base configuration.

Steelhead.
keyboard a few times. A login screen appears.

Note: If you do not see the configuration wizard, reset the system back to factory.
4. Go to eLab Management Center to reboot your system.
Use a CMC to auto-configure your appliance?

according to the Topology 1 diagram, using your group number for the boxes as in the
Step 2: Use DHCP on primary interface? [no]
Step 3: Primary IP address? [169.254.169.254] 10.1.x.30 (x.90 for DC)
Step 4: Netmask? [255.255.0.0] 255.255.255.224 (/27 in the DC)
Step 5: Default gateway? 10.1.x.25 (or 10.1.x.85 for DC)
Step 9: SMTP server:
Step 10: Notification email address:
Step 14: In-Path IP address? 10.1.x.20 (or 10.1.x.80 /27 for DC)
Step 15: In-Path Netmask? [0.0.0.0] 255.255.255.224 (/27 in the DC)
Step 16: In-Path Default gateway? [10.1.x.25] (or 10.1.x.85 for DC)

diagram.
9. Configure the AUX interfaces of the Steelheads. The AUX interfaces are typically used for
out-of-band management and are used in the eLab for SSH and HTTP GUI access to the
Steelheads.
closely.

d. Repeat the steps to configure the data center Steelhead using the appropriate IP address

e. Access the Management Console of each Steelhead using the Branch Steelhead or
Server Steelhead links in the eLab Gateway.
10. Remain in the administrative CLI of the data center Steelhead.

1. Enter configuration mode.
2. Disable NTP and verify.
your RDP sessions.

5. Repeat the setting of the clock for the branch Steelhead.
Task 5: Verifying QoS settings

1. Before you begin this lab, ensure that you have configured and tested the simple in-path
deployment (Topology 4). This lab also assumes that no previous QoS configuration is
configured on either Steelhead. This can be verified by navigating to the Configure >
Networking > Basic QoS page in the Management Console.
Figure 110: QoS Classification
Task 6: Explore and get to know JPerf

In this section you will enable JPerf on both sides of the network, on PCxA and PCxB.
1. Connect to your Group PCs and open two instances (two on each Group PC) of JPerf by
double-clicking the icon on the desktop twice. Note that one window may hide behind the
other.

2. On the server-side PC, PCxB, select one of the JPerf windows and configure it to match the
settings in the following screenshot. (Server, listening port 5001, UDP protocol)
Figure 111: JPerf Config
a. Click the Run IPerf! button to have this window start listening on UDP
port 5001.
b. Select the second Jperf window (do not close the previous window!) on PCxB and
configure it similar to the previous window, but with Listen Port 6001 (UDP, Server, Port
6001).
c. Click the Run IPerf! button for this second window to start listening on UDP port 6001
3. Configure PCxA so that it will create traffic for our simulated flood and voice traffic
(UDP ports 5001 & 6001, respectively). Begin with setting the parameters on the first JPerf
window to match the settings on the following screenshot, making sure to adjust the IP
address for your pod environment.

Figure 112: JPerf Config 2
a. Click the Run IPerf! button. This begins to saturate the line by sending traffic from the
Client PC to the Server PC at 500k/s (as configured in the previous step).
b. Configure the other JPerf window on each branch PC similar to the previous window, but
this time to simulate the stream with two voice calls (Client, Server Address: 10.1.x.70,
Port 6001, Transmit: 20 seconds, UDP, UDP Bandwidth: 80kb/s).
c. Click the Run IPerf! button to start sending the traffic that will simulate the two voice
calls.
4. After 20 seconds, click the Stop button on PCxB for the window configured to serve on port
6001.
Notice the graphs on the system. You will see the Jitter and the Kbits (BW) on the Server
listening side JPerf. We will use this utility to verify our QoS configuration.
Task 7: Configure QoS

In this section, you will be configuring QoS on the branch office Steelhead.
1. Enable QoS to improve the bandwidth and jitter results with QoS disabled.
a. On the branch office Steelhead, navigate to Configure > Networking > Basic QoS.

Figure 113: General QoS Settings
b. Enter 500 as the WAN interface bandwidth for interface wan0_0.

c. Click the Apply button.
d. Save the configuration and restart the optimization service.
e. Select the Applications tab.
f. Click the Add Application button.

g. Add a QoS application that tells the Steelhead what traffic to put into what service class.
In this case, we want any UDP traffic destined for port 6001 to go into the Voice QoS
class. Configure the application accordingly and click Add, followed by a configuration
save. Use the screenshot below as an example if necessary.
Figure 114: QoS Application
Task 8: Attempt to saturate the link to measure performance

In order to saturate a link, we are going to pull down a file while simulating a voice call.
Therefore we will perform task 8 with task 9.
1. From PCxB, have your partner start the 3CDaemon FTP software. Make sure anonymous is
configured and pointing to c:\class.

2. From PCxA open a command prompt and connect via FTP to the server.
3. Find a large file to copy to PCxA. Do NOT start the transfer yet.
Task 9: Reconfigure your JPerf with the new settings and view base transfer with no QoS
and compare this with QoS
1. Configure the other JPerf window to simulate a stream with two voice calls. This can be done
by matching the settings in your second window to those on the following screenshot. (6
streams, 20 seconds of transmit, port 6001, and 80 KBytes)
2. Start your FTP. This should be coming over cold.

3. Start your JPerf transfer. Click Run to start sending the traffic that will simulate the 6 streams
or 12 voice calls (80kbit/sec). You have now generated enough statistics.
4. Click the Output tab and scroll to the bottom to see the summary results for the transfer.
They should look similar to the numbers in the following graphic.
In this example, the summary (the last line before Done) shows that 34 out of 137 packets
were lost or approximately 25%. It also shows that average throughput was closer to 57.2
Kbits/sec and that average latency was about 47.571ms.

Lets start QoS and see how the graph changes.

5. Enable QoS.
Figure 117: Enable QoS Classification & Enforcement
6. Restart clean on both Steelheads. Note: This command will kill your FTP so you will have to
reestablish your FTP connection.
7. Start your ftp session of the same file which should transfer cold.
8. Execute JPerf with 6 streams again.

Figure 118: JPerf Graph
Note: Your QoS Graph now shows 0/137 with 0% loss.
END OF EXERCISE 12

Appendix A Topology Diagrams
You may want to detach the following topology diagrams for use with the labs.

Note
Every Steelheads AUX port is in the 192.168.99.0/24 network. The last octet of each AUX
interface IP address is set as follows:
Table 1 Steelhead AUX IP addressing schema
sh1br .201 sh1d .202 sh5b .209 sh5d .210
c r c
sh2br .203 sh2d .204 sh6b .211 sh6d .212
c r c
sh3br .205 sh3d .206 sh7b .213 sh7d .214

c r c
sh4br .207 sh4d .208 sh8b .215 sh8d .216
c r c

SADM6 - 5 eLabExercises v02

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

SADM6 - 5 eLabExercises v02

Uploaded by

Copyright:

Available Formats

Table of Contents

2008-2011 Riverbed Technology 1

2 2008-2011 Riverbed Technology

Figure 1: Riverbed eLab Login Page

Figure 2: Security Question

2008-2011 Riverbed Technology 3

(at the bottom of the list). The eLab Management

Figure 4: eLab Management Center Login

4 2008-2011 Riverbed Technology

Using & Managing Your eLab Pod

1. SSH using the Branch Steelhead link , or

2008-2011 Riverbed Technology 5

Figure 6: WAN Simulator Menu

Figure 7: Terminal Server Connections

6 2008-2011 Riverbed Technology

Figure 8: Terminal Sessions

Figure 9: Terminal Session Login

2008-2011 Riverbed Technology 7

Figure 10: Lab Topologies

Task 2: Configure your simulated WAN

b. Click the Device Settings tab.

8 2008-2011 Riverbed Technology

e. Click the Bridge/Route tab.

Figure 12: Bridge/Route

g. Click the Apply Changes button.

2008-2011 Riverbed Technology 9

k. Click the Apply Changes button.

Task 3: Configure your branch office and data center Steelheads

Figure 14: Telnet Session

10 2008-2011 Riverbed Technology

5. Enter n and press Enter. The configuration wizard prompt appears.

7. When prompted, press Enter to save your configuration.

b. Enter enable mode, so youll be able to use privileged commands.

d. Save the configuration and restart the optimization service.

2008-2011 Riverbed Technology 11

Task 4: Configure the date and time

6. Verify the clock setting:

Task 5: Check software version and licenses

Task 6: Verify connectivity

12 2008-2011 Riverbed Technology

Figure 15: Online Help

6. Close the Help page.

Task 8: Configure system settings

2008-2011 Riverbed Technology 13

4. Click the Apply button.

Task 9: Set up a student role-based account (RBA)

14 2008-2011 Riverbed Technology

Figure 18: Student Login Home Page

Task 10: Configure web settings

Figure 19: Web Settings

3. Click the Apply button.

Task 11: Check connections

2008-2011 Riverbed Technology 15

Figure 21: Health Check Report

4. Feel free to run any additional tests that you wish.

Task 13: Backup the configuration on all Steelheads

Figure 22: Save Configuration

16 2008-2011 Riverbed Technology

Figure 23: Initial Configuration

Figure 24: Backup Configuration

2008-2011 Riverbed Technology 17

Figure 25: Disable Service

18 2008-2011 Riverbed Technology