MTU explanation

Unanswered Question
Jan 20th, 2012

Hi,

I need some clarifcation regarding the MTU concept.

I know that IP MTU is 1500 bytes and that includes IP header+TCP header+payload

What about ethernet MTU?

  • Is it equal to IP MTU that is to say 1500 bytes?
  • Or it is 1514 bytes --> IP MTU +14 bytes Ehternet header(6-SA+6-DA+2-Ethertype) whithout preamble and CRC?
  • When configuring system MTU are we talking about Ethernet MTU without header?
  • What about ethernet MTU on a trunk?


I am a bit confused when trying to understand QinQ for example. Why should the system MTU be 1504? I know that we are adding a tag of 4 bytes but the tag is in the header right. If you are taking in consideration that ethernet MTU is the  IP MTU that is to say 1500 so the 4 bytes of the tag are not taking into account as ethernet MTU would without header.

Would be nice to get some clarification there.

Thanks.

/Laurent

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 3 (2 ratings)
JosephDoherty Fri, 01/20/2012 - 12:01

Disclaimer

The    Author of this posting offers the information contained within this    posting without consideration and with the reader's understanding that    there's no implied or expressed suitability or fitness for any  purpose.   Information provided is for informational purposes only and  should not   be construed as rendering professional advice of any kind.  Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In    no event shall Author be liable for any damages whatsoever  (including,   without limitation, damages for loss of use, data or  profit) arising  out  of the use or inability to use the posting's  information even if  Author  has been advised of the possibility of such  damage.

Posting

IP MTU isn't 1500 except on standard Ethernet as such Ethernet's maximum frame payload is 1500.  (IP's "MTU" is about 64 KB.)

The system MTU, I believe you're describing, supports enabling Jumbo Ethernet; it increases the maximum frame payload size.

MTU on a trunk shouldn't change as the media allows VLANs tags to extend the frame size.

lap@axcess.dk Fri, 01/20/2012 - 12:34

Hi Doherty,

Thanks for trying to explain but it didn´t clarify really my understanding of MTU. Anyone else could help me to clarify my questions in my original post?

Regards,

/Laurent

rynewell Fri, 01/20/2012 - 12:49

Good question. Ethernet MTU is 1500. The switch is not counting ethernet header or CRC trailer which is 18 btyes. It is only referring to Ethernet payload as Joseph stated. When system MTU 1500 is configured switches support a maximum Ethernet Frame size of 1522. 1500 ethernet payload + 18 bytes of header and trailer + 4 bytes for dot1q. When q-in-q is configured the system mtu must be changed to 1504. This brings the max ethernet frame size to 1526.

Regards,
Ryan

lap@axcess.dk Fri, 01/20/2012 - 13:15

Hi Ryan,

Thanks a lot for reply. that means that:

  • Ethernet MTU is 1500 without header and trailer and system MTU command is referencing to that
  • Swith by default (system MTU 1500 and access port) can maximun switch frames with 1518 bytes and 1522 bytes on Dot.1Q
  • System MTU is increasing the payload size but the QinQ tag is in the header right?
  • Since we need 4 bytes extra for QinQ we need to change system MTU to 1504

Correct me if I am wrong

/Laurent

rynewell Fri, 01/20/2012 - 13:43

Correct. We need the 4 extra bytes for QinQ.

Is QinQ a part of the header? The command increases the Ethernet mtu payload. Which leads me to believe (CAUTION: I have entered the realm of speculation) the first q tag, the customer tag, would actually be considered Ethernet payload. The second q tag is added by ISP switch and is a part of the Ethernet header. Again this is me speculating and I could be totally wrong.

Regards,

Ryan

lap@axcess.dk Fri, 01/20/2012 - 14:44

Interesting. Could be nice to test. I hought like the switch will just insert the metro tag in the header and then strip it off when sending the frame out to the CE. A bit like in MPLS with labels.

Regards,

Laurent

JosephDoherty Fri, 01/20/2012 - 18:37

Disclaimer

The     Author of this posting offers the information contained within this     posting without consideration and with the reader's understanding  that    there's no implied or expressed suitability or fitness for any   purpose.   Information provided is for informational purposes only and   should not   be construed as rendering professional advice of any kind.   Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In     no event shall Author be liable for any damages whatsoever   (including,   without limitation, damages for loss of use, data or   profit) arising  out  of the use or inability to use the posting's   information even if  Author  has been advised of the possibility of  such  damage.

Posting

Sorry, it might have helped if you had replied what or why what I had explained didn't help to clarify MTU.

However, from reading your follow-up exchange between you and Ryan, it appears the part of understanding MTU that was really confusing you is Q-in-Q; the part of your original post I didn't touch upon.  The reason I didn't address that was because you didn't seem clear on MTU for basic frames or single tagged frames.

The key point of understanding MTU it's the maximum transmission unit for L3.  This would be, for Ethernet, the frame's payload, and again for "standard" Ethernet, 1500 bytes.

802.1q tags extend the Ethernet L2 frame to support them, leaving the system configured MTU as it was.

Q-in-Q though, instead of once again implicitly extending the frame size to support these tags, considers the prior tag as part of frame's payload.  If using IP, and starting with an original payload of 1500, IP could fragment the packet to deal with the additional overhead, as it often does, for example, with GRE tunnels.  However, if we can explicitly increase the MTU, this fragmentation can be avoided.  As described by Ryan, to allow for just the additional overhead of a single Q-in-Q, increasing the MTU, if supported by the hardware, to 1504, avoids L3 fragmentation.  (NB: same thing can be done for GRE if you can increase MTU by 24 bytes.)

Now if you're wondering why 802.1q tags is an implicit frame size extension while Q-in-Q, optimally, requires explicit frame extension; the latter, where you can adjust MTU is more flexible.  As I've already noted, it can be used for GRE, but there are other encapsulation protocols that can benefit too.  Also keep in mind, L2 frame sizes have hardware implications.  Many, but not all, Jumbo Ethernet devices support frames up to about 9K, but other hardware media/interfaces support different MTUs.  Even currently, don't recall any mainline hardware media/interface that would support a full IP packet of 64 KB.

Where all of this is confusing, a 1500 byte packet would optimally use a 1500 MTU setting for standard Etherent or 802.q tagged Ethernet, but use a 1504 MTU setting for Q-in-Q Ethenet and a 1524 MTU setting for GRE.  The latter two MTU settings are larger because instead of implictly extending frame size for the overhead, it's now included as part of the payload and so we need to extend MTU to allow for this additional encapsulation overhead.

You might find some of the following helpful reading:

http://www.cisco.com/en/US/products/hw/switches/ps663/products_tech_note09186a00801350c8.shtml

http://www.cisco.com/en/US/docs/switches/datacenter/sw/5_x/nx-os/interfaces/configuration/guide/if_qinq_tunnel.html

Actions

Login or Register to take actions

This Discussion

Posted January 20, 2012 at 9:01 AM
Stats:
Replies:7 Avg. Rating:3
Views:3119 Votes:0
Shares:0
Tags: No tags.

Discussions Leaderboard

Rank Username Points
1 15,007
2 8,150
3 7,730
4 7,083
5 6,742
Rank Username Points
165
82
70
69
55