New Question
PRTG Network Monitor

Intuitive to Use.
Easy to manage.

200.000 administrators have chosen PRTG to monitor their network. Find out how you can reduce cost, increase QoS and ease planning, as well.

Download >>


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


Top Tags

View all Tags

My SNMP sensors don’t work. What can I do?



Your Vote:



What can I do when my SNMP sensors in PRTG show errors? Are there troubleshooting steps?

important prtg snmp troubleshooting

Created on Jan 30, 2013 9:25:15 AM by  Gerald Schoch [Paessler Support]

5 Replies

Accepted Answer



Your Vote:



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.

Getting Started

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

Basic Requirements

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!
    • Usernames
    • Passwords

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,, 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.

See also

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

  1. Go to the Paessler SNMP Tester.
  2. Download the .zip-file and follow the instructions on the page.
  3. Scan the target device from the system your PRTG Probe is running. First scan for uptime, later on for other values, too.
  4. Check if values are returned.

Please refer to the following articles for further information:

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.

Importing MIBs

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

SNMP, Mac OS, and PRTG

SNMP, Linux, and PRTG

SNMP Traps and PRTG

SNMP Sensors and Devices

Other Issues

Further Reading

Refer to the following Microsoft TechNet articles for a general introduction to SNMP:

See also the following Paessler White Papers:

Created on Jan 30, 2013 9:39:00 AM by  Gerald Schoch [Paessler Support]

Last change on Jan 29, 2018 2:21:58 PM by  Martina Wittmann [Paessler Support]



Your Vote:



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?


Created on Mar 31, 2015 9:30:09 PM by  Metuckness (0) 1



Your Vote:




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.

Created on Apr 2, 2015 2:56:38 PM by  Jochen Greger [Paessler Support]



Your Vote:



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.

Created on Feb 12, 2016 11:59:47 PM by  shanghaione (0)



Your Vote:



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.

Created on Sep 11, 2017 9:44:37 PM by  trevoc (0) 1

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.