In the context of Maximum Transmission Unit, or MTU for short, we are referring to two distinct categories. The first one specifies the maximum size, in bytes, that frames can have while passing through an interface, while the second one sets the maximum size of an IP packet that an interface can process before fragmentation occurs.
Compared to the standard size for MTU L2 frames, which is 1514 bytes (1518 if we take into consideration dot1q-tagging), the standard MTU value for L3 packets is approximately 1500 bytes.
At this point in time, it is not uncommon for us to see anything similar in our networks that is moving around:
- There are 1460 bytes of data for TCP.
- The TCP header takes up 20 bytes.
- 20 bytes for the IP header.
- The Ethernet header is made up of 14 bytes.
Additional headers
- 4 bits optional dot1q tagging
- 24 bytes GRE Tunnel
- 73 bytes IPSec VPN Transform set esp-aes-(256 or 192 or 128) esp-sha-hmac or md5
When we take a more in-depth look at the frame and the packet, we will notice that the third layer of the packet contains a “df-bit” (df = Don’t Fragment!). This bit communicates to the receiver whether or not the packet can be fragmented. When a packet of 1600 bytes travels through the network and reaches a layer-3 interface with a maximum transmission unit (MTU) of 1400, the packet will fragment into two packets if the ‚df-bit‘ is not set. However, if the ‚df-bit‘ is set, the interface will not be permitted to fragment the packet. As a result, the packet will be dropped, and an ICMP message will be generated and sent back to the sender. This is how it appears to all of us.
Switch#ping 10.1.1.1 size 1600 df-bit repeat 2
Type escape sequence to abort.
Sending 2, 1600-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
Packet sent with the DF bit set
*Jun 26 19:14:30.821: ICMP: dst (10.1.1.1): frag. needed and DF set.
*Jun 26 19:14:32.821: ICMP: dst (10.1.1.1): frag. needed and DF set.
Success rate is 0 percent (0/2)
It is not always desirable to have fragmentation. Every time a router needs to fragment a packet, it requires resources from its central processing unit (CPU) and memory. Additionally, the packet that has been created additionally contains headers, which results in additional overhead during the transmission.
Before and after fragmentation
After fragmentation
Imagine you have established a virtual private network (VPN) tunnel between two different websites. You do not observe any packets that are fragmented on the gateway of your client, thus it is possible that everything is alright with you. It is essential that we keep in mind that the egress interface of your tunnel is undergoing the addition of a few more headers during this process. If your packet was close to the maximum size that may be transmitted, then it is possible that it will become fragmented on the egress interface as a result of the addition of headers following the decryption process. As a result, the peer router will have to cope with a fragmented encrypted packet before it can decrypt the data. This will result in an excessive consumption of the available resources.
