This knowledge base article describes a scenario where an NMS is unable to receive SNMP traps from a device, despite having a known working configuration that functions correctly on other devices. The article outlines how to troubleshoot the issue step by step and isolate the root cause.

• The same configuration is working on other devices, and the NMS is successfully receiving traps from them. 
• SNMP traffic routed through the "mgmt_junos" routing instance is functioning correctly, ICMP works towards the NMS.
• We confirmed that SNMP traps are being sent via the management port when monitoring the traffic interface. However, the following logs appear on the device:

SNMPD_SEND_FAILURE: trap_io_send_trap_now: send to (ip-addr) failure: No route to host

Below is the config of the SNMP:

set groups SNMP snmp v3 vacm access group NMS_1 default-context-prefix security-model any security-level privacy read-view all

set groups SNMP snmp v3 vacm access group NMS_1 default-context-prefix security-model any security-level privacy notify-view all

set groups SNMP snmp v3 target-address NMS_1 address 192.168.100.10

set groups SNMP snmp v3 target-address NMS_1 port 162

set groups SNMP snmp v3 target-address NMS_1 tag-list TAG-PFMS

set groups SNMP snmp v3 target-address NMS_1 routing-instance mgmt_junos

set groups SNMP snmp v3 target-address NMS_1 target-parameters NMS_1

set groups SNMP snmp v3 target-parameters NMS-PA parameters message-processing-model v3

set groups SNMP snmp v3 target-parameters NMS-PA parameters security-model usm

set groups SNMP snmp v3 target-parameters NMS-PA parameters security-level privacy

set groups SNMP snmp v3 target-parameters NMS-PA parameters security-name pandora

set groups SNMP snmp v3 target-parameters NMS-PA notify-filter TRAPS-PFMS

set groups SNMP snmp v3 notify NOTIFY-PFMS type trap

set groups SNMP snmp v3 notify NOTIFY-PFMS tag NMS_1

set groups SNMP snmp v3 notify-filter TRAPS oid 1.3.6.1.4.1.2636.4.1 include

set groups SNMP snmp v3 notify-filter TRAPS oid 1.3.6.1.4.1.2636.4.2 include

set groups SNMP snmp v3 notify-filter TRAPS oid 1.3.6.1.6.3.1.1.5 include

set groups SNMP snmp v3 notify-filter TRAPS oid 1.3.6.1.2.1.15.7 include

set groups SNMP snmp v3 notify-filter TRAPS oid 1.3.6.1.4.1.2636.5.3.1.0 include

set groups SNMP snmp v3 notify-filter TRAPS oid 1.3.6.1.4.1.2636.4.14.0 include

set groups SNMP snmp v3 notify-filter TRAPS oid 1.3.6.1.2.1.118.0 include

set groups SNMP snmp v3 management-routing-instance mgmt_junos

set groups SNMP snmp engine-id use-mac-address

set groups SNMP snmp view all oid .1

set groups SNMP snmp routing-instance-access access-list mgmt_junos

set groups NMS snmp trap-group NMS targets 192.168.100.10

Following logs were seen:

SNMPD_SEND_FAILURE: trap_io_send_trap_now: send to (ip-addr) failure: No route to host

The "> show route" output shows that the route to the NMS IP is via the "mgmt_junos":

root@user> show route 192.168.100.10

mgmt_junos.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

0.0.0.0/0     *[Static/5] 30w0d 09:32:52

          > to 10.10.10.1 via em0.0

We have reachability towards the NMS:

root@user> ping routing-instance mgmt_junos 192.168.100.10

PING 192.168.100.10 (192.168.100.10): 56 data bytes

64 bytes from 192.168.100.10: icmp_seq=0 ttl=54 time=5.102 ms

64 bytes from 192.168.100.10: icmp_seq=1 ttl=54 time=6.047 ms

64 bytes from 192.168.100.10: icmp_seq=2 ttl=54 time=5.311 ms

64 bytes from 192.168.100.10: icmp_seq=3 ttl=54 time=5.163 ms

If connectivity to the NMS is confirmed, proceed to generate SNMP traps using the command "> request snmp spoof-trap <>"  for multiple OIDs. Then, monitor the egress interfaces to verify that the trap packets are being sent out:

root@user> monitor traffic interface em0 no-resolve matching "udp port 162" layer2-headers 

verbose output suppressed, use <detail> or <extensive> for full protocol decode

Address resolution is OFF.

Listening on em0, capture size 96 bytes

23:07:03.406210 Out aa:bb:cc:dd:ee:20 > aa:bb:cc:dd:ee:10, ethertype IPv4 (0x0800), length 74: truncated-ip - 224 bytes missing! 10.10.10.20.51311 > 192.168.100.10.162: F=ap [|snmp][|snmp]

23:07:07.989156 Out aa:bb:cc:dd:ee:20 aa:bb:cc:dd:ee:10, ethertype IPv4 (0x0800), length 74: truncated-ip - 224 bytes missing! 10.10.10.20.51311 > 192.168.100.10.162: F=ap [|snmp][|snmp]

23:08:22.715242 Out aa:bb:cc:dd:ee:20 > aa:bb:cc:dd:ee:10, ethertype IPv4 (0x0800), length 74: truncated-ip - 201 bytes missing! 10.10.10.20.51311 > 192.168.100.10.162: F=ap [|snmp][|snmp]

23:08:24.939059 Out aa:bb:cc:dd:ee:20 > aa:bb:cc:dd:ee:10, ethertype IPv4 (0x0800), length 74: truncated-ip - 224 bytes missing! 10.10.10.20.51311 > 192.168.100.10.162: F=ap [|snmp][|snmp]

23:08:27.513429 Out aa:bb:cc:dd:ee:20 > aa:bb:cc:dd:ee:10, ethertype IPv4 (0x0800), length 74: truncated-ip - 224 bytes missing! 10.10.10.20.51311 > 192.168.100.10.162: F=ap [|snmp][|snmp]

We observed traffic leaving the management interface. Since the NMS was not receiving traps from the switch, the next step was to verify connectivity hop by hop to determine if traffic was being dropped along the path. Alternatively, a packet capture (PCAP) could be taken on the ingress side of the NMS to confirm whether the traps were arriving.

In this case, we confirmed that traffic was reaching the NMS; however, a configuration issue on their side prevented proper processing. Once the SNMP tool configuration was corrected, the issue was resolved.