Causes of Network Breakdown
- Small problems cause a lot of faults. Is it easy to ignore our troubleshooting? For example, loose network cables are a common problem. Check plugs, connectors, cables, hubs, and switches. Small things can cause big problems.
- Most network failure problems are caused by human factors (errors). By providing network configuration and role information or providing training in this area, most of these errors can be eliminated.
- Pay attention to the way to solve the problem. The information collected during each test should be used to guide your analysis. If you cannot ensure the original test environment you choose, you should never move to another test environment based on your assumption.
- Be open-minded and flexible. Don’t think that the cause of the problem is too much, and don’t believe that the next level does not cause the question found at the application level. Some people always think that the network is faulty, while others still consider that there is a problem on the far side. Some people are so sure that they know the cause of the problem so that they don’t care about the test results. Don’t repeat these mistakes; you should test every possible situation and decide your actions based on the test results.
- Use several simple troubleshooting tools. For most TCP / IP software problems, several simple tools are sufficient to solve the problem, and it is worthwhile to spend some time learning how to use the new maintenance tools. Because the causes of many network problems are straightforward, it is often possible to find an answer with a clear understanding of the problem.
The following introduces a simple tool that can help you overcome the most challenging problems:
Ping
This command tool can be found under Linux / Unix, Dos, Windows 9x, Windows NT, and other systems.
This tool can test whether your system can reach a remote host. The simple function is beneficial for testing the network connection regardless of the application in which the problem is detected.
Ping allows you to test whether the network connection layer (lower layer) or application layer (higher tier) is the next step.
If ping shows that the packet message can reach the remote system and return, the user’s problem may be in the higher layer; if the packet message cannot be returned for transmission, the failure may be in the lower protocol layer or physical layer.
When Using the user’s hostname or IP address, you can first use the ping command on the remote host. If the execution is successful, the user will use the ping command on the host; if the performance is successful, then you should concentrate on analyzing the user’s problem application.
If your ping command is executed successfully, but the user’s ping command fails, you can focus on testing the user’s system configuration file, and compare the path between you and the user to the remote host to find their differences.
If both you and the user’s ping command fails, the error message displayed by the ping command is beneficial and can guide you through the next test plan.
There are several basic types of errors:
unknow host
The name of the remote host cannot be converted into an IP address by DNS (Domain Name Server). DNS may be faulty. The name may be incorrect. The network between your system and the remote server may be wrong. If you know the IP address of the remote host, you can try the ping command again. If it can reach the host using its IP address, the problem may be in DNS.
Network unreachable
The local system has no route to the remote system. If the IP address is used in the ping command, then use the hostname to re-enter the ping command, which eliminates the possibility of entering an incorrect IP address. If you use a routing protocol, make sure it is running and use estat to check its routing table.
no answer
The remote system is not responding. Most network utilities have similar information in different forms. The ping command of some systems can be printed as 100% packet loss and telnet as connection timeout.
All these error messages indicate the same problem: the local system has a route to the remote system, but it cannot receive any packet message response to the remote system.
There are many reasons for this problem, the remote host may not work, the local or remote host may be improperly configured, and the line between the local and remote hosts is abnormal.
Comments