==== Wizards ====
PFSense 2.0 includes multiple wizards that setup the traffic shaping for various usage scenarios. It is recommend to start out with one of the Wizards since having a known starting point makes support easier.
=== Single Lan multi Wan ===
This will setup the traffic shaping for the case where you have one local network and multiple WAN networks.
=== Single Wan multi Lan ===
This will setup the traffic shaping for the case where you have multiple local networks and one WAN network.
=== Multiple Lan/Wan ===
This will setup the traffic shaping for the case where you have both multiple local networks and multiple WAN networks.
=== Dedicated Links ===
(I can only guess on the specific purpose of this wizard, please fill in usage info).
=== Creating new Wizard templates ===
Wizard configuration files are located under /usr/local/www/wizards.
==== 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.
==== Floating Rules ====
==== Limiter ====
The limiter allows you to setup Dummy Net pipes. One of the features of dummynet pipes is the ability to limit bandwidth that flows through the pipe. You can also add delay and packet loss if you so choose.
Once you setup a limiter pipe, the next step is to assign traffic to it by setting the "in/out" option in a rule.
* Dummy Net documentation: http://www.dummynet.com/
==== Layer 7 ====
==== Example Scenarios ====
=== Example 1 ===
==== Rules ====
Revision Edited on 2009-07-13 14:21:33 by JoshStompro [Skeleton of pfsense 2.0 traffic shaping guide.]
Revision Edited on 2009-02-15 00:22:57 by JimP [Skeleton of pfsense 2.0 traffic shaping guide.]
It is recommened that you use the Traffic Shaping Wizard to create a default set of rules from which to start. The rules the wizard creates can sometimes cope well with VOIP traffic, but need tweaking to accomodate other traffic.
As an example, let's look at shaping P2P traffic. Assuming you used the wizard, there will be qP2Pup and qP2Pdown created already. When you launch a P2P app, you should see traffic in these queues. They are designed to carry the bulk P2P traffic, which normally slows your connection down. Other generic traffic, like web pages (HTTP), email, IM, VOIP etc will go into other queues.
Initially, the wizard sets all queues to 1% bandwidth. This is not enough. In particular, the queue qwanacks certainly needs more bandwidth if you do a lot of downloading. First, a quick note about ACK packets.
When you download, your computer needs to send (upload) ACK packets. These are basically saying "yep, I got that part of the download OK". If the computer you are downloading 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 that you can download data at, so it's important that ACKs get sent as soon as possible and don't get dropped in order to keep your downloads flowing fast. Also, repeatedly dropped ACKs can result in dropped connections, web page time-outs etc.
When you download, qwanacks is where the ACK packets your computer sends out go. You need to make sure this queue has enough bandwidth to maintain your downloads. To work out how much bandwidth you need, there are two options. You could simply experiment, keeping an eye on the queue while downloading as fast as your connection will allow, or you could try and work it out. 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, qwanacks should have at least 60% bandwidth available (I use 65% for the above). If you set qwanacks like this, you should not see any drops in that queue. However, you will see a lot in qP2Pup, but that's OK. P2P upload packets are just bulk traffic, not really important so it doesn't matter if they drop a bit. qP2Pup will now be using what is left of the available upload bandwidth, after qwanacks has used up to 65% of it. You will probably want to increase the bandwidth allowance for qwandef as well, since this is where HTTP requests and other general uploads go, which chances are you want to be higher priority than qP2Pup. Bandwidth percentages need not add up to 100%, but unless you have a very slow connection you don't need too much for qwandef since it is mainly small requests or the odd few kb of email.