Solution to a network problem

Network Environment:

Premise: all involved machines are allowed to be pinged. Only the machines in hand are allowed.
Problem description: Ping 10.11.12.13 on the PC, but cannot connect, but can ping 10.11.12.13 on the router.
Troubleshooting process:
1. Make sure that the ip_forward of the vro is 1.
Conclusion: The router can be routed.
2. confirm that the router is configured with the correct route and Nat, and clear the filter table of the router iptables.
Conclusion: The router fault can be temporarily ignored.
3. Ping 10.11.12.13 again on the PC after 2.
Conclusion: PC is a problem in general.
4. delete any route except 10.11.12.13 on the server on the PC and confirm that there is only one route to the Internet.
Objective: to remove as many interference factors as possible.
5. ping the vroping on the PC and capture ICMP packets on the PC and vro at the same time. The Ping succeeds and packets are successfully captured on the PC, no packets are captured on the vro。 (the-e-VV parameter must be added to tcpdump to display the Ethernet header ).
Conclusion: A. The route takes effect;
B. It may be an IP address conflict, but the Router network protocol stack failure is not ruled out.
6. analyze the Ethernet header in the result of tcpdump in Step 6 and execute the ARP command. The MAC address of the target address is, then run IP link show or ifconfig on the vro。 to obtain the MAC addresses of the IP addresses ranging from B, A and B.
Conclusion: The data packet is sent to the wrong destination.
7. Clear the ARP cache on the PC, run Ping 192.168.1.1 again, capture the ARP packet on the PC and vro, and send an ARP request. Two ARP reply packets are returned in the same LAN.
Conclusion: there must be an IP conflict in the LAN, and a problem is located, but other problems are not identified, leading to network failure.
8. clear the ARP cache of the PC, and then use the ARP command to forcibly configure the ARP cache instead of letting the PC learn automatically: ARP-s "192.168.1.1" B (B in Step 6), and then Ping 192.168.1.1 again, ping 10.11.12.13.
Conclusion: The problem of network disconnection is indeed caused by IP conflicts and ARP learning errors.
Note: As we cannot determine the location and purpose of the host that conflicts with the vro, we cannot unplugging the host that conflicts with the vro, because we do not know the detailed network IP address configuration, if the IP address of the vro is modified, a new IP address conflict may be introduced. Therefore, the IP address of the vro cannot be modified. Therefore, you can only set ARP ing to locate the problem, in practice, force ARP ing should be avoided. ARP processes, including learning, caching, and invalidation, will be implemented in almost all implementations of the TCP/IP protocol stack of the OS kernel.
Note: You can use the traceroute command to view the data path, but printing a "*" row at a certain hop does not indicate that the link is disconnected, however, it may be because the intermediate router shields the ICMP response of TTL death or the response times out. Therefore, if traceroute fails, you must adopt another troubleshooting scheme. The principle of traceroute is listed below:
Essentially, in Linux, traceroute is implemented by UDP, And the destination port uses a large port. The execution process of traceroute is actually a series of TTL dead processes. First, the source host sends a UDP packet whose TTL is 1, and then arrives at the first hop to the destination address. before forwarding, after the TTL is reduced, the TTL is 0. Therefore, when the source host receives a TTL-dead ICMP report, it is regarded as the first hop and printed, next, send a UDP packet whose TTL is n ++ (n> 1... Traceroute has a waiting time parameter-W waittime, and each TTL repeat parameter-Q nqueries. Generally, by default, each TTL attempts to send three UDP packets, each waiting for the waittime, if you do not respond to ICMP at one time, a "*" will be printed. If nqueries does not respond to ICMP at one time, the TTL + 1 will continue, therefore, if all the routers along the road shield the response of TTL dead or the interval between sending UDP packets and sending TTL dead response from the intermediate router is greater than waittime (this is possible, many routers take the response to this ICMP packet as an additional action, so it is often scheduled to run in a kernel thread with a lower priority, then the source host will completely print "***...", However, the final link is still accessible. When the data arrives at the destination, a message indicating "port inaccessible" will be returned. If you want to try the preceding description, run traceroute w-w m-Q n, W is as far as possible, not easy to reach, M is as small as possible, n is random, the result is almost a lot of rows "*", N rows, if the network to W is abnormal, in short, traceroute can only give a general route, not the only one, or even execute traceroute at the same time, when the TTL value is n + 1, the routes used when the TTL value is N may be different. In Windows, tracert sends an ICMP request packet and stops when it receives ICMP reply. It is not implemented through UDP, but the TTL death mechanism is consistent with that in Linux.
Therefore, the commands used in network troubleshooting are traceroute/tracert, netstat, ping, iptables, route, ifconfig, IP, ARP, and tcpdump.