Experincing issues with 2960X switch

[brianaddicks1]

Having the same issue, have you gotten any resolution yet?

[Adrian.Fullerton]

Frustratingly not, only accumulating data to help isolate the underlying issue. I haven't been able to find the error message that I saw anywhere on the Internet - it's gonna take someone from Cisco to spot it and figure out the trigger. I'm buying some new modules to rule them out, after that it has to be switch, the software or an interaction between the two. Batch of dodgy components, flaky memory, who knows. If I do find out, I'll post it.

[RAMEEZ RAHIM]

The bug i got from TAC & BU is CSCul78520 and has two parts.

First issue is regarding the entropy error seen periodically. The issue is specific to 2960s.

Second issue, the important one,  is regarding the uplink ports with GLC-T SFP going down at times,  if we have configured port channel.

This issue is also valid for 2960X.  In case of 2960s, the second issue causes issue 1.

The issue is seen due to the following reason:- when interface has port channel config, the link status of port is read very frequently. The link status is then frequently read from internal phy in GLC-T over i2c bus, which sometime cause i2c bus to get hung and the port link goes down.

Available workaround is to either use FIBRE links or do not use Etherchannel on these ports. 

Pending FIX

[Jason Williamson]

WTH is wrong with Cisco here???This should be such a straightforward issue - but no documentation & just code u pgrades that may or may not work?

630900401 os my ticketnumber currently open... i've seen this with ex2 ona previously purchased stack , cisco's solution was EX4. Now I boyght $400k worth of 2960x's because i thought I would be fine to proceed - but now they  have ex5 and are fubar just like my old ones? Frankly I'm pissed that anyone "sold' me on these switches - should have just bought the old trusty 2960S and forgotten about trying to go to a switch that can get up to 10G uplinks. :-(

[Jason Williamson]

Replying to my own post here. 15.0.5(EX5) is SOLID - but if you do a show inventory, it won't show you all your SFPs that you have installed. they DO work though, and pass failover testing, etc, in my production environments. 

[Nickolus Looper]

We have had multiple issues even with 15.0.2(EX5) - particularly with the GLC-T transceivers.  TAC and our account mgr escalated it to the 2960 product line mgmt. team, and they confirm bugs remain in 15.0.2(EX5) (in spite of the fact that all bugs for this issue show EX5 as a 'fixed-in' version).

Our account rep says that this should be fixed in a release coming out in November.  Our TAC case for this issue still has a status of 'release-pending' as of 17 November 2014.

[Mitchel Erb]

Did TAC ever release this fix Nick?  Was it the 15.2.2E1(ED) released on 11/19/14?  Any issues since uploading this in your environment?

Thanks!

[Nickolus Looper]

Since the fix came out in an entirely new train and not like maintenance build to the earlier train (like an EX6), we've haven't put it into production yet.  We're gonna conservatively deploy the new train.

We've had no issues with EX5 and fiber SFPs, only the GLC-T SFP, which we only have in a few deployments of the 2960Xs.

I will keep following this post - eager to hear about the experiences of others!

----------------------

5/14/2015 Edit: We have had issues with fiber SFPs on EX5 as well :-(

Good news is that 15.0(2a)EX5 (+ a hard reboot - see elsewhere in this thread) fixes this.

[greg.murray]

Hi

I had the exact same issue with the EX3 / EX4 and EX5 release train.

I changed the code approx 3 weeks ago on my c2960-X switches to 15.2(2a)E1 and I have just seen the same problem again.

Switch#sh controllers ethernet-controller gi1/0/49 phy de

GigabitEthernet1/0/49 (gpn: 49, port-number: 49)
-----------------------------------------------------------
hulc_sfp_iic_intf_read_eeprom sfp _index 0 yeti_iic_read_retry fail
hulc_sfp_iic_intf_read_eeprom sfp _index 0 yeti_iic_read_retry fail
hulc_sfp_iic_intf_read_eeprom sfp _index 0 yeti_iic_read_retry fail

Honestly don't think this is a code specific issue any more and I think there is a hardware issue at the root of this.

[Mike Pavlovich]

Hi Greg,

Details of the software fix for this issue can be found here:

http://www.cisco.com/c/en/us/support/docs/switches/catalyst-2960-x-series-switches/118837-technote-catalyst-00.html

Note the mention that a one time hard boot (unplug and replug the power cable) may be required after upgrading to the 15.0(2a)EX5 or 15.2(2)E2 code with the fix if the switch was in the failed state prior to the code upgrade. See my note to Nickolus above regarding the reason for the hard boot.

[burkes]

Running 15.0(2)EX5, fiber sfp's work, copper ones don't.  Well, they do for a while and then you have to hard boot your switch to get them to come back, crap shoot for how long they stay up.  Very frustrating, I've been a loyal Cisco customer for 15 years plus and have always bought their "good stuff" , 3560's 3750's etc.  never had issues like this before now.  So do we have to buy the real pricey stuff now like layer 3 switches everywhere to avoid this nonsense I wonder?  They used to take all this code revision stuff seriously.  Some of their comments on the work arounds are laughable like "don't use copper sfp's, use the downlinks" What??!! really??!!  I'm almost waiting for them to write "if you need a reliable switch, keep looking this isn't it".

[Mike Pavlovich]

Hi Burkes,

Sorry about the trouble you have gone through due to this software issue. The workarounds were options while waiting for the code fix. Now that the fix is available in 15.0(2a)EX5 & 15.2(2)E2 an upgrade is the way to go. A one time hard boot may be required once the new code is loaded. See my note to Nickolus above regarding the reason for this

[sorry about the multiple links below, the editor won't let me delete them]

http://www.cisco.com/c/en/us/support/docs/switches/catalyst-2960-x-series-switches/118837-technote-catalyst-00.html#sthash.Gp8hNKf1.dpuf

http://www.cisco.com/c/en/us/support/docs/switches/catalyst-2960-x-series-switches/118837-technote-catalyst-00.html#sthash.Gp8hNKf1.dpuf

http://www.cisco.com/c/en/us/support/docs/switches/catalyst-2960-x-series-switches/118837-technote-catalyst-00.html#sthash.Gp8hNKf1.dpuf

[Doug Thompson]

Hi Mike,

We have recently installed several of the 2960x switches and switch stacks in our environment.  Today we lost the connection to the connection on our 4507 aggregation switch to our core.  Once we established the connection again, all of our 3750g switches reconnected just fine.  However, everyon of the 2960x switch had to be hard booted in order for them to reconnect.  I had to go to 7 different buldings to pull the power and reboot for the to re-connect.

I am running the 15.0(2a)EX5 code on all of them

Have you heard of that issue?  Is there a fix yet?

Thanks!

[Mike Pavlovich]

Hi Doug,

If the 2960X switches were already running fine on 15.0(2a)EX5 prior to the 4507 connectivity issue, then this code should have prevented them from experiencing the uplink issue and ILET issue mentioned here:

http://www.cisco.com/c/en/us/support/docs/switches/catalyst-2960-x-series-switches/118837-technote-catalyst-00.html

The hard boot is only required if the 2960X was in a bad state prior to loading 15.0(2a)EX5 which does not appear to be the case here.

The only other issue I am aware of that requires a power cycle of the 2960X switch to recover is the following which is still under investigation:

https://tools.cisco.com/bugsearch/bug/CSCuu99972/?referring_site=ss

It is not a commonly seen problem in the field since the trigger is a very short duration power glitch. I am not sure if this applies to your situation. If not, you may want to contact the Cisco TAC to dig into the details surrounding the event a little deeper.

Mike