Same issue here, I have a totally unrelated interface with a 40 Mbps traffic shaper on upload and download, whenever I enable captive portal on an unrelated interface and enable per user bandwidth limitation any other interfaces with a traffic shaper completely lose internet. What is happening here?

@sysadminfromhell In general, a limiter limits bandwidth. A shaper prioritizes packets. Sometimes they are used together.

Netgate has a page on bufferbloat also, which uses both. I've not set that up myself, I've used the shaper with other methods, like PRIQ only prioritizes packets.

"your experience with fq-codel is impossible unless you misconfigured it"

I never said that.

Yet your replies are contrary.

My reply is still the same:

If possible use CAKE (preferably with the ingress keyword) if you want to maximize throughput for a given increase of latency (which ultimately effects the packet loss rate).

Question your solution if you have to sacrifice 40 % of your throughput in order for FQ-CoDel to have no packet loss on sparse flows.

not to mention the dozens of lines that show you have not read the documentation you linked to

I leave it to the reader to judge who has neither read nor understood it.

@jimp said in Old bug or new issue?:

Those are not the same rule you have failing in the error message.

The one in the error message has a different description.

Check all the other tabs and see where that specific rule is, labeled "Connections From Upstream SIP Server"

Rebooted today and the issue is gone.. bizarre

@demux To the 200Mbit and 20Mbit pipes you created, the remainder of your bandwidth does not exist. Any traffic that you assign to those pipes using firewall rules will only ever have access to a total of 200Mbit and 20Mbit of bandwidth respectively. If you assign all your traffic to one or the other of these two pipes, then the remainder of your bandwidth will just go unused.

@tman222 awesome! thanks for the information :)

@jaypfadmin You saved me HOURS of troubleshooting!

I created a small tool luckman212/stv to help make it a little easier to debug states. In case it's useful to anyone else.

I think I figured it out. I was using one limiter for all interfaces. I created one limiter per interface and it appears to be working as desired. Sorry for asking a dumb question.

@thiasaef said in Question about firewall rules for FQ_Codel Limiter:

@fsr the source port randomization should alleviate the issue:

By default, pfSense rewrites the source port on all outgoing connections

Thanks for your answer. It certainly looks like the limiter does a good job, even after NAT.

Also is this graph from Flent?

Yes.

@jonathanlee Thank you very much for this attempt. I am personally very graphically untalented, but very responsive to good graphs. If ever you have a chance to give this a go again, to revisit and re-use your first tail drop diagram in contrast with codel alone - codel drops from the head of the queue, not the tail, and I would perhaps draw a 5ms target window at the same 4 packets you use here and feature a few more packet slots as a shock absorber. then three phases

queue over target showing timestamps shock absorber filling -> dropping from head when too old queue below or at target

I have NEVER managed to describe how codel operates well enough to suit me, and fq_codel, or for that matter, cake, oh, man...

https://lists.bufferbloat.net/pipermail/bloat/2013-February/004888.html

To try and describe how fq-codel works, I would use a single queue on the front left there with different colors for packets and their bunches. I do things like

AAAAAABBFBBEAAAFEAAACAAA ->

And coming out:

BABAABFA BCEFCA

Which is kind of accurate for a per packet FQ system, but DRR is different and having the longer blobs to represent bytes rather than packets might help.

Does that help any?

Ended up reverting back to 2.5.2 and everything works as it should. Not as I want, but at least the static traffic shaping does what it is described to do in the guide.