PRTG Manual: Monitoring via SNMP
Monitoring via the Simple Network Management Protocol (SNMP) is the most basic method of gathering bandwidth and network usage data.
Simple Network Management Protocol (SNMP) is a set of standards for communication with devices in a Transmission Control Protocol (TCP)/IP network. SNMP monitoring is useful if you are responsible for servers and network devices such as hosts, routers, hubs, and switches. It enables you to keep an eye on network and bandwidth usage, and monitor important issues such as uptime and traffic levels.
You can use SNMP to monitor the bandwidth usage of routers and switches on a port-by-port basis, as well as device readings such as memory and CPU load. The target devices must support SNMP. Most devices with enabled SNMP require the same configuration like SNMP version and community string. To find out how to set up SNMP on a specific device, search the internet for your device name or model and SNMP configuration.
When you use a sensor with this technology, PRTG sends small data packets to devices, for example, querying routers, switches, and servers for the traffic counters of each port. These queries trigger reply packets from the device. Compared to other bandwidth monitoring technologies via World Wide Name (WWN), packet sniffing, or Windows Management Instrumentation (WMI), the SNMP option creates the least CPU and network load.
SNMP is the most commonly used method because it requires minimal bandwidth and CPU cycles. If your network devices support SNMP and/or if you want to monitor large networks with several hundred or thousands of sensors, we recommend that you start with SNMP.
Besides network usage monitoring, another well-known feature of SNMP is the ability to also monitor other network parameters such as CPU load, disk usage, temperature, as well as many other readings, depending on the queried device.
To use SNMP for monitoring purposes, it is necessary that User Datagram Protocol (UDP) packets can be bidirectionally sent from the PRTG core server to the device that you want to monitor. This is usually the case in LANs and intranets. For connections across the internet, to a perimeter network (also known as DMZ, demilitarized zone, and screened subnet), or for WAN connections, some changes to the traversed firewalls might be necessary.
Keep in mind that SNMP v1 and v2c are no secure protocols, so you should not use them on the internet or with data connections that are not secure. Only SNMP v3 supports encryption.
To better understand and set up SNMP sensors, you might want to learn more about the principles of object identifiers (OID) and Management Information Base (MIB) files.
For more information about this topic, see the Knowledge Base: How do SNMP, MIBs, and OIDs work?
For an overview and details about all SNMP sensors, see section List of Available Sensor Types.
For more information about which SNMP sensor is best for your monitoring setup, see section Choosing the Right SNMP Sensor.
PRTG supports three versions of the Simple Network Management Protocol (SNMP) protocol: version 1, version 2c, and version 3.
This is the oldest and most basic version of SNMP.
- Pro: Supported by most SNMP-compatible devices.
- Con: Limited security because it only uses a simple password (community string) and sends data in clear text (unencrypted). Because of this, you should only use it inside LANs behind firewalls, but not in WANs. Version 1 only supports 32-bit counters, which are not enough for high-load (gigabits/second) bandwidth monitoring.
This version adds 64-bit counters.
- Pro: Supports 64-bit counters to monitor bandwidth usage in networks with gigabits/second loads.
- Con: Limited security (same as with SNMP v1).
This version adds authentication and encryption to SNMP.
- Pro: Offers user accounts and authentication for multiple users and optional data packet encryption to increase the available security, and has all advantages of Version 2c in addition.
- Con: Difficult to configure and higher overhead for the probe, which reduces the number of devices that you can monitor (see here for more information).
Various devices can send SNMP trap messages to notify you of system events.
- PRTG supports SNMP v1 and SNMP v2c traps.
- The destination for SNMP traps is the IP address of the trap receiver, which is the IP of the probe system to which you add the SNMP Trap Receiver sensor.
Which SNMP Version Should I Choose?
The SNMP version you should choose depends on your environment. Here are some guidelines:
- If your network is publicly accessible, you might want to use SNMP v3, which has encryption and secure access. However, security and encryption add overhead, which results in less performance.
- If your network is isolated or well-protected behind firewalls, the lower security level of SNMP v1 or SNMP v2c might be sufficient.
- From the perspective of monitoring with PRTG, SNMP v2c is preferable if you have a lot of devices to monitor. This lets you monitor more devices with a shorter scanning interval, and it supports 64-bit counters.
The most important aspect is to set the same SNMP version in the PRTG settings (for example, in the root group settings) as you have configured in your target device. If you select an SNMP version that is not supported by the server or device that you want to monitor, you receive an error message. Unfortunately, these error messages, in most cases, do not explicitly point to the possibility that you are using the incorrect SNMP version. These messages provide minimum information only, such as cannot connect. Similar errors occur when community strings, usernames, or passwords do not match.
For more information about basic requirements for SNMP monitoring, see this Knowledge Base article: My SNMP sensors don't work. What can I do?
SNMP v1 and v2 scale directly with the performance of the hardware and the speed of the network. In our labs, we can monitor 30,000 SNMP v1 sensors in a 60-second scanning interval with one PRTG core server (and local probe) plus two remote probes with 10,000 sensors each.
SNMP v3 has performance limitations because of the use of encryption. Furthermore, keep in mind that SNMP v3, unlike SNMP v1 and v2c, does not scale with more CPU power. Because of this limitation, PRTG can only handle a limited number of requests per second so that you can use only a limited number of sensors using SNMP v3.
Furthermore, the PRTG core server and probes should run on different computers. If you experience increased values in the Interval Delay SNMP or Open Requests channels of the Probe Health sensor (values above 0 % indicate that the SNMP requests cannot be performed at the desired interval), you need to distribute the load among probes. SNMP v1 and v2 do not have this limitation.
If you run into SNMP overload problems, you have the following options:
- Increase the scanning interval of the SNMP v3 sensors.
- Distribute the SNMP v3 sensors among two or more probes.
- Evenly distribute the SNMP v3 sensors on your devices (about 10 to 100 sensors per device).
- Check if your target devices answer fast enough. Performance issues might also result from slow SNMP v3 devices.
- Switch to SNMP v1 or v2 if you can go without encryption.
The SNMP community string is similar to a user ID or password that allows access to the statistics of a device. PRTG sends the community string along with all SNMP requests. If the correct community string is provided, the device responds with the requested information. If the community string is incorrect, the device discards the request and does not respond.
SNMP community strings are only used by devices that support SNMP v1 and SNMP v2c. SNMP v3 uses safer user name/password authentication, along with an encryption key.
By convention, most SNMP v1/v2c equipment ships with a read-only community string set to the value public. It is standard practice for network managers to change all the community strings to customized values during device setup.
How do SNMP, MIBs, and OIDs work?
My SNMP sensors don't work. What can I do?
What SNMP sensors does PRTG offer?
The interface numbers on my switch keep changing. What can I do?
What can I check if SNMP and SSH sensors throw timeout and auth errors?
What can I monitor with the SNMP Custom Table sensor?
MIB Importer and SNMP Tester
PAESSLER WHITE PAPER
Introducing SNMP and Putting SNMP into Practice