Deployment Guide - VSH on Cisco SRE.pdf

DEPLOYMENT GUIDE

Riverbed Virtual Steelhead on Cisco SRE/ISR G2

Deployment Guide Riverbed Technical Marketing

RIVERBED VIRTUAL STEELHEAD ON CISCO ISR/G2

© 2012 Riverbed Technology. All rights reserved. 1

VIRTUAL STEELHEAD ON CISCO ISR/G2

Introduction

Cisco® Integrated Service Router Generation 2

The Cisco Integrated Service Router Generation 2 (ISR G2) is a family of branch-office routers. It has more processing power and better WAN performance than the models in the previous ISR family. Supported routers in the family can run a more powerful ESXi 4 or ESXi 5 virtualization platform via the SRE modules which can be plugged into the router. For more information on the ISR/G2 family of branch-routers, visit the Cisco product page at http://www.cisco.com/en/US/products/ps10906/Products_Sub_Category_Home.html#~one Cisco Services-Ready Engine

A summary of the Cisco Services-Ready Engine (SRE) can be found at the Cisco website at http://www.cisco.com/en/US/prod/collateral/modules/ps10598/data_sheet_c78-553913.html . “The Cisco® Services-Ready Engine (SRE) modules are router blades for the Cisco Integrated Services Routers Generation 2 (ISR G2) that provide the capability to host Cisco, third-party, and custom applications. The modules have their own processors, storage, network interfaces, and memory that operate independently of the host router resources, helping ensure maximum concurrent routing and application performance.”

Figure 1 – Cisco 900/910 Cisco SRE Module

This paper is a deployment guide for configuring Riverbed Virtual Steelhead (VSH) on the SRE. It begins with some information for new deployments of SRE (especially as it pertains to VSH), then provides some network integration examples. As the virtualization environment is VMware® ESXi®, this paper will not concentrate on installing VSH on ESXi (please refer to the documentation on the Riverbed Support Site at https://support.riverbed.com/docs/appliance.htm). Instead, this paper will concentrate on the important parts around VSH in this specific ESXi environment: SRE configuration and the various WCCP options. The SRE-V image is a Cisco-prepared version of ESXi. You must use the Cisco version of ESXi on the SRE. This document assumes you have basic understand of ESXi, VSH, and WCCP (as it pertains to Riverbed Steelhead appliances). In this paper, we document the steps we took to get VSH running in the SRE environment. Some of these steps may need to be altered or may not apply in your environment.

Checklist for Administrators with VSH Experience

The following is a list of pertinent information in this documentation for those administrators who already have extensive VSH experience:

Installing the SRE module, configuring basic management IP addresses

Installing the SRE software – do not use the FTP service in Microsoft® Windows Server 2008R2 operating system

http://www.cisco.com/en/US/products/ps10906/Products_Sub_Category_Home.html#~one

http://www.cisco.com/en/US/prod/collateral/modules/ps10598/data_sheet_c78-553913.html

https://support.riverbed.com/docs/appliance.htm



vmnic mapping to router/SRE entities

VSH model support

Configuring the SRE on the Cisco ISR G2 router for ESXi In this section, we follow many of the steps in Cisco SRE-V Self Training guide, located on the Cisco website at http://www.cisco.com/en/US/prod/collateral/ps10265/ps11273/installation_guide_c07-640002.html#wp9000192 . Our test setup has a 3945 ISR G2 and an SRE 910 blade with 8GB RAM (2x4GB) installed.

Install the SRE blade

Install the SRE module into an available slot on the ISR G2 router. In our test setup, we installed the module into Slot 4. For more information on installing the SRE Service Module into the router, refer to documentation on the Cisco website at http://www.cisco.com/en/US/docs/interfaces_modules/services_modules/sre_v/1.0/user/guide/hardware.html .

Configure the management network

In our test setup, interface Gi0/3 on the router has been designated as our management interface. The first part of configuration is to setup IP addressing such that the SRE-V software can be installed via ftp. We have an ftp server installed on Windows 2008R2 Server on a management network. We will configure the management interface on the same network as the ftp server.

gi0/3: mgmt

10.32.146.196

Windows 2008R2E

Cisco 3945 ISR G2

mgmt: 10.32.146.217

Figure 2 – Management IP address configuration for ftp access

http://www.cisco.com/en/US/prod/collateral/ps10265/ps11273/installation_guide_c07-640002.html#wp9000192

http://www.cisco.com/en/US/docs/interfaces_modules/services_modules/sre_v/1.0/user/guide/hardware.html



Router configuration: interface GigabitEthernet0/3

description mgmt

ip address 10.32.146.196 255.255.255.0

duplex auto

speed auto

!

Make sure you can ping the FTP server from the ISR G2.

Configure the SRE management network

ESXi interfaces cannot be tied to the Gigabit Ethernet interfaces of the router. They can use SM<slot>/0, SM<slot>/1, or the external gigabit interface on the SRE blade. In this section we will configure the SRE management network (which will also be the network for ESXi) on SM4/0. After installing the SRE module, verify the following interfaces exist: SM<slot>/0 and SM<slot>/1. In our test setup we installed the SRE in slot 4, so we verify the presence of SM4/0 and SM4/1 using the “sh interfaces” command. In our test setup, we configured SM4/0 as an internal network for ESXi and VSH. SM4/0 will have 2 IP addresses: one for the router side of the SM interface, and one for the ESXi side.

gi0/3: mgmt

10.32.146.196

Windows 2008R2E

Cisco 3945 ISR G2

mgmt:

10.32.146.217

sm 4/0 (internal)

ESXi

10.1.20.1

SRE

SRE External Interface

vmnic1 10.1.20.2

Figure 3 – Management IP address configuration for ftp access, adding SM interface



Router configuration: interface SM4/0

ip address 10.1.20.1 255.255.255.0

service-module ip address 10.1.20.2 255.255.255.0

service-module ip default-gateway 10.1.20.1

!

Prepare the ftp server with the SRE-V image

Obtain the SRE-V image

SRE images and release notes can be found at http://developer.cisco.com/web/srev/docs . Note that there are different images for 700/710 modules and the 900/910 modules. The SRE-V image is Cisco prepared version of ESXi. You must use the Cisco version of ESXi on the SRE. Add the SRE-V files to the ftp server

Extract the contents of this file into a directory of an ftp server that the SRE can access with known ftp user credentials. Note: Do not use the Windows ftp service. Instead, use a third party ftp server such as FileZilla. The FTP server on Windows Server 2008R2 does not support extended passive mode used by the SRE to obtain the image files. In our test setup, on the Windows 2008R2 Server used for management, we created a user named share with password share, and configured that user to access C:\share. In C:\share we extracted the contents of the SRE-V image file into the C:\share directory.

Figure 4 – Configuration of user account with root directory that contains the extracted SRE-V image files

Install the SRE-V infrastructure software

Router# service-module sm <slot>/0 install url <ftp://username:password@ server IP address/path to

http://developer.cisco.com/web/srev/docs



pkg file name>

In our test setup, we install the SRE-V infrastructure software on SM4/0 via Router# service-module sm 4/0 install url ftp://share:[email protected]/sre-v-k9-

r.SPA.smv.1.5.1.pkg

Note 1: We hot-plugged a SRE900 module into a 3945-E chassis. After running the install command, the prompt would hang for a few minutes then return. We had to power-cycle the whole chassis to have a successful install. Remember, the installation is done from the router, not from within an SRE console session. The installation process will refer to the pkg file, which will refer it to other files in the same FTP directory. This directory can be the FTP root directory or any subdirectory. The only requirement here is that all of the files from the distribution should be extracted into the same directory. You will have to answer a few questions during the install. The most important one is (on the 900 and 910) decide whether to configure the disks as no raid, RAID0, or RAID1. More on this decision when we discuss performance. If you have any problems during the installation, you can enable logging via:

Router#debug sre-install all

You can send the debug information to log via:

Router#Conf t

Router(config)#logging buffered debugging

Then view the current log via:

Router#show logging

Validate the installation of the SRE-V infrastructure software

Issue the service-module sm<slot>/0 status command and verify the service module is in Steady State with ESXi running. galvatron#service-module sm4/0 status

Service Module is Cisco SM4/0

Service Module supports session via TTY line 258

Service Module is in Steady state

Service Module heartbeat-reset is enabled

Getting status from the Service Module, please wait..

Cisco SRE-V Software 1.5.1.0

VMware ESXi 4.1.0 build-348481 running on SRE

Module resource information:

CPU Frequency: 1860 MHz

Memory Size: 8162 MB

Disk 0 Size: 500108 MB



No install/uninstall in progress

No local partition

galvatron#

With ESXi now running, you are ready to configure the management IP address for ESXi.



Configure Management Network on ESXi

You can enter the console of the SRE (now connected to ESXi) from the router via Router# service-module sm<slot>/0 session

The default login/password for logging into ESXi is root/<no password>.

During the SRE-V installation, vmnic1 is automatically assigned the same IP address as what was specified in the “service-

module ip address” command (see above). You should still log into the session/console to verify this was done. In the test setup we verified that vmnic1 was chosen for management and already assigned an IP address of 10.1.20.2. Note that in our test setup, 10.1.20.1 is the router side of the SM 4/0 interface. More information on the vmnicX interfaces (including why vmnic1 was selected in our test setup for ESXi management) can be found in the VSH/SRE Network Options section of this document. Once you have logged out of ESXi, close the session via CTRL+ALT+6 then x You will be returned to the router cli. However the session to the ESXi console is still open. To close the session, enter the following command: Router# service-module sm<slot>/0 session clear

In our test setup, we clear the session via: galvatron#service-module sm4/0 session clear │

[confirm] <Press enter here>

[OK]

galvatron#

Install and Configure VSH on ESXi

With ESXi operational, you can now connect VMware vSphere to ESXi and install and configure VSH. Please refer to the documentation on the Riverbed Support Site at https://support.riverbed.com/docs/appliance.htm . In our test setup, the VMware vSphere® has been installed on the Windows 2008R2 Server test machine. In order for the Win2008R2machine to reach the 10.1.20 network inside the sm4/0 interface, a static route needed to be defined on the Windows Server 2008R2 machine via: C:\windows> route ADD 10.1.20.0 MASK 255.255.255.0 10.32.146.196

This allows the Windows 2008R2 Server machine to reach the internal network on the SM interface via the management interface of the router (10.32.146.196 on gi0/3).

Vmnic Interface Map

Before we discuss virtual interfaces on VSH, we need to first understand what vmnics refer to which entities on the SRE.




The following table maps ESXi vmnics to entities on the router:

vmnic mapping

vmnic0 External interface on the SRE module, not related to anything internal on the router.

vmnic1 Internal management, tied to interface sm<slot>/0. Due to router load, not recommended for optimization, but ok for primary/aux management.

vmnic2 Internal Multi-Gigabit Fabric (mgf) interface, tied to interface sm<SLOT>/1, can be trunked for vlans on the router.

Table 1 – ESXi vmnic to router/SRE interface mapping

Map ESXi Network Interfaces to VSH

In our test setup, we will map vmnic0 (see the Vmnic Interface Map section for a description of the various vmnics) to the WAN interface on VSH. vmnic0 is the external network interface on the SRE. Note that the external interface has no internal connectivity to the rest of the router. The VSH and gi0/2 will be on a separate network (192.168.4.0). On a new SRE-V installation, vmnic0 will not be assigned to a network. Via VMware vSphere, create a new vSwitch2 and assign vmnic0 to it. Then when adding the VSH VM, you can assign the WAN interface to vmnic0, via a network we will name as “SRE-External”. Also by default, vmnic1 is not assigned. We will create a new vSwitch for vmnic1 so that we can assign it to the Primary interface of the VSH. This new network will be called “mgmt”. In our test setup, we will create the appropriate vSwitch/vmnic mappings prior to importing the VSH VM:

Figure 5 – ESXi network configuration after having added vSwitch2 (mapped to vmnic0/SRE external interface) and a mgmt. network for vmnic1.



We created the mgmt network because the default Managememt Network cannot be mapped to a VSH interface. We can now import the VSH VM/OVA and are able to map the WAN to the SRE-External Interface/vmnic0 and the Primary interface to mgmt/vmnic1.

Figure 6 – Network mapping step during VSH OVA import Even though we are not using the LAN and Aux interface in our test setup, there is currently no way to have VSH interface not assigned to any network. In this case just ignore the warning message. Our test router has 4 Gigabit Ethernet interfaces. gi0/3 is connected to a separate management network, gi0/0 and gi0/1 will each handle LAN and WAN traffic, respectively. We will use the remaining gi0/2 interface as a dedicated interface to connect to the VSH. To do this, we connect a network cable between gi0/2 and the external interface on the SRE. Our new network diagram looks like this:



gi0/2192.168.4.1wccp router

gi0/3: mgmt

10.32.146.196

Windows 2008R2E

Cisco 3945 ISR G2

mgmt:

10.32.146.217

sm 4/0 (internal)

ESXi

10.1.20.1

SRE


vmnic1 10.1.20.2

VSH

vmnic0wan0_0192.168.4.10wccp client

primary10.1.20.3

Figure 7 – Adding the WAN and Primary interfaces of VSH to the network topology

Router configuration: interface GigabitEthernet0/2

ip address 192.168.4.1 255.255.255.0

duplex auto

speed auto

!

On the VSH, configure the IP addresses and appropriate gateway IP addresses for the Primary and WAN interfaces. Follow the VSH deployment guide instructions on licensing and ESXi resource allocation for your desired VSH model.



VSH/SRE Network Options Note: This documentation is not intended to be a primer on WCCP. It merely lists some practical examples. For a primer on WCCP for Riverbed Steelheads, refer to the Riverbed Deployment Guide on the Riverbed Support Site at https://support.riverbed.com/docs/appliance.htm

WCCP Using External SRE interface

There are a few ways to configure redirection of user traffic to VSH for optimization. In our test setup, we have a 3945 with 4 Gigabit Ethernet interfaces, plus the external gigabit Ethernet interface on the SRE. We configure for the most liberal use of interfaces on the router: 2 for LAN/WAN traffic, 1 for management, 1 for a dedicated connection to the SRE external interface.


gi0/3: mgmt

10.32.146.196

Windows 2008R2E

Cisco 3945 ISR G2

mgmt:

10.32.146.217

sm 4/0 (internal)

ESXi

10.1.20.1

SRE


vmnic1 10.1.20.2

VSH

vmnic0/wan0_0192.168.4.10wccp client

primary10.1.20.3

Windows 7

test:

192.168.3.10

gi0/0192.168.3.201

LAN routerW

CCP in

gi0/1192.168.0.201

WAN router

WCCP

in

T1 WAN

Figure 8 – Adding the branch network to the VSH topology

Default branch routing to WAN

Let us begin by adding the basic routing needed for the branch to get out to the WAN. gi0/0 is our router LAN interface and gi0/1 is our WAN router interface. The LAN is a flat 192.168.3.0/24 network, and the WAN is a flat 192.168.0.0/24 network. Router configuration: interface GigabitEthernet0/0

ip address 192.168.3.201 255.255.255.0

duplex auto

speed auto




!

interface GigabitEthernet0/1

ip address 192.168.0.201 255.255.255.0

duplex auto

speed auto

!

On the windows machine, configure an IP address on the test network (192.168.3.0/24) and specify the gateway IP address (192.168.3.201). Verify from the Windows client that you can ping the gateway/LAN router interface and the WAN router interface. Basic WCCP configuration (Router)

Continue with the WCCP configuration on the router. We will redirect all traffic coming into the router LAN and WAN interfaces to the VSH/external interface on the SRE. The Steelhead will join WCCP group 61. The LAN and WAN interfaces will be configured to redirect traffic coming into those interfaces to WCCP group 61. Router configuration: ip cef

ip wccp 61

ip wccp 62


ip address 192.168.3.201 255.255.255.0

ip wccp 61 redirect in

duplex auto

speed auto

!


ip address 192.168.0.201 255.255.255.0


duplex auto

speed auto

!

Note that in this lab example, we’ve defined WCCP service group 62 but not used it. Since this is a single Steelhead environment, in this case having one WCCP service group used is ok, because regardless of the direction of traffic for the single used service group, there is only one WCCP client (Virtual Steelhead) to choose from. In our next example with multiple Steelheads, we will use multiple service groups to load balance to two Virtual Steelheads. Basic WCCP configuration (Steelhead)

For a Riverbed primer on WCCP, refer to the Riverbed Deployment Guide on the Riverbed Support Site at https://support.riverbed.com/docs/appliance.htm Here is a summary of basic WCCP configuration used in this environment: Configure > Networking > Simplified Routing: Collect Mappings From: None Configure > Networking > In-Path Interfaces: Set an IP address/default gateway for Inpath0_0 Configure > Optimization > General Service Settings: Enable In-Path Support, Enable L4/PBR/WCCP/Interceptor Support, Enable Optimizations on Interface inpath0_0 Configure > Networking > WCCP: Join appropriate WCCP service groups (a screenshot of this configuration can be seen in the dual VSH WCCP configuration further in this document) Verify you can see the Steelhead as a WCCP client on the router (show ip wccp 61 det). Verify optimization with a remote site. Here is our test setup incorporating a remote site:





gi0/3: mgmt

10.32.146.196

Windows 2008R2E

Cisco 3945 ISR G2

mgmt:

10.32.146.217

sm 4/0 (internal)

ESXi

10.1.20.1

SRE


vmnic1 10.1.20.2

VSH

vmnic0/wan0_0192.168.4.10wccp client

primary10.1.20.3

Windows 7

test:

192.168.3.10

gi0/0192.168.3.201

LAN routerW

CCP in

gi0/1192.168.0.201

WAN router

WCCP

in

SH1050Hinpath0_0:

192.168.0.105

Windows 2008R2E

test:

192.168.0.101

T1 WAN

Figure 9 – Adding a remote site to the topology

WCCP Using Internal MGF interface

In our next topology, we make these changes:

run 2 SREs (a model 910 and a model 900), each running VSH

configure the external interface on each for management of VSH instances

configure a VLAN with an IP address

configure the internal MGF interface (vmnic2) on each SRE as a trunk, map this interface to the VSH WAN interface, and configure WCCP with 2 service groups, for each of the two VSH instances

The following is a diagram of the new topology:



gi0/3: mgmt

10.32.146.196

Windows 2008R2E

Cisco 3945 ISR G2

mgmt:

10.32.146.217

sm 4/0 (internal)

ESXi

10.1.20.1

SRE


vmnic1 10.1.20.2

VSH

vmnic0/primary10.32.146.243

wan0_010.1.30.10

Windows 7

test:

192.168.3.10

gi0/0192.168.3.201

LAN router WCCP in

gi0/1192.168.0.201

WAN router

WCCP in

SH1050Hinpath0_0:

192.168.0.105

Windows 2008R2E

test:

192.168.0.101

T1 WAN

SRE

ESXi

VSH


vmnic0/primary10.32.146.244

wan0_010.1.30.11

sm 2/0 (internal)

vmnic1 10.1.40.2

10.1.40.1

vmnic2

vmnic2

sm 4/1 (internal, trunk)

sm 2/1 (internal, trunk)

VLAN110.1.30.1WCCP router

In this diagram, the red path represents a management network. We use one of the Gigabit ports on the router for management as well as the external interfaces on the SRE (to manage the Steelheads). Management of the ESXi instances is via the internal SRE interface and tied to the SMX/0 interface. This interface is not recommended for user data flow. The green path represents the network path for the customer. On the router, WCCP redirect commands have been applied to the lan and wan interfaces of the router, which are Gi0/0 and Gi0/1, respectively.



In this deployment, we SM X/1(mapped to vmnic2, on ESXi) is configured as a trunk to VLAN1. IP addresses cannot be tied to the SM X/1 interfaces. Each VSH WAN interface uses the IP address of VLAN1 as their gateway and WCCP router. Router Configuration

ip wccp 61

ip wccp 62

…


description $ETH-LAN$$ETH-SW-LAUNCH$$INTF-INFO-GE 0/0$$ES_LAN$

ip address 192.168.3.201 255.255.255.0


duplex auto

speed auto

!


ip address 192.168.0.201 255.255.255.0


duplex auto

speed auto

!

…


description mgmt

ip address 10.32.146.196 255.255.255.0

duplex auto

speed auto

!

…

interface SM2/0

ip address 10.1.40.1 255.255.255.0


!Application: VMware ESXi 4.1.0 build-348481 running on SRE


!

interface SM2/1

description Internal switch interface connected to Service Module

switchport mode trunk

no ip address

!

interface SM4/0

ip address 10.1.20.1 255.255.255.0


!Application: VMware ESXi 5.0.0 build-474610 running on SRE


!

interface SM4/1

description Internal switch interface connected to Service Module

switchport mode trunk

no ip address

!

interface Vlan1

ip address 10.1.30.1 255.255.255.0

ip wccp redirect exclude in

!

…



The following is the configuration for joining WCCP Service Groups 61 and 62, with 61 expanded:

When configuring WCCP for more than one VSH, make sure to configure Connection Forwarding on each VSH instance. This allows the Steelheads to communicate to make sure each Steelhead gets the proper amount of WCCP bucket allocation (for the Hash assignment scheme). On each VSH instance, go to Configure > Networking > Connection Forwarding, and add each other VSH inpath IP as a neighbor. Enable Connection Forwarding. Enable In-path Neighbor Failure.



The following is an example screenshot of Connection Forwarding UI on the SRE 900 configured with the VSH instance on the other SRE (910) as a Neighbor:

Other Redirection Options

Main options: WCCP, Policy Based Routing (PBR), Interceptor, or Server-Side Out of Path to Primary

“Router on a stick” – single router interface, using subinterfaces then applying a redirection method like WCCP

Active/Standby failover with 2 VSH instances: configure one VSH with a WCCP weight of 0. Remember, do not use the management network (vmnic1) for user traffic or optimization, to reduce router load.

Recommended VSH model and SRE combinations

Riverbed supports the following combinations of software and hardware for this solution:

Platform Disk Configuration RAM Maximum VSH

Model RiOS

SRE900/910 RAID1 8GB V1050H 7.0.0+, 6.5.4+

SRE900/910 RAID1 4GB V1050M 7.0.0+, 6.5.4+

SRE700/710 Single disk 4GB V250H 7.0.0+, 6.5.4+

SRE300 NOT SUPPORTED

300 model SRE: as this platform has no hard drive, this is platform is unsupported for VSH. 700/710 model SRE: (Core 2 solo CPU): as this platform has a single core CPU it only supports a V250L/M/H. This platform only has 4GB of RAM. 900/910 model SRE: (Core2 duo CPU): as this platform has a dual core CPU, the highest supported model is a V1050H. This



platform has 4 or 8GB of RAM. Since there is a RAM overhead for ESXi, 8GB is required to run the V1050H. Note that ESXi will allow you to configure a VM with more memory than the SRE physically has. For example, an SRE with 4GB of RAM will consume some of that RAM for ESXi itself. This leaves less than 4GB available for a V1050H VSH. However, ESXi will allow you to allocate 4GB to the VM. Doing this will allow the VM to run, and performance may seem good at first. But when VSH attempts to utilize all 4GB of RAM, there is likely to be performance issues as ESXi substitutes slower disk for solid-state RAM. For this reason, allocating more RAM to a VSH than the SRE has is a Riverbed unsupported configuration.

About Riverbed Riverbed delivers performance for the globally connected enterprise. With Riverbed, enterprises can successfully and intelligently implement strategic initiatives such as virtualization, consolidation, cloud computing, and disaster recovery without fear of compromising performance. By giving enterprises the platform they need to understand, optimize and consolidate their IT, Riverbed helps enterprises to build a fast, fluid and dynamic IT architecture that aligns with the business needs of the organization. Additional information about Riverbed (NASDAQ: RVBD) is available at www.riverbed.com. © 2012 Riverbed Technology. All rights reserved. Riverbed®, Cloud Steelhead®, Granite™, Interceptor®, RiOS®, Steelhead®, Think Fast®, Virtual Steelhead®, CSA®, Mazu®, Cascade®, Cascade Pilot™, Shark®, AirPcap®, Skipware®, TurboCap®, WinPcap®, Wireshark®, and Stingray™ are trademarks or registered trademarks of Riverbed Technology, Inc. in the United States and other countries. Riverbed and any Riverbed product or service name or logo used herein are trademarks of Riverbed Technology. All other trademarks used herein belong to their respective owners. The trademarks and logos displayed herein cannot be used without the prior written consent of Riverbed Technology or their respective owners. Cisco® is a registered trademark of Cisco Systems, Inc. and its affiliates in the United States and in other countries. Microsoft® is a registered trademark of Microsoft Corporation and its affiliates in the United States and in other countries. VMware® is a registered trademark of VMware, Inc. and its affiliates in the United States and in other countries.

Riverbed Technology, Inc. 199 Fremont Street San Francisco, CA 94105 Tel: (415) 247-8800 www.riverbed.com

Riverbed Technology Ltd. One Thames Valley Wokingham Road, Level 2 Bracknell. RG42 1NG United Kingdom Tel: +44 1344 31 7100

Riverbed Technology Pte. Ltd. 391A Orchard Road #22-06/10 Ngee Ann City Tower A Singapore 238873 Tel: +65 6508-7400

Riverbed Technology K.K. Shiba-Koen Plaza Building 9F 3-6-9, Shiba, Minato-ku Tokyo, Japan 105-0014 Tel: +81 3 5419 1990

http://www.riverbed.com/

Documents

Deployment Guide - VSH on Cisco SRE.pdf