Support Support Downloads Knowledge Base Service Request 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

[EX] NMS server unable to get SNMP information from EX switch

0

0

Article ID: KB30188 KB Last Updated: 05 Mar 2017Version: 2.0
Summary:

This article is a troubleshooting guide for users unable to obtain information from an EX switch via SNMP.

Symptoms:

SNMP is a protocol used for monitoring networking devices. When setting up SNMP version 1, 2c, or 3, users may encounter issues obtaining the desired information. This article suggests some steps to take to see if SNMP information is arriving at the NMS server.


Solution:

There are two different main communication methods between an SNMP server (manager) and a switch (agent):

  • SNMP polling: (manager to agent) NMS server requests information from the device. Default port is UDP 161.
  • SNMP traps and informs: (agent to manager) Agent device, in this case the EX switch, sends SNMP information to the NMS server upon specific events. The switch forwards such information without the NMS server requesting it (asynchronous). Similar to syslogs, SNMP traps and informs allow the device to notify the management station of significant events by sending unsolicited messages.

SNMP polling troubleshooting

  1. Make sure SNMP requests are arriving at the EX switch.
  2. Regardless of the SNMP version being used, for a device to respond with SNMP information it first needs to receive a request from the management station. Such a request may arrive in the form of the following PDU:

    • GetRequest
    • GetNextRequest
    • GetBulkRequest

    There is also a SetRequest, but set operations are not supported by Junos OS at the present time.

    You can use different tools to check if SNMP traffic is arriving to the switch, such as firewall eters or traffic monitoring (SNMP traffic destined for the switch is exception traffic). However, the most accurate way is to enable SNMP traceoptions:

    show configuration snmp | find traceoptions
    traceoptions {
                 flag all;
                 }

    After traceoptions are enabled, reproduce the issue and then check the file located under /var/log. A correct transaction should look like this:

    root> show log snmpd
    Feb 18 21:45:25 snmpd[642b] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    Feb 18 21:45:25 snmpd[642b] >>> Get-Next-Request
    Feb 18 21:45:25 snmpd[642b] >>> Source: 172.22.198.70
    Feb 18 21:45:25 snmpd[642b] >>> Destination: 172.22.201.169
    Feb 18 21:45:25 snmpd[642b] >>> Version: SNMPv2
    Feb 18 21:45:25 snmpd[642b] >>> Request_id: 0x642b
    Feb 18 21:45:25 snmpd[642b] >>> Community: public
    Feb 18 21:45:25 snmpd[642b] >>> Error: status=0 / vb_index=0
    Feb 18 21:45:25 snmpd[642b] >>> OID : sysObjectID
    Feb 18 21:45:25 snmpd[642b] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

    Feb 18 21:45:25 snmpd[642b] <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
    Feb 18 21:45:25 snmpd[642b] <<< Get-Response
    Feb 18 21:45:25 snmpd[642b] <<< Source: 172.22.201.169
    Feb 18 21:45:25 snmpd[642b] <<< Destination: 172.22.198.70
    Feb 18 21:45:25 snmpd[642b] <<< Version: SNMPv2
    Feb 18 21:45:25 snmpd[642b] <<< Request_id: 0x642b
    Feb 18 21:45:25 snmpd[642b] <<< Community: public
    Feb 18 21:45:25 snmpd[642b] <<< Error: status=0 / vb_index=0
    Feb 18 21:45:25 snmpd[642b] <<< OID : sysObjectID.0
    Feb 18 21:45:25 snmpd[642b] <<< type : Object
    Feb 18 21:45:25 snmpd[642b] <<< value: jnxProductNameEX9208
    Feb 18 21:45:25 snmpd[642b] <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
    snmpd[642c] <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

    root>

    Notice that the debug output shows us the source and destination of the packet, as well as the version. It is important to view the request ID, since the response packet will have the same request ID. This is how we know that the switch is properly responding to the packets. Also notice that the request packet has the OID that is being requested and the response packet has a proper value for such OID. In our example the NMS server (172.22.198.70) requested the OID sysObjectID, and the device (172.22.201.169) replied with the proper value jnxProductNameEX9208.

    In situations where SNMP packets are not arriving at the switch, the error seen on the server should be "No Response". For example:

    C:\usr\bin>snmpwalk -v 2c -c public 172.22.201.179 ifTable
    Timeout: No Response from 172.22.201.179

    C:\usr\bin>

  3. SNMP manager polls the EX switch, and packets arrive at the switch; however, the switch does not respond with the desired information.
  4. Juniper EX switches will reply to SNMP request packets only if the credentials match. SNMP v1 and v2c uses a community string for authentication. SNMPv3 uses the USM model, where username and passwords replace the community string role. Encryption is also added.

    Device config:

    root@> show configuration snmp
    community public;
    traceoptions {
    flag all;
    }

    root@>

    In the debug output, you can see packets arriving but the NMS server still receives no SNMP information:

    Feb 19 17:49:09 snmpd[490e] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    Feb 19 17:49:09 snmpd[490e] >>> Get-Next-Request
    Feb 19 17:49:09 snmpd[490e] >>> Source: 172.22.198.70
    Feb 19 17:49:09 snmpd[490e] >>> Destination: 172.22.201.169
    Feb 19 17:49:09 snmpd[490e] >>> Version: SNMPv2
    Feb 19 17:49:09 snmpd[490e] >>> Request_id: 0x490e
    Feb 19 17:49:09 snmpd[490e] >>> Community: Public
    Feb 19 17:49:09 snmpd[490e] >>> Error: status=0 / vb_index=0
    Feb 19 17:49:09 snmpd[490e] >>> OID : sysObjectID
    Feb 19 17:49:09 snmpd[490e] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    Feb 19 17:49:09 SNMPD_AUTH_FAILURE: nsa_log_community: unauthorized SNMP community from 172.22.198.70 to 172.22.201.169 (Public)

    root@IO-re0>

    Notice that the SNMP community listed in the 'Get-next-Request' is "Public", but the device was configured with a community string of "public". SNMP credentials are case sensitive, so these credentials do not match. It is also not recommended to use special characters on your community strings, especially the "@" symbol, as it might cause SNMP community string indexing issues.

  5. Make sure the source IP address of the SNMP request is a valid and permitted one.
  6. You can restrict polling of SNMP information to defined IP addresses by using a config file such as:

    community v6tyo4Dyr7Tq2009ro {
    authorization read-only;
    client-list-name MGMT-SNMP;
    ----

    prefix-list MGMT-SNMP {
    10.20.64.0/32;

    Make sure the source IP address is permitted on the list.

SNMP trap troubleshooting

A customer reports that SNMP traps are not being generated by the device upon configured events.

  1. Make sure that the proper SNMP category is enabled for the problematic event.
  2. For example if a link is going down but customer is not getting a trap for such event, make sure that linkDown traps are enabled:

    root@IO-re0# set trap-group TRAPS categories ?
    Possible completions:
    + apply-groups Groups from which to inherit configuration data
    + apply-groups-except Don't inherit configuration data from these groups
    authentication Authentication failures
    chassis Chassis or environment notifications
    configuration Configuration notifications
    link Link up-down transitions
    > otn-alarms OTN alarm trap subcategories
    remote-operations Remote operations
    rmon-alarm RMON rising and falling alarms
    routing Routing protocol notifications
    services Services notifications
    > sonet-alarms SONET alarm trap subcategories
    startup System warm and cold starts
    vrrp-events VRRP notifications
    [edit snmp]
    root@IO-re0# set trap-group TRAPS categories
    >
  3. If the proper categories are enabled but customer is still not getting the trap, enable traceoptions and then generate a spoof trap using the request snmp spoof-trap linkDown command.
  4. If not configured, SNMP traps will use the IP address of the exiting interfaces as the source IP address of the SNMP traps.
  5. This may cause routing issues or packet blocking if the server is not expecting traffic from that source. To avoid such issues, Juniper recommends hard-coding the IP address to be used as source of SNMP traps. You can configure the source-address, routing-instance, or logical-instance name for the source IP address using the trap-options command:

    root@> show snmp trap-options

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

Security Alerts and Vulnerabilities

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