Ad blocker detected: Our website is made possible by displaying online advertisements to our visitors. Please consider supporting us by disabling your ad blocker on our website.
It's cuz E1Utilization value not exactly in 1.3.6.1.4.1.35265.1.29.31.1 OID, it's in 1.3.6.1.4.1.35265.1.29.31.1.index.0 OID.
Any advice to solve this problem?
Now i have problem with geting data for indexes to make graphs: data stores in OIDs like 1.3.6.1.4.1.35265.1.29.31.1.index.0
I can get data with snmpwalk and not with snpmget:
$ snmpwalk -v 2c -c secret 1.1.1.1 1.3.6.1.4.1.35265.1.29.31.1.0
SNMPv2-SMI::enterprises.35265.1.29.31.1.0.0 = Counter32: 9
$ snmpget -v 2c -c secret 1.1.1.1 1.3.6.1.4.1.35265.1.29.31.1.0
SNMPv2-SMI::enterprises.35265.1.29.31.1.0 = No Such Instance currently exists at this OID
I'm using method walk in my XML query file, but in tcpdump i see responses like "SNMPv2-SMI::enterprises.35265.1.29.31.1.0 = No Such Instance currently exists at this OID". How can i change XML file or somewhere in Cacti to query OID like 1.3.6.1.4.1.35265.1.29.31.1.index.0?
Are you sure the indexes for those two OIDs can be shared between 1.1.1.1 1.3.6.1.4.1.35265.1.29.7.1.2 and 1.1.1.1 1.3.6.1.4.1.35265.1.29.31.1.0? I would've expected the first query to output the index.0, but it doesnt appear to do so.
Maybe have cacti build the index using 1.1.1.1 1.3.6.1.4.1.35265.1.29.31 and update the regex to use both touples of the OID so Cacti ends up with:
1.0
2.0
3.0
etc
BSOD2600 wrote:
Maybe have cacti build the index using 1.1.1.1 1.3.6.1.4.1.35265.1.29.31 and update the regex to use both touples of the OID so Cacti ends up with:
1.0
2.0
3.0
etc
Tnx for advice. Looks a bit dirty, but it works, tnx again!