Cisco SFP (with DOM) Optical value plugin v0.2.3 + 0.2.4b

[timi]

Code: Select all

Error: XML: Hash version does not exist.

I got this when try to import the xml file saved from the link above

There are two XML in my post, are you trying to import cisco-sensors.xml instead of cacti_data_query_cisco_-_various_sensors.xml?

nope, the file is cacti_data_query_cisco_-_various_sensors.xml

[sodium]

is the XML is for 0.87e and not for previous versions?

[BorisL]

is the XML is for 0.87e and not for previous versions?

It was exported on 0.8.7e indeed, I can not verify that older version can not import it, all my instances are 0.8.7e. May be my XML is compatible with 0.8.7e only.

[sodium]

that is/was my point -- I do not have any 0.87d releases anymore... (too many improvements )

[FirstLast]

Hi,

ss_65xx_sfp.php doesn't work for SFPs/XFPs installed on 6500 into one of sub-slots with SIP-7600 and SPA 5X1GE-V2 or SPA-1X10GE-L-V2, it works only if SFP or X2 are installed into Supervisor Engine Slots 5 or 6.

This parsing for interfaces : # /usr/bin/php -q /usr/share/cacti/scripts/ss_65xx_sfp.php 192.168.1.11 public 2 index

using :
$var = (cacti_snmp_walk($hostname, $snmp_community, ".1.3.6.1.4.1.9.9.91.1.1.1.1.1", $snmp_version, "", "", 161, 5000, $snmp_retries, SNMP_POLLER));

would return only interfaces Te5/4 or T6/4, those which return DOM values with :

sho int T5/4 transceiver

However, SFPs, XFPs installed into SPA cards return DOM values with :

R#sho hw-module subslot 8/0 transceiver 1 status
The Transceiver in slot 8 subslot 0 port 1 is enabled.
Module temperature = +43.156 C
Transceiver Tx supply voltage = 3287.8 uVolts
Transceiver Tx bias current = 22588 uAmps
Transceiver Tx power = -5 dBm
Transceiver Rx optical power = -12 dBm
#

Does anybody know how to tweak this script to parse SPA cards for DOM-capable SFPs proper way ?

Regards

FirstLast

[sodium]

look at CISCO-ENTITY-SENSOR-MIB oid's

maybe you could test i with the script of BorisL (some postings back in the same thread)

[FirstLast]

I see he posted some some XML files, also see some other scripts, but they all use same snmp walk to determine interface which returns 14 as result of having DOM dBm sensor.

In order for DOM to be read from SFP inserted into SPA, different walk and drill down into subslot, then into sub-slot ports would be required before trying to determine which port returns dBM sensor value.

snmp walk will never return 14 for SFP in SPA card, because of different way of reading DOM from it :

R#sho int G8/0/1 transceiver
Module 8 doesn't support DOM

versus

R#sho hw-module subslot 8/0 transceiver 1 status
The Transceiver in slot 8 subslot 0 port 1 is enabled.
Module temperature = +40.453 C
Transceiver Tx supply voltage = 3277.8 uVolts
Transceiver Tx bias current = 24332 uAmps
Transceiver Tx power = -4 dBm
Transceiver Rx optical power = -5 dBm

Regards

FirstLast

[sodium]

Sorry I do not have your hardware so if you can not provide me with the OID's to poll I can not assist you in solving your issue...

[FirstLast]

Hi,

let me try to drill down to subslot to try to at least identify SFPs installed and I will get back to you.

Does anybody else know snmp-walk for CISCO6509 subslots, like SIP-7600, SPA cards, which can help identify SFPs installed and their eventual DOM capabilities ?

[BorisL]

There is a bug in IOS: newly installed transievers (after reboot) are not listed in DOM MIB inspite of being presented both in cli/inventory MIB.
That is why you can not fetch data from them via SNMP, no SNMP script/template will succeed.

[FirstLast]

Hi Boris,

do you know which firmware versions are affected with it ?

I run : s72033-adventerprisek9_wan-mz.122-33.SXI2.bin
which is one of very recent versions.

cmd line doesn't seem to have a problem, but only if you check via subslot syntax.

Regards

FirstLast

[toe_cutter]

is the XML is for 0.87e and not for previous versions?

It was exported on 0.8.7e indeed, I can not verify that older version can not import it, all my instances are 0.8.7e. May be my XML is compatible with 0.8.7e only.

Dont you run all your custom patches aswell? Without them, surely your cisco-sensors.xml will break.
Also considering reading the buglog with all the patches and more links to other bugs and patches (and more links in them), ill just wait for 0.8.8

[BorisL]

is the XML is for 0.87e and not for previous versions?

It was exported on 0.8.7e indeed, I can not verify that older version can not import it, all my instances are 0.8.7e. May be my XML is compatible with 0.8.7e only.

Dont you run all your custom patches aswell? Without them, surely your cisco-sensors.xml will break.
Also considering reading the buglog with all the patches and more links to other bugs and patches (and more links in them), ill just wait for 0.8.8

I wrote those patches actually

[BorisL]

Hi Boris,

do you know which firmware versions are affected with it ?

I run : s72033-adventerprisek9_wan-mz.122-33.SXI2.bin
which is one of very recent versions.

This version is affected for sure, I have a couple of them

[toe_cutter]

It was exported on 0.8.7e indeed, I can not verify that older version can not import it, all my instances are 0.8.7e. May be my XML is compatible with 0.8.7e only.

Dont you run all your custom patches aswell? Without them, surely your cisco-sensors.xml will break.
Also considering reading the buglog with all the patches and more links to other bugs and patches (and more links in them), ill just wait for 0.8.8

I wrote those patches actually

Yeah, i know :p (youre awesome!)
But what i meant was that on the 1225 bug there is like 7 patches, further down links to 4 more bugs, at least 2 of them have more patches and more links to other bugs and so forth, its hard keeping track of what i need

The first patch i tried from 1225 also failed on the dry-run :/