# SNMP Traps Troubleshooting Guide **URL:** \ **Category:** Troubleshooting\ **Tags:** snmp-trap, troubleshooting-guide, extensions\ **Created:** [July 30, 2025, 10:46am UTC](https://community.dynatrace.com/t/snmp-traps-troubleshooting-guide/52694 "2025-07-30T10:46:29Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![maciej-tokarz](https://avatars.discourse-cdn.com/v4/letter/m/54ee81/32.png) [@maciej-tokarz](https://community.dynatrace.com/u/maciej-tokarz)\ **Post date:** [July 30, 2025, 10:46am UTC](https://community.dynatrace.com/t/snmp-traps-troubleshooting-guide/52694/1 "2025-07-30T10:46:29Z")
# Summary This troubleshooting article will help you resolve some common issues faced while installing and setting up SNMP trap-based extensions. # **Things to know** SNMP Traps (com.dynatrace.extension.snmp-traps-generic) is a special extension that generates Log Events based on the captured traps in the network. It also produces single metric **com.dynatrace.extension.snmp-traps-generic.traps.count** that is number of captured traps in the interval. SNMP Traps extensions use _datasource_ that binds to and listens on the configured UDP port. Incoming packets are filtered by the configured IP address and mask. Finally, the packets are verified against provided credentials (v1, v2c, or v3). If there were no errors along the way, the Log Events should be visible in the Logs screen. ![maciejtokarz_0-1753790650397.png](https://global.discourse-cdn.com/dynatrace/original/2X/7/7b6ab85512a286d9e8fb0b8fe35f18a519e90312.png) ## **Where to look for symptoms?**   Specific symptoms mentioned in this article can be seen in the Extensions app/Extension page in the Dynatrace Hub and file logs. Here is how you can find them. **SFM logs** SFM logs are available in the health tab on the Extension page in the Extensions app or on Extension page in the Dynatrace Hub. Log files can be found in the paths: - Linux ActiveGate: /var/lib/dynatrace/remotepluginmodule/log/extensions/datasources/\ - Windows ActiveGate: %PROGRAMDATA%/dynatrace/remotepluginmodule/log/extensions/datasources/\ - Generated support archive from the ActiveGate ([How to collect a Support Archive)](https://community.dynatrace.com/topic/252022): /remotepluginmodule/log/extensions/datasources/\ # **Problems** ## **No Traps count metric nor(or) trap Log Events** ### **Troubleshooting** - Verify the result of metric **dsfm:server.metrics.rejections**. Common cause of issue are exhausted DDUs. - Verify the result of metric **dsfm:extension.engine.logs\_ingest.records\_rejected**. - Check Logs limits in the Dynatrace environment. - Investigate **snmptraps** _datasource_ and _Extensions Execution Controller_ logs. ## **Traps count metrics is non-zero but trap Log Events are missing** ### **Troubleshooting** - Verify the result of metric **dsfm:extension.engine.logs\_ingest.records\_rejected**. - Check Logs limits in the Dynatrace environment. - Make sure you use the latest version of SNMP Traps extension and have **Events** feature set enabled. ## **Traps count metric is zero and trap Log Events are missing** There can be multiple reasons that can cause metrics and trap LogEvents to not show up. Listed below are some common causes - ### **Rejected Metrics** #### **Troubleshooting** Verify the result of metric **dsfm:server.metrics.rejections**. Common cause of issue are exhausted DDUs. ![maciejtokarz_0-1753791397426.png](https://global.discourse-cdn.com/dynatrace/original/3X/f/4/f4ba0ac1f8e029049686fb4eac28d9374c7b8c90.png) ### **Rejected Logs** #### **Troubleshooting** - Verify the result of metric **dsfm:extension.engine.logs\_ingest.records\_rejected**. - Split the metric on the log source and see if the traps are in there. ### **Monitoring Configuration is in Pending status** #### **Troubleshooting** For SNMP Traps extension, due to the “reverse” function of the data source listening rather than making requests, the EEC status for the extension is not set by using a fastcheck. The monitoring configuration will stay pending until an ActiveGate in the configured AG group has received the configuration, which can take a few minutes. If the monitoring configuration is still in pending state after approximately 10 minutes or so, the issue may be related to the Extension Execution Controller (EEC) or something on the ActiveGate blocking the extension from running properly. #### **Solution** Generate a support archive from the relevant ActiveGate and review the EEC and SNMP Traps-based extension logs. ### **Verify Network Connectivity** #### **Troubleshooting** First, verify that there is network connectivity from the device that is sending the SNMP Traps to the ActiveGate that is running the SNMP Traps extension using curl with the telnet protocol. The default port for receiving SNMP Traps is port 162, however, different ports can be used. ```markup curl telnet://:162 ``` If the curl from the SNMP-enabled device fails, there may be an intermediate network device, such as a firewall, blocking the traffic between the SNMP-enabled device and the AG, or potentially a missing network route between subnets. ### **Wrong IP net address** #### **Troubleshooting** This error occurs when a monitoring configuration has been set with an IP address that does not follow [CIDR Notation](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing), if targeting traps from a single host, /32 must be added to meet the requirements. i.e. 10.126.240.38/32. ```markup [ds:snmptraps] [severe] [INVALID_CONFIG_ERROR] Wrong ip net address 10.126.240.38 [status code=32] ``` #### **Solution** Use a correct IP address/Mask. ### **Verify SNMP Trap source IP included in address space** #### **Troubleshooting** Each monitoring configuration for an SNMP Traps extension has a field that configures the IP address space in CIDR Notation that expected SNMP Traps will be received from, sometimes it may be a /32 listing for a single host up to /8 for an entire class A private network full of IP addresses. If you are unfamiliar with the process of calculating subnets and determining the IP addresses that would be contained in the address space, a subnetting calculator tool can be utilized to determine the valid IP range. For example, this [subnet calculator](https://www.calculator.net/ip-subnet-calculator.html) that takes the input of the subnet mask and an IP address and provides the network address and usable IP range among additional details. **Input** ![maciejtokarz_0-1753792926698.png](https://global.discourse-cdn.com/dynatrace/original/2X/f/f48d2f0992a27bd8b5f69c74c2dd21fd7f71a7e4.png) **Output** ![maciejtokarz_1-1753792956531.png](https://global.discourse-cdn.com/dynatrace/original/2X/c/c38cdcfb2cf5494438272a4023acadc36adb11cc.png) **Notice:** The IP address/Mask used in the extension monitoring configuration must match the source IP address of the packet that the datasource ‘sees’ - therefore, if a proxy is used, the extension monitoring configuration must be configured with the IP address/Mask that includes the proxying service IP address. ### **Verify that the SNMP Traps datasource is listening on the port** #### **Troubleshooting** If an SNMP trap listener is already running on the same host and using port 162, the SNMP Traps extension will not be able to bind to that port, preventing it from receiving SNMP traps properly. Utilize the command below to output the ports that the host is listening on and review the output to determine if port 162 or the port in the monitoring configuration is actively being listened on by a process other than the ActiveGate/EEC. The below commands aim to filter the listening processes to target the specific process of the SNMP Traps datasource. - **Linux:** - **Windows:** **Notice:** Depending on the OS, datasource might not report any issue with port binding even if it’s already used by another program. Effectively it will bind to the port, but traps would reach the other program that had bound to port in the first place. ### Authentication Error #### Troubleshooting Check the correctness of the authentication parameters and try to manually enter them in the extension monitoring configuration. Compare the authentication parameters from the extension monitoring configuration with the trap sender authentication settings (they should be the same). Avoid using special characters (@ $ # % etc.). Pay attention to smallest details e.g. usage of AES256C instead of AES256. Verify that environment is configured according to [documentation](https://docs.dynatrace.com/docs/extend-dynatrace/extensions20/data-sources/snmp-extensions/snmptraps-extensions#snmp-traps-data-source). ### Verify that traps reach the host that runs the extension #### Troubleshooting - It can be done with tcpdump tool or Wireshark. ### Verify firewall, SELinux or similar tools settings #### Troubleshooting Even if the packets reach the host running extension, firewall or similar tools might still block _datasource_ from getting the traps. _This is very common issue and it is being frequently overlooked by a customer._ - Review the firewall settings and make sure that the incoming traffic is allowed on the specified port and there are no rules that block it. - Review the SELinux settings, and make sure that **dynatracesourcesnmp** is allowed (or not blocked) to bind to ports lower than 1024.  **Notice** : In case SELinux here is the command that you can use to see if UDP traffic on port 162 is allowed **semanage port -l | grep http\_port**. If there is no rule for UDP on port 162 then you can add this by calling this command: **semanage port -a -t http\_port\_t -p udp** **162**. - As an additional test, configure SNMP Traps to listen on higher port like **9162** and try sending traps on that port. If traps are received, that means the problem still lies somewhere in the customer’s environment. ### Send traps manually #### Troubleshooting If the SNMP trap provider doesn’t produces ones all the time. Use snmptrap tool or any of your choice. It is worth collecting network packets when sending SNMP traps. This can help investigate the issue and confirm that the trap has reached the desired host. ```markup tcpdump -i eth0 -w output.pcap ``` ## Device name is coming as Device IP ### Troubleshooting Verify resolving the raw IP to the DNS name from the host where the extension monitoring configuration works. ```markup nslookup ``` **Notice:** The SNMP traps datasource needs at least two traps with the same address to send the resolved IP. Resolving raw IP to DNS name is running in parallel to avoid blocking the sending of traps and improve performance. ## MIBs issues ### Troubleshooting The SNMP traps data source uses a default set of MIB files. You can also extend the default set with your own files. There are often issues with loading MIBs and translating OIDs based on the MIB files [SNMP traps data source — Dynatrace Docs](https://docs.dynatrace.com/docs/ingest-from/extensions20/data-sources/snmp-extensions/snmptraps-extensions#mib-files). - Verify if the traps are translated after changing the SNMP version. For example, from SNMP v1 to SNMP v2c. It can mean that the MIB module cannot support all SNMP versions, and an updated MIB file is required. - Verify **NOTIFICATION-TYPE** in the MIB file. Some vendor’s MIB modules, and even some RFCs, defined a NOTIFICATION-TYPE with a parent of zero but without an object name for that zero, which results in incorrect MIB resolution by our SNMP traps datasource. More information can be found at the link [https://www.ibm.com/docs/en/netcoolomnibus/8.1.0?topic=snmp-mib-object-types#omn\_ref\_mib\_mibobjects\_\_title\_\_6.For](https://www.ibm.com/docs/en/netcoolomnibus/8.1.0?topic=snmp-mib-object-types#omn_ref_mib_mibobjects __title__ 6.For) example: - At the start of the mib, this is defined. - Then there is some kind of overlap. Potential solution: Try to manually updating mib file to change **::= { netapp 0 x}** to  **::= { netapp0 x}** or remove all ‘0’ in all objects (expect for netapp0). - Verify if in the MIB file in the fragment **DEFINITIONS ::= BEGIN** , there are **excessive whitespaces** in between **::=** and **BEGIN** and there should be only a **single space**. - Check MIB files defines the names from the ROOT, otherwise OIDs are not resolved correctly. - SmiType is nil - it is common warning log `SmiType is nil. Module name `, if the warning in the log file doesn’t lead to a missing OID name resolution, it can be discarded. It occurs, because SmiType is verified to be non-nil before parsing. Potential causes: - SYNTAX clause of a Textual Convention can refer to a previously defined Textual Convention (RFC 2579). - MIB object does not define a type (syntax). ![maciejtokarz_5-1756906881086.png](https://global.discourse-cdn.com/dynatrace/original/2X/2/2db3852e4999316fa04382adc89d64281eb6ec9d.png) # SNMP Traps DataSource related knowledge ## Useful links - [SNMP traps data source](https://docs.dynatrace.com/docs/ingest-from/extensions20/data-sources/snmp-extensions/snmptraps-extensions) - official documentation for SNMP traps data source - [Custom MIB files](https://docs.dynatrace.com/docs/ingest-from/extensions20/data-sources/snmp-extensions/snmp-schema-reference#add-your-own-mib-file) - official documentation how to add custom MIB files. - [Dynatrace HUB](https://www.dynatrace.com/hub/) - all released extensions, where you can download and gain more information about them - [Extensions 2.0](https://www.dynatrace.com/support/help/extend-dynatrace/extensions20/) - what are extensions 2.0 - [Custom Extensions Creator](https://www.dynatrace.com/hub/detail/custom-extensions-creator/) - create custom extension directly on the Dynatrace web UI - [Signing extensions](https://www.dynatrace.com/support/help/extend-dynatrace/extensions20/sign-extension/) - how to sing an extension - [Dt-CLI usage](https://github.com/dynatrace-oss/dt-cli) # What’s next If none of the solutions above has worked for you and you are still experiencing issues with the SNMP Traps extension you are trying to configure there’s always a chance that there is a problem with the extension itself or the underlying data source. In that case feel free to open a support ticket specifying: - A description of the problem - A list of troubleshooting steps that have been performed - Logs from the ActiveGate - support\_archive.zip ([How to collect a Support Archive](https://community.dynatrace.com/topic/252022)) - Working link to the environment - Dynatrace version - ActiveGate version - Extensions Module version - Monitoring configuration ID/name - Screens from the UI where the problem is visible (e.g., monitoring configuration error, errors in log monitoring, data gaps, or lack of data on the dashboard/data explorer) - If it’s a custom extension please provide the extension YAML or ZIP file - TCP dump (recorded communication between ActiveGate and SNMP trap provider) If this article has helped you and provided you with valuable insight, please give it a thumbs-up (kudos). ---
**Author:** ![AntonPineiro](https://dub1.discourse-cdn.com/dynatrace/user_avatar/community.dynatrace.com/antonpineiro/32/49_2.png) [@AntonPineiro](https://community.dynatrace.com/u/AntonPineiro)\ **Post date:** [July 30, 2025, 11:41am UTC](https://community.dynatrace.com/t/snmp-traps-troubleshooting-guide/52694/2 "2025-07-30T11:41:30Z")
Thank you! :money\_mouth\_face: ---
**Author:** ![AntonioSousa](https://dub1.discourse-cdn.com/dynatrace/user_avatar/community.dynatrace.com/antoniosousa/32/50_2.png) [@AntonioSousa](https://community.dynatrace.com/u/AntonioSousa)\ **Post date:** [July 30, 2025, 1:12pm UTC](https://community.dynatrace.com/t/snmp-traps-troubleshooting-guide/52694/3 "2025-07-30T13:12:17Z")
[@maciej-tokarz](https://community.dynatrace.com/user/64155) , Congratulations for this excellent article! I’m a heavy user of traps, in several clients, and wasn’t expecting to learn anything, but I did! Some notes: - Traps are typically UDP/162, so a telnet curl might not work, but traps still get through - I normally do the tcpdump with a filter for the specific SNMP traps port, as you might have much more traffic in the AG server: ```markup tcpdump -i eth0 -w output.pcap​ udp port 162 ``` ---
**Author:** ![Romanenkov\_Al3x](https://dub1.discourse-cdn.com/dynatrace/user_avatar/community.dynatrace.com/romanenkov_al3x/32/36257_2.png) [@Romanenkov\_Al3x](https://community.dynatrace.com/u/Romanenkov_Al3x)\ **Post date:** [August 26, 2025, 7:46am UTC](https://community.dynatrace.com/t/snmp-traps-troubleshooting-guide/52694/4 "2025-08-26T07:46:07Z")
Thanks for sharing. Helpful. ---
**Author:** ![fstekelenburg](https://dub1.discourse-cdn.com/dynatrace/user_avatar/community.dynatrace.com/fstekelenburg/32/22029_2.png) [@fstekelenburg](https://community.dynatrace.com/u/fstekelenburg)\ **Post date:** [January 27, 2026, 4:22pm UTC](https://community.dynatrace.com/t/snmp-traps-troubleshooting-guide/52694/5 "2026-01-27T16:22:12Z")
When running with firewalld on Linux (RH9) make sure the **snmptrap** is loaded as **service**. (service snmp does not apply to traps) **# cat /usr/lib/firewalld/services/snmptrap.xml** \ \ \SNMPTRAP\ \SNMP traps enable an agent to notify the management station of significant events by way of an unsolicited SNMP message.\ \ \ \ **# firewall-cmd --info-service=snmp** snmp   ports: 161/tcp 161/udp   protocols:   source-ports:   modules:   destination:   includes:   helpers: