[c-nsp] Another unsupported-transceiver issue

[tim]

Nick,

On 02.09.2011 4:47 PM, Nick Ryce wrote:
> State:
>     Administrative state: enabled
>     Operational state: Down (Reason: Security failure (not a valid part))
>     LED state: Yellow On
> 
> Is there another hidden command I need to set to get the XFP to work?

I am not an optical or XFP expert, but we had the same issue with some
second source optics and the ASR 9000 series.  The ASR 9000 line-cards
seem to be more aggressive in the time-slot between giving power to the
XFP and wanting to fetch the data from the XFP eeeprom (i.e., the XFP
has not so much time to boot/get warm and deliver the eeeprom data to
the line-card).
One can test this by resetting the line-card with the XFP inserted.  If
the XFP comes up properly it is (it could be) this issue.

We have no (realistic) work-around for this second source optics, but
discussed this with the XFP vendors and they modified/upgraded the XFPs
and now they work with the ASR 9000 series routers.

BTW:  Until now we had no example were we needed the global "service
unsupported-transceiver" statement.  We do use the "transceiver permit
pid all" statement in interface configuration mode for some SFPs.

Hth,
	tim