On Apr 23, 2014, at 9:35 AM, Jared Mauch wrote: > > On Apr 23, 2014, at 1:07 AM, Charles Sprickman <[email protected]> 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 > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
