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

Fri May 16 16:30:16 EDT 2014

On Fri, May 16, 2014 at 1:10 PM, Jared Mauch <jared at puck.nether.net> wrote:

>
> 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.

I think this is the key--mentioning short distances.  Routers and
(non-optical) switches just weren't made to transport over such long
distances.

> > 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.
>

Some vendors do that but have hidden commands that enable "unsupported"
optics.  I know Cisco does this.  I haven't seen a vendor that just flat
out refuses without any option (hidden or not) to turn on support for
"unsupported" optics.  It worries me that vendors would do that.

>
> 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.
>

Thanks for this, by the way.  Will keep it in mind in the future.

>
> - 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
>
>