[c-nsp] SFP's (Third party) for ME3600

Fri Sep 5 06:56:55 EDT 2014

Hello.
The feeling we have had is that mostly it's the tri-rate copper SFPs that is causing the frustration.
Same with ASR1001. Never had an issue with optical fixed rate modules though. 

Bästa hälsningar / Best regards,

Gustav Uhlander
Senior Communication & Infrastructure Engineer

Steria AB
Kungsbron 13
Box 169
SE-101 23  Stockholm
Sweden

Tel: +46 8 622 42 15
Fax: +46 8 622 42 23
Mobile: +46 70 962 71 03
gustav.ulander at steria.se 
www.steria.se

-----Original Message-----
From: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Aaron
Sent: den 4 september 2014 20:41
To: 'Lobo'; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] SFP's (Third party) for ME3600

Have you tried the hidden global command... "service unsupported-transceiver"

This worked for me when I couldn't get sfp's to work.  My notes below...

after typing that global command, just shut/no shut the port and it should immediately start working.  you won't need to reboot me3600 nor will you need to reinsert the sfp.  it will work.

insert sfp...  "show log" will show bad crc error and port in err-disabled mode.

sh int status err
sh int g0/23

...will show port in err-disabled

sh inventory

...will not be listed at first.

...will be down down on "sh ip int br"

conf t
int g0/23
shut
no shut

sh inventory

...will now show like this...

NAME: "GigabitEthernet0/23", DESCR: "Not Present"
PID:                   , VID:     , SN: 0000000008332636

Apr 18 07:59:26: %GBIC_SECURITY_CRYPT-4-VN_DATA_CRC_ERROR: GBIC in port 23 has bad crc Apr 18 07:59:26: %PM-4-ERR_DISABLE: gbic-invalid error detected on Gi0/23, putting Gi0/23 in err-disable state

eng-lab-3600-2#sh int status err

Port      Name               Status       Reason
Gi0/23    lab2 pc            err-disabled gbic-invalid

conf t
service unsupported-transceiver

eng-lab-3600-2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
eng-lab-3600-2(config)#service unsupported-transceiver
Warning: When Cisco determines that a fault or defect can be traced to the use of third-party transceivers installed by a customer or reseller, then, at Cisco's discretion, Cisco may withhold support under warranty or a Cisco support program. In the course of providing support for a Cisco networking product Cisco may require that the end user install Cisco transceivers if Cisco determines that removing third-party parts will assist Cisco in diagnosing the cause of a support issue.

eng-lab-3600-2(config)#int g0/23
eng-lab-3600-2(config-if)#shut
eng-lab-3600-2(config-if)#no shut
eng-lab-3600-2(config-if)#^Z
eng-lab-3600-2#ib g0/23

Interface              IP-Address      OK? Method Status
Protocol
GigabitEthernet0/23    unassigned      YES unset  down                  down
eng-lab-3600-2#ib g0/23
Interface              IP-Address      OK? Method Status
Protocol
GigabitEthernet0/23    unassigned      YES unset  down                  down
eng-lab-3600-2#ib g0/23
Interface              IP-Address      OK? Method Status
Protocol
GigabitEthernet0/23    unassigned      YES unset  up                    up

eng-lab-3600-2#

...show invent...

NAME: "GigabitEthernet0/23", DESCR: "Not Present"
PID:                   , VID:     , SN: 0000000008332636

...sho log...

Apr 18 08:08:24: %LINK-3-UPDOWN: Interface GigabitEthernet0/23, changed state to up Apr 18 08:08:25: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/23, changed state to up

eng-lab-3600-2#sh int status err
eng-lab-3600-2#

Aaron

-----Original Message-----
From: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Lobo
Sent: Thursday, September 04, 2014 10:48 AM
To: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] SFP's (Third party) for ME3600

Similar issues here.  The only 1000BaseT SFPs that we've gotten to work are the Cisco branded ones.  Some of the other brands/manufacturers we've used have given mixed results.  In one instance we had plugged in a 10/100/1000 SFP and tried connecting it to a Cisco 3750 FE port.  The FE port on the
3750 would come up but it would not come up on the 3600X side.  Swapping the SFP with a Cisco branded one would resolve the issue most of the time.  The 3600X has proven to be one of the more finicky switches in terms of accepting non Cisco branded SFPs.

Jose

On 9/4/2014 6:53 AM, Phil Mayers wrote:
> On 03/09/2014 22:03, David Farrell wrote:
>> On 02/09/2014 20:10, James Bensley wrote:
>>> I've used hundreads with no issues at all (with both 
>>> insertion/removal and actual operation).
>
>> I've had a few 1000BaseT SFPs, both Cisco-branded and otherwise, 
>> where the wee tab mechanism has broken and the 'release' isn't pushed 
>> in to allow the SFP to slide out. I ended up having to push the 'release'
>> mechanism in with a screwdriver to pop the SFP out. Had to file those 
>> SFPs in the bin.
>
> Likewise. The copper SFPs seem to be a bit hit and miss TBH, in terms 
> of physical build quality and actual work-ing-ness, particular the 
> tri-rate / autoneg style issues.
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net 
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/