Fragmentation. It's what happens when a big packet spawns a lot of smaller baby packets because the MTU is not big enough, be it anywhere in transit (IPv4) or only at the source (IPv6). It also might cause engineers to lose their sanity while troubleshooting weird problems.
Up until recently, I have to shamefully admit, I had no idea how to read a Wireshark capture of fragmented packets. It always looked dodgy to me and I didn't make the effort to make some sense out of it.
You can see a bunch of fragments, which it says are Reassembled in #7, but packet number 7 has a size of 134. Errr, what? Worry not, it shall all be explained below!
What's the capture about?
First thing's first, the screenshot above shows a capture of a ping between two routers in GNS3 with a size of 9000. As the link between those two routers runs a 1500 MTU, this bad boy has to be fragmented.
One tiny bit of information: a ping command in IOS with a size of 9000 will calculate the ICMP payload so that the total IP packet is 9000 Bytes in length. The ping command on Linux or Windows will put 9000 Bytes inside the ICMP packet, resulting in a 9028 Byte IP packet.
GNS3 allows you to take live packet captures on any link (extremely handy) and it's also a very controlled environment. I have a couple mind-boggling examples from the real world though, but I'm saving those for later.
How do I read all of that?
A few fields in the IP header are of particular interest, so here's a quick refresher:
- Identification - this value identifies a group of fragments. It's what tells the reassembling device which fragments make up the original packet.
- Fragment offset - once all the fragments have been received, they need to be put back in the correct order. This field tells the reassembling device where in the original packet to place the data from each fragment (after stripping the L2&L3 headers).
- the value for the first fragment will be 0
- Flags - MF bit - More Fragments means that there are additional packets coming in after this one.
- it is set (1) in all but the last fragment (0)
The most important information is in the last entry (#7 for the request and #14 for the reply). It shows a combination of the contents (and size) of the last fragment to arrive (134 bytes), but it also shows the reassembled packet in all its glory (8980 bytes).
They key to that is noticing the tab that appears at the bottom which says Reassembled IPv4 (8980 bytes).
To make matters worse, the IP header shown inside the reassembled packet is the one from the last fragment (notice Fragment offset is 8880 and MF is 0). On the flip side, it does tell you that the packet has been reassembled from 7 fragments and it gives you the sizes and links to the fragments themselves. Convenient.
The ICMP header is there and the 8972 bytes of garbage that come with it for you to analyze. In the fragmentation process, everything coming after the IP header will be split up - in this case the ICMP header (8 bytes) and the data (8972 bytes).
This means that the ICMP header will only be present in the first fragment (offset=0). You can check by taking the next 8 bytes after the IP header in the reassembled frame (08 00 25 f1 00 03 00 00) and looking for them in the first fragment. It's nowhere to be seen in the following fragments, as expected.
There a lot more to discover by poking around yourself, so here's the packet capture - open it in Wireshark and have a go at it. If there's something you don't understand, ask away in the comments below.
Wasn't that fun?
Maybe. Maybe not. But I sure hope it was of some use to you - let me know in the comments below.
There are two more parts to read while we're on this topic, part 2 which shows examples from the real world and part 3 which will cover IPv6.
And, as always, thanks for reading.