LANs /

Do more with your bandwidth

Sitara Networks' QosWorks 10000 provides powerful quality-of-service features.

By Chris Griffin and Greg Goddard

Also: How we did it Scorecard and NetResults

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 100M bit/sec and has an integrated Pentium III 600-MHz processor, dual 10/100M bit/sec 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 100M bit/sec. 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 10M-bit/sec WAN, using NetIQ's Chariot software to generate traffic between both networks. We generated a total of 25M bit/sec 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% 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%. On the other hand, SMTP received the bandwidth it needed using only half of its 20% 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% of the link remained idle from the unused SMTP bandwidth.

To test the full capacity of the box, we changed the WAN connection to 100M bit/sec. 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 10M bit/sec of SMTP traffic, and 30M bit/sec each of FTP and HTTP traffic, as well as 50M bit/sec of UDP-based RealVideo streams. We created policies that gave FTP 30% of the bandwidth; SMTP and HTTP, 20% each; with the remaining 30% 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 30M bit/sec, 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 20M bit/sec maximum as we had configured.

Finally, we added a voice-over-IP call while attempting to transfer a 50M-byte file across the WAN. We altered the policies to reserve 5% of the bandwidth for voice-over-IP devices, and an additional 10% 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.

---

RELATED LINKS