QoS/Shaping not quite working right after upgrade from ancient 2.3.5 to 2.7.2
-
Hi there,
Long time fan of the project here. I've recently upgraded an ancient old soldier running 2.3.5 at a family members rural property to something more robust running 2.7.2. I was able to restore all my settings from a recent backup of the FW, but I've noticed this morning that my QoS setup definitely isn't performing like it was before. I absolutely cannot remember all the knowledge I had to cram to set it up in the first place, and I'm wondering if any soul out there could maybe help me understand where it's falling over. Otherwise I'll probably need to schedule another trip to the property after reteaching myself how to do some basic Queueing. :-(
All of the FW rules place the traffic in the proper queues it appears, but something is wrong with the proportions / shaping. Previously, if there was majority traffic in the "QOthersLow", and then 'regular' traffic began to take place, the servicing of QOthersLow would drop to almost nothing. Now, it doesn't appear to have any effect at all, and this low priority traffic is choking this 3Mbps link :-(
I really don't want to have to redo everything here, and I'm debating on simply finding a way to put the old HW back in >:-[
-
@ctrlbreak Can you post the shaping configuration? Images, and/or what algorithm etc.
I personally find it confusing at times and the wizards have a few bugs now and again (https://redmine.pfsense.org/issues/12393) which doesn't help.
For prioritizing specific things like VoIP and not worrying about bandwidth limits, I find PRIQ by far the easiest. With a 3 Mbit connection though are you trying to limit certain traffic?
-
Sure. Here is the configuration as it was restored from the 2.3.5 backup config. I honestly can't remember the original setup, only that I burnt 3 days trying to understand and get something that worked at the time. For some reason, my gut tells me that some of these settings aren't exactly what are configured on the original fw.
My next step is actually to take a drive to physically get the old FW hardware and power IT up at 2.3.5 so that I can compare the actual configuration that it was running with :-S
EDIT: I guess I did a no-no trying to upload that many screencaps. Here's a link to them instead:
https://imgur.com/a/Qepl4RD
-
@SteveITS any ideas?
I've since went and retrieved the original FW and compared the configuration on it. It looks to be absolutely identical. Unfortunately, it's just not behaving the same on the replacement FW at 2.7.2.
-
@ctrlbreak I was on vacation last week. I haven't used HFSC but it's the more complex one.
Netgate has a recipe for CoDel which is basically auto/not-configured.
https://docs.netgate.com/pfsense/en/latest/recipes/codel-limiters.htmlYou should be able to restore just the traffic shaping portion from a backup if you want to try it and revert easily.
-
I suppose I could try that. Does anyone else have any methods to actually troubleshoot what could be the issue, rather than starting over?
This is extremely frustrating.
-
@ctrlbreak I'm happy to help but, first of all, could you try to summarize your requirement?
I.e. I have this 3 Mbit/s link and I'd like this traffic get priority over this other and that other traffic only get that amount of bandwidth etc etc (regardless of the actual configuration... I can see that you did use the wizard that -in my experience- is buggy and sometimes messy).
I would rather help you to re-do the config from scratch...
-
Thank you!
Yes. I have a grandfathered ASDL link at a remote property that receives some 'personal cloud' backup data... as well as sends some occasional video surveillance checks back regarding the property. The issue is the link is roughly 3MBps/0.3KBps D/U.
There's a scheduled rsync job that pushes data to the site over an OVPN connection that I wanted relegated to lowest priority / background queue. Effectively, everything else gets priority, but if things are idle, I'd like this sync job over OVPN to use what's available. If generic traffic picks up at the site, I want this low priority queue to back off immediately, leaving only a trickle of data sufficient so that rsync doesn't totally shit the bed, or the OVPN tunnel flap.
That being said, the wizard did create a 'High Priority' queue, which I then assigned some remote management FW rules too as well, just to ensure I don't get pinched out of remote manageability if the site is under extreme traffic.
As I mentioned, it does appear to be classifying the rules to the appropriate queues based on rule config, but the 'OthersLow' doesn't back off like it used to at all :-/
-
@ctrlbreak Ok thanks for the answer.
So, before we 'destroy' the current config, let's check what's going on behind the UI.
Are you in a position to connect remotely to your pfSense box and copy and paste here the output of these 2 commands?
pfctl -s queue -v
and
pftop -v queue
Thanks!
-
-
@ctrlbreak right.. you are using HFSC. In the queue qOtherLow you have both ecn and codel enabled. Try to remove codel and leave only ECN).
Could you also post your floating rules (mask the IPs...)
-
Hi. I removed Codel from the qOthersLow and restarted the FW to test. Still no change in behaviour.
Also, I have no floating rules on the FW.
-
@ctrlbreak Ok, leave Codel out anyway (you should use ECN or Codel not both and I suggest ECN for this specific case)
Regarding the firewall rules; I can guess that probably you did use the interface firewall rules, rather than the floating one.
Could you please check if you have any firewall rules for your WAN and LAN interface (or whatever you called re0 and re1): open the fw rules, scroll down and click on 'Advanced' then, scroll all the way down. You should see ACK/queue; for each fw rule, could you please paste the (or screenshot) the configuration of ACK/queue?
You must have fw rules that send the traffic to the queues as I can see that the various queues are receiving packets...
-
Indeed. I think i've understood your request, so sending some details. The following screenshots are actually all the rules on the FW, as well as the 'Advanced' settings for one of the rules.
-
@ctrlbreak Ok thanks just a question: how are you testing this? At the moment your default queue is qLink on re01(573.44Kb with a qlimit of 500 -which in my opinion is terribly wrong... I would lower that to 50 or less).
Did you test with traffic that will hit qOthersHigh and qOthersLow at the same time?
From what I see it should work (but again please lower down the qlimit from 500 to 50 for the re1 default queue)
It seems that you are generating traffic that is missing some rule -hence it will go to default and qOthersLow will take the priority)
If you could test making sure to hit traffic for both qHIgh and qLow... that would be great (and paste the result..)
For your use case btw I would scrap this mess :) and re do it from scratch using CBQ (the wizard, especially few years ago was not the best tool to configure QoS)
With CBQ you will easily define queue that can borrow bandwidth (if you decide so) as well as the priority will work beautifully well
-
@ctrlbreak Can you post your queue config? If the wizard was used there is this issue for instance: https://forum.netgate.com/topic/166621/priority-of-qotherslow-higher-than-default
