the value for the first fragment will be 0.This field tells the reassembling device where in the original packet to place the data from each fragment (after stripping the L2&元 headers). Fragment offset - once all the fragments have been received, they need to be put back in the correct order.It's what tells the reassembling device which fragments make up the original packet. Identification - this value identifies a group of fragments.How do I read all of that?Ī few fields in the IP header are of particular interest, so here's a quick refresher: I have a couple mind-boggling examples from the real world though, but I'm saving those for later. GNS3 allows you to take live packet captures on any link (extremely handy) and it's also a very controlled environment. The ping command on Linux or Windows will put 9000 Bytes inside the ICMP packet, resulting in a 9028 Byte IP packet. 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. As the link between those two routers runs a 1500 MTU, this bad boy has to be fragmented.
Errr, what? Worry not, it shall all be explained below! What's the capture about?įirst thing's first, the screenshot above shows a capture of a ping between two routers in GNS3 with a size of 9000. You can see a bunch of fragments, which it says are Reassembled in #7, but packet number 7 has a size of 134.
It always looked dodgy to me and I didn't make the effort to make some sense out of it. Up until recently, I have to shamefully admit, I had no idea how to read a Wireshark capture of fragmented packets. It also might cause engineers to lose their sanity while troubleshooting weird problems. 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).
0 kommentar(er)
