MTU Issue?

[NetriX]

I've always had an optimal MTU value of 1500 after adding the 28 byte header - lowest non fragmentation is 1472.

 

Received Netduma router and set it up then decided to test my mtu again. The new optimal value is 1499 (28 byte header added - 1471).

 

Is something improperly configured by chance? It appears to be some sort of overhead.

[Netduma Crossy]

Hi GlitchKing, welcome to the forum

 

Could you try just giving the Netduma a reboot first. Also, could it be possible that the MTU on the router that the Netduma is connected to isn't set to 1500? Also try setting the MTU on the Netduma to 1500 incase 'automatic' is doing something weird

[NetriX]

Hi Crossy, thanks for warm welcome 

 

I have it directly connected to my cable modem in bridge mode, previously I had an Asus RT-AC56R that I used, I connected it again and tried a direct modem connection and both have 1500 MTU values. Only the Netduma's optimal setting is 1499 which leads to believe on your end.

 

Also, I did a factory reset on my R1 and got the same results. 

[Netduma Crossy]

Hi Crossy, thanks for warm welcome 

 

I have it directly connected to my cable modem in bridge mode, previously I had an Asus RT-AC56R that I used, I connected it again and tried a direct modem connection and both have 1500 MTU values. Only the Netduma's optimal setting is 1499 which leads to believe on your end.

 

Also, I did a factory reset on my R1 and got the same results. 

 

If you change the MTU on the Netduma in Settings >> WAN and Settings >> LAN to 1500 does that sort it at all?

[NetriX]

It would change my mtu to 1500. However, that is not my optimal MTU settings when using the Netduma as compared to other routers, for some reason.

 

Example:

C:\Users\brand>ping 8.8.8.8 -f -l 1472

Pinging 8.8.8.8 with 1472 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

Ping statistics for 8.8.8.8:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\Users\brand>ping 8.8.8.8 -f -l 1471

Pinging 8.8.8.8 with 1471 bytes of data:
Reply from 8.8.8.8: bytes=64 (sent 1471) time=52ms TTL=37
Reply from 8.8.8.8: bytes=64 (sent 1471) time=51ms TTL=37
Reply from 8.8.8.8: bytes=64 (sent 1471) time=50ms TTL=37
Reply from 8.8.8.8: bytes=64 (sent 1471) time=49ms TTL=37

Ping statistics for 8.8.8.8:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 49ms, Maximum = 52ms, Average = 50ms

Normally it wouldn't need to fragment at 1472 and thus adding the 28 byte header it equates to 1500. In my case, I always end up with an optimal 1499 setting because 1471 + 28 = 1499 MTU.

 

I don't suppose it's an actual problem in itself to have it slightly lower than 1500, just a curious case as to why. 

 

Update - I found a similiar question on http://serverfault.com/questions/70075/why-does-lowering-the-mtu-from-1500-to-1499-allow-me-to-access-most-websites and a detailed suggested answer:

 

 

That may mean some other device upstream from you has a smaller mtu and someone has mis-configured a firewall to block all ICMP preventing MTU discovery for the path.

 

Many naive network administrators seem to believe that ICMP has no purpose and you can completely block it without any repercussions.

[Netduma Fraser]

We haven't changed anything in relation to that so it could be due to the end host.

 

Either way, I don't believe MTU really has as huge effect as people seem to think it does so I wouldn't worry that it is 1499 now instead