IP Fragmentation and MTU

Earlier this week, someone asked me a simple question about the “Fragment Offset” in an IP Packet Header. I have to admit that my understanding this field was slightly incorrect. Before I come clean with my misinterpretation, I wanted to throw out a challenge. Review the image below, then answer the question that follows.

An administrator on RTR A enters the command “ping 192.168.2.3 size 1500 repeat 1”. The IP address 192.168.2.3 exists on RTR C. How many fragments will be received by RTR C?

  • One (Packet will not be fragmented)
  • Two
  • Three
  • Zero (ICMP Echo will be dropped prior to reaching C)

Prior to experimenting, I would have chosen “three”. The logic is that RTR A would internally produce an IP Packet that is 1500 bytes. As it leaves RTR A, it would be fragmented in two packets. One would have an overall length of 1498 bytes and the other one would be 2 bytes (plus the IP Header). As this 1498 byte packet left RTR B, it would be fragmented again. This would have RTR C receiving a 1492 byte packet, a packet that is 6 bytes (plus the 20 byte IP header, and a packet that is 2 bytes (plus the 20 byte IP header).

This answer would have been incorrect. The “fragment offset field”, used for reassembling fragmented packets by the receiver, is clearly identified in RFC 791. This field does not represent a single octet, but multiples of 8 octets. It also represents only the data portion of an IP Packet. The data portion is 20 bytes less than the overall packet lenght. In my example, 1498 – 20 (1478) is not divisible by eight.

If we create a packet that is 1500 bytes and send it out an interface with an MTU of 1492, it will be fragmented to the largest packet whose data field is divisible by eight and less the 1498. In this case, it happens to be 1492 (1492 – 20 or 1472 is divisible by eight). If we wanted to create a scenario that produces three fragments at RTR C, we would need to have MTU’s that are a little further apart (or produce IP Data fields that fall into ranges that are in a different multiple of eight). For example, decreasing the MTU on RTR B to 1491 would produce three fragments at RTR C. Of course this is assuming that the same 1500 byte packet is sourced from RTR A.

Other Articles about MTU

About Paul Stewart, CCIE 26009 (Security)

Paul is a Network and Security Engineer, Trainer and Blogger who enjoys understanding how things really work. With over 15 years of experience in the technology industry, Paul has helped many organizations build, maintain and secure their networks and systems.
This entry was posted in Design. Bookmark the permalink.

6 Responses to IP Fragmentation and MTU

  1. mj says:

    I need some help in the below mtu scenario. I am not getting icmp replies when I ping qemu 7 from qemu 6 with more than 1270 bytes of data. All the interfaces are configured properly. When I see wireshark output on R2’s s2/0 link , I can see that icmp request is going to the destination but I dint see any echo replies.Since packet will be fragmented based upon the outgoing link mtu , so when i send 1270 bytes of data , echo request goes unfragmented as the outgoing link has 1500 mtu but replies come fragmented as the outgoing link has 1200 mtu. Am I correct ? Also please help me understand why I am not getting echo replies when I send more than 1270 bytes of data. I am using linux-microcore qemu image.

  2. Paul Stewart says:

    You are correct in how it should work. Based on what you are saying QEMU7 isn’t responding. I am guessing the QEMU issue is separate. Therefore, you could probably experiment with a smaller mtu and icmp packet size.

  3. Will says:

    Studying MTU always makes my head hurt.

  4. kbm says:

    Hi, help in understanding the behaviour of a fragmented packet (say around 1450 B) encounters another LOW MTU router (say around 1000B) in the routing path (DF – is not set, PMTU is not an option).

  5. Pingback: Understanding Tunnel Path MTU Discovery - PacketU

  6. Matteo says:

    Thanks Paul, I was doing some labs about MTU and I couldn’t realise why the first fragment wasn’t equal to the lower MTU in the path. Now I have an answer!

Comments are closed.