Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Alex Atkin UK]

I've been pondering this for a while but figure I will throw this out there.

If I use mini Jumbo frames to the ONT with PPP of 1500, tests on the LAN show the maximum MTU as 1480 not 1500.
If I do not use mini-Jumbo, it shows as 1472 with PPP of 1480.

All interfaces on pfSense (except VPNs and L2TP obviously) show an MTU of 1500.

What on earth is going on here?  Fairly sure it didn't do this on FTTC.

[Chrysalis]

On FTTC the modem itself needs baby jumbo frame support, so I googled it, but apparently people have managed to get it working by just enabling it on the router like you have done, so I got no idea.

[Alex Atkin UK]

Yeah I never understood how it worked on the HG612 when it claimed its interfaces were 1500, but on the Zyxel you HAD to use the modified firmware.  I can't remember what I did on the HomeHub.

But what I can't understand here is it clearly IS adjusting the MTU, except its showing as unable to pass the right sized packets in both cases which is bizarre.

Everything seems normal on the pfSense side:

Code: [Select]

igc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1508

pppoe0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1500
So why on earth are the packets fragmenting?

[j0hn]

If you use http://www.letmecheck.it/mtu-test.php
what result do you get? (IPV6 needs to be disabled for the site to work).

1472 sounds right to me with 28 bytes being for headers, making an MTU of 1500.

PPP can knock that down to 1464 with the additional 8 bytes overhead.

I'm on Talktalk (IPOE) and have an MTU of 1500 set. The maximum unfragmented packet I can send is 1472.

With my previous PPP using ISP's the MTU would be limited to 1492 without baby jumbo frames. That gave 1464 as the maximum unfragmented packet.

So what you are seeing sounds about right too me?

[underzone]

Test with:

Linux command:
ping -c4 -M do -s 1472 1.1.1.1

Windows command:
ping -f -l 1472 1.1.1.1

If you can ping through with 1472 you are all set (add 28 and your max MTU is 1500, since you specified ping packet size, not including IP/ICMP header of 28 bytes).
1472 will work (if you have 1500 MTU) and 1473 will be too long (if you have 1500 MTU) .

[Weaver]

To clarify what J0hn meant: PPP+PPPoE is 8 bytes; PPP is 2 bytes, PPPoE is 6.

[Alex Atkin UK]

If you use http://www.letmecheck.it/mtu-test.php
what result do you get? (IPV6 needs to be disabled for the site to work).

1472 sounds right to me with 28 bytes being for headers, making an MTU of 1500.

PPP can knock that down to 1464 with the additional 8 bytes overhead.

I'm on Talktalk (IPOE) and have an MTU of 1500 set. The maximum unfragmented packet I can send is 1472.

With my previous PPP using ISP's the MTU would be limited to 1492 without baby jumbo frames. That gave 1464 as the maximum unfragmented packet.

So what you are seeing sounds about right too me?

Yeah, my bad, I was mis-remembering what it was supposed to be.  It doesn't help when trying to refresh my memory a LOT of the Google results involve pinging larger packets than can ever work over a normal MTU, stupid.  I just incorrectly thought it was supposed to be higher than 1480.   A quick test pinging over the LAN would have proven otherwise, DOH, why didn't I think of that?

That site shows everything is working as expected with an MTU of 1500.

To clarify what J0hn meant: PPP+PPPoE is 8 bytes; PPP is 2 bytes, PPPoE is 6.

Right, that much I remembered, I just got the ping overheads wrong so thought it should be higher than 1480.

I think what threw me is Xbox is showing 1480 when it used to show 1500 as I recall, I guess they changed how their test works?  Kinda stupid of them to not include overheads, makes it sound like the MTU is wrong when in fact its working correctly.  Mind you, its still showing strict NAT when I moved it back to the main LAN and uPNP is working, so it seems their tests are broken all round.

[Weaver]

An IPv4 ICMP ping is 20 + 8 = 28 bytes, or 48 bytes for IPv6 (presumably, haven’t tested the latter though).

[Alex Atkin UK]

IPv6 appears to be 1452 max packet size for ping.

[burakkucat]

An IPv4 ICMP ping is 20 + 8 = 38 bytes,

20 + 8 = ? 

[Alex Atkin UK]

20 + 8 = ? 

Oh right, so it IS 1472, that makes the Xbox claiming 1480 even more confusing.  I guess it IS using pings output that includes the TCP header but not the IP header.

Why do they have to confuse things like this?  Tell us either the MSS or the actual MTU.

From the top result on Google:

Confusingly, different systems have different definitions of what is included in an MTU calculation.

No wonder I got confused.

[Weaver]

You can’t just say MTU - you have to say what it is the MTU of, which protocol layer, so you’re stating what is and is not included in the byte count. Of course people often mean IP (PDU) MTU, but when they’re talking about PPPoE then they need to say that.

[craigski]

Just read this, as I was interested in the history of 'why 1500':

https://blog.benjojo.co.uk/post/why-is-ethernet-mtu-1500

https://blog.benjojo.co.uk/asset/1hhfq2UR8P

> -A longer maximum frame increases the memory requirement for a NIC using
> a simple, fixed buffer design. This is the *real* reason for the 1500
> byte limit; at the time we designed it (1979), buffer memory was much
> more expensive than it is now, and DMA controllers were too complex to
> be implemented in anything less than a full-custom chip.
In retrospect, a longer maximum might have been better, but if it increased the cost of NICs during the early days, it may have prevented the widespread acceptance of Ethernet, so I'm not really concerned.

[Alex Atkin UK]

Of course, as we also use this over the Internet there are now other considerations too.

While a larger MTU reduces CPU overhead and can increase the maximum speed slightly, it also will increase latency and make packet loss much more severe as the packets you've lost are bigger and take longer to re-transmit.

If you're trying to reduce bufferbloat, a smaller MTU and reducing the NICs txqueuelength might actually be beneficial.

[craigski]

If you're trying to reduce bufferbloat, a smaller MTU and reducing the NICs txqueuelength might actually be beneficial.

If you think about it, smaller MTU will potentially increase latency, more packets to process.

Easiest way to improve latency/bufferbloat is to limit the available bandwidth. Easy to test, if you are on 900 FTTP, set your switch port to 100Mb/s, and do a bufferbloat test