Configuring Traffic Shaping¶

Traffic Shaping and queuing in pfSense® software can be accomplished in several ways. The easiest to implement is ALTQ-based shaping with the Traffic Shaping Wizard.

Traffic Shaping configuration is based at Firewall > Traffic Shaping.

Limitations¶

ALTQ shaping is not capable of setting an upper limit on traffic. Use Using Limiters to Restrict Bandwidth Usage for controller upper limits.

Wizards¶

Use of The Traffic Shaping Wizard is recommended to create a default set of rules from which to start. The rules created by the wizard cope well with VOIP traffic, but may need tweaking to accommodate other traffic not covered by the wizard.

There are several wizards available, the exact choices depend on the version in use.

As an example, look at shaping P2P traffic. Assuming the wizard was used, qP2P will exist under WAN(s) and LAN(s). When a P2P app is launched, traffic will show in these queues if it it was matched by the rules created by the wizard. These queues are designed to carry the bulk P2P traffic, which normally slows a connection down. Other generic traffic, like web pages (HTTP), email, IM, VOIP etc will go into other queues.

On current versions of pfSense software, queue sizes and bandwidths are sized appropriately for most configurations by the wizard, unlike older versions. In some cases they may need to be manually adjusted, but for the majority of cases it is unnecessary.

Multiple Lan/Wan¶

This wizard can accommodate an arbitrary number of WANs and LANs (1 or more of each). It is the best choice to use.

Dedicated Links¶

This wizard is meant for multiple WANs and LANs where specific LAN/WAN pairings do not mix traffic with others. So a single firewall manages several ‘virtual’ links through itself. For example, say providing services to 4 different customers in one building, and they each have their own separate internet connections. All 4 internet connections could be run through one pfsense box to each of the customers LAN networks and provide separate traffic shaping configurations to each.

Other Wizards¶

Other wizards may be used, if their descriptions suit the environment in which they are intended to be used. Due to a large amount of unnecessary redundancy between the various wizards, use of the Multiple Lan/Wan wizard is recommended instead as it is the only similar option available on pfSense software version 2.2 and later.

Queuing Schedulers¶

Priority Queueing (PRIQ)¶

Priority queuing is the simplest form of traffic shaping, and often the most effective. It performs prioritization of traffic only, without regard for bandwidth. A flat hierarchy of priority levels is created, all packets at the highest priority level are always processed first.

Pros

Easy to configure and understand.

Cons

Lower priority queues can be completely starved for bandwidth easily.

Class Based Queueing (CBQ)¶

CBQ is the next step up from priority queuing. A tree hierarchy of classes is created; each with an assigned priority and bandwidth limit. Priority works much in the same way that it does in the PRIQ however, instead of processing all packets from the class, it will only process enough packets until the bandwidth limit is reached.

Hierarchical Fair Service Curve (HFSC)¶

Hierarchical Fair Service Curve (HFSC) is the most complex of the ALTQ shaper types. In older versions of pfSense software, it was the only option available. It has a hierarchy of queues and is capable of real-time traffic guarantees.

It can be very effective for VoIP on links that degrade quickly, such as 3G/4G, but it can be complex to configure and tweak for proper operation.

ACK Queue Size¶

The size of the ACK Queue often needs to be adjusted with asymmetrical links since by default the size is based on both up and down speed being equal. See the later section on this article about ACK Queue Sizing

Floating Rules¶

Floating rules allow shaping rules to affect all interfaces at once. Rules there may also be set to Match which selects them for traffic shaping queues but does NOT affect whether or not the traffic is passed or blocked. These rules are evaluated before the interface rules, and are non terminating. The last floating rule that matches a stream will be the one that applies. See Floating Rules for more details on how Floating Rules operate.

Tips¶

When modifying floating rules, remember to clear the firewall states before testing changes. If the states are not cleared, traffic will not be queued properly.

Troubleshooting Traffic Shaping¶

View Queues with pfTop¶

To view live stats on traffic shaping (altq) from the command line use the following command:

pftop -s1 -v queue

Limiters¶

For information on Limiters, see: Using Limiters to Restrict Bandwidth Usage.

ACK Queue Sizing¶

When data is downloaded, a computer needs to send (upload) ACK packets. These are basically saying “yep, I got that part of the download OK”. If the computer being downloaded from detects that an ACK has not been received, it assumes that the data was not received and sends it again. The rate at which ACKs are sent back is also used to help determine the maximum speed at which data may be downloaded, so it is important that ACKs get sent as soon as possible and don’t get dropped in order to keep downloads flowing fast. Also, repeatedly dropped ACKs can result in dropped connections, web page time-outs etc.

The qACK queue is where the ACK packets are placed. This queue must have enough bandwidth to maintain downloads. By default, the wizard uses 18% of the link speed for ACKs, but that may not be ideal. To work out how much bandwidth is needed, there are two options. By experimentation, keeping an eye on the queue while downloading as fast as the connection will allow, or by using math to calculate the value. As a rough starting point, an NTL 10Mb/512Kb cable connection needs about 260-270Kb/sec of ACK packets to download at full speed.

Taking the above example, we can see that ACKs can consume 60% of the available upload bandwidth. Thus, qACK on WAN should have at least 60% bandwidth available (65% was used for the above example). If the qACK queue on WAN is set like this, there should not be any drops in that queue. However, there will be a lot in qP2P, but that’s OK. P2P upload packets are bulk traffic, not really important so it doesn’t matter if they drop a bit. qP2P will now be using what is left of the available upload bandwidth, after qACK on WAN has used up to 65%. The bandwidth allowance for qDefault on WAN may need increased as well, since this is where HTTP requests and other general uploads go if they are not otherwise matched and placed into other queues. It should also be higher priority than qP2P. Bandwidth percentages need not add up to 100%, but unless the connection is very slow, qDefault need not be large since it is mainly small requests or the odd few kb of other traffic.