Quality of service (QoS) is one of those amorphous terms thrown around a lot. It seems we all want QoS, but what it means, what it does for us, and how we're going to get it is unclear. You hear QoS most frequently in two contexts. The first is voice over IP (VoIP), where the VoIP consultant says, "If you don't have QoS, I can't guarantee that this will work correctly." The second is download controls, where a manager says, "Can't we...
limit downloads to keep the Internet link responsive?"
In both cases, the answer is: network bandwidth management. Network engineers see bandwidth control and management as one part of QoS. In smaller networks, guaranteeing or limiting bandwidth is as much QoS as we need. The best place to do network bandwidth management is at the edge of the network, which usually means on the firewall that sits between your network and the Internet. Here are five quick tips to help you apply QoS controls on the edge firewall.
- Figure out how you're going to identify the traffic you want to control. If the firewall is going to guarantee bandwidth, then you will probably need to configure certain traffic with certain guarantees. Identifying the traffic you want to guarantee is easier if you use IP addresses. For example, if you are trying to guarantee bandwidth for your VoIP devices, then group them together and use IP addresses to identify their traffic. Trying to use TCP and UDP port numbers can backfire, because many types of multimedia traffic (such as VoIP) require a properly functioning application-layer gateway in the firewall to separate traffic -- and these ALGs often don't function properly. IP addresses are a sure thing.
- QoS guarantees only matter in a time of scarcity. A firewall won't be able to guarantee a certain bandwidth unless it thinks the circuit is fully loaded. One of the most common errors I see in firewall QoS configuration is forgetting to put in the actual upstream bandwidth to the firewall. Without this number, the firewall can't tell when you are fully utilizing the link, and no QoS will work. If it's an Ethernet drop to your ISP, the bandwidth probably isn't 100 Mbps or 1,000 Mbps, instead it's whatever upstream bandwidth you're paying for. Put in the true bandwidth, not the Ethernet port speed.
- Firewalls can only guarantee bandwidth outbound, not inbound. Your QoS can only be managed in the upstream direction. Once the traffic has reached your firewall, it's already gone over the slowest link, and it's too late to effectively shape the traffic. If you want QoS to guarantee bandwidth in both directions, you're going to have to get your ISP to help by prioritizing or controlling traffic before it's sent over the link to your business.
- Most effective QoS is about guaranteeing bandwidth. Trying to limit bandwidth -- another oft-asked-for feature -- is a tricky thing, and may or may not be very effective. Bandwidth limits can only really work with TCP-based protocols. Bandwidth limiting UDP traffic means simply dropping the packets on the floor, and depending on the application, could mean simply flooding even more and more packets into the network to try and get the traffic through. Concentrate on TCP if you want to apply bandwidth limits. Good firewalls, when applying bandwidth limits, will actually reach into the TCP data stream and delay ACK packets to slow things down, which keeps the application happy and avoids pathological flooding behaviors that work against what you're trying to accomplish.
- Don't get carried away. Edge firewalls are firewalls, not QoS enforcement devices, no matter what the glossy brochure or PowerPoint said. If you want sophisticated controls and reporting, look to QoS-centric devices, such as the Blue Coat PacketShaper or any of its competitors. Cisco routers also have some powerful bandwidth management tools, although almost no reporting. If you have those on either side of your firewall, you may be able to use them to apply controls the firewalls can't.
Joel Snyder is a senior partner at Opus One, an IT consulting firm specializing in security and messaging.
Send comments on this technical tip email@example.com.
Join us on LinkedIn.