Python for Network Engineers

Ip fragmentation and ip mtu size

by: George El., 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&nbsp;<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, a windows 10 machine, from wich I ping router
R2 which has a loopback ip address of (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 =&gt; icmp
payload = 1472. so if I do ping -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 -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
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.

( 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 -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 1300

Now i set the mtu on R3 fa0/0 to 1300 bytes
ping -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 &gt; mtu set I will
get back an ICMP unreachable that says that I need to fragment the


Please not the the ICMP unreachable message says <font
color="#3366ff">Code 4: Fragmentation Needed and MTU of next hop
<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>

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.

comments powered by Disqus