NMS Cannot Receive SNMP Traps from an S Series Switch

This document describes how to troubleshoot the fault that a network management system (NMS) cannot receive Simple Network Management Protocol (SNMP) traps from a switch.

SNMP-enabled switches can proactively send traps to an NMS to notify alarms, clear alarms, and events.

The preceding figure shows the path along which a switch sends a trap to an NMS. If the NMS does not receive the trap, the trap may be lost on the switch, NMS, or the network between them.

This document applies to all versions of all S series switches. In the following troubleshooting procedures, eSight is used as the NMS and switches run V200R019C10.

The prerequisite for an NMS to receive SNMP traps from switches is that eSight has successfully managed switches. This document assumes that eSight has successfully managed switches.

A switch uses a randomly allocated port to send SNMP traps, and an NMS uses UDP port 162 to receive SNMP traps. If port 162 has been occupied by another software, the NMS cannot receive SNMP traps from the switch. eSight can be deployed on the Windows, SUSE Linux, and EulerOS operating systems. You can check whether UDP port 162 is occupied by another software based on the operating system used.

• Check whether UDP port 162 is occupied by another software on Windows.
  1. In the CLI window, run the netstat -aon | findstr 162 command to check the process identification (PID) corresponding to UDP port 162, which is 12884 in this example.

  2. In the Task Manager window, check the process name corresponding to the PID. If the process name is not java, port 162 is occupied by another software, instead of eSight.

  To rectify the fault, perform the following operations:

  In the Task Manager window on the Windows operating system, stop the process that occupies UDP port 162, and restart eSight.

• Check whether UDP port 162 is occupied by another software on SUSE Linux or EulerOS.

  On SUSE Linux and EulerOS, UDP port 162 is automatically mapped to port 10162. Therefore, you need to check whether port 10162 is occupied.

  1. Run the netstat –anp | grep 162 command to check the ID of the process that occupies the port.

  2. Run the ps aux | grep 7898 command to check the service name corresponding to the process ID. 7898 is the process ID obtained in the previous step.

     If the service name corresponding to the process ID is not eSight, the port is occupied by another service.

     To rectify the fault, perform the following operations:

     Run the kill -9 command to stop the process that occupies the port, and restart eSight.

A firewall discards all packets by default, and forwards only the packets permitted in a firewall policy. If no policy is configured for traps on the firewall, traps sent from switches cannot reach the NMS.

For example, the switch has the following configurations:

snmp-agent 
snmp-agent local-engineid 800007DB032CAB009815C0 
snmp-agent community read cipher %^%#*st8U]NHG)dZ.:T_Ys~N\](o8YsWU=k(5MGm87^/=<;#5gHcG2LBc(R*88.P#IkQ~-JR$STyAORB=(e=%^%# mib-view test
snmp-agent sys-info version all
snmp-agent target-host trap address udp-domain 10.10.10.10 params securityname cipher %^%#tRFS8{]e{AY=)C$50[hJ<!)Z5ZLU{BlJKh&Q2CE9%^%# v2c 
snmp-agent trap source LoopBack0  //The source address of traps sent from the switch is set to the IP address of loopback 0. 
snmp-agent trap enable 

When adding a policy for permitting traps on the firewall, pay attention to the following:

• The source IP address is the IP address of loopback 0 specified in the snmp-agent trap source command.
• The destination IP address is the NMS IP address specified in the snmp-agent target-host command.
• The service type is snmptrap.

Run the display trapbuffer command to check whether the trap buffer contains the corresponding trap. If not, the switch does not generate the trap. In this case, check configurations on the switch.

• Check whether the trap function is enabled

  based on the name of the module to which the trap belongs. For details about the module name, see Alarm Handling in the product documentation.

  For example, the trap name IFNET_1.3.6.1.6.3.1.1.5.3 linkDown shows that the interface Down trap belongs to the IFNET module. In this case, you can run the display snmp-agent trap feature-name ifnet all command to check whether the interface Down trap function is enabled according to the value of the linkDown field in the command output. If not, you can run the snmp-agent trap enable feature-name feature-name [ trap-name trap-name ] command to enable the alarm function for a specified module.

  <HUAWEI> display snmp-agent trap feature-name ifnet all 
  ------------------------------------------------------------------------------ 
  Feature name: IFNET 
  Trap number : 15 
  ------------------------------------------------------------------------------ 
  Trap name                    Default switch status   Current switch status  
  ... 
  linkDown                     off                     on   
  linkUp                           off                        on
  ...
  

• Check whether the conditions for triggering the trap on the switch are met.

  For example, a high CPU usage trap is generated only when the CPU usage of the switch exceeds the trap threshold. By default, the CPU usage trap threshold is 95%, and the threshold at which the trap is cleared is 80%. You can run the set cpu-usage threshold command on the switch to change the thresholds.

• Check whether the trap is filtered out.
  When the info-center filter-id bymodule-alias modname alias command is configured on the switch, the NMS cannot receive the trap even if the switch has generated the trap. For example, the interface Up and Down traps will be filtered out if the switch has the following configurations: In this case, you can run undo info-center filter-id bymodule-alias modname alias command to delete the trap filtering configuration.

  info-center filter-id bymodule-alias IFNET IF_LINKUP 
  info-center filter-id bymodule-alias IFNET IF_LINKDOWN 

SNMP is available in three versions: SNMPv1, SNMPv2c, and SNMPv3. The SNMP version configured for the target trap host (that is, the NMS) must be the same as that enabled for the switch. Otherwise, the NMS cannot receive traps from the switch. If no SNMP version is configured for the target trap host, it uses SNMPv1 by default.

snmp-agent
snmp-agent local-engineid 800007DB033400A3D84ECA
snmp-agent community read cipher %$%$S3Qp9LT`25*T=ZL=(vS$S!j.BEqp1C(ss;b28h37cb5V!j1Su-bH3)\,6V~*-5ASuvd9j:S!%$%$
snmp-agent community write cipher %$%$iwMf;[j>rA;F9*(:f^)RS!jScmYKI.u3h*bf[GJivizT!jVSa`E#BZ63XP+>&.'[+zwDj_S!%$%$
snmp-agent sys-info version v2c    //SNMPv2c is enabled for the switch. 
undo snmp-agent sys-info version v3
snmp-agent target-host trap address udp-domain 10.10.10.10 source Vlanif800 params securityname cipher %@%@%8$!GUNhxN'Db'VHj^6S*JOF%@%@  //No SNMP version is configured for the target trap host. Therefore, SNMPv1 is used by default. 
snmp-agent trap enable

Use either of the following methods to rectify the fault:

Method 1: Set the SNMP version to SNMPv2c for the target trap host.

snmp-agent target-host trap address udp-domain 10.10.10.10 source Vlanif800 params securityname cipher %@%@%8$!GUNhxN'Db'VHj^6S*JOF%@%@ v2c

Method 2: Enable SNMPv1 for the switch.

snmp-agent sys-info version v1

• S Series Switches Alarm Handling
• SNMP Configuration
• SNMP MIB
• SNMP OID