MTU Configuration

And why you should not block ping on your network

It is common for 4G / LTE connections to be unable to support full size (1500 byte) frames. In fact, we have seen networks that support MTUs of less than 1300, which can break a lot of software.

We also commonly see broken path MTU discovery (PMTUD) and when combined with low MTUs, this can cause a lot of problems.

First of all we need a bit of background information about what MTU is:

What is MTU?

MTU stands for maximum transmission unit, or in other words the maximum size of a packet that a path between two routers can support. Think of it like a road tunnel with a height restriction - small cars can fit through, big vehicles cannot fit.

Most networks can support 1500 byte packets and this is the 'standard' MTU setting on most routers. However, not all paths between routers can support a 1500 byte MTU, so it is sometimes necessary to reduce the MTU size.

SIM card networks are particularly likely to not support full size (1500) byte MTUs. This is because the carriers often have to 'encapsulate' packets inside of other packets to transport them across their networks, and this reduces the available MTU as there is overhead introduced by the encapsulation algorithm.

What is path MTU discovery (PMTUD)?

Path MTU discovery is the technique that routers are meant to use to work out the maximum size packet that they can send. In very simple terms, a client will send a 1500 byte packet to the server at the far end. If any of the routers that the packet has to pass through in order to get to the server at the other end cannot support a 1500 byte packet, they will return a "packet too large" message to the client, telling the client what MTU they can support (for instance, 1428).

The client should receive this message and adjust the size of the next packet it sends out to a smaller MTU so as it can get all the way to the server.

Unfortunately, PMTUD is often broken...

Why is PMTUD often broken?

Path MTU discovery relies on the ICMP (ping) protocol to send the 'packet too large' messages. Unfortunately, some networks block the ICMP protocol for "security" reasons. If ICMP is blocked, the "packet too large" messages cannot get through, and the devices on the network have no ability to work out that they need to send smaller packets.

Should I block ICMP (ping) on my network?

No!! It's a stupid thing to do, and serves absolutely no purpose other than breaking how things were designed to work.

For more details of why you should not block it, see: http://shouldiblockicmp.com/

If you really must block ICMP, at least allow Fragmentation Needed (IPv4 Type3, Code4) and Packet Too Big (IPv6 Type2, Code0) messages so as PMTUD works.

You can check if you have a ICMP blackhole on your network with this checker from Cloudflare: http://icmpcheck.popcount.org/

Other reasons PMTUD might be broken

Unfortunately, some routers are just very bad at handling "packet too large" messages. Some routers simply ignore them, some routers refuse to forward them on, some routers do not send them in the first place.

Unfortunately, if you are behind a network that does not forward the ICMP messages on to you, there is not much you can do about it, other than manually configure the MTU as a workaround.

Typical signs of MTU issues

The most obviuous sign is that seemingly random web pages won't load

• If you have trouble getting some websites to load, but others load just fine, it's probably an MTU issue.

• Github.com and Amazon.com generally show signs of MTU issues, whereas bbc.co.uk is more tolerant to bad MTU configuration.

• If the non-SSL version of webpages works, but SSL doesn't work, it's probably an MTU issue.

You may also see MTU issues show up when you can't get to a camera or router web admin page:

• If you can't get to the login page of a Teltonika router, or if the login page takes forever to load, or throws an error when you try and login, it's probably an MTU issue.

• If a Teltonika router won't connect to RMS, it's often an MTU issue

Or if you have problems viewing RTSP streams from cameras

• RTSP streams using TCP are much more tolerant to MTU issues than RTSP over UDP.

SIM card networks with known low MTUs

Some SIM card companies are doing a level of 'magic' in their networks in order to seemingly put static IP addresses on SIM cards or connect them to private VPNs. Most of these solutions rely on NAT, and they almost universally break PMTUD.

Arkessa SIMs

If you have a SIM from Arkessa (or one of their resellers such as Zest4) that has a NATted static IP, you will likely need to set the MTU to around 1400.

Verizon SIMs

Not all Verizon cell towers seem to be able to cope with 1500 MTU. We have seen SIMs on the same cell tower, otherwise identical, where one was working fine with a 1500 MTU and the other needed a lower MTU. 1428 is normally always supported.

Dealing with MTU Issues

On the basis that we cannot rely on PMTUD to work reliably on SIM card networks, we have to manually limit the MTU on routers. Giraffe have done lots to try and make our Edge Controller work by default even on really broken networks, but we cannot fix other devices that may be plugged into the router.

The starting point for fixing MTU issues is to limit the MTU on the routers WAN interface to a lower value than the 1500 default.

We generally recommend a 1428 value as a 'safe' value that should always work. There is relatively little downnside of setting a lower MTU other than slightly less efficiency but for most situations this will not be noticeable.

Teltonika

On a Teltonika router, the MTU can be set by going

Network -> Interfaces -> Mobile -> Edit

You can force the MTU in the Override MTU field:

Peplink

Peplink routers default the MTU to 1428 on their cellular interfaces and it shouldn't be necessary to change this. We do not recommend increasing it.

Edge Controller workarounds

The Giraffe Edge Controller does various workarounds to try and mitigate the effects of badly configured networks

• All RTP video packets generated by the Edge Controller are limited to an MTU of 1000. This enables them to be encapsulated over various VPN tunnels and still make it safely to the destination. This includes the WebRTC packets as well as any RTSP streams generated by the Edge Controller.

• Any packets sent from the Edge Controller to the Giraffe platform are limited to 1200 MTU in order to maximise the chance of them arriving successfully.

• Any proxied connections to cameras or other devices behind the Edge Controller have their MTU limited and we use MSS clamping to try and maximise compatibility.