Troubleshooting MTU Issues

Overview

This article provides troubleshooting guidance for identifying and resolving Maximum Transmission Unit (MTU) related issues in Cisco Meraki environments.

MTU defines the maximum packet size that can be transmitted across a network path without fragmentation. The MX uses an MTU size of 1500 bytes on the WAN interface. When a packet is sent from a local host to a host in a remote network, the packet may traverse multiple router hops.

If an intermediate router is configured with an MTU size that is too small and the IP header in the datagram has the "Do-not-fragment" bit set, the router informs the sender of an unacceptable maximum packet size with an ICMP "Destination Unreachable-Fragmentation Needed and DF Set" message. The sender will then transmit a smaller packet taking into account the smaller MTU size.

Some routers are configured to drop certain ICMP traffic. If the ICMP error message never makes it back to the sender, it can cause intermittent connectivity issues between the source and destination hosts.

Environment

Device: Cisco Meraki MX

Default WAN MTU: 1500 bytes

Default LAN MTU: 1500 bytes

Cisco secure connect default MTU: 1406 bytes

PPPoE maximum MTU: 1492 bytes

Firmware required for Non-Meraki VPN MTU adjustment: MX 19.1.12 or 19.2.4 and above

Jumbo frames: Not supported. MTU cannot be adjusted above 1500 bytes

Common issues and solutions

The following are common MTU-related symptoms:

Intermittent connectivity between hosts: ICMP "Destination Unreachable – Fragmentation Needed and DF Set" messages are being dropped by an intermediate router

Packets dropped over Auto VPN: MTU overhead is not accounted for when determining MTU size

Connectivity issues after firmware upgrade to MX18+: Increase in overhead from SL0 to SL2

Connectivity issues on PPPoE uplink: PPPoE header reducing available MTU to 1492 bytes

Troubleshooting MTU issues

Intermittent connectivity issues between source and destination hosts can occur when there is an MTU mismatch along the network path. This can happen when ICMP error messages are blocked by an intermediate router, when VPN overhead is not accounted for, or when the MTU is not correctly configured on the router or clients.

Possible causes

An intermediate router is configured to drop ICMP "Destination Unreachable – Fragmentation Needed and DF Set" messages, preventing the sender from detecting the MTU mismatch
VPN overhead not accounted for when determining MTU size
Clients are not configured with the correct MTU size
Router MTU is set to 1500 bytes but an intermediate device requires a smaller size

Troubleshooting steps

Here are some steps you can take when dealing with an MTU issue.

Ensure routers and firewalls along the traffic path do not block ICMP "Destination Unreachable – Fragmentation Needed and DF Set" messages.
Verify the MTU configured on the router. If the MTU is set to 1500 bytes, test with a smaller MTU value to determine whether the issue is resolved.
Verify the MTU configured on affected client devices. Configure a smaller MTU value if necessary.
If multiple clients are affected, use DHCP Option 26 to distribute a smaller MTU value automatically.
If traffic traverses Auto VPN, account for up to 69 bytes of encapsulation overhead when determining the MTU value. The exact overhead varies depending on packet size.
If traffic traverses a non-Meraki IPsec VPN, account for up to 100 bytes of encapsulation overhead when determining the MTU value.
Contact Cisco Meraki Support to modify the MTU size on the MX WAN link, if required. The MX does not support jumbo frames and the WAN MTU cannot be increased beyond 1500 bytes. The LAN-side MTU is also 1500 bytes.
Contact Cisco Meraki Support to adjust the MTU for Non-Meraki VPN and Client VPN tunnels. This requires MX 19.1.12 or later firmware.
For PPPoE uplinks, note that the maximum MTU is 1492 bytes and cannot be increased.

Note: If a peer has a reduced MTU, the Auto VPN MTU will automatically propagate across the Auto VPN environment and adjust to match the lowest detected value among all peers.
Some examples of possible reasons for a reduced MTU include:
•   Primary cellular uplink
•   PPPoE connection
•   ISP-assigned DHCP MTU

Using ping to identify acceptable MTU size

Ping can be used to find an acceptable MTU size. Make sure to take into account the 28 bytes for the IP and ICMP headers by subtracting from the packet size.

Windows

ping www.meraki.com -l 1472 -f

This command will ping host www.meraki.com with 1472 bytes of data and set the "Do-not-fragment" bit. This assumes that you are testing a 1500 byte IP datagram minus the 28 bytes of overhead (IP header). If the results of the ping come back "Packet needs to be fragmented but DF set" try lowering the size of the packet until you receive a successful reply from the destination.

Mac OS X

ping www.meraki.com -s 1472 -D

This command will ping host www.meraki.com with 1472 bytes of data and set the "Do-not-fragment" bit. This assumes that you are testing a 1500 byte IP datagram minus the 28 bytes of overhead (IP header). If the results of the ping come back "Packet needs to be fragmented but DF set" try lowering the size of the packet until you receive a successful reply from the destination.

Linux

ping www.meraki.com -s 1472 -M do

This command will ping host www.meraki.com with 1472 bytes of data and set the "Do-not-fragment" bit. This assumes that you are testing a 1500 byte IP datagram minus the 28 bytes of overhead (IP header). If the results of the ping come back "Packet needs to be fragmented but DF set" try lowering the size of the packet until you receive a successful reply from the destination.

Additional Auto VPN overhead considerations

Enabling Virtual Routing and Forwarding (VRF) adds 8 bytes of overhead to Auto VPN traffic. Enabling Security Group Tag (SGT) also adds 8 bytes of overhead when both Auto VPN peers have Peer SGT Capable enabled. When both VRF and SGT are enabled with Peer SGT Capable configured on both peers, the total additional overhead is 12 bytes beyond the standard Auto VPN overhead.

Additional resources

For more information on MTU issues, visit the links below:

Path MTU Discovery

RFC 1191 - Path MTU Discovery