[j-nsp] EX3300 fails to recognize 3rd party optics
Tyler Christiansen
tyler.christiansen at adap.tv
Fri May 16 15:54:15 EDT 2014
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.
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.
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.
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
>
More information about the juniper-nsp
mailing list