02-28-2023 02:07 AM - edited 02-28-2023 02:37 AM
Hello community,
I still have confusion regarding where MTU is being checked, on ingress or engress or both side of interface? It looks also being dependent on if it's L2 MTU or L3 MTU. There is some Cisco's document: https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/XE3-5-0E/15-21E/configuration/guide/config/sw_int.html
It states: "A jumbo frame is a frame larger than the default Ethernet size. Enable jumbo frame support by configuring a larger-than-default MTU size on a port or interface.
Catalyst 4500 series switch Ethernet LAN ports configured with a nondefault MTU size accept frames containing packets with a size between 1500 and 9216 bytes (including Ethernet payload, header and trailer). (The maximum MTU size for a Catalyst 4948 series switch is 9198 bytes (not including header and trailer.)) With a nondefault MTU size configured, the packet size of ingress frames is checked. If the packet is larger than the configured MTU, it is dropped.
For traffic that needs to be routed, the MTU of the egress port is checked. If the MTU is smaller than the packet size, the packet is forwarded to the CPU. If the “do not fragment bit” is not set, it is fragmented. Otherwise, the packet is dropped.
The Catalyst 4500 series switch does not compare the packet size with the MTU at the egress port, but jumbo frames are dropped in ports that do not support them. The frames can be transmitted in ports that do support jumbo frames, even though the MTU is not configured to jumbo size." - especially I don't understand this highlighted part.
02-28-2023 08:20 AM
Unsure how familiar you're with MTU, but before we get into 4500 (?) operations, let's review the subject, in general, first.
MTU defines the maximum frame size standard for a particular medium. MTU does generally differ between media types.
As I understand, one consideration is, when a MTU standard was defined for a medium, how "easily" the hardware, at that time, could support, or the additional cost, to support larger and larger sizes. (BTW, some of us recall when, decades ago, a NIC, alone, cost a lot more than many of today's PC kind of systems [also when money units were worth more back then too]).
Per medium standard, NICs on the same medium should support the same MTU. Otherwise, if one NIC could send a frame larger than another could accept, the latter would drop the frame.
L3, though, recognized a packet could transverse multiple medium types, and so, IP, for example, allows for splitting a too large packet into multiple medium capable frames.
So, what should always be the case is: at L2, NICs on the same medium should be able to handle all the same frame sizes. At L3, too large packets, can be fragmented (unless the packets indicates not to be fragmented).
With "jumbo" Ethernet (NB: not a standard), some Ethernet NIC vendors support much, much larger frames, often into the 9K size region.
Consider jumbo Ethernet NIC sending jumbo Ethernet frame to a standard Ethernet NIC. The latter cannot physically accept the frame, so it will be dropped (along with "wasting" medium bandwidth). So, ideally, if we want to mix jumbo Ethernet NICs on the same medium with standard Ethernet NIC, we may want to configure the former not to transmit jumbo frames (because a particular receiving NIC might just drop them as being too large).
If the jumbo Ethernet NIC always enforces our logical setting, it should drop jumbo frames before transmitting them. But does it?
If the jumbo Ethernet NIC has a logical limit, like don't transmit jumbo frames, ideally, it will apply the too large rules for a jumbo sized packet. But does it?
For the converse situation, what should a jumbo NIC do, when configured with a logical non-jumbo Ethernet MTU, if it receives a jumbo Ethernet frame/packet? Physically, it can accept the jumbo frame/packet. But does it?
Years ago, a Cisco SE told me, what Cisco network devices generally do, for Ethernet, is they enforce a lower MTU, the NIC is capable of, for L2 and L3 sending. If they receive a frame/packet larger than their defined MTU, but which they can physically accept, they will accept the frame/packet and pass it along (letting the next egress port apply its own L2 and L3 MTU settings enforcement). (In a way, this makes sense. When sending, enforce configured limits, even if less then what NIC supports. When receiving, even if you received a frame/packet beyond your configured limits, since you got it, don't just discard it, try to forward it and let the egress port [same device] deal with it.)
Reading what you've posted, and briefly glancing through the Jumbo Frame Support section, if I'm reading it correctly, it contradicts what expected behavior should be (based on what the Cisco SE told me years ago, which makes sense). So, it's possible this documentation is incorrect (which can happen), or it's correct in that particular IOS version on 4500s (regardless of sup or line cards being used).
In either case, I would consider it poor practice to rely on how a particular platform behaves, when it's contrary to standards or expectations. I.e. all NICs on the same medium should be supporting the same MTU. If L3 egress port MTU is too small for packet to be transmitted, regardless of whether MTU is really physical or logical, L3 rules (fragment or drop) should be applied.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide