IOS 15.0(2)SE and Jumbo Frames and undocumented feature

cdickerson · ‎08-09-2012

Wanted to point out some new "features" with this release. First, this version fixes the problem on the 3750X and 3560X with false dropped packets being reported on the interface (CSCtq86186). Second, this version adds REP (Resillient Ethernet Protocol) even though it's not documented anywhere. With all good things, there has to be a bad thing and I think I found it. Jumbo frames configuration appears jacked up. The new maximum Jumbo frame size appears to be 9000 down from 9198. But here is the kicker, if you have Jumbo frames configured for 9198 and load the code, on the next reboot you are reset to 1500! On the 3560X platform, it appears to let you enter 9198 and accepts the command, but on the reboot Jumbo MTU is 1500, you have to enter 9000 for it to keep the MTU on reboot. The system MTU routing is now capped at 1500 as well. I have tested this on multiple switches and all exhibit the same behavior, so don't know if this change was intentional or a bug/oversight.

-Craig

rcustersp · ‎08-30-2012

Hey Craig,

Have you found any further information on this or opened a TAC case? If the MTU is really 9000 instead of 9198, that would cause some serious issues. I assume that it is just displaying as 9000.. I am in the process of upgrading all of my switches to this release, but have not yet done any of our switches that run jumbo frames.

cdemont · ‎01-09-2013

Hello,

I'm very interessting in this topic and I would like to know if you have a status on those bugs and if there is a "good" version for 3750X in IOS 15.x

Any feedback appreciated,

Regards,

Christophe

cdickerson · ‎01-09-2013

No I never did take the time to open a TAC case to confirm. I actually am getting ready here in the next few weeks to work on a large REP project using these model switches so I might open a case just to confirm then.

-Craig

cdemont · ‎01-09-2013

Hi Craig,

FYI today I called a customer who encountered this issue of mtu of 9000. He says there are big bugs in this code 15.0.2 like erroneous sh interface status compared to a sh interface , or erroneous snmp state of power supplies after a power down of 1 of them (still down in snmp get) plus with this restriction of mtu 9000 , that makes a lot. There are 2 bigs problems related to this mtu size , first the mtu routing beeing different you can experience OSPF problem (not sure the "mtu ignore" is a good idea as you might receive ospf database packets larger than 9000 if your neighbor has 9198)
Plus what if you implement ip mtu of 9000 like in iscsi env. , will packet a bit larger than 9000 being dropped ??? No idea ...
That's really a pain that a such platform like the 3750X widely deployed is undergoing such bad IOS development, please if a dev team read this , I'm curious to get some inputs.
Regards
Christophe

Sent from Cisco Technical Support iPhone App

Leo Laohoo · ‎01-09-2013

All of my fleet of 3750E/X have their IOS rolled back from 15.0(1)SE and/or 15.0(2)SE to 12.2(55)SE6.

cdemont · ‎01-10-2013

Many thanks for this feedback !

Sent from Cisco Technical Support iPhone App

jbeauchamp1 · ‎01-10-2013

Running into this exact issue myself which has been causing me some exchange nightmares due to "latency issues", but I think its all because of jumbo frames not working properly any longer. I'm going to rollback my 3750's to 12.2(55) SE6 and give it a test.