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

Troubleshooting Guide

CloudEngine 16800, 12800, 12800E, 8800, 7800, 6800, and 5800 Series Switches

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).
Troubleshooting Procedure

Troubleshooting Procedure

After commands are configured to troubleshoot faults, pay attention to the configuration validation mode to ensure that the configurations take effect. Unless otherwise specified, this manual defaults to the two-phase validation mode.

  • In immediate validation mode, the configuration takes effect immediately after you run a command and press Enter.
  • In two-phase validation mode, you must run the commit command after commands are configured to commit the configuration.

Save the results of each troubleshooting step, so you can provide related information to Huawei technical support if your troubleshooting fails.

Procedure

  1. Check the logs to find the cause of the fault.

    Run the display logbuffer size buffersize command to access the following log information.

    If the log message is as follows, the neighbor status changes:

    CE12800 %%01 ospfv2comm/6/NBR_CHANGE(l):VS=0-CID=[UINT];Neighbor changes event: neighbor status changed. (ProcessId=[UINT], NbrIpAddr=[IPADDR], NbrEvent=[UINT], NbrPreviousState=[UINT], NbrCurrentState=[UINT])

    Check the NbrEvent field, which records the cause of the fault. The possible causes of the fault are as follows:

    • Inactivity (NbrEvent=7)

      An InactivityTimer event of the neighbor state machine occurs. If a device does not receive any Hello packets from its neighbor within the down time, the OSPF neighbor relationship becomes Down. In this case, go to Step 2.

    • LLDown (NbrEvent=6)

      An LLDown event of the neighbor state machine occurs, indicating that the lower-layer protocol notifies the upper layer that the neighbor is unreachable. In this case, go to Step 2.

    • 1-Way Received (NbrEvent=4)

      A 1-Way Received event of the neighbor state machine occurs. A 1-Way Hello packet is sent from the remote end to the local end when the OSPF status on the remote end changes to Down. After receiving the packet, the OSPF status on the local end also changes to Down. In this case, check the remote end to rectify any possible fault.

    • Kill Neighbor (NbrEvent=5)

      This event indicates that the interface or BFD session becomes Down. Run the display interface [ interface-type [ interface-number ] ] command to check the interface status and rectify any possible fault.

    If the log message is as follows, the reset ospf process command has been run:

    CE12800 %%01 ospfv2comm/6/OSPF_RESET(l):VS=%u-CID=[UINT];OSPF process or area reset. (CompCID=[UINT], Parameter=[UINT], ResetReason=[UINT])

    To verify whether this command has been run, check the operation records or log information.

    In all other cases, go to Step 9.

  2. Check whether the link between the two devices is normal.

    Run the ping command and the display this interface command in the interface view to check whether the link between the two devices is normal and the transmission devices are normal. If the link is normal, go to Step 3.

  3. Check whether the CPU usage is within the normal range.

    Run the display cpu command to check whether the CPU usage of the faulty device is too high. If it is, OSPF fails to receive and send protocol packets, causing the neighbor relationship to flap. In this case, troubleshoot the fault of the high CPU usage and disable unnecessary functions. If the CPU usage is within the normal range, go to Step 4.

  4. Check whether the interface status is Up.

    Run the display interface [ interface-type [ interface-number ] ] command to check the physical status of the interface. If the physical status is Down, troubleshoot the interface fault.

    If the physical status of the interface is Up, run the display ospf interface command to check whether the OSPF status of the interface is a normal type such as DR, BDR, DROther, or P2P.

    <HUAWEI> display ospf interface
              OSPF Process 1 with Router ID 10.1.1.1
                      Interfaces
    
     Area: 0.0.0.0          (MPLS TE not enabled)
     Interface          IP Address      Type           Cost    Pri
     Vlanif50           192.168.1.1       Broadcast         1       1

    • If the OSPF status of the interface is Down, run the display ospf cumulative command to check whether the number of interfaces enabled with OSPF in the OSPF process exceeds the upper limit. If so, reduce the number of interfaces enabled with OSPF.

      <HUAWEI> display ospf cumulative
                OSPF Process 1 with Router ID 10.1.1.1
                        Cumulations
        IO Statistics
                   Type        Input     Output
                  Hello            0         86
         DB Description            0          0
         Link-State Req            0          0
      Link-State Update            0          0
         Link-State Ack            0          0
        ASE: (Disabled)
        LSAs originated by this router
        Router: 1
        Network: 0
        Sum-Net: 0
        Sum-Asbr: 0
        External: 0
        NSSA: 0
        Opq-Link: 0
        Opq-Area: 0
        Opq-As: 0
        LSAs Originated: 1  LSAs Received: 0
        Routing Table:
          Intra Area: 1  Inter Area: 0  ASE: 0
        
               Neighbor Cumulate:
        =======================================================
            Neighbor cumulative data. (Process 1)
        -------------------------------------------------------
        Down:       0 Init:        0 Attempt:    0 2-Way:    0
        Exstart:    0 Exchange:    0 Loading:    0 Full:     1
        Retransmit Count:1
      
            Neighbor cumulative data. (Total)
        -------------------------------------------------------
        Down:       0 Init:        0 Attempt:    0 2-Way:    0
        Exstart:    0 Exchange:    0 Loading:    0 Full:     1
        Retransmit Count:1
    • If the OSPF status of the interface is a normal type, such as DR, BDR, DR Other, or P2P, go to Step 5.

  5. Check whether the IP addresses of the two devices are on the same network segment.

    Run the display interface interface-type [ interface-number ] command to check the IP addresses of the interfaces on the two devices.

    • If the IP addresses of the two devices are on different network segments, run the ip address command to change these IP addresses to ensure that they are on the same network segment.

    • If the IP addresses of the two devices are on the same network segment, go to Step 6.

  6. Check whether the MTUs of interfaces on both ends are consistent.

    If the ospf mtu-enable command is run on the interfaces on both ends, the MTUs of the two interfaces must be consistent. Otherwise, the OSPF neighbor relationship cannot be established. Run the display this interface command in the interface view to check the interface MTU.

    • If the MTUs of the two interfaces are inconsistent, run the mtu mtu command in the interface view to change the MTUs so they are consistent.

    • If the MTUs are consistent, go to Step 7.

  7. Check whether there is an interface whose priority is not 0.

    On broadcast and NBMA network segments, at least one interface whose priority is not 0 must exist to ensure that the DR can be elected correctly. Otherwise, the OSPF neighbor relationship can only reach the two-way state.

    Run the display ospf interface command to view the interface priority.

    <HUAWEI> display ospf interface
              OSPF Process 1 with Router ID 10.1.1.1
                      Interfaces
    
     Area: 0.0.0.0          (MPLS TE not enabled)
     Interface          IP Address      Type         State    Cost    
     Vlanif50           192.168.1.1       Broadcast    P-2-P    1       

  8. Check whether the OSPF configurations on the two devices are correct.

    1. Check whether the OSPF router IDs of the two devices conflict.

      <HUAWEI> display ospf brief
                OSPF Process 1 with 
                        OSPF Protocol Information

      If so, modify the OSPF router IDs. If not, proceed with the check.

    2. Check whether the OSPF area configurations on the two devices are consistent.

      <HUAWEI> display ospf interface
                OSPF Process 1 with Router ID 10.1.1.1
                        Interfaces
      
                 (MPLS TE not enabled)
       Interface          IP Address      Type         State    Cost    Pri
       Vlanif50           192.168.1.1       Broadcast    BDR      1       1
    3. Check whether other OSPF configurations on the two devices are the consistent.

      Run the display ospf error command every 10s for 5 minutes.

      <HUAWEI> display ospf error
                OSPF Process 1 with Router ID 10.1.1.1
                        OSPF error statistics 
      General packet errors:
       0     : IP: received my own packet     0     : Bad packet
       0     : Bad version                  0     : Bad checksum
       0     : Bad area id                   0     : Drop on unnumbered interface
       0     : Bad virtual link               0     : 
       0     : Bad authentication key         0     : Packet too small
       0     : Packet size > ip length         0     : Transmit error
       0     : Interface down                0     : Unknown neighbor
      HELLO packet errors:
       0     : Netmask mismatch              0     : 
       0     :            0     : 
       0     : Router id confusion            0     : Virtual neighbor unknown
       0     : NBMA neighbor unknown          0     : Invalid Source Address
      • Check the Bad authentication type field. If the value of this field keeps increasing, the OSPF authentication types of the two devices that establish the neighbor relationship are different. In this case, set the same authentication type for the two devices.
      • Check the Hello timer mismatch field. If the value of this field keeps increasing, the value of the Hello timers on the two devices that establish the neighbor relationship are different. In this case, check the interface configurations of the two devices and set the same value for the Hello timers.
      • Check the Dead timer mismatch field. If the value of this field keeps increasing, the value of the dead timers on the two devices that establish the neighbor relationship are different. In this case, check the interface configurations of the two devices and set the same value for the dead timers.
      • Check the Extern option mismatch field. If the value of this field keeps increasing, the area types of the two devices that establish the neighbor relationship are different (the area type of one device is the common area, and the area type of the other device is the stub area or NSSA). In this case, set the same area type for the two devices.

    If the fault persists, go to Step 9.

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

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

Translation
Download
Updated: 2020-01-07

Document ID: EDOC1000060766

Views: 603909

Downloads: 2938

Average rating:
This Document Applies to these Products

Related Version

Related Documents

Share
Previous Next