The management interface has changed very little from that of the Packeteer PacketShaper 6500, which I tested last February (see Packeteer's PacketShaper 6500 Keeps Networks Flowing Freely, February 19, 2001). For my tests of the 8500, I got permission to use the traffic-shaping function live on the Syracuse University network.

PacketShaper 8500 (screen view) Click here to enlarge

As expected, the 8500 handles higher throughput than does the 6500, and it can operate on OC-3 connections. And there's no significant increase in latency times with the 8500.

I was impressed with how well the Layer 7 classification worked. New peer-to-peer protocols are harder to shape, however; they disguise themselves via HTTP tunneling or using multiple ports. But because the PacketShaper works by analyzing at Layer 7, it looks at more than just the port number. Instead, it examines application signatures, resulting in a more accurate analysis.

Shaping, Monitoring Campus Traffic

I set up the PacketShaper on our test network at the labs. First, I had the PacketShaper limit bidirectional traffic to 250 Kbps. Then I started a large FTP transfer and tried to telnet into a chat server. The FTP transfer was sucking up all the available bandwidth, so the telnet ran very slowly. Latency is noticeable with telnet, and there were several seconds of delay between key presses.

I then configured the PacketShaper to give telnet traffic a higher priority than that of any other traffic. As expected, telnet became more responsive and smoother. The FTP transfer slowed down while telnet was sending data; when there was no telnet activity, FTP resumed its previous speed. I checked out the claim that the PacketShaper supports Layer 7 by running the chat server on Port 5555. It did indeed correctly identify the traffic to Port 5555 as telnet.

Now for the big test. I put the PacketShaper on the Syracuse University network. I positioned it on a 100-Mbps link between the Internet router and one half of the dormitory network. This resulted in diverse traffic being pushed across the PacketShaper and showed me how much bandwidth peer-to-peer technology consumes.

The university already controls its bandwidth with a traffic-management device, so when I installed the PacketShaper I put it in monitor-only mode. At around 8 a.m., I turned off the university's traffic-shaping feature. Instantly, bandwidth usage shot from an average of 21 Mbps to more than 80 Mbps. I then set up a policy file on the PacketShaper limiting outbound traffic to no more than 35 Kbps for some peer-to-peer protocols. At around 9 a.m., I turned on the PacketShaper's shaping capabilities. Bandwidth dropped back down to just above previous levels--around 24 Mbps.

The PacketShaper showed diverse traffic on the university network, from HTTP to H.323. Programs that use the Napster protocol, once the king of bandwidth usage, averaged well less than 3 Mbps.

The big news in peer-to-peer file sharing these days is Kazaa, and its traffic peaked at 78 Mbps during that brief period when traffic shaping was turned off. This kind of traffic is why universities are looking into bandwidth-management devices. When 78 percent of your Fast Ethernet backbone is full of Kazaa traffic, there isn't much room for mission-critical and priority data, such as e-mail and Novell GroupWise files.

Classifying

Despite the 350 protocols the PacketShaper can identify, an administrator may find there is still a bundle of unknown traffic with which to deal. In my tests, a long list of traffic couldn't be classified by name. The traffic came up as "Discovered TCP Port 8300." Unrecognized traffic is most likely from games or new software for which Packeteer hasn't yet developed signatures.

The PacketShaper also offers a default category. Any traffic that isn't seen x times in 60 seconds falls into the default category to prevent the class tree from becoming overpopulated with less common traffic. You can configure this number and you can rate limit default. This feature also can be disabled by setting the number of times per 60 seconds to 0, but this will cause all traffic in the default category to be integrated into the class tree. Be aware that the class tree has an upper limit of 1,000 or 2,000 discovered protocols, depending on which PacketShaper model you purchase. When the class tree is full, PacketShaper stops classifying newly discovered data.

Vendor Information PacketShaper 8500, $22,000 to $49,000. Available: Now. Packeteer, (408) 873-4400; fax (408) 873-4410. www.packeteer.com

The PacketShaper has a safety feature: If the box is turned off or both the redundant power supplies fail, a relay inside the device puts it into a passive mode and allows traffic to continue to pass through.

Quality of Service

Traffic can be shaped by partitioning bandwidth in various ways. You can put a cap on a specific protocol, limit inbound or outbound traffic and set minimum rates. You also can block a protocol completely. For example, you may want to give a VoIP (voice over IP) connection a guaranteed 7 Kbps, and if the bandwidth isn't available, you might want to set up the device to prevent the client from connecting.

Additionally, you can set a burstable limit so Web traffic is guaranteed 5 Kbps and up to 10 Kbps, if the bandwidth is available. If reserve bandwidth is available and nobody is using it, the PacketShaper will temporarily allocate that bandwidth to other areas. This way you can set minimums and guarantee traffic without wasting bandwidth.

Policies can be set by time but can't be accessed via the GUI. In the next software upgrade release for the PacketShaper, the GUI should have this capability.

In addition to TCP traffic, the PacketShaper recognizes and shapes some non-TCP traffic, such as AppleTalk, IPX, SNA and UDP. These traffic types can't be TCP-rate shaped but use other forms of control, such as queuing.