Defining Class-Based Queues

Class-based queueing is much more interesting than priority-based queueing. Start by enabling CBQ on your system's Internet-facing Ethernet interface:

 altq on fxp1 1 cbq bandwidth 2 100Mb queue { 3 local, 4 t1} 

As we state that we're using 1 CBQ on this interface, all child queues are also CBQ queues. This particular queue has 2 100Mb of bandwidth, and two child queues: 3 local and 4 t1. We do not bother defining tbrsize or qlimit. Once you have a parent queue, you can define the children. CBQ queues are defined with the following syntax:

 queue queue-name bandwidth bandwidth priority priority cbq(options) {child-queue4, child-queue5} 

Like PRIQ, each queue must have a unique name.

The bandwidth term uses the same bandwidth labels that the parent queue uses, but the value cannot exceed the total amount of bandwidth available on the parent queue. Child queues can also use a percentage value for bandwidth, indicating the percentage of the parent queue that this queue can consume. Bandwidth and queue are the only mandatory terms in a child queue description. Here we set the "local" queue to have a bandwidth of 98,456Kb ^[2]:

 queue local bandwidth 98456Kb 

The total bandwidth of all child queues should add up to the bandwidth of the parent. The parent queue is 100 megabits per second, or 100,000,000 bits per second. We have a comparatively small amount of bandwidth remaining for our other queue:

 queue t1 bandwidth 1544Kb 

Anyone who has worked on a WAN should recognize the size of the bandwidth queue here — 1,544 kilobits per second is the maximum throughput of a standard T1 circuit. The Ethernet card on the outside of our firewall might be able to handle a hundred megabits a second, but the circuit to our Internet provider almost certainly cannot. We have lots of local bandwidth to our local Ethernet, however, so we want to handle that separately. You could easily edit these numbers to fit your particular situation. We will make further queues for Internet traffic, all children of the t1 queue. But first, let's look at our local queue.

We set aside a queue for systems on our local Ethernet but outside our firewall, so that the bandwidth limits we placed on the circuit will not affect our connections to hosts outside our firewall. Let's expand this rule to make it do what we want.

Then we can assign a priority to a queue. CBQ priorities run from 0 to 7, with 7 being the highest. The default priority is 1. A CBQ queue with a higher priority does not run to the exclusion of other queues, but it is processed more quickly than other queues. Going back to the grocery store analogy for a moment; if you give a queue a high priority, it's like assigning a faster cashier to that line. Each packet will pass through the queue more quickly than it would get through another queue, but other queues will still be processed. We don't really need to assign a priority to our local queue.

We then have options for how CBQ behaves, as discussed in "Queue Options." To enable an option, put the algorithm it applies to, and then the options in parenthesis. For example, our "local" queue can borrow extra bandwidth from the parent queue, if it is available.

 queue local bandwidth 98456Kb cbq(borrow) 

This queue is now complete. If you wanted to allocate bandwidth on that local network you could do so, but generally this is a waste of time. We just need to write a PF rule that will direct all connections to the local network outside the firewall to this queue. We'll see how to do that in "Queue Assignment."

Subdividing a CBQ Queue

Before you write your rules, decide how you want to divide your Internet bandwidth. While you could use bits per second to measure bandwidth, generally speaking percentages are easier to deal with for such things. Here's how I might divide up Internet bandwidth for a small company. Start by writing down your desired results, and then assign a name to each queue

• 5% of our bandwidth is reserved for SSH sessions (ssh).

• 25% of our bandwidth is reserved for inbound HTTP requests (http-in).

• 25% is reserved for outbound HTTP request, with Random Early Detection (http-out).

• 20% is reserved for email (mail).

• 4% is reserved for DNS (dns).

• 20% is reserved for FTP (ftp).

• 1% is reserved for any other traffic (misc).

• All of these connections may borrow from their parent queue.

Because all of these are children of the t1 queue, the t1 queue is their parent. Just as we did with the initial parent queue, list these children in braces at the end of the rule;

 queue t1 bandwidth 1544Kb {ssh, http-in, http-out, mail, dns, ftp, misc} 

Now create a definition for each child queue:

 queue 1 ssh bandwidth 2 5% 3 priority 7 4 cbq(borrow) 

We start with the 1 queue name and the 2 bandwidth percentage we've selected. This percentage is taken from the parent of this particular queue, so we've allocated 5 percent of 1544 Kb per second, or about 77 Kb per second. This is faster than a 56 Kbps modem, and should be enough to do any interactive task in the event of a bandwidth flood. Because this queue is the most likely to be vitally needed in case of emergency, we're going to increase its 3 priority dramatically. Finally, we allow this queue to 4 borrow available bandwidth from other queues. We can use more than 77 Kb/second for SSH, but that much will always be available at the server. ^[3] Given this example, our other queues are very simple to create:

 queue http-in bandwidth 25% cbq(borrow) queue http-out bandwidth 25% cbq(borrow, red) queue mail bandwidth 20% cbq(borrow) queue dns bandwidth 4% cbq (borrow) queue ftp bandwidth 20% cbq(borrow) queue misc bandwidth 1% cbq(borrow) 

Now that we have rules to describe our desired maximum bandwidth usage, we have to somehow get the traffic into these queues.

^[2]98,456 kilobits per second? What sort of half-baked bandwidth limit is that? It's a hundred megabit, minus a T1. You do want to treat your Ethernet outside the firewall differently than the T1 bandwidth, no?

^[3]Of course, if other sorts of requests (such as a denial-of-service attack) flood the circuit itself, this SSH connection queue is useless. Never forget that.