Showing results for 
Search instead for 
Did you mean: 

ping v4 echo replies are split into 3 fragments?

Level 1
Level 1

pmtu is 1472. I am sending ping without -M option(ping -s 2000 The first packet, expectedly gives me "need to frag" error. The echo reply for second packet has this:

10:44:32.424610 00:00:5e:00:01:00 > 02:1e:4f:09:a6:8e, ethertype IPv4 (0x0800), length 1442: (tos 0x0, ttl 63, id 56141, offset 0, flags [+], proto ICMP (1), length 1428) > ICMP echo reply, id 2406, seq 2, length 1408

10:44:32.424626 00:00:5e:00:01:00 > 02:1e:4f:09:a6:8e, ethertype IPv4 (0x0800), length 106: (tos 0x0, ttl 63, id 56141, offset 1408, flags [+], proto ICMP (1), length 92) > icmp

10:44:32.424628 00:00:5e:00:01:00 > 02:1e:4f:09:a6:8e, ethertype IPv4 (0x0800), length 562: (tos 0x0, ttl 63, id 56141, offset 1480, flags [none], proto ICMP (1), length 548) > icmp


echo request has 2 fragments, as expected.

1. Am i looking at it properly? Are these 3 fragments of the echo reply?

2. Is this the expected behavior for v4?

Attached the entire tcpdump.


3 Replies 3

Peter Paluch
Cisco Employee
Cisco Employee


These packets really seem to be fragments of the former packet. Based on the fragment offset, they fit into each other nicely. Their payload sizes are 1408, 72, 528 bytes, respectively, totalling the size of 2008 bytes which is the size of the ping body including the ICMP header. It seems as if the reply was originally sent in two fragments, the first carrying 1480 bytes in its payload (the entire packet probably had the usual 1500 bytes), the second carrying the remaining 528 bytes in its payload. However, it seems that the first fragment had to be fragmented again in transit, and the device that has fragmented it was using the (path) MTU of 1428. So it chopped the first 1408 bytes off the original first fragment, leaving 1480-1408=72 bytes as the remainder. This would explain what you see here: your IP packets arriving in three resulting fragments, their total size being 1428, 92, 548 bytes, and the payloads being 1408, 72, and 528 bytes.

The other question is why a device en route decided to perform fragmentation down to the (path) MTU of 1428 bytes. Quite frankly - I do not know. This would require knowing more about the devices on the path between the source and destination of this ping.

Best regards,