Support Support Downloads Knowledge Base Case Manager My Juniper Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[M Series] SNMP polling failure due to community format misconfiguration on NMS

0

0

Article ID: KB23548 KB Last Updated: 20 May 2013Version: 2.0
Summary:
This article describes the step by step troubleshooting procedure to correctly configure the community format on NMS.

Symptoms:

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)


Below are the troubleshooting steps used to isolate the problem:

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


The above output showed SNMP daemon worked perfect.

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:

1) Enable SNMP access over routing Instances
2) Specify a Routing Instance in an SNMPv1 or SNMPv2c Community

Note: On the NMS side, the community or routing-instance@community format may be configured.

SNMP polling may still have an issue after adding the two options above.

Step 5: Enabled the traceoption for SNMP and then checked the snmpd log:

[edit snmp]
set traceoptions flag all;

> show log snmpd | no-more 
......
Apr 16 13:55:15 snmpd[2a232c] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Apr 16 13:55:15 snmpd[2a232c] >>> Get-Request
Apr 16 13:55:15 snmpd[2a232c] >>> Source: 10.1.55.12
Apr 16 13:55:15 snmpd[2a232c] >>> Destination: 192.168.40.3
Apr 16 13:55:15 snmpd[2a232c] >>> Version: SNMPv1
Apr 16 13:55:15 snmpd[2a232c] >>> Request_id: 0x2a232c
Apr 16 13:55:15 snmpd[2a232c] >>> Community: TM*itd#3
Apr 16 13:55:15 snmpd[2a232c] >>> Error: status=0 / vb_index=0
Apr 16 13:55:15 snmpd[2a232c] >>> OID : sysUpTime.0
Apr 16 13:55:15 snmpd[2a232c] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
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)
.....


This snmpd log clearly showed that the NMS was using the community format, NOT routing-instance@community which is required for SNMP polling from in the routing-instance.

Cause:

NMS from in the routing-instance (e.g. VRF CE network) was using the normal community format.


Solution:

Change made to the NMS using the routing-instance@community format like ITDNET@TM*itd#3 allowed the SNMP polling to work properly.



Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search