Bandwidth Management


One common task for a firewall to perform is bandwidth management. Not only do you want to be able to control how much bandwidth is used for certain tasks, you need to be able to reserve bandwidth for vital functions. If someone really does load the next Harry Potter script on your web server you need to be able to SSH in, find out why your server is running so slowly, and fix the problem. PF includes a large chunk of the ALTQ bandwidth management system. While some aspects are not yet completely integrated as this is written, work is in progress. We will only discuss those portions that are integrated and stable as of this writing. As with the rest of PF, check the manual pages for the latest details.

The most important thing to remember with bandwidth management is that you cannot control how much traffic enters your network. Traffic can be stopped at the first point it enters the network, but it cannot be stopped before it enters your network. You might restrict your web server to serving 1.4MB/second with ALTQ, but that won't stop ten thousand people a second from clicking on a link to that server. The best you can do is restrict how you respond to those requests.

The only way to restrict incoming traffic is to block it before it reaches you. If you control the routers upstream of this web server (e.g., if you're in an ISP environment), you may be able to implement bandwidth controls there.

Note

While memory and hard disks are usually measured in multiples of bytes, network traffic is almost always measured in bits. One byte is eight bits. Do not confuse bits and bytes!

Queues

ALTQ manages bandwidth in queues. A queue is just a list of packets waiting to be processed. By breaking your traffic up into separate queues, and processing those queues under different conditions, you can manage server bandwidth. Queues are somewhat like the checkout lines at the grocery store; some lines are for ten packets or less, and supposedly get you out quickly, while others are for people whom only shop once a month but fill up three carts. You can define just about any characteristics for packet queues, as if you could create a "meats only" or a "white wine with fish" register. (Unlike grocery store customers, packets have no choice but to respect the queues they're assigned to.)

Queue Types

Queues can be handled in any number of different ways, and the most proper method for any situation is a very thorny topic. TCP/IP quality of service queue handling is one of those topics that makes small children cry and fish fly over mountains in an effort to escape the discussion. By default, OpenBSD (and all BSD-based systems) use First-In First Out queuing, where packets that are received first and processed first. Newer packets wait in a queue for their turn to be processed.

OpenBSD also supports Priority Queuing (PRIQ), where packets of a certain type are considered to have "priority" and are processed first. This means that if you assign web packets highest priority, all web packets gets to jump to the head of the queue. Packets of lower priority may never be processed at all under this scheme.

In almost all operational settings where you want to regulate bandwidth, however, Class-Based Queuing (CBQ) is appropriate. CBQ allows the network administrator to allocate a certain amount of bandwidth to different type of traffic through hierarchical classes. Each class has its own queue, with its own bandwidth characteristics. You can assign different sorts of traffic to different classes — SSH traffic to one class, HTTP traffic to another, and so on. One of the nice features of CBQ is that its hierarchical nature allows lower classes to borrow bandwidth from classes above it, if the bandwidth is available.

PRIQ and CBQ are mutually exclusive; you cannot enable both sorts of queues on a single interface. Both CBQ and PRIQ require a parent queue to define basic facts about how traffic passes through the system.

Queue Options

OpenBSD can process queues in a variety of ways through the use of options. Options allow a queue to decide how to respond to a variety of bad network conditions and bandwidth availability.

Default

Every parent queue must have one and only one default child. If a packet is assigned to no other queue, it is assigned to the default queue.

Control

This queue is used for network control packets, such as ICMP, IGMP, RSVP, and so on.

Red

Random Early Detection is a method for handling packet loss when a queue is full. If you fill up your queues, packets will start to drop. By enabling RED, PF will drop packets proportionately to the queue length. Data streams with long queues will drop more packets than data streams with short queues. The net effect is that short transfers, such as HTTP requests and interactive SSH sessions, will respond more quickly, while larger transfers will become slower. Random Early Detection is a very complicated system, however, and don't think that it will solve all your interactive connection problems. Before you begin implementing RED everywhere, I strongly suggest reading "Random Early Detection (RED) Gateways for Congestion Avoidance" by S. Floyd and V. Jacobson. Your favorite search engine will lead you to a dozen copies of this classic paper, but a good site is at http://www.icir.org/floyd/papers/red/red.html.

ECN

Explicit Congestion Notification is an addition to RED that allows devices along a connection path to notify the client and the server that the network is experiencing congestion and to slow down transmission rates. Not all devices speak ECN, however, so it's best to know that everything involved in transactions along this queue won't have trouble with ECN before enabling it. For full details on ECN, read RFC3168.

Borrow

The "borrow" option is only available in CBQ. A queue with the "borrow" option may borrow bandwidth from its parent queue, if the bandwidth is available. For example, you might have a queue reserving 20 percent of your bandwidth for HTTP. If you don't have that much HTTP traffic at the moment, the parent will have excess traffic available. Other queues could "borrow" bandwidth from that allocation. The second you need that bandwidth for HTTP traffic, the bandwidth loan is revoked and the HTTP traffic gets priority. This option is what makes CBQ so desirable in most circumstances.




Absolute Openbsd(c) Unix for the Practical Paranoid
Absolute OpenBSD: Unix for the Practical Paranoid
ISBN: 1886411999
EAN: 2147483647
Year: 2005
Pages: 298

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net