cancel
Showing results forĀ 
Search instead forĀ 
Did you mean:Ā 
cancel
104611
Views
164
Helpful
75
Replies

Experincing issues with 2960X switch

75 Replies 75

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

 

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

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.

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

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

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

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

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.

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.

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.

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

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 .

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

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.

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

Review Cisco Networking for a $25 gift card