Join Telegram Study Group ▷
Network problems are often unique and sometimes difficult to resolve. Troubleshoot to deal with undesired things, usually only need to master conceptual knowledge, not knowledge of the details needed to configure the network. To solve the problem correctly and smoothly, you need to have a clear understanding of the entire LAN, understand the network cabling, electrical environment, how TCP/IP is on the network, on a single host, routing data between layers of the protocol stack, etc. These are very important for overhauling the network and very helpful to know the troubleshooting portion of Cisco certification or other IT part.
Some of the following tips are useful in troubleshooting network problems:
1. Don't ignore the obvious things. Loose network cables are a common problem. Plugs, connectors, cables, hubs, and switches should be checked. Small things can cause major problems.
2. Most problems are caused by human factors (errors). By providing network configuration and role information or providing training in this area, most of the errors can be eliminated.
3, should pay attention to the way to solve the problem, should use the information collected during each test to guide your test, if you can not ensure the original test environment of your choice, do not transfer to another test environment based on subjective assumptions in.
4. You should broaden your thinking and be flexible. Don't think that there are too many reasons for the problem. Don't think that the problem found at the application level is not caused by the next level. Some people always think that the network is faulty, while others always think that there is a problem at the remote end. Some people are so sure that they know the cause of the problem, regardless of the test results. Don't repeat these mistakes. Test every possible situation and decide your actions based on the test results.
5. Use several simple troubleshooting tools. For most TCP/IP software problems, using a few simple tools is enough to solve the problem, and it's worth taking the time to learn how to use the new service tool. Since the causes of many network problems are simple, it is often possible to find an answer if you have a clear understanding of the problem. Unfortunately, this is not always the case! Here are a few simple tools that can help you solve the most difficult problems.
Ping: This command tool can be found on Linux/Unix, Dos, Windows 9x, Windows NT and other systems.
This tool can test if your system can reach a remote host. This simple feature is very useful for testing network connections, regardless of the application in which the problem is detected. Ping allows you to test the network connection layer (lower layer) or the application layer (higher layer). If the ping shows that the packet message can go to the remote system and return, the user's problem may be in the higher layer; if the packet message cannot be returned, the failure may be in the lower protocol layer or physical layer.
Use the user's host name or IP address to use the ping command on the remote host first. If the execution is successful, the user will use the ping command for the host. If the execution is successful, then you should concentrate on analyzing the user who is experiencing the problem. application.
If your ping command succeeds and the user's ping command fails, you can centrally test the user's system configuration file and compare the path you and the user to the remote host to find the differences.
If both you and the user's ping command fail, the error message displayed by the ping command is helpful and can guide you through the next test plan. Here are a few basic types of errors: unknow host The name of the remote host cannot be translated to an IP address by DNS (Domain Name Server), DNS may fail, the name may be incorrect, between your system and the remote server The network may be out of order. If you know the IP address of the remote host, you can try the ping command again. If the host can be reached with its IP address, the problem may be with the DNS.
Network unreachable The local system does not have a route to the remote system. If you use an IP address in the ping command, re-enter the ping command with the host name, which eliminates the possibility of entering an incorrect IP address. If you use a routing protocol, make sure it is running and use nestat to check its routing table.
No answer The remote system is not responding. Most network utilities have different forms of similar information. Some systems can print pings to 100% packet loss and telnet to connection timeout. All of these error messages indicate the same problem: The local system has a route to the remote system, but it does not receive any packet message responses it sends to the remote system. There are many reasons for this problem, the remote host may not work, the local or remote host may be misconfigured, the line between the local and remote hosts is abnormal, and so on. Only other methods can be used to isolate the cause of the problem.
A lot of tongues were abolished, and finally the reason for "UNPING" came to the fore. I didn't understand it even more deeply. Please bear with me. Let's continue to see what the content of the ping shows after it has been pinged.
The basic format of the ping command is: ping host [packetsize][count] (different systems, slightly different format) host is the host name or IP address of the remote host being tested. Packetsize is optional and defines the length of the test packet (Byte), which is only used when the count field is used. However, the packet length is 56 Byte, and count is the number of packets sent during the test. Count is generally set to a lower value, generally set to 4 or 5.
To test whether you can reach ly from Link, use the following command: C:>ping ly Pinging ly [222.222.222.15] with 32 bytes of data: Reply from 222.222.222.15:bytes=32 time=1ms TTL=128
Reply from 222.222.222.15:bytes=32 time=1ms TTL=128
Reply from 222.222.222.15:bytes=32 time=1ms TTL=128
Reply from 222.222.222.15:bytes=32 time=1ms TTL=128
Ping statistics for 222.222.222.15:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip in in milli-seconds:
Minimun = 1ms, Maximum = 1ms, Average = 1ms This test indicates that the link to ly connection is very normal, no packets are lost, and the response is fast. The round trip between link and ly takes an average of 1 millisecond. For LAN connections, the less packet loss and the smaller the round trip time, the more normal. TTL ( Time To Live ) = 128. The statistics displayed by the ping command can indicate the next level of network problems. The key statistics are: * How long does it take for a packet to travel back and forth, which is displayed after time=.
* The percentage of packet loss. It is displayed in the total statistics line at the end of the ping output.
* The order in which the packets arrive. Such as the ICMP sequence number ( icmp_seq ) of each packet.
If the packet loss rate is high, the response time is very slow, or the packets arrive out of order, then there is a possibility that the hardware is faulty; of course, if these situations occur on the WAN, you don't have to worry too much.
In the local network, the round-trip time is approximately equal to 1 millisecond, with little or no packet loss, and each packet should arrive in order.
If not, then there is a problem with the network hardware. In Ethernet it may be due to: Unsuitable cable termination (termination resistance), poor cable, poor active hardware ( Hub, etc.). First check the cable termination, It's so easy, and see if there is a terminating resistor. This is one of the most common and simple ways to detect a cable by measuring the resistance of a port with a multimeter. If the measured port resistance is zero, the cable is short-circuited, and the circuit is open for infinity. A 50 ohm or so indicates that there is a terminating resistor falling off, which should be about 25 ohms.
The result of a simple ping test, even if the test passes, will guide you through further testing to help you find the most likely problem. But to drill down into the problem and find the underlying cause, you need additional diagnostic tools.
Finally, a few useful tools are briefly introduced: netstat provides a variety of information, usually used to display detailed statistics for each network interface, network socket, network routing table, and so on.
Arp provides information about Ethernet IP address translation, which can be used to detect systems in the local network that are configured with the wrong IP address.
Ifconfig provides basic configuration information for the interface. It is useful for detecting incorrect IP addresses, subnet masks, and broadcast addresses.
