First Steps to Using PacketShaper ISP

(1)

First Steps to Using

(2)

(3)

T

ABLE

OF

C

ONTENTS

O

VERVIEW

... 1

D

ETERMINING

Y

OUR

P

ACKET

S

HAPER

ISP D

EPLOYMENT

S

TRATEGY

... 2

ISP Upstream Link ...2

Cable or DSL Head End ...2

U

SING

THE

C

LASSIFICATION

-A

CCELERATOR

C

ACHE

... 3

T

RAFFIC

T

REE

C

ONFIGURATION

... 4

Direction ...4

Organization ...4

Using the Command-Line Interface ...4

Creating Folder Classes...5

D

EFINING

C

LASSES

FOR

E

ACH

S

UBSCRIBER

... 6

Creating Classes ...6

Adding Matching Rules...6

Adding Subscriber Comments...7

Adding Owners...7

A

LLOCATING

B

ANDWIDTH

TO

S

UBSCRIBERS

... 8

Examples ...8

Turning Shaping On ...8

C

REATING

A

D

ATA

E

NTRY

F

ORM

... 9

V

ERIFYING

THE

IP C

LASS

L

OOKUP

A

CCELERATOR

C

ACHE

IS

B

EING

U

SED

.... 10

Cacheable Classes ...10

(4)

(5)

First Steps to Using a PacketShaper ISP 1

Overview

PacketShaper ISP models offer bandwidth provisioning and management solutions for Internet Service Providers, educational institutions, and other bandwidth providers. For providers, it is often most effective to organize the PacketShaper’s traffic tree by subscriber rather than by application.

A PacketShaper offers two ways to track and allocate bandwidth per subscriber:

• By manually creating traffic classes, one per subscriber, and then assigning partitions to each of these classes. Subscribers can be allocated different amounts of bandwidth, depending on the terms of their contract.

• By using the dynamic partition feature to allocate bandwidth to users as they log on to the network. With this technique, each user is allocated the same amount of bandwidth. You can use the flow de‐ tail records or host accounting features to track usage.

This guide shows you how to configure your PacketShaper using the first method. If you want to explore the possibility of using dynamic partitions and host accounting, see PacketGuide for details. In addition, PacketGuide includes a recommendation, Provision Bandwidth Equitably, that may be of particular interest to educational institutions and service providers who want to ensure that each user gets an equal share of bandwidth.

(6)

2 First Steps to Using a PacketShaper ISP

Determining Your PacketShaper ISP Deployment Strategy

To maximize performance, configure PacketShaper ISP models so that the inside port of the unit is on the same side as the blocks of IP addresses being managed. The following network topologies show

configurations that optimize PacketShaper ISP units.

ISP Upstream Link

To set up an ISP upstream link configuration, connect the PacketShaper ISP unit’s outside port to the router and connect the inside port to the ISP network.

Cable or DSL Head End

To set up a cable or DSL head end configuration, connect the PacketShaper ISP’s outside port to the ISP network and the inside port to the distribution network that contains the users.

PacketShaper ISP

ISP Network

inside outside

router

Internet

PacketShaper ISP ISP Network

cable or DSL users

outside inside

DSLAM or cable head-end

(7)

Using the Classification-Accelerator Cache

PacketShaper ISP models offer a caching feature that stores qualified IP address‐based classes in a cache, thereby increasing the speed at which the PacketShaper classifies flows on the inside of the unit. Best performance is achieved when address‐based classes are cached in the classification‐accelerator cache. Caching can reduce the number of CPU cycles needed for classification by ten times, leaving more processing capability available for traffic shaping. In particular, the cache provides benefits if you have more than 750 classes in your traffic tree.

To take advantage of the classification‐accelerator cache:

1. Position PacketShaper ISP units so that most of the IP addresses or subnets are located on the INSIDE port (unless you change the Caching of IP address‐based classes system variable to outside). See

“Determining Your PacketShaper ISP Deployment Strategy” on page 2 for topology examples. 2. For each subscriber, create an IP address‐based class. (See “Defining Classes for Each Subscriber” on

page 6.)

Note: Using other criteria, such as specific services or ports, you can create classes that do not use the address cache.

3. Append additional matching rules, if applicable. (See “Adding Matching Rules” on page 6.)

4. Make sure cacheable classes are indeed being cached. (See “Verifying the IP Class Lookup Accelerator Cache is Being Used” on page 10.)

(8)

Traffic Tree Configuration

A traffic tree is a hierarchical list of traffic classes. A traffic class is a logical grouping of traffic flows that share the same characteristics — a specific application, protocol, address, or set of addresses. Typically, on PacketShaper ISP units, each subscriber is configured as a traffic class based on an IP address or subnet.

Note: If you want to control application performance in addition to allocating bandwidth, you can create application-based traffic classes as well. However, this guide focuses on the creation of subscriber-based classes.

Direction

PacketShapers have a fixed number of traffic classes — for example, a maximum of 5000 classes on the 9500/ ISP series. Therefore, give careful consideration to whether you want PacketShaper to manage traffic in one or both directions. If inbound traffic uses an insignificant amount of bandwidth, you may not want to create classes for the inbound direction. By creating classes for only one direction, you will be able to create twice as many classes.

Organization

Before creating any classes, you should also think about how you want to organize the traffic tree. By grouping your subscriber classes into categories, you will be able to locate them more easily in the tree and create more meaningful reports and graphs. Here are a few ways you can organize your subscriber classes:

• by rack • by subnet

• by subscriber plan (gold, bronze, silver) • by region

For example:

Outbound Gold_Plan Brians_Bridal Florences_Flowers Gregs_Greetings Jeffs_Java Jennifers_Jellies Silver_Plan Pats_Pets Steves_Stereos Todds_Toys

In the above example, Gold_Plan and Silver_Plan are folder classes, used for organizing and logically grouping traffic classes.

Using the Command-Line Interface

Since you will be manually creating many classes and partitions, Packeteer recommends using the command‐line interface (CLI) for initial configuration.

To access the PacketWise CLI with a remote login utility (such as Telnet or SSH):

1. Connect to the unit using its IP address — for example telnet 10.10.1.100. When you connect successfully, you will be prompted for the unit’s password.

2. Enter the password and press Enter.

Creating Folder Classes

(9)

class new <parent_name> <name> folder

For example, to create an Inbound folder named Gold_Plan:

(10)

Defining Classes for Each Subscriber

Most often, ISPs can identify subscribers by IP address, by subnet, by VLAN, or by HTTP 1.1 host name, so configuring PacketShaper involves manually creating traffic classes, one per subscriber. PacketShaper ISP models have been optimized for these IP address‐centric configurations.

You will need to define a traffic class for each subscriber (either single IP address or subnet) on the inside of the PacketShaper.

Creating Classes

The CLI command for creating IP address‐based classes is:

class new <parent_name> <tclass> inside <ipaddr>[/<cidr>] [:<submask>]

Examples:

To create a traffic class based on a single IP address, enter the following command at the PacketShaper# command‐line prompt:

class new inbound/gold_plan sample_subscriber_ip inside 192.168.1.1

Notice that the above command specifies the folder (inbound/gold_plan) in which you want the class created.

To create a traffic class based on a subnet, using CIDR (Classless Inter‐Domain Routing) shorthand to represent the IP network/subnet mask pair:

class new inbound/gold_plan sample_subscriber_subnet inside 192.168.2.0/24

When creating a child class of an IP address‐based parent, you will probably want to use the class new’s nodefault parameter. For example:

class new outbound/silver_plan 216.158.145.0 nodefault inside net:216.158.145.0/19 outside host:any

With the nodefault parameter, PacketWise will not create a Default match‐all class as it normally does. Be aware that match‐all siblings or parents of cacheable classes can create redundancies in the tree and cause problems in the accelerator cache. (See “Improving Cache Performance” on page 10.)

Adding Matching Rules

Matching rules define the criteria PacketWise uses to identify traffic types. If a subscriber has more than one IP address or subnet range, you will need to append additional matching rules to the class. Repeat as necessary if multiple subnets or IP addresses are allocated to a single subscriber. Consider using host lists if more than two IP address ranges are assigned to a single subscriber. A host list contains a list of IP addresses, ranges of IP addresses, subnets, and DNS names.

If the number of IP addresses exceeds the size of the host database, additional flows will be classified in the /Inbound/Default and /Outbound/Default classes. To avoid this, optimize the definition of matching rules so that the total number of IP addresses or subnets for all of the matching rules does not exceed the size of the host database. The host database size is listed in the online PacketGuide reference section.

The CLI command for adding a matching rule to an IP address‐based class is:

class rule add <tclass> inside <ipaddr>[/<cidr>] [:<submask>]

Examples:

To add a matching rule for an additional IP address to the sample_subscriber_ip traffic class:

(11)

To add a matching rule for an additional subnet to the sample_subscriber_subnet class:

class rule add inbound/gold_plan/sample_subscriber_subnet inside 192.168.3.0/24

To create a host list, use the hl new command. To add hosts to an existing host list, use the hl add command. For example:

hl new mylist 192.168.4.0/24

hl add mylist 192.168.1.10-19.168.1.200

class rule add inbound/gold_plan/subscriber inside list:mylist

Adding Subscriber Comments

You can use the comment field to include additional information about each subscriber. For example, enter the following command to note that sample_subscriber_ip is a subscriber with two IP addresses:

class note inbound/gold_plan/sample_subscriber_ip "Class for subscriber with 2 IP addresses"

The note will appear in the Comment field on the Traffic Class page in the browser interface.

Adding Owners

The customer portal feature, described in detail in PacketGuide, allows you to offer customized screens of PacketWise statistics to your subscribers. If you plan to use the customer portal feature, you may want to assign an “owner” to each class after you create it, using the following command:

class owner <tclass> “<ownername>”

(12)

Allocating Bandwidth to Subscribers

To allocate bandwidth to a subscriber, assign a partition of a specific size to its traffic class. A partition is a virtual pipe that you can create for a given traffic class. This virtual pipe reserves bandwidth for all flows of a given type — such as all traffic associated with an IP address or subnet. The partition can be used either to place bandwidth utilization limits on a subscriber or to guarantee the subscriber a minimum amount of bandwidth. Some ISPs use partitions to enforce maximum bandwidth usage limits, which are similar to Frame Relay’s concept of EIR (Excess Information Rate) but offer no guaranteed bandwidth (such as Frame Relay’s concept of 0 Committed Information Rates [CIRs]). Other ISPs may design their service offerings so that each subscriber is guaranteed a minimum quantity of bandwidth, either with or without a maximum bandwidth utilization limit.

Examples:

The first example below shows a partition with 0 Kbps CIR, 256 Kbps EIR. The second example shows a partition with 64 Kbps CIR, 256 Kbps EIR.

To allocate a minimum of 0 bandwidth and a maximum bandwidth of 256 Kbps to the sample_subscriber_ip class:

partition apply /inbound/gold_plan/sample_subscriber_ip 0 256k

To allocate a minimum of 64 Kbps and a maximum of 256 Kbps:

partition apply /inbound/gold_plan/sample_subscriber_ip 64k 256k

• For an ISP upstream link configuration, you will want to create a partition for each subscriber in the ISP network.

• For a web hosting configuration, you will want to create a class and a partition for the IP address of each “virtual” web server. If you are using HTTP 1.1 Host Name headers (multiple host names per single IP address), create the class using the HTTP Criterion option to specify the Virtual Host name. • For a cable or DSL head end configuration, you will want to create a partition for each cable or DSL subscriber, based on IP addresses or subnets. These environments use DHCP (Dynamic Host Con‐ figuration Protocol), so IP address policies will be ineffective. This is a good application for dynamic partitions. (For details about dynamic partitions, see your online PacketGuide.)

Turning Shaping On

Partitions have no effect until traffic shaping is turned on. To do this in the CLI, type:

setup shaping on

Or, in the browser interface: 1. Click the setup tab. 2. Turn Shaping on. 3. Click apply changes.

(13)

Creating a Data Entry Form

Instead of using the CLI to manually create all of your IP address‐based classes and partitions, PacketWise offers a way to automate the process with a fill‐in‐the‐blanks data entry form. An HTML form is generated from a command file that consists of CLI commands and variables. You can fill in the blanks in the HTML form, and when the data is processed, the CLI commands in the source command file will be executed. For more information on this technique, see the online PacketGuide. (In the PacketGuide navigation bar, choose Tasks > Administration > Create Forms.)

(14)

Verifying the IP Class Lookup Accelerator Cache is Being Used

Cacheable Classes

PacketShaper ISP models follow certain criteria to determine whether a class can go into the accelerator cache. In order for a class to be considered cacheable:

• It must be a leaf class (that is, it can’t have any children).

• Its parents and siblings must be either IP address‐based classes or match‐all classes.

• The class’ matching rules must specify “outside host:any” if the cache is on inside addresses (the de‐ fault).

Use the class show command to determine if a class is cacheable. Cacheable classes are marked with a “C” flag. Cacheable classes are always address‐based (marked with an “a” flag) and their parents are also address‐based or match‐all classes (marked with an “m” flag). Note that exception classes are not cacheable.

class show

Derivation: (I)nherited (O)verride (U)nderride (L)ocal

Class Flags: (A)utocreated (D)iscovering (E)xception (I)nherit (P)olicy (C)acheable

Rule Types: (o)ptimized (m)atch-all (a)ddress is cacheable

Class Name Flags Partition Name

Inbound m

Localhost E P /Inbound 10.7.38.0 a /Inbound

SUBSCRIBER ma /Inbound

mysite.org C a /Inbound Default IP m /Inbound

Outbound m

Localhost E P /Outbound 10.7.38.0 a /Outbound

SUBSCRIBER ma /Outbound

mysite.org C a /Outbound Default IP m /Outbound

In this example, the class mysite.org in the Inbound and Outbound direction is cacheable.

Improving Cache Performance

If a cacheable class has more than one match‐all sibling or parent, it will not be treated as cacheable. You can use the flags in the output of the class show command to determine if this situation exists in your traffic tree. These flags indicate whether the class is (C)acheable, (a)ddress‐based, and/or (m)atch‐all.

Because uncached classes can use more CPU resources to classify traffic, you can improve performance by making all qualified address‐based leaf classes cacheable. One way to do this is to remove a redundant match‐all class near the uncached class, such as removing a Default bucket that is a sibling of the uncached class(es) or a sibling of the parent of the uncached class(es). In the example below, you can make the mysite.org class cacheable by removing the Default class that is mysite.org’s sibling.

Class Name Flags Partition Name

. . .

SUBSCRIBER ma /Inbound

mysite.org a /Inbound