Third post in this serie. Based on CCIE+Enterprise+Infrastructure+(v1.0+RevA)+Exam+Topics.pdf (cisco.com)

When we talk about Maximum Transmission Unit, MTU for short, we talk about two different types of values. The one defining the largest size in bytes for frames traveling through an interface and the second the biggest IP packet that an interface can handle before fragmentation.

The standard MTU value for L3 packets is 1500 bytes, whereas the standard size for MTU L2 frames is 1514 (1518 if we consider dot1q-tagging).

Nowdays normally we would see something like this in our networks travelling around:

• 1460 bytes of payload for TCP.
• 20 bytes for the TCP header.
• 20 bytes for the IP header.
• 14 bytes for the Ethernet header.

Additional headers

• 4 bytes dot1q tagging (optional)
• 24 bytes GRE Tunnel
• 73 bytes IPSec VPN Transform set esp-aes-(256 or 192 or 128) esp-sha-hmac or md5

Having a closer look to the frame and packet, we will see in the packet (Layer-3) that there is a ‚df-bit‘ (df = Dont Fragment!), which indicates to the receiver that the packet can be fragmented or not. That means, if a packet (1600 bytes) is travelling the network and reaches a layer-3 interface that has a MTU of 1400, the packet will fragmented in two packets as far as the ‚df-bit‘ is not set, but if the ‚df-bit‘ is set then the interface won’t be allowed to fragment it, the packet is dropped and an ICMP message is generated and sent back to the sender. This is how it looks like.

Switch#ping 1.1.1.1 size 1600 df-bit repeat 2
Type escape sequence to abort.
Sending 2, 1600-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with the DF bit set

*Jun 26 19:14:30.821: ICMP: dst (1.1.1.1): frag. needed and DF set.
*Jun 26 19:14:32.821: ICMP: dst (1.1.1.1): frag. needed and DF set.
Success rate is 0 percent (0/2)
Switch#

Fragmentation is not always desired. Whenever a router has to fragment a packet, it needs CPU and memory resources, also the packet that has been generated also has headers, which leads into more overhead in the transmission.

Pre- and post-fragmentation

post-fragmentation

Imagine you set a VPN Tunnel between two sites. You are not seeing packets that are being fragmented on your clients gateway, so… you may be fine. But we must remember that there are some other headers that are being added on the egress interface of your tunnel. So, if your packet was nearly the maximum transmit size, it may get fragmented on the egress interface due the addittion of headers, after decryption. Therefore the peer router will need to deal with a fragmented encrypted packet before decryption. This will lead into an excessive resource comsuption.

pre-fragmentation

If you set the reduce the packet size before encryption the remote peer will only need to decrypt the packet and forward it to its destination. The end host will lead with the reassambly of the packets. This alleviates the remote peer.

Setting up MTU Size in IOS XE

This is a value that can be adjusted, but there are some things to consider when configuring MTU sizes manually. In IOS XE we can configure MTU size on a interface basis and on protocol basis (ip, ipv6).

If we want to change the MTU size globally we have to execute under the config mode „system mtu 2400“. This will change maximum size for frames before being fragmented to 2400 bytes.

The system mtu can be globally adapted by issuing the following command

system mtu bytes

On a Layer-3 Interface the mtu size can be modified for ipv4 and ipv6

ip mtu bytes

ipv6 mtu bytes