Simple Network Management Protocol (SNMP) traps are messages sent by SNMP devices that notify network monitoring systems about device events or significant status changes.
At LogicMonitor, our view on SNMP has evolved over the years. While we have often favored other logging methods that offered more insights and were considered easier to analyze in the past, we recognize that SNMP traps remain an essential tool in network management.
For network engineers, SNMP traps deliver real-time alerts faster than other methods, ensuring you’re the first to know when critical network events occur. They also provide specific, actionable data that can only be captured through traps, helping you quickly isolate issues and reduce downtime.
And it’s our mission to ensure our customers have all the necessary—and best—tools to solve their problems, no matter the technology. Mature techology =/= obsolete or ineffective.
So, let’s look at SNMP traps and how your organization can leverage them to monitor your IT infrastructure.
SNMP traps vs. SNMP polling
SNMP polling is similar to SNMP traps in that it allows you to collect information about a device’s status and store it in a monitoring server. The difference between the two is the way information is sent.
SNMP traps work on an event-based model. When a pre-defined event occurs, it immediately sends a trap message to the designated receivers. On the other hand, SNMP polling mechanisms work with the monitoring server actively requesting information from SNMP agents.
Using SNMP traps offers you many advantages over polling:
- Get real-time notifications to learn the moment an event occurs
- Reduced network overhead by only sending messages when events occur
- Quickly catch issues that may get missed by intermittent problems
Depending on your organization’s needs, there are also some drawbacks to using SNMP traps, some of which include:
- Notifications may be lost during transit since they are sent using User Datagram Protocol (UDP—a fast, connectionless communication method that sends data without guaranteeing delivery, often used in real-time applications)
- Setting up individual devices to send traps may be more complex if setting up more than one trap instead of just starting an SNMP agent to accept polling, but this isn’t always the case
- It may miss the broader context regular polling provides (if not using a combination of trapping and polling) because traps only send point-in-time information
Despite those challenges, you can still use SNMP traps to get information about your infrastructure. We offer LM Logs as part of the Envision platform. LM Logs provides many features that help IT teams manage SNMP traps, such as:
- Sending traps to the collector to gather and Map Management Information Base (MIB) data
- Uploading proprietary and/or custom MIB definitions to expand translation capabilities
- Automatically translating object identifier (OID) and Varbind (Variable Bindings) information into human-readable labels to focus on finding issues
- Using advanced anomaly detection features to remove the noise and surface only the most important traps
- Utilize stateful alerting to automatically close alerts that receive an indication that the error status doesn’t exist anymore to reduce the number of alerts
Detailed mechanism of SNMP traps
Several components make up SNMP traps:
- SNMP agent: Software running on monitored devices that generate and send SNMP trap messages
- SNMP manager: Systems that receive and parse SNMP trap information
- Management Information Base (MIB): Database defining the structure and meaning of trap information
- Network Management System (NMS): The overall system responsible for monitoring and managing network devices, including routers, servers, and switches.
The other critical part of SNMP traps is how the data is stored. This happens through OIDs. By default, SNMP agents come with default OIDs from the built-in traps. However, you may also create custom OIDs or download pre-built ones from device vendors to upload to your monitoring solution.
You must also consider how SNMP traps are submitted. They use single UDP packets for transmissions, meaning delivery isn’t guaranteed. You can minimize some of this risk by putting the device and collector as close together as possible on the network.
When using SNMP traps, you’ll need to weigh the benefits of lower overhead against the risk of missed deliveries. Although polling may provide data at a delayed rate, combining it with traps will ensure you don’t miss any critical alerts.
Types of SNMP traps
Several SNMP traps are available, from standard to enterprise-specific and custom traps.
Let’s look at some common traps available:
- coldStart: Indicates system reinitiation itself with potential configuration changes
- warmStart: Indicates system reinitiation without configuration changes
- linkDown: Indicates a communication link failure
- linkUp: Indicates a communication link was restored
- authenticationFailure: Indicates an authentication request failure
- egpNeighborLoss: Indicates an EGP neighbor loss
You can create custom traps if your organization needs more from SNMP traps. To do this, you would download the proprietary MIB files from your vendors (or create a custom one if you have more specific needs). You can then upload your custom MIB file to your monitoring solution so it can translate the data.
Through this, you can define custom traps to look for events such as CPU utilization and memory usage. You can also define custom alerting behavior based on specific conditions using LogSources and Pipelines to get notified about the alerts that matter most—as well as define custom “stateful” behaviors to remove alerts that aren’t relevant anymore. Example: “alert on Link Down, but close the alert if/when you get a Link Up for the same interface.”
The good thing about collecting this information using traps (as opposed to polling) is that it’s less resource-intensive on networks, as businesses only get the alerts they’re looking for instead of constantly polling devices—something especially important in large environments.
It also offers alerts when they matter the most—when a device problem occurs. This helps teams find issues immediately instead of only learning about problems when a device is polled.
Configuring SNMP traps
Configuring SNMP traps involves configuring individual devices to trigger SNMP traps and send them to the Collector. Follow the general steps below to start with the configuration:
- Access the device configuration to enable the SNMP agent
- Configure the trap destination by inputting the IP address or DNS of the trap receivers
- Study vendor documentation for proprietary OIDs to learn the available traps and upload them to your Collector
- Define the trap types by selecting the events that trigger traps and send data to the receivers
- Set community strings for trap configuration (authentication strings, port numbers, and engine ID)
- Test the configuration to ensure traps work properly
This can get your organization set up with a basic configuration. However, a few advanced tips are available that will help optimize your SNMP traps:
- Send all traps available to a monitoring server and filter everything not required
- Collect MIB information from proprietary vendors to get comprehensive insights into enterprise environments
- Use a DNS name instead of an IP address to avoid misconfiguration when IP addresses change
- Avoid sending traps across the NAT or the internet to avoid packet loss with UDP packets
- Use the default LogSource when possible and add customization when you need custom behavior
Monitoring and managing SNMP traps
SNMP traps can gather a lot of information, but as your network environment grows, you may start gathering a lot of information and need a way to filter down to the most important data.
This requires strong SNMP trap monitoring and management.
It comes down to two things: interpreting trap messages to respond effectively and automating alerting.
- Interpreting trap messages: Properly define source devices, event types, and associated data. Filter messages to surface trap information that indicates problems that IT teams should respond to—avoiding time wasted looking through irrelevant data.
- Automation: Automatically filter information based on the above criteria and use reporting tools to send it to the appropriate party for resolution—ensuring engineers only see the information they should act on.
You can use tools such as the ones we offer at LogicMonitor with LM Logs to improve the management of SNMP traps as part of a hybrid observability solution (for legacy on-prem and cloud infrastructure and services). LogicMonitor Envision provides several features to make management easier:
- Automatic ingestion, parsing, and mapping SNMP traps as logs to read OIDs in a human-readable format and streamline their management
- Automatic translation of OIDs and their data to remove the need for you to manually decode them, helping you quickly learn what potential problems the data shows
- Store historical data to get the historical context of SNMP logs—along with other data—to perform historical analysis and find trends
- Automatic anomaly detection using AI-powered features to help automatically surface the SNMP trap data that matters and helps you save time
- Integrate with SNMP polling to get faster notifications and maximum visibility
- Link SNMP trap information with other data within LM Envision to help correlate potential issues with other data
Best practices for SNMP trap management
With so much data available with SMP traps, your organization can employ best practices to help streamline operations. Use the following tips to practice efficient SNMP management:
- Centralize management: Centralize the collection of SNMP traps using monitoring software (like LM Logs) to streamline management
- Filter traps: Use filters using your management software to eliminate traps you aren’t interested in
- Complete visibility: Collect as much information as possible to get complete visibility on a network
- Integrate with other tools: Use SNMP trap data in other tools to get a more comprehensive view of your IT infrastructure instead of only using SNMP trap information
- Automate where possible: Avoid manual work wherever possible by automating alerts and OID translation
Challenges, best practices, and troubleshooting in SNMP trap management
Although several challenges are associated with SNMP traps, there are ways you can mitigate those challenges to ensure you get the information you need.
Let’s look at a few common challenges and the best practices to overcome them.
Missed traps
Since SNMP uses UDP for transmission, traps can be lost in transmission. Consider using SNMP inform messages or app-level acknowledgments to ensure the trap receiver sees all traps. These will help agents determine if a trap message was successfully sent. Also, try to avoid sending traps across network address translations (NATs) and network boundaries to reduce the chance of packet loss.
Some traps have thresholds that trigger an alert. If a device isn’t configured properly, it won’t send an alert to you. When setting up traps, audit devices to ensure proper configuration and test devices where possible to see if traps trigger.
False positives
Traps provide a lot of information—and not all of it is relevant to finding and fixing IT problems. You may miss the important alerts if you look at all this data. Regularly review any false positives triggered and put filters in place to remove them from regular alerts—reducing alert fatigue and allowing you and your team to focus on real problems.
Security concerns
Traps can potentially expose sensitive information if not properly secured. Ensure your organization uses the latest SNMP (SNMPv3) version and implements encryption, complex community strings, Access Control Lists (ACLs), and trusted IP addresses. Implementing a regular audit of SNMP traffic can help identify anomalies.
Troubleshooting SNMP problems
Troubleshooting SNMP issues comes down to ensuring traps are generated when necessary and make their way to the trap receiver. Here’s some steps you can leverage to identify potential SNMP problems:
- Verify trap generation to ensure the target devices are correctly configured
- Check network connectivity to look for network issues that may impact transmission
- Validate trap receiver configuration to ensure traps go to the right place
- Analyze trap content to ensure it contains the correct information
- Review MIB files to ensure they are updated to the latest versions from the vendors
Advanced topics in SNMP traps
Understanding where SNMP came from and other advanced topics will help you learn what it’s about and how it helps.
The evolution of SNMP
SNMP started with SNMPv1 in the 1980s. It started simple with limited features, but it lacked security features, making it a problem for businesses. Over time, the SNMPv2 protocol was released, and it came with manager-manager communication and enhanced security. It greatly expanded the amount of data available to be received on a single request, giving organizations more flexibility in how they use the protocol.
However, one of the biggest challenges with SNMPv2 was that the security amounted to nothing more than a password, which is where SNMPv3 comes in. SNMPv3 is the latest and most secure version. It includes authentication and encryption, ensuring that you and your team are the only people able to view trap data.
SNMP trap storms
SNMP trap storms occur when the number of traps received from a specific device reaches a specific threshold. Trap storms can indicate network outages, device misconfiguration, or cascading failures.
Trap storms can lead to network problems because of the overwhelming amount of bandwidth used on a network. They are also a sign that a more serious problem may need to be addressed immediately.
Your organization can address trap storms in several ways:
- Implement rate limiting to stop irrelevant traps
- Filter data to avoid unwanted traps
- Aggregate data to group similar traps in single alerts
Using SNMP traps with other protocols
SNMP traps provide a lot of data, but they’re only a piece of the puzzle when looking at a network in its entirety. Integrating them with other protocols like syslog and Netflow can offer more comprehensive visibility into IT infrastructure.
For example, Netflow tells businesses a lot about how data flows on a network—something SNMP doesn’t. Your organization can use the two protocols together to learn about what happens on devices and how devices interact with each other.
The same is true with syslogs. SNMP may tell you when something goes wrong on a device—but it may not give any details about more specific application errors. Looking at syslogs can give more details that SNMP doesn’t to help troubleshoot and fix problems.
SNMP traps are a mechanism a device uses to send information about device events. It’s a data collection mechanism that helps you and your team learn if anything important happens to their infrastructure.
SNMP informs require a response from other SNMP agents they communicate with. They expect a response from the other agent upon receipt of a message, which helps agents determine if a trap was successfully sent. These are good to use in cases when reliability is critical, and the information sent is vital to operations.
Wrapping up
As we’ve outlined, SNMP traps can be a useful tool, especially when combined with Logs. LogicMonitor has evolved our perspective, thanks to customers’ input to provide the best tool for the job. SNMP traps and LM logs offer the best of both worlds, giving IT teams actionable insights and helping them troubleshoot critical infrastructure problems. Using traps and polls together provides a comprehensive solution for network monitoring and helps teams ensure their infrastructure stays online.
Mike Rodrigues is a tech leader with 15+ years in IT. He's passionate about helping organizations streamline their IT ecosystems to achieve mission-driven success, using observability tools that deliver predictive insights and actionable data. His expertise spans across network management, cloud services, and automation, making him a trusted advisor for staying ahead in IT.
Disclaimer: The views expressed on this blog are those of the author and do not necessarily reflect the views of LogicMonitor or its affiliates.
