I had the PacketShaper up and running for about two weeks during the end of Syracuse University's fall academic semester at our Real-World Labs. I installed the PacketShaper between the Internet-2 router and the backbone; the WAN is an OC-3 running at 155 Mbps, but the segment of the university's backbone used for testing ran at only 100 Mbps.

Classification Gets a 7

Traffic Monitoring (screen view) Click here to enlarge

The PacketShaper can analyze traffic up to Layer 7, looking at individual sessions to determine what type of connection is being made. One of my tests was to run a Web server on ports 80 and 9000. The PacketShaper classified HTTP connections to these ports as HTTP traffic. In other words, it does not look only at the port numbers--a spiffy feature. In many cases, network managers attempt to block traffic merely by blocking default ports; however, many programs allow servers to be run very easily on an arbitrary port. For example, let's say you want to block all online games. You can block the default ports, but anyone can set up a Quake II server outside your network on TCP Port 80, and there is a very good chance you won't be blocking outbound Web traffic. But with PacketShaper, it's easy to get gamers off your network; even though they're good people at heart, they just like blowing stuff up--especially your bandwidth usage.

The PacketShaper can identify many types of traffic. The manual says it can recognize more than 275 applications and/or protocols, and that number should increase as new protocols arise. Protocols recognized include RTSP (Real Time Streaming Protocol); UUCP (Unix to Unix Copy); H.323; NFS; id software's Doom; rlogin; TN3270; and, God help you if you have to use these, DECnet and SNA. You can see some of the services blocked here www.packeteer.com/technology/4steps.pdf (Adobe PDF file, Page 6).

With PacketShaper, you can create graphs illustrating network utilization and efficiency over a period of time. I discovered, with little surprise, that the Syracuse connection is least busy from 3:30 am until 6:00 am. Pretty much the only traffic in this timeframe is generated by grad students (and certain freelance writers) who like to stay up late and wake up late. The graph shows average and peak megabits per second over time, and PacketShaper keeps logs for up to two months. Network efficiency reports show the percentage of total traffic that is not a TCP retransmit. While a retransmit will happen from time to time--our labs never dropped below 80 percent--lots of retransmits will slow down the network and be perceived by end users as a cut in speed. You will be able to look for patterns to help determine when problems occur.

Network Performance Summary (screen view) Click here to enlarge

Finally, you can generate a pie chart showing the protocols used most often and their average bytes per second, both inbound and outbound. For example, 59 percent of our test lab's inbound traffic was IPX, with an average rate of 58.4 Kbps, although I did not see any way to differentiate between broadcast and unicast traffic. Our outbound top was "default," at 21.9 Kbps and 37 percent. Traffic that is not classifiable or shows up in small amounts is put into the default category so as to not barrage the administrator with reports of thousands of miscellaneous or unknown protocols. Although our beta code showed about one-fifth of the Syracuse University traffic to be default, Packeteer said that newer versions of the software would perform better.

Shaping, Amid the Slings and Arrows

All IT managers face technological as well as political challenges. In the academic world, if you block a protocol from the network, be prepared to read in the school newspaper about how freedom of speech is being oppressed and how evil you are. In the private workplace, users may hunt you down and shoot you with Nerf arrows, or maybe throw the yo-yos that vendors gave out at the last trade show at your head. And let's not get started on the corporate politicians playing network brinkmanship with you.

But the fact remains: Good network administers don't let Napster take over 95 percent of their bandwidth. What to do? PacketShaper lets you reach a compromise by dividing your bandwidth into parts. This way, you can say, for example, that Napster can't consume more than 20 percent of available bandwidth with a burst capability of 35 percent. If you're really fiendish, set max Napster usage on your T-3 to 500 KBps. The program will work fine, but really slow. This will probably make your life slightly easier, as the political arguments will be greatly reduced--many, perhaps most, users won't catch on. After all, the only thing worse than technology hijacking your network is having a user try to snatch it by going over your head, especially when you know you're right.

The PacketShaper allows you to partition your bandwidth into separate virtual channels. Think of this as similar to partitioning a disk: If you take a 10 GB disk and partition 4 GB to temp space, there will always be 4 GB of data that can be written to the temp volume. In a similar fashion, you can create bandwidth partitions with the PacketShaper and enforce policies on those partitions. For example, you can create a partition for VoIP, then specify the minimum rate for each flow. You can also specify burst limits. Then, unused bandwidth may be used for other traffic until needed, so it isn't wasted by sitting idle.

Traffic Class (screen view) Click here to enlarge

Policies allow you to set priority on a flow-by-flow basis. Choices include: setting by priority levels or rate control; blocking a service by dropping all packets; ignoring a service by just passing it through; and never-admit. Never-admit allows you to do more than refuse connections; it also supports redirecting Web traffic to a different server. For example, I set it up so that all Web traffic to www.networkworld.com was redirected to www.networkcomputing.com. Really. In addition, you can use this feature to redirect traffic to your backup Web server if your primary server is down, hacked, unplugged or suffering cola spillage.

I also set rate policies to control bandwidth usage. However, I forgot that I left the traffic shaping on, and one of our senior technology editors was wondering why his FTP transfer was getting only 500 bytes per second. Oops. You can set guaranteed bytes per second, burst priority or an upper limit on traffic. This will allow you, for example, to set aside 8 KBps to each VoIP session. The PacketShaper works by changing the TCP rate control between the inside and outside stations. The method used by other QoS software is usually a queuing algorithm. The trouble with queuing is that there may be an increase in time-outs and retransmits, and thus it doesn't really solve the problem. Nodes on the inside will continue to transmit as fast as they can, and incoming traffic will still clog up the pipe. By using TCP rate control, the PacketShaper can tell the sender to slow down and not try to transmit packets as fast as it can. This helps control incoming traffic as well by, for example, adjusting window size, regulating TCP acknowledgements and performing other feats of technomagic.

The PacketShaper 6500 will probably find its way onto many network con-nections. After all, bandwidth isn't cheap; customers expect a certain level of responsiveness; service agreements may require minimum bandwidth; and large file transfers and bandwidth-hogging programs are proliferating. Packeteer has found a way to suppress--not deny--these bandwidth hogs. The ability to analyze traffic up to Layer 7 defeats some common techniques to get around bandwidth control or protocol blocking. If you are having bandwidth trouble, QoS problems or simply don't want users getting around your policies by lame default port blocking, the PacketShaper 6500 should definitely be looked at as a solution.

Michael J. DeMaria is a system administrator in Syracuse, N.Y. Send your comments on this article to him at demaria@nand.net.