cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
641
Views
19
Helpful
5
Replies

3750X 15.0(2)SE3

Kevin Dorrell
Level 10
Level 10

I know that 15.0(2)SE3 was deprecated because of a serious bug relating to TACACS ... if you have TACACS configured, the switch effectively locks up during boot.  Unfortunately, I upgraded one of my stacks just before the storm broke about 15.0(2)SE3, and now I am stuck with it.  Fortunately, I do not use TACACS.

Does anyone know more technical detail about this bug?  Could it be that the bug is further-reaching than just TACACS?  Is there something wrong with the CPU sheduler?  I know that normally there is some form of QoS on the CPU to make sure that no process can lock out the other processes.  Does it still work in 15.0(2)SE3?

I recently had some strange behaviour from a stack running 15.0(2)SE3.  I did some configuation elsewhere on the network, totally unrelated to the 3750X stack.  The only difference the 3750X would have seen was some extra layer-2 flooded traffic, (not very much, about 7 Mbps), on a VLAN for which it did not even have an SVI.  For some reason, the CPU of the stack went up to close to 100%, and it started to lose its OSPF, HSRP, and BGP adjacencies, which continued flapping until I removed the flooded traffic.

Has anyone else experienced this?  Can anyone tell me how the TACACS bug came about?

Kevin Dorrell

CCIE #20765

Luxembourg

5 Replies 5

Kevin Dorrell
Level 10
Level 10

Anyone?

Hi Kevin,

The only thing that made me stop testing 15.0(2)SE3 is the TACACS bug.  I didn't bother testing any further since "what's the point".  Can't comment on QoS as we've totally disabled QoS/CoS in our network.  QoS/CoS on our LAN gives us grief and we have 802.1x and voice running without it for a long while now.

If you have any 3560- or 3750-series switches, I'd recommend IOS version 12.2(55)SE8.  I've found some bit of occassional CPU spike even when testing the newer 15.0(2)SE4.   If you need features only found in 15.0, then consider 15.0(2)SE4.  Currently, I'm testing the 15.2(1)E.

Can anyone tell me how the TACACS bug came about?

This was taken from a Cisco staff, michelpe and stated:

We weren't aware of this bug before releasing 15.0(2)SE3 or we would have fixed it before releasing it. 
The bug was caused by another bug that was commited at a late moment in the release cycle after we done
the full testing on AAA.

The entire thread is here.

To answer your question, someone inserted a buggy code (without any testing), didn't tell anyone else.  The firmware was released and, as they always say in showbusiness, the rest is history.

What other potential monster is lurking inside it, I don't know.  I have copies of this faulty IOS version in my HDD.  Very useful if you want to drive some poor network bloke nuts.  

Leo, Thank you for letting me know your view of this problem.  I have opened a TAC case, but I am almost sure they will say "15.0(2)SE3 is not supported".  That will not help me much because it is already running in my non-stop data centre, with little chance of a maintenance slot this decade.

I had to upgrade from 12.2 because of a bug in the SNMP.  CSCtq86186. The SNMP occasionally and randomly returns incorrect discard counters ... in fact double their real value ... and then back to the proper value.  That is not so useful if you are taking a delta at regular intervals to try and detect congestion.  I don't know whether 12.2(55)SE8 fixes that ... I was running 12.2(58)SE2 at the time.  And I was at 12.2(58)SE2 because of a bug in 12.2(53) to do with LACP.

Anyway, thanks again for your reply.

Best regards

Kevin

I was running 12.2(58)SE2 at the time.

Do be careful when you are using 12.2(58)SE.  Got a lot of CPU hog issues that Cisco is unable to fix.  If you look at the date of release, this version is about >2 years old.  So this is a sure sign any improvements to this version may have been shelved in favour of the 12.2(55)SE train (my recommendation for 3560- and 3750-series) and 15.0(2)SE4 (recommended for 2960/G/2960S).

I'm currently testing 15.2(1)E on a 3560CG.  Will be loading this on a 2960S soon.

Not sure how you do your SNMP traps but I've seen a lot of examples where people just enable ALL the SNMP traps.  Whatever your IOS version is, this is a recipe for disaster as I've seen CPU spikes when you don't select what SNMP traps you require.  It's like saying you have a Trunk link and you enable all VLANs but you only have a handful of VLANs.

And thanks for the ratings. 

Thanks Leo, I shall bear that in mind.  That is useful information.  I shall look into reverting to the 12.2(55)SE train on both sites, but only if my two "show-stopper" bugs are not present, that is:

  • the occasional doubling of the discard counters in SNMP
  • the inability of LACP to revert to "individual" if the host does not play LACP

Best regards

Kevin

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: