4 ms·
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 packe
by jandrese 6y ago
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.
- kazen44 6y ago> 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.
- jandrese 6y agoThe "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.
- garaetjjte 6y ago>IPv4's 576 minimum nearly triples the number of packets you generate IPv4 minimum MTU is... 68 bytes. >Every internet module must be able to forward a datagram of 68 octets without further fragmentation. https://tools.ietf.org/html/rfc791 https://tools.ietf.org/html/rfc791