Cacti suddenly not parsing SNMP OIDs

[AndyH]

I'm not sure how this has happened, but Cacti has suddenly stopped parsing SNMP OIDs and translating them properly according to the MIBs available on the system.

This is manifesting in several ways:

1. The output of the "Type" column in the "SNMP - Interface statistics" query now only lists the returned value and not the descriptive text specifying the interface type (e.g. it is displaying "117" when previously it was "gigabitEthernet(117)" (see attached screenshot, highlighted in red near the top)
2. Some data queries aren't working correctly as the OIDs aren't being translated at all (see two data queries near the bottom of the screenshot attached, the top example in red has been refreshed recently and is now broken, the bottom example in green has not been refreshed recently and shows the expected format).
3. The "add_graphs.php" CLI command isn't working as it's complaining about "ERROR: Unknown snmp-value for field ifType - ethernetCsmacd(6)". The below confirms the issue:

Code: Select all

php /var/www/cacti/cli/add_graphs.php --host-id=2086 --snmp-field=ifType --list-snmp-values
Known values for ifType for host 2086: (name)
1
117
6

If I do an snmpwalk on the CLI as the www-data user (which the poller and Apache2 run as), it correctly translates the SNMP OIDs according to the available MIBs:

Code: Select all

sudo -u www-data snmpwalk -v 2c -m ALL -c public 10.65.40.193 ifType
IF-MIB::ifType.1 = INTEGER: gigabitEthernet(117)
IF-MIB::ifType.2 = INTEGER: gigabitEthernet(117)
IF-MIB::ifType.3 = INTEGER: gigabitEthernet(117)
IF-MIB::ifType.4 = INTEGER: gigabitEthernet(117)
IF-MIB::ifType.5 = INTEGER: gigabitEthernet(117)
IF-MIB::ifType.6 = INTEGER: gigabitEthernet(117)
IF-MIB::ifType.7 = INTEGER: gigabitEthernet(117)
IF-MIB::ifType.8 = INTEGER: gigabitEthernet(117)
IF-MIB::ifType.9 = INTEGER: gigabitEthernet(117)
IF-MIB::ifType.10 = INTEGER: gigabitEthernet(117)
IF-MIB::ifType.11 = INTEGER: gigabitEthernet(117)
IF-MIB::ifType.12 = INTEGER: gigabitEthernet(117)
IF-MIB::ifType.13 = INTEGER: gigabitEthernet(117)
IF-MIB::ifType.14 = INTEGER: gigabitEthernet(117)
IF-MIB::ifType.15 = INTEGER: gigabitEthernet(117)
IF-MIB::ifType.16 = INTEGER: gigabitEthernet(117)
IF-MIB::ifType.17 = INTEGER: gigabitEthernet(117)
IF-MIB::ifType.18 = INTEGER: gigabitEthernet(117)
IF-MIB::ifType.19 = INTEGER: gigabitEthernet(117)
IF-MIB::ifType.20 = INTEGER: gigabitEthernet(117)
IF-MIB::ifType.21 = INTEGER: gigabitEthernet(117)
IF-MIB::ifType.22 = INTEGER: gigabitEthernet(117)
IF-MIB::ifType.23 = INTEGER: gigabitEthernet(117)
IF-MIB::ifType.24 = INTEGER: gigabitEthernet(117)
IF-MIB::ifType.25 = INTEGER: other(1)
IF-MIB::ifType.26 = INTEGER: other(1)
IF-MIB::ifType.27 = INTEGER: other(1)
IF-MIB::ifType.28 = INTEGER: other(1)

Code: Select all

sudo -u www-data snmpwalk -v 2c -m ALL -c public 10.65.40.193 iso.3.6.1.4.1.890.1.2.1.1.2.34.1.5.1
GBNPlatformOAM-MIB::stackDramUtilz.1 = INTEGER: 38

It's almost as if Cacti isn't able to load any SNMP MIBs, but I don't know why the behaviour is different on the CLI and when invoking Cacti (either through the web GUI or using the add_graphs.php script on the CLI, which I run as the root user).

[AndyH]

Having delved into this further, it looks like one of the issues (number 2 above) is due to Cacti suddenly deciding to interpret OIDs differently, which is causing the <oid_index_parse> regex to fail to match.

Previously we had:

Code: Select all

   <oid_index>.1.3.6.1.4.1.890.1.2.1.1.2.34.1.2</oid_index>
   <oid_index_parse>OID/REGEXP:enterprises.890.1.2.1.1.2.34.1.2.([1-4])$</oid_index_parse>

And now it works if we change it to:

Code: Select all

   <oid_index>.1.3.6.1.4.1.890.1.2.1.1.2.34.1.2</oid_index>
   <oid_index_parse>OID/REGEXP:iso.3.6.1.4.1.890.1.2.1.1.2.34.1.2.([1-4])$</oid_index_parse>

So Cacti is translating the start of the OID differently, preferring "iso.3.6.1.4.1.890.1.2.1.1.2.34.1.2" to "enterprises.890.1.2.1.1.2.34.1.2". An snmpwalk for "enterprises" works fine, so it's not like that definition has disappeared from the MIBs on the server.

The above seems to fix the parsing of the affected data queries, but it doesn't explain the other two issues (1 and 3 in the post above), namely that for some reason Cacti isn't correctly interpreting the values returned by the interface query; it's still only returning the numerical value for the interface type and not the textual description.

[netniV]

The ISO vs ENTRPRISE is not cacti interpreting things different but the device or MIB being updated to issue it differently. More than likely it's the MIBs that got updated.

[AndyH]

The ISO vs ENTRPRISE is not cacti interpreting things different but the device or MIB being updated to issue it differently. More than likely it's the MIBs that got updated.

I agree - I can work around that by updating the regex in the template XML files. I'm assuming that the same thing is affecting the displayed output of the "ifType" column (displaying only the numerical value and not the textual description for the interface type). But I don't understand that one - an snmpwalk clearly works fine on the CLI, so I'm not clear on why Cacti appears to be behaving differently.

[AndyH]

So it now looks like the problem has fixed itself; I'm suspecting that the values must have been cached somewhere though. Despite refreshing the data queries multiple times after each change I made, it didn't seem to be making any difference to the ifType column in the GUI.

But now it's back to normal again and is matching the output of snmpwalk via the CLI. Very odd.