Re: vendor-locking optical modules (Question re: IBM G8124E)

[Faisal Imtiaz <faisal () snappytelecom net>]

Hello,
Since we are on the topic of vendor locked optics.

Does anyone know  if the IBM G8124 TOR Switches have a hidden menu option to over-ride the vendor lock optics ?

--------
We are seeing something interesting... we have a couple of these in production networks, apparently one switch will 
accept only IBM Optics, while the other will accept any....

I am not able to find anything which can explain the different behavior on the two switches.

If anyone can offer an insights that would be greatly appreciated.


Many Thanks in advance.

Faisal Imtiaz
Snappy Internet & Telecom
7266 SW 48 Street
Miami, FL 33155
Tel: 305 663 5518 x 232

Help-desk: (305)663-5518 Option 2 or Email: Support () Snappytelecom net 

----- Original Message -----
> From: "Chuck Anderson" <cra () WPI EDU>
> To: nanog () nanog org
> Sent: Saturday, December 6, 2014 8:37:01 AM
> Subject: Re: A case against vendor-locking optical modules
>
> On Sat, Dec 06, 2014 at 11:51:56AM +0200, Saku Ytti wrote:
> > a) one particular optic had slow i2c, vendor polled it more aggressively
> > than
> > it could respond. Vendor polling code didn't handle errors reading from
> > i2c,
> > but instead crashed whole linecard control-plane.
> > Vendor claimed it's not bug, because it didn't happen on their optic. I
> > tried
> > to explain to them, they cannot guarantee that I2C reads won't fail on
> > their
> > own optics, and it's serious problem, but was unable to convince them to
> > fix
> > it.
> > Now I am in possession of good bunch of SFP I can stick to your routers in
> > colo, have them crash, and you won't have any clue why they crashed.
> >
> > b) particular vendor had bug in their SFP microcontroller where after 2**31
> > 1/100 of a seconds had passed, it started to write its uptime to a location
> > where DDM temperature measurements are read. This was obvious from graphs,
> > because it went linearily from -127 ... 127, then jumped back to -127.
> > These optics when seated on Vendor1 caused no problems, when seated on
> > Vendor2
> > they caused link flapping, even two boxes away! (A-B-C, A having
> > problematic
> > optic, B-C might flap). Coincidentally Vendor2 is same as in case a), they
> > didn't consider this was bug in their code.
> > This was particularly funny, if you rebooted 100 boxes in a maintenance
> > window, then the bug would trigger at same moment after 2**31 1/100th of a
> > second, causing potentially major outage.
>
> Who is Vendor2?