What can I do when my SNMP sensors in PRTG show errors? Are there troubleshooting steps?
SNMP and PRTG: Basic Troubleshooting
Every so often customers using PRTG Network Monitor report issues when trying to monitor their systems using Simple Network Management Protocol (SNMP). In most cases, these issues result from a malfunctioning SNMP configuration or installation. The following article provides an overview about most common reasons for problems when monitoring via SNMP.
Important! Before going any deeper into troubleshooting, you need to have a sound knowledge of the principles and functions of SNMP!
For a general introduction, see
Find an overview about SNMP, MIBs, and OIDs in
Please ensure the following:
- Enable SNMP on the device.
- Allow access to SNMP for the machine running PRTG Network Monitor in the device’s security settings.
- Allow User Data Protocol (UDP) packages to travel from the machine running PRTG to the device you want to monitor and back. If the device and PRTG are on different sides of a firewall, make sure that UDP access to port 161 (SNMP) is allowed. You will also need the return path open. For more information, please see the following articles:
- SNMP requires the use of UDP ports >1023 to the PRTG client side. This is important for your firewall settings.
- Ensure that the firmware of the monitored device runs at the latest version available! If an SNMP sensor (for example, the SNMP Traffic sensor) does not receive any packets from the monitored device, an update of the firmware of this device might help.
- PRTG supports three versions of the SNMP protocol:
- SNMP Version 1
- SNMP Version 2c (recommended)
- SNMP Version 3
It is important to know which SNMP version you have to select, because if it is not supported by the server or device you want to monitor, you will receive an error message. These error messages do not explicitly mention that you might use the incorrect SNMP version but only provide minimum information only, for example, could not connect. You can check/change the SNMP version used by PRTG in the Settings | Credentials for SNMP Devices of a device or group.
Note: SNMP v1 does not support 64-counters which may result in invalid data when monitoring traffic via SNMP. We recommend that you use SNMP v2c (most common) or SNMP v3.
- Similar error messages occur if authentication does not match:
- Community strings: a Community String is similar to a user ID or password allowing the access to a device’s statistics. PRTG sends it along with all SNMP requests. If the community string is incorrect, the device will discard the requests and will not respond. This value is case sensitive!
Error messages indicating that something is wrong with these requirements often are:
- Could not connect
- Error # 10060
- Error # 2003
Furthermore, it might not work to query data from a probe device via SNMP (querying localhost, 127.0.0.1, or ::1). In this case, add this device to PRTG with the IP address that it has in your network and create the SNMP sensor on this device.
Troubleshooting in Detail
If you encounter any problems with your SNMP sensors, the first step after checking basic requirements is to debug SNMP activities in order to find communication and/or data problems in SNMP monitoring configurations. For this concern, Paessler provides a test program, the Paessler SNMP Tester, that runs simple SNMP requests against a device in your network. If the connection works with this tool, it will also work with PRTG.
Debugging SNMP Activities—Steps to Go
- Go to the Paessler SNMP Tester.
- Download the .zip-file and follow the instructions on the page.
- Scan the target device from the system your PRTG Probe is running. First scan for uptime, later on for other values, too.
- Check if values are returned.
Please refer to the following articles for further information:
- Using Paessler SNMP Tester to debug SNMP problems with PRTG
- Solving “Could not connect” or “Error 10060” Messages when using SNMP
PRTG Settings for SNMP
SNMP V3 has software dependent performance limitations due to SSL encryption. If you encounter overload problems with SNMP V3, try the following options:
- Increase the monitoring interval of the SNMP V3 sensors. Currently, PRTG is able to handle roughly 40 requests per second and computer core, depending on your system. This means that, on a common 1.x GHz computer with two cores, you can monitor about 5,000 SNMP V3 sensors with a 60 seconds scanning interval.
- Distribute the SNMP V3 sensors over two or more probes if you experience an increased Probe Interval Delay SNMP or Probe Open Requests channels of the Core/Probe Health sensor.
- Switch to SNMP V1 or V2 if you can go without encryption, because these versions do not have these limitations.
Many network devices and programs come with Management Information Base (MIB) files which describe the parameters and readings available for monitoring via SNMP. With Paessler MIB Importer you can import these MIB files and convert them into OID libraries for PRTG. This way, you can easily setup SNMP Library sensors. For more information, please go to the following page:
Note: PRTG creates the log file mibparser.log for debugging purposes of MIB imports. This file contains all warnings and errors that might occur when reading an MIB file. You can find mibparser.log in the \MIB subfolder of your PRTG installation.
Tips and Tricks
Following are listed SNMP related issues:
SNMP, Windows, and PRTG
- Installing the SNMP service on Windows NT/2000/XP/2003
- Security aspects when working with SNMP on Windows
- Monitoring Windows Computers via SNMP
- What SNMP Sensors does PRTG offer?
SNMP, Mac OS, and PRTG
SNMP, Linux, and PRTG
SNMP Traps and PRTG
- Documentation of SNMP Traps Sent by PRTG
- How can I use PRTG’s trap receiver and what are its limitations?
- Testing a SNMP Trap Receiver sensor
SNMP Sensors and Devices
- How can I see all interfaces when adding a SNMP sensor for my Cisco device?
- Monitoring my Cisco switch doesn't work properly with SNMP. What can I do?
- No Such Name (SNMP error # 2) for NetApp Sensors
- SNMP NetApp System Health: SNMP error # 137
- SNMP error # 223 with HP C3000 Blade
- My Juniper switches show false 0 zero errors. What can I do?
- What can I check if SNMP and SSH sensors throw timeout and auth errors?
- How can I read “DateAndTime” format OIDs?
- How can I change the defaults for names automatically generated for new SNMP sensors?
- Some of my SNMP sensors do not work after updating from PRTG 8 to PRTG 9 or later (might also work after updates from other versions)
Refer to the following Microsoft TechNet articles for a general introduction to SNMP:
See also the following Paessler White Papers:
Can this be clarified?
"SNMP requires the use of UDP ports >1023 to the PRTG client side. This is important for your firewall settings."
I thought that SNMP used UDP ports 161 and 162? What would I set in my Windows firewall to accommodate the above statement? Would I set the firewall to allow incoming on port 1023? Or is it everything greater than 1023?
The UPD port 161 is used for snmp and port 162 for SNMP traps. By default on the PRTG Server Windows machine the outgoing Ports >1023 (greater than 1023) are open for snmp. It is not necessary to open incoming requests greater than 1023.
This may help you and others with Sophos firewalls, but we had to set the PRTG snmp version to V1. No matter what the Sophos version is, as long as the PRTG server is authorized to the Sophos, then set PRTG to V1. PRTG set to V2c and V3 seemed to balk and give no sensors. After changing to V1, everything lit up.
Right click the device, Edit, Settings, scroll down to Credentials for SNMP, uncheck it and then check that the version is V1. Do an auto discovery on that device and it should find a bunch of stuff for you. Been a year trying to figure this out. Got it from a network guy across the way who was messing around. Hope it helps.
This may or may not apply to you, but I was running PRTG in Server 2016 on a Hyper-V host connected obviously to a virtual switch that was physically a 6 NIC Team on my Host.
Teaming didn't work so great. Connected the vm to a single network card instead of the team and all my problems went away. Before I would get slow, spotty peformance, maybe 1/10 or at best 3/10 repsonses to my snmp polls.
Now it's rock solid.
If anyone ends up here and is teaming their nics for prtg, I'd suggest against it. Couldn't find any information on this anywhere, so it was a day spent with wireshark and powershell until I figured it out. Not fun.