ping v4 echo replies are split into 3 fragments?

Sh HH · ‎03-01-2015

pmtu is 1472. I am sending ping without -M option(ping -s 2000 104.130.2.3). 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)

104.130.2.3 > 182.121.242.3: 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)

104.130.2.3 > 182.121.242.3: 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)

104.130.2.3 > 182.121.242.3: 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.

Peter Paluch · ‎03-02-2015

Hi,

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,
Peter

Sh HH · ‎03-03-2015

Thanks for the reply Peter. The sending and receiving entities are virtual machines, connected by logical switch connections. Frankly, I have started using this type of topology recently, so will have to find out the details of the devices along the path.

Either ways, what surprises me about it is the pmtu. I used the "tracepath -n <ip address>" command to get the pmtu as 1472. If any device along the path could handle only 1428, should I not see it reflected in the tracepath output. The only difference is tracepath sends udp and ping, icmp, but I don't see how that matters. Am i missing something?

Peter Paluch · ‎03-05-2015

Hi,

You are welcome. Hmmm, at this point, I am confused. If I am getting you correctly, you are saying that the virtual machines that are the endpoints are interconnected by a logical switch - does that mean that they are on the same segment with no routers inbetween? Can you perhaps be more specific with respect to how the logical switch works?

The other thing, however, is that if there are asymmetrical MTUs then they might not necessarily show in the tracepath output. Or even better, let me ask you: If you perform the tracepath from both endpoints to each other, do they report the same PMTU?

Best regards,
Peter