Network packet loss troubleshooting solution

1. Location and processing of network packet loss

When network packet loss occurs, the first step is to determine the network location of the packet loss, followed by determining the cause of the packet loss, and then solving the problem based on the located cause. The location process is roughly shown in Figure 8-1.

Figure 8-1 Network packet loss location and processing

This article uses the packet loss phenomenon in a certain campus as an example to provide methods for locating and handling packet loss in a network where switches are deployed.

For example, in a campus network, as shown in Figure 8-2, users A, B, and C are connected to switches Switch_3 and Switch_2, and users D and E are connected to switch Switch_4. They are then connected to the core switch Switch_1 and connected to the Internet through a firewall.

Figure 8-2 Network diagram for a campus deployment

User A reported that Internet access was very slow and sometimes even failed to open web pages, while other users reported no abnormalities. At this time, when user A's PC directly pinged the public network address, packet loss occurred.

2. Confirm that network packet loss occurs

The network packet loss symptom is usually as follows:

When users surf the Internet:

• The network speed is unstable, the speed of opening web pages is very slow, and sometimes part of the web page content or the entire page cannot be displayed;
• When watching video services, there are mosaics or screen distortion and other freezes;
• Instant messaging tools such as QQ frequently disconnect or prompt login timeout;
• Slow file download speed;

When the switch is working:

• When you perform a Ping operation on the switch to test the network connectivity, a timeout message is displayed.
• The port cannot forward data normally;
• When the management user logs in to the switch, a timeout message is displayed;
• Frequent business interruptions;

These fault phenomena are almost all related to network packet loss. If one or more of the above fault phenomena occur in the live network, it can be basically confirmed that network packet loss has occurred.

3. Check the PC that causes packet loss

Check the PC itself for problems that cause packet loss.

For example, whether the PC's network card is normal or whether the cable connecting the PC to the device is normal may cause device packet loss. Solution: After disconnecting from the network, check the PC for viruses, check the network cable, reinstall the operating system, check the network card, etc.

After confirming that the PC is normal, if the fault still exists, proceed to the next step.

4. Check whether the physical status of the interface is Down

Generally speaking, the physical status of the interface is Down, or the duplex mode or rate negotiation mode of the interface is inconsistent with that of the peer end, which will cause the interface status to be abnormal. Execute the following command on the device:

Use the display interface interface-type interface-number command to check whether the interface is running normally.

Here, check GE1/0/2 of Switch_3 as an example.

 < HUAWEI > display interface gigabitethernet 1 / 0 / 2
 GigabitEthernet1 / 0 / 2 current state : DOWN //Current physical state of the interface
 Line protocol current state : DOWN
 Description :
 Switch Port , Link - type : access ( negotiated ),
 PVID : 1 , TPID : 8100 ( Hex ), The Maximum Frame Length is 9216
 IP Sending Frames ' Format is PKTFMT_ETHNT_2, Hardware address is 000b-0974-a475
 Last physical up time : 2016-08-10 21:09:51 Last physical down time : 2013-08-10 21:10:51 ​ ​ ​ ​ ​ ​ ​ ​ ​ ​
 Current system time : 2016-08-10 21:15:06 ​ ​ ​ ​ ​
 Port Mode : COMMON FIBER //Interface working mode. COMMON COPPER means this interface is an electrical interface; COMMON FIBER means this interface is an optical interface
 Speed ​​: 1000 , Loopback : NONE //Interface rate and loopback status must be consistent at both ends of the link
 Duplex : FULL , Negotiation : ENABLE //Interface duplex mode and auto-negotiation status, both ends of the link need to be consistent
 -- -- More -- --

• The output information displays "current state: UP", indicating that the interface is operating normally. Please skip this section and refer to the next section for location and processing.
• If the output information displays "current state: Administratively down", it means that the interface is shut down manually.

Run the interface interface-type interface-number command in the system view to enter the faulty interface view and run the display this command to check whether the interface has been shut down. If so, run the undo shutdown command in the interface view.

• If the output information shows "current state: DOWN", you need to check whether the negotiation state, rate, duplex mode, and network cable adaptation mode of the interface are consistent at both ends of the link. Run the display interface command on the devices at both ends of the link to view the above information, as shown in Table 8-1.

Table 8-1 Check the duplex, rate, and negotiation mode of the device interfaces at both ends of the link

If the output information displays "current state : ERROR DOWN (down-cause)", it means that the interface is shut down due to an error event. You need to troubleshoot the fault based on the specific field information of the down-cause field.

5. Check whether there is a CRC error in the incoming direction of the interface

Check whether the physical port through which the message passes has CRC check errors and whether the error count is increasing. If the output information shows that the field "CRC" has a count, and the count is found to be increasing after repeated execution of the command, it means that the port has received a CRC error message, that is, there is a CRC check error, indicating that the error packet is caused by a physical link or device problem.

6. Check whether there is a Discard count in the outbound direction of the interface

Check whether there are discarded packet counts on the port.

Run the display interface interface-type interface-number command in any view, or run the display this interface command in the interface view to check the outbound packet counts of the device-connected user-side port. If there is a Discard packet loss count, it means that the port was congested. When the service is affected, observe whether the Discard count increases. If not, the service impact is not related to the Discard packet loss.

7. Check if there is a loop

This is the most likely factor to cause packet loss, and it is relatively hidden. For example, in a large network environment, the administrator can easily connect the ports between switches incorrectly, causing a network loop and packet loss. Observe whether the following loop-related phenomena occur. When a network loop occurs, in addition to packet loss, the following phenomena generally occur:

• Run the display interface brief | include up command to view the traffic on all Up interfaces. The InUti and OutUti counts on the interface with a loop will gradually increase, even close to 100%, far exceeding the service traffic.
• When you use the display interface command to view the interface statistics, you can find that the interface receives a large number of broadcast packets.
• The indicator on the VLAN interface where a loop occurs flashes frequently.
• The device CPU usage exceeds 80%