This article describes the step by step troubleshooting procedure to correctly configure the community format on NMS.
SNMP polling from NMS was not working. The following error was reported in the snmpd log:
Apr 16 13:55:15 SNMPD_AUTH_FAILURE: nsa_initial_embedcomm: unauthorized SNMP community from 10.1.55.12 to unknown community name (TM*itd#3)
Step 1: Monitored SNMP Statistics
> show snmp statistics extensive SNMP statistics: Input: Packets: 8637132, Bad versions: 0, Bad community names: 90, Bad community uses: 61453, ASN parse errors: 0, Too bigs: 0, No such names: 0, Bad values: 0, Read onlys: 0, General errors: 0, Total request varbinds: 45492258, Total set varbinds: 0, Get requests: 8566436, Get nexts: 420, Set requests: 0, Get responses: 0, Traps: 0, Silent drops: 0, Proxy drops: 0, Commit pending drops: 0, Throttle drops: 0, Duplicate request drops: 0 V3 Input: Unknown security models: 0, Invalid messages: 0 Unknown pdu handlers: 0, Unavailable contexts: 0 Unknown contexts: 0, Unsupported security levels: 0 Not in time windows: 0, Unknown user names: 0 Unknown engine ids: 0, Wrong digests: 0, Decryption errors: 0 Output: Packets: 8575589, Too bigs: 0, No such names: 0, Bad values: 0, General errors: 0, Get requests: 0, Get nexts: 0, Set requests: 0, Get responses: 8575589, Traps: 0 SA Control Blocks: Total: 8203981, Currently Active: 0, Max Active: 20, Not found: 0, Timed Out: 0, Max Latency: 1 SA Registration: Registers: 0, Deregisters: 0, Removes: 0 Trap Queue Stats: Current queued: 0, Total queued: 0, Discards: 0, Overflows: 0 Trap Throttle Stats: Current throttled: 0, Throttles needed: 0 Snmp Set Stats: Commit pending failures: 0, Config lock failures: 0 Rpc failures: 0, Journal write failures: 0 Mgd connect failures: 0, General commit failures: 0
Step 2: Checked the syslog:
> show log messages | no-more Mar 20 20:03:03 R01-KCH snmpd[1547]: SNMPD_SEND_FAILURE: jnx_netsnmp_udp_send: send message (10.1.55.12) failure: No route to host Mar 20 20:03:15 R01-KCH last message repeated 2 times Mar 20 20:08:01 R01-KCH snmpd[1547]: SNMPD_SEND_FAILURE: jnx_netsnmp_udp_send: send message (10.1.55.12) failure: No route to host Mar 20 20:08:13 R01-KCH last message repeated 2 times ......
Step 3: Asked customer to check whether there was a route issue between DUT and NMS (10.1.55.12). The customer confirmed that they were able to ping the NMS:
> ping routing-instance ITDNET 10.1.55.12 PING 10.1.55.12 (10.1.55.12): 56 data bytes 64 bytes from 10.1.55.12: icmp_seq=0 ttl=253 time=32.238 ms 64 bytes from 10.1.55.12: icmp_seq=1 ttl=253 time=54.464 ms 64 bytes from 10.1.55.12: icmp_seq=2 ttl=253 time=31.084 ms 64 bytes from 10.1.55.12: icmp_seq=3 ttl=253 time=53.418 ms ^C --- 10.1.55.12 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 31.084/42.801/54.464/11.154 ms
Step 4: The check above indicated that the NMS was located behind the CE (VRF) network. In this case, two more configurations options MUST be deployed:
community
routing-instance@community
Step 5: Enabled the traceoption for SNMP and then checked the snmpd log:
NMS from in the routing-instance (e.g. VRF CE network) was using the normal community format.
Change made to the NMS using the routing-instance@community format like ITDNET@TM*itd#3 allowed the SNMP polling to work properly.
ITDNET@TM*itd#3