Professional Documents
Culture Documents
TABLE OF CONTENTS
OVERVIEW ................................................................................................................ 1 DETERMINING YOUR PACKETSHAPER ISP DEPLOYMENT STRATEGY................. 2
ISP Upstream Link ...........................................................................................................................................2 Cable or DSL Head End ...................................................................................................................................2
CREATING A DATA ENTRY FORM ........................................................................... 9 VERIFYING THE IP CLASS LOOKUP ACCELERATOR CACHE IS BEING USED .... 10
Cacheable Classes ..........................................................................................................................................10 Improving Cache Performance.......................................................................................................................10
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 PacketShapers 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 detail 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.
To set up an ISP upstream link configuration, connect the PacketShaper ISP units outside port to the router and connect the inside port to the ISP network.
Internet
router
outside
inside
ISP Network
PacketShaper ISP
To set up a cable or DSL head end configuration, connect the PacketShaper ISPs outside port to the ISP network and the inside port to the distribution network that contains the users.
outside
inside
ISP Network
PacketShaper ISP DSLAM or cable head-end
2.
3. 4.
Direction
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.
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.
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. 2. 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 units password. Enter the password and press Enter.
Creating Classes
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 news 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.)
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:
class rule add inbound/gold_plan/sample_subscriber_ip inside 192.168.1.2
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
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>
The <ownername> should match the login ID you plan to give the subscriber.
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
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 Configuration 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. 2. 3. Click the setup tab. Turn Shaping on. Click apply changes.
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 Inbound Localhost 10.7.38.0 SUBSCRIBER mysite.org Default Outbound Localhost 10.7.38.0 SUBSCRIBER mysite.org Default Flags Partition Name m E P /Inbound a /Inbound ma /Inbound C a /Inbound IP m /Inbound m E P /Outbound a /Outbound ma /Outbound C a /Outbound IP m /Outbound
In this example, the class mysite.org in the Inbound and Outbound direction is cacheable.
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.orgs sibling.
Class Name . . . SUBSCRIBER mysite.org Default Flags Partition Name
10