[j-nsp] QFX3500 optics lock?

[Phil Mayers]

On 01/08/2012 12:22 PM, sthaug at nethelp.no wrote:
>> However - crappy though they were, imagine my irritation when, even with
>> "service unsupported-transceiver", a duplicate SFP serial number caused
>> err-disable on BOTH ports, and requires BOTH transceivers to be removed.
>>
>> It's not obvious to me that this is a reasonable response; the 1st
>> transceiver was in, and forwarding packets. Why disable it? What
>> possible "value" does that add?
>>
>> So even the Cisco model is a bit more restrictive than first
>> appearances. It's only "some" unsupported transceivers.
>
> I believe I've also seen the problem that switches which *can* read
> DOM values (e.g. 3560, ME3400) won't do this for non-cisco branded
> SFPs (e.g. when you need to use "service unsupported-transceiver")
> even when the SFPs themselves support this (and will happily supply
> optical signal levels when inserted for instance into a Juniper MX
> router).

Ugh, I'd forgotten about that. What was their crappy claim?

"We once saw an SFP give crazy DOM numbers, and the customer really 
hassled TAC, so we decided to disable DOM on all non-Cisco SFPs just in 
case, even though they all come from the same factory."

DOM in Cisco has always been a bit of a pain though (6748-SFP linecards, 
GRR HULK SMASH).

That's why we took the time to specifically add the 2nd clause to our ITT:

"""
The device must support DOM/DDM, specifically including TX and RX light 
levels. Any device which does not report DOM/DDM on generic transceivers 
will be immediately disqualified.
"""

I am determined that the vendors are going to start getting the message 
on this.