New Traffic Shaper - What works correctly or makes sense?
-
after lot of trial and error i manged to get it working but to my experience, the shaper in 1.2.3 was much smoother in operation than the one in 2.0 as in 1.2.3 i used to give 25% of my bandwidth for voip and when p2p apps were downlaoding, it never used to give me choppy audio on the voip phone and currently with 2.0 shaper, i have given 50% of bandwidth for voip and now if ppl use p2p, latency on voip goes higher and still there is choppy audio every now and then so i have to use limiters, queues with max bandwidths etc etc to do the shaping and yet i dont understand the proper way of creating rules, the directions etc, just managed to get it running with a lof of trails and vieweing traffic in queues so im assuming its working, not sure though.
it would be better if documented with beginners in mind using scenarios such as:
this way u create a rule to put uplaod of a client to a specific queue, it should be under the xxx tab, the direction etc etcabove coz i created a rule under the lan tab that says source as lan ip and destination as * but this rule is considered as download for the client, never been able to understand how coz if i throw a ball at u so im the source and ur the destination so isnt that supposed to be an upload rather than download?
-
I am not sure why this has to come shouting right now!
There was a very long thread in the bounty section about the shaper and i explained most of the things there.
A rewrite to give full potential does not mean that it will work the same in 1.2.x because it really it was not the way to implement it.Surely, it is more complex/flexible now and it needs a user guide that i thought was clear enough during the bounty.
Either way. The explanation is based on what is drawn on the attached figure and what the wizard actually create.
These are the rules of the system:
1- A packet is queue only when going out an interface.
2- A packet WILL ONLY be queued on one queue and ONLY one leaving an interface.
3- A queue can be selected on any part of the system incoming on an interface processed by the filter or outgoing an interface, BUT it will be enforced only when leaving an interface.With all said this is the normal flow of a packet on pfSense for teh shaper.
Remember the queue would be enforced on outgoing:
1- packet comes in on LAN
2- matches a rule without any queue setup, creates respective state, continues flow
3- it goes outside WAN interface
4- it matches a rule with a queue(qHigh)
5- the matched rule marks the packet to go to that queue(qHigh) and records this in the state just created
6- packet goes finally out of WAN(gets queued on the WAN qHigh queue)
7- response packet comes in on WAN
8- matches the previous state created and finds a queue(qHigh) has to be attached
9- marks the packet with the queue(qHigh)
10- packet goes ouside LAN interface
11 - it matches the state created previously, since there is no queue it does not take any action
NOTE: this means that the decision taken on WAN for queue(qHigh) still prevails
12- it goes to the queue(qHigh) marked since it came in on WAN(if it can find it of course)
13-finally goes out of LAN(gets queued on the LAN qHigh queue)That is the reason that the queues by the wizard are created with the same name on LAN and WAN it is not just a cosmetic coincidence.
Now on 2.0 each filter rule has the option to choose 2 queues for matching packets.
One is for the ACK queue and the other the normal data queue. Be aware that the ACK queue only makes sense for TCP traffic and it is the best usage to create rules for TCP traffic with ACK queue separately from other protocol rules.
So from the 2 dropdowns that you can select in the rules section the first can be selected for ACK queue and the other for the data queue(that is why the section has ACKqueue/queue).The wizards normally create rules on the Floating section with direction outgoing because that is the most safest option to automatically generate without stamping on other user rules.
Though the user rules can override the selection done form the rules(automatically created by the wizard) thus invalidate the queue selection.
And if a rule does not match it cannot select a queue. THIS is the dificulty the user configuration has in 2.0, since you need to be aware that when you create a new firewall rule you can break you shaping strategy.Now tell me what YOU DO NOT UNDERSTAND to facilitate your brain!
-
Ermal,
Thanks for your reply. I don't doubt that the shaper in 2.0 functions as it should; my problem at present is that I simply don't understand how to use it entirely and I think the UI needs work in that regard. That's not a criticism of you or the work that you've done, but a call to the community to put our heads together to work on improving that. I think your participation will be critical though, as I have yet to see anybody else on the web or forum that understands the shaper to the extent that you do.
I'd like to propose a few things that need to be improved or clarified, for the purpose of moving forward.
1. The wizard for multi-LAN doesn't create any queue on the LAN or OPT interfaces.
2. The multi-LAN wizard prompts user to "Setup connection speed and scheduler information for interface #1". This is the 'conn0upload' that SlickNetAaron mentioned. The problem here is that it is not clear to the user which queue he is setting up here.
3. The floating interface appears in the firewall:rules section without explanation. This is confusing to the new user. In fact, I think anybody that is using the shaper in 2.0 at this point is doing so under the assumption that any queuing or classification has to be done on the floating interface. It appears from Ermal's previous post that this may not be the case, although I am still unclear as to why. Ultimately, I think we need to clarify the role and purpose of the floating rules.
4. The floating rules have the option to "Apply the action immediately on match", while rules on the real interfaces do not. In fact, I believe this option ("quick"?) is automatic and hidden on the other interfaces. At present most or all of the queuing rules I have created on the floating tab function only when I activate this option, so again, I'm not sure why it's there.
5. The wizard creates floating rules without selecting an interface. In my experience, I cannot select a packet based on a source IP in a local subnet unless I choose "LAN" as the interface. I also have a rule where I have chosen WAN as the interface, and I don't recall why, although I believe the rule to be queuing traffic as desired.
6. When an interface is selected in a floating rule, that rule is placed at the top of the rules list, above rules which have no selected interface, and is therefore evaluated first. I have been able to work around this, but I don't understand it.
7. I'm not sure the purpose of choosing direction in my floating rules. As Ermal explained, queues only leave a given interface. My hunch is that the direction has nothing to do with the queue, but has to do with selecting packets. For example, if I want to select for source IP address for packets moving from LAN to WAN, I can choose Interface:LAN Direction:In, and then designate the source IP of the LAN host that I am filtering for.
8. The "Bandwidth" setting for a queue is vague. From the wizard, I gather that this value is equivalent to the "m2" value on the "Link share" line. Is it totally redundant?
9. The wizard created some queues with "m1" and "d" values on the "Link share" line. I didn't enter anything into the wizard to suggest these values, so where did they come from.
10. In queues where the wizard entered values for m1 and d, the m1 value was the same as the m2 value, so doesn't that make the m1 and d values entirely redundant?
11. The wizard does not allow me to create bandwidth values greater than 30%. I'm not sure why.
12. The wizard sometimes complains if the bandwidth value is not given as a percentage. If that is a requirement, then the user should not be able to select mbit, kbit, etc. in place of percentage.That's all for now. Feel free to add constructive points to this list. Please let's work together to clarify these things and whittle this list down.
-
thanks ermal for the reply but i would like a more clearer picture on the source and destination under lan, wan and floating tabs so as to be more clear on what rules need to go where based on upload and download for the land client as well as a remote webserver traffic coming into pfsense.
fo eg:
i created a rule under the lan tab that says source as lan ip and destination as * but this rule is considered as download for the client, never been able to understand how coz if i throw a ball at u so im the source and ur the destination so isnt that supposed to be an upload rather than download? -
xbipin,
there cannot be a real drawing of directions because pfSense is stateful.
fo eg:
i created a rule under the lan tab that says source as lan ip and destination as * but this rule is considered as download for the client, never been able to understand how coz if i throw a ball at u so im the source and ur the destination so isnt that supposed to be an upload rather than download?This rule will never match anything related to client traffic. Especially if it is targeted at client initiated traffic.
Since the client will create a state and the src ip of the client cannot be lan ip it will never match.
If you have a queue on LAN, qClient, and the same queue on WAN, qClient, than you can create a rule on LAN
pass from client to any queue qClient and it will put upload an download traffic on qClient.Be aware that you can override the queue(qClient) on WAN through floating rules with a rule that has diirection out.
-
Ermal,
Thanks for your reply. I don't doubt that the shaper in 2.0 functions as it should; my problem at present is that I simply don't understand how to use it entirely and I think the UI needs work in that regard. That's not a criticism of you or the work that you've done, but a call to the community to put our heads together to work on improving that. I think your participation will be critical though, as I have yet to see anybody else on the web or forum that understands the shaper to the extent that you do.
I'd like to propose a few things that need to be improved or clarified, for the purpose of moving forward.
1. The wizard for multi-LAN doesn't create any queue on the LAN or OPT interfaces.
Please open a ticket on redmine.pfsense.org with steps to reproduce.
2. The multi-LAN wizard prompts user to "Setup connection speed and scheduler information for interface #1". This is the 'conn0upload' that SlickNetAaron mentioned. The problem here is that it is not clear to the user which queue he is setting up here.
There is no queue you are actually setting the total upload speed on the interface #1 and download speed on the 'lan' interface.
The wizard take some decision on its own about these bandwidths.3. The floating interface appears in the firewall:rules section without explanation. This is confusing to the new user. In fact, I think anybody that is using the shaper in 2.0 at this point is doing so under the assumption that any queuing or classification has to be done on the floating interface. It appears from Ermal's previous post that this may not be the case, although I am still unclear as to why. Ultimately, I think we need to clarify the role and purpose of the floating rules.
The 'Floating rule' section has nothing to do with the shaper. It just allows to use it for the shaper too.
The real purpose of the 'Floating rules' is to allow some complicated filter rules of multi-wan for traffic initiated from the pfSense itself, etc…
You just can create rules that apply to any interface in there quite simply.4. The floating rules have the option to "Apply the action immediately on match", while rules on the real interfaces do not. In fact, I believe this option ("quick"?) is automatic and hidden on the other interfaces. At present most or all of the queuing rules I have created on the floating tab function only when I activate this option, so again, I'm not sure why it's there.
Yeah for interfaces the quick is assumed action. As i told most of 'Floating rules' is for reducing rules number or other complex stuff.
You need quick in there because you might have other rules that override this rule. Plain simple.
While on other rules the first one wins on Floating rules without 'Apply the action immediately on match' the last one wins/matches.5. The wizard creates floating rules without selecting an interface. In my experience, I cannot select a packet based on a source IP in a local subnet unless I choose "LAN" as the interface. I also have a rule where I have chosen WAN as the interface, and I don't recall why, although I believe the rule to be queuing traffic as desired.
Probably because you are trying to match packets wrong, the rule assumption is wrong.
6. When an interface is selected in a floating rule, that rule is placed at the top of the rules list, above rules which have no selected interface, and is therefore evaluated first. I have been able to work around this, but I don't understand it.
Probably a bug please open a redmine ticket with instructions how to reproduce.
7. I'm not sure the purpose of choosing direction in my floating rules. As Ermal explained, queues only leave a given interface. My hunch is that the direction has nothing to do with the queue, but has to do with selecting packets. For example, if I want to select for source IP address for packets moving from LAN to WAN, I can choose Interface:LAN Direction:In, and then designate the source IP of the LAN host that I am filtering for.
It depends on the needs and how explicit you want to be. Its not a question of shaper but a question of what you want to match, the queue is just an action taken on matched traffic by a rule.
8. The "Bandwidth" setting for a queue is vague. From the wizard, I gather that this value is equivalent to the "m2" value on the "Link share" line. Is it totally redundant?
Depends on the case, but if m2 is specified bandwidth is redundant but the wizard fills it to be consistent with what it did on 1.2.x
9. The wizard created some queues with "m1" and "d" values on the "Link share" line. I didn't enter anything into the wizard to suggest these values, so where did they come from.
Its a wizard some calculation it does by itself. Though you can tweak them after the wizard.
10. In queues where the wizard entered values for m1 and d, the m1 value was the same as the m2 value, so doesn't that make the m1 and d values entirely redundant?
Possibly resulting from calculation though its no pesimization to do so!
11. The wizard does not allow me to create bandwidth values greater than 30%. I'm not sure why.
Probably a bug create a redmine ticket with steps to reproduce.
Just beaware that total bandwidth assumed by wizard is 100% and if during wizard you allocate more than 70% it will complain if you specify 30+%.12. The wizard sometimes complains if the bandwidth value is not given as a percentage. If that is a requirement, then the user should not be able to select mbit, kbit, etc. in place of percentage.
Bug. Specify steps to reproduce this.
That's all for now. Feel free to add constructive points to this list. Please let's work together to clarify these things and whittle this list down.
Yeah but do not expect from me to write a book about this! I already wrote the software.
-
@ermal:
Yeah but do not expect from me to write a book about this! I already wrote the software.
Heh. Thank you for the shaper. It's a must-have for my deployments. I appreciate your answers to my questions and I will certainly follow up with your suggestions.
-
basically the rule i mentioned earlier i had created for client download and atleast it puts the client traffic in the required queue but now thgat u said it wont match anything then i wonder that y its presence is allowing client traffic in the required queue.
my situation is as follows:
i got alias as
3rdfloor - 192.168.0.24 - 192.168.0.36
3rdfloor23 - 192.168.0.23, 192.168.0.37QUESTION OR DOUBT 1
–-----------------now i would like to restrict the above 2 client groups upload as well as downlaods so this is what i have done.
q23 - has a upper limit set to the uplaod bandwidth i want that group to have (this queue is under WAN only), upper limit no necessary as now i use limiters under lan rules.
qp2p - has no upper limit set but just the lowest priority queue.under floating tab if u see, the 2 rules both have direction out mentioned by u and provided src is * and destination is lan client then only does the upload gets restricted as well as put into q23 and qp2p on WAN so my question is, the direction being out can be understood but why src as * and dest as lan client, isnt it supposed to be the other way round if u think of it logically in the msot dummest ways as traffic starting from lan client and ending up on the itnernet without having a clue of states etc which some others might not think of while creating rules?
QUESTION OR DOUBT 2
now coming to the lan tab, i have also restricted their download for each of the 2 client groups but here is where limiters r used to actually do the uplaod and download shaping or limiting.
qp2p - has no upper limit set but just the lowest priority queue.
these rules r to restrict client download and limiters with in and out bandwidth r used.
now if i dont use the rules created as they r in the pics then either the traffic doesnt go in proper queues or it doesnt get limited, now plz explain which of the rules r bogus and what rule needs to be where related to upload and download from lan client point of view, plz give more emphasis on the src and dest fields under each tab as i understand the queue and how they work from ur previous post with diagrams.
![CropperCapture[2].jpg](/public/_imported_attachments_/1/CropperCapture%5B2%5D.jpg)
![CropperCapture[1].jpg](/public/_imported_attachments_/1/CropperCapture%5B1%5D.jpg)
-
Unfortunately this thread got a bit hi-jacked and off-topic, but it brings up many good points.
I think we need to understand the user point of view. A good user experience should eliminate 95% of the repeated questions that Ermal is being subjected to since the re-write started. Perhaps my critique can be better put to use with offering a solution rather than pointing out problems.
1. What are the things a user knows when he starts to setup a traffic shaper?
- I have x amount of upload and download bandwidth on my wan.
- I have x WAN connections, and x LAN interfaces
- I have some ideas of what I need to accomplish (shape, limit bad traffic, prioritize certain apps/web, guarantee traffic for VoIP or server, etc)
- I want to make sure I get every ounce of performance out of my WAN by using this shaper.
2. A user should be able to provide those parameters in the GUI to get at least pretty close to a working config for most common implementations.
3. The results of the wizard should make sense and offer the expected shaping results (high priority queue should get higher bandwidth than the catchall!)
I spent some time sketching a UI which makes a lot more sense. The last screen will be critical, but I have not started sketching. My notes in blue describe it's functionality. This GUI eliminates having 4 different wizards and gives the user a lot more control at the same time. This should, in theory, make it easier to write out a config to hfsc.
This isn't finished, but mostly condenses what the shaper already has.
Thoughts?
-
is it possible to pay and get some questions answered?
is so then i can pay to get the above 2 questions answered in my earlier post, just need to get my doubts cleared related to the source and destination under each rule. -
Better yet, someone give an example of the exact steps from scratch on how to setup traffic shaping for an outgoing http + ack packet. And I'm sure we can learn from here.
-
an example would be great
-
The first screenshot is of a rule on my floating interface. You can't see it, but the Ackqueue/Queue is qACK/qOthersHigh, which were created by the wizard.
The second shot is during the download phase of speedtest.net.
The third is during the upload phase of speedtest.net.
The fourth is immediately following the speedtest. You can see traffic in the low priority queue from torrents, which I have ever seeding.
In this case I'm doing speedtest.net from a host on the LAN interface. I think you would see the same thing if I did it from a host on the WISP interface, which is a second LAN, but I haven't confirmed that.
I think if you had traffic coming in the WAN to a LAN host listening on port 80, this rule might match that as well, although I'm not sure how it would queue it, as I have queues only on the WAN as a result of the shaper wizard.
-
Here's a picture of the rule that selects all except voip traffic from a LAN host "mule" and queues it to the lowest priority.
I found selecting on source IP a little trickier, and it required additional settings, as you can see in the screenshot. I had to select LAN as the interface, direction in, or it wouldn't queue the packets.
This rule is also on the Floating interface, and I'm not sure how this is different from just making a rule on the LAN interface, although I haven't tried that.
You'll also notice that I have !link2voip as destination to avoid demoting voip packets which also come from mule. Normally I would have just put another rule ahead of this one to preemptively classify voip packets, but there is a shaper bug that places rules with a selected interface ahead of rules with no selected interface. For reasons I can't explain, the next rule has no selected interface and therefore I cannot place it ahead of this one, hence the need to exclude packets destined to my SIP provider.
Hope this helps.
-
SNA, your sketch makes sense to me. I especially like the last setting for not shaping traffic that is router inter-LAN. I'm not even sure how to do that presently, but I would like to for the sake of having a host with squid caching on the LAN, and clients on another subnet having limited download speed, except when pulling from said cache.
-
The first screenshot is of a rule on my floating interface. You can't see it, but the Ackqueue/Queue is qACK/qOthersHigh, which were created by the wizard.
The second shot is during the download phase of speedtest.net.
The third is during the upload phase of speedtest.net.
The fourth is immediately following the speedtest. You can see traffic in the low priority queue from torrents, which I have ever seeding.
In this case I'm doing speedtest.net from a host on the LAN interface. I think you would see the same thing if I did it from a host on the WISP interface, which is a second LAN, but I haven't confirmed that.
I think if you had traffic coming in the WAN to a LAN host listening on port 80, this rule might match that as well, although I'm not sure how it would queue it, as I have queues only on the WAN as a result of the shaper wizard.
having queues for WAN means ur shaping ur uplaods only, u need to have queues for LAN also if u need to shape on downloads even
-
Here's a picture of the rule that selects all except voip traffic from a LAN host "mule" and queues it to the lowest priority.
I found selecting on source IP a little trickier, and it required additional settings, as you can see in the screenshot. I had to select LAN as the interface, direction in, or it wouldn't queue the packets.
This rule is also on the Floating interface, and I'm not sure how this is different from just making a rule on the LAN interface, although I haven't tried that.
You'll also notice that I have !link2voip as destination to avoid demoting voip packets which also come from mule. Normally I would have just put another rule ahead of this one to preemptively classify voip packets, but there is a shaper bug that places rules with a selected interface ahead of rules with no selected interface. For reasons I can't explain, the next rule has no selected interface and therefore I cannot place it ahead of this one, hence the need to exclude packets destined to my SIP provider.
Hope this helps.
the rule u mentioned, basically ur trying to put the mule client traffic to the lowest priority queue for uplaods, meaning from lan client to WAN, if this rule works then i also have one rule under floating tab, no idea how but it does the exact same stuff
apply the action - unticked
interfaces - don't select any
direction - out
source - *
port - *
destination - mule
port - *
queue - to ur lowest priority queue -
if u want to put client traffic in proper queues and ackqueues based on destination port or protocol on WAN side, thats pretty easy, just create rules under floating tab.
src - *
dest port - 80above for all uploads or all traffic from client to web server on WAN and just flip the src and dest port for all downloads from web server to LAN client, this is straight forward.
the part where i get totally lost is when u need to have rules where WAN side port or ip would be * and LAN side a LAN client. this is where things gets messy and weird rules seem to match, for eg: if u were to put all LAN client upload to a p2p queue then u would need rules under floating tab as in such a scenario, states r created so rule needs to be in direction out but y src ip and port as * and dest ip as LAN client?
-
As someone that is somewhat knowledgeable, but by no means a networking expert, I can agree with SNA about the wizard.
I know a bit about networking and how to set up queues and such, enough to do really well in 1.2.3. But the wizard in 2.0 is plain confusing, and over-complex. While many people that use pfSense are extremely well-versed in networking and such, there are also many that are not. When I first downloaded pfSense, I was really new, and read an article on how to put an old machine of mine to use ("Armor Your Palace" article). Since then I've come a long way and learned quite a bit.
The difference between the wizards is extreme enough that when seeing the one for 2.0, I just looked at it for a few minutes. Also there should not be more than one wizard. It should be one wizard that is able to deal with the different combinations. I would think (I'm not a coder so I'm guessing) that one wizard with SNA's idea would reduce coding (1 wizard instead of many), and IMHO would be much more intuitive and functional.