MTU & Fragmentation
ping -M do -s 1472 example.com goes through, but bump the size to -s 1473 and it fails with "message too long": one byte past a limit set not by your machine, but by a link somewhere along the way.
- ▸A packet that cleared your first hop can still die at a smaller link deeper in the path.
- ▸Lose one piece of a split packet and the whole message is gone, not just that piece.
- ▸TCP never gets fragmented: it settles the size up front, advertising a segment ceiling of its link minus 40 bytes.
That ping failure is your first clue that a size limit exists, and that it does not belong to your computer. Each link a packet crosses (the Ethernet to your router, the line to your ISP, a VPN tunnel, the far side's network) carries its own ceiling on how many bytes fit in one frame. On plain Ethernet that ceiling is 1500 bytes. A DSL line running PPPoE is 1492, because an 8-byte header eats into it. A tunnel is always smaller than the link it rides on, by whatever it wraps around your data.
Now trace a real path: your 1500-byte link, then a 1400-byte tunnel in the middle, then a 1500-byte link at the far end. What is the largest packet that can cross all three untouched? Not 1500, the number on the links at each end. The 1400-byte tunnel in the middle governs everyone who passes through it. The largest packet the whole path accepts is the smallest link on it, and no endpoint can know that number by looking at its own connection alone.
This is the trap in -s 1473: it fits your first hop with room to spare, so your machine sends it happily. It only fails later, at a link your machine never sees, whose ceiling it never measured. The size that matters is a property of the route, not of either end.