[j-nsp] EX3300 fails to recognize 3rd party optics

Fri May 16 16:10:58 EDT 2014

On May 16, 2014, at 3:54 PM, Tyler Christiansen <tyler.christiansen at adap.tv> wrote:

> As much as it sucks, they're "right".  Most hardware vendors certify
> specific hardware as compatible, and if you choose to purchase outside of
> that is pretty much "caveat emptor".  Some optics are standards-based, some
> aren't, and you're at their mercy at the end of the day.  It's true of any
> vendor.

I think there are some varying degrees of grey here.  I've had some significant issues
with one of my vendor supporting their own optics within their own devices, even from
the same platform/business-unit.

> If it dies on you in the middle and kills that slot, the answer is just to
> not use it.  If you need long-haul transport, lease the transport or build
> your own transport equipment using equipment that's designed to do
> transport over long distance.
> 
> I know it's not the answer you want, but it's like trying to force a square
> peg into a round hole.  Routers and switches aren't designed for long-haul
> transport.  Optical transport equipment is designed for that role.

There's something to be said about utilizing optics in a router if you are just going a short distance and it's only one, but most folks don't take the time to check what that does to your thermals.  a 80km optic requires more power (and creates more heat) than a 10km optic.

> With all of that said, you have an ADVA optic, so maybe you have your own
> optical transport network.  In that case, I'm not entirely sure why you're
> trying to use a 160Km optic in the switch instead of using the optical
> long-haul network.

I think the key here is the forced locking vs supportability.  I'm fine with a device saying "This is unqualified", but I know how to talk to the i2c and provide power and talk to the data pins as defined in the SFF MSA.

Some vendors will refuse to read perfectly valid MSA fields if it's not "theirs", and that is borderline immoral.  I've started making sure RFP/RFI include reading those SFF MSA fields from all optics.

for SFP+ there are cool things like this:

http://www.amazon.com/gp/offer-listing/B00E0GWLGG?tag=pucknethernet-20&linkCode=sb1&camp=212353&creative=380553

Which include the ability to drop a grey optic on one side and use a colored or different optic on the other side for sub-$500.

- Jared

> On Fri, May 16, 2014 at 12:26 PM, ML <ml at kenweb.org> wrote:
> 
>> I've opened a JTAC case on this as well since I've seen this issue across
>> several EX3300s and several optic resellers (At least OSI and Transition
>> Networks.  I'm trying to get confirmation on OSI) and I want to find out if
>> other operators are seeing this problem.
>> 
>> I don't have any Juniper branded optics to test with unfortunately.
>> Especially since Juniper doesn't sell a 160km optic.
>> 
>> I have EX3300(s) which fail to recognize 3rd party optics when plugged in
>> after JunOS is loaded.  If the optics are in place and a reboot occurs the
>> optics are functional until I remove and reinsert them.  So far only a
>> reboot seems to restore functionality.
>> Even worse is that after an optic fails to get recognized in a given port,
>> that port is essentially 'poisoned' for a lack of a better term.  If I take
>> a functioning optic from one port and move it to a port which previously
>> exhibited log output similar to below,  the optic won't load.
>> Note: When an optic fails to load the switch doesn't show it as inserted
>> in any given port (At least via 'show chassis hardware').
>> 
>> Steps to show failure and testing procedure thus far.
>> 
>> EX3300 with the following optics:
>> 
>> ge-0/1/0: Transition Networks 160km  (TN1)
>> ge-0/1/1: ADVA 80km (AD1)
>> ge-0/1/3: Transition Networks 160km  (TN2)
>> 
>> Reboot switch.  All optics show in 'show chassis hardware'
>> 
>> Remove TN1, Remove AD1 and insert AD1 in ge-0/1/0.   AD1 is recognized.
>> Remove AD1, Insert TN1 in ge-0/1/0.  TN1 is not recognized. <----EEPROM
>> read failures occur here
>> Remove TN1, Insert AD1 in ge-0/1/0. AD1 is not recognized.
>> Remove AD1, Remove TN2 and insert TN2 in ge-0/1/0.  TN2 is not recognized.
>> 
>> Once the EEPROM read errors occur the port is essentially non-functional
>> and the optic that caused it won't work in any other port either.
>> 
>> 
>> Failure mode 2:
>> 
>> ge-0/1/0: Transition Networks 160km  (TN1)
>> ge-0/1/1: ADVA 80km (AD1)
>> 
>> Reboot switch.  All optics show in 'show chassis hardware'
>> 
>> TN2 inserted in ge-0/1/3. TN2 is not recognized <----EEPROM read failures
>> occur here
>> AD1 moved from ge-0/1/1 to ge-0/1/2 - Optic is recognized
>> AD1 and TN2 removed and AD1 inserted in ge-0/1/3. AD1 not recognized
>> <----EEPROM read failures occur here
>> AD1 and TN1 removed and AD1 inserted in ge-0/1/0. AD1 is recognized
>> AD1 removed and TN1 re-inserted in ge-0/1/0.  TN1 is not recognized
>> <----EEPROM read failures occur here
>> TN1 removed and AD1 re-inserted in ge-0/1/0.  AD1 is not recognized
>> <----EEPROM read failures occur here
>> 
>> Now to throw a wildcard in here.  Tried inserting a very off brand SFP-T
>> and SX multimode optics in all the ports in sequence and only ge-0/1/2
>> recognized the SFP.
>> 
>> Failure mode 3:
>> 
>> No optics are inserted at boot.
>> 
>> Moved the two off-brand SFPs and ADVA optic between all ports.  Not able
>> to generate EEPROM read failures.
>> Insert TN2 in ge-0/1/3.  EEPROM read failures occur here.  Now I am not
>> able to get any of the ADVA or off brand SFPs to work in ge-0/1/3
>> 
>> 
>> It would seem from this set of testing that Transition Networks SFPs are
>> the cause of the failures..
>> 
>> Example of what I see when an optic fails to load.
>> 
>> May  7 13:46:47  LAB.EX3300 chassism[1280]: phy_BCM8747_read_i2c: phy
>> eeprom read failed
>> May  7 13:46:47  LAB.EX3300 chassism[1280]: CCM: Failed to read SFP+ 3 ID
>> EEPROM at addr:0x50
>> May  7 13:46:47  LAB.EX3300 chassism[1280]: XCVR: XCVR 3 EEPROM read Failed
>> May  7 13:46:47  LAB.EX3300 chassism[1280]: xcvr_cache_eeprom:
>> xcvr_read_eeprom failed - link:3 pic_slot:1
>> May  7 13:46:47  LAB.EX3300 chassism[1280]: JTASK_SCHED_SLIP: 40 sec
>> scheduler slip, user: 1 sec 838899 usec, system: 1 sec, 419780 usec
>> May  7 13:48:15  LAB.EX3300 chassism[1280]: phy_BCM8747_read_i2c: phy
>> eeprom read failed
>> May  7 13:48:15  LAB.EX3300 chassism[1280]: CCM: Failed to read SFP+ 0 ID
>> EEPROM at addr:0x50
>> May  7 13:48:15  LAB.EX3300 chassism[1280]: XCVR: XCVR 0 EEPROM read Failed
>> May  7 13:48:15  LAB.EX3300 chassism[1280]: xcvr_cache_eeprom:
>> xcvr_read_eeprom failed - link:0 pic_slot:1
>> May  7 13:48:35  LAB.EX3300 chassism[1280]: phy_BCM8747_read_i2c: phy
>> eeprom read failed
>> May  7 13:48:35  LAB.EX3300 chassism[1280]: CCM: Failed to read SFP+ 0 ID
>> EEPROM at addr:0x50
>> May  7 13:48:35  LAB.EX3300 chassism[1280]: XCVR: XCVR 0 EEPROM read Failed
>> May  7 13:48:35  LAB.EX3300 chassism[1280]: xcvr_cache_eeprom:
>> xcvr_read_eeprom failed - link:0 pic_slot:1
>> May  7 13:48:35  LAB.EX3300 chassism[1280]: JTASK_SCHED_SLIP: 40 sec
>> scheduler slip, user: 1 sec 845078 usec, system: 1 sec, 417995 usec
>> 
>> 
>> 
>> Recent testing has been on: 12.3R6.6  although this issue was seen on
>> earlier releases.  I found a reference to PR/939041 it's similar but I
>> don't see I2C errors.
>> 
>> JTAC called me back while writing this and gave me the standard "can't
>> support 3rd party SFP line".  In my mind it shouldn't matter *when* the SFP
>> is inserted.  During boot, before boot, or after boot.  Seems like flimsy
>> software to me.
>> Is there a workaround to get the SFP recognized?
>> 
>> The optic appears as so:     "Xcvr 3       REV 01   740-011787 TNJN9XXXXX
>>      SFP-LH"  I found references to "SFP-OC48-LR" and "SFP-LR" for the
>> part number.  Could that make a difference?
>> 
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp