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

Experincing issues with 2960X switch

75 Replies 75

Hi Jackson.ku

 

Do you mean you got the same issue at IOS EX3, EX4, EX5 and 15-2.2?

We mean " try downgrade and upgrade  IOS EX3, EX4, EX5 and 15-2.2"

We attach file

Please suggest case this to me

 

I experienced a similar problem while trying to add an SFP to an existing and working WS-C2960X-24PS-L switch installed as a single switch with no stacking.

 

When I did a sh inv neither the production working SFP nor the newly installed SFP showed up.  I  also tried to view the transceiver under the show interface transceiver cmd.  I got the following output.

 

#sh int g1/0/28 transceiver
hulc_sfp_iic_intf_read_eeprom sfp _index 3 yeti_iic_read_retry fail
hulc_sfp_iic_intf_read_eeprom sfp _index 3 yeti_iic_read_retry fail
hulc_sfp_iic_intf_read_eeprom sfp _index 3 yeti_iic_read_retry failDiagnostic Monitoring is not implemented.

 

I then checked another of our many 2960x switches in another doctor's building on a non-clinical switch stack (using 3750x switches in more critical clinical areas w/ dual 10G VPC uplinks), and I saw the same output from the sh int gn/0/n transceiver cmd.  These stacked switches were working on the SFP uplinks.

 

My resolution for the moment was to do a hard power cycle.  I tried a reload that resulted in a non-communicating switch requiring me to go in for a power cycle late in the evening (doctor's area closed at night while making these changes).

 

I received the following output after the hard power cycle - pulling the plug.

 

#sh int g1/0/28 transceiver properties
Diagnostic Monitoring is not implemented.
Name : Gi1/0/28
Administrative Speed: auto
Administrative Duplex: auto
Administrative Auto-MDIX: on
Administrative Power Inline: N/A
Operational Speed: 1000
Operational Duplex: full
Operational Auto-MDIX: on
Media Type: 1000BaseSX SFP

 

I will be upgrading the code as well per other recommendations noted in this discussion thread.  These switches have not had a code upgrade since their install a few years ago with no problems noted until this incident.  The current version is 15.0(2)EX5.

 

Even in this situation, the problem did not become apparent until I tried to add a second SFP to provide 7K connected VPC redundant connectivity to one of our doctor's office locations on campus.   To date these switches have been very reliable with no initial out of box install failures and no production failures.

 

Thx

I downgraded to EX3 and all stacks have been stable since. Thanks.

Martin Swanson
Level 1
Level 1

I am running - WS-C2960X-48TS-LL  15.0(2)EX3            C2960X-UNIVERSALK9-M    

just had the switch lock up on tuesday.. 

Brand new switches - ran for about 30 days.

Swapped SFP's - and SFP ports / no luck - no light / rebooting resolved the problem

We havin the same kind of issue with a 2960X stack. (2 x 2960X)

only 1 out of 4 uplinks is working.

on 2 out of the 4 no SFP is recognized

and 1 port is showing up/up on 2960x side but not on the other side.

Stack runs on EX4 because of a bug CSCuj7029

buyin a switch for 2k and not be able to use the uplinks. great job cisco

MRCobb
Level 4
Level 4

I had this same issue today on a stack of 2960X switches.  When I checked on the bug listed in this posting, I noticed that 15.0(2)EX5 was released 3/8/2014 which contains the fix for this issue.  I have upgraded and verified that the issues are resolved at least for now.

Thanks,

Mike

I upgraded from EX4 to EX5 and still saw the SFP issue. 15.2 code has it fixed on 3 switch deployments so far. Tomorrow night will be my real test with putting 15.2 in a large closet. Will see!

Richard Imus
Level 1
Level 1

Hi.

Cisco Bug Search (CSCul88801) says that 15.0(2)EX5 is a known fix release. However the issue happened to our switch which is running on EX5. The switch uplinks suddenly went down without any related error in the logs. When I unplugged and plugged the sfp module again the error below came up:

 

ulc_sfp_iic_intf_read_eeprom sfp _index 0 yeti_iic_read_retry fail

 

After reboot sure enough it works again. But I don't know when will it happen again as we have total of four 2960X running on the same firmware.

 

Anyone else seen this issue on EX5? Our switch is operating as normal (no etherchannel, no stacking), just purely uplink to the core switch. Is there a clear fix to this issue yet? This switch is critical to us as all device connected to it are IP phones.

 

Thank you.

 

Agreed. Just had a group of switches go out again, because the distribution 2960X lost connection with its copper SFPs. Upgrading some to 15.2 now.

That doesn't seem to matter either (15.2). Cisco has recently released a 15.0.2a(EX5) release. I've installed it on one switch, and will install on another Thursday morning. If anyone uses this, be careful. I had to manually power cycle the switch twice, because things seemed to stall during the microcode update. Just be patient when it seems like it's not doing anything. Any pause longer than 10 minutes, reboot.

Another agree.

We have seen the issue on 2960Xs running EX5 using the GLC-T transceiver on several occasions.  TAC told us to downgrade to EX1 or not use the GLC-T transceivers for now.

I saw this issue in ex2, ,4, and 5... Upgrading to 15.2/fixed it

Hi, I got the same issue, the original IOS is 150-2.EX5, today I upgraded to 152-2.E, same issue still occurred.

The uplink port of this switch used SFP-T GBIC, and no etherchannel configured.

Please help to give me some advise. Should I downgrade to 150-2.EX3?

rrwise1
Level 1
Level 1

I had this issue with 2 stacked 2960-x switches using 15.0(2) EX4 loaded from the factory. A switch reboot temporarily fixed the issue.

I find it concerning that there have been multiple versions of the software that still have this issue with no clear idea if the problem is resolved or not. This should never have been an issue to begin with and the fact that it has been allowed to continue without a clear fix for a significant amount of time is not what I have come to expect from Cisco. I didn’t sign up to beta test switches.

For me the whole purpose of purchasing a switch with an SFP+ port is to USE the SPF+ port! I suspect this is the case for most companies that buy this or similar models. I realize that using 15.0(2) EX1 is a possible fix, but with all the bug fixes in the software since that version I would be very hesitant to use it. I also realize that 15.0(2) EX3 and EX5 are supposed to fix the issue as well, but some have reported the same issue with those versions. The bug search issues covering this don’t even list 15.2(2)E as a known affected or a known fixed release. Cisco should at least update the bug articles with up to date information.

I have upgraded to 15.2(2)E and it is working for now, but no idea if or when the SFP+ ports may become disabled again. Not something I want to put into production with this unknown!

FYI - I received this response from TAC regarding version 15.2(2)E:

"Yesterday I sent a email to the Developer team asking if this specific bug was fixed in 15.2(2)E and an Engineer confirmed that it is a fix release."

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: