Host down...but not down?

[hipsterdoofus]

I just replaced a server and in doing so I upgraded from 0.8.6j to 0.8.7b - did the db upgrade, etc. Everything seems to be working great with one exception -

I have an MGE UPS. For some reason, on the devices list, cacti says it is down; however, if I click on the device, it shows current snmp system info at the top. I can do an snmpwalk from command line and it comes back fine. Kind of stumped. I seem to recall there are ways to do stuff from command line to try to figure out where a problem is, but can't recall how, so any tips would be appreciated.

[BSOD2600]

what uptime detection method are you using for that device?

Looking in your cacti.log file, why was the device detected down during the last polling cycle?

[hipsterdoofus]

what uptime detection method are you using for that device?

Looking in your cacti.log file, why was the device detected down during the last polling cycle?

Looks like the device detection is snmp....which again, works fine through an snmpwalk. Also...log file looks good...I had something else in there that was failing, but just took care of that.

[hipsterdoofus]

Anyone else have any tips for troubleshooting this problem? Thanks.

[hipsterdoofus]

Do I need to post this in another area? Could really use ideas on troubleshooting

[gandalf]

Cacti performs an snmpwalk against .1.2 to verify host availability. Please return result of such a command
Reinhard

[mcutting]

This may sound slightly dumb, but is the snmp community correctly defined in Cacti dor this host ? Also, have you tried SNMP v1 and v2 ?

[hipsterdoofus]

Cacti performs an snmpwalk against .1.2 to verify host availability. Please return result of such a command
Reinhard

Thanks for the reply -
snmpwalk -c public -v 1 10.59.33.175 .1.2
Gives a response of
Timeout: No Response from 10.59.33.175

However, if I do
snmpwalk -c public -v 1 10.59.33.175 .1.3.6.1.4.1.705.1.5.2.0
I get back
SNMPv2-SMI::enterprises.705.1.5.2.0 = INTEGER: 100

And yes...snmp communities are defined correctly...in my Devices listing, it shows it as down, but when I click on the device, up at the top, it shows the snmp response:
SNMP Information
System: Galaxy 3000 20 kVA
Uptime: 701352210 (81 days, 4 hours, 12 minutes)
Hostname:
Location: Computer Room
Contact: Computer Room Manager

All that I did was move my cacti setup from one server to another. During the process, I also upgraded from an older version. Everything else came up fine...only this UPS isn't working correctly.

[chummers]

I too am getting the exact same symptoms on two Powerware 80Kva Room UPS's, the 30Kva and 60Kva Generex UPS's are fine...

I would be interested to find out why this is happening...

[hipsterdoofus]

I too am getting the exact same symptoms on two Powerware 80Kva Room UPS's, the 30Kva and 60Kva Generex UPS's are fine...

I would be interested to find out why this is happening...

Glad to see that maybe I am not crazy ...I don't necessarily need to know how to fix it...just a better idea of how to troubleshoot and figure out the problem. Doesn't make sense to me that cacti thinks its down in one place, yet it is obviously getting an snmp response. Also my graphs are not working and I am getting nan...

Something in the difference between the previous version of cacti that I had and this one.

[gandalf]

Please see http://forums.cacti.net/about6515.html
Reinhard

[hipsterdoofus]

Please see http://forums.cacti.net/about6515.html
Reinhard

I don't think that applies to me...because I believe it references 8.6c...and I start out with 8.6j I think - which worked fine and moved to 8.7b...which doesn't work.

[gandalf]

While you are correct in detail, you fail when it comes to the "general principle". Perhaps my answer was a bit too short.
It should tell you, that cacti requires an snmp enabled device to answer to a specific OID request. Please be assured, that we re-thought this every now and then to get the best possible approach! But there are devices out there, that simply do NOT return anything meaningful to what we supposed would be the "most common" OID. In this case, currently you'll have to change cacti code as given in this thread.
I suppose that once in a while we'll have to introduce a new host-specific parameter "Device specific OID for SNMP availability Tests" or the like to avoid code changes. Perhaps this goes with the feature "automatic device type detection".
Reinhard

[hipsterdoofus]

While you are correct in detail, you fail when it comes to the "general principle". Perhaps my answer was a bit too short.
It should tell you, that cacti requires an snmp enabled device to answer to a specific OID request. Please be assured, that we re-thought this every now and then to get the best possible approach! But there are devices out there, that simply do NOT return anything meaningful to what we supposed would be the "most common" OID. In this case, currently you'll have to change cacti code as given in this thread.
I suppose that once in a while we'll have to introduce a new host-specific parameter "Device specific OID for SNMP availability Tests" or the like to avoid code changes. Perhaps this goes with the feature "automatic device type detection".
Reinhard

When I do the search in ping.php, it has an if/else loop...the first option in the loop is .1.3.6.1.2.1.1.3.0, which is what that thread says to change it to...the second option is .1.3.6.1.2.1.1.1.0...so it seems to already be done?

[gandalf]

But does your device answer to one of both OIDs? Your example shows a private MIB OID
Reinhard