Ip fragmentation and ip mtu size
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 <a href="R3-cloud.pcapng">cloud-R3</a> <a href="R2-R3.pcapng">R2-R3</a> 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 184.108.40.206 (you can do right click, open in new tab to see a larger image)
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 220.127.116.11 -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.
Now lets ping with an icmp payload 1473 bytes.
ping 18.104.22.168 -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
packet captured after R3
we can see that fragmentation happens
- 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,
IP mtu 1400Now I set the ip mtu on R3 fa0/0 to 1400.
( 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 22.214.171.124 -n 1 -l 1400
capture between R3 and cloud (here the packet is not fragmented because the mtu is 1500), Look at identification 2650
packet captured after R3, Look at identification 2650
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 1300Now i set the mtu on R3 fa0/0 to 1300 bytes
ping 126.96.36.199 -n 1 -l 1400
capture on the cloud, Look at identification 2651
capture after R3, Look at identification 2651
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?
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.</b>If I had 1400 bytes packet, the ip payload would be 1380, 1380/8 = 172.5, not a multiple of 8. 1396 bytes packet, ip payload = 1376, 1376/8 = 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.
Please not the the ICMP unreachable message says <font color="#3366ff">Code 4: Fragmentation Needed and MTU of next hop 300<br> <font color="#000000">this will inform the application to send smaller packets <img src="/img/posts/Administrator_%20Command%20Prompt%2012_30_2018%209_07_21%20PM.png" alt="icmp_df_bit_command" class="img-fluid shadow1"><br> </font></font><br>
no ip unreachables
if I put in the router no ip unreachables, I will not get this message and my ping will just fail
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.