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.
To test the full capacity of the box, we changed the WAN connection to 100 Mbps. QosWorks can limit the amount of traffic that passes across the WAN, but it is unable to directly control the amount of data that "touches" the LAN interface, which can cause congestion independently of what goes on over the WAN link. TCP, which has built in flow-control mechanisms, can correct for this, but unacknowledged UDP packets will continue to bombard the LAN interface.
To start the new round of tests, we used Chariot to create 10 Mbps of SMTP traffic, and 30 Mbps each of FTP and HTTP traffic, as well as 50 Mbps of UDP-based RealVideo streams. We created policies that gave FTP 30 percent of the bandwidth; SMTP and HTTP, 20 percent each; with the remaining 30 percent allotted to AnyIP. We also gave priority to HTTP traffic, and let each category of TCP traffic burst to twice their allocated values.
Before we applied the policies, RealVideo and FTP streams dominated the WAN, with HTTP and SMTP much lower than desired. After applying the policies, the RealVideo streams dropped to 30 Mbps, but the TCP-based traffic was lower than expected. The cause appeared to be congestion at the LAN interface, which resulted in the TCP traffic slowing due to flow control.
To verify this, we reduced the amount of UDP traffic being transmitted, which showed the TCP-based traffic returned to expected levels. Because SMTP was not using its full bandwidth allotment, the high-priority HTTP traffic could burst above its 20 Mbps maximum as we had configured.
Finally, we added a voice-over-IP call while attempting to transfer a 50-MB file across the WAN. We altered the policies to reserve 5 percent of the bandwidth for voice-over-IP devices, and an additional 10 percent for traffic to and from our Windows 2000 Server. Prior to implementing the policies, the branch office voice-over-IP phone was unable to place a call across the WAN link, and the file transfer was slow and bursty. After the policy change, we could place a voice call across the WAN with a minimum of jitter or distortion, and the simultaneous file transfer was steady and near the desired rate.
The QosWorks 10000 features real-time traffic flow monitoring. It can classify traffic by application/port or by address of the sender or the receiver. If operating by application/port, the unit will attempt to recognize the traffic by application. If it doesn't know a particular application, you can also build custom port filters to help an identification see a port number. Unfortunately, some new applications use random ports on both ends, which makes it difficult to classify these types of traffic by application. Traffic is also classified by port, but the management interface does not distinguish whether the port is source or destination, which can be confusing.
For traffic control, you can set QosWorks filters based on traffic type, source address/mask, destination address/mask, and port numbers. Once a filter is in place, it can be applied toward a policy class, which is the mechanism used to support bandwidth restrictions and priorities. The QosWorks platform has a slew of ways to carve your bandwidth, including setting limits, burst ceilings, priorities, time of day, and even session bandwidth, which can guarantee each session a minimum allocation with admission control. You can even have it mark the type-of-service byte, which can be used by other QoS-aware devices on your network, although QosWorks 10000 cannot act based on the type-ofservice byte.
You can generate graphical reports that are used to determine the effectiveness of policies as changes are made.
QosWorks has a Web caching component that reduces the demand on your WAN links. The feature worked well. However, because caching is integrated with bandwidth policies, it is difficult to exclude some sites from being cached without affecting bandwidth management.
QosWorks 10000 comes with command-line and Web-based interfaces. We found the Web-based interface to be more useful, especially with respect to the online help. The box can also be monitored via SNMP.
Access to the box is controlled by username and password. When logging on, we noticed a password prompt was returned only if a valid username was entered. This can be used to determine the names of valid accounts. Additionally, there are no access control lists to prevent unauthorized connections to the management interfaces, but Sitara has informed us that this will be addressed in a subsequent update.
Documentation comes in several PDFs. There is also a small printed manual that describes the initial installation procedures. The majority of useful documentation can be found in the user guide covering the Web-based management interface.
QosWorks 10000 is a powerful and easy-to-use appliance for monitoring and managing your bandwidth. It could be just the thing for weary network managers and their stressed-out WANs.
This story, "QosWorks 10000 does more with your bandwidth" was originally published by NetworkWorld.