After playing around some more, looks like "Bandwidth" field uses parent-relative %, but " B/W share of a backlogged queue" (m2) uses absolute %. This makes a bit more sense now why both fields are provided -- but the UI is still atrocious.

Correction: "Bandwidth" field allows me to add sum of %s which exceed the parent's %. I'm not certain they'll be applied as relative

@hebein fq-codel is more of an automatic solution, in the way that it does'nt starve any connections of bandwidth and tries to keep latency low at all time. You give priority by creating more child queues under the limiter and set the weight parameter and thereafter make a rule to catch the traffic that needs priority. But as with all other type of QoS it needs the bandwidth to be available which could be a problem on LTE and although it might take a few more minutes to implement there is far less adjustments needed to get a good result contrary to the traffic shaper guide.
The difference fq-codel isn't just seen on low end connections, on the two speedtests below you can see the difference it makes on a 240 Mbit symmetric fiber connection. The black line is average of the four streams, and total bandwidth is four times the average.

test32_20480_flows_800_uplimit_800limit_20480_flows_download.png

all.png

Thanks for the reply.
I rebooted the system & now the limiter info is cleared out, but it still won't let me delete them.
I've gone through every rule and can't find any that have a limiter set. Why can't the error message just tell me which rule it thinks has a limiter set?

681101cb-448f-4b86-a944-86e88fe1f41d-image.png

@Harvy66 Thanks for the education and info, I really appreciate it. I will keep this in mind and refer back to this thread if I do have any issues. So far I haven't had any complaints from VOIP users.

I also tried to make this work with the tag and tagged fields, the original rule that I have working:

Action: match
Interface: WAN
Direction: in
Address Family: IPv4
Protocol: TCP
Source: any
Destination: Wan Address
Destination Port Range: 443

this is working ok tagging the traffic going to the HaProxy, not my finnal intente (I only what to filter the traffic going to the emby server) and now I tried to add:

Tag: fromwan
Queue none/none

Then I used the rule that I stated above:

Action: Match
Interface: LAN
Direction: Out
Address Family: IPv4
Protocol: TCP/UDP
Source: any
Destination: EmbyServer
queues qACK/qStream
Tagged: fromwan

Nothing, the traffic keeps not being assign to any queue. Just out of curiosity I tried to block the traffic from the wan to the emby server. I used the rule above

Action: Block
Interface: LAN
Direction: Out
Address Family: IPv4
Protocol: TCP/UDP
Source: any
Destination: EmbyServer
queues qACK/qStream

This rule was working blocking the traffinc, but now I added Tagged fromwan. The result was no blocking at all.

Floating rules are so hard to predict and test, but I need them to shape my traffic.

Hello!

Maybe delay pools in the squid package?

John

@bobbenheim Looks like that was the trick, I can see the rule working choosing LAN for the Penalty users, thanks Sir.

@Kaila said in pfSense CE:

I need to know if pfSense CE gives bandwidth use. If It does, how much is that?

Yes, bandwith is limited to the hardware pfSEnse is running on.
If you have x GB capable device, then that's what you get ^^

@Kaila said in pfSense CE:

do we need any routers or servers to work with pfSense CE?

Well, you will have to use some upstream "modem", or whatever other device that brings "Internet" to your site.
But no routers or servers are needed.

On Linux I'd know a way, netfilter actually has a module that switches chain/rule after a certain amount of time, but on BSD I actually don't because I never had the problem before.

Btw: Standards are a problem of their own. When stuff like HFSC gets implemented it doesn't necessarily mean it's following the whole standard. Always check the BSD docs on the corresponding version:

https://www.freebsd.org/cgi/man.cgi?query=altq&apropos=0&sektion=4&manpath=FreeBSD+11.2-RELEASE&arch=default&format=html

Sadly I don't see a solution at this time, not with pf or even ipfw and limiters as there's no way to do anything based on time (e.g. 5 seconds).

There are workarounds with tables and PF's match rule, but that's nothing you want in production.

Cu

ue0 (USB Ethernet) does not support ALTQ.

@bobbenheim said in Log limiters:

The more important question is what traffic are getting dropped and is it a problem?

Yes, it could be the problem. For example: unauthorized application installed (P2P), misconfigured application, malware... etc.

Aaah, I have an alternative port... Thanks for the hint!

@PVuchetich2 that is a typo, i meant 20480 :)

Update: tried upping value of flow and am not seeing any stability issues, though i am on 2.4.5 versus 2.4.4 p3 when i last increased flows. Also setting flows to 40960 gave a couple of ms less on upload bufferbloat in dslreport's speedtest. Download seems to be the same but cpu usage is increased by it.

@dzabdelhak according to the pfsense docs here you can set a weight on your child queues. I have not tested weights, but i would assume that if you set a weight of 50 for both queues it should prioritize them evenly when needed. It might be easier to set up fq-codel with a single queue first to mitigate bufferbloat and then add a second queue afterwards.

Maybe a part of answer here:

https://success.alienvault.com/s/article/Why-does-a-TCPdump-of-my-monitor-interface-return-ethertype-Unknown

In some environments, a physical or virtual switch can be configured to use VLANs on the SPAN ports the USM is connecting to. When using this configuration, the appliance will discard this traffic as it is unable to parse VLAN Trunking or other Bridge Protocol encapsulated traffic.

This message indicates that the network stack is not capable of reading or interpreting the traffic showing this message. As this traffic cannot be read, it will be discarded. This issue can be resolved by configuring your physical or virtual switch to pass the mirrored traffic to the monitor port as IP traffic (ethertype 0x0800).

In this context, does somebody knowss how to configure pfsense to pass the mirrored traffic to the monitor port as IP traffic (ethertype 0x0800)?

Are there some security risks to do that?

Thanks