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.
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 to monitor important metrics 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 (identical SNMP version and community string). To learn how to set up SNMP on a specific device, search the internet for its name and SNMP configuration.
When you use a sensor with this technology, PRTG sends small data packets to a device, which in turn trigger reply packets. 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 target device. 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.
PRTG supports three versions of the SNMP protocol: version 1, 2c, and 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. SNMP v1 only supports 32-bit counters, which are not enough for high-load (gigabits/second) bandwidth monitoring.
This version adds 64-bit counters.
- Advantage: Supports 64-bit counters to monitor bandwidth usage in networks with gigabits/second loads.
- Disadvantage: Limited security (see SNMP v1).
This version adds authentication and encryption to SNMP.
- Advantage: Offers user accounts and authentication for multiple users and optional data packet encryption to increase available security. Has all advantages of SNMP v2c.
- Disadvantage: Difficult to configure and higher overhead for the probe, which reduces the number of devices that you can monitor (see SNMP Overload and Limitations of the SNMP System 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 address of the probe system to which you add the SNMP Trap Receiver sensor.
Which SNMP Version Should I Choose?
This 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, this also adds 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.
- If you have a lot of devices to monitor, SNMP v2c is preferable since it has a shorter scanning interval and supports 64-bit counters.
Make sure to set the same SNMP version in the PRTG settings (for example, in the root group settings) as in the target device. If you select an SNMP version that is not supported by the server or target device, you receive an error message. These error messages often do not explicitly say that you are using the wrong SNMP version and only provide minimum information, such as cannot connect. Similar errors occur when community strings, user names, 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.
Make sure that each target device supports SNMP, and that SNMP is enabled. You can find out whether a device supports SNMP by either going to the vendor’s website or checking that it is enabled in the configuration of the device.
If you are uncertain whether SNMP is enabled on the target device and works, we recommend that you try SNMP Tester. You can scan for uptime to perform a basic check for SNMP availability of the target device.
- Enable SNMP on the device.
- In the security settings of the device, allow SNMP access for the PRTG core server system.
- Allow User Datagram Protocol (UDP) packages to be sent bidirectionally from the PRTG core server to the device.
- SNMP requires the use of UDP ports >1023 to the PRTG client side. This is important for your firewall settings.
- Make sure that the firmware of the device is up to date.
- Select the appropriate SNMP protocol.
It is important to know which SNMP version you need to select, because if it is not supported by the server or device you want to monitor, you receive an error message.
For more information, see the Knowledge Base: My SNMP sensors don’t work. What can I do?
PRTG offers many vendor-specific SNMP sensors for some common vendors. These sensors are programmed to match the respective end devices. There are also workarounds for known vendor implementation issues, for example, if SNMP has not been fully implemented on an end device according to the RFCs. Here, our vendor-specific sensors still automatically receive the most important values.
PRTG offers several generic sensors that work with almost every device that supports SNMP, the corresponding Management Information Base (MIB) file and OIDs, and it correctly implements the respective RFCs. The standard SNMP libraries of PRTG include predefined, common values for the generic SNMP sensors. You can monitor the following parameters with the generic sensors.
PRTG also offers several operating system-based SNMP sensors that extend your SNMP monitoring. You can monitor the following parameters with these sensors.
PRTG also offers custom SNMP sensors. The monitoring capabilities of these sensors extend the scope of the generic sensors. With custom sensors, you can show certain values that are not included in the standard libraries of PRTG. With these sensors, you can monitor most devices that support SNMP and for which PRTG does not have native sensors. Basically, you only need to find out the required OIDs for the desired device readings, for example, in the vendor’s documentation for your hardware device.
For more information, see the Knowledge Base: How do I find out which OID I need for an SNMP Custom sensor?
How do SNMP, MIBs and OIDs work?
My SNMP sensors don’t work. What can I do?
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?
How can I import my MIB files into PRTG?
How do I find out which OID I need for an SNMP Custom sensor?
Can't find a sensor for my device in PRTG but I believe it supports SNMP. How to proceed?
MIB Importer and SNMP Tester
PAESSLER WHITE PAPER
Introducing SNMP and Putting SNMP into Practice