[c-nsp] ASR-1K and 3rd party sfps

[Charles Sprickman]

On Apr 23, 2014, at 9:35 AM, Jared Mauch wrote:

> 
> On Apr 23, 2014, at 1:07 AM, Charles Sprickman <spork at bway.net> wrote:
> 
>> On Apr 23, 2014, at 12:39 AM, Mike Hale wrote:
>> 
>>> We've seen really weird behavior with third party SFPs in the past.
>>> NHR has been surprisingly solid for us across all out platforms so far
>>> *knock on wood*.
>>> 
>>> We've got some Finisar-branded SFPs in our ASR which work nicely (but
>>> that's expected since Finisar is the OEM, IIRC, for Cisco's SFPs).
>>> 
>>> Actually...check this out.
>>> 
>>> https://supportforums.cisco.com/discussion/11445646/advice-needed-cisco-asr-1002-routers-sfps
>>> 
>>> The GLC-T don't appear to be supported on first glance.  The GE-T are.
>>> Since your vendor calls them GLC-T (even though they claim to be
>>> GE-T), that might be your issue?
>> 
>> I suspect you nailed it.  The sticker says GLC-T, the idprom (or perhaps this is something IOS is generating based on some other properties of the GBIC) says "GE-T":
>> 
>> Transceiver Type:                         = GE T (26)
>> 
>> Of course it also claims the connector is an LC (or "LC."), which is beyond nonsensical:
>> 
>> Connector type                            = LC.
>> 
>> Vendor is supposed to be shipping something out to replace it, not sure what yet.
>> 
>> I promise to follow-up for the archives when I've got something that works.

For Google:

In the ASR-1000 series SPAs, you do not want a GLC-T SFP.  You want a GE-T.

Vendor (Level4 Hardware) overnighted the proper SFP and it worked perfectly.

>From what I can gather, the GE-T only does 1000-Base-T FD.  The GLC-T does 10/100/1000 FD/HD.  If I had to wildly speculate on this, I would say that there no reason at the hardware level for the GLC-T to not work; it's probably just sitting there waiting for some handshake from the router regarding speed/duplex.  This never happens and it sits there in a quasi-active state.

> When Cisco reports improper data out of the SFF-8472[1] MSA please open a support case showing the
> issue and how to reproduce so they can fix their drivers.
> 
> It looks like they are reading/populating the connector type wrong that should be read from
> address 0xa0 byte 2 as seen in table 3.4 of the SFF-8472 MSA.  Or the optic you have is presenting it incorrectly.  RJ45 is 0x22 and LC is 0x07.
> 
> I've found many bugs in the SFP/i2c driver in all versions of software (IOS, IOS-XE, IOS-XR) in our operation that cause improper data to be reported.

The GE-T reports as LC as well.

I absolutely can't find it now, but when I was furiously googling around for more information on this problem, I could have swore I saw a reference somewhere that the fixed-speed copper SFPs always report the connector type as LC.

If you think it's worthwhile to open a case though, I will - we finally have SmartNet, so I don't mind making Cisco work a bit for the contract.

Thanks,

Charles

> - Jared
> 
> yes, FTP transport is 'correct'...
> 
> [1]ftp://ftp.seagate.com/sff/SFF-8472.PDF
>