[j-nsp] QFX3500 optics lock?

[Phil Mayers]

On 01/09/2012 11:05 PM, Richard A Steenbergen wrote:
> On Sun, Jan 08, 2012 at 12:11:19PM +0000, Phil Mayers 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?
>
> Actually, this one I get... They're trying to detect and block a
> counterfeit product that says "Cisco" on it, and which as you said, was
> introduced into the supply chain without your knowledge that it was an
> inferior fake (and maybe even without your VARs knowledge too). This is

I wouldn't want to comment on the VAR. Suffice to say that "too good to 
be true" described the situation and pricing well...

> COMPLETELY different from artificially disabling a third party's
> product.

I am not trying to compare this to vendor locking. They are indeed 
completely different, and I merely cite it as illustration of one other 
position on the spectrum of transceiver permissiveness.

I will grant that denying the "new" optic is understandable. But 
shutting down an existing link is deeply unhelpful (as well as TOTALLY 
NON-OBVIOUS to the person inserting the optics).

For starters - what if the existing link is a Genuine Cisco(tm) SFP? 
Then the forged SFP not only doesn't work (fine) but stops a valid SFP 
from working (not fine). Unlikely I will admit, but not impossible.

I will also add that I have no evidence this duplicate checking is 
limited to transceivers matching CISCO* in the EEPROM; for all I know, 
it does it for any transceiver...

>
> Of course, if they weren't so busy trying to do the later there wouldn't
> be nearly as much demand for people doing the former, but they're still
> probably justified in blocking the duplicate serial #'s of Cisco
> products.

If you mean denying the new SFP, then I could understand that.

If you mean shutting down the existing SFP then I'm afraid we'll have to 
agree to disagree.

Anyway, this is getting OT for a Juniper list.

Cheers,
Phil