[c-nsp] Bugs in the 12.2(33).SRA1

[Emanuel Popa]

Hello everybody,

Regarding this old thread, I've recently discovered that DOM is no
longer supported for XENPAK-10GB-LR with 12.2(33)SRB. And I'm not
speaking about SNMP. Not even CLI show of transceiver DOM.
Fortunately, transceiver DOM is still available for XENPAK-10GB-LW:

router#sh ver | i IOS
Cisco IOS Software, c7600rsp72043_rp Software
(c7600rsp72043_rp-ADVIPSERVICES-M), Version 12.2(33)SRB1, RELEASE
SOFTWARE (fc3)

router#sh int status | i Gbase
Te10/1       CENSORED connected    routed       full    10G 10Gbase-LW
Te10/3                          disabled     1            full    10G 10Gbase-LR
Te12/1       CENSORED connected    routed       full    10G 10Gbase-LW

router#sh int te10/1 transceiver
[...]
                                         Optical   Optical
         Temperature  Voltage  Current   Tx Power  Rx Power
Port     (Celsius)    (Volts)  (mA)      (dBm)     (dBm)
-------  -----------  -------  --------  --------  --------
Te10/1     34.8       0.00      29.2 --   -2.6      -6.2

router#sh int te10/2 transceiver
Diagnostic Monitoring Data is not available.

why is that DOM feature not supported anymore? there was no problem
regarding DOM with CLI in SXF or SRA.

regards,
emanuel popa


On 1/30/07, Marian Durkovic <md at bts.sk> wrote:
> > Perhaps what I'm most annoyed is lack for DOM statics over SNMP, which
> > used to work great in SXF. But SRA tries to check if SFP/XENPAK really
> > is supported for DOM, and if cisco deems it is not, it happily
> > displays DOM in CLI, but according to TAC intentionally does not export to
> > SNMP. But at least for me, even supported XENPAKs (such as cisco DWDMs)
> > mostly do not export DOM over SNMP in SRA.
>
> This is clearly a serious design flaw. Noone could create a complete list of
> supported transceivers and once some manufacturer changes the product
> code all users will have to upgrade their IOS just to get DOM over SNMP.
> And of course, this will prevent the users to use DOM in cases where
> Cisco does not provide DOM-capable transceivers although they are easily
> available on the market.
>
> There is absolutely NO reason to introduce such flawed code, since the
> transceivers indicate their DOM capability by setting specific bits
> in their EEPROM. If there's fear that someone might plug in some crappy
> transceiver which sets those bits incorrectly, much more apropriate
> solution would be to introduce per-interface command to disable DOM
> for this specific interface.
>
>
>         With kind regards,
>
>
>                 M.
>
> --------------------------------------------------------------------------
> ----                                                                  ----
> ----   Marian Durkovic                       network  manager         ----
> ----                                                                  ----
> ----   Slovak Technical University           Tel: +421 2 524 51 301   ----
> ----   Computer Centre, Nam. Slobody 17      Fax: +421 2 524 94 351   ----
> ----   812 43 Bratislava, Slovak Republic    E-mail/sip: md at bts.sk    ----
> ----                                                                  ----
> --------------------------------------------------------------------------
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>