When we talk about MTU, we have to make sure that we’re always using the right context. Sometimes it includes the Ethernet header, sometimes it does not. For example, when you configure the IP MTU or the interface MTU on a Cisco IOS device, it never includes the Ethernet header. This diagram shows this clearly:
Whenever we configure these values, we only take into account the payload. So a “normal” Ethernet frame will have an MTU of 1500, but the extra 14 bytes of the header are assumed.
Now if you have a trunk port, the MTU size still remains 1500, because the extra 4 bytes of the VLAN tag are considered part of the Ethernet header. So you would still have an MTU of 1500, but the interface knows to allow for a header size of 18, so the total frame size will be 1518.
However, if you are using a feature such as QinQ, which adds a second VLAN tag, you must change the MTU of the QinQ switches to at least 1504 to accommodate that additional VLAN tag. Why? Because they don’t detect the internal tag of 4bytes, so they expect a size of 1500+18=1518, but they receive a frame of 1500+18+4 = 1522 so they drop it.
To add confusion to the whole mix, Cisco IOS XR software includes the L2 header in the
interface mtu command. So in such a case, you would use the value of 1514 for a “normal” frame on a Cisco IOS XR device, while you would use a value of 1500 on a Cisco IOS device. More info about this is found in the MTU size in Cisco IOS XER and IOS software NetworkLessons note.
In all cases, however, the FCS is never included in the calculation of the MTU. The only time this would be taken into account is if an Ethernet frame is encapsulated within another type of frame (MPLS for example) where the FCS is included in that encapsulation.
I hope this has been helpful!