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

AR Router Troubleshooting Guide

This Product Documentation provides guidance for maintaining AR Enterprise Router, covering common information collection and fault diagnostic commands, typical fault troubleshooting guide, and 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).
The Ping Operation Fails

The Ping Operation Fails

Common Causes

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

This fault is commonly caused by one of the following:

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

  • There are improper configurations. 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 14-14 shows the troubleshooting flowchart.

Figure 14-14  Troubleshooting flowchart for a ping failure

Troubleshooting Procedure

Context

NOTE:

Save the operation results of follow-up steps so that you can refer to them during troubleshooting.

Procedure

  1. Check whether the ping failure is caused by the too long link transmission delay.

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

    NOTE:

    In this command, the parameter -t is used to set the timeout period for waiting 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, you can 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 the preceding information is displayed, it indicates that 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 ping operation can succeed only after -t is increased to a very long value, there is a possibility that a fault occurs on the device or link. Check the device and link status and clear the fault.

    If the fault persists, go to 2.

    NOTE:

    To ping a private network address from a PE, you need to 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 whether the ping operation is properly performed.

    1. Check whether the ping -f command is run. If this command is run, it indicates that 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 than the size of the ping packet, packet loss will occur, in which case, you need to change the size of the ping packet to a value smaller than the MTU or change the ping operation. Otherwise, go to 2.b. You can run the following command to view the MTU of an interface:

      <Huawei> display interface gigabitethernet 1/0/0
      GigabitEthernet1/0/0 current state : UP
      Line protocol current state : UP
      Description:HUAWEI, AR Series, GigabitEthernet1/0/0 Interface
      Route Port,The Maximum Transmit Unit is 1500
    2. Check whether the ping -i command is run, 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, you need to specify the directly connected interface as the outbound interface. If the fault persists, go to 3.

    NOTE:

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

  3. Locate the direction in which the fault occurs.

    A ping operation involves three roles: the sending device (source end) of 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 and therefore you need to locate the direction and node where the fault occurs.

    Figure 14-15  Application scenario of a ping operation

    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 ICMP packet transmission. The following information is displayed:

    <Huawei>  display icmp statistics
      Input: bad formats            0      bad checksum                     0
             echo                  36      destination unreachable          9
             source quench          0      redirects                       43
             echo reply              18      parameter problem                0
             timestamp              0      information request              0
             mask requests          0      mask replies                     0
             time exceeded          6
             Mping request          0      Mping reply                      0
      Output:echo                  20      destination unreachable      71438
             source quench          0      redirects                        0
             echo reply              36      parameter problem                0
             timestamp              0      information reply                0
             mask requests          0      mask replies                     0
             time exceeded          0
             Mping request          0      Mping reply                      0
    NOTE:

    Run the display icmp statistics command on the source end to view statistics about packets on the main control board.

    Run the display icmp statistics command on the destination end to view statistics about packets on a specified interface board.

    • If the number of ICMP packets does not increase, it indicates that the board or 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 statistics about ICMP packets.

      According to the numbers of sent and received ICMP packets, you can locate the direction in which the fault occurs:

      • If the following conditions are all met, it indicates that the source end sends Request packets but does not receive any Response packet, 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 numbers of sent and received packets remain unchanged.

        In this case, you can determine that the fault occurs in the direction from the source end to the destination end.

      • If the following conditions are all met, it indicates that the source end sends Request packets but does not receive any Response packet, and the destination end receives the Request packets and sends 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 numbers of sent and received packets increase normally.

        In this case, you can determine that 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 4.

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

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

        Use the following configurations as 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 interfaces.

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

        Use the following configurations as an example:

        #
        interface GigabitEthernet1/0/0
         ip address 1.1.1.2 255.255.255.252
         traffic-policy 3000 inbound
        #
        interface GigabitEthernet2/0/0
         traffic-policy 3001 outbound
        #
        
        NOTE:
        If the ACL is applied to a trunk interface or VLANIF interface, you need to configure the traffic policy on a physical member interface.
      3. Run the display traffic policy statisticsinterface 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: GigabitEthernet0/2/0
        inbound
        Interface: GigabitEthernet0/2/0
        inbound: test 
        Traffic policy applied at 2014-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 ping packets match the ACL, it indicates that the ping packets are sent or received normally. If the ping operation still fails, collect the preceding information and contact technical support personnel.
        • If both incoming and outgoing ping packets of the intermediate device match the ACL, it indicates that the intermediate device works properly. Then, you need to check whether a fault occurs on the source end or destination end.
        • If incoming ping packets of one of the three devices do not match the ACL, it indicates that the upstream device of this device becomes faulty. Then, go to 4.

  4. 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, press CTRL_C to break
         1 10.1.1.1 5  ms  4 ms  3 ms
         2 10.0.0.2 10 ms  11 ms  8 
         3   *  *  *
         ...

    The preceding command output shows that the next hop of the route to 10.0.0.2 (namely, the node displayed as "3 * * *") becomes faulty. After locating the node where the fault occurs, go to 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.

  5. 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 ICMP packets are sent to the CPU is decreased 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 whether there are 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 policy-number commands to check the following:
      • Check whether the blacklist that contains the source or destination IP address of ping packets is configured.
      • Check whether the CAR is configured. If the CAR is configured, check whether ping packets fail to be processed because the CAR is set to a too 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 then run a ping command again. If the ping operation still fails, go to 6.

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

  6. Check that FIB and ARP entries on the problem node are correct.

    Run the display fib destination-address command on the problem node to check whether a route to the destination address exists. If such a route does not exist, see OSPF Troubleshooting or IS-IS Troubleshooting for troubleshooting.

    If such a route exists and ping packets are transmitted over an Ethernet link, run the display arp all command to check whether the required ARP entry exists. If yes, go to Step 7. If not, go to Step 9.

    NOTE:

    For the ping operation to a VPN, run the display fib 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.

  7. Check that there are no error packets on interfaces on the node where the fault occurs.

    Run the display interface interface-type interface-number command to check 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, it indicates that the link or optical module becomes faulty. Clear faults on the link or optical module.

  8. 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 ICMP packets are sent and received normally.
      <Huawei> display icmp  statistics
      
        Input: bad formats           0          bad checksum            0   
               echo                  0          destination unreachable 0   
               source quench         0          redirects               0   
               echo reply            0          parameter problem       0   
               timestamp request     0          information request     0   
               mask requests         0          mask replies            0   
               time exceeded         0          timestamp reply         0   
               Mping request         0          Mping reply             0   
        Output:echo                  0          destination unreachable 0   
               source quench         0          redirects               0   
               echo reply            0          parameter problem       0   
               timestamp request     0          information reply       0   
               mask requests         0          mask replies            0   
               time exceeded         0          timestamp reply         0   
               Mping request         0          Mping reply             0   

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

      If ICMP packets are received normally, go to 8.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                123174      local                     0
                   bad protocol            0      bad format                0
                   bad checksum            0      bad options               0
                   discard srr             0      TTL exceeded              0
         Output:   forwarding              0      local                268816
                   dropped                 0      no route                  0
         Fragment: input                   0      output                    0
                   dropped                 0
                   fragmented              0      couldn't fragment         0
      Reassembling:sum                   0      timeouts                  0  

      If error packet statistics (such as the values of the bad protocol, bad format, bad checksum, bad options, discard srr, TTL exceeded, dropped, no route, and couldn't fragment fields) displayed in the command output increase, it indicates that some error packets reach the network layer and are dropped after validity check.

      • If error packet statistics increase, it indicates that the board on the device may become faulty. In this case, go to Step 9.

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

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

Translation
Download
Updated: 2019-05-10

Document ID: EDOC1000079719

Views: 450643

Downloads: 4307

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