This article is a troubleshooting guide for users unable to obtain information from an EX switch via SNMP.
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.
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
- Make sure SNMP requests are arriving at the EX switch.
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:
GetRequestGetNextRequestGetBulkRequest
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] <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
{MASTER}
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>
- SNMP manager polls the EX switch, and packets arrive at the switch; however, the switch does not respond with the desired information.
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;
}
{MASTER}
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)
{MASTER}
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.
- Make sure the source IP address of the SNMP request is a valid and permitted one.
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.
- Make sure that the proper SNMP category is enabled for the problematic event.
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
{MASTER}[edit snmp]
root@IO-re0# set trap-group TRAPS categories
> - 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. - If not configured, SNMP traps will use the IP address of the exiting interfaces as the source IP address of the SNMP traps.
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;