Packeteer Deployment Topologies

(1)

Technical Guide

Packeteer Deployment Topologies

for PacketWise version 8.2

Packeteer, Inc.

Cupertino, CA 95014 408.873.4400

Packeteer, the Packeteer logo, combinations of Packeteer and the Packeteer logo, as well as PacketShaper, PacketShaper Xpress, PacketSeeker, PacketWise, PolicyCenter, ReportCenter, iShared, iShaper and SkyX are trademarks or registered trademarks of Packeteer, Inc. in the United States and other countries. Other product and company names used in this document are used for identification purposes only and may be trademarks of other companies and are the property of their respective owners. Copyright © 2002-2007 Packeteer, Inc. All rights reserved. No part of this publication may be reproduced, photocopied, stored on a retrieval system, transmitted, or translated into another language without the express written consent of Packeteer, Inc. Packeteer software is licensed, not sold, and its use is subject to the license terms set forth in the end user license agreement.

(2)

1 Packeteer Deployment Topologies

Getting the most from the least — it’s a common goal. It’s probably the reason you’re interested in ordering and using a PacketShaper, Packeteer’s application traffic management product. It helps you get the most from your network, bandwidth, and applications.

Getting the most from a PacketShaper depends on choosing the right deployment strategy for your topology and needs. That’s what this guide is all about: where, when, and what to deploy. It answers questions such as:

• What are the pros and cons of deploying one main-site PacketShaper?

• Should I put a PacketShaper with just the monitoring module at each of my branch sites? • Where do I put PacketShaper with respect to my firewall?

1.1 Supporting

Information

This guide is relevant after you decide you want PacketShapers but before you start unplugging and plugging cables to install them. Although the guide addresses you, the customer, it assumes that a Packeteer sales engineer or partner is working with you in deciding on an appropriate deployment strategy.

This guide does not include PacketShaper’s features, benefits, or usage instructions. Complete documentation is available in PacketGuide, a web-based resource containing all the details about how to use a PacketShaper. You can access the following documents in PacketGuide by clicking the

packetguide button in the products’ browser interface, browsing your PacketGuide CD, or by going

directly to http://support.packeteer.com/documentation/packetguide/8.2/documents/index.htm • Strategies for Managing Application Traffic Using Visibility, Control, and Compression to

Deliver Performance: Describes how Packeteer’s Application Traffic Management system

detects, addresses, and prevents application performance problems.

• Gaining Visibility: A conversational white paper describing Packeteer's visibility features. • Controlling Bandwidth and Performance: A technical paper that delves into Packeteer's control

features — protecting, containing, and pacing applications' access to bandwidth. • Quick Start Guide: A manual describing how to install and start using a PacketShaper. • LAN Expansion Module documentation: Short manuals containing all installation and usage

information for the LEM accessories.

• Fiber Bypass Switch documentation: A short manual with details on implementing port-bypass failover protection for a PacketShaper connected to a fiber optic network.

PacketGuide also includes a Configuration Limits table which allows you to check which PacketShaper model suits the needs of your deployment. This web page is available at

http://support.packeteer.com/documentation/packetguide/8.2/reference/boundaries.htm. In addition to the above resources, the Packeteer Best Practices sizing guide includes instructions for choosing the model of PacketShaper that best suits your needs. This document is available at

(4)

1.2 Document

Structure

Each covered topology has its own section that describes relevant topics. Some of the per-topology topics include:

Description: A short account of how we define the topology

Environmental Requirements: Aspects of your network, applications, traffic, number of

branches, or other items that impact your ability to choose this deployment topology

Reasons to Choose: Aspects of your network, applications, traffic, or other items that suggest you

should or could use this topology

Installation Considerations: Anything related to physical installation of a PacketShaper that is

different from the textbook installation procedures described in the Quick Start Guide

Capabilities: Product features that you can access with this topology

Limitations: Product features that you can’t access with this topology or disadvantages of using

this topology

Scaling Considerations: Factors to consider when choosing an appropriate model for purchase and

when determining how the topology will continue to work for you as your network and application needs grow

Configuration Suggestions: Ideas for organizing your traffic tree and policies. Check PacketGuide

for instructions on how to implement the suggestions. Keep in mind that the suggestions are exactly that – you should feel free to follow your own ideas and strategies.

Complementary Products: Other products that would enhance function or ease administrative

overhead

The topology sections are not necessarily mutually exclusive. For example, you might consult the sections for main-site Internet deployment as well as deployment with firewalls, if both are applicable to your own environment.

2 Setting the Stage

You can deploy PacketShaper comprehensively throughout many or all offices, or you can start more slowly and follow a phased deployment strategy starting with a main site first. Benefits vary with the product and locations you choose.

When you consider where you will place your PacketShaper units, also consider which features are required at each location.

Packeteer's monitoring module provides deep insight into application traffic, making it easy to

identify and measure all traffic types—mission-critical, recreational and miscellaneous. This module gives visibility into network and application behavior with analysis features including classification, utilization analysis, service-level management, efficiency analysis, thresholding and events, packet capture, diagnostic graphs, and reports.

The shaping module enables you to shape traffic, ensure Quality of Service (QoS) and provide

latency-sensitive, business-critical applications with the bandwidth they need to perform at their peak using flexible policy-based control. You can use this module to fix critical application

(5)

congestion, queuing latency and inefficiencies that hurt application response times between remote locations.

The compression module shrinks the size of transferred traffic, effectively increasing the amount

of bandwidth available on a link. You can enable/disable compression globally or for a specific tunnel. By integrating these technologies with the monitoring and shaping modules, PacketWise ensures that the increased virtual WAN pipe is not consumed by aggressive, non-mission critical applications that burst to consume any bandwidth given to them.

Packeteer’s acceleration module significantly improves the performance of TCP/IP over satellite

links or long-delay terrestrial networks. This module accelerates both transactions and file transfers to enhance network performance. Xpress acceleration allows you to maximize bandwidth

utilization, speed up application response times, accelerate the transfer of large files, and minimize the impact of other problems that are common with TCP-based applications on high-latency links.

Locations

The most common topological locations for a PacketShaper are:

• Main site’s WAN link: connects a main site to branches across a corporate WAN

• Main site’s Internet link: connects a main site to branches across VPN and/or is simply a link to the Internet

(6)

Choose between main-site deployments (shown above) and distributed deployments (shown below), or evolve from one to the other.

Installation

PacketShapers sit on the LAN side of Internet or WAN access links, analyzing and/or controlling all traffic as it passes. They integrate transparently with existing network infrastructure and impose no changes on router configuration, topologies, desktops, or servers. PacketShapers are available in a several different models with a variety of capacities.

A PacketShaper must be positioned so that it sees all traffic you intend it to manage. Packeteer’s LAN expansion module (LEM) facilitates deployment in locations with more than one LAN. Installation is easy and configuration consists of plugging in two cables and entering address and access information on a web-based setup page.

(7)

3 Main Site WAN Link Topology

3.1 Description

A main-site WAN-link topology has a PacketShaper only at main sites.

3.2 Environmental

Requirements

Network: To monitor and control performance most effectively from a centralized location, the

WAN should be a pure hub-and-spoke design. All branch traffic must go through the main-site PacketShaper, and there should be no branch-to-branch traffic, which in this topology can reduce PacketShaper’s ability to calculate utilization for each link. Sometimes, the only way to determine that this is your exact network topology is to deploy a PacketShaper with the monitoring module at a branch to check for traffic that doesn’t head to or come from the main site. For example, many supposedly hub-and-spoke IP/Frame Relay hybrid networks are actually meshed networks where routing occurs inside a service provider’s network.

Pure hub-and-spoke design is not necessary if you plan to manage only the main site’s WAN link and not to manage branch offices’ WAN connections. The more of the branch offices’ traffic your PacketShaper can see, the more effective it can be.

PacketShaper’s Xpress compression and acceleration modules require units on both sides of compression tunnels, so a main-site only deployment strategy does not offer compression or acceleration capabilities.

Applications: Application and Intranet servers must be at the main site’s data center. Each branch

must access the Internet through: • The main site, or

• A totally separate Internet connection that doesn’t use the same last-mile connection to the WAN

(8)

3.3 Reasons to Choose

Customers with networks that fit the environmental requirements choose this topology to: • Get visibility into network and application behavior before making further changes • Try the technology before making a larger investment

• Avoid or phase the costs that come with additional branch units • Deploy units gradually, as they are needed

3.4 Installation

Considerations

Most main site WAN link installations require the same procedures as described in the

PacketShaper Getting Started Guide. You plug the site router’s LAN port to PacketShaper’s

OUTSIDE port and plug the LAN to PacketShaper’s INSIDE port. Then you follow Guided Setup.

3.5 Limitations

The PacketShaper Xpress compression and acceleration modules require a PacketShaper at both sides of the WAN link, and will not function in a topology with only a single PacketShaper at the main site.

3.6 Complementary

Products

Although Packeteer’s ReportCenter is usually associated with a distributed deployment, it can be effective for this main-site option as well. ReportCenter’s usual role is to aggregate and correlate data from multiple units and create single reports for multiple locations. In this topology, you can use ReportCenter instead to create single reports for multiple locations, despite the fact that there is only one unit from which to collect data.

PolicyCenter isn’t necessary, as its benefits are realized only with multiple-unit deployments.

3.7 Traffic Tree Options

A traffic tree is the construct that organizes and categorizes your traffic. Different types of traffic trees organize traffic differently – for example, by location or by application or both. Your choice of a style of traffic tree dictates:

• How PacketShaper will analyze and control your traffic • Which modules and features are accessible to you • The configuration tasks you’ll need to do

• How many branches and/or applications your model will support

• How easy it is to add managed branches or applications to your network

Consult the descriptions of traffic tree options and their implications in Appendix A: Traffic Tree

Options. You are not limited to these trees, but they can provide insight into which options might be

(9)

4 Main Site Internet Link Topology

4.1 Description

A main-site Internet-link topology has a PacketShaper at the main site’s link to VPN-connected branches, dial-up VPN users, partner extranets, and/or simply the Web.

4.2 Environmental

Requirements

Network: No special requirements

Applications: Applications for VPN-connected branches must be hosted at main site servers.

4.3 Reasons to Choose

Customers choose this topology when their main site’s Internet link supports both critical and casual traffic, or just to find out what traffic is on their Internet link and how it behaves. Deployed in this topology, PacketShaper can protect VPN traffic, protect dial-up users, contain unsanctioned web traffic such as music downloads, pace multimedia for optimum performance, reveal top web destinations, and more.

4.4 Installation

Considerations

If you don’t use VPN, installation is the same as the procedures described in the Getting Started Guide. As usual, you plug the Internet router’s LAN port to the PacketShaper’s OUTSIDE port and plug the LAN to PacketShaper’s INSIDE port. Then you follow Guided Setup. If you use VPN, consult the Virtual Private Network Topology section that appears later in this document.

4.5 Capabilities

• PacketShaper’s web classification features are particularly handy for this Internet link topology, as web traffic can vary in urgency, sensitivity to latency, and performance requirements.

Classification based on travel direction, server location, mime type (XML, MPEG, and others), URLs, and other criteria help distinguish between casual browsing, business applications, customers’ online activities, and so on.

(10)

• A PacketShaper with the monitoring module offers all its monitoring and analysis features for all traffic that passes through the unit.

For example, you can see how much of your Internet link goes to VPN branches and how much goes to casual browsing.

• A PacketShaper with both the monitoring and the shaping modules offers all its control features on all traffic that passes through the unit.

For example, you can allocate a third of your link to the branch VPN traffic or to your partners’ extranet. Give each VPN user an appropriate minimum and maximum. Allocate a steady rate to multimedia streams. Block unsanctioned traffic such as music downloads or web sites with questionable content.

4.6 Limitations

An Internet link unit at only the main site does not aid performance at other branches with their own Internet links. It also does not aid performance for WAN traffic that uses a different link and

network. The PacketShaper compression and acceleration modules require PacketShapers at both sides of the WAN link, and will not function in a topology with only a single PacketShaper.

4.7 Configuration

Suggestions

If you do not manage traffic to multiple branches on your Internet link, use a traffic tree that is based upon network applications, rather than branch locations or subnet. Automatic traffic discovery and classification are a good basis for the traffic classes, but you can also add or tailor classes based on other criteria. It’s a simple tree to create and use, managing traffic according to type of traffic (such as application) rather than according to destination or location. Suggestions include:

• Customize an application-based tree with some of the web classification criteria to differentiate customers versus partners versus employees versus any other group you want to protect or control separately.

• Create a folder for streaming media and move all streaming protocols underneath it. Assign rate policies with guaranteed, per-session bandwidth. Consult PacketGuide’s Recommendations for instructions.

• Create a folder called Unsanctioned or Undesirable or any other name that suits. Move any traffic classes that you would like to block (or at least contain to small amounts of bandwidth) to the folder. Then assign a policy to limit or block the traffic. Consult PacketGuide’s

Recommendations for instructions.

• If you use VPN, create a folder class to handle all VPN traffic types. Then assign a carefully sized partition to protect your VPN traffic. Use a dynamic subpartition on a VPN class if you want to provision bandwidth for each dial-up user.

• If you do manage multiple branches’ traffic on your main site’s Internet link, consult the VPN topology section later in this document.

(11)

4.8 Scaling

Considerations

The PacketShaper model for a main site’s Internet link needs to accommodate the link’s capacity, anticipated maximum number of concurrent flows, and anticipated number of users. Although most PacketShapers deployed in this topology use a traffic tree that is based primarily upon the

applications running on the network, if you choose to create a traffic tree based upon branch office or subnet locations, the PacketShaper needs to accommodate the number of traffic classes and matching rules required for the tree. Consult the Configuration Limits table in PacketGuide to check which model suits your tree’s needs, or refer to the Packeteer Best Practices sizing guide.

4.9 Complementary

Products

Although Packeteer ReportCenter is usually associated with a distributed deployment, it can be effective for this main-site Internet link option when you manage multiple sites over VPN. ReportCenter’s usual role is to aggregate and correlate data from multiple units and create single reports for multiple locations. In this topology, you can use ReportCenter instead to create single reports for multiple locations, despite the fact that there is may be only one unit from which to collect data. By expanding your deployment to include multiple PacketShapers, each with a separate ReportCenter data collector, you can easily create customized data polling schedules, minimizing the impact of network data reporting for individual customers. For additional information, refer to the ReportCenter Administrator’s Guide, available online at

http://support.packeteer.com/documentation.

PolicyCenter isn’t necessary for a single-unit deployment, as its benefits are realized only with multiple-unit deployments.

(12)

5 Distributed Branch Topology

5.1 Description

A distributed topology has a PacketShaper at each main and remote site. It is the most powerful and flexible topology. In addition, it is the topology of choice for Packeteer’s Xpress compression and acceleration features.

5.2 Environmental

Requirements

Network: No token ring networks. No other special requirements. Applications: Any main site or branch can host applications.

Number of branches: No specific limit. Ten to several hundred branches are typical. The greater

the number of branches, the more Packeteer’s centralized-management products reduce the cost and overhead involved in a distributed solution.

5.3 Reasons to Choose

Customers choose this topology because it is the most powerful and flexible, it scales well, and they can squeeze more branch-to-branch traffic through a limited-capacity WAN with compression. Specific characteristics that indicate a distributed deployment is best include:

• Many branches need management

• A meshed network design (traffic doesn’t pass through a main site)

• Branch-to-branch traffic (VoIP, shared folders, collaboration tools, and so on) • Independent Internet links at branches (not dependent on a main site’s Internet link) • Applications hosted on servers at branches

(13)

• Small branches must access centralized applications through very constrained links

• Connectionless applications that must be contained. PacketShaper’s TCP Rate Control can contain TCP traffic in both directions, but UDP and legacy flows require PacketShaper on both sides of a connection for optimal management of inbound flows.

5.4 Installation

Considerations

Most installations require the same procedures as described in the Getting Started Guide. You plug the site router’s LAN port to PacketShaper’s OUTSIDE port and plug the LAN to PacketShaper’s INSIDE port. Then you follow Guided Setup.

5.5 Capabilities

• A PacketShaper with the monitoring module offers all its monitoring and analysis features, including classification, utilization analysis, service-level management, efficiency analysis, thresholding and events, packet capture, diagnostic graphs, and reports.

• A PacketShaper with the monitoring and shaping modules provide additional control features, including those to protect, contain, pace, and provision bandwidth, provide TCP Rate Control, mark packets, and suppress DoS attacks.

• The compression module shrinks the size of transferred traffic, effectively increasing the amount of bandwidth available on a link. When a PacketShaper combines the compression module with the monitoring and shaping modules, it ensures that the increased virtual WAN pipe is not consumed by aggressive, non-mission critical applications that burst to consume any bandwidth given to them.

• The acceleration module significantly improves the performance of TCP/IP over satellite links or long-delay terrestrial networks by accelerating both transactions and file transfers to enhance network performance.

5.6 Limitations

Purchase of multiple units is required. PolicyCenter and/or ReportCenter add initial cost but reduce cost of ownership through management ease and time savings.

5.7 Scaling

Considerations

This topology is most suited and adaptable to large or growing networks.

Each branch needs the PacketShaper model that matches its WAN access-link capacity. Consult the

Configuration Limits table in PacketGuide or the Packeteer Best Practices sizing guide to check

which model suits each branch’s needs. If plan on using the Xpress compression module, be sure to note the alternate WAN link capacities in the table in the appendix.

Each branch where you want the benefits of compression and acceleration technology needs to have an PacketShaper enabled with the compression and acceleration modules. Don’t forget that if you want any branch to have compression and/or acceleration, your main site unit must have these modules as well.

(14)

The type of traffic tree you choose for a main site impacts the model you select. Choices for your traffic tree and implications are discussed in Appendix A: Traffic Tree Options. The model for a main site needs to accommodate the link’s capacity, the anticipated maximum number of concurrent flows, and the anticipated number of users. If you choose a location-based tree for the main site, the model needs to accommodate the number of traffic classes and matching rules required for each remote site in the tree.

5.8 Configuration

Suggestions

No special configuration tasks are required for PacketShaper Xpress compression and acceleration features. Just enable compression and/or acceleration on all units with those modules, and they will automatically attend to compression and acceleration tunnels and other configuration details.

Branch

For each branch office, use an application-based tree. Assign partitions and policies to each application that needs protection or that undermines other applications’ performance. Consult

Policy and Partition Guidelines in PacketGuide for suggestions on specific applications and Control Strategy Overview for more high-level advice.

Main Site

For the main site or sites, use either a simple location-based tree (to control only the total bandwidth going to each location), or a location-based tree with per-location applications (to control each application for each location separately).

Using a simple location-based tree:

Assign a static partition to each location with a size equal to the branch’s capacity, and leave it to the branches’ PacketShapers to manage individual applications.

If using a location-based tree with per-location applications:

If branches’ application traffic goes through the main site, give each branch office a static partition with the proper minimum/maximum sizes corresponding to the branch WAN-link capacity (CIR or port speed). Then, for each branch’s applications, assign partitions and policies that correspond to those you assigned at the branch office’s unit. UDP traffic benefits most from having policies at both ends. TCP Rate Control on your branch PacketShapers manages both inbound and outbound rates for your TCP-based traffic classes.

5.9 Complementary

Products

We recommend Packeteer PolicyCenter for deployments with more than 10 PacketShapers to ease distribution of definitions for new or updated applications, events, policies and partitions, plugins, and software upgrades.

We recommend Packeteer ReportCenter to aggregate and correlate data for multiple PacketShapers and generate corresponding reports. A typical ReportCenter server with one local collection agent polling data from multiple units can report data for up to 8,000 traffic classes. Deploying additional ReportCenter data collection agents on separate servers greatly increases ReportCenter’s capacity for data polling and reporting within larger distributed-branch deployments.

(15)

• Two remote collection agents can support deployments with 20,000-40,000 traffic classes. • Three remote collection agents can support deployments with 40,000-50,000 traffic classes. Separate ReportCenter data collectors can also ease the network impact of data collection by polling their units on different schedules. For additional information, refer to the ReportCenter

(16)

6 Topologies with Multiple LANs

6.1 Description

This topology includes any environment with multiple LANs connected to one or more routers attached to WAN or Internet links. Up to three LANs and three routers can be directly connected to a single PacketShaper.

All traffic using any portion of access-link bandwidth should be managed together with a cohesive strategy. It is not effective to enforce policy-based bandwidth allocation on one portion of a router’s traffic, if uncontrolled traffic from an additional LAN can swamp the router’s capacity and

undermine any potential performance gains. Packeteer’s LAN Expansion Modules (LEMs) extend PacketShaper benefits to organizations with multiple LANs without the need for extra switches or appliances to aggregate traffic. The PacketShaper 1400 does not support a LAN Expansion Module, but has two additional built-in ports that can act as a “backup LEM”, routing traffic through a secondary WAN connection in the event of a primary WAN failure.

6.2 Installation

Considerations

Packeteer offers three different LEM models. Select the appropriate LEMs for your link type. • 100 Megabit LEMs for 10/100BaseT links

• Gigabit LEMs for 10/100/1000BaseT links

• Fiber-Optic Gigabit LEMs for 1000Base-SX or 1000Base-LX links

Installation procedures vary by model of PacketShaper and LEM type. Each LEM includes documentation describing how to install the LEM into each model of PacketShaper that supports that LEM type.

• Connect LAN1’s port on a site router to the PacketShaper’s built-in (non-LEM) OUTSIDE port. Then connect LAN1 to the PacketShaper’s built-in INSIDE port.

• Install one LEM for each additional LAN (second or third) in the open expansion slots located on the front or side of certain models of PacketShapers. See the Configuration Limits table in PacketGuide to see which PacketShapers support each model of LEM. Each module offers two more ports — one for a cable to a

site router and one for a cable to the additional LAN. _{Installing a Gigabit}

(17)

• Connect LAN2’s port on a site router to one of the PacketShaper’s LEM OUTSIDE ports. Then connect LAN2 to the same LEM’s INSIDE port.

• Connect LAN3’s port on a site router to the last LEM’s OUTSIDE port. Then connect LAN3 to the same LEM’s INSIDE port.

6.3 Capabilities

• A PacketShaper with the monitoring module offers all its monitoring and analysis features for all traffic on all LEM ports.

• A PacketShaper with both the monitoring and shaping modules offers all its control features for all traffic on all LEM ports.

• Although multimode (SX) transceivers are included with the newer model Fiber-Optic Gigabit LEMs, due to the interchangeable nature of an SFP transceiver, it is possible to remove existing transceivers and install into the LEM any supported SFP transceiver appropriate for your type of network link.

• The newer model Fiber-Optic Gigabit LEMs also allow you to implement a port bypass for the LAN by adding a fiber bypass switch. The Packeteer Fiber Bypass Switch is available with single-mode ports or multimode ports for use with either SX or LX fiber links.

6.4 Topology Examples with Multiple LEMs

Each of the example topologies uses the following legend:

Example 1: In this topology, three LANs are attached to a single switch which is connected to the INSIDE ports on the main, upper and lower LEMs on the PacketShaper. All OUTSIDE ports are connected to a single site router.

(18)

Example 2: In this example, the three LANs switches are connected to the INSIDE ports on the main, upper and lower LEMs on the PacketShaper. Each OUTSIDE port is connected to a corresponding WAN.

Example 3: The additional built-in ports on a PacketShaper 1400 (BACKUP INSIDE and BACKUP OUTSIDE) can act as a backup LEM for a single LAN. In this example, traffic will be routed through the Internet VPN link if the Frame Relay WAN loses connectivity*.

*The PacketShaper 1400 provides pass-through failover only on the INSIDE and OUTSIDE ports. If the

PacketShaper is turned off or disabled, traffic will not pass through the BACKUP INSIDE and BACKUP OUTSIDE ports.

6.5 Limitations

Up to three LANs can be accommodated on a single PacketShaper.

6.6 Configuration

Suggestions

For the topology shown in example 1, you can separate statistics and control strategies for each LAN by defining subnet- or IP address-based traffic classes for those LANs and then configuring a static partition for each class. For the topology shown in example 2, you can classify traffic by LEM (main, upper or lower) to segregate LAN traffic in the tree. For either topology, the remainder of your management strategy is not impacted by the presence or absence of multiple LANs.

(19)

6.7 Scaling

Considerations

Choose a model based on total WAN-link capacity, not the needs of one particular LAN. Be sure to verify if the model that suits your capacity needs supports your desired LEM. Consult the

Configuration Limits table in PacketGuide, or the LEM datasheet.

If you have more than three LANs sharing a single WAN or Internet connection, consider connecting the PacketShaper to uplink ports on a switch. Consult your Packeteer engineer or reseller to determine the best configuration.

6.8 Complementary

Products

The Packeteer Fiber Bypass Switch is an external device that provides physical layer bypass protection around a PacketShaper. The bypass switch connects the LAN devices, preventing the PacketShaper from interrupting network access when the unit is not powered on or is in bypass mode. See the Fiber Bypass Switch Installation Guide for details on connecting a Fiber Bypass Switch to a Fiber-Optic LEM.

(20)

7 Virtual Private Network Topology

7.1 Description

A virtual private network (VPN) is a private data network that uses the public telecommunication infrastructure to extend a WAN from a main site to branch offices or dial-up users. Encryption and security procedures keep data private. A VPN enables companies to share distributed data and applications without the expense of dedicated leased lines, frame relay, or private lines. Although the Internet can serve as an economical WAN alternative, your enthusiasm for this solution can wane if you are faced with unpredictable performance for mission-critical applications traversing the VPN. To add to this problem, most monitoring tools aren’t able to portray VPNs’ encrypted traffic with any detail. A PacketShaper with both the monitoring and shaping modules assists both issues and PacketShaper with just the monitoring module can help in the latter.

7.2 Environmental

Requirements

There are no special requirements.

7.3 Reasons to Choose

Customers choose this topology to protect the performance of applications on a VPN.

7.4 Installation

Considerations

You can choose to install a PacketShaper on either side of your VPN gateway. Its position with respect to the VPN gateway dictates whether it will classify applications before or after encryption, and whether it can support Packeteer’s Xpress compression module. The two deployment

(21)

Example 1

Put the PacketShaper between the router and the VPN gateway if you do not want the Xpress

compression module, but do want a quick and easy way to spot all encrypted VPN traffic in order to protect it. In this example, you plug the Internet router’s LAN port to the PacketShaper’s OUTSIDE port and plug the VPN gateway to the PacketShaper’s INSIDE port.

Example 2

Put the PacketShaper on the inside of the VPN gateway if you want it to differentiate between multiple encrypted applications, or you want to enable Packeteer’s Xpress compression and/or acceleration modules. A PacketShaper in this location can use the compression module only if the VPN allows RSVP and IPCOMP traffic, and if the VPN does not use NAT. You plug in the VPN gateway’s LAN port to the PacketShaper’s OUTSIDE port and plug the LAN to the PacketShaper’s INSIDE port.

7.5 Capabilities

• If you place the PacketShaper between the VPN gateway and the site router, it sees both encrypted VPN traffic and normal web traffic or other applications. It classifies VPN traffic according to encrypted protocol and does not see which applications are encrypted. It

automatically differentiates many types of secure traffic including IPSec (AH, ESP), PPTP, L2TP, DLS, DLA, SSL, SSH, RADIUS, GRE, IKE, SSL, ISAKMP, and SOCKS.

• A PacketShaper can utilize the monitoring module to monitor and analyze for the traffic that passes through it.

For example, you can see how much of your link goes to each VPN-connected branch.

• A PacketShaper that has both the monitoring module and the shaping module offers additional control features.

For example, you can allocate a set amount or percentage of your link to each branch and a per-user amount of bandwidth for each dial-up per-user.

(22)

7.6 Configuration

Considerations

• If you installed PacketShaper so it can only see encrypted traffic, then use a simple location-based tree (consult Appendix A: Traffic Tree Options for details on this tree type). Assign a partition to each location matching the capacity of the branch.

• If you installed PacketShaper so it sees traffic before it is encrypted, create a location-based tree with per-location applications (consult Appendix A: Traffic Tree Options for details on this tree type). Then manage each application at each location separately with appropriate policies and partitions.

7.7 Scaling

Considerations

The product model for a VPN needs to accommodate the link’s capacity, anticipated maximum number of concurrent flows, and the number of traffic classes and matching rules required for the location-based tree. Consult the Configuration Limits table in PacketGuide or the Packeteer Best Practices sizing guide to check which model suits your tree’s needs.

7.8 Complementary

Products

Although Packeteer ReportCenter is usually associated with a distributed deployment, it can be very handy for a VPN when managing multiple branch offices. ReportCenter’s usual role is to aggregate and correlate data from multiple units and create single reports for multiple locations. In this

topology, you can use ReportCenter instead to create single reports for multiple locations, despite the fact that there is only one unit from which to collect data.

PolicyCenter is appropriate if you have PacketShapers installed at the main site and branch offices.

(23)

8 Topologies with Firewalls

8.1 Description

This topology includes any environment with both a firewall and a PacketShaper.

8.2 Installation

Considerations

The issues for this topology center around installation and cabling of the router, firewall, and a PacketShaper. The additions of NAT (network address translation) and/or a DMZ (publicly available content, not protected by the firewall) require consideration.

Placing a PacketShaper between the firewall and the protected LAN results in the most function and least confusion. If you have NAT, PacketShapers deal only with internal IP addresses. If your firewall is a termination point for VPN tunnels, then they see only unencrypted traffic. With the PacketShaper between the firewall and unprotected LAN, you get full application-intelligent classification features and the ability to control individual types of traffic (instead of just one large mass of IPSec traffic). If you use the Top Listeners feature, then you get a meaningful list of the top consumers of any traffic class with their real, internal IP addresses.

It is possible to deploy PacketShaper between the router and the firewall, but it is not recommended. PacketShaper would see only NAT configured addresses; all candidates for the Top Talkers list and Top Listeners would appear to be just one address, and VPN classification and control would be very coarse.

With no DMZ:

1. Plug the site router’s LAN port to the firewall.

2. Connect the firewall’s LAN port to PacketShaper’s OUTSIDE port. 3. Connect the protected LAN to PacketShaper’s INSIDE port.

With a DMZ:

1. Install a LEM (LAN Expansion Module) into PacketShaper. It will handle the traffic to and from the DMZ.

(24)

3. Connect the firewall’s port for all DMZ traffic to the LEM’s OUTSIDE port. 4. Connect the LEM’s INSIDE port to the DMZ LAN.

5. Connect the firewall’s port for the protected LAN traffic to PacketShaper’s OUTSIDE port. 6. Connect the protected LAN to PacketShaper’s INSIDE port.

8.3 Capabilities

• A PacketShaper with the monitoring module offers all its monitoring and analysis features with no NAT, and all but one (either Top Talkers or Top Listeners) with NAT.

• A PacketShaper with the monitoring and shaping modules offers additional control features on all traffic that passes. For example, you can allocate one third of your link to the DMZ. If the DMZ is not in use, its bandwidth will be loaned to others.

8.4 Limitations

With NAT, neither Top Talkers nor Top Listeners is useful (see Installation Considerations, above).

8.5 Configuration

Suggestions

• Define a static partition for DMZ traffic to protect it in case the protected LAN swells. • Manage the protected LAN as usual. See PacketGuide’s Control Strategy Overview for help.

8.6 Scaling

Considerations

The presence or absence of a firewall does not impact the choice of a model or ability to accommodate growth. If a unit is going on a main site’s link, consult Appendix A: Traffic Tree

Options to choose an appropriate traffic tree configuration for your needs. Then, no matter where a

unit is being deployed, consult the Configuration Limits table in PacketGuide or the Packeteer Best Practices sizing guide to select a model.

8.7 Complementary

Products

The decision to add PolicyCenter and ReportCenter lies in the number of units you deploy rather than the presence or absence of firewalls.

(25)

9 Direct

Standby

9.1 Description

Packeteer’s direct standby function allows a PacketShaper to integrate smoothly into a variety of redundant network topologies — those with redundant routers, redundant switches, two data paths, two LANs, and/or redundant firewalls.

Two PacketShapers each connect to a different router. Both units are considered active, and each unit can receive and forward traffic. To ensure that both units accumulate the same traffic tree and measurement data, each unit processes the packets received by the other. When a unit receives traffic directly, it copies that traffic and transmits it to the other unit. The other unit classifies the traffic, just as if it had received it directly, but does not forward the traffic onto the LAN.

9.2 Installation Considerations

You directly connect PacketShapers via a LEM. If two LEMs are present, you must use the

upper-most or right-upper-most LEM for the direct connection between PacketShapers. Complete instructions

and information are available in the Getting Started Guide.

When you connect a PacketShaper in a redundant topology, you can access and manage the unit from any of the LAN-connected ports. If desired, the INSIDE port on the direct-standby LEM can be connected to a management network. Note, however, that when this port is connected, it becomes the exclusive management port for the unit; you will not be able to access the unit from the other ports.

On PacketShaper 3500 and 7500 models, you can connect to a management network via the MGMT port. This connection would provide a secondary way to access the unit. If you enable the

Dedicated Management Port option, you would be able to access the unit through this port only. If

both the MGMT port and the INSIDE port on the direct standby LEM are connected, the MGMT port takes precedence.

(26)

Some installation considerations include:

• Both units must have the same configuration limits and installed memory. You should not mix units with different capacities since the units will be passing the same traffic and require identical configurations.

• The direct connection between the two units must be equal to or greater in speed than each of the WAN links. This requirement ensures that each unit receives copies from the other unit fast enough to prevent out-of-order packets.

• The bypass relays in both units and all LEMs must be disabled. Normally, when a PacketShaper goes down or is unplugged, a bypass relay closes to allow traffic to pass. But this normally advantageous feature becomes a problem in any standby mode. You don’t want the backup and failed units both forwarding duplicate sets of traffic. Therefore, you must disable the bypass relay feature.

• Because the bypass relays are disabled, the units should not be powered off when they sit in a direct standby configuration — doing so causes loss of connectivity on that link and all traffic is routed to the other path.

To make the PacketShaper function in these types of topologies, you connect each unit to each redundant network path as well as directly connect the two units. In addition, you need to make sure you can still access each unit if a router or switch goes down with a redundant management path from the unit to the switch on the parallel path.

So, in summary, there are connections between the pair of PacketShapers, between each

PacketShaper and each redundant switch, and between each PacketShaper and its own side’s router. The topology drawings in section 10.2.1 detail connections in several topologies. For more, see the

PacketShaper Getting Started Guide.

9.2.1 Topology Examples

Each of the example topologies uses the following legend: Example 1: This basic redundant router topology uses a single LEM to connect the redundant PacketShapers:

(27)

Example 1, continued

With a PacketShaper 3500, 7500

This basic redundant router topology uses a single LEM to connect the redundant PacketShapers. On PacketShaper 3500 and 7500 units (shown above), the MGMT port can be connected to a management network to provide an alternate way to manage the unit. If you enable the Dedicated

Management Port option, you would be able to access the unit through this port only. With PacketShaper 1400

This basic redundant router topology uses the BACKUP OUTSIDE ports to connect the redundant PacketShapers.

(28)

With a PacketShaper 4500, 6500, 8500, 9500, 10000

This basic redundant router topology uses a single LEM to connect the redundant PacketShapers

Example 2:

(29)

This topology requires two LEMs. The left LEM is for the redundant data path and the right LEM is used to connect the PacketShapers directly. On PacketShaper 3500 and 7500 units (shown above), the MGMT port can be connected to a management network to provide an alternate way to manage the unit. If you enable the Dedicated Management Port option, you would be able to access the unit through this port only.

(30)

This topology requires two LEMs. The OUTSIDE port of the upper LEM is used to connect the PacketShapers directly.

Example 3:

(31)

The firewall shown in this topology can actually be any generic device that sits in this position. A single LEM is needed to connect the redundant PacketShapers. On PacketShaper 3500 and 7500 units (shown above), the MGMT port can be connected to a management network to provide an

alternate way to manage the unit. If you enable the Dedicated Management Port option, you would be able to access the unit through this port only.

With a PacketShaper 1400

The firewall shown in this topology can actually be any generic device that sits in this position. The BACKUP OUTSIDE port connects the redundant PacketShapers

(32)

The firewall shown in this topology can actually be any generic device that sits in this position. A single LEM is needed to connect the redundant PacketShapers.

Example 4

(33)

In this topology, there are routers on each side of each PacketShaper. On PacketShaper 3500 and 7500 units (shown above), the MGMT port can be connected to a management network to provide an alternate way to manage the unit. If you enable the Dedicated Management Port option, you would be able to access the unit through this port only.

(34)

9.3 Capabilities

• A PacketShaper with the monitoring module offers all its monitoring and analysis features, including classification, utilization analysis, service-level management, efficiency analysis, thresholding and events, packet capture, diagnostic graphs, and reports.

• A PacketShaper with the monitoring and shaping modules is able to protect, contain, pace, and provision bandwidth, and provide TCP Rate Control, mark packets, and suppress DoS attacks. See Limitations.

• With the compression module, a PacketShaper includes the above features, plus the ability dynamically set up data compression tunnels to other Xpress units. Direct standby can be enabled only when the Xpress unit is set to legacy tunnel mode; it cannot be enabled in migration or enhanced tunnel mode. Note that the acceleration module requires migration or enhanced tunnel mode, and cannot be used with a PacketShaper in a direct standby

configuration.

9.4 Limitations

Several features cannot be used with a direct standby topology, including: • Frame Relay

• ATM

• Xpress compression or acceleration features using Migration or Enhanced tunnel modes • watch mode

9.5 Configuration

Suggestions

As usual, protect critical applications, pace less urgent applications, and contain unsanctioned applications. See PacketGuide’s Control Strategy Overview for help.

9.6 Scaling

Considerations

Both units in direct-standby mode must be the same model and capacity. Keep in mind that each of the units is processing the traffic going to both routers and both WAN links. Therefore, assuming both links are active, each of the units needs to be a model that can process the amount of

throughput in both routers. For example, if you have two 45 Mbps links, each with its own router and each active, then each PacketShaper needs to be able to support 90 Mbps.

If the pair is going on a main site’s link, consult Appendix A: Traffic Tree Options to choose an appropriate traffic tree configuration for your needs. Then, no matter where a unit is being deployed, consult the Configuration Limits table in PacketGuide or the Packeteer Best Practices sizing guide to select a model.

9.7 Complementary

Products

The decision to add PolicyCenter and ReportCenter lies in the number of sites where you deploy rather than the use of direct standby.

(35)

10 Non-Inline Deployments (Watch Mode)

10.1 Description

Packeteer's watch mode is used to monitor traffic non-inline, where the PacketShaper is not cabled into the main data path. This type of deployment is best suited for enterprises that have strict change control procedures or security restrictions on the introduction of inline elements into the network. A PacketShaper configured in watch mode passively monitors the traffic on the network and performs all the traffic classification and reporting tasks that PacketShapers typically do, providing insight into what applications are being used on the network and highlighting performance issues. Because a PacketShaper in watch mode cannot perform traffic shaping, this feature is more often used on PacketShapers with just the monitoring module, rather than PacketShapers with both the monitoring and shaping modules.

Note: If the Dedicated Management Port feature is enabled on the PacketShaper 3500 or 7500

series, you will only be able to access the unit through the MGMT port; you cannot manage via any other port.

10.2 Reasons to Choose

A PacketShaper in watch mode can easily conduct network audits or managed application assessments while offering increased deployment flexibility in restricted or complex data center environments. The watch mode feature offers functionality similar to a network probe, but PacketShaper’s extensive monitoring capabilities can classify and record measurement data by application (layer 7), not just by port.

Another reason to deploy a non-inline unit in watch mode is to evaluate the Xpress compression module. With the addition of an evaluation compression module, a non-inline PacketShaper in watch mode gives you a simple way to project compression gains from PacketShaper’s Xpress option without deploying more than one unit. When a PacketShaper is deployed non-inline with compression and watch mode enabled, the PacketShaper will estimate the amount of compression that would have occurred on outbound data if the unit had been deployed inline. All the

compression statistics, graphs, and reports are accessible and reflect an estimation of compression benefits. To come up with these estimates, the compression module does not compress the live data; it compresses the packets in the outbound direction and then drops the compressed data.

(36)

10.3 Installation Considerations

A PacketShaper in watch mode works with any hub or switch; when connected to a switch, it should be connected to a SPAN port so that it has access to all the WAN traffic. If you want to monitor traffic sent by the switch to the router, you need to have the bidirectional traffic on the switch’s router port copied over to the SPAN port in order for the PacketShaper to receive and monitor it. Complete instructions and information are available in the PacketShaper Getting Started

Guide.

10.4 Watch Mode Topology Examples

Each of the example topologies uses the following legend:

Example 1: In this topology, a hub is connected to the OUTSIDE port on the PacketShaper and nothing is connected to the INSIDE port. Because the PacketShaper is connected to the hub, it monitors all traffic between the switch and the routers. The PacketShaper will be accessed and managed from the same LAN that is being monitored:

(37)

Example 2: In this topology, a PacketShaper monitors network traffic via a connection between its OUTSIDE port and a switch’s SPAN port. The INSIDE port, which is connected to the switch, is used for PacketShaper access and management, and must be connected to the appropriate LAN segment for PacketShaper access. Traffic received on the management port is not classified or measured.

Example 3: This topology is similar to Topology 2 in that PacketShaper’s OUTSIDE port is

connected to a switch’s SPAN port. In Topology 3, however, you can access PacketShaper from a PC on another LAN. On a PacketShaper 3500 or 7500, you can use the MGMT port to manage the unit from another LAN.

On the PacketShaper 1400, you can manage the unit from the BACKUP INSIDE port. Traffic received on the management port is not classified or measured

(38)

On other PacketShaper models, you can manage the unit from an INSIDE port on a LEM. Traffic received on the LEM management port is not classified or measured

Example 4: In this topology, PacketShaper monitors traffic on up to three different LAN segments. This is achieved by using two LEMs. The built-in OUTSIDE port is connected to a switch or hub on one LAN and the OUTSIDE ports on two LEMs are connected to two other LANs. On a

PacketShaper 3500 or 7500, you can use the MGMT port to manage the unit from another LAN.

(39)

On other PacketShaper models, you can manage the unit from any of the INSIDE ports (built-in or LEM)

Example 5: In this topology, the network to be monitored is connected to the OUTSIDE port on a LEM, or to the BACKUP OUTSIDE port of the PacketShaper 1400. The built-in INSIDE port is used for management access to the unit. This configuration is appropriate, for example, when a fiber-optic LEM is installed on a PacketShaper 6500 in order to monitor a fiber-optic network.

(40)

On a PacketShaper 1400, the network to be monitored is connected to the BACKUP OUTSIDE port. The INSIDE port is used for management access to the unit

On a PacketShaper 3500 or 7500, you can use the MGMT port to manage the unit from another LAN.

(41)

10.4.1 Additional Non-Inline Topology Examples

Unlike the previous topology examples, a non-inline deployment using a network tap does not require the PacketShaper to be in watch mode. In this topology, the PacketShaper is connected to the network through a tap. A network tap is a transmit-only hardware device, placed inline, that provides a permanent access port for passive network monitoring. When a PacketShaper is connected to a tap, it receives the same traffic as if it were located directly on the wire.

The PacketShaper’s INSIDE and OUTSIDE ports are connected to the tap — and watch mode is

not enabled. The tap will copy traffic in both inbound and outbound directions.

Since the tap does not pass traffic back to the network, you must use the MGMT port (on PacketShaper 1700, 3500, and 7500 models) to manage the unit

On the PacketShaper 1400, you must use one of the BACKUP ports to manage the PacketShaper. If you have set your site router to none (recommended), you can access the unit via the BACKUP INSIDE or BACKUP OUTSIDE port. The unit’s address can be on the same or different subnet from the subnet being monitored (where the tap is located).

If you have set a specific site router address, Packeteer recommends that you manage the PacketShaper via the BACKUP OUTSIDE port. In addition, the unit’s address, site router, and management port connection must be on the same subnet.

(42)

On other models, you must use a LEM port to manage the PacketShaper.

If you have set your site router to none, you can access the unit via the INSIDE or OUTSIDE LEM port. The unit’s address can be on the same or different subnet from the subnet being monitored (where the tap is located).

If you have set a specific site router address, Packeteer recommends that you manage the PacketShaper via the OUTSIDE LEM port. In addition, the unit’s address, site router, and management port connection must be on the same subnet.

10.5 Capabilities

A PacketShaper in watch mode includes the following features:

• Is compatible with SPAN ports, mirrored switch ports, and hubs connecting multiple routers • Can monitor traffic to/from up to 256 WAN routers

• Can monitor traffic from different network segments (if LAN Expansion Modules are installed)

• Can be managed from a separate network than the one being monitored

When deployed using mirrored switch ports, taps, or SPAN ports and the compression module, the Compression Estimator capability allows a PacketShaper to monitor traffic and estimate the bytes saved for different application traffic types and produce overall compression savings estimation for the entire link.

10.6 Limitations

Consistent with its role as a passive monitor, a PacketShaper deployed non-inline with a network tap or in watch mode will not perform traffic shaping; any existing policies and partitions will be ignored. Packeteer's watch mode and direct standby features cannot be used together.

(43)

• Works on outbound traffic only. Due to the asymmetric nature of traffic, the majority of traffic is served outbound from data center servers and represents a suitable proxy for overall network traffic.

• Offers statistics on byte savings and bandwidth increases, but doesn't provide differences in response times. (An inline deployment of PacketShaper with the monitoring, shaping and compression modules offers this capability.)

• Is not applicable where existing PacketShapers are deployed inline.

• Watch mode requires the Xpress compression module to be set to legacy tunnel mode; watch mode cannot be enabled if the unit is in migration or enhanced tunnel mode. The acceleration module requires migration or enhanced tunnel modes, and so cannot be used when a unit is configured in watch mode.

10.7 Configuration Suggestions

For non-inline deployments where a PacketShaper monitors traffic on more than one LAN segment (such as Example 5 ) you may want to define subnet- or IP address-based traffic classes for each LAN in order to track traffic statistics for each LAN.

10.8 Scaling Considerations

The PacketShaper for a non-inline deployment needs to accommodate the link’s capacity, anticipated maximum number of concurrent flows, and anticipated number of users. If you are monitoring traffic on more than one LAN, choose a model based on total WAN-link capacity, not the needs of one particular LAN. Be sure to verify if the model that suits your capacity needs supports your desired LEM. Consult the Configuration Limits table in PacketGuide or the LEM datasheet.

10.9 Complementary Products

If you are satisfied with the estimated compression results and want to use the Xpress compression module to compress data, you will need to purchase the compression module and deploy additional PacketShapers (to create compression tunnels). All units must be deployed inline in order to

(44)

11 Topologies with SkyX and PacketShaper Appliances

11.1 Description

Xpress has the ability to accelerate traffic between hosts on one side of a PacketShaper unit and hosts on the other side of a SkyX device. This type of tunnel, called a SkyX tunnel, requires that you manually create a static tunnel that is SkyX compatible.

11.2 Capabilities

A SkyX tunnel between a SkyX and PacketShaper appliance: • Accelerates traffic with XTP unless SCPS is enabled • Uses global settings for Prefetch and FastStart

• Can be created in migration or enhanced mode

11.3 Installation

Before creating a SkyX tunnel, you need to make sure "accept-all-xtp" mode is enabled on the SkyX device. Log into the SkyX device, and at the command line, type skyx stat to view the current settings. If accept-all-xtp is off, type skyx set accept-all-xtp on to enable it.

Next, add a SkyX tunnel on your PacketShaper, making sure Acceleration is turned on, and that the

Acceleration setting is set to use global. Log into the PacketShaper, and at the command line,

enter the following command:

tunnel remote add <SkyXtunnelName> host|list:hosts|range|subnet/cidr

The SkyX tunnel will now be listed in the Xpress Tunnels Overview window on the PacketShaper. In the Features column for the SkyX tunnel you just created, you will see A(S) if acceleration is already globally enabled or (S) if acceleration hasn't yet been enabled. A=Acceleration, (S)=SkyX.

(45)

11.4 Limitations

The SkyX option is intended for accelerating flows between a PacketShaper unit and a SkyX device. Although Xpress allows you to create a SkyX tunnel between two PacketShapers, it's not supported or recommended, nor does it serve any useful purpose.

A SkyX tunnel does not compress or pack traffic. Options for firewall support, DiffServ support, and auto-discovery of hosts and partners are not applicable.

(46)

12 Topologies with iShared and PacketShaper

Appliances

12.1 Description

The WCCP-based traffic redirection feature allows customers to use a PacketShaper and iShared appliance (or any other cache device that supports WCCPv1 or V2) at the same site and get full benefits of both appliances.

Note: WCCPv2-based traffic redirection supports only one PacketShaper and one cache device.

This feature does not support load-balancing.

12.2 Capabilities

The PacketShaper transparently redirects traffic to the branch office iShared appliance for optimization and reduction, and then iShared sends it back to the PacketShaper for control and further compression and/or acceleration. PacketShaper uses the Web Cache Communication Protocol (WCCP) v2 to redirect traffic to the iShared appliance via a generic routing encapsulation (GRE) tunnel.

PacketShaper is connected to the WAN router, allowing it to classify and control all WAN bound traffic. The iShared appliance is connected to the LAN switch so that it can communicate directly to the clients without having to go through the PacketShaper.

(47)

The diagram above illustrates the redirection process using an iShared appliance. Here are additional details about the process:

1. A client initiates a request to the server located at the data center. This request goes through the PacketShaper.

2. The PacketShaper encapsulates the packets into a GRE packet and redirects this request to the iShared appliance. Note that the packets will not be processed by the PacketShaper’s classification, monitoring, and control features before redirection.

3. One of the following happens:

• If the traffic is eligible for optimization, iShared optimizes the packets and sends them through an ARC or SC/IP tunnel to the iShared appliance at the data center. • If the traffic cannot be optimized, iShared returns the packets through a GRE tunnel

to the PacketShaper. The GRE packets will then be de-encapsulated, classified, controlled, and sent to their destination.

• If the file is available locally, the iShared appliance can reply via CIFS to the client. This traffic does not get classified since it doesn’t go back through the PacketShaper.

12.3 Requirements

The PacketShaper to iShared redirection feature has the following requirements:

• The management port (available on certain models) cannot be enabled for dedicated access, and you can enable WCCP only if the dedicated management port is disabled.

(48)

• Redirection is supported on the following PacketShaper models: 1200, 1400, 1550, 1700, 2500 (with 512 MB of memory), 3500, 6500, 7500, 9500, and 10000.

• This feature is only available on PacketShapers running PacketWise 8.2.x or later.

• Redirection must be configured on the PacketShaper and the iShared appliance. For details, see section 12.6, “Configuring iShared and PacketShaper for Redirection” .

• WCCP should be disabled on the router.

• SCPS acceleration should not be enabled on the PacketShaper.

• You must disable the Use PacketShaper MAC for WCCP system variable when the clients and the iShared (or other cache device) are on different subnets or VLANs, and the traffic between the branch clients and iShared Edge Appliance must pass through the PacketShaper gateway. For further details on this system variable, see PacketGuide:

http://support.packeteer.com/documentation/packetguide/8.2/nav/tasks/configure/adjust-system-variables.htm

12.4 Limitations

The PacketShaper to iShared redirect topologies have the following limitations:

• You can configure redirection on a single interface pair only. For example, you can configure the INSIDE and OUTSIDE ports on a lower LEM, but you cannot configure the

INSIDE port on the main device and the INSIDE port on a lower LEM.

• Although you can configure an MD5 password on the PacketShaper, this type of

authentication is not currently supported on the iShared appliance. Therefore, the password should not be used when pairing a PacketShaper with iShared.

• These topologies do not support direct standby or watch mode.

• Topologies in which traffic between the iShared and PacketShaper bounce off of the router are not recommended in PacketWise 8.2. Packeteer does not recommend using a topology in which the iShared appliance is on a different subnet from the PacketShaper and all GRE traffic goes outside to the router, then back through the PacketShaper to iShared.

(49)

12.5 PacketShaper to iShared Redirect Topology Examples

Example 1

In this topology, the iShared remote appliance and PacketShaper are on the same subnet. This is the recommended and most efficient topology for the iShared redirect feature, because traffic has a direct path between the remote iShared appliance and the PacketShaper and does not have to pass through the router until it is ready to be sent through the WAN.

Example 2

The WCCP-based traffic redirection feature also supports the following topology for an iShared Edge Appliance and a PacketShaper on different subnets or VLANs, when the traffic between the branch clients, iShared Edge device and the PacketShaper passes through a layer-3 switch.

Packeteer Deployment Topologies

Technical Guide