Why would you reduce the MTU? I had an issue many years ago playing league of legends where log in would fail until I changed the MTU to be slightly lower. Something like 1486.
Tunnels always have the danger of reducing the MTU because they have to account for the header.
Worse, is that if a tunnel doesn't reduce the MTU and its packets are dropped by a router further down the line the the ICMP TOO_FAT response back to the tunnel endpoint not the original host. The tunnel endpoint has zero clue what to do with it and drops it on the ground, leaving the original host in the dark.
Even worse is when overzealous firewall admins start locking down everything they don't understand and that includes ICMP. "Some hackers could ping our networks!" Then you're truly up a creek.
Luckily MTU breakage is fairly easy to spot once you know what to look for. It's easy enough to fix too if your local firewall admins aren't the block everything type. Just fix the MTU on the tunnel endpoint and suddenly everything will start working.
One final note: If as a router or application developer you ever find yourself having to fragment packets, please, for the love of all that is holy, fragment them into two roughly equal sized packets. Don't create one huge packet and one runt from the leftovers. It hurts me to see packets coming in from some heavily tunneled source with 1400 byte initial packet followed by 3 or 4 tiny fragments. Or worse, 3 or 4 tiny out of order fragments followed by the 1400 byte bulk because the MAC prioritized small packets in its queue and send them first.
> One final note: If as a router or application developer you ever find yourself having to fragment packets,
Ideally, you should not want to fragment IP packets. It is far better to do MSS clamping in TCP to prevent the size of the TCP payload to grew above the size of the max MTU in the path. TCP can stitch together the data at the other node just fine, without routers in between having to fragment the IP packets, which will kill your bandwith in comparison.
The "application" in this case is for example a packet->radio bridge application, or a VPN tunnel endpoint. Something that is chewing on packets mid stream where you don't get much choice in the matter.
One thing I like about IPv6 is the minimum MTU of 1280. That's big enough that if I'm really uncertain about the environment I can just set my MTU to that and avoid future headaches without impacting performance too badly. IPv4's 576 minimum nearly triples the number of packets you generate, which is really noticeable when you're running routers close to their limit. Forwarding speed is often dominated by packets per second, not bytes per second.
1500 bytes is the de facto standard maximum size of an ethernet frame (not including headers). Therefore, if you want to send data over Ethernet, for example, an IP packet you can typically only send up to 1500 bytes at a time, and if you try to send more it gets dropped. This is called the Maximum Transmission Unit (MTU).
Apparently, their customers were tunneling IP packets through another protocol, meaning that instead of sending an IP packet in a Ethernet frame, they were sending an IP packet in an X packet in an Ethernet frame. Since, like IP and Ethernet packets, the X packets need to contain some information related to the protocol, there was less room for the IP packet. I.e. the MTU was lower.
When you set the MTU on your Operating System (OS), it refers to something slightly different. Instead of "this is the maximum size packet that will fit", it means "assume this is the maximum size packet that will fit". You can use that setting to force your OS to send smaller packets if you know the MTU is lower than your OS thinks.
1500 payload bytes is not de facto, it's part of the actual 802.3 standard. Any other payload MTU is actually non-standard (and the IEEE has went out of their way to avoid standardizing other payload sizes. Frame size had a bump with 802.3as but still expressly left payload at 1500).
MTU doesn't refer to anything different in that case, MTU always refers to the maximum size frame "this" node can handle. It also doesn't always mean the OS assumes it's the maximum size packet that will fit on a path it's the maximum size Ethernet frame the OS knows will fit on the NIC. The OS has other methods for assuming things about a path. Forcing MTU lower does force the OS to assume any path is never more than the MTU though which is why it works as a fix.
