The VLAN for IoT is already flagged for lowest priority at the interfaces->other types->VLAN "PCP = Background(1,lowest)"
Config in the shaper, queuing weights are used and in rules apply a DSCP value.
I have also made rules in the firewall->settings->normalization that mimic the shaper rules, i.e. same direction/source/destination, dscp value etc. to raise work machines to C5 and lower IoT to default (0x00).
Where I'm running into issue is that I cannot get Opnsense to actually prioritize traffic to/from specific machines - above other traffic, i.e. IoT devices.
This does mark the packet with the specific DSCP if I am not wrong, on which the shaper can classify the packet.However there is no reason to do this as you can classify based on 5-tuple. If you would have another device that would mark the packets before it hits the OPNsense or an application on an Endpoint would do it, you could then use OPNsense to take advantage of rules based on DSCP values.
If you have still performance issues with FQ_C while the WAN is in congestion, you can tune it further. Keep in mind one of the most important parameters to have when using FQ_C is to set the BW properly into the shaper > pipeIf you want to do BW prioritization you have to use WFQ not FQ_C.
Thank you for clarification on some of the feature sets.The issue is on the WAN asymmetrical connection. On the LAN side, everything is connected 1Gbs full duplex and see no issues to/from the media server (JellyFin) etc. I have a Netgear 308gs that is currently configured for port based priority (high, medium, low) but does allow DSCP values.All the rules in OPNSense are based on 5-tuple info, except given the nature of usage- "any" must be used for either source or destination as it is unknown (no set server, etc) and there seems to be an issue if ports or ips are not specifically declared as seen here: https://forum.opnsense.org/index.php?topic=24756.0
In all of my testing with QoS setups - WFQ does not mitigate bufferbloat and latency is all over the place for real time traffic. Fq_Codel does, and definitely helps when the house is busy.However, the issue is actually prioritizing individual devices for throughput priority NOT bandwidth sharing (i.e. all traffic from my desktop-> process first). Which is why I need to flag specific things as voice etc. Bandwidth is not the issue.For a contrast: DDWRT QoS allows for FQ_Codel (uses HTB or HFSC) to be used directly in conjunction with priority based on traffic type, ip address, mac address etc and can very simply accomplish my goal all on one page. Unless I have misinterpreted what is happening there and it is merely bandwidth sharing as well.So my original question remains: What is the correct way to do this in OPNSense?
3. If you care about prioritization, you can go one step back and use WFQ as scheduler and turn on Codel in the Queue. This may not perform as good as does FQ_C, but you will get prioritization based on Weights.
Since we cannot configure an AQM via Gui- How can this be done via console?? Any resources to point me to?
In Pipe you configure the scheduler, the Weights are configured in the Queues.Do not enable Codel in the Pipe, cause the Codel in Pipe is only turned on for dynamic queues e.g if you dont use manually created Queues.So do this:Pipe:- Configure BW- Scheduler WFQ- Everything else blankQueues:- Create Queues how many you need per a specific service- Set proper Weights, the higher the weight the more BW chunk the classified traffic will get. Image Weight as a ratio of the total BW configured in a Pipe- Create separate DL and UP Queues- Enable Codel on the QueuesRules:- Create Queues how many you need per a specific Queue to classify the packets into that specific Queue- Create separate DL and UP Rules to classify the packet to the specific QueuesGo thru > https://docs.opnsense.org/manual/how-tos/shaper_prioritize_using_queues.htmlRegards,S.
"SQM is an integrated system that performs per-packet/per-flow network scheduling, active queue management (AQM), traffic shaping, rate limiting, and QoS prioritization. In comparison, “classic” AQM only manages queue length and “classic” QoS only does prioritization."
“Smart Queue Management”, or “SQM” is shorthand for an integrated network system that performs better per-packet/per flow network scheduling, active queue length management (AQM), traffic shaping/rate limiting, and QoS (prioritization).“Classic” QoS does prioritization only.“Classic” AQM manages queue lengths only.“Classic” packet scheduling does some form of fair queuing only.“Classic” traffic shaping and policing sets hard limits on queue lengths and transfer rates“Classic” rate limiting sets hard limits on network speeds.
In comparison, “classic” AQM only manages queue length and “classic” QoS only does prioritization."
Yes, maybe you missintrepreted something.Just a quick recap:There are two methods to filter in FreeBSD: ipfw and pf (there are some older ones too). In the beginning pf was the standard and all GUI stuff is based on this. Sadly pf under FreeBSD isn't very active (compared to OpenBSD) and more development goes into ipfw. But the work to rewrite all the GUI stuff would take too much time and is way too error prone since so many ppl use this in very complex ways. Don't get me wrong, pf is still the way to go, no downsides in security. Current shaping technology is only developed on ipfw so the OPN guys build a way to use both, pf for filtering and ipfw for shaping. You can in theory mark packets with DSCP values via pf (firewall rules), but you can't match them afterwards. May I have to recheck this when I find more time, perhaps I didn't test everything.So in sum, if you want to speed up DNS, you don't need EF, you can just use the rule as a condition to give DNS more weight or bandwidth. The only way where DSCP really makes sense is in big enterprises where edge switches already mark the packets with DSCP. Then you don't need tons of rules to and link them to queues/pipes. You can just have any/any rules with a gives DSCP match.