How to solve switch faults quickly

Compared with vrouters, it is still troublesome to solve vswitch faults. So I have studied two simple troubleshooting methods. I will share them with you here, hoping to help you. In a switched network, it is often more difficult to troubleshoot a vswitch than to troubleshoot a vro. Although the working principle of a vro is much more complex than that of A vswitch. Today, I want to introduce some of my own vswitch maintenance experience and teach you two simple ways to troubleshoot vswitches. I hope this will help you.

1. Analyze network traffic using idle ports of vswitches

When network congestion or other problems occur, we first need to analyze some data traffic. Only after analysis can we remedy the problem and solve the problem quickly. For this reason, when I encounter a switch failure, I like to access a detection tool, such as a protocol analysis instrument, on the idle port of the switch. Connect the protocol analysis instrument directly to the idle port of the switch. In this case, you can view the broadcast domain of the switch without interrupting the current service. The network administrator can determine whether a network failure is caused by too many broadcast domains.

However, in actual work, there is also a small trick to note. As we all know, a vswitch is a layer-2 network device that forwards traffic to a broadcast domain, but does not forward other traffic. That is to say, a vswitch belongs to a large broadcast domain, not a conflict domain. Therefore, the switch does not distribute any valuable traffic to the monitored port. The switch forwards data traffic directly to the corresponding destination port. In these idle ports, protocol analysis instruments can only monitor broadcast packets, but cannot monitor other information traffic. Because almost all the traffic forwarded to the idle port (Monitoring Port) is broadcast, including some sporadic frames with unknown destination addresses. These sporadic frames are due to the aging of the route forwarding table. It can be seen that without special processing, even if the monitoring device is connected to the idle port, it can only discover infinite broadcast packets, rather than monitor other valuable information traffic.

The most expensive monitoring equipment must also be able to help our administrators find the crux of the problem when there is traffic. These monitoring devices cannot do anything without valuable traffic. To this end, our network administrator needs to find ways to handle the traffic passing through other ports on this idle port.

In this case, the port mirroring technology can help us solve this problem effectively. Port Mirroring backs up traffic from some ports to an idle port so that the idle port has the same information traffic. Cisco switches basically have this technology. Cisco switches can connect monitoring tools to a dedicated idle port. In earlier versions of Cisco, there may be limits on this port. However, for vswitches currently available in the market, you can configure any idle vswitch port to implement port mirroring technology.

However, you also need to pay attention to one problem. In order to improve the forwarding efficiency, the switch directly filters out some wrong packets and information when forwarding traffic. In normal times, this can significantly improve the efficiency of switch data forwarding. However, our network administrator does not want to see this situation during troubleshooting. This error message may indicate the crux of the problem. If you want to troubleshoot the network, you must change the configuration of the vswitch. However, after troubleshooting is completed, you need to promptly change this parameter back.

When monitoring the Image Port, you also need to pay attention to the packet loss problem. The output capability of the monitoring port is often an important factor that affects the final troubleshooting effect. The Image Port is the same as the common switch port. It can be received or sent. However, to simplify the monitoring data, we usually disable the packet sending function of the monitoring port When configuring the mirror port. The monitor can only analyze the received information traffic. Despite this configuration, the Image Port's receiving capability is still limited. If the rate of the fully-duplex port to be monitored is the same as that of the mirror port, the mirror port may lose packets when the switch forwards traffic. The traffic of the monitored port may exceed the receiving capacity of the Image Port. Therefore, although theoretically any idle port can be used as the mirror port. However, to reduce packet loss, the network administrator still needs to make some choices when preparing the Image Port. At least ensure that the performance of the Image Port is higher than that of the monitored port. This ensures that the monitor has a correct result.

Therefore, in order to reduce the occurrence of port packet loss, I have two suggestions. First, do not mirror the information traffic of multiple monitored ports to one port, which will aggravate packet loss. Second, when selecting an Image Port, it is best to select a high-speed idle port as the monitoring port.

2. Use a layer of equipment to help the monitor

Since the vswitch is a layer-2 device, it cannot forward all information traffic. So let's think, can we use a device, such as a hub, to help the monitor collect the required information? In fact, the network of many enterprises is a large broadcast domain. For example, we add a hub to a key link in the middle. Connect the network monitor to the idle port of the hub. In this case, the network monitor can collect the required network traffic without configuring the Image Port.

The difficulty of using this method is that the network administrator must select a proper location to place the hub. If you choose improperly, the network monitor still cannot collect the required content. Currently, most enterprises adopt network applications based on the server/client or server/browser mode. This is different from the previous network deployment mode. In the past, when an enterprise deployed a network, each host may have a shared folder for access by other employees. But now it is different. To improve the security and sharing of enterprise files, network administrators usually deploy a dedicated File Server to manage these shared files. Improve file security through a unified backup and File Access Authorization solution.

At this time, the traffic between the enterprise server and the customer segment is usually the most concentrated. If the network administrator deploys the hub on one end of the server and places the network monitor on the idle port of the hub, most of the network traffic can be monitored. So that the network monitor can produce a relatively reasonable diagnosis result. Deploying a hub and other network devices at one end of the server helps the network administrator collect data traffic from user logon failures, access conflicts, packet loss, and authentication failures, this provides data support for solving the problem. In this way, we can determine whether a fault has occurred on the switch side or another problem has occurred. As the saying goes, I don't know the true colors of the mountains, but I am born here. Sometimes, finding network faults out of the switch can help our network administrator quickly locate the switch fault. In addition, so far, this is also the only method I know that can be used to view and analyze physical address layer errors in a switched network environment. This method can be used to identify whether IP Address Resolution errors exist in network devices such as switches. Especially for discovering ARP attacks. However, using hubs to identify faults of Cisco switches still has some defects.

First, frequent plugging and removal of hubs may cause daily network access problems. Because it is impossible for the network administrator to place an inefficient hub device between the server and the customer segment. This greatly reduces the server performance. The network administrator can temporarily deploy a hub between the server and the customer segment only when the network is faulty and requires maintenance. In this case, you need to temporarily interrupt network access and establish a connection.

Second, if the working status of the hub port is different from that of other adjacent devices, for example, if the server link is not full-duplex or does not match the duplex status of the hub port, instead, it will bring many additional error results. These error results will confuse the network administrator's ideas for solving the problem. Therefore, the author suggests that if you want to use a hub to identify the switch failure, it is best to confirm that the working status of the hub port matches the existing network before this. Avoid unnecessary troubles due to non-matching.

Third, the network administrator can only passively use this method. It is silly to place a hub near the server. Therefore, network administrators usually deploy a hub only when a problem occurs for network troubleshooting. Therefore, this network monitoring cannot be a daily behavior. Therefore, this method is relatively passive for network administrators.

The preceding two troubleshooting methods are often used in the enterprise network composed of vswitches. These two methods can help the network administrator solve most of the network problems caused by switch faults. However, in practice, some switch faults cannot be solved in this way. However, the network administrator's experience is required to discover the problem. After all, relying on existing technologies and tools, it is almost impossible to look at the entire enterprise exchange network in some simple ways.