New Traffic Shaper - What works correctly or makes sense?

xbipin

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.37

QUESTION 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
CropperCapture[2].jpg_thumb
CropperCapture[1].jpg
CropperCapture[1].jpg_thumb

SlickNetAaron

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?

Sketchsm.jpg_thumb

xbipin

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.

biatche

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.

xbipin

an example would be great

clarknova

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.

rule.png_thumb

download.png_thumb

upload.png_thumb

torrent.png_thumb

clarknova

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.

p2p.png_thumb

clarknova

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.

xbipin

@clarknova:

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

xbipin

@clarknova:

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

xbipin

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 - 80

above 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?

Liath.WW

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.