IPv6 Control Plane with FQ_CoDel Shaping

[meyergru]

Unless there is a less intrusive way of fixing this than a reboot, it should be pointed out as a caveat in the instructions. Would a fw state reset help?
Matter of fact, for me, this was unexpected and I still can neither reliably reproduce it nor are the effects consistent.

[Seimus]

Unless there is a less intrusive way of fixing this than a reboot, it should be pointed out as a caveat in the instructions.

I agree, but thinking about it, into which section of the shaper docs to point it out? This is not specific only to the examples, but to the Shaper as whole. I think if this is the case it should be under the main Shaper section.

Would a fw state reset help?

Would be worth a try.

@All
If somebody hits this problem can that person try to reset the fw states and let us know?

Matter of fact, for me, this was unexpected and I still can neither reliably reproduce it nor are the effects consistent.

Its interesting this is happening at all, from the description of the problem one would assume that the problem could be due to packets not being classified properly, but in that case no BW reduction would be visible if the shaper is bypassed.


Regards,
S.

[OPNenthu]

Would a fw state reset help?

Probably not, IMO.  I tested with an OPNsense VM in a double-NAT setup (IPv4-only), so not exactly the same situation, but I did reproduce the issue.

I configured the control & data plane pipes, queues, and rules.  I set the Download pipe to 545Mbit/s and the Upload to 34Mbit/s accounting for the VM/NAT overhead.

After applying the changes I observed a false start in the Bufferbloat test (hung on "Warming Up..."), followed by a semi-successful test (reduced performance on the Download), followed by a second false start.  See "semi_successful.png".

I then reset the F/W states from the Diagnostics menu and gave it a minute to re-establish and settle.  The next couple of Bufferbloat tests did not stall, but the Download performance was still subpar.  This was reproducible.  See "after_reset.png".

Finally I rebooted the VM and then only observed the full performance:  Result
(Sorry, ran out of image quota on this post, so had to crop the second image and could not upload the final one).

[Seimus]

Alright looks like following observations can be made,

A. There really is a glitch or BUG, when configuring or Changing the Shaper
B. Issue is causing degraded performance e.g lower than expected Throughput and/or application stall(during congestion)
C. This is somewhat reproducible
D. Affects any traffic matched by the Shaper Rules
E. Clearing States in pf doesn't fix the problem
F. FW reboot does fix the problem

So there is either something wrong with OPNsense pushing the config into ipfw/dummynet or ipfw/dummynet itself.

Regards,
S.

[vik]

@Seimus and @franco ... any ETA on a fix for this issue? ... thx