Limiters are the closest you'd get, there isn't anything comparable on pfSense to the CIR/MIR method of traffic policing. Everything will queue.

been there as well already  ;)  thanks

Since you're not sure, just go under each queue and check "Codel Active Queue". See if that helps.

Personally, my recommendation is to just use FairQ as the sharper for both up and down, just have a single Default queue, and check "Codel Active Queue". It might be good enough for you or least get you by while you learn how traffic shaping works.

Thanks bradenmcg

I have already ran the wizard and I know the rule you're talking about but that rule doesn't do anything for me. In fact any floating rule that I create and assign to the qPnP queue will not be matched by the rule except for a few packets as you can see in the first pic.

The only way I have had this kinda work is if I create a LAN rule that passes the traffic to the SOURCE of 10.1.1.9. Not destination but source which I thought was backwards until I tried it and now traffic going from the internet to 10.1.1.9 goes into the queue but it isn't perfect and I'm sure there are other issues that will pop up from it being a pass rule and not match and also the fact it is in LAN rules may affect LAN traffic

Agree with Harvy66, ur using the wrong tool for the job.

Hi Plissje how did you end up fixing your rules?

I'm having the same issue where all my traffic that should be going into a queue isn't

I would highly recommend just enabling FairQ on you WAN(upload) and LAN(download) interfaces, and check the "codel active queue" box in the default queue. Set your bandwidths to 80%-90% of your actual bandwidth.

If that isn't good enough, then go further down the infinite rabbit hole of QoS.

When pfSense 2.4.4 comes out, look into just using fq_Codel limiter. The above tries to simulate fq_Codel.

Hello again.
This annoyed me enough I spent some time looking at it, and I found the problem and solution.

Graphs are updated by this script: /var/db/rrd/updaterrd.sh

Within it, this is the section that updates the traffic/queue graphs:

# polling packets for interface wan pppoe0 /usr/bin/nice -n20 /usr/local/bin/rrdtool update /var/db/rrd/wan-packets.rrd N:`/sbin/pfctl -vvsI -i pppoe0 | awk '\ /In4\/Pass/ { b4pi = $4 };/Out4\/Pass/ { b4po = $4 };/In4\/Block/ { b4bi = $4 };/Out4\/Block/ { b4bo = $4 };\ /In6\/Pass/ { b6pi = $4 };/Out6\/Pass/ { b6po = $4 };/In6\/Block/ { b6bi = $4 };/Out6\/Block/ { b6bo = $4 };\ END {print b4pi ":" b4po ":" b4bi ":" b4bo ":" b6pi ":" b6po ":" b6bi ":" b6bo};'` ` pfctl -vsq -i pppoe0 | awk 'BEGIN {printf "/usr/bin/nice -n20 /usr/local/bin/rrdtool update /var/db/rrd/wan-queues.rrd " } { if (($1 == "queue") && ( $2 ~ /^q/ )) {  dsname = dsname ":" $2 ;  q=1; }  else if (($4 == "bytes:") && ( q == 1 ) ) {  dsdata = dsdata ":" $5 ;  q=0; } } END {  dsname = substr(dsname,2);  dsdata = substr(dsdata,2);  printf "-t " dsname " N:" dsdata }'  dsname="" dsdata=""` ` pfctl -vsq -i pppoe0 | awk 'BEGIN {printf "/usr/bin/nice -n20 /usr/local/bin/rrdtool update /var/db/rrd/wan-queuedrops.rrd " } { if (($1 == "queue") && ( $2 ~ /^q/ )) {  dsname = dsname ":" $2 ;  q=1; }  else if (($4 == "bytes:") && ( q == 1 ) ) {  dsdata = dsdata ":" $8 ;  q=0; } } END {  dsname = substr(dsname,2);  dsdata = substr(dsdata,2);  printf "-t " dsname " N:" dsdata }'  dsname="" dsdata=""`

So to graph queues, we're running this command: pfctl -vsq -i pppoe0

If I run this on my pfSense, I get the following:

[2.4.2-RELEASE][admin@trogdor]/etc: pfctl -vsq -i pppoe0 queue Bulk on pppoe0 bandwidth 1Mb priority 0 qlimit 455 fairq( codel linkshare 20Mb )   [ pkts:          0  bytes:          0  dropped pkts:      0 bytes:      0 ]   [ qlength:  0/455 ] queue Low on pppoe0 bandwidth 5Mb qlimit 256 fairq( codel default linkshare 20Mb )   [ pkts:      3032  bytes:    667799  dropped pkts:      0 bytes:      0 ]   [ qlength:  0/256 ] queue Medium on pppoe0 bandwidth 10Mb priority 2 qlimit 256 fairq( codel linkshare 20Mb )   [ pkts:      2659  bytes:    895810  dropped pkts:      0 bytes:      0 ]   [ qlength:  0/256 ] queue High on pppoe0 bandwidth 3.30Mb priority 3 qlimit 32 fairq( codel linkshare 20Mb )   [ pkts:          0  bytes:          0  dropped pkts:      0 bytes:      0 ]   [ qlength:  0/ 32 ] queue VeryHigh on pppoe0 bandwidth 500Kb priority 4 qlimit 16 fairq( linkshare 20Mb )   [ pkts:        333  bytes:      27377  dropped pkts:      0 bytes:      0 ]   [ qlength:  0/ 16 ] queue Priority on pppoe0 bandwidth 200Kb priority 7 qlimit 8 fairq( linkshare 20Mb )   [ pkts:          4  bytes:        176  dropped pkts:      0 bytes:      0 ]   [ qlength:  0/  8 ]

Hmm, so that works just fine.  Let's look at that sed line a bit closer: { if (($1 == "queue") && ( $2 ~ /^q/ ))

HANG ON A SECOND.

If the queue name doesn't begin with the letter q, my traffic is not going to be collected by this!

The simple fix: A traffic queue's name must start with the letter q

so I renamed my queues from Bulk, Low, Medium etc to qBulk, qLow, qMedium etc and I'm now getting lovely queue graphs.

This little quirk doesn't appear to be documented anywhere, and of course if you use the Wizard (as 99% of sensible, normal people will do) the queues are all created with q in front of their name.

I hope this helps someone in the future!

@Derelict:

It wouldn't have been anyway.

A laggX traffic shaper, if it worked, would still be separate from any shaping on the individual VLANs. It would not be hierarchical.

I think that I was not clear enough, sorry.

I can confirm that the bandwidth is shared when you use a "fake" interface to apply QoS on it (igb0), so I don't see any reason despite the fact that the driver doesn't exist for the LAGG.

igb2 -> used for WAN
igb0 -> used for VLANs

no VLAN no IPv4 no IPv6 on igb0 -> VLANS
VLAN 1040 on igb0 -> CUSTOMER0 (interface LAN)
VLAN 1041 on igb0 -> CUSTOMER1 (interface OPT1)
VLAN 1042 on igb0 -> CUSTOMER2 (interface OPT2)
VLAN 1043 on igb0 -> CUSTOMER3 (interface OPT3)
VLAN 1044 on igb0 -> CUSTOMER4 (interface OPT4)

Traffic Shaper applied on igb0(VLANS) for icoming/outgoing

WAN
–qWan
----q10
----q11
----q12
----q13
----q14
----q15
VLANS
--qLink
----q10
----q11
----q12
----q13
----q14
----q15

Yes captive protal + FreeRADIUS package. Not sure if it just blocks them after exceeding quota or if you can limit there speed

You can distribute states across multiple WAN interfaces using a load-balancing gateway group to help distribute load across them but you cannot combine two circuits into anything that looks like one.

The wizard is pretty bad. Other than the default floating rules, I ditched the wizard and did everything myself.

If possible, I'd just use Limiters and setup fq_Codel, which is pain right now but should be a simple check-box soon™. Limiters have the benefit of being able to shape ingress, allowing for easy multi-WAN shaping, and fq_Codel is turn-key for nearly every situation with no config other than setting the bandwidth.

The destination wasn't Steam, it was the proxy.

I suffer for years on slow DSL but ISPs have up the game and are offering more speed for same, even less$ so stay abreast of what they are currently offering.  Comcast even allowing Internet-only, they used to charge big time for this and forcing you to buy double-play, triple-play but no longer.

@SammyWoo:

LIMITING won't be so limiting (punt intended) if it allows % of total bandwidth, rather than a fixed number.

But I disagree with above, Pfsense KNOWS how much bandwidth you got, Traffic Shaper MAKE you to tell it doesn't it?  So OK, SOHO have no guaranteed BW, but since Pfsense makes you input something, at least there is something to go by.

"So OK, SOHO have no guaranteed BW" exactly the problem. Just because you know your car can go 100mph doesn't mean you can do that during rush hour.

Unstable Internet during saturation is symptom, not a cause. I let Bittorrent consume 99% of my bandwidth with no ill effects.

I recommend trying to enable FairQ on your WAN interfaces, set your bandwidth to some value less than 100%, start with 80%, and enable Codel on the child queue. Just a few check boxes and like 2 minutes to setup. If that isn't good enough for you, look into fq_Codel limiters.

@SammyWoo:

My understanding is, priorities queues are activated on the egress side of interfaces.

Thank You!  I'm still messing around with traffic shaping and trying to figure this whole thing out.  So far, I haven't wrecked anything yet.  :)

For floating rules, catch all should be at the top. For normal rules, catch all should be at the bottom.