Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

Experincing issues with 2960X switch

 
Everyone's tags (4)
3 ACCEPTED SOLUTIONS

Accepted Solutions
Silver

2960X stops recognising SFP modules

Adrian,

This error message is due to a bug, CSCul88801.

https://tools.cisco.com/bugsearch/bug/CSCul88801/?reffering_site=dumpcr

Downgrading the IOS to 15.0(2)EX3 should resolve the issue.

Thanks

Ankur

"Please rate the post if found useful"

Cisco Employee

2960X stops recognising SFP modules

Edit: Please see CSCur56395, resolved in 15.0(2a)EX5.

New Member

Confirmed, hard boot did the

Confirmed, hard boot did the trick in both instances and we're back in business.

 

Also want to share with folks that before this 2a install, regular EX5 was still giving us problems with the GLC-LH-SM xcvr.  This was a break to the pattern where we thought the only xcvr still with issues with GLC-T.

71 REPLIES
New Member

2960X stops recognising SFP modules

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

New Member

2960X stops recognising SFP modules

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.

New Member

The bug i got from TAC & BU

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

New Member

WTH is wrong with Cisco here?

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. :-(

New Member

Replying to my own post here.

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. 

 

New Member

We have had multiple issues

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.

New Member

Did TAC ever release this fix

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!

New Member

Since the fix came out in an

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.

New Member

HiI had the exact same issue

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.

Cisco Employee

Details of the fix for this

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.

 

New Member

Running 15.0(2)EX5, fiber sfp

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".

Cisco Employee

It is a software issue and

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
New Member

Hi Mike,We have recently

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!

Cisco Employee

Hi Doug,If the 2960X switches

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

 

 

New Member

Hi Doug and allHad 30 x 2960x

Hi Doug and all

Had 30 x 2960x with 15.0(2a)EX5 delivered a few weeks ago. Clean out of box and today saw the same error message:

hulc_sfp_iic_intf_read_eeprom sfp _index 1 yeti_iic_read_retry fail POST

Seems the bug still exists in this version. We are about to put these into production environment!!

Is there a version that actually fixes this problem. Seems a huge amount of confusion and frustration around this and I share the feeling.

Any clear and definitive answer would be very helpful

Thanks

Rhydian

 

Cisco Employee

Hi Rhydian,Sorry to hear

Hi Rhydian,

Sorry to hear about the problem you are facing. I spent some time checking through our internal Cisco TAC database and this is the 1st I have heard of 15.0(2a)EX5 not fixing the "hulc_sfp_iic_intf_read_eeprom sfp _index 1 yeti_iic_read_retry fail POST" issue referenced here:

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

As mentioned in the doc a one time hard boot (unplug and replug the power cable) is typically required for switches running 15.0(2a)EX5 that had experienced the issue prior to an upgrade to 15.0(2a)EX5. In your case if the switches were running 15.0(2a)EX5 out of the box I assume this means that they were powered up with this code which would amount to the same thing.

If this is the case then I would recommend opening a case with the Cisco TAC to investigate. Please reference the above doc when talking to the TAC engineer. The TAC engineer can do a more detailed analysis like looking at the SFP's involved in the error message, etc.

Thanks,

Mike

New Member

Thanks MikeIt's pretty

Thanks Mike

It's pretty frustraing as it's clear from the forum going back 18 months that this is an issue with the 2960x yet no clear resolution.

We are in a production environment and very reluctant to role this out. Will open a case with TAC but don't hold out much hope having read the issues and how long it's been going. Really dissapointed in Cisco on this.

New Member

Thanks Mike. All of these

Thanks Mike.

 

All of these switches came out of the box with the Version 15.0(2a)EX5 code.

We configured them for our environment and then put them in production.  All were connected back to a 4507 switch.  The 4507 2 - 10gb uplink was disconnected for about 2 hours.  The 4507 was left powered on as well as all of the 2960x switches.

We reconnected the 2 - 10gb uplinks to the 4507.  The 4507 as well as all the 3750 switches connected to the 4507 links came right back.  However, none of the 2960x switches did until we pulled the power on them.

Doug

Cisco Employee

Hi Doug,Are all the 2960X's

Hi Doug,

Are all the 2960X's part of the same power source (such as UPS, etc?)? Is there any chance that the 2960X's may have experienced a brief 1-3sec power toggle to trigger this know issue:

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

I suggest opening a TAC case to investigate. The TAC engineer can look at things like event syslogs to try and piece together what happened.

Mike

New Member

Hi DougHaving exact same

Hi Doug

Having exact same issues in testing phase before deploying these switches into a production environment.

Did you have any updates or resolutions to this issue?

Any help or guidance would be really appreciated.

Thanks

Rhydian

New Member

Hi MikeHad 30 x 2960x

Hi Mike

Had 30 x 2960x switches delivered a few weeks ago 15.0(2a)EX5 on them. Still seeing the error message:

 hulc_sfp_iic_intf_read_eeprom sfp _index 1 yeti_iic_read_retry fail POST

 

Obviously the problem is not fixed. Others reporting that 15.2(2) is also failing in same way.

We're in production environment and cannot deploy these switches as is until there is a clear and reliable resolution that is known to work.

Do you have any more information that would help?

Thanks

Rhydian

New Member

Recently tried 15.0(2a)EX5 on

Recently tried 15.0(2a)EX5 on a few switches, and I had to do a physical power cycle after a normal software reload for the SFPs to finally be recognized.    Granted, this is a very small sample set to draw any solid conclusions.  All I can say is I've had such solid reliability with every Cisco switch model up until the 2960X.

Cisco Employee

Hi Nickolus,15.0(2a)Ex5 does

Hi Nickolus,

15.0(2a)Ex5 (and 15.2(2)E2) does have the fix but as mentioned in the link below a one time hard boot (physical power cycle by unplugging and plugging the power cable) may be required after the code is upgraded if the switch was in a failed state prior to the upgrade.

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

This issue has to do with an internal bus getting into a bad state. The hard boot is to reset power to the bus if the bus was already in the bad state prior to the upgrade. The code upgrade procedure itself initiates a soft boot to load the image but the bus maintains power through that process so an existing bad bus state may not get cleared. Once the issue is cleared after the hard boot, 15.0(2a)EX5 (or 15.2(2)E2) will ensure it does not come back in the future even during future reloads or power outages. If a switch has not yet experienced the issue then an upgrade to 15.0(2a)EX5 (or 15.2(2)E2) without a hard boot will be enough to avoid the issue in the future.

New Member

Confirmed, hard boot did the

Confirmed, hard boot did the trick in both instances and we're back in business.

 

Also want to share with folks that before this 2a install, regular EX5 was still giving us problems with the GLC-LH-SM xcvr.  This was a break to the pattern where we thought the only xcvr still with issues with GLC-T.

New Member

Hi Nickolus Just readin

Hi Nickolus

 

Just readin through the thread. We have 25 x 2960x switches with 15.0.2(EX5) on site. I've configured them in test environment new from box and have the same bug issue.

Really concerned about putting these into our production environment.

Just wondering if you found a resolution and how this issue has panned out for you.

Any feedback or help would be really appreciated.

Thanks

Rhydian

New Member

i need help ,cisco catalyst

i need help ,cisco catalyst sw2960G 24port power problem in customer place ,

how can i check this ?

i.e. switch off and switch on sw2960G is not power on ,but connect to office mean power is on .

New Member

This error message is due to

This error message is due to a bug, CSCul88801.

https://tools.cisco.com/bugsearch/bug/CSCul88801/?reffering_site=dumpcr

Downgrading or upgrading the IOS to 15.0(2)EX3,EX4, EX5 series IOS having above mentoned bugs should resolve the issue.

Thanks

Sandeep Yadav

New Member

If you have an open TAC case

If you have an open TAC case ask for 15.0 (2) EX5ES, they published it to me last week and so far so good...no lockups to report.

New Member

Is that like a special fix to

Is that like a special fix to EX5 that just adds the code for the SFP issues?

55150
Views
149
Helpful
71
Replies
CreatePlease to create content