Network Fault stratified troubleshooting-New Network Analysis ideas

To reduce design complexity and enhance versatility and compatibility, computer networks are designed as hierarchies. This hierarchical system enables a variety of different hardware systems and software systems to easily connect to the network. When analyzing and troubleshooting network faults, administrators should make full use of the layered features of the network to quickly and accurately locate and eliminate faults. However, in the actual troubleshooting process, this layered method is often ignored, resulting in reduced troubleshooting efficiency.

Two layer-by-layer troubleshooting methods

The OSI hierarchy provides an excellent way for administrators to analyze and troubleshoot faults. Because each layer is relatively independent, layer-by-layer troubleshooting can effectively detect and isolate faults. Therefore, layer-by-layer analysis and troubleshooting are generally used.

There are usually two layer-by-layer troubleshooting methods. One is to troubleshoot from the lower layer, which is suitable for situations where the physical network is not mature and stable enough, such as creating a new network, re-Adjusting Network cables, and adding new network devices. The other is to start troubleshooting from a high level, which is suitable for the relatively mature and stable physical networks, if the hardware is not changed. Either way, the goal can be achieved, but the efficiency of solving the problem is different.

Select the troubleshooting method based on the actual situation

You can select the specific method based on the actual situation. For example, when a client cannot access the Web service, it is too pessimistic if the administrator first checks the connection cable of the network, unless he knows that the network line has changed. The better choice is to start directly from the application layer, so you can check: First, check whether the client Web browser is correctly configured, you can try to access another Web server using the browser; if the Web browser is no problem, you can test whether the Web server runs normally on the Web server. If there is no problem with the Web server, test the network connectivity. Even Web server problems can be solved by layer-by-layer troubleshooting from the underlying layer, but it takes too much time. If it happens to be a line problem, it will be a waste of time to troubleshoot it layer by layer from the top.

In practical applications, there are often trade-offs. If an application involves network communication problems, you can directly troubleshoot the problem from the intermediate network layer. First, test network connectivity. If the network cannot be connected, check again from the physical layer test line); if the network can be connected, then test the application itself from the application layer) to start troubleshooting.

First, use the ping command to test connectivity. In TCP/IP networks, the first step in network troubleshooting is to use the ping command. If the remote host can be successfully pinged, the possibility of a network connection failure is ruled out. Even if you use the ping command, you can perform a step-by-step detection and determination.

Figure 1 Network

For example, if there is a network shown in 1, we need to test whether the network can communicate normally. Generally, ping host B on host A from the beginning of the ping remote computer). Success indicates that the system and network are normal. Failure indicates that the host is offline or the network is faulty. After the failure, ping the gateway in the same subnet for 192.168.1.1) to check whether host A can connect to the vro. After the failure, ping the loopback address 127.0.0.1 to check whether the TCP/IP software is faulty. If the problem persists, re-install the TCP/IP software. You can also take another step, starting from pinging the loopback address 127.0.0.1. Failure indicates that the TCP/IP protocol software installation is faulty. If you successfully ping the gateway of the same subnet, if other gateway routers are successfully pinged, check the network until the remote host is finally pinged. As long as the remote host is successfully pinged, you can determine that network problems generally occur at a higher level.

Network Layer troubleshooting measures

Figure 2 network layer troubleshooting measures

Each network layer has corresponding detection and troubleshooting tools and measures, as shown in basic troubleshooting measures 2 at each layer. At the bottom layer of the physical layer, professionals often use dedicated cable testers. If there is no tester, they can use network adapters, switches, and other signal lights for visual testing. There are not many problems at the data link layer. For TCP/IP networks, you can use simple arp commands to check the physical addresses of MAC addresses) and the ing between IP addresses. The network layer is more likely to have problems, and the routing configuration is prone to errors. You can use the route command to test whether the route path is correct, or use the ping command to test connectivity. Protocol analyzer, such as the network monitor provided by Microsoft, has strong detection and troubleshooting capabilities. It can analyze data communication at the link layer and above, including the transmission layer. As for the application layer, you can use the application itself for testing.