Check out our White Paper Series!
A complete library of helpful advice and survival guides for every aspect of system monitoring and control.
1-800-693-0351
Have a specific question? Ask our team of expert engineers and get a specific answer!
Sign up for the next DPS Factory Training!
Whether you're new to our equipment or you've used it for years, DPS factory training is the best way to get more from your monitoring.
Reserve Your Seat TodaySimple Network Monitoring Protocol (SNMP) is one of the most used communication protocols when it comes to managing a network. Although it stands for "simple", many people disagree with that. Maybe it was simple in the late '80s when this protocol became standard for network monitoring. However, that was a long time ago, and just like any other technology, SNMP evolved.
Now, for many network techs, implementing SNMP is not easy and can be a hassle.
At DPS, our experts help many clients achieve a smooth SNMP implementation. We provide user-friendly devices and efficient tech support, as well as training. For us, it's important that you are able to work with SNMP and get the most out of your monitoring system.
So, to help you through the process of implementing SNMP in your network, we'll go over what SNMP is exactly and the challenges you may expect when using it to monitor your remote sites. The main goal here is for you to learn the industry's best practices when it comes to implementing SNMP monitoring.
SNMP is an application-layer protocol that involves a manager device and an agent device.
The SNMP agent is usually an RTU deployed at a remote equipment site. It will collect performance information about the monitored devices and will send all the data to your SNMP manager.
The SNMP manager can be software installed on a general-purpose computer or be a purpose-built device (that's the best practice in terms of security and reliability). The manager will receive the data the agent collects and provide you with an interface for your network where you can, at the most basic level, manage and control remote devices.
The communication between the agent and manager devices happens over the UDP protocol.
There are two ways that SNMP monitors your remote sites - traps and polling.
The information that the SNMP agent gathers and sends to the manager can be related to many things, such as environmental conditions, equipment malfunction or failure, battery levels, or even building access. Each piece of data is considered an object and is referenced using a unique object identifier (OID).
An OID is a long string of digits, separated by dots, just like an IP address. This is called dot notation.
Each OID is organized hierarchically in a management information base (MIB). Think of a MIB as a database of all the OIDs and their associated names and definitions. It forms a hierarchical structure resembling a tree that you must travel through in order to get the data you want for a determined object.
The SNMP standard defines "public" MIBs that each device should gather, such as network interfaces with the IF-MIB. There are also "private" MIBs that manufacturers can add to their devices that go beyond the standard. This allows them to expose additional information about their devices that are useful in SNMP monitoring.
When you want to receive alerts about network issues, you can use SNMP trap messages. This means that an SNMP-enabled RTU or equipment can notify your purpose-built manager when certain levels are below or above the set thresholds.
Your SNMP-enabled RTU could be configured to send traps to your master each time a particular threshold is crossed. But, you probably won't be sitting in front of your computer in your office 24/7 just to watch if any traps are coming in.
Also, your network probably has many more RTUs monitoring multiple other devices. If so, you need an efficient master station to receive and view all your trap messages. If so, you need to invest in a tool like T/Mon LNX. With it, you'd be able to see all the traps sent by your RTUs in a user-friendly web interface.
Once you have all this trap data in your T/Mon, you can do things such as generating alerts to ensure you're aware of issues on your network. And you'll be able to filter nuisance alarms, so you can be alerted only when real issues happen, avoiding an overload of alerts.
Operating a remote network can come with many frustrating problems, implementing SNMP can be one of them. Here are some of the challenges that it's important to keep in mind:
SNMP has three main versions: SNMPv1, SNMPv2c, and SNMPv3. The earlier versions (v1 and v2c) present security issues because, as its most basic level, all you need to query an SNMP-enabled device is a community string. The community string is your password.
Not only is a single password insecure and not the best practice, v1 and v2c send it in cleartext. This is not very secure and hackers wouldn't need much effort to break into your network.
To solve this issue, SNMPv3 was introduced with authentication and encryption features.
The SNMP MIBs are extensive, depending on the equipment you have. Because of that, on many devices, SNMP is a low-priority process. This means that, under heavy load, your SNMP queries may get dropped. Also, when you configure traps, the device may not send them during extra load due to its low priority.
To avoid that, you can adjust the priority level in some devices, but this may have adverse performance effects. It's always important to run tests first.
SNMP is a standard protocol for monitoring solutions, but its success depends directly on your system's manufacturer. Depending on the vendor and their devices, they may choose to implement SNMP a different way than the RFC. This may lead to SNMP responding slowly.
The RFC MIB is a basic dictionary of terms that manufacturers utilize to write their own equipment-specific MIBs. A vendor-created MIB doesn't have to define the entire OID tree. The vendor's MIB file only has to define the unique OIDs that describe the vendor's gear.
Also, be careful where you enable SNMP. On highly available systems, you may want to think twice about enabling SNMP or make sure you've thoroughly tested how your devices behave under SNMP polling.
If you are thinking about using SNMP to monitor your remote equipment and processes, the challenges above are just a small example of the things to be aware of. There are many best practices to keep in mind when implementing SNMP monitoring. Some of them include:
SNMPv3 has authentication with MD5 or SHA-1, which can be considered insecure. To help minimize the chances of a network attack due to the insecurity of MD5 and SHA-1, it's recommended you use different passwords for authentication and encryption.
Some organizations still use the same password for both, but if you do this you're only setting yourself up for failure.
Sometimes network operators simply enable SNMP and start polling their devices. Although this makes things "simple", you leave the default settings, which are often the read-only and read-write community strings. They are usually "public" and "private", respectively.
It's OK to not change your community strings if you're only testing the feature. However, when you implement SNMP and start monitoring your network with it, not changing the default string is a recipe for disaster.
To mitigate security threats, change the community strings from the factory default. You can also invest in SNMPv3-enabled devices, this way you'll have to create a username and password.
If you can't use SNMPv3, it's important to use complex community strings. Whatever rules your company has for user passwords, use them for your strings as well. The best practice is to make sure your strings include at least 20 characters and different types of characters, such as numbers and letters.
If possible, utilize a separate management subnet for your SNMP monitoring. At DPS, we often see that SNMP is the dominant source of network traffic at some companies. This can create unnecessary traffic that your infrastructure and employees have to deal with.
Don't let SNMP traffic affect your network's efficiency. When you use a separate management network, it provides the added benefit of protecting your information against possible security risks as well.
To maximize the efficiency of your monitoring system, you should consider using only one tool to collect SNMP data. Some companies use one tool for monitoring, another for configuration, and even a third for equipment control. This can be problematic because the more devices you have, the more security risks they can bring into your network.
T/Mon LNX is a multiprotocol, multifunction single-platform solution for all remote alarm monitoring uses. It will collect alarm monitoring data from multiple different devices from multiple different manufacturers.
T/Mon is a cost-effective way to reduce costs and to achieve visibility over your remote sites. This is because between other capabilities, T/Mon is able to:
Implementing and working with SNMP nowadays may not be as simple as it once was. However, it's important to know how to properly use it in order to achieve complete visibility over your remote sites.
And visibility is precisely the main goal of remote monitoring systems - through real-time information you'll have a complete picture about what's going on in your network.
As experts in remote monitoring solutions, we know that the SNMP protocol can be a powerful tool to leverage your bottom line. That's why we aim to provide intuitive and user-friendly devices so SNMP monitoring will not be a hassle for you.
Don't get caught off guard by failing to monitor your network, reach out to us today.
Morgana Siggins
Morgana Siggins is a marketing writer, content creator, and documentation specialist at DPS Telecom. She has created over 200 blog articles and videos sharing her years of experience in the remote monitoring industry.
