You enable jumbo frame support when you want to avoid fragmentation in your network. If your devices support it, I recommend enabling it.
You are correct, a dot1q frame will reach 1522 byte, this is considered a baby giant, and i believe that most switches support baby giant without the need of extra configuration, let me double check this out, what switch platform are we talking about ?
When configuring dot1q trunking on a switch interface, the maximum Ethernet frame size is now 1500 + 4 + 18 = 1522, the switch will automatically assume that there is an extra four bytes of data appended on, incrementing the frame size, therefore, for implementations that require exactly only one tag to be carried like 802.1q it is possible to force the switchport to accept an extra four bytes of data by configuring it as a trunk port, while if more than 4 bytes are increased example for this case of QinQ you need to increase the system mtu of the switch.
Please check this document:
I believe that in some scenarios you must enable baby giants over 1504 bytes, its not just the fragmentation issue, an example of this would be when having MPLS over Ethernet with Ethernet switches in between, if another 4 bytes are added (MPLS label), then a fully loaded IP packet (1500 byte) will never make it through the core switches, it will be dropped by the core switch and reported as giant.
What you're saying is interesting. I always thought that the "1500" in the 1500-byte ethernet frame designation really only included the data, not the header or trailer, both of which add up to 18 bytes. So, I was under the impression that any switch that supports the legacy ethernet frame size of 1500 is really allowing an MTU of 1518 by default, [EDIT] except for the case of dot1q ports, which would support 1522 by default [EDIT].
Are you aware when it would be the case that the supported MTU size for the full frame is only 1504?
Thanks in advance
You are correct, the 1500 bytes are the frame payload (IP Packet, plus extra added tags, may be dot1q tags or MPLS labels) excluding the 18 bytes (Ethernet header and CRC trailer), the 1518 supported by the switch is called the maximum ethernet frame size and not the MTU (i think that here is your confusion, the 1518 is not the MTU it is maximum Ethernet frame size supported on the switch including the Ethernet header and CRC trailer which are excluded when we talk about MTU), when the 4 byte dot1q tag is added then excluding the 18 bytes the frame is now 1504 bytes (this is the MTU not the maximum Ethernet frame size which is now 1522 bytes), a switch can accommodate to this size by default if the interface is configured as trunk.
I hope that i've cleared this out for you.
Yes, i faced this issue while doing a complete redesign for the provider i am working for, its a very important thing to take care of while implementing MPLS over Ethernet.