On Fri, May 16, 2014 at 1:10 PM, Jared Mauch <[email protected]> wrote:
> > On May 16, 2014, at 3:54 PM, Tyler Christiansen < > [email protected]> 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 <[email protected]> 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 [email protected] > >> https://puck.nether.net/mailman/listinfo/juniper-nsp > >> > > _______________________________________________ > > juniper-nsp mailing list [email protected] > > https://puck.nether.net/mailman/listinfo/juniper-nsp > > _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
