Ip fragmentation and ip mtu size

December 2018, Reading time: 5 minutes

In this example, I explain the ip fragmentation, based on the ip mtu size and the role of icmp unreachable messages. You can follow along, by downloading the pcap files cloud-R3 R2-R3 I have the following topology. Cloud 1 is where my PC is with ip address 192.168.137.1, a windows 10 machine, from wich I ping router R2 which has a loopback ip address of 2.2.2.2 (you can do right click, open in new tab to see a larger image)

topology
check mtu on windows 10
netsh int ipv4 show subinterface

I see my mtu is 1500 bytes. if I don’t want to have fragmentation, I need to send a packet of 1500 bytes = 20 ip header + 8 icmp header + icmp payload => icmp payload = 1472. so if I do ping 2.2.2.2 -n 1 -l 1472 I get the following which is what I was expecting. We see the frame has total length 1514 bytes. That is 6 bytes source + 6 bytes destination + 2 bytes type field. Wireshark does not capture the 4 bytes FCS because this is inserted by the network interface card and wireshark captures before the card.


icmp1
Now lets ping with an icmp payload 1473 bytes.
ping 2.2.2.2 -n 1 -l 1473
I filter on source address because if you filter on icmp you will not see the second packet, because it is an ip fragment.
Look at identification 2649

icmp_fragmentation_mtu_1500

packet captured after R3

icmp_1500_2

we can see that fragmentation happens
We have:
  • one packet is 1514 bytes, 14 bytes ethernet, 20 bytes ip header, 8 bytes icmp header and 1472 payload, MF=1, offset = 0
  • second packet is 35 bytes, 14 bytes ethernet, 20 bytes ip header, 1 byte payload, MF=0(last packet), offset=185*8=1480,
the offset is on the ip packet payload which is  1472 + 8 = 1480 bytes and must be a multiple of 8

IP mtu 1400

Now I set the ip mtu on R3 fa0/0 to 1400.
r3_mtu

( IP MTU is used to set MTU size of IP PACKET.)
So if I ping with an icmp payload of 1400 the packet will be fragmented when it reaches R3 because the total packet will be 1400+8+20+14 = 1442 bytes as shown below
ping 2.2.2.2 -n 1 -l 1400
capture between R3 and cloud (here the packet is not fragmented because the mtu is 1500), Look at identification 2650
icmp_mtu_1400

packet captured after R3, Look at identification 2650
icmp_mtu_1400_after_R3

Look at identification 2650. the packet is split into two packets, one 1396 bytes and the other 52 bytes. the overhead of ethernet is 14 bytes, as I explained above, so the total sizes are 1410 and 66 bytes. I will explain in the next section, why the ip packet size is 1396 and not 1400.


IP mtu 1300

Now i set the mtu on R3 fa0/0 to 1300 bytes
ping 2.2.2.2 -n 1 -l 1400
capture on the cloud,
Look at identification 2651
icmp_mtu_1300_1

capture after R3,
Look at identification 2651
icmp_mtu1300_2
Look at identification number 2651.

No I see two ip packets, one with size 1300 (20bytes ip header + 8 bytes icmp header + 1272 bytes payload) and one with size 148 bytes (20 bytes ip header + 128 bytes payload)

Explanation of offset and packet size

So in the first case (ip mtu 1400) the ip packet was split to 1396 bytes + 52 bytes while in the second case (ip mtu 1300) it was split into 1300 + 148 bytes Why is this happening?

offset

Note that Fragment Offset field is expressed in 8-byte units, not in bytes. This is the reason why the payload size inside each of the fragment, except the last fragment, must be multiple of 8 bytes.If I had 1400 bytes packet, the ip payload would be 1380, 13808 = 172.5, not a multiple of 8. 1396 bytes packet, ip payload = 1376, 13768 = 172. So in the case of 1400 mtu, you see that the offset is 172X8 = 1376, while in the case of mtu 1300 the offset is 160 X 8 = 1280

Don’t fragmet bit

if i send a packet with a df bit and packet size > mtu set I will get back an ICMP unreachable that says that I need to fragment the packet.

icmp_DF_set

Please not the the ICMP unreachable message says Code 4: Fragmentation Needed and MTU of next hop 300
this will inform the application to send smaller packets

icmp_df_bit_command

no ip unreachables

if I put in the router no ip unreachables, I will not get this message and my ping will just fail

ip_unreachable

ip_unreachable_df_bit
You see that is says no response seen. so disabling ip unreachable can lead to problems, especially when you have changed the mtu along the path. Another thing to note is that the ping request was fragmented but the reply was not fragmented. this is because i changed the mtu only on R3 side.

TCP adjust mss

in the case of TCP traffic, if we know the maximum mtu on a path, we can change the tcp segment size by using the command, ip adjust mss. So if I know that the maximum mtu is 1400, I will set the ip adjust mss to 1360, to allow for ip and tcp header. Infact this is the recommended setting on most vpn connection, because the ipsec overhead can add up to around 80bytes depending on protocols used.

comments powered by Disqus