[c-nsp] Third Party Xenpaks

[Michael Balasko]

What we have done is order one legit optic so we can get around the "TAC" issue when we call and then we tend to use finisar or merge for our optics.
Nary an issue yet and oddly I feel happy that I am not being asked to grab the far side of the desk.

Michael Balasko
CCSP,CCNP,MCSE,SCP
Network Specialist II

“I am willing to rock the boat because I am not afraid to swim. – me.”

On Nov 7, 2011, at 10:16 AM, Phil Mayers wrote:

On 07/11/11 17:56, Scott Voll wrote:
<legend says> unfortunately....it all came from a very large customer......

They were using 3rd party stuff and things were failing. couldn't figure
it out.... told cisco to figure it out or they were going to rip
everything out.

Cisco sent staff and found that the fiber transciever they were using
was over heating and dying. After that, cisco went to the if it ate
cisco we are not going to support it. it's at least better..... now they
let you..... but it raises BIG flags(or causes major issues).

I don't see how that incident justifies:

if (strncmp(xcvr->vendor, "CISCO", 5)==0) {
 do_ddm();
} else {
 /* OH NOES! An EEPROM from a different vendor */
 return -1;
}

Even if it did somehow justify it, it's not even an effective measure; as I said, it's really REALLY easy to buy "Cisco compatible" optics which just have CISCO written into the EEPROM.

So it's theatre; they pretend to lock optics, we pretend to care what they think and the people who suffer are the people who don't know about the "Cisco compatible" rigmarole, and suddenly find DDM doesn't work after a reload.

Pointless waste of time...
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net<mailto:cisco-nsp at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/