Traffic shaping usenet 563?
-
By now I have studied it and indeed, you have a remarkable skill for explaining things very structured and simple; once again thank you ;D
Might I ask one thing which, due to my malfunctioning brain, I didn't quite understand?
On the other hand, the sum of all realtime value cannot exceed 80% of your total bandwidth.
But per your suggestion on setting up the queues, your 'linkshare m2 and bandwith', we don't have realtime, do we? So why the 80%?
Thank you Georgeman ;D
-
Realtime is used to set minimum guaranteed bandwidth. You didn't mention you have anything that needs a guaranteed bandwidth, that's why I invented the "web server" to set the example.
If you do want to set a realtime value for some queues, the sum of those realtime values cannot exceed 80%, but if you don't use it, is fine
You'll see that it is actually useful to further filter down the traffic and use realtime curves so, for example, your downloads or p2p don't clog up your HTTP browsing. Realtime is specially useful for things like ACKs and DNS, which benefit a lot from guaranteed bandwidth
Regards!!
-
Realtime is used to set minimum guaranteed bandwidth. You didn't mention you have anything that needs a guaranteed bandwidth, that's why I invented the "web server" to set the example.
If you do want to set a realtime value for some queues, the sum of those realtime values cannot exceed 80%, but if you don't use it, is fine
You'll see that it is actually useful to further filter down the traffic and use realtime curves so, for example, your downloads or p2p don't clog up your HTTP browsing. Realtime is specially useful for things like ACKs and DNS, which benefit a lot from guaranteed bandwidth
Regards!!
Thank you for your reply, Georgeman: appreciated once again ;D
I think I have expressed myself wrong (that happens a lot with a brain like mine :P ;D): what I didn't quite understand is how you arrive at the 80%(?)
-
The 80% value is per design. The sum of realtime values cannot exceed 80% of the parent's queue bandwidth, otherwise you'll receive errors.
-
The 80% value is per design. The sum of realtime values cannot exceed 80% of the parent's queue bandwidth, otherwise you'll receive errors.
Thank you for your reply once again, Georgeman ;D
After your most excellent explanation I tried to go the route you proposed. But I ran into a problem. I creates queues qWife, qHollander and qUsenet and assigned the 50-50-0 to them. However, Pfsense kept complaining about the child queues being more than 100% of the higher que. I figured this is because qAck also has 20%, so 120% > 100%. But qAck needs to have that, and I found a monst interesting thread (stickied above) about that qAck in my setup actually would need to be 43% on WAN and only 1% on LAN (given 20/2 is a factor 10).
So being the dumb noob that I am I am lost once again; if they can't be 50-50-0, what would you say they need to be?
Thank you for all your help very much ;D
-
Remember that the linkshare value is just a proportional value. If you say that as per your calculation you need 1% of ACK on LAN and 43% on WAN, you can create queues on LAN as:
- qACK: 1%
- qUsenet: 1% (I think it'll complain if you set it to zero)
- qHollander: 48%
- qWife: 48%
On WAN:
qACK: 43%
qUsenet: 1%
qHollander: 28%
qWife: 28%In whatever case, it is a good idea to assign that value you calculated for ACKs as a realtime curve since it is really important for you not to have drops on these queues. If you calculated 43% for ACKs, I would set a little more, let's say 48% as realtime and 5% or whatever as linkshare for the qACK queue on WAN (make sure the sum of linkshare does not exceed 100%)
Regards!
-
Thank you once again for your most excellent, and too kind, help, Georgeman: I am in your debt :P
I tried it again, and you will guess it: it doesn't work :-[
I have created several screenshots and combined them into one that I have attached.
As you can see, the traffic is not assigned to the right que once I have the usenet download server running. Everything stays in the same queue. I am also struggling with the floating rules, and I noticed something strange. The two disabled rules you see in the screenshot are those the wizard generated. The only thing I did was change these rules to change the port to 563. And then it worked. At least traffic came in the right queue due to the port. Already, in these wizard rules, when I added the source-IP (192.168.2.21) and left the ports empty, it didn't work (just as now, with my newly created rule based on your guidance). So that is one problem: the assignment based on SRC IP doesn't appear to work.
The other thing that is strange is that although you can see in the screenshot that the first wizard rule has qACK/qOthersLow, this is [b]not what the rule contains. Because there it only says: qACK/none (screenshot).
Finally, I have attached my floating rule that doesn't work. And I've noticed that the wizard has created two rules for the NNTP-traffic, but I don't know why. I created one with protocol is 'any', this should do the same, shouldn't it?
-
And finally my own firewall rule. Sorry it is slightly difficult to read, as I had to zoom out to get it all on one screen :-X
-
And of course I forgot: thank you very much for helping me out Georgeman ;D
-
I thought perhaps it would be wise to make some screenshots of how I've set up the queues ;D
-
@Hollander:
the assignment based on SRC IP doesn't appear to work.
Yep! And that's right. The reason behind this is that by the time the packet reaches the WAN interface, NAT has already ocurred, so in fact there are no packets with the private IP address to be seen by the rule (it has already been translated).
In order to queue based on the source IP, you need to create the rule on the LAN interface, direction IN. The rest is the same.
As regards the weird rules: sometimes this happens when you modify the queues after the rules were created. Just delete and recreate the rules. Bear in mind that you can only select an acknowledge queue if you also select a regular queue (as the little snippet explains)
-
And once again thank you, thank, thank you, Georgeman ;D
I didn't quite understand this:
The reason behind this is that by the time the packet reaches the WAN interface, NAT has already ocurred, so in fact there are no packets with the private IP address to be seen by the rule (it has already been translated)
But this is incoming (downloading from usenet), so it comes in on the WAN, and after that there needs to be NAT, not before(?)
With regards to this:
In order to queue based on the source IP, you need to create the rule on the LAN interface, direction IN. The rest is the same.
I tried that, but when I want to create a rule on LAN there is no 'match' under 'Action', only block/reject/pass. The floating rules the wizard creates on the other hand have 'Action = match'.
And finally:
Bear in mind that you can only select an acknowledge queue if you also select a regular queue (as the little snippet explains)
I actually don't have a clue why there are two fields there. I do understand what ACK is, but after that I am lost as to why you need to enter two values there, and what they do in the first place. I do have the Pfsense 2.0 book, but unfortunately that doesn't discuss this, and googling for quite some time also doesn't tell me what it is.
I've also send you a PM, btw ;D
Thank you once again Georgeman; the debt keeps on building up ;D
-
The idea behind this traffic shaper is actually to get firewall states tagged as belonging to a specific queue. If you tag an incoming traffic on LAN (request to the internet), then the corresponding traffic incoming on WAN (the actual data download) will be put on the queue with the same name, on WAN, since it belongs to a state already tagged (and this is why the queues on LAN and WAN have the same names).
In fact, the floating rules the firewall creates are actually direction out on interface WAN. So this means that traffic leaving the WAN is what is being matched, not the incoming traffic. Since all traffic incoming on WAN must have been requested from inside, tagging on LAN also works. Also consider that if you do have unsolicited traffic coming in from WAN (a port forward for example), then you need to tag this incoming traffic explicitely on your firewall rules.
On your specific case, what you need to do is create a floating rule, action match interface LAN, direction IN, source IP: your usenet server IP, which assigns the traffic to the appropriate queue.
Does the server accept connections directly from the outside? In that case, you also need to make the NAT rule create an associated filter rule. and then modify that rule on WAN and make it assign the right queue.
On a side note, this same thing could be achieved without floating rules. Pass rules on the interfaces can also assign queues to matching traffic, so you could add a rule on LAN, action pass, above the default allow all rule, with the right queues set and it will be the same thing.
–----------
Regarding the "two queues assignment": the "acknowledge" queue allow you to specify a different queue that will be used for TCP SYN and ACK packets. Usually this is a higher priority queue. This means that for an existing state matching this rule, regular packets will go into the regular queue, and related TCP SYN and ACK packets will go into the acknowledge queue. Of course it does not make sense to specify just the acknowledge queue because if you do so, where the "regular" packets will go?
-
@Hollander:
Thank you once again for your most excellent, and too kind, help, Georgeman: I am in your debt :P
I tried it again, and you will guess it: it doesn't work :-[
[/quote]Hello,
Did you manage to get this finally working ?
I'm interested because I'm only using basic rules for my VoIP … that are working.Tx !
-
@Hollander:
Thank you once again for your most excellent, and too kind, help, Georgeman: I am in your debt :P
I tried it again, and you will guess it: it doesn't work :-[
[/quote]Hello,
Did you manage to get this finally working ?
I'm interested because I'm only using basic rules for my VoIP … that are working.Tx !
What I want not yet, no. But I have reasons to believe shortly it will work. But the default traffic shaping is working (again, I wanted something a little bit different). So you might considering trying the default; simply go through the wizard and raise the priority for VOIP, and then see what happens. Perhaps this works for you too :D