Performance regression 2.7.2 to 2.8
-
@fathead pfSense doesn’t block anything by default. I’d check DNS and connectivity from the other device.
-
We may have just hit this internally.
Try setting an MSS value of 1472 on the 6RD tunnel interface. That usually has an MTU of 1472 but for some reason it doesn't seem to be seen.
Are you using if_pppoe?
-
@stephenw10 That is it!
But How do I set the MSS on just the 6RD?
Besides the MSS on interfaces.php
It is set currently on the WAN.
if_pppoe was off at first turning it on did not change; if_pppoe is on currently.
So rfc5969 says minus 20 bytes, does setting MSS on interfaces.php affect ipv4 as well?! -
Setting MSS in the interface adds pf scrub rules for IPv4 and IPv6 at 40B and 60B below the value set respectively.
Setting that on the 6RD tunnel would theoretically affect any IPv4 traffic but since it only carries IPv6 it doesn't matter. So you should just be able to set it there.
-
If that works and it wasn't required in 2.7.2 then it confirms the regression and we'll dig deeper.
-
@stephenw10
MSS is set to 1472 on the only wan interface, the only other interface is the lan.
interfaces.php?if=wan How does this not affect ipv4?
ifconfig shows wan_stf with mtu1472
How to check MSS or are the pf scrub rules in a file or only in running memory?
Also does a doc exist on docs.netgate.com about ipv6 packet too big being a default pass rule, is creating a pass rule for this redundant? -
This post is deleted! -
Ah, OK the 6RD tunnel is not exposed dircetly... Hmm. I don't use 6RD.
So, yes, applying that on the WAN will affect IPv4 traffic. And more importantly may not apply it to traffic inside the 6RD tunnel. Setting it on LAN would though.
The actual value required may vary but in the one other case I've seen it was 1472.
We are digging into this....
-
@fathead said in Performance regression 2.7.2 to 2.8:
How to check MSS or are the pf scrub rules in a file or only in running memory?
Look at the ruleset file: /tmp/rules.debug
-
@stephenw10 Thank you!
Looks like it affects both.
before:
scrub on $WAN inet all max-mss 1452 fragment reassemble
scrub on $WAN_STF inet6 all max-mss 1432 fragment reassemble
after setting MSS:
scrub on $WAN inet all max-mss 1432 fragment reassemble
scrub on $WAN_STF inet6 all max-mss 1412 fragment reassemble
What file creates the scrubs that are applied? -
Oh, OK. That looks correct then. Except it's not including the 6RD overhead. What we want to see there is:
scrub on $WAN inet all max-mss 1452 fragment reassemble scrub on $WAN_STF inet6 all max-mss 1412 fragment reassembleYeah OK let me dig into this. It's likely a simple patch....
-
Can you test a patch?
That should allow if_pppoe to work as expected. mpd5/netgraph is a different matter!
-
@stephenw10 Thanks for the reply!
That worked instantly.scrub on $WAN inet all max-mss 1452 fragment reassemble scrub on $WAN_STF inet6 all max-mss 1412 fragment reassemble -
Nice
And traffic passing as expected?
I imagine one of our devs might have a better patch than that but it proves the issue.
-
@stephenw10
99% of FIN_WAIT_2 are gone.
WAN side seems OK.
LAN side inconsistently get NO_TRAFFIC:NO_TRAFFIC with 64:ff9b::7f00:1 -
Hmm, that could be nothing if you're not seeing connection issues at the clients.
You could try setting a slightly lower MSS value and see if it changes anything.
-
ping6 -s56 64:ff9b::7f00:1
ping6 -s32 64:ff9b::7f00:1
Sometimes works, sometimes does not. -
Hmm, just with different ping sizes?
MSS has no effect on pings, only TCP. So nothing should have changed there.
-
@stephenw10
ping6 from lan side to pfSense it self and lan to lan.
I have only tested with small packets, however so far size does not matter.Both fail sometimes:
ping6 -s56 64:ff9b::7f00:1
ping6 -s32 64:ff9b::7f00:1
Even the default address of 64:ff9b::c0a8:101 sometimes fails.
What I do not understand is why it comes and goes.
setting lan side mtu/mss to 1.4k, 1.5k or 9k changes nothing. -
@fathead said in Performance regression 2.7.2 to 2.8:
ping6 from lan side to pfSense it self and lan to lan.
Hmm, well that would have nothing to do with the pppoe change on WAN. Something local blocking traffic?
