Regression #11952
closed
Traffic matching rules with limiters is not handled by DUMMYNET
100%
Description
Traffic limiters have no effect when applied in 21.05 or 21.09 in a multi-wan environment.
3 ISPs - each 1Gbit up / 1 Gbit down.
6 limiters created (1 up, 1 down for each of 3 ISPs), each with a child queue. Each uses droptail as queue management algorithm, and FQ_CODEL as scheduler, limited to 25 Mbit/s. Child queues use droptail as the queue management algorithm. All 6 limiters are identical for testing purposes.
Limiters applied as floating MATCH traffic rules. As traffic passes counters increase as expected, yet applied pipes have no effect
Currently no other firewall rules enabled on the system. For reference, this was working as is on 2.4.
anchor "userrules/*"
pass out quick on { ix0 ix1 ix2 } inet proto icmp from any to any icmp-type trace tracker 1621863034 keep state label "USER_RULE: ICMP policy routing traceroute workaround"
pass in quick on { ix0 ix1 ix2 } inet proto icmp from any to any icmp-type { echorep,echoreq } tracker 1621863105 keep state label "USER_RULE: ICMP limiter drop echo-reply under load workaround"
match in on { ix0 } inet from any to any tracker 1621861885 dnqueue( 1,2) label "USER_RULE"
match in on { ix2 } inet from any to any tracker 1621862371 dnqueue( 3,4) label "USER_RULE"
match out on { ix2 } inet from any to any tracker 1621862389 dnqueue( 4,3) label "USER_RULE"
match in on { ix1 } inet from any to any tracker 1621862308 dnqueue( 6,5) label "USER_RULE"
match out on { ix0 } inet from any to any tracker 1621861900 dnqueue( 2,1) label "USER_RULE"
match out on { ix1 } inet from any to any tracker 1621862327 dnqueue( 5,6) label "USER_RULE"
[21.09-DEVELOPMENT][admin@gw01]/root: ipfw sched show
00001: 25.000 Mbit/s 0 ms burst 0
q65537 50 sl. 0 flows (1 buckets) sched 1 weight 0 lmax 0 pri 0 droptail
sched 1 type FQ_CODEL flags 0x0 0 buckets 0 active
FQ_CODEL target 5ms interval 100ms quantum 300 limit 20480 flows 65535 ECN
Children flowsets: 1
00002: 25.000 Mbit/s 0 ms burst 0
q65538 50 sl. 0 flows (1 buckets) sched 2 weight 0 lmax 0 pri 0 droptail
sched 2 type FQ_CODEL flags 0x0 0 buckets 0 active
FQ_CODEL target 5ms interval 100ms quantum 300 limit 20480 flows 65535 ECN
Children flowsets: 2
00003: 25.000 Mbit/s 0 ms burst 0
q65539 50 sl. 0 flows (1 buckets) sched 3 weight 0 lmax 0 pri 0 droptail
sched 3 type FQ_CODEL flags 0x0 0 buckets 0 active
FQ_CODEL target 5ms interval 100ms quantum 300 limit 20480 flows 65535 ECN
Children flowsets: 3
00004: 25.000 Mbit/s 0 ms burst 0
q65540 50 sl. 0 flows (1 buckets) sched 4 weight 0 lmax 0 pri 0 droptail
sched 4 type FQ_CODEL flags 0x0 0 buckets 0 active
FQ_CODEL target 5ms interval 100ms quantum 300 limit 20480 flows 65535 ECN
Children flowsets: 4
00005: 25.000 Mbit/s 0 ms burst 0
q65541 50 sl. 0 flows (1 buckets) sched 5 weight 0 lmax 0 pri 0 droptail
sched 5 type FQ_CODEL flags 0x0 0 buckets 0 active
FQ_CODEL target 5ms interval 100ms quantum 300 limit 20480 flows 65535 ECN
Children flowsets: 5
00006: 25.000 Mbit/s 0 ms burst 0
q65542 50 sl. 0 flows (1 buckets) sched 6 weight 0 lmax 0 pri 0 droptail
sched 6 type FQ_CODEL flags 0x0 0 buckets 0 active
FQ_CODEL target 5ms interval 100ms quantum 300 limit 20480 flows 65535 ECN
Children flowsets: 6
[21.09-DEVELOPMENT][admin@gw01]/root: ipfw queue show
q00001 50 sl. 0 flows (1 buckets) sched 1 weight 0 lmax 0 pri 0 droptail
q00002 50 sl. 0 flows (1 buckets) sched 2 weight 0 lmax 0 pri 0 droptail
q00003 50 sl. 0 flows (1 buckets) sched 3 weight 0 lmax 0 pri 0 droptail
q00004 50 sl. 0 flows (1 buckets) sched 4 weight 0 lmax 0 pri 0 droptail
q00005 50 sl. 0 flows (1 buckets) sched 5 weight 0 lmax 0 pri 0 droptail
q00006 50 sl. 0 flows (1 buckets) sched 6 weight 0 lmax 0 pri 0 droptail
Files
Updated by Adam Goldberg over 3 years ago
Could it be possible that the auto-added NETGATE rules, which have higher precedence, are overriding the USER limiter rule?
[21.09-DEVELOPMENT][admin@gw01]/root: cat /tmp/rules.debug | grep "pass in on { ix0 }"
pass in on { ix0 } inet from any to <negate_networks> tracker 10000001 keep state dnqueue( 1,2) label "NEGATE_ROUTE: Negate policy routing for destination"
pass in on { ix0 } $GWWAN_DHCP inet from any to any tracker 1621870415 keep state dnqueue( 1,2) label "USER_RULE: WAN IN"
[21.09-DEVELOPMENT][admin@gw01]/root: cat /tmp/rules.debug | grep "pass in on { ix1 }"
pass in on { ix1 } inet from any to <negate_networks> tracker 10000003 keep state dnqueue( 6,5) label "NEGATE_ROUTE: Negate policy routing for destination"
pass in on { ix1 } $GWSP_DHCP inet from any to any tracker 1621870445 keep state dnqueue( 6,5) label "USER_RULE: SP IN"
[21.09-DEVELOPMENT][admin@gw01]/root: cat /tmp/rules.debug | grep "pass in on { ix2 }"
pass in on { ix2 } inet from any to <negate_networks> tracker 10000005 keep state dnqueue( 3,4) label "NEGATE_ROUTE: Negate policy routing for destination"
pass in on { ix2 } $GWNW_DHCP inet from any to any tracker 1621870270 keep state dnqueue( 3,4) label "USER_RULE: NW IN"
Updated by Jim Pingle over 3 years ago
It's unlikely the negate rules would be hit unless nothing else matched (note that they lack quick)
Another way to check is to look at the rule counters on the match rules you use to apply the limiters and see if traffic is shown as hitting them.
We did recently have an issue with match rules in general so it's possible there is another lingering issue here, see #11857 for that one.
Updated by Adam Goldberg over 3 years ago
Thanks for the fast response, Jim. I believe this to be a different problem. The rules are indeed being matched as the counters increase accurately. However, the applied limiters are ignored (no traffic restricted to 25 Mbit/s as in the example). Additionally, I receive no parse errors as seen in #11857.
Additionally, it appears no matter how the limiter is tweaked (droptail, CODEL, PIE, different bandwidths, ECN on/off, etc..) it is completely ignored for the passed traffic. It's as if the limiter is just not being applied to the floating rule.
Updated by Jim Pingle over 3 years ago
- Tracker changed from Bug to Regression
- Subject changed from Traffic shaper limiters ignored on 21.05/21.09 to Traffic matching rules with limiters is not handled by DUMMYNET
- Status changed from New to Feedback
- % Done changed from 0 to 100
- Plus Target Version changed from 21.09 to 21.05
- Release Notes changed from Default to Force Exclusion
PR with a fix was merged into src branches, will be in builds soon.
Updated the subject to better reflect what the problem was, but excluding from release notes since it was a regression in behavior introduced after the previous release.
Updated by Adam Goldberg over 3 years ago
Issue appears resolved on 21.09.a.20210526.0100
Updated by Jim Pingle over 3 years ago
- Status changed from Feedback to Closed
Confirmed working here as well on latest 21.05 build. I see traffic in limiter info now, and my bufferbloat score is back to A+ from F.
Updated by Jim Pingle over 3 years ago
- Target version changed from 2.6.0 to 2.5.2