I use traffic shaping to give our VOIP phones priority over the rest of the traffic. As far as I can tell the traffic is correctly tagged into the right category but If I saturate the bandwidth the sound quality becomes really unacceptable.
Should the traffic shaper be able to handle such situation ? I tried various ways to get it working correctly, including specifying a lower than real available bandwidth in the ppp; fiddling with the TCLinklayer parameter (which looks not taken into account) but didn’t succeed, it just don’t work.
cat /etc/firehol/fireqos.conf
# ================= DO NOT MODIFY THIS FILE =================
#
# Manual changes will be lost when this file is regenerated.
#
# Please read the developer's guide, which is available
# at NethServer official site: https://www.nethserver.org
#
#
FIREQOS_CONNMARK_RESTORE=""
modinfo act_connmark &>/dev/null
if [ $? -eq 0 ]; then
FIREQOS_CONNMARK_RESTORE="act_connmark"
fi
interface ppp0 EDPNT bidirectional input rate 45000kbit output rate 8000kbit balanced ethernet
class high input commit 10% output commit 10%
match connmark 0x4
class low input ceil 90% output ceil 90%
match connmark 0x3
class voip input commit 10% ceil 10% output commit 10% ceil 10%
match connmark 0x2
As it appears, your Nethserver is your primary (and only) firewall…
How many users / VoIP phones are we talking about?
I also use Nethserver in larger environments, like in a Hotel, where NethServer is AD and primary Server. However, in this case, Nethserver does not act as Firewall (We have 4 internal LANs, three providers incl. fail-over. In such a scenario, too many LANs in the nethserver makes the firewalling unduly complex, and usually results in AD not working…
I do use traffic shaping / QOS to provide adequate VoIP quality, especially during Backups, where Data is sent to an external Storage. Agreed, Backups are done at night, but at a Hotel, there are almost always telephone calls…
Traffic shaping is done by my firewall, not the nethserver. This is also OpenSource Software (OPNsense by Decisio) with a hardware box.
At a Hotel with free WLan for guests a major problem is uncontrolled Laptops (Windows). Several guests seem to have whole spamware collections on their Notebook…
My solution is something akin to toilet flushing. You can flush as often as you want. The first times, there’s still water in the tank, but afterwards you need to wait for the tank to fill up. Guests can send mail, no probs. But if they want to send 100 or 1000 mails, they’d have to stay longer!
Take a look at OPNsense, a fork of pfsense, which was itself a fork of M0n0wall. I used M0n0wal for quite a while, until the project was closed.
I tried out PFsense - I was using Soekris Hardware at the time. Soekris also closed shop, due to too much competitors from China, and Soekris could not hold the prices…
PFsense is quite good, but after trying out OPNsense, i was hooked…
See https://www.applianceshop.eu for HW for both platforms.
PFsense does too much in my opinion, and tries to satisfy hobbyists and enterprises alike - but one size does not fit all! Additionally, the cheapest support solution costs almost 1000.-/year!
OPNsense works well for me without support, for the last 4+ years. I have OPNsense at about 10 clients.
As a tip: both can be tested on VM, it doesn’t really matter what virtualisation you choose or are comfortable with. I actually keep a virtual firewall “ready”, in case or HW problems with the real HW.
The only problem I currently have with OPNsense is the fact that I can use Nextcloud to do automatic and regular backups of configuration, but it won’t accept my LetsEncrypt protected NextCloud running inhouse on the Nethserver.
I personally never used QoS over PPPoE.
I think that the right TCLinklayer options could make some difference. @pagaille, if the db prop seems to be ignored, please modify directly /etc/firehol/fireqos.conf.
I investigated further and narrowed the problem down to a radio link between the modem and the NS gateway.
It appeared that for whatever reason the available bandwidth wasn’t sustainable and varies between 50% and 100% of the nominal vdsl bandwitdh. Therefore the traffic shaper wasn’t able to work accurately.
I ended up restraining the available bandwidth to 50% of the vdsl link’s full bandwidth into NS’s network settings to workaround this. Now the VOIP works even with the bandwidth “fully” saturated.
Thanks all for sharing your ideas.
PS @filippo_carletti I confirm that the TCLinklayer parameter is not taken into account. I’ll look into this and will submit a PR if I’m able to.
PS2 : @giacomo when you’ll port this to Cockpit, take care of this : the order of the Traffic shaper rules is important. For example a “voip” rule should be higher than the default “high” category. So the list should be sortable.
There are also a lot of other FireQOS parameters that could be added to the UI but that’s another story.
That machine wasn’t up to date. I just updated and now it works. Probably there was some bug fixed lately.
Thanks filippo.
Matthieu
NB : in my test and in my particular crippled configuration I didn’t noticed any enhancement between “ethernet" and "adsl local”. But your mileage may certainly vary.
