Fault Diagnosis of Switching Network Environment (1)

In an exchange network, how do you determine where to start searching for problems? It is very difficult to look into a "Perspective" exchange network. First, the two-layer switch still uses the bridging forwarding method, but the three-layer switch has more advanced features and forwarding rules, such as VLAN. In layer-4 switching, it is even more complicated. With more advanced forwarding and load balancing technologies, more Switch configuration knowledge is required for fault diagnosis and troubleshooting.

After a vswitch is installed, the half-duplex port of each vswitch constitutes a conflict domain. If the port is connected to a hub and several sites are connected under the hub, the conflict domain will expand. However, as the price of switching products declines, most newly created networks now have only one site connected to each switching port. Therefore, in a half-duplex connection, the conflicted domain is only for a single cable link.

A vswitch is usually part of an independent broadcast domain, including any number of other switches connected in series or connected. If the three layers of the OSI model are used, you can create multiple broadcast domains. The number of broadcast domains is equal to the number of VLANs. If the vswitch function permits, each port can be configured as an independent broadcast domain. This situation can be described as routing to the desktop. After creating an independent broadcast domain for each port, the fault diagnosis will be strictly limited. However, if we set each port as a separate broadcast domain, each port needs routing services when the switch forwards traffic, which will occupy limited resources of the switch CPU. In the network environment, it is very difficult to route requests and responses to each separate port. We should avoid such configuration. Unfortunately, this situation is very common in actual situations. In the network, we often find that all servers are in one subnet or broadcast domain, and all customers are in another Subnet or broadcast domain. In this case, all requests must be routed. If the maintenance behavior is restricted to a separate server group, consider placing the server in a separate VLAN. Then, users using this server are placed in the same VLAN. In this way, you can use a two-layer bridge to exchange traffic. Only a few requests require routing. If the server supports more than one user zone, you can install more than one network card on the server to achieve two-layer switch connection to the user.

Five technologies for vswitch Fault Diagnosis

You can use five basic methods to view the vswitch. Each method is different and has a positive or negative side. Similar to other problems encountered in the network, there is no best answer. The most appropriate solution often depends on the resources you can use or the tools you have installed before, and the use of these technologies may cause service interruption.

Even if these methods are combined, the connected network cannot be monitored. In the exchange environment, the monitoring is not as convenient as the hub. It is almost impossible to see all the traffic through one vswitch. Most Fault Diagnoses assume that the traffic passes between the site and the Connected Server or through the uplink port of the fault diagnosis switch. In fact, if two hosts directly transmit information, they will not use the uplink port of the switch or any other port to exchange traffic. Unless you know which port is used, it cannot be monitored.

For example, 1. A server is connected to a vswitch. Some of the users who report problems are directly connected to the vswitch, while others are connected by the uplink port of the vswitch from other vrouters or vswitches. Fault Reports are slow to access servers. Such fault reports are of little value to Technical Support Engineers.

, A basic vswitch Environment

Method 1: connect to the server through TELNET or serial port

When performing fault diagnosis, senior network technical support engineers or other persons who know the switch password can choose to Log On Through TELENET or the serial port of the switch to check the switch configuration. 2)

Figure 2 using a RS-232 control port

The vswitch configuration can be viewed in the two methods mentioned above, although the problem may not be caused by the configuration. No matter whether the problem is a BUG in the operating system or the configuration is incomplete, you cannot easily check the configuration list. Configuration information is useful in locating whether a vswitch is running as expected, but it is not for fault diagnosis. To verify the configuration of a vswitch, multiple fault diagnosis methods are often required.

Many vswitches are equipped with real-time fault diagnostic tools. Because of the differences between the manufacturer and model of the vswitch, the features of these troubleshooting tools are also different. However, to use these tools well, you must rely on some theoretical knowledge and practical experience.

Method 2: connect to an idle Port

The simplest troubleshooting method is to connect a monitoring tool, such as a protocol analyzer, to the idle port of the switch.

Figure 3 monitoring from any port

Connect the monitoring tool to an idle port of the vswitch to view the broadcast domain without interrupting the service. This monitoring tool has the same permissions as other sites in the broadcast domain.

Unfortunately, as a multi-port bridge device, the switch almost does not forward traffic to the monitoring port. Because the bridge device is designed in this way, the traffic is directly forwarded to the destination port, and no other ports are transferred. As a result, the protocol analyzer barely monitors traffic.

Figure 4. The switch forwards traffic between the source port and the destination port. A very small amount of traffic is forwarded to other ports. The site and server may forward several thousand frames per second, but the Monitoring port can only see several frames per minute.

Almost all the traffic forwarded to the monitoring port is broadcast, including sporadic frames with unknown destination addresses. These sporadic frames are due to the aging of the route forwarding table, and are often frames with unknown destination ports. Some technical staff who are not experienced enough can see that such a high broadcast speed is close to 100%), but did not notice that the port utilization rate is very low, so they may misjudge that a broadcast storm has occurred on the network. In fact, it is not.

In this way, it is almost useless to view the switching network, because the monitoring tool must obtain the traffic. The obtained traffic or query of broadcast domains is helpful for network search and other types of problems, but it does not help solve the problem of slow connection.

For most vswitches, there is a better option to back up the port traffic to be monitored to a dedicated idle port. This technology is usually called a port image.

Most switch manufacturers provide backup or image traffic functions. You can connect the monitoring tool to a specially configured port of the switch. The old switch must specify a dedicated monitoring port as the mirror port, but now most new switches can specify any port as the mirror port.

Although the image implementation methods of switch manufacturers vary, there are some similar monitoring options. It is worth noting that in almost all cases, when the switch forwards traffic to the mirror port, it also filters out errors. For fault diagnosis, this means that useful information is filtered out at the same time.

In addition, we need to configure the image through the RS232 port of the control port switch or the Telnet process. This means that in addition to monitoring tools, we usually need to bring a computer or terminal to configure the switch.

The mirror port is often only a "listener" port, but many switch manufacturers allow this port to be configured in full duplex mode. With the image port configured, the monitoring tool can view the backup of the actual traffic between the host and the server reporting slow connection. The Image Port can only monitor any port of the vswitch, or even Uplink port, or monitor multiple ports of the vswitch at the same time. However, if a large number of ports are monitored at the same time, excessive traffic may exceed the Image Port's reception capability.

Monitoring Port output capability is a very important issue. The image port can be received or sent. During configuration, the Image Port sending function is often disabled. However, whether or not the Image Port sending function is disabled, whether the Image Port is full-duplex or not, the Image Port's reception capability is limited. If the rate of the fully-duplex port to be monitored is the same as that of the mirror port, the switch will easily lose packets when forwarding traffic, but the switch will not notify you.

Assume that you are monitoring a server that is connected to a vswitch at a full rate of 100 M, when the server is working in full duplex, the server's sending and receiving rate is 200 M, then there will be a total of M. However, the M Image Port of the vswitch can only receive M of traffic at most. Therefore, when the full port utilization of any vswitch exceeds 50%, packets received by the mirror port will be lost.

If you mirror multiple ports to one port, packet loss will become more serious. Because most switches work at low capacity, this issue is not immediately noticed. The average usage of most user connections is low. Only occasional traffic spikes.

If you select a High-Speed Image Port, the packet loss problem can be reduced. For example, if you change the 1000 M Image Port in Figure 6 to M, you can easily receive M monitoring traffic.