How does MTU actually function GUI->real???

mer

@johnpoz said in How does MTU actually function GUI->real???:

POLA violation.

Dude ;) You dating yourself with pulling out that term.. heheheh Or maybe dating myself knowing what that means - hehehe

Maybe dating a lot of us. It's fun using it and then explaining it to people that have never seen a 6502 cpu.

Now how about bikesheds?

stephenw10

@mer said in How does MTU actually function GUI->real???:

Now how about bikesheds?

MrPete

@stephenw10 I knew I'd found friends here LOL

Y'all are youngsters though.

How many have loved JFFO?

(POLA is in the eyes of the beholder, BTW... at least we can document the "normal" use of the form field to make life easy.)

And yes, @johnpoz, this is all about tunnels... Not positive I need it yet, but I'm running HE tunnel over PPPoE...

stephenw10

Yeah you would need to set that lower, see:
https://docs.netgate.com/pfsense/en/latest/recipes/ipv6-tunnel-broker.html

If the WAN used for terminating the GIF tunnel is PPPoE or another WAN type with a low MTU, move the slider down as needed. For example, a common MTU for PPPoE lines with a tunnel broker is 1452.

Steve

johnpoz

@mrpete said in How does MTU actually function GUI->real???:

Not positive I need it yet, but I'm running HE tunnel over PPPoE...

Yeah mss clamping is not your issue with that.. I saw your other HE thread..

MrPete

@stephenw10 said in How does MTU actually function GUI->real???:

Yeah you would need to set that lower...

...a common MTU for PPPoE lines with a tunnel broker is 1452.

OK, this is quite wierd.... I'm testing to discover the actual limit. From inside pfSense...

ping6 -nms 1232 google.com
PING6(1280=40+8+1232 bytes) 2001:470:39:3c7::2 --> 2607:f8b0:400f:803::200e
76 bytes from 2607:f8b0:400f:803::200e, icmp_seq=0 hlim=119 time=6.014 ms

Anything larger fails.

I can reach both ends of the HE tunnel with 1452.

UPDATE: looks like a pfSense bug. Why oh why would it set the gif interface MTU to 1280 as a default?!!!

MrPete

@stephenw10
OK, and with my gif-based WANv6 interface manually set to MTU = 1492... I still have a minor question:

I can ping6 to either end of the HE tunnel with -nms 1452
But to go beyond requires -nms 1444

Is there some kind of extra packet overhead involved?

I'd really rather not chalk it up to "ipv6 is just strange that way" ;)

stephenw10

Hmm, yet you can ping the remote side of it with 1452?

johnpoz

@mrpete said in How does MTU actually function GUI->real???:

Why oh why would it set the gif interface MTU to 1280 as a default?!!!

You can change it on the HE site..

1280 is a common MTU for IPv6, since it like a requirement that IPv6 support this min size.

And you can change it on your interface..

MrPete

@johnpoz 'twas not an issue on the HE site. Just had to set 1492 there since I am using PPPoE.

and yes, I can and now have forced it on my end.

Just more than a little surprised to see a default of 1280?!!!

And YES @stephenw10 , I could ping the far end of the tunnel way beyond the MTU. Crazy.

And now, I can ping the far end of the tunnel with 8 bytes more than the outside world.

Here: Near, Far, GoogleBad, GoogleGood ;)

[2.6.0-RELEASE][root@jasmine.ds.org]/root: ping6 -nms 1452 2001:470:39:3c7::2
PING6(1500=40+8+1452 bytes) 2001:470:39:3c7::2 --> 2001:470:39:3c7::2
1460 bytes from 2001:470:39:3c7::2, icmp_seq=0 hlim=64 time=0.180 ms
^C
--- 2001:470:39:3c7::2 ping6 statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.148/0.163/0.180/0.013 ms
[2.6.0-RELEASE][root@jasmine.ds.org]/root: ping6 -nms 1452 2001:470:39:3c7::1
PING6(1500=40+8+1452 bytes) 2001:470:39:3c7::2 --> 2001:470:39:3c7::1
1460 bytes from 2001:470:39:3c7::1, icmp_seq=0 hlim=64 time=5.750 ms
^C

[2.6.0-RELEASE][root@jasmine.ds.org]/root: ping6 -nms 1452 google.com
PING6(1500=40+8+1452 bytes) 2001:470:39:3c7::2 --> 2607:f8b0:400f:802::200e
^C
--- google.com ping6 statistics ---
5 packets transmitted, 0 packets received, 100.0% packet loss
[2.6.0-RELEASE][root@jasmine.ds.org]/root: ping6 -nms 1444 google.com
PING6(1492=40+8+1444 bytes) 2001:470:39:3c7::2 --> 2607:f8b0:400f:802::200e
76 bytes from 2607:f8b0:400f:802::200e, icmp_seq=0 hlim=119 time=6.146 ms