[j-nsp] Junos 12.3 more strict about 3rd party optics?

[Jonas Frey (Probe Networks)]

Most 3rd party vendor's lock down the A0 part of the SFP+, so you cant
change values there. Try asking your vendor if they can provide A0
unlocked SFP+...usually they will be a bit more expensive. If they dont
want to offer them just choose another supplier...there are plenty.
Having a SFP+ EEPROM writer can be very handy, in case you are having
problems with vendor XY locking down their routers/switches etc.
And dont go with "pay as you write" SFP eeprom writers which are tied to
certain companys.


Am Dienstag, den 24.06.2014, 09:17 -0400 schrieb Chuck Anderson:
> On Wed, Jun 11, 2014 at 03:49:16PM +0100, Phil Mayers wrote:
> > On 11/06/14 15:01, Chuck Anderson wrote:
> > 
> > >Jun 10 11:40:54  ex4200 chassism[1293]: XCVR: Unit 0, SFP+ of type 0 EEPROM is Mis Programmed!!
> > 
> > Yeah, this was the one that caught my eye. I wonder if it's choking
> > on unknown values in the EEPROM.
> 
> After much investigation, and thanks to Juniper not locking down
> access to the internal debugging tools on JUNOS, I was able to
> determine that bytes 3-10 of the SFP ID EEPROM of optic I'm using are
> coded as all 0's.  My reading of the SFF-8472 MSA says that this is
> invalid:
> 
> "Transceiver Compliance Codes [Address A0h, Bytes 3-10]
> 
> The following bit significant indicators define the electronic or
> optical interfaces that are supported by the transceiver. At least one
> bit shall be set in this field."
> 
> The top half of byte 3 is defined as follows, and I would expect any
> MSA Ethernet optic to have at least one of these bits set, even
> CWDM/DWDM optics:
> 
> Byte	  Bit	 Description
> 3	  7	 10G Base-ER
> 3	  6	 10G Base-LRM
> 3	  5	 10G Base-LR
> 3	  4	 10G Base-SR
> 
> My optic vendor doesn't agree and says that those bits only refer to
> "grey" optics--standard wavelengths 850nm or 1310nm, and says that it
> is VALID to have no bits set all all in bytes 3-10.  I'm guessing that
> the SFP driver in EX4200 doesn't like this, but the one in MX doesn't
> care.
> 
> I tried changing the values using "xcvrpeek" and "xcvrpoke" (and
> "i2cpeek"/"i2cpoke").  Reads work fine, writes fail with -EIO in dmesg
> and the values don't change when read back.  I guess the optic is
> "locked" from writing changes to the EEPROM without some sort of OEM
> password or something.
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://puck.nether.net/pipermail/juniper-nsp/attachments/20140624/12db508a/attachment.sig>