With the AC 200, you have several options for controlling network usage. It limits bandwidth or number of connections based on a virtual channel, which is defined by source or destination address of packets, Layer 3 and Layer 4 network protocols or time of day. You then choose a rule that applies to TCP/IP traffic in this virtual channel, such as limiting bandwidth for each connection or the entire channel by buffering packets. When bandwidth is available, the buffered packets are released. The AC 200 also uses TCP flow control to limit packet rates.

Management is handled via a Java-based Web agent that comes bundled with the AC 200. The agent simplifies visualizing the virtual channels and their associated rules. This ease of use puts the AC 200 slightly ahead of most other bandwidth managers.

I installed the AC 200 so that traffic moving between the lab's two servers, Eclipse and Louie, would pass through it. Then I created a virtual channel called Eclipse & Louie that would work with any network traffic whose source and destination address was Eclipse or Louie.

Once the channel was in place, I used the Web agent to create a rule that would determine what happened to traffic in the channel. I limited connections in the channel to 19,200 bytes per second of bandwidth. I set this amount as both the minimum and maximum bandwidth, but you have the option of leaving it as a minimum. The AC 200 maintains a default channel that applies to packets that don't match other channel definitions. I limited this default channel to 50 bytes per second.

Next, I downloaded a 30-MB file from Louie to Eclipse, and the throughput corresponded with the set limitation. The same file was downloaded from Camelot, another computer, to Eclipse. This transfer fell under the default channel, since the file was 30 MB and the allocated bandwidth was 50 bytes per second.

Another measure for determining packet management involved assigning a priority to each channel. A priority is assigned when a bandwidth value has not been set or when channels are not using all of their allotted bandwidth. This time, I defined priorities--not bandwidth restrictions--for individual channels. AC 200 has 10 priorities to choose from. I attributed virtual channel Priority 10 to Eclipse & Louie and Priority 1 to the default virtual channel, respectively. I ran FTP transfers concurrently, one in each channel. In this configuration, an FTP session between Eclipse & Louie completely preempted the Eclipse and Camelot transfer, whose packets were buffered until the first session ended. Diminishing the priority difference altered this behavior, so that the higher priority transfer occurred much faster without completely preempting the other transfer.

During testing, I used the Web agent to change the access control policy on the Eclipse & Louie channel from accept to reject. With this, any attempted connections between the two computers were denied, but connections not involving both computers succeeded.

Load Balancing and Fault Tolerance Allot's line of bandwidth managers also load balances servers and enables fault tolerance when the optional load-balancing module is installed. In an effort to keep things simple, some could argue that such capabilities don't belong in a bandwidth manager. However, combining this functionality into one black box is beneficial, because it reduces the number of computers that you must manage. And since they exist on the same box, you only have to learn one user interface. Furthermore, the AC 200's design integrates fault tolerance and load-balancing capabilities with bandwidth management functionality.

In the lab, I set up a virtual channel, LoadBal., and configured it using the Web agent for packets destined for Network Computing's Web server's HTTP port. I then created a load-balancing rule, mandating that traffic in this channel should be distributed equally across Network Computing's server and the backup server, Louie.

As I monitored the Web server software's access logs, I noticed that alternate requests to the Web server would be serviced by the backup Web server. I reconfigured the rule so that the primary Web server would receive two requests for every one the backup server received. This let me control the level of stress I placed on the servers in my Web server farm. I made sure the backup server didn't sit idle and the primary server carried most of the load.

Incidentally, the AC 200 isn't limited to balancing Web traffic. I changed my channel definition so that it applied to FTP traffic. I experienced similar results with this test, but had failed to mirror the primary server's FTP directories onto the secondary server. As a result, my FTP session was fraught with invalid requests. This was easily corrected by mirroring the data.

When I tested the optional load-balancing module, it worked flawlessly. In addition, configuring the AC 200 was a snap. You can hook it up with either a serial connection or by attaching a monitor and keyboard. I chose the latter method. After assigning the requisite network addresses, choosing passwords and rebooting my machine, I plugged the AC 200 into the network and used a Web browser to perform other configuration and management tasks.

Jeremy Impson is a freelance writer based in Syracuse, N.Y. He can be reached at jdimpson@syr.edu.