5

There is a server I connect to over the WAN and somewhere over the route there is packet loss unless I set the interface MTU to 600:

ifconfig eth0 mtu 600

Doing this causes problems with connections to other equipment. In order to get both to work I tried setting the 600 MTU for the one bad route:

ip route add 10.10.10.0/24 via 10.11.11.1 mtu 600

Or

ip route add 10.10.10.0/24 via 10.11.11.1 mtu lock 600

Then verifying that this is being chosen with:

ip route get 10.10.10.20

But then tests with only the MTU set for a route indicate it isn't going at 600 but as if no change had been made from the default.

Is there any less obvious difference between these methods of adjusting the MTU? Possibly MTU discovery?

  • 1
    That sounds like some kind of network problem. I can't even remember when I had to reduce the default of 1500 MTU lower to adjust to old equipment (I have vague memories from 2 decades ago). On a WAN perhaps a firewall setup for things like DDoS could be affecting your connection. Have you tried running a traceroute to see where your connection drops out or to check MTU's traceroute --mtu [ip]. Perhaps its not the server dropping the packets but something in between? Otherwise path MTU discovery I thought happened automatically with Ethernet2...but I could be mistaken. – dakka Jul 21 '15 at 5:53
  • I changed the post to be more clear on this point - it is definitely something in between my computer and the server, not the server itself. Unfortunately after quite some hours trying to debug the root of the problem nothing but dropping the MTU on the interface worked. – buckaroo1177125 Jul 21 '15 at 6:29
  • Same problem for me. Setting MTU for a route seems have no effect. From man ip-route, it seems that the MTU setting for a route is handled differently for IPv4 and IPv6: If the modifier lock is used, no path MTU discovery will be tried, all packets will be sent without the DF bit in IPv4 case or fragmented to MTU for IPv6. – cyfdecyf Nov 16 '16 at 17:49
1

I did find that using "ip route via mtu " did work when setting properly on the side that was dropping fragments.

My setup: 1500MTU local eth0 -> 1428 MTU IPSEC -> WAN -> (fragment dropping firewall here?) -> 9182 MTU VPN concentrator -> 1500 MTU destination host.

All packets flowing from local to destination make it fine because the 1428MTU IPSEC tunnel is fragmenting locally before sending packets, however, I was receiving only the first of the fragments back from the destination->local responses, as it was sending 1500 byte packets to the vpn concentrator which was then getting fragged into 1428+additional fragments and the additional fragments were being dropped on the return path by the firewall. Turns out that setting "ip route add $local via $dest_gw mtu 1400" stopped the fragmentation on the return packets which kept the FW from dropping the return packets.

You might need to set your MTU for the path on both sides of the connection to be successful.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.