On Jan 15, 2008, at 5:34 PM, bill fumerola wrote: > On Thu, Jan 10, 2008 at 05:38:47PM -0500, Richard A Steenbergen wrote: >> I heard some grumbling that HP implemented vendor locking on >> their switches out of the blue with no notice and significant >> downtime >> caused to users who tried to upgrade code. > > this is true. as i recall, the warning was buried deep in the release > notes (possibly even the release AFTER the code that made devices sad) > and was phrased as a "reliability improvement" or some such.
Yep, this bit us, too. HP sold us switches saying we could move our existing SFP inventory over to save money, then pushes a non- downgradeable update on us for vague security reasons that slips in a vendor lockout... This is getting a bit off topic, but I can't turn down a chance to make sure the world knows about this. :) We invested a decent amount replacing our switch infrastructure with HP ProCurve switches. One of the things we confirmed with the sales engineers was that our existing SFPs would work. We even brought demo units in to play with before buying, and confirmed that our mish-mash of SFPs would work. This was important because we were on a limited budget, and I've got a rule about not stocking more spares than I need. Kinda pointless stocking otherwise identical SFPs except for the vendor ID. Then one day we get a notice from HP suggesting that we upgrade the firmware/OS on the switches. The exact description of the fix said nothing more than "Certain types of traffic cause the switch to route very slowly and drop packets." (seriously, those exact words were the entire description) Before doing the upgrade, I checked the full release notes and saw nothing else scary, so I upgraded our test switch (which had no SFP in it), saw that it was fine, then pushed the update to our production switches. Looking back that was probably a mistake, but... yeah. Even though the release notes said NOTHING about this, they slipped in a change that made the switch stop accepting non-HP SFPs. Absolutely nothing would get logged, the port would just seem dead. Even worse, as soon as the switch saw a non-HP SFP in a slot, it would completely kill that port until you rebooted the switch. Even swapping an HP SFP in wouldn't help unless you removed your non-HP SFPs before powering up. That made debugging this nearly impossible unless you knew what the problem was. The only thing I could see was that all my SFP ports were dead. This pretty much meant we were completely down. HP's ProCurve support seemed to know nothing about this change either. Downgrading to an older version was impossible for reasons I can't quite remember right now. Finally we get someone there to give us an updated release notes PDF that mentions that they're no longer allowing non-HP SFPs. On page 80-something of a 100+ page PDF. Since then they've moved it up to page 17, with a paragraph that says: "Non-genuine ProCurve Transceivers and Mini-GBICs have been offered for sale in the marketplace. To protect customer networks from these unsupported products, starting with release E.09.22, ProCurve switch software includes the capability to detect and disable non-genuine transceivers and mini-GBICs discovered in Series 5300xl Switch ports. When a non- genuine device is discovered, the switch disables the port and generates an error message in the Event Log." We escalated this as high as they'd let us. The reply from high up was that they were sorry for the inconvenience, but there is no workaround, and that it's for our own protection. I was a huge ProCurve fan before this, but... that's the last piece of HP gear we've purchased. If their SFP prices were at least reasonable, I would have at least been willing to put up with it, but when they're asking for $4k for an SFP today (it was even higher back when these were new), it's hard to justify that they're really doing this for anyone's good but themselves. Google for "J4860B" if you don't believe they actually want $4k for a GE SFP. :) -- Kevin _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp