Traffic Shaping Config Sharing
-
Anyone willing to share their Traffic Shapping configuration that works for them?
I'm too new with this so I'm not sure how to configure this. If someone share me theirs that works for them. It would help me learn quickly.
thank you
-Cardin
-
I suspect that the Wizard has provided you with a basic setup for both incoming and outgoing traffic. However, I recommend to use the traffic shaper only for traffic going from a higher bandwidth link into a lower bandwidth one (in other word, only traffic going into a bottleneck, not coming out of one - that traffic has already been throttled at a point probably outside your control).
Your WAN speed is 50/10. So, if your LAN speed is above 10MBit/s, you'll need outbound traffic shaping. If your LAN speed is above 50MBit/s, you won't need inbound traffic shaping. I will assume that your setup satisfies these criteria (like about everything deployed in the last 10 or 15 years).
As you mentioned "realtime" parameters, I assume that your chosen discipline is HFSC. This is the most complex traffic shaping discipline. It's poorly documented, but quite promising. Keep it.
Via "Firewall: Traffic Shaper", you can navigate to the "Queue Tree". Click the LAN root node and simply uncheck the "enable/disable" checkbox to leave inbound traffic unrestricted. Your clients can drain the pipe faster than the 50Mbit downlink can fill it up, so I don't expect any congestion there.
This will reduce complexity a bit, as we only need to concentrate on outbound traffic. You can still re-enable these queues at some later point of time if you need to "discipline" some specific users or downloads. It may appear a bit counter-intuitive, as you want faster downloads, but the fact is that shaping the uplink is the key to faster downloads.
In the WAN root node, verify that it's enabled, the discipline is HFSC and the bandwidth is set to 9 Mbit/s (for a start, you might later on try tweaking it closer to 9500kbit/s - or downward, if you cannot reliably get 10Bit uplink speed from your ISP).
One down into the tree, click the qACK queue. Enter 6 for priority. Place a checkmark at real-time, enter 1.5Mb into the realtime-m2 box. That is the conventional estimate: 3% of the downlink bandwidth is required on the uplink to transmit ACKs fast enough, so the server won't reduce it's speed for your downloads. I also enable the linkshare parameters, entering 50% into the linkshare-m2 box there.
Next, qDefault quere. I simply enter 10% into the bandwidth option box there. Priority is 3.
qP2P: set priority to 1, enable upperlimit, enter 50% into upperlimit-m2, enable linkshare, enter 5% into linkshare-m2.
qGames: that one I am not sure about. I'll give you my current parameters. priority=5, realtime enabled, m1=30kB, d=10, m2=30kB, linkshare enabled, m2=20%. As you may have more gamers online simultaneously, yoo might consider to raise the 30kB to 300kB or even more. As this is HFSC, bandwidth is not exclusively dedicated to a queue, but can be used by other queues if not in use.
qOthersHigh: priority=4, linkshare enabled, m2=10%.
qOthersLow: priority=2, linkshare enabled, m2=5%.
Now that the queues are set up, we need to get the traffic filters configured to get the right traffic into them. Navigate to "Firewall: Rules" and click the LAN tab. You will (hopefully) see the default "allow any" rule. It should have the "qACK/qDefault" queues assigned. If not, edit it so it uses these two ques for ACKs and the "default traffic".
The other filters will configured as floating rules. Click the "Floating" tab. You'll probably see a whole lotta rules there, provided to you by the Wizard. In my case, I deleted all inbound floating rules for better overview, but you may choose to simply disable them, if you want. I assume that you can now modify the existing rules and setup new ones, based on the ideas in your Tomato screenshots. Note that I'd leave out any L7 (Layer 7) rules used in Tomato; they might not be worth the effort (and L7 filtering has a performance impact).
As you mentioned issues with P2P traffic, the idea to assign all not otherwise classified UDP traffic as P2P traffic could have merits. Some users are clever enough to change the ports used by their P2P clients. That filter might look like that:
Action: match
Interface: WAN
Direction: any
Protocol: UDP
Source, Destination, Ports: any
Ackqueue/Queue: none/qP2PThis rule should be on TOP. Floating rules are evaluated from top to bottom, and the last matching rule wins (unless a rule with the "quick" checkbox checked has been matched earlier on; a "quick" rule stops evaulation of any further rules). As the "all UDP traffic" rule would also catch online gaming traffic, we need to make sure that the more specific rules will override it. Note that some overly clever guy may still configure his BT client to use port 27015, getting his P2P traffic into the games queue…but that would a abuse calling for "real-life measures", IMHO.
-
I suspect that the Wizard has provided you with a basic setup for both incoming and outgoing traffic. However, I recommend to use the traffic shaper only for traffic going from a higher bandwidth link into a lower bandwidth one (in other word, only traffic going into a bottleneck, not coming out of one - that traffic has already been throttled at a point probably outside your control).
Your WAN speed is 50/10. So, if your LAN speed is above 10MBit/s, you'll need outbound traffic shaping. If your LAN speed is above 50MBit/s, you won't need inbound traffic shaping. I will assume that your setup satisfies these criteria (like about everything deployed in the last 10 or 15 years).
As you mentioned "realtime" parameters, I assume that your chosen discipline is HFSC. This is the most complex traffic shaping discipline. It's poorly documented, but quite promising. Keep it.
Via "Firewall: Traffic Shaper", you can navigate to the "Queue Tree". Click the LAN root node and simply uncheck the "enable/disable" checkbox to leave inbound traffic unrestricted. Your clients can drain the pipe faster than the 50Mbit downlink can fill it up, so I don't expect any congestion there.
This will reduce complexity a bit, as we only need to concentrate on outbound traffic. You can still re-enable these queues at some later point of time if you need to "discipline" some specific users or downloads. It may appear a bit counter-intuitive, as you want faster downloads, but the fact is that shaping the uplink is the key to faster downloads.
In the WAN root node, verify that it's enabled, the discipline is HFSC and the bandwidth is set to 9 Mbit/s (for a start, you might later on try tweaking it closer to 9500kbit/s - or downward, if you cannot reliably get 10Bit uplink speed from your ISP).
One down into the tree, click the qACK queue. Enter 6 for priority. Place a checkmark at real-time, enter 1.5Mb into the realtime-m2 box. That is the conventional estimate: 3% of the downlink bandwidth is required on the uplink to transmit ACKs fast enough, so the server won't reduce it's speed for your downloads. I also enable the linkshare parameters, entering 50% into the linkshare-m2 box there.
Next, qDefault quere. I simply enter 10% into the bandwidth option box there. Priority is 3.
qP2P: set priority to 1, enable upperlimit, enter 50% into upperlimit-m2, enable linkshare, enter 5% into linkshare-m2.
qGames: that one I am not sure about. I'll give you my current parameters. priority=5, realtime enabled, m1=30kB, d=10, m2=30kB, linkshare enabled, m2=20%. As you may have more gamers online simultaneously, yoo might consider to raise the 30kB to 300kB or even more. As this is HFSC, bandwidth is not exclusively dedicated to a queue, but can be used by other queues if not in use.
qOthersHigh: priority=4, linkshare enabled, m2=10%.
qOthersLow: priority=2, linkshare enabled, m2=5%.
Now that the queues are set up, we need to get the traffic filters configured to get the right traffic into them. Navigate to "Firewall: Rules" and click the LAN tab. You will (hopefully) see the default "allow any" rule. It should have the "qACK/qDefault" queues assigned. If not, edit it so it uses these two ques for ACKs and the "default traffic".
The other filters will configured as floating rules. Click the "Floating" tab. You'll probably see a whole lotta rules there, provided to you by the Wizard. In my case, I deleted all inbound floating rules for better overview, but you may choose to simply disable them, if you want. I assume that you can now modify the existing rules and setup new ones, based on the ideas in your Tomato screenshots. Note that I'd leave out any L7 (Layer 7) rules used in Tomato; they might not be worth the effort (and L7 filtering has a performance impact).
As you mentioned issues with P2P traffic, the idea to assign all not otherwise classified UDP traffic as P2P traffic could have merits. Some users are clever enough to change the ports used by their P2P clients. That filter might look like that:
Action: match
Interface: WAN
Direction: any
Protocol: UDP
Source, Destination, Ports: any
Ackqueue/Queue: none/qP2PThis rule should be on TOP. Floating rules are evaluated from top to bottom, and the last matching rule wins (unless a rule with the "quick" checkbox checked has been matched earlier on; a "quick" rule stops evaulation of any further rules). As the "all UDP traffic" rule would also catch online gaming traffic, we need to make sure that the more specific rules will override it. Note that some overly clever guy may still configure his BT client to use port 27015, getting his P2P traffic into the games queue…but that would a abuse calling for "real-life measures", IMHO.
thank for your guidances. It helps me understand alot ….....would buy you a bear if you're around Seattle-olympia area.
=)
-Cardin
-
oh yeah do you mind sharing your
firewall rules
and traffic shapping?
posting up the saved version so I can restore and play with it?
-
What changes are there now that the newer version of pfsense is out? (pfsense 2.3)
-
Great write-up Klaws!!
-
A simple forum search will get you several posts on some complete traffic shaping configs.