@a_null:

Limiters don't really seem to work on pfSense versions above 2.15.

Only where NAT applies on the interface where the rules reside. The circumstances being discussed here work fine.

Generally where they don't work at higher speeds it's because the queue length isn't long enough (though the default is fine to >100 Mb generally). Though in VM environments, timing or scheduling issues with the VM in general can be problematic, that's usually not an issue.

@Nullity:

When you say "download something", are you referring to p2p/multi-stream or single-stream download traffic?

You need to classify your bulk downloads separately from important traffic, like twitch streams.

Best QoS/traffic-shaping tutorial (imo): http://www.linksysinfo.org/index.php?threads/qos-tutorial.68795/

I will check out that tutorial, thanks.  I mean single stream download traffic.. not p2p.

Looking for this feature too  ;D

@Harvy66:

You're the one who started it. /semi-sarc I showed documented proof that CBQ is worse than HFSC when it comes to delay and bandwidth coupling. I was using the CBQ definition of "coupling" or "decoupling", not your HSFC version. Remember, words have different meaning in different contexts, even extremely similar contexts with extremely similar usages. Context nuances are important.

I do concede that CBQ is easier to use(fewer options) and will agree that if even if using simple HFSC settings is too much, CBQ is good enough.

P.S. I am just saying I think is true, but you may also do the same.
P.P.S Nullity has properly corrected me on several occasions, which forced me to do more digging and correct myself. And I thank him for that.

CBQ, in any implementation prior to HFSC, had no mention of "decoupling" or "coupling". There is no “CBQ definition of 'coupling' or 'decoupling'”, as you put it, as CBQ is wholly unaware. Post a link to any paper that implemented any CBQ algorithm with an understanding of decoupling bw & delay. If you cannot find one, please edit your posts to remove the misinformation.

No 30-page anecdotes. Link or stfu.

thanks guys. all i can say is wow. that is super neato.

some kind of wizardry going on here.  ;D

thanks guys. moving the rules to the lan did the trick.  ;D

Long story short, freaking firewall rules that classify your traffic, like port matching, and use those rules to assign the traffic to queues. Then you shape those queues.

Here's an example of what you can do
https://forum.pfsense.org/index.php?topic=94831.msg528836#msg528836

@CDuv:

My multi-WAN is a Load Balancing.
I have no rule that dictates which Internet connection should be used (except for some very specific remote IP).

Is why, I as want to limit only one of my WAN, I had placed the limiter-applying-firewall-rule on the WAN_A interface.

If I have to create a firewall rule on the LAN interface, how could I make it limit the WAN_A traffic only?

Will packet marking that I outlined above not work?
Apply the mark if the packet is incoming WAN_A.
Then match the mark at the LAN and assign it to queue/limiter.

Edit: Changed "WAN" to "WAN_A" to clarify.

@Nullity:

Does this link offer any help?

https://forum.pfsense.org/index.php?topic=63531.0

This what I used for now.. At least I able to update all server software. But this setting, the user will go more than allocated BW (2Mbps) but yes I can control total BW for the user (480Mbps). After update I change to per IP allocation back since its our business rules. User capped at 2Mbps.

@Harvy66:

Sounds like a bufferbloat issue. Try enabling CoDel or FairQ?

Will take a look for both because I never heard any of that.

@wizbit:

Right I see what you mean, however, how can I set a bandwidth for http/s as this can depend on how many users are viewing websites, downloading, etc ?

Technically, you can only fully control traffic that you transmit. QoS/traffic-shaping is most effective on upload traffic. HTTP(S) browsing will primarily be download traffic, which you cannot really prioritize. Actually, downloads (incoming WAN traffic) are only controlled as a side-effect of controlling what the LAN interface is able to transmit.

Ultimately, just create VOIP, radio, and bulk/other/default queues on WAN. Apply Codel to the default queue then see if that works. This will solve most problems with upload.

Unless you are well-versed in the intricacies of traffic-shaping, I would stick with simple rules and only add additional rules if you have a problem that needs fixing.

If you have problems with download bufferbloat, there are a few ways to deal with it, but sadly you are limited because of your multi-LAN setup, because interfaces cannot share bandiwdth… If you had one LAN interface, I would say setup 1 queue on your LAN with a bitrate of 90-98% (lower if traffic is p2p) of your measured download speed and set the queue size to 1 (so it acts like a traffic-policer, rather than a traffic-shaper). That would effectively stop bufferbloat on downloads.

With your multi-LAN setup, you would need to do the same as above, but give each interface half of the bandwidth, which is no good...

In theory, you could limit the outgoing WAN ACK rate which would limit download rates, but ACK rates are not an exact science, so this is pretty damn hard to configure, requiring a bit of trial and error. It should allow WLAN/LAN to better share the full download bandwidth than the sub-optimal 50/50 split though.

I can see no diff unless the top rule lumps udp into the ack queue, but I would not expect that.

I would probably choose the lower rule, because I learned that my traffic-shaping configurations were easier to trouble-shoot when I was explicit. Making assumptions has caused me quite a bit of turmoil.

Also, my blacklisted/whitelisted ports are put into aliases, which I organize into UDP and TCP, so using separate rules are easier.

You could just say the hell with it all and just use CoDeL. In a home environment with Voip (Ooma and cell phone based voip) heavy downloads and a 1 person playing an online game (CS:GO), no one saw any problems at all and the call quality was better than with my last setup using HFSC.

If the issue is not enough bandwidth, then do something like enable Codel or FairQ on your interfaces to reduce the damage of bandwidth hogs. Maybe even HFSC if it's a specific protocol that is being greedy.

@Nullity:

You may need to enable net.link.bridge.pfil_bridge in System->Advanced->System Tunables to enable filtering on the bridge interface.

There are other related net.link.bridge.* settings that you may want to look at as well, in System Tunables.

Thank you for the suggestion! It looks like all the tunables in regards to the bridge are correct on my install. Looks like this was working under 2.1.x but not under 2.2.x (I'm on 2.2.5) and it's been filed into a ticket; I should of looked/searched harder earlier:

https://redmine.pfsense.org/issues/4405

Guess I'm out of luck for now and either downgrade to 2.1.x or wait for the possibility that it's resolved in 2.3.  I think for now, I'll make due and wait.  :)

Thanks again!

Cheers,
Kermee

@Derelict:

192.168.0.49/31 covers IP addresses 192.168.0.48 and 192.168.0.49. (You probably want to specify 192.168.0.48/31 for clarity instead)

Just enable that rule and remove the limiters on it. Those two source IP addresses will not be limited.

And instead of a special limiter rule, just delete that and add the limiters to the default rule.

awesome thank you soo much that fixed my problem, works great now thank you very much. I guess i was just over complicating things haha

With the same error: "You have less interfaces than number of connections!"

Running on release 2.2.5 the same issue with more than 2 active interfaces.

Could not test in production, but this is what i done:

Disable all LAN interfaces and stay with one WAN and one LAN interface. Execute the Traffic shaper wizard and complete it. Check your Status - Queues  (menu status) Check your Shaper and bandwidths. Enable other LAN interfaces. Enable Queue on each interface ( Enable/disable discipline and its children ) Goto the Traffic Shaper - By Queues tab  (https://…../firewall_shaper_queues.php) Choice the qLink queue and for each interface do the:  Clone shaper/queue on this interface  action Choice the qInternet queue and for each interface do: Clone shaper/queue on this interface  action
---- this will copy also all sub-queues behind qInternet. Remove qDefault from LAN interfaces (qLink is the default). Check the queues tab to see if the queues are created. Check the Queue status (  https://..../status_queues.php )  if all queues are active Adjust values of all qLink queues to match internet upload speed (the sum of all queues is your speed).

Remark:  this wil limit the bandwidth between the LAN segments also because the queues are generic, the Traffic shaper wizard only assumes traffic to/from WAN-LAN's  and not traffic between LANs!  If you want this you need to manual create Queue's or adjust the floating queue rules to be more specific.

You could use limiters to proportionally share traffic among the clients/IPs, each getting a fair minumum while sharing excess bandwidth. I think limiters are currently incompat with squid, though.

You mighy benefit from this tutorial; http://www.linksysinfo.org/index.php?threads/qos-tutorial.68795/
Aside from being my favorite QoS tutorial, I think you will find it useful since the asuthor also must admin large networks of uncooperative users.