MTU size on 4507+E issues

[Kiley Arena]

Hello,

We have a 4507+E running cat4500e-universalk9.SPA.03.01.01.SG.150-1.X01.  The rommon is at level 15.0(1r)SG2.  Level 3 engineers tell me that there are multiple servers and a security device that are not transmitting data effeciently (dropped packets, retransmissions, etc) and the problem they say is with the MTU on the switch, that it's setting the DF bit.   They tell me that they have to set the devices listed to a lower MTU size than 1500 in order for them to pass data without dropping packets/retransmitting.

I'm told the solution is to upgrade the IOS and ROMMON.  The security device sits directly on the 4507 but the other servers are VMs hanging off of a NEXUS.  All affected devices are in the same subnet.  The traffic is being sent over a WAN link via FWs and other security devices. The engineers are at the other side of the WAN link where the data is being transmitted to.

I've been reading up on MTUs, etc and, other than sending pings with 1500 byte packets (ping x.x.x.x size 1500 df-bit), I haven't found out how or why this DF bit is being set.  When I ping the security device from any switch within the LAN using the ping ... size 1500 df-bit, it fails.

When I do the same thing to some of the other servers having issues, they do not fail.

When I set my ping....size xxxx to the same size the security device is set to, the pings succeed (which makes sense since I'm matching what is configured on that device).

I am doing my pinging from within the LAN.

My question is, how will an IOS upgrade resolve this issue and how can I verify that the IOS is or is not the issue in the first place?

Thank you very much!

Kiley

[Leo Laohoo · Accepted solution]

cat4500e-universalk9.SPA.03.01.01.SG.150-1.X01
(dropped packets, retransmissions, etc)

With this IOS version, I am suspecting you are probably using a Sup7E.  If this is the case, then what you are seeing is typical and no amount of IOS upgrade or ROMmon upgrade will help you.  Let me explain. 

The memory buffer of a Catalyst switch is very, very shallow.  It's built like this because Catalyst switches are designed as access switch.  They are NOT designed to work in a DC environment of continuous high-volume data traffic.  

Cisco's answer to this is the Nexus solution.  One of the regular guys here, Joseph, has also recommended that the 4500-X is a cheaper candidate to Nexus.  

Another method is to fine-tune your QoS. 

[Kiley Arena]

Leo,

Excellent - thanks very much.  Yes, we are using it as a core switch in a DC environment, which would explain some of the issues we are currently seeing.

Now I have a reason to upgrade!

[Leo Laohoo]

Thanks for the ratings and that's one very, very old IOS.  It's the first IOS to support the Sup7E, if I'm not mistaken.