Fault diagnosis skill of switch in network

In a switched network, how do you decide where to start looking for problems? It is very difficult to delve into the "perspective" of a switched network. First of all, in the 2-tier exchange or bridge forwarding, but to the 3-tier exchange has more advanced features and forwarding rules, such as VLANs.

To the 4-tier exchange, it is more complex, there are more advanced forwarding and load balancing technology, fault diagnosis and resolution of troubleshooting needs more knowledge of switch configuration.

After a switch is installed, the Half-duplex port on each switch constitutes a conflict domain. If the port is connected to a hub and a number of sites are connected under the hub, the conflict domain expands. But with the price of exchange products falling, most newly created networks now connect only one site to each switch port. Therefore, in the case of a Half-duplex connection, the conflict domain is only for a single cable link.

A switch is usually part of a stand-alone broadcast domain, including any number of other switches that are concatenated or connected. If you use the OSI Model Layer 3 feature, you can create a multicast domain with the number of broadcast domains equal to the number of VLANs. In the extreme case, each port can be configured as a separate broadcast domain if the switch function allows. This situation can be described as routing to the Desktop. When you create a separate broadcast domain for each port, troubleshooting is strictly restricted. However, if we set each port as a separate broadcast domain, the switch will require routing services for each port when forwarding traffic, which consumes the limited resources of the switch CPU. In a networked environment, it is very difficult to route requests and responses to each individual port, and we should avoid such a configuration. Unfortunately, this situation is very common in the actual situation, the network often found that the server is all in a subnet or broadcast domain, all customers in another subnet or broadcast domain. In this case, all requests must be routed. If the maintenance behavior is limited to a single server farm, consider putting the server in a separate VLAN. The user who uses this server is then placed on the same VLAN. This allows you to exchange traffic using a 2-tier interchange bridge, with only a few requests requiring routing. If the server supports more than one user area, you can install a single NIC on the server to achieve a 2-tier switching connection to the user.

5 Techniques for fault diagnosis of switches

There are 5 basic ways to pivot the switch. Each method is different, there is a positive or negative side. Like other problems encountered in the network, there is no best answer. The most appropriate scenarios often depend on the resources available to you (what tools can be used or what tools have been installed previously), and the use of these technologies may result in service disruption.

Even if these methods are combined, it is not possible to monitor the connected network and, in the Exchange environment, it is not as convenient to monitor as a hub. It is almost impossible to see all the traffic through a switch. Most troubleshooting assumes that traffic passes between the site and the connected server, or through the uplink switch. In fact, if 2 hosts directly transmit information, they will not use the switch's uplink port or any other ports to exchange traffic. It is not monitored unless you know which port to use.

For example, as shown in Figure 1, a server is plugged into a single switch. Some of the users who are reflecting the problem are connected directly to the switch, and the other part of the user is connected to the uplink port of the switch from another router or switch. Failure reporting is a "slow" access server, which is essentially worthless to technical support engineers.

Figure de jure the most basic switch environment

Method 1: Access the server via Telnet or serial port

Advanced Network technical Support engineers or other people who know the switch password can choose to check the configuration of the switch by Telenet or the serial port of the switch when troubleshooting. (Figure 2)

Figure 2, using the RS-232 control port

The switch configuration can be viewed through the 2 methods mentioned above, although the problem is not necessarily caused by configuration. Whether the problem is an operating system bug or an imperfect configuration, it is not easy to view from the configuration list. Configuration information is useful for locating switches to run as expected, but not for troubleshooting. In order to verify the configuration of the switch, it is often necessary to use a variety of switch fault diagnosis methods.

Many switches are equipped with real-time troubleshooting tools, and the characteristics of these troubleshooting tools vary, depending on the manufacturer and model of the switch. But to use these tools, we must rely on a certain amount of theoretical knowledge and practical experience.

Method 2: Connect to an idle port

The simplest method of troubleshooting is to access a monitoring tool, such as a protocol analyzer, on the free port of the switch.

Figure 3, monitoring from any port

Access the monitoring tool to a free port on the switch and view the owning broadcast domain without interrupting the service. The monitoring tool has the same permissions as other sites in the broadcast domain.

Unfortunately, the switch (which is a bridging device for a multiport port) hardly forwards traffic to the monitoring ports. Because the bridge device is designed this way, the traffic is forwarded directly to the destination port and does not go to the other ports. The protocol analyzer therefore almost does not monitor traffic.

Figure 4, the switch forwards traffic between the source port and the destination port. Very little traffic will go to other ports. Thousands of frames may be forwarded between the site and the server every second, but the monitoring port can see only a few frames per minute.

The traffic forwarded to the monitoring port is almost entirely broadcast, containing a number of frames with unknown destination addresses. These sporadic frames are the result of a routing-forwarding aging, often a frame with an unknown destination port. Some inexperienced technicians see such a high broadcast (close to 100%), but do not notice that the port utilization is very low, it is wrong to misjudge the network broadcast storm, in fact, is not.

It is almost useless to view a switched network, because the monitoring tool must obtain traffic. The flow of traffic, or queries against broadcast domains, can be useful for searching the web and discovering other types of problems, but it does not help to solve the problem of slow user connections.

For most switches, there is a better option to back up the port traffic that needs to be monitored to a dedicated idle port. This technique is often referred to as Port mirroring.

Most switch manufacturers provide backup or mirrored traffic, and they can connect the monitoring tool to a specially configured port on the switch. The old switch must designate a dedicated monitoring port as the mirror port, but now most new switches can designate any one port as the mirror port.

Although the way the switch manufacturers implement mirroring is different, there are some basic same monitoring options. It is worth noting that in almost all cases, the switch filters out the errors while forwarding traffic to the mirror. For fault diagnosis, this means filtering out useful information at the same time.

In addition, the actual operation requires us to configure mirroring via the control port (the RS232 port of the switch) or the Telnet process. This means that in addition to monitoring tools, we usually need to bring a computer or a terminal to configure the switch.