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

Regardless, would moving to HFSC make sharing/borrowing between interfaces easier?

Shaping can't work across interfaces, but if there's a way to get two or more interfaces to bridge to a pseudo-interface, and assuming you can shape that pseudo-interface, you could probably do it.

When you shape an interface, you shape the data leaving the interface. Shaping your LAN interfaces effectively slows how quickly you can download. With the naive setup for multi-LAN, you can't say how little bandwidth each gets, but how much. If you have 10Mb to split, you may give your guest 2Mb and your main LAN 8Mb.

You may also want to try enabling CoDel on the child queues. If you have less than 1Mb/s, you may not want to do it. CoDel seems to have issues with 1500MTU with bandwidths less than 1Mb.

Curiously, pfsense can do rather basic marking of 802.1p (layer2) - but not diffserv in layer 3.

You're not shaping your downloads because everything is going to qLink and everything is under qDefault for your upload.

Like KOM said, in a nutshell HFSC lets you specify the minimum amount of bandwidth you want to provide a queue, and HFSC will fairly distribute the bandwidth that meets your minimums.

Thanks guys for your clarification.

Let see if I get the logic.

1MB/1MB

If we setup limiter we chose mask source…

Each source will have 1MB/1MB pipe.

1MB/1MB

If we setup limiter we chose nothing  in the mask.

We have 1 pipe 1MB/1MB for all our sources?

Them 10 users will share 1MB/1MB?

Thanks.

@Derelict:

Your WAN IP address should be something other than your gateway IP address.

IP addresses on a subnet must be unique.

i have edited my first post, perhaps its clearer than before.

I know that there were issues with the vmxnet3 drivers in older versions of pfsense, but they've now included it in the later builds.  However, I do agree that while it does work, it may not be the optimal solution.

I am now wondering if vmware is the cause of my packet loss….

Please, read the linked thread. Seriously don't have time to extract info for your from 8+ pages thread.

Right. I was talking Limiters and Shapers as two distinct things.

Limiters work on 2.2 as long as NAT or other redirection isn't involved on the subject interface.