Xedia Corp.'s Access Point 10 (AP 10) is the newest product in the company's line of network bandwidth managers. This bridge lets you partition network traffic and allocate portions of bandwidth to various traffic classes. The technology behind this Xedia product line is invaluable for controlling network resources--your users access only the required bandwidth. In addition, a new Web-based management agent lets you perform administrative tasks directly from your Web browser.

I tested a beta version of the Access Point 10 in Network Computing's Syracuse University Real-World Lab®. AP 10 is efficient, but there's room for improvement. You must carefully define traffic classes to ensure that your intentions are correctly translated into traffic rules. Some knowledge of network protocol concepts is necessary to take complete advantage of AP 10.

Directing the Flow Initial setup and configuration was easy. I encountered some minor bugs, but they didn't hamper the product's performance. You need to install only one AP 10 between two points on your network for optimal bandwidth regulation.

To make the device easier to use, Xedia has included a Web-based management agent that lets you perform almost every administrative function from the comfort of your favorite browser. I used this agent to monitor my progress as I defined classes and subclasses. Its graphical nature let me easily visualize the class hierarchy I created, and its command-line interface, modeled after Cisco Systems' IOS (Internetwork Operating System) command line, makes management a snap.

AP 10 manages network traffic with tremendous efficiency and flexibility, thanks to Xedia's CBQ (Class-Based Queuing) technology. When you create a class, you configure AP 10 to allocate a certain amount of bandwidth. The product uses packet characteristics--such as source and destination addresses (and ranges of addresses), source and destination ports and protocols--to determine which packets are bound to a particular class.

With AP 10, you can define classes as bounded or unbounded. A bounded class only lets you use the allocated bandwidth. In contrast, an unbounded class lets you use the allocated bandwidth, along with idle bandwidth, but it must be relinquished if packets in another class need it.

In the lab, AP 10 did not impose an unreasonable limit on the available bandwidth, so I created a root class with full 10-Mbps bandwidth. I designated two classes--subnet1 and subnet2--under the root class and allotted 5 Mbps of bandwidth to each. Subnet1 applied only to packets whose destination address fell within a certain range of IP addresses; subnet2 applied to a different range of destination addresses.

AP 10's CBQ technology gains its flexibility through subclassing. I created two subclasses under subnet1: subnet1_tcp and subnet1_udp. I didn't allot any bandwidth to subnet1_tcp, while subnet1_udp enjoyed the complete 5 Mbps. I then configured subnet1_tcp to apply to any TCP packet and subnet1_udp to any UDP (User Datagram Protocol) packet. Because subnet1_tcp and subnet1_udp are subclasses of subnet1, they apply only to traffic that falls under subnet1. So TCP traffic destined for IP addresses that fall under subnet1 is blocked, while UDP traffic to those same addresses is passed on. Any type of connectivity falling under subnet2 worked correctly.

This configuration for subnet1 isn't very useful, because denying all TCP connectivity is usually counterproductive. My tests were designed to demonstrate the effectiveness and flexibility of subclassing. To illustrate a more useful application, you can try a similar configuration approach with an NFS client/server farm and allot more bandwidth to UDP packets than to TCP packets. Because NFS usually works over UDP, this would designate a higher priority to NFS communications over non-UDP activity.

To further test AP 10, I created a class based on port number and configured it to control all HTTP traffic bound for a Web server. This class applies to traffic moving in either direction across AP 10 for all packets destined for an HTTP port. While I wanted to restrict the bandwidth of inbound connections, I didn't want to limit outbound connections. AP 10 is incredibly flexible, but you must carefully plan your class rules because, as I discovered, some ramifications aren't obvious. I further refined the Web class so that it only affected packets headed for the HTTP port of the Web server's specific IP address. This class was assigned 2 Mbps of bandwidth, and the remainder was assigned to a default class.

As the final part of my test, I tagged the Web class as bounded and the default class as unbounded, allowing all traffic--except for inbound Web traffic--full use of the available bandwidth. Incoming Web traffic could not overwhelm any other type of traffic--as evidenced by a couple of load generators that pegged the Web class allotment--but let me continue my other work, such as an FTP session, with no noticeable lag.

In the next version, Xedia claims that AP 10 will include limited Layer 4 support with the ability to define traffic classes in terms of the URL of HTTP packets. With this support, you'll be able to restrict and favor various parts of a Web site. You can devise different billing schemes, reflecting how much bandwidth will be allotted to the customer's Web site.

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