MTU mismatch in Layer 2 network?

[kerim mohammed]

  Hi,

I am just wondering on how mismatched MTU sizes are handled in Layer-2 networks and also inside a particular switches internal architecture.

Layer 2 devices do not do fragmentation in the even of MTU mismatch. is this because Layer 2 devices do not re-write header information (like inserting destination IP and next hop MAC into the newly created frame.) i believe this is what they call per-hop behaviour? if this not the reason, then...? assuming this is the reason, let me proceed to my next question.     When we set MTU on an interface , there is no mention of direction (ingress or egress), so i take this as means in both directions. so if a jumbo frame comes in on an interface which is set to recieve jumbo frames and forwarding decision is made and the frame is scheduled to egress via an interface whose MTU is not set for Jumbo frames, will the switch drope the frame at the egress buffer? if not, this implies MTU is an ingress property(only for incoming packets). But, again if it drops the packet, then MTU shoud have been system wide or global configuration as opposed to interface level configuration (just like nexus 5000). please, let me know. details and scenarios are always appreciated.

Thanks,

Kerim

[rais]

There aren't too many just Layer2 networks. Usually, higher layer protocols ride on layer-2 and take care of MTU mismatches at higher layers.

A layer-2 protocol example is ISIS Hello frames that are padded to the full MTU size. A neighoring interface that doesn't have similar [and has smaller] MTU would discard this packet and neighbor relationship wouldn't be formed.

MTU configured on an interface is a bi-directional attribute.

HTH.

[Joseph W. Doherty]

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

On ingress, port can't accept frame.  Should be logged as some kind of error.

On egress, port can't transmit a frame that's too large, but as this can be indicated to higher level protocol(s), the higher protocol level might fragment what it's trying to transmit into a size the interface can accept.

Regarding global vs. interface MTU, global settings probably simplify programming like interface hardware (e.g. all Ethernet interfaces), and help insure consistency across the device, but per interface MTU is generally the case for different physical media (e.g. Ethernet vs. Token Ring).

I.e., low end switches that support only one physical media are likely only to offer global MTU, high end hardware that supports different media types likely to offer per interface MTU.