OPNsense Forum
Archive => 18.1 Legacy Series => Topic started by: namezero111111 on April 21, 2018, 08:12:59 am
-
Dear folks,
regarding an earlier issue with traffic shaping (https://forum.opnsense.org/index.php?topic=7836),
what is the proper way to set up a default rule to direct traffic into a queue that has not been matched by previous rules?
Given the rules as attached results in ipfw configuration as below:
60001 8797 1208768 queue 10017 udp from any to 192.168.4.2 dst-port 6010-6016 via em3
60002 13956 16872512 queue 10009 udp from 192.168.4.2 6010-6016 to any via em3
[...]
60019 13922 16826624 queue 10007 ip from 192.168.0.0/16 to any via em3
60020 4 320 queue 10012 ip from any to 192.168.0.0/16 via em3
Traffic matching sequence 1011 is matched by both rules 60002 and 60019 (hence pushed through the pipe twice by different queues).
The expected outcome would be that the traffic matched 60002 and is left alone by 60019.
-
There is a sysctl with something count one. Do a sysctl -a grep one.
-
Mhhh, net.inet.ip.fw.one_pass is set to 1 on this system (appears to be the default, too)
Could it somehow be reinjected through strange interaction with route-to / pf ?
-
I set mine to have two pipes, one outbound and one inbound with their speeds set close to what my connection is capable of then set three sets of queues, one pipe for each direction with high priority at 100 for voip, medium at 50 for streaming movies and music and priority 1 for bulk. Then one rule in each direction for streaming devices pointing to the correct queue, the ip of the devices are used as either source or destination depending on direction. Windows 10 no longer is able to hog my bandwidth phoning home at the most inopportune times such as when streaming internet radio or on a phone call via voip. I use the codel scheduler with related settings only on the pipes, do not duplicate it in the queues!
-
Ok, but in that case you're not matching any default traffic (i.e. that doesn't match any other queue).
As fair as I understand traffic not matching any rule at all will bypass all traffic shaping; meaning shaped traffic will have to compete 1:1 with unshaped (default) traffic.
This is what we're trying to avoid.
-
@mimugmail: Do you think this can still be related to #1900?
Without route-to/multi-wan it behaves as expected...
-
Ok, but in that case you're not matching any default traffic (i.e. that doesn't match any other queue).
As fair as I understand traffic not matching any rule at all will bypass all traffic shaping; meaning shaped traffic will have to compete 1:1 with unshaped (default) traffic.
This is what we're trying to avoid.
But there is a rule, low priority for all other traffic, nothing is left out. In my case everything will be bound to one of three priorities. When you give a priority of 1 out of 100 for traffic from any source to any source that is not covered by specific addresses covered in 50 or 100, it's still a rule.
-
Problem is; at least in the case where (suspected) Multi-WAN is enabled, the traffic flows through both queues: A matched one and then the default catch-all, with one_pass set to 1.
I checked with the output of ipfw show, and the stats for both rules increase.
-
Problem is; at least in the case where (suspected) Multi-WAN is enabled, the traffic flows through both queues: A matched one and then the default catch-all, with one_pass set to 1.
I checked with the output of ipfw show, and the stats for both rules increase.
I may not be understanding fully what you are trying to do, are you trying to classify priorities to different wans? To be honest, I haven't experimented with that yet.
-
Thanks, everyone.
In our environment, there happened to be another rule matching (supernet), the problem is resolved and everything works perfectly with the shaper!
Thank you again!