No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

ME60 Troubleshooting Guide V1.0 (VRPv8)

This document provides the maintenance guide of the device, including daily maintenance, emergence maintenance, and typical troubleshooting.
Rate and give feedback :
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
SNMP Troubleshooting

SNMP Troubleshooting

This chapter describes common causes of SNMP faults, and provides the corresponding troubleshooting flowcharts, troubleshooting procedures, alarms, and logs.

An SNMP Connection Cannot Be Established

This chapter describes common causes of the fault that an SNMP connection cannot be established, and provides the corresponding troubleshooting flowcharts and examples.

Common Causes
SNMP connection cannot be established is commonly caused by one of the following:
  • Packets cannot be exchanged between the host and the NMS.

  • Configuration is incorrect.

Troubleshooting Flowchart
Figure 4-12 Troubleshooting flowchart for the fault that an SNMP connection cannot be established

Troubleshooting Procedure

Procedure

  1. Run the ping command to check whether the host and the NMS can successfully ping each other.

    • If the ping succeeds, it indicates that the host and the NMS are reachable. Go to Step 2.

    • If the ping fails, see The Ping Operation Fails to locate the problem so that the host and the NMS can ping each other.

  2. Run the display logbuffer command to check whether login failure logs exist on the host.

    • If no login failure log exists on the host, go to Step 3.

    • If login failure logs exist on the host, analyze the logs.

    Table 4-1 Log description and solution for the troubleshooting of an SNMP connection cannot be established
    Logs Description Solution
    Failed to login through SNMP (IPAddress=[STRING], Times=[INTEGER], CommunityName/UserName =[STRING], ReasonInfo =[STRING]) This event log occurs when the community name/user name is incorrect.

    Run the display snmp-agent community command to view the community string configured on the host.

    • If the community strings used by the NMS and the host are the same, go to Step 3.
    • If the community strings used by the NMS and the host are different, run the snmp-agent community command to configure a read-write community string on the host , which must be identical with the community string configured on the NMS.

      • If the fault is rectified, go to Step 4.
      • If the fault persists, go to Step 3.

    For SNMPv3, run the display snmp-agent usm-user command to view the user string configured on the host.

    • If the user strings used by the NMS and the host are the same, go to Step 3.
    • If the user strings used by the NMS and the host are different, run the snmp-agent usm-user command to add a user to an SNMP user group on the host, which must be identical with the user string configured on the NMS.
      • If the fault is rectified, go to Step 4.
      • If the fault persists, go to Step 3.
    Failed to login through SNMP. (IPAddress =[STRING], Times =[ULONG], CommunityName/UserName =[STRING], ReasonInfo =[STRING]) This event log occurs when SNMP agent rejects the login due to incorrectness in packet or version.

    Run the display snmp-agent sys-info version command to check whether the host supports the SNMP version used by the NMS to send login requests.

    • If the host supports the SNMP version, go to Step 3.
    • If the host does not support the SNMP version, run the snmp-agent sys-info version command to configure the SNMP version supported by the host.

      • If the fault is rectified, go to Step 4.
      • If the fault persists, go to Step 3.
    Failed to login through SNMP. (IPAddress =[STRING], Times =[ULONG], CommunityName/UserName =[STRING], ReasonInfo =[STRING]) ACL rules deny the connection request.

    Run the display acl command to view the ACL configuration on the host.

    • If the IP address from which the NMS sends login requests is permitted by the ACL, go to Step 3.
    • If the IP address from which the NMS sends login requests is denied by the ACL, run the rule command to enable the ACL to permit the IP address from which the NMS sends login requests.
      • If the fault is rectified, go to Step 4.
      • If the fault persists, go to Step 3.
    SNMP Operation failed. (IPAddress =[STRING], NodeName =[STRING], OperationType =[ULONG], RequestId =[ULONG], ErrorStatus =[ULONG], ErrorIndex =[ULONG], ReasonInfo =[STRING]) This event log occurs when SNMP agent fails to set/get/get next/get bulk operation. Please contact technical support personnel.

  3. If the fault persists, collect the following information and contact technical support personnel.

    • Results of the preceding troubleshooting procedures
    • Configuration files, log files, and alarm files of the devices

  4. End.
Relevant Alarms and Logs
Relevant Alarms

None.

Relevant Logs

AUTHENTICATION_FAILURE

SNMP_AUTHEN_FAILED

The NMS Fails to Receive Trap Messages from the Host

This chapter describes common causes of the fault that the NMS fails to receive trap messages from the Host, and provides the corresponding troubleshooting flowcharts and examples.

Common Causes
NMS fails to receive trap messages from the host is commonly caused by one of the following:
  • The trap message is lost.

  • The SNMP configuration on the host is incorrect. As a result, the host is unable to send trap messages.

  • No trap message is generated on the host-side service module.

  • The trap message is generated on the host-side service module, but the format of the trap messages is incorrect. As a result, the trap message cannot be sent.

Troubleshooting Flowchart
Figure 4-13 Troubleshooting flowchart for the fault that the NMS fails to receive trap messages from the host

Troubleshooting Procedure

Context

NOTE:

After the commands are configured to troubleshoot the faults, check the configuration validation mode to ensure that the configurations take effect. Unless otherwise specified, this manual defaults to immediate validation mode.

  • In immediate validation mode, the configurations take effect after the commands are entered.
  • In two-phase validation mode, after the commands are configured, the commit command needs to be run to commit the configurations.

Save the results of each troubleshooting step so that if your troubleshooting attempts fail to correct the fault, you will have a record of your actions to present to Huawei.

Procedure

  1. Check whether the SNMP configuration on the host is correct.

    • If the SNMP configuration is correct, go to Step 2.

    • If the SNMP configuration is incorrect, modify the configuration according to the following configuration cases.
      Table 4-2 Typical SNMP configurations
      Configuration Case Command
      Configure a host to run SNMPv2c and use default destination port 162. On the host, configure user name huawei and IP address 192.168.1.1, but do not configure VPN instances.
      NOTE:
      huawei must be an existing user name.
      <HUAWEI> system-view
      [~HUAWEI] snmp-agent target-host trap address udp-domain 192.168.1.1 params securityname huawei v2c
      Configure a host to run SNMPv2c and use default destination port 163. On the host, configure user name huawei and IP address 192.168.1.1 which belongs to the VPN instance VPN-TEST.
      NOTE:

      huawei must be an existing user name.

      VPN-TEST must be an existing VPN instance.

      <HUAWEI> system-view
      [~HUAWEI] snmp-agent target-host trap address udp-domain 192.168.1.1 udp-port 163 vpn-instance VPN-TEST params securityname huawei v2c
      Configure a host to run SNMPv3. On the host, configure user name huawei which belongs to user group huawei_group and has the trap rights (notify view) of Huawei_view.
      NOTE:

      Huawei_view allows the user to access all nodes from the iso subtree.

      huawei must be an existing user name.

      # Configure a MIB view.
      <HUAWEI> system-view
      [~HUAWEI] snmp-agent mib-view included Huawei_view iso
      # Configure a user group.
      [~HUAWEI] snmp-agent group v3 huawei_group privacy read-view Huawei_view write-view Huawei_view notify-view Huawei_view
      # Configure a user.
      [~HUAWEI] snmp-agent usm-user v3 huawei group huawei_group
      Configure a host to run SNMPv3 and use default port number 162. On the host, configure user name huawei and IP address 192.168.1.1, but do not configure VPN instances.
      NOTE:
      huawei must be an existing user name.
      <HUAWEI> system-view
      [~HUAWEI] snmp-agent target-host trap address udp-domain 192.168.1.1 params securityname huawei v3
      Configure a host to run SNMPv3 and use default port number 163. On the host, configure user name huawei and IP address 192.168.1.1 which belongs to the VPN instance VPN-TEST.
      NOTE:
      huawei must be an existing user name.

      VPN-TEST must be an existing VPN instance.

      <HUAWEI> system-view
      [~HUAWEI] snmp-agent target-host trap address udp-domain 192.168.1.1 udp-port 163 vpn-instance VPN-TEST params securityname huawei v3

  2. Run the display current-configuration | include snmp-agent command to check whether the trap function is enabled on all feature modules.

    • If the trap function is not enabled on all feature modules, go to Step 3.

    • If the trap function is enabled on all feature modules, go to Step 4.

  3. Run the snmp-agent trap enable command to enable the host to send trap messages and configure parameters for trap messages.

    • If the NMS can receive trap messages from the host, go to Step 7.

    • If the NMS fails to receive trap messages from the host, go to Step 4.

  4. Run the display logbuffer command to check whether login failure logs exist on the host.

    Table 4-3 Description of SNMP login failure logs and Solutions to the failure
    Logs Description Solution
    SNMP agent failed to send Notification. (IPAddress =[STRING], NotificationName =[STRING], AlarmID = [ULONG], NotificationQueueLength =[ULONG], ReasonInfo =[STRING])
    1. The SNMP agent failed to send trap messages due to insufficient buffer space, short of Variable Bindings (VBs) or too many VBs.
    2. The SNMP agent did not receive ACK in response to the Inform message.
    Please contact technical support personnel.
    NOTE:
    The log message indicating that a specific trap is generated is as follows:
    2011-01-13 23:47:09 HUAWEI %%01cfg/6/CONFIG_CHANGE_TRAP(l):CID=2160787468;Co
    nfigure changed. (LogIndex=1, SrcCmd=1, SrcData=3, DestData=2, TerUser="anonymou
    s", SrcAddr=0.0.0.0, ConfigChangeId=16, LogTime=58318668, CfgBaselineTime="2011-
    1-7 5:47:25")
    • If the log message indicating that a trap message is generated does not exist on the host, go to Step 6.
    • If the log message indicating that a trap message is generated exists on the host, but the NMS failed to receive it, go to Step 5.

  5. Run the snmp-agent target-host inform command to configure the SNMP agent to send an Inform message.

    NOTE:
    Trap messages are transmitted using UDP which is an unreliable transmission. Trap messages may be lost on the link. Inform mechanism ensures that trap messages are sent in a reliable manner. For configuration details, see "SNMP Configuration" in the HUAWEI ME60 Configuration Guide System Management.
    • If the NMS can receive trap messages sent by the host, go to Step 7.

    • If the NMS fails to receive trap messages sent by the host, go to Step 6.

  6. Collect the following information and contact technical support personnel.

    • Results of the preceding troubleshooting procedures
    • Configuration files, log files, and alarm files of the devices

  7. End.
Relevant Alarms and Logs
Relevant Alarms

None.

Relevant Logs

None

Translation
Download
Updated: 2019-06-11

Document ID: EDOC1000175918

Views: 4620

Downloads: 208

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next