MTU Troubleshooting on Cisco IOS

This topic is to discuss the following lesson:

Thanks a lot great tutorial , keep up the good work


Ethernet adds a minimum of 18 bytes, does it not? smac + dmac + type + FCS = 6 + 6 + 2 + 4 = 18. I only bring this up because of the conversation we had recently about some inconsistencies with fragmentation … and of course, the 8 bytes preamble added by the interface drivers. Wondering if Wireshark simply discards the FCS, but I am pretty sure the FCS is part of the actual Ethernet II frame and is associated with L2 encapsulation, not L1 like the preamble is.


Thanks, very useful information!!!

Hi Rene,

i have 2 questions :slight_smile: :

  1. When I try to set “mtu 1400” on the roter interface, I get the error: “% Interface FastEthernet0/0 does not support user settable mtu.” What can be done in order to solve this error?

  2. In the first solution presented above in order to solve the MTU issue, why is not enough only the command “ip mtu 1400”, since you have also added “ip tcp adjust-mss 1360”? Actually, wouldn’t be enough only one of them, why have you used both?

Thank you,

1 Like

Hi Marian,

It will depend on the router, some routers can’t set the “Eternet” MTU. IP MTU will always work.

I changed the “ip mtu” to 1400 which will cause IP packets to be fragmented if they exceed 1400 bytes. If there is something in the path that doesn’t allow fragmented packets then those packets will be dropped. It’s better to adjust the TCP MSS as well, if you set it at 1360 then the total MTU is 1400 bytes (40 bytes for headers) which ensures that we don’t need fragmentation.

Does that make sense?



Hi Rene,

I think I understood your explanations.

Thank you very much,


Towards the end of the lesson you state:
Here’s how to configure the correct IP MTU value:
And then you proceed to set the mtu to 1400.

My question is shouldnt you set it to 1500 then? If its not fragmenting at 1400 and the packet size is greater than 1400 (1500 in your example) shouldnt the ip mtu command have 1500 set?
I dont understand why we would lower it instead of increasing it.


Hi Michael,

Just before setting the IP MTU, I reduced the layer 2 MTU to 1400 bytes. This means that on layer 2 we can’t forward anything that is larger than 1400 bytes.

If I set the IP MTU to 1500 bytes then the router thinks it can forward an IP packet that is up to 1500 bytes on this interface, this is never going to fit since we only allow a MTU of 1400 on layer 2.

By setting the IP MTU to 1400 bytes, the router knows that the largest IP packet can be 1400 bytes…anything larger and it will fragment the IP packet. By doing this, we’ll never run into issues on layer 2.

Does that make sense?



Few questions

  1. In your article you state that if we include the ethernet header that will bring our total packet size to 1514 bytes. But if the MTU is 1500 bytes by default how does it take into account the additional 14 bytes of Ethernet

  2. I thought MTU was the maxium size of the PDU (protocol data unit) that can be sent on a medium. If a PDU includes headers and trailers then why do you state that a single ethernet frame can carry up to 1500 bytes of data (without headers).

  3. If a total length of a packet is 1514 bytes will the router still fragment the packet even though ethernet does add the additional 14 bytes?

Hi Michael,

  1. The MTU of 1500 bytes for Ethernet is its payload so this includes the IP packet with its IP header (20 bytes), TCP header (20 bytes) and a payload of 1460 bytes. It doesn’t include the Ethernet header of 14 bytes. The total “packet” size of 1514 bytes is the complete Ethernet frame, the IP packet itself is 1500 bytes.

  2. That’s correct. The maximum size of the PDU (IP Packet in this case) is 1500 bytes. So this includes the IP + TCP headers but doesn’t include the Ethernet frame header.

  3. If the IP packet is 1514 bytes then it will, since the total frame will be 1514 + 14 = 1528 bytes.

If I misunderstood your question, please let me know :slight_smile:


1 Like

Hi Rene,
Maybe I misunderstood this part of the paragraph
“This means that a single Ethernet frame can carry up to 1500 bytes of data (without headers). Typical header sizes are 14 bytes for Ethernet (add another 4 bytes if you use 802.1Q tagging) and 20 bytes for an IP header”

That is my source of confusion. You state than en ethernet frame can carry up to 1500 bytes of data (without headers). But MTU does include the IP header and TCP header (if tcp is in use).

Maybe I am overthinking this :slight_smile:

Hi Michael,

I just reworded it a bit, that sentence was confusing :slight_smile: The 1500 bytes that Ethernet can “carry” is 1500 bytes. These 1500 bytes are used for the IP packet with its IP header, TCP header and payload.

It’s good to give this some thought, MTU issues happen with DSL sometimes.


Hi Rene,

I have a similar issue . user unable to ping server with MTU 1500 . I can ping from ASA with MTU 1000 also customer able to ping with 1000. I check the MTU is set to 1500 . please if you can help . Below is the log from ASA
%ASA-4-400023: IDS:2150 ICMP fragment from 172.21.0.* to 10.124.. o o n interface wan3

Hi Syed,

Is 1000 bytes the maximum? If so, it’s probably not related to MTU but something else.


MAx is 1500

I’m talking about the pings that go through :slight_smile: You could ping with a MTU of 1000 but anything higher doesn’t work?

Thats is Correct :slight_smile:

Hmm any chance you have an IP audit policy on one of your ASA interfaces?

Hi. Great explanations. Couple quick clarifications.

  1. You mention ‘The MSS value isn’t synchronized between hosts, it can be different for each direction’ - I thought this gets negotiated as a part of the 3 way handshake? Are you saying in your example above if say set “ip tcp adjust-mss 1360” on the f0/1 of R2 and then set “ip tcp adjust-mss 1460” on the f0/1 of R1 then it wouldnt negotatiate down to the lowest common MSS and hence break?

  2. Assuming I am using GRE over IPSEC with transport mode I looked at a recent customer network in which the tunnel interface was set to “IP MTU 1400” and it also had the corresponding command “ip tcp adjust-mss 1360” under the tunnel interface as well. The tunnel interface MTU was kept at default which was 17912. Seems redundant based upon some of the explanations above to set the MTU when setting the “ip tcp adjust-mss” command? Assume it is really one or the other like you mentioned above, but the adjust-mss would avoid fragmentation where the IP MTU would cause fragmentation so better to use the adjust-mss? What is the best practice ideal setting for the tunnel interface in this case as it relates to this and the appropriate size (ie is adjust-mss the best approach, but maybe we should make the byte size higher than 1360)?

  3. How does “MPLS MTU” compare to “IP MTU” on the interface level? Does it behave in the same fashion?

Many thanks.