April 16, 2001, 12:09 PM — Enterprise networks are stressed to the limit but still are expected to transport more business-critical services than ever. This is where network quality of service can save the day.
The QosWorks 10000 is the latest in Sitara Networks' line of quality-of-service (QoS) appliances that sit between a LAN and WAN router, letting network administrators monitor and manage expensive network bandwidth. This model supports data rates up to 100 Mbps and has an integrated Pentium III 600-MHz processor, dual 10/100-Mbps Ethernet interfaces and some fairly sophisticated software, all integrated in a Web-based management interface.
We found installation to be a breeze, management painless, and performance as advertised. We would like to see Sitara include additional intelligence to assist in classifying a wider variety of traffic, as well as additional features to secure the unit from unwanted visitors.
The device is set up to monitor traffic only, and not enforce any default policies. This is important because it lets the user get acquainted with the user interface without the risk of downing the network. The Ethernet ports are labeled LAN and WAN, and are designed to plug into a switch/hub and router respectively.
To baseline performance, we ran throughput tests using different Ethernet frame sizes at 100 Mbps. In most cases, QosWorks passed line-rate traffic across its interfaces. We only noticed loss using 64-byte frames.
To test the bandwidth management capabilities, we started with a 10-Mbps WAN, using NetIQ's Chariot software to generate traffic between both networks. We generated a total of 25 Mbps of traffic consisting of HTTP, FTP, Simple Mail Transfer Protocol and User Datagram Protocol (UDP)-based RealVideo streams while running the QosWorks in monitor-only mode. We noticed the videostreams were using most of the available bandwidth.
We used the Web management interface to create policies that limited the videostreams and SMTP each to 20 percent of the available bandwidth and left the remainder to all other IP traffic. The videostreams, which were previously dominating the WAN connection, were now clearly limited to 20 percent. On the other hand, SMTP received the bandwidth it needed using only half of its 20 percent allotment, with FTP and HTTP traffic garnering roughly an equal share of the remaining resources. Because we didn't allow bursting above the configured maximum, 10 percent of the link remained idle from the unused SMTP bandwidth.