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).
IP Forwarding Troubleshooting

IP Forwarding Troubleshooting

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

The Ping Operation Fails

This chapter describes common causes of the Ping operation fails, and provides the corresponding troubleshooting flowcharts and examples.

Common Causes

If the source end does not receive a response to its Request packet from the destination end within a specified period, the ping operation fails.

This fault commonly results from one of the following causes:

  • The link transmission delay is too long. Therefore, if the source end does not receive a Response packet from the destination end within the waiting time, the ping operation fails.

  • Improper configurations exist. For example, packet fragmentation is not enabled when a large Ping packet is sent, but the outbound interface of the packet has a smaller MTU.

  • Routing entries or ARP entries (for Ethernet links) are incorrect.

  • The hardware is faulty.

Troubleshooting Flowchart

Figure 4-35 shows the troubleshooting flowchart for a ping failure.

Figure 4-35 Troubleshooting flowchart for a ping failure

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 ping failure is caused by an excessively long link transmission delay.

    Run the ping -t time-value -v destination-address command to check whether the ping failure is caused by an excessively long link transmission delay.

    NOTE:

    In this command, the parameter -t is used to set the timeout period for a Response packet from the destination end. By default, the timeout period is 2000 ms. The parameter -v is used to display unexpected Response packets. By default, such packets are not displayed.

    The ping operation succeeds if a Response packet is received within a specified period, and the ping operation fails if no Response packet is received within the specified period. Therefore, specify proper values for -t and -v to check whether the ping failure is caused by a long link transmission delay. If ping packet loss occurs because the configured link transmission delay is shorter than the actual delay, the following information is displayed:

    <HUAWEI> ping -v -t 1 10.1.1.1
          PING 10.1.1.1: 56  data bytes, press CTRL_C to break
            Request time out
    Error:  Sequence number = 1 is less than the correct = 2!

    If this information is displayed, the ping failure occurs because the configured link transmission delay is shorter than the actual delay. To solve this problem, increase the value of -t. If the fault persists, go to Step 2.

    NOTE:

    If the ping operation can succeed only after -t is increased to a very long value, a fault can still occur on the device or link. Check the device and link status and clear any faults that exist.

    To ping a private network address from a PE, you run the ping -vpn-instance vpn-name destination-address command. The parameter -vpn-instance vpn-name specifies the VPN instance to which the pinged destination address belongs.

  2. Check for any incorrect operations.

    1. Check whether the ping -f command is running. If it is, packet fragmentation is not supported. In this case, check whether the MTU of the outbound interface along the path is smaller than the size of the Ping packet. If the MTU is smaller, packet loss occurs, in which case, change the size of the Ping packet to a value smaller than the MTU. Otherwise, go to sub-step 2.b. You can run the following command to view the MTU of an interface:

      <HUAWEI> display interface gigabitethernet 1/0/1
      GigabitEthernet1/0/1 current state : UP 
      Line protocol current state : UP 
      Last line protocol up time : 2010-10-25 17:34:51
      Description: HUAWEI, GigabitEthernet1/0/1 Interface (ifindex: 6, vr: 0)
      Route Port,The Maximum Transmit Unit is 1500 
      Internet Address is 1.0.0.1/24
      IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 00e0-fc12-3456
      The Vendor PN is PD100-TXLEB     
      The Vendor Name is Santur Corp.    
      Transceiver max BW: 43000Mbps, Transceiver Mode: single mode
      WaveLength: 0nm, Transmission Distance: 10000m
      Rx Optical Power: -40.00dBmTx Optical Power: -40.00dBm
      Loopback: none, LAN full-duplex mode, Pause Flowcontrol: Receive Enable and Send Enable
      Last physical up time   : 2010-10-25 17:27:25
      Last physical down time : 2010-10-25 17:17:24
      Current system time: 2010-10-25 18:11:44 
      Statistics last cleared:never
          Last 300 seconds input rate 25600 bits/sec, 0 packets/sec
          Last 300 seconds output rate 25600 bits/sec, 0 packets/sec
          Input: 960300 bytes, 100 packets
          Output: 960200 bytes, 100 packets
          Input: 
            Unicast: 100 packets, Multicast: 0 packets
            Broadcast: 0 packets, JumboOctets: 0 packets
            CRC: 0 packets, Symbol: 0 packets
            Overrun: 0 packets, InRangeLength: 0 packets
            LongPacket: 100 packets, Jabber: 0 packets, Alignment: 0 packets
            Fragment: 0 packets, Undersized Frame: 0 packets
            RxPause: 0 packets
          Output:
            Unicast: 100 packets, Multicast: 0 packets
            Broadcast: 0 packets, JumboOctets: 100 packets
            Lost: 0 packets, Overflow: 0 packets, Underrun: 0 packets
            System: 0 packets, Overruns: 0 packets
            TxPause: 0 packets
          Last 300 seconds input utility rate:  0.01%
          Last 300 seconds output utility rate: 0.01%
    2. Check whether the ping -i command is running, that is, whether an outbound interface is specified. If a broadcast interface such as an Ethernet interface is specified as an outbound interface, the destination address to be pinged must be the address of the directly connected interface. If this condition is not met, specify the directly connected interface as the outbound interface. If the fault persists, go to Step 3.

    NOTE:

    If -f is specified in a ping command, the Ping packets do not support packet fragmentation. If -iinterface-name is specified in a ping command, interface-name is specified as the outbound interface of the Ping packets, and the destination address is used as the next-hop address.

  3. Check whether the routing entries and ARP entries on the nodes.

    Run the display ip routing-table destination-address command on the nodes to check whether a route to the destination address exists. If no such route exists, see OSPF Troubleshooting or IS-IS Troubleshootingfor help on solving the problem.

    NOTE:

    For the ping to a VPN, run the display ip routing-table vpn-instance vpn-name destination-address command to check FIB entries. vpn-instance vpn-name specifies the VPN instance to which the pinged destination address belongs.

  4. Locate the direction in which the fault occurs.

    A ping operation involves three roles: the sending device (source end) of the Ping packets, intermediate device, and receiving device (destination end) of the Ping packets. If the ping operation fails, the fault may occur in the sending or receiving direction of any of the three devices. Therefore, locate the direction and node where the fault occurs.

    Check whether the fault occurs in the direction from the source end to the destination end or in the reverse direction. Stop the ping operation on the source end and destination end, and run the display icmp statistics command to check the ICMP packet transmission. The following information is displayed:

    <HUAWEI> display icmp statistics
    Input:  bad format      0          bad checksum              0   
            echo            0          destination unreachable   0   
            source quench   0          redirects                 0   
            echo reply      0          parameter problem         0   
            timestamp       0          information request       0   
            mask requests   0          mask replies              0   
            time exceeded   0          other                     0   
            Mping request   0          Mping reply               0   
    Output: echo            0          destination unreachable   132360   
            source quench   0          redirects                 0   
            echo reply      0          parameter problem         0   
            timestamp       0          information reply         0   
            mask requests   0          mask replies              0   
            time exceeded   0          
            Mping request   0          Mping reply               0   
    • If the number of ICMP packets does not increase, the device does not receive other ICMP packets, such as ICMP packets sent from the NMS. Do as follows to locate the fault.

      Perform a ping operation, and run the display icmp statistics command again to view the statistics about the ICMP packets.

      Based on the number of sent and received ICMP packets, you can locate the direction in which the fault occurs:

      • If the following conditions are met, the source end sends Request packets but does not receive any Response packets, and the destination end does not receive the Request packets.

        • On the source end, the value of the Output:echo field increases normally but the value of the Input:echo field does not increase.
        • On the destination end, the number of sent and received packets remain unchanged.

        In this case, the fault occurs in the direction from the source end to the destination end.

      • If the following conditions are met, the source end sends Request packets but does not receive any Response packets, and the destination end receives the Request packets and sends the Response packets.

        • On the source end, the value of the Output:echo field increases normally but the value of the Input:echo field does not increase.
        • On the destination end, the number of sent and received packets increase normally.

        In this case, the fault occurs in the direction from the destination end to the source end.

      After determining the direction in which the fault occurs, go to Step 5.

    • If the number of ICMP packets still increases, the board or the device receives other ICMP packets. Do as follows to locate the fault.

      NOTE:
      Before performing any subsequent operations, ensure that:
      • Services on the current network are not affected.
      • No traffic policies are applied to the interfaces.
      1. Configure an ACL on each device to match the Ping packets using source and destination addresses.

        The following configurations are an example:

        statistics enable
        #
        acl number 3000
        rule 5 permit ip source 1.1.1.1 0 destination 1.1.1.2 0
        #
        traffic classifier 3000 operator or
        if-match acl 3000 
        #
        traffic behavior 3000
        #
        traffic policy 3000
        statistics enable
        classifier 3000 behavior 3000
      2. Run the traffic-policy command in the interface view to configure a traffic policy and apply the ACL to the interfaces.

        • On the source end and destination end, apply the traffic policy in the inbound direction of the interfaces on both ends.
        • On the intermediate device, apply the traffic policy in both the inbound and outbound directions of the associated interface.

        The following configurations are an example:

        #
        interface GigabitEthernet2/0/0
        ip address 1.1.1.2 255.255.255.252
        traffic-policy 3000 inbound
        #
        interface GigabitEthernet3/0/0
        traffic-policy 3001 outbound
        #
        
        NOTE:
        If the ACL is applied to a trunk interface, configure the traffic policy on a physical member interface.
      3. Run the display traffic policy statistics interface command to view statistics about the Ping packets that match the ACL on each interface.
        <HUAWEI> display traffic policy statistics interface gigabitethernet 1/0/0 inbound
        Interface: GigabitEthernet1/0/0 
        inbound: test 
        Traffic policy applied at 2007-08-30 18:30:20 
        Traffic policy Statistics enabled at 2007-08-30 18:30:20
        Statistics last cleared: Never
        Rule number: 7 IPv4, 1 IPv6 
        Current status: OK!
        Item                             Packets                      Bytes
        -------------------------------------------------------------------
        Matched                            1,000                    100,000
          +--Passed                          500                     50,000
          +--Dropped                         500                     50,000
            +--Filter                        100                     10,000
            +--URPF                          100                     10,000
            +--CAR                           300                     30,000
        Missed                               500                     50,000
        Last 30 seconds rate
        
        • If all the Ping packets match the ACL, the Ping packets are sent or received normally. If the ping operation still fails, collect this information and contact technical support personnel.
        • If both the incoming and outgoing Ping packets of the intermediate device match the ACL, the intermediate device is working properly. Check whether a fault occurs on the source end or destination end.
        • If the incoming Ping packets of one of the three devices do not match the ACL, the upstream device of this device becomes faulty. If this occurs, go to Step 6.

  5. Locate the node where the fault occurs.

    Locate the node according to the direction in which the fault occurs.
    • If the fault occurs in the direction from the source end to the destination end, do as follows to locate the node where the fault occurs, starting with the source end.

    • If the fault occurs in the direction from the destination end to the source end, do as follows to locate the node where the fault occurs, starting with the destination end.

    Run the tracert dest-ip-address command to find the location where packet loss occurs.

    <HUAWEI> tracert 1.1.1.1
       traceroute to  1.1.1.1(1.1.1.1), max hops: 30 ,packet length: 40
         1 2.1.1.1 5  ms  4 ms  3 ms
         2 3.0.0.2 10 ms  11 ms  8 
         3   *  *  *
         ...

    This command output shows that the next hop of the route to 3.0.0.2 (namely, the node displayed as "3 * * *") becomes faulty. After locating the node where the fault occurs, go to Step 5.

    NOTE:

    For the tracert to a VPN, run the tracert -vpn-instance vpn-name destination-address command for fault location. -vpn-instance vpn-name specifies the VPN instance to which the tracerted destination address belongs.

  6. Check whether a local attack defense policy is configured on the node where the fault occurs.

    If some devices have been attacked by ICMP packets, the rate at which the ICMP packets are sent to the CPU decreases and excess ICMP packets are dropped to protect against attacks. As a result, the ping operation fails.

    Run the display current-configuration | include cpu-defend command to check for the configurations of a CPU attack defense policy in the configuration file of the device.

    • If a CPU attack defense policy is configured, run the display cpu-defend policy and display cpu-defend car commands to check the following:
      • Whether or not the blacklist that contains the source or destination IP address of the ping packets is configured.
      • Whether the CAR is configured. If it is, check whether the Ping packets fail to be processed because the CAR is set to an unacceptably small value.

      If the blacklist is configured or the CAR is set too small, a ping failure or packet loss occurs. If the ping operation is still required, delete the blacklist or the CAR and run a ping command again. If the ping operation still fails, go to Step 7.

    • If no CPU attack defense policy is configured, go to Step 7.

  7. Check whether the routing entries and ARP entries on the node where the fault occurs are correct.

    Run the display ip routing-table destination-address command on the node where the fault occurs in check whether a route to the destination address exists. If no such route exists, see OSPF Troubleshooting or IS-IS Troubleshootingfor help on solving the problem.

    If a route to the destination address exists and the Ping packets are transmitted over an Ethernet link, run the display arp interface command to check whether the required ARP entry exists. If the required ARP entry does not exist, see the ME60 Troubleshooting - LAN Access and MAN Access for help on solving the problem. If the fault persists, go to Step 8.

    NOTE:

    For the ping to a VPN, run the display ip routing-table vpn-instance vpn-name destination-address command to check FIB entries. vpn-instance vpn-name specifies the VPN instance to which the pinged destination address belongs.

  8. Check whether any error packets exist on the interfaces on the node where the fault occurs.

    Run the display interface interface-type interface-number command to check the packet statistics on the specified interface.

    • Check whether the value of the CRC field on an Ethernet interface increases after this display command is run again.

    If the number of error packets or alarms on the specified interface increases, the link or optical module becomes faulty. Clear the faults on the link or optical module.

    If the number of error packets or alarms on the specified interface does not increase, go to Step 9.

  9. Locate the layer where the fault occurs.

    After finding the node where the fault occurs, do as follows to locate the layer where the fault occurs.

    1. Check whether the ICMP packets are sent and received normally.
      <HUAWEI> display icmp  statistics
      Input:  bad format      0          bad checksum              0   
              echo            0          destination unreachable   0   
              source quench   0          redirects                 0   
              echo reply      0          parameter problem         0   
              timestamp       0          information request       0   
              mask requests   0          mask replies              0   
              time exceeded   0          other                     0   
              Mping request   0          Mping reply               0   
      Output: echo            0          destination unreachable   132360   
              source quench   0          redirects                 0   
              echo reply      0          parameter problem         0   
              timestamp       0          information reply         0   
              mask requests   0          mask replies              0   
              time exceeded   0          
              Mping request   0          Mping reply               0   

      If no ICMP packets or error packets are received, collect this information and contact technical support personnel.

      If the ICMP packets are received normally, go to Sub-step 9.b.

    2. Check whether the network layer is normal.

      Run the display ip statistics command to check whether the network layer is normal.

      <HUAWEI>  display ip statistics
      Input:        sum                2209077    local           528839    
                    bad protocol       1150       bad format      0         
                    bad checksum       43379      bad options     0         
                    discard srr        0          discard rr      0         
                    discard ra         0          discard ts      0         
                    TTL exceeded       0         
      Output:       forwarding         0          local           0         
                    dropped            0          no route        0         
      Fragment:     input              0          output          0         
                    dropped            0          fragmented      0         
                    couldn't fragment  0         
      Reassembling: sum                0          timeouts        0

      If the error packet statistics displayed in the command output increase, some error packets reach the network layer and are dropped after a validity check.

      • If the error packet statistics increase, the board on the device may become faulty. If so, collect this information and contact technical support personnel.

      • If the error packet statistics do not increase, go to Step 9.

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

    • Results of this troubleshooting procedure
    • Configuration files, log files, and alarm files of the devices

Relevant Alarms and Logs
Relevant Alarms

None

Relevant Logs

None

The Tracert Operation Fails

This chapter describes common causes of the tracert operation fails, and provides the corresponding troubleshooting flowcharts and examples.

Common Causes

This fault commonly results from one of the following causes:

  • Routing entries or ARP entries are incorrect.

  • Tracert packets are modified. As a result, these packets are dropped because they fail validity check at the network layer.

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 routing entries and ARP entries are correct.

    Run the display ip routing-table destination-address command on each device to check whether a route to the destination address.

    • If no route to the destination address exists, see OSPF Troubleshooting or IS-IS Troubleshooting for help on solving the problem.
    • If a route to the destination address exists and the Tracert packets are transmitted over an Ethernet link, run the display arp interface command to check whether the required ARP entry exists. If the required ARP entry does not exist, go to step 3. If the fault persists, go to Step 2.

  2. Check whether the device sending the Tracert packets (the source end) receives the ICMP error packets.

    Run the display icmp statistics command on the source end to check whether it receives the ICMP error packets.

    <HUAWEI> display icmp statistics
    Input:  bad format      0          bad checksum              0   
            echo            0          destination unreachable   0   
            source quench   0          redirects                 0   
            echo reply      0          parameter problem         0   
            timestamp       0          information request       0   
            mask requests   0          mask replies              0   
            time exceeded   0          other                     0   
            Mping request   0          Mping reply               0   
    Output: echo            0          destination unreachable   132360   
            source quench   0          redirects                 0   
            echo reply      0          parameter problem         0   
            timestamp       0          information reply         0   
            mask requests   0          mask replies              0   
            time exceeded   0          
            Mping request   0          Mping reply               0   

    During the tracert operation, run the display icmp statistics command several times to check the tracert result. If the increased value of the total number of Destination Unreachable packets and Time Exceeded packets in the Input field equals the number of sent Tracert packets, the source end receives the ICMP error packets. Pleasecontact technical support personnel. Otherwise, go to Step 3.

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

    • Results of this troubleshooting procedure
    • Configuration files, log files, and alarm files of the devices

Relevant Alarms and Logs

None

Translation
Download
Updated: 2019-06-11

Document ID: EDOC1000175918

Views: 13779

Downloads: 257

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