SNMP Doesn’t Work! Can Somebody Out There Please Help?!

 Originally published on August 23, 2017 by Martina Wittmann
Last updated on May 10, 2022 • 16 minute read

SNMP is the protocol you use to monitor your network? Good choice! However, it drives you crazy already while setting it up? Or have you finished setup and SNMP still doesn’t work? Or does SNMP seem to work but your network breaks down? Okay, I promise, you’re not alone! Take a deep breath and then check if you meet the following requirements.

Rescue in Sight

We gathered the most frequent problems that many customers who contacted our technical support had and decided to let you know.


iSNMP stands for Simple Network Monitoring Protocol. Its usefulness in network administration comes from the fact that it allows information to be collected about network-connected devices in a standardized way across a large variety of hardware and software types. SNMP is a protocol for management information transfer in networks, for use in LANs especially, depending on the chosen version. Read more ...


It may seem too obvious, but yes, sometimes the SNMP service has not been activated. Make sure SNMP is active on your target device(s). If you need help with the SNMP activation on common operating systems, see how you enable SNMP on Windows, Linux, or MacOS.



Check the machine running your monitoring tool. Is it allowed to send SNMP messages? The (Windows) firewall or other 3rd party firewall tools may be preventing the system from sending SNMP messages.

Also check the machine you're trying to monitor: Is it accepting SNMP requests?



Check your Access control list (ACL) and firewall regarding the ports and IPs you use. If certain ports are blocked, free the ports for SNMP, which is basically, port 161. Port 162 is used for traps, so keeping it open widens your monitoring possibilities. Find a list of the ports that Paessler PRTG monitoring software requires in our Knowledge Base.

 An Access List Example

ip access-list extended ABC-ACL

Permit udp X.X.0.0 eq snmp host SERVER_IP



Make sure that the SNMP versions of both (or all) your SNMP manager and agent(s) match. For example, if you use SNMP v3, select SNMP v3 as the active SNMP version on your target device (SNMP agent) as well as in your monitoring solution (SNMP manager). In LANs you can also use SNMP v2c. You could also use SNMP v1 but it’s not as reliable as v2c and should only be used as a “last resort”, for example, if your device only supports SNMP v1.


Check your SNMP credentials. An SNMP manager and an SNMP agent can only successfully transmit messages if the credentials match. In case of SNMP v1 and v2 (almost always v2c), you just have to check the community string. The community string is a kind of a password (sent, however, in clear text!) and is usually public by default. So try public at first. If the default community string has been changed, take the new one. If you use SNMP v3, there is a little more to check in the SNMP credentials. Make sure that the following SNMP v3 settings match in both your monitoring solution and on your device(s): the selected algorithm for authentication, the user name and password, the encryption type, and possibly the data encryption key and context name as far as you use them.

SNMP settings v2c.pngThat’s it! SNMP should now be activated and message transfer should work. Now setup or (fine) tune your monitoring. Your monitoring solution might help you build up the SNMP monitoring you want and need in your network. PRTG Network Monitor, for example, offers a list of various pre-defined sensors to monitor various devices via SNMP out of the box. Or, even more comfortable, let PRTG find out with the Smart Setup if it’s your first set up of PRTG, or with the auto-discovery function that you can start whenever you want. Maybe you’ll be surprised to see what things there are to monitor in your network you didn’t even know about!

If you feel that your SNMP monitoring is not complete, you might want to have a look at your devices’ Management Information Bases (MIBs).


Looking at a device’s MIB file(s) is the solution if you don’t get the data you want from it by default. Because an MIB file shows you in human readable form what a device supports, and hence, what information you could request using SNMP. Try it, although we admit that it is not so easy to read MIB files if you never have before. No idea of what MIB files are? Never mind (however, you should), we wrote a few words down for you.

ifPhysAddress OBJECT-TYPE

      SYNTAX PhysAddress

      ACCESS read-only

      STATUS mandatory


           "The interface address at the protocol layer

           immediately 'below' the network layer in the

           protocol stack. For interfaces which do not have

           such an address (e.g., a serial line), this object

           should contain an octet string of zero lenght"

      : := { ifEntry 6 }

The Monitoring Object ifPhysAddress in the IF-MIB (RFC1213)


And if you still think that your monitoring is not yet complete, find a native PRTG sensor that we developed for you, create your own (SNMP) custom sensor, or search our Sensor Hub

Great! You can now monitor everything that is monitorable.

Are there still some troublemakers left, like poor network performance or message loss?

Consider these hints:


SNMP is a low priority process on most devices. So under heavy load, they may drop the SNMP service and consequently, the SNMP messages you are waiting for will never arrive (and never be sent). On some devices, you may configure SNMP to be a higher priority service. If this is not possible, reduce the amount of SNMP queries, which in the case of PRTG means set higher scanning intervals and/or try to use fewer sensors.


Avoid overloaded links because they may cause SNMP messages to be dropped easily. That means that they are sent out but get lost somewhere in your network. The reason for this is that SNMP messages are based on the User Datagram Protocol (UDP), a protocol that creates sparse overhead but does not guarantee delivery of data packets.

2017-08-02 14_52_11-(063) To NUE-QSC-SW-01-Ten-GigabitEthernet1_0_43 Traffic _ Sensor Details _ PRTG.png


Using SNMP v3, the securest SNMP version so far, surely is a good plan. However, SNMP v3 can cause some overhead, making your network become paralyzed. If you’re working in a small LAN with physical security, you can usually change to SNMP v2c without bother. It will give the same good services and its sending passwords in plain text will not be an issue – especially if you work with read-only communities. If necessary, you may also change to SNMP v1, but then you’ll have to be okay with 32-bit counters and be aware that they may not be enoughfor GB/s traffic monitoring like saeed88 faced it.


Your monitoring tool at best supports a considerable number of SNMP requests recurring with a reasonable scanning interval on one machine. But if necessary, you can also distribute the monitoring load to more machines. This is possible, if your monitoring solution includes monitoring entities that work like separate but connected entities, as is the case with PRTG remote probes. Our manual describes how many SNMP sensors you can use on one or several machines.

We hope that our tips help you overcome the hurdle in your SNMP monitoring! And if not, get help in our Knowledge Base like JrTech did and explore our Resource Center. And, of course, you can still contact our technical support  – we’re glad to help!

New Horizons

Stay tuned on our SNMP blog series if at least one of the following questions has already crossed your mind: