Troubleshooting of vswitch Network Communication

Troubleshooting of vswitch Network Communication

Cisco's catalyst switches are generally not prone to faults. Once a fault occurs, it is usually difficult for CCNA certified trainees to detect and troubleshoot, this section summarizes some minor faults that often occur during the use of vswitches to help students pass authentication and adapt to a simple working environment.

Faults related to physical layer connection:

Physical Layer line connections are in advance of normal network usage, so we have to point out that many of the so-called network faults are caused by successive physical layer lines, such: the twisted pair wires connected to the corresponding desktop computer are connected to incorrect switch interfaces, RJ45 connector loose, and physical cables are not connected. In particular, it is suggested that Cisco switches use cross-twisted pair wires to connect to vrouters or computers. If you need a vswitch to perform an adaptive media interface on an interface, you must start the auto-MDIX command in the related interface mode, the full name of auto-MDIX is automatic medium-dependent interface crossover. After this function is enabled, no matter which type of cable the interface is connected, the switch can automatically adjust this interface to keep it working normally. There is a requirement to start auto-MDIX: this interface must be able to automatically negotiate the rate and duplex mode.

Duplex mode faults:

If the two modes do not match, related faults may occur. Based on the publication time of this book, almost all devices in the current network market support full duplex mode. Of course, apart from traditional HUB devices, all network devices should be in the dual-mode. By default, Cisco recommends that you set the switch interface to automatic negotiation speed and duplex mode. The reason for this is: if a half-duplex device is connected to a Cisco switch, cisco switches will downgrade their full duplex mode to half duplex mode to adapt to the operation of the device. If the Administrator forces the switch interface to work in full duplex mode, an interface error will occur. The reason for troubleshooting is to use show interfaces fastEthernet 0/1 counters errors to View Interface errors. 14.27.

Interface Error faults:

A switch interface error usually results in a large number of data frames. For example, when a user finds that TCP-based applications become very slow, it seems that the slow speed of TCP applications is not related to the switch interface failure, however, further consideration is that the TCP Slow Start is more caused by the slow start of TCP. In the slow start of TCP, the size of the TCP sliding window will decrease, this phenomenon is often caused by packet loss on the switch. In this situation, UDP-based applications are even more terrible, because UDP will not re-transmit at all, so the network quality will be seriously reduced. Therefore, when troubleshooting such a fault, we need to know why the switch packet loss is often related to the interface error of the switch. We must check the error statistics of the switch interface, you can use show interface x/y counters errors to obtain the error statistics message of the vswitch interface, as shown in Figure 14.27. Now you can understand the meaning of each error statistician:

NAlign-Err (alignment error): if the data frame does not end with an even eight-bit group, an alignment error occurs, indicating a physical layer error, which is generally caused by wiring or switch interface faults.

NFCS-Err (frame verification error): The frame verification error usually occurs at the physical layer and is accompanied by Align-Err.

NXmit-Err (sending error): indicates that the switch interface sends cache overflow, which is usually caused by mismatch between inbound and outbound rates.

NRcv-Err (receiving error): indicates that the switch interface receives cache overflow, which is usually caused by backplane congestion of the switch, resulting in receiving cache full. In many cases, receiving errors also imply that the duplex mode does not match.

NUnderSize (ultra-short frame): indicates that the checksum is valid, but the frame size is smaller than 64 bytes. This indicates that the host connected to this interface is sending an invalid data frame size.

NSingle-Col (single conflict): indicates that a single conflict error occurs before the interface successfully sends data frames, the cause of this error is that the link usage is too high or the duplex does not match.

NMulti-Col (multiple conflicts): indicates that multiple conflict errors will occur when multiple conflicts occur before the interface successfully sends data frames, the cause of this error is that the link usage is too high or the duplex does not match.

NLate-Col (post-conflict): indicates the conflict detected only after the data frame is forwarded. The cause of this error is that the physical medium (such as the cable) is too long or the duplex does not match.

NExcess-Col (overload conflict): when a data frame encounters 16 consecutive conflicts, it is discarded and an overload conflict error occurs, the main cause of this error is that the link usage is too high, the duplex does not match, and there are too many devices in the network, especially half-duplex devices.

NCarri-Sen (carrier listener): indicates that the interface is in the half duplex status. According to the working principle of CSMA/CD, when sending data in the half duplex status, conflict Detection is required, which adds the carri-sen counter. CSMA/CD is not used in full duplex mode.

NRunts (residual frame): the size of the frame is smaller than 64 bytes, and CRC error occurs. The error of the residual frame is generally caused by physical layer failure or duplex mode mismatch.

NGiants (ultra-long frame): The frame size is greater than 1518 bytes. The error of ultra-long frame is usually caused by host NIC failure.

If the CPU usage of the vswitch is too high:

Vswitch architecture shown in 14.28. Generally, the vswitch architecture consists of two layers: A control layer and a forwarding layer. The control layer is responsible for running the switch operating system, STP, routing protocol, route table maintenance, and ACL execution. The control layer includes the switch CPU and memory. The forwarding layer includes the forwarding logic and backplane of the switch. The forwarding logic of the switch is the hardware used by the switch to make forwarding decisions. The hardware is responsible for rewriting the data frame header; the backplane of A vswitch is responsible for physically connecting to the port of the vswitch. It depends on the system architecture of the vswitch. data frames are transmitted from the inbound interface of the vswitch and then forwarded to the backplane of the vswitch, finally, the data frame is forwarded through the outbound interface. Note that the control plane is not directly involved in data Frame Forwarding during this process. So when the switch works normally, even during the peak traffic forwarding period, the CPU usage of the switch should be very low because it does not directly participate in traffic forwarding.

Figure 14.28 vswitch Architecture

Although the control layer does not directly participate in traffic forwarding, because the forwarding logic in the forwarding layer comes from the control layer, there is still a certain indirect relationship between the data Frame Forwarding and control layer. In this case, if there is a sustained high load at the control layer, for example, the CPU usage is too high, this will affect the data forwarding rate of the switch. Therefore, in terms of the switch architecture, the control layer does not affect the performance of the switch, but the control layer must also be considered in troubleshooting.

The forwarding logic of a vswitch is embodied in a dedicated memory called TCAM. When TCAM is combined with the cef function of the vswitch, the data forwarding speed will be very fast, but once the forwarding logic fails, for example: if TCAM memory overflow occurs, the forwarding logic cannot forward traffic. At this time, the switch CPU completes the forwarding traffic, which increases the switch CPU overhead and reduces the forwarding capability. Or in other words, if the CPU usage of the switch is too high, it indicates that the switch has not used the forwarding logic to forward data frames, and the fault needs to be rectified in a timely manner.

This article is from the "untitled Christ" blog and will not be reproduced!