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

[Jared Mauch]

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.


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.

- Jared

yes, FTP transport is 'correct'...

[1]ftp://ftp.seagate.com/sff/SFF-8472.PDF