Networking – MTU and ping

So, sometimes you need to test the size of a package or optimal maximum transmission unit (MTU) that goes through the network or a tunnel. For instance the MTU of a WireGuard tunnel is usually 1420 bytes (for IPv4), and with the header overhead it comes out around 1380 bytes.

To actually test if the tunnel passed the amount of bytes needed to not fragment (dividing up the package), one way to test is to use ping.

ping -M do -s 1380 IP

From the man page:
-M pmtudisc_opt
Select Path MTU Discovery strategy. pmtudisc_option may be either do (set DF flag but subject to PMTU checks by kernel, packets too large will be rejected),
want (do PMTU discovery, fragment locally when packet size is large), probe (set DF flag and bypass PMTU checks, useful for probing), or dont (do not set DF flag).

From what we can see, the -M do enables the do not fragment part of ping, and it tries to send the packet through.

Pinging through an WireGuard tunnel with a size of 1400 bytes:

ping -M do -s 1400 10.10.50.10
PING 10.10.50.10 (10.10.50.10) 1400(1428) bytes of data.
ping: local error: message too long, mtu=1420
ping: local error: message too long, mtu=1420

Same test with the size set to 1380 bytes:

ping -M do -s 1380 10.10.50.10
PING 10.10.50.10 (10.10.50.10) 1380(1408) bytes of data.
1388 bytes from 10.10.50.10: icmp_seq=1 ttl=63 time=33.2 ms
1388 bytes from 10.10.50.10: icmp_seq=2 ttl=63 time=32.4 ms

---

So.. where can this be usefull? When working with networks, sometimes you encounter different technologies that has different MTU’s, like for instance the WireGuard tunnel.

Other such things are VLans, QinQ – which is VLans inside of VLans, IPSec tunnels and more.

Ping is a great tool to test basic network functionality before breaking out bigger guns. Maybe it’s just the size that is misconfigured.