Messages

[Example 1]

Cheers for that, was totally unaware. Never touched shaping before so went with fq_codel as that was what tutorial used lol

Will have a dig in further and try a different queue type. Can you mix and match? E.g. leaving fq_codel for normal traffic and setup different pipe and queues for VOIP? As there is a difference since using this for bufferbloat.

VOIP is very low bandwidth anyway and on 900 up/down but just want to make sure it is prioritised over everything else as that is my business phone line so want to make sure it runs as good as it can, nothing more off-putting than a bad quality line when trying to speak to a customer.

Absolutely yes, you can mix and match in a number of ways... here's a couple if ideas:

Idea 1:

• You could define multiple queue considering various sizes of bandwidth, within your overall bandwidth allowance. For example, considering that you have a 500/500 Mbit link, you can carve 4 pipes of which:
  -  Example 1: 2 Pipes (Download and Upload) of, let's say 450 Mbits using QFQ as scheduler  and a number of queues with weights that will divide the traffic to serve difference priorities (ie: work, games, media etc); the rules will point to those specific queues accordingly.
  - Example 2: 2 Pipes (Download and Upload) of, let's 10 Mbit (for VoIP is quite a lot but... this is just an example :) ) using FQ_Codel as scheduler and 2 pipes (more or less like you did with your current configuration).
  
  Regarding the 2 example above:
  
  - Example 1, if you define VoIP with the highest weights (ie 90 or 100) the traffic will take precedence over the other queues, no matter what; QFQ is also very good with bufferbloat.
  
  - Example2, the traffic for VoIP will get it's own, dedicated bandwidth (with Codel making the magic for bufferbloat); for your use case this is probably the best option as you will make sure that your VoIP will always have dedicated, 'clean' bandwidth, no matter what...
  
  

Idea 2:

• You could define your Pipes as 'normal', using QFQ as scheduler and FQ_Codel in your queues; this means, all the traffic for each queue will be 'sorted' by FQ_Codel and prioritized by QFQ. So you could have various queues (VoIP, Games, Work, Media etc etc) assign to them the relevant priority and FQ_Codel (or PIE, it's equally good). Just a note though; Codel or Pie will only soft the traffic out for each specific queue (so, let's say that you have 10 people talking to the phone using your VoIP system; Codel will make sure that each of those 10 people will get an amount of bandwidth with the target latency, no matter what). But... if you've defined an higher priority queue (ie Games get weights 75 and VoIP 30), the packets from Games will be processed and forwarded before the one in VoIP (as this is what QFQ is there for...).

Traffic Shaping is a very interesting matter, you can be very creative :)

Hope this helps, happy shaping :)

I've then duplicated these queues for "high priority" with a weight of 100 and created two additional rules for VOIP base (pic attached).

Can anyone offer any pointers?

I'm sorry to disappoint but there's no such a thing of 'high priority queues' if you select fq_codel as scheduler, in your pipes. Fq_codel is all about sharing bandwidth. The priority field is simply ignored.

If you want to prioritize traffic using weights, you should use WFQ+ or QFQ (this latter is the best IMHO) as scheduler (remember to disable completely ECN from both queues and pipes). If you do that, you can start using the 'weight' field in your queues

Attached, an example of my queues where I have a number of different classes for Download and Upload (Platinum being the highest priority and Copper the lowest); the Platinum is for DNS, Ping and ACK, the rest of the classes is for my Work devices, PC and laptops, Media devices, iphone, tablets, IOT, CCTV and Lab test. Doing so, I'm making sure that the most important devices (ie Work) are never affected by whatever the other devices are doing (up to a certain point, as WFQ+ and QFQ will never 'starve' a queue for bandwidth in favour of another queue).

Which CPU, client or firewall?

In general, CPU/GPU usage has increased somewhat on the client side (neat graphics aren't free), and reduced on the firewall side.

Firewall side. The current dashboard demand a toll to the Firewall CPU. I hope the new one, don't (I don't mind if the load is on the client CPU though)

Best
F

strangely it seems that the weight value is simply ignored. Weight 100/Weight 1 share bandwith equally.

I'm experiencing your exact issue; the only difference is that apparently (for me) the weight doesn't seems to have any effect at all (upload / download).

I'm using WFQ as scheduler for 2 pipes (down and up).

For each pipe I've defined 5 queues (Platinum, Gold, Silver, Bronze and Copper) and I've assigned specific traffic for each of those queues (ie TCP ACK, DNS and Ping goes in Platinum, Work devices in Gold, other laptop and desktop in Silver etc etc)

I've extensively tested with traffic generated simultaneously from different queues with very bizarre results (ie a download from the same source for the queue Copper will have more bandwidth than the Gold queue while downloading from the same source... etc).

I'm, like you, on the verge of insanity :) (on paper should be very easy....).

I wish the CBQ scheduler will be added at some point...  ::)

I just hope that will not be 'heavy' on CPU like the current one....

What I've heard is OpenWRT (being Linux based as appossed to BSD) is more performant due to better multi-threading (PPPOE's not an issue either).  The thing BSD has going for it is it's network stack, it just keeps going and going.  But then I've heard BSD13 has much improved multi-threading...

Yep, on OpenWRT you get the full Gigabit with zero issue; the hardware is absolutely capable...

Sure! Here it is:

root@OPNsense:~ # top -a | head -n 25
last pid: 72174;  load averages:  1.05,  1.02,  0.97  up 1+17:22:00    15:20:53
46 processes:  3 running, 43 sleeping
CPU:  4.3% user,  0.0% nice,  6.8% system,  1.6% interrupt, 87.3% idle
Mem: 66M Active, 826M Inact, 609M Wired, 323M Buf, 2450M Free
Swap: 8192M Total, 8192M Free

  PID USERNAME    THR PRI NICE   SIZE    RES STATE    C   TIME    WCPU COMMAND
16040 root          1  52    0    58M    30M accept   1   0:09   1.76% /usr/local/bin/php-cgi
99298 root          1  20    0    58M    30M select   3   0:03   0.59% /usr/local/bin/php-cgi
38828 root          1  20    0    58M    29M select   2   0:01   0.59% /usr/local/bin/php-cgi
  241 root          3  52    0    92M    43M accept   3  13:18   0.49% /usr/local/bin/python3 /usr/local/opnsense/service/configd.py con
97243 root          1  20    0    58M    29M accept   2   0:05   0.49% /usr/local/bin/php-cgi
97389 root          1  52    0    58M    30M accept   0   0:09   0.29% /usr/local/bin/php-cgi
79149 root          1  52    0    13M  2608K wait     2   1:54   0.20% /bin/sh /var/db/rrd/updaterrd.sh
73776 unbound       4  20    0    83M    44M kqread   2   8:03   0.00% /usr/local/sbin/unbound -c /var/unbound/unbound.conf
24848 root          3  20    0    49M    13M kqread   3   2:18   0.00% /usr/local/sbin/syslog-ng -f /usr/local/etc/syslog-ng.conf -p /va
75624 root          1  20    0    13M  2604K bpf      1   1:15   0.00% /usr/local/sbin/filterlog -i pflog0 -p /var/run/filterlog.pid
40640 root          1  20    0    23M    12M select   0   1:03   0.00% /usr/local/bin/python3 /usr/local/sbin/configctl -e -t 0.5 system
93814 root          1  20    0    12M  2144K select   0   1:01   0.00% /usr/sbin/powerd -b hadp -a hadp -n hadp
52464 root          1  20    0    23M    12M select   2   0:58   0.00% /usr/local/bin/python3 /usr/local/opnsense/scripts/syslog/lockout
18856 root          1  20    0    21M  8668K kqread   2   0:41   0.00% /usr/local/sbin/lighttpd -f /var/etc/lighty-webConfigurator.conf
77681 root          1  20    0    21M  6580K select   0   0:31   0.00% /usr/local/sbin/ntpd -g -c /var/etc/ntpd.conf
44223 root          1  52    0    58M    30M accept   2   0:06   0.00% /usr/local/bin/php-cgi
79030 root          1  20    0    12M  2124K piperd   2   0:05   0.00% daemon: /var/db/rrd/updaterrd.sh[79149] (daemon)
  235 root          1  52    0    24M    13M wait     1   0:04   0.00% /usr/local/bin/python3 /usr/local/opnsense/service/configd.py (p

Thanks Franco for your answer  ;D

Thing is, my 10 years old APU (less than 10 watt at full load... what a joy for a 4 core SOC 1.4 GHz!) -that on paper should be perfectly fine- is spending lots of CPU time doing this (please note at this moment the UI is NOT loadad in my browser there just 1 Alexa playing the Radio..).

Those Python processes are taking lots of CPU time and they are completely unrelated to packet routing, firewall and whatnot  :)

It's absolutely not a matter of storage space, it's more that the CPU should be more busy managing the TCP/IP stack rather than the UI.

Hence my 'nice to have' of an home version, for poor people like me  :D that want to continue to use OPNsense and don't care too much of a nice shiny and wonderful Graphical interface (ie Luci on OpenWRT is absolutely SAD but its consuming next to nothing in terms of CPU and memory).

Is this just a dream? Or it's something that can become real, at some point?

Please note: I 'could' give up and use OpenWRT (or derivate)... I just DON'T want to, I like OPNsense and I'm a FreeBSD absolutely fanboy.


Thanks!


last pid: 50690;  load averages:  0.97,  0.91,  0.85                                                             up 1+16:55:09  14:54:02
46 processes:  2 running, 44 sleeping
CPU 0: 65.5% user,  0.0% nice,  6.7% system,  0.0% interrupt, 27.8% idle
CPU 1: 34.9% user,  0.0% nice, 12.9% system,  0.0% interrupt, 52.2% idle
CPU 2: 37.3% user,  0.0% nice, 12.9% system,  0.4% interrupt, 49.4% idle
CPU 3: 23.5% user,  0.0% nice,  4.7% system,  0.0% interrupt, 71.8% idle
Mem: 63M Active, 825M Inact, 609M Wired, 323M Buf, 2452M Free
Swap: 8192M Total, 8192M Free

  PID USERNAME    THR PRI NICE   SIZE    RES STATE    C   TIME    WCPU COMMAND
42491 root          1  78    0    55M    39M CPU3     3   0:02  93.15% python3.9
  241 root          1  52    0    92M    43M accept   3  12:38   4.57% python3.9
62843 root          1  21    0    58M    30M accept   2   0:09   3.39% php-cgi
18856 root          1  20    0    21M  8668K kqread   1   0:39   0.23% lighttpd
19417 root          1  21    0    55M    22M wait     3   0:00   0.17% php-cgi
24848 root          3  20    0    49M    13M kqread   1   2:15   0.13% syslog-ng
73776 unbound       4  20    0    83M    44M kqread   2   7:57   0.05% unbound
40640 root          1  20    0    23M    12M select   1   1:03   0.04% python3.9
93814 root          1  20    0    12M  2144K select   3   1:01   0.04% powerd
52464 root          1  20    0    23M    12M select   1   0:57   0.04% python3.9
79149 root          1  23    0    13M  2608K wait     3   1:52   0.02% sh
77681 root          1  20    0    21M  6580K select   3   0:31   0.02% ntpd
75624 root          1  20    0    13M  2604K bpf      2   1:14   0.00% filterlog
59050 root          1  52    0    58M    30M accept   3   0:07   0.00% php-cgi
32044 root          1  52    0    58M    30M accept   2   0:06   0.00% php-cgi

I think that would be a bit extreme (I mean it's already possible today if you chuck FreeBSD on a x86 appliance and do everything from there) and maybe will discourage many end users that prefer to have a more 'point and click' experience.

I was more thinking like an 'Home version' so with the UI still be the enabler for the final user but more simplified both in terms of capabilities offered and the technology used for the UI itself (the UI seems to be very heavy on the hardware - I believe Franco itself said in a post that the current UI is using a very old and inefficient backend, difficult to modify and update). Maybe re-write something from scratch, with modern technologies?
I know that Deciso is selling hardware for OPNsense (a bit expensive but on paper truly fantastic) but a 'lighter' version will definitely contribute to expand the OPNsense audience to those users that does not need all the enterprise capabilities and have reduced needs in terms of hardware (or better want to re-use their own hardware)? I would be of course happy to pay for such thing (or donate).

I'm running the latest OPNsense on my APU4 with various optimisation (RSS and hardware offloading).

All in all I'm quite satisfied considering my current ISP speed (500 Mbit) and the 12 VLANs (I don't route traffic between them though).

I'm aware that the APU4 is not a super powerful but, with other Firewall OS (ie OpenWRT) it does route to gigabit between VLANs with zero effort and pretty much null CPU usage.

I've noticed that most of the time, processing hogging my APU4 with OPNsense are Python processes; I'm wondering if the graphical interface (and everything related to it) is actually stealing the most of the cpu power to route packets...

Hence my 'nice to have': what about having an OPNsense 'light' with minimal UI (and functionality) but pretty much focussed to packet routing, firewalling, VLANs, QoS etc? A sort of minimal distro...

what's your thoughts?

Thanks
F

Hi there,

I've spent many hours (days, months!) on the subject and now I'm fairly self sufficient and I quite understand how the shaper works. I'm happy to help if I can.

Let's start from the basics... what are you trying to achieve? What's your current configuration?

Best.

Thanks Franco, I'll check that; I will also try to change the lease time for the WAN interface to 30 days and see what happen...

Thanks Franco for your answer; what I don't understand is... I'm not adding any new rules (nor modifying any rules); why the counters are zeroed?

I get it that there are 'many other reason' but just for the sake of making my day today (and I'm going to make a donation to the project!)... could you please explain why and what is the process that zero the counters?

Thanks,
:D

Hi everyone,

there's quite few posts in regard the INSPECT function (which allow to see when a firewall rule has been executed as well as how many bytes that specific rule is 'consuming' from your network).

What's not clear to me is that the counters are zeroed (I believe every 24h) by some process (cron?) while I'd like that the counters are NOT zeroed.

I've read that this is due to the scheduler being active (as there may be some firewall rules scheduled for the execution) but that's not my case, I have nothing in the scheduler section (and of course no scheduled firewall rules)

In the crontab for the user root I can see these jobs:

#minute   hour   mday   month   wday   command
1   *   *   *   *   (/usr/local/sbin/configctl -d syslog archive) > /dev/null
2   *   *   *   *   (/usr/local/sbin/expiretable -v -t 3600 sshlockout) > /dev/null
3   *   *   *   *   (/usr/local/sbin/expiretable -v -t 3600 virusprot) > /dev/null
4   *   *   *   *   (/usr/local/etc/rc.expireaccounts) > /dev/null
*/4   *   *   *   *   (/usr/local/sbin/ping_hosts.sh) > /dev/null
0   22   *   *   *   (/usr/local/sbin/configctl -d firmware changelog cron) > /dev/null
0   1   *   *   *   (/usr/local/sbin/configctl -d system remote backup) > /dev/null
1   3   1   *   *   (/usr/local/sbin/configctl -d filter schedule bogons) > /dev/null
*   *   *   *   *   (/usr/local/bin/flock -n -E 0 -o /tmp/filter_update_tables.lock /usr/local/opnsense/scripts/filter/update_tables.py) > /dev/null

while for the user nobody (which I believe is used by the UI):

# DO NOT EDIT THIS FILE -- OPNsense auto-generated file
#
# User-defined crontab files can be loaded via /etc/cron.d
# or /usr/local/etc/cron.d and follow the same format as
# /etc/crontab, see the crontab(5) manual page.
SHELL=/bin/sh
PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
#minute   hour   mday   month   wday   command

(this confirms that I have no schedule configured).

Can any of the jobs scheduled for the user 'root' be the cause of the counters being zeroed on a regular basis?

If not what other area should I look for?

Thanks in advance for any answer and help on this matter!

Hi again,

The reset of the counters happens every 15 minutes. It's caused by the scheduled filter reload script, which is executed every 15 minutes when a schedule rule is active. I created a schedule rule some weeks ago, and I didn't saw the connection between this two things until today.

I guess it is not a bug, more an expected behaviour. Not really nice, but OK when you know it.

Make it sense to open a feature request for this?

Interesting as I don't have any scheduled rule but the counters are reset on a regular basis (not sure about the interval of time between reset but it's quite frequent..)

I wonder if there's any way to fix this behavior (I use the Inspect function quite a lot to keep under control how some specific rules behave..., number of it's and amount of data).

Any idea on how to stop the 'reset'?

Thanks :)