What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general. You are invited to get involved by asking and answering questions!

Learn more

PRTG Network Monitor

Intuitive to Use. Easy to manage.
More than 500,000 users rely on Paessler PRTG every day. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free Download

Top Tags


View all Tags

Network snmp rewalk

Votes:

0

Your Vote:

Up

Down

In added a bunch of Cisco 3650s running 3.07.02 to my PRTG instance with no problems. THe auto-discovery found sensors and they all came up fine. After I upgraded to 16.3.1 the health sensors are in warning. I can delete the sensor and re-add it and it comes back. I did another auto-discovery but it is still alarming. What do I need to do to get it to automatically update without deleting and re-adding?

16-3-1 cisco

Created on Sep 26, 2016 4:50:13 PM by  tvc15 (0) 1



7 Replies

Votes:

0

Your Vote:

Up

Down

Hello,

Thank you very much for your KB-Post. Which exact errors do you get? Please send some screenshots showing the exact error messages from the "Overview"-Tab. In case the sensors are not in error-state right now, you can also check the "Log" tab of the sensor, to view previous error-messages.

best regards.

Created on Sep 27, 2016 11:23:47 AM by  Torsten Lindner [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Here is the alarm from the logs.

9/26/2016 9:00:27 AMSystem Health FansDownNo such instance (SNMP error # 223)

I didn't make any changes except upgrade to 16.3.1

Created on Sep 27, 2016 1:31:47 PM by  tvc15 (0) 1

Last change on Oct 3, 2016 6:56:39 AM by  Luciano Lingnau [Paessler]



Votes:

0

Your Vote:

Up

Down

It's very likely, that the OIDs on the target Cisco device change here, and the sensors then cannot find the OIDs anymore, which they need to monitor.
To check this, please use our SNMP Tester, run it on the PRTG Host (or host of the Remote Probe), and perform a SNMP Walk against the target device on the following base OID:

  • 1.3.6.1.4.1.9.9

Perform this walk once with the sensors green, save the result, and run the SNMP Walk again, when the sensors show this error again. Then send both walk-results to us.

Created on Sep 28, 2016 8:41:25 AM by  Torsten Lindner [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Doing a rewalk now. The PRTG utility has never worked for me. Does PRTG do a re-walk of the devices on schedule or on demand?

Created on Sep 30, 2016 11:07:39 PM by  tvc15 (0) 1



Votes:

0

Your Vote:

Up

Down

What exactly do you mean by 're-walk'? Which options are you using in PRTG to this? Did you run the SNMP Walk already with the SNMP Tester? We need the latter to see if the target device does even service the OIDs necessary for PRTG to show you sensors.

Created on Oct 3, 2016 6:56:16 AM by  Torsten Lindner [Paessler Support]



Votes:

0

Your Vote:

Up

Down

So I just manually deleted and recreated the sensors, but now we have to make more code changes and I am back to having sensors that are wrong. The previous version of cisco code has the temperaturestate (just as an example) at:

  • 1.3.6.1.4.1.9.9.13.1.3.1.6.1011 and the new code its:
  • 1.3.6.1.4.1.9.9.13.1.3.1.6.1006 Both stacks of two both OIDs for the first switch. There are other system health sensors with this same change. I tried setting the SNMP options to track by ifname, ifalias, ifdescription with no change. If I run autodiscovery it creates new sensors and I still have a bunch of bad sensors. Can I edit the OID for the existing sensors to the new version OID?

Created on Feb 22, 2017 10:28:08 PM by  tvc15 (0) 1



Votes:

0

Your Vote:

Up

Down

Thank you for the response. I'm very much afraid the SNMP Compatibility Options which if-fields are used for re-detection of changed OIDs only works with SNMP Traffic Counters, because there are these several fields which make sure, that an interface can definitely be identified.
Here with these objects like the Cisco Health Sensors, there is basically just the index. So there is no way to guarantee that the index 1006 is really the same element as 1011 was before. Which is why it is not possible to have an automatic detection here, and the OID cannot be changed manually either. So the sensor has to be created anew. Sorry.

Created on Feb 23, 2017 8:34:08 AM by  Torsten Lindner [Paessler Support]



Please log in or register to enter your reply.


Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.