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.