@MHM Cisco World wrote:
Totally sure' if server and clinet is in same subnet and port in sw is 1500 then if server send 9000 the traffic will drop by SW' this common in SW that why you need to match mtu in your network.
MHM
Logically, I completely agree. (Also how I believe it ought to behave.)
Physically, that conflicts with what a Cisco SE told me, many years ago. (Might have been possible true then, but not now, too.) Don't recall why this question arose (then), possibly because I saw the behavior SE described (which I didn't expect). Don't recall if I ever verified it, and I don't have a way to test it today.
Have you actually physically verified this on different Cisco switches that support jumbo Ethernet? (Specifically host (jumbo) 9k => (interface 1500) switch (interface jumbo) => (jumbo) host; does host receive jumbo frame?)
Physically, it's certainly possible a switch's interface hardware (if physically capable of jumbo) could ignore a MTU setting for ingress.
As the SE described it, on a jumbo capable Cisco switch, a jumbo could be accepted on a 1500 MTU ingress, and be transmitted on another jumbo enabled port.
Of course, SE could have been wrong, or perhaps he had in mind something like baby giants, or my memory is faulty, or . . .
in Troubleshoot MTU on Catalyst 9000 Series Switches, dated 5/12/23 (so not too old), we find:
Does MTU check happen Ingress or Egress?
Egress: MTU is the Maximum Transmission Unit, it is an Egress check, the decision to fragment or transmit as is or drop is decided for egress
- If the Port MTU is higher than the packet length to be routed out, Packet is sent as is
- If the Packet is larger than the egress port MTU and if Egress port is
- a Layer 3 port, packets is fragmented as per the MTU
- a Layer 2 port, Packets are dropped. (Fragmentation is done only at Layer 3)
Note: If a packet has the DF (Don't Fragment) bit set in the IP header and Port MTU is less than the packet to be routed, Packet it is dropped
Ingress: MTU check is also done for packets which arrive at an interface
- If an interface receives a packet over its configured MTU, these packets are treated as oversized packets and dropped.
So, the forgoing does agree with what you describe (and my opinion how it ought to work).
Still, I wonder if that's always been the case (and accurate [IOS does change features - found a reference where on one Cisco switch, jumbo support went from global setting only, to also per port settings, with an IOS upgrade {9300 starting with 17.1.1}]). The "years ago" I refer to, was when jumbo Ethernet was still a rather new technology and was only found on (at the time) the very latest gen of Cisco switches.
Again, even within the Cisco switches, there's a lot of "variety" when working with jumbo Ethernet frames, not only between switch series, but for chassis switches, specific line cards and/or supervisors.
For example, within Configure Jumbo/Giant Frame Support on Catalyst Switches, it's noted:
Catalyst Support for Maximum Frame Sizes
The ability of the various Catalyst switches to support various frame sizes depends on many factors that can include hardware and software. Notice that certain modules can support larger frame sizes than others, even within the same platform. Additionally, maximum frame size support can also change based on the software version you use.
So, again, perhaps the behavior I recall the SE described to me, then, was true then.
I will conclude with, all interfaces, within the same L2 domain, should support the same MTU, however as long as you don't send a too large frame to an interface that cannot handle it, you can mix different interface MTUs within the same L2 domain (not something I recommend).
