[c-nsp] Third Party Xenpaks

Phil Mayers p.mayers at imperial.ac.uk
Mon Nov 7 09:30:46 EST 2011


On 07/11/11 14:09, Michael Robson wrote:
> After seeing how much money there is to be saved from using third
> party optics instead of Cisco branded ones, we finally bought a few
> to try. We have encountered no issues with using 10Gbps xenpaks, we
> plugged them in and they just worked. However, we did notice that DOM
> support was missing for these interfaces which didn't bother us much

Grr! Anger! The optic-monster awakes!

I really hate this vendor optics crap. I wish one of the really large 
customers would put in a mandatory tender requirement:

MR56. Vendor must not disable or restrict any feature on optics on the 
basis of optic EEPROM fields. On any of their platforms. Even ones we're 
not buying. Ever.

;o)

> but slightly more annoyingly was that after rebooting these two 6500s
> (running SXI5 IOS) we noticed that DOM stopped working for _all_
> interface modues (Cisco or third party)-  the "sh int transceiver"
> command disappeared all together.

That sounds like an IOS bug.

What does "sh idprom int Tex/y | inc endor" say for one of the non-Cisco 
parts, compared to a Cisco part?

>
> Is this to be expected and/or is there a way to restore DOM support
> for our Cisco Xenpaks?

For what it's worth, when buying 3rd party transceivers we've always 
bought "Cisco compatible" from Prolabs. AFAICT this means they blow the 
string "CISCO" into the EEPROM... I believe you can actually do this 
yourself if you have the right kit.

We've never had problems with such transceivers and DOM, including with 
SFP+ in a X2->SFP+ converter in a 6716.


More information about the cisco-nsp mailing list