In-depth analysis of traceroute by using the tcpdump command, tcpdumptraceroute

In-depth analysis of traceroute by using the tcpdump command, tcpdumptraceroute
Yesterday, I was suddenly asked about the traceroute principle. I couldn't say it for a while. Although some commands are often used, I really don't know the actual principle. I will take this opportunity to sort it out.

Traceroute: indicates the routing commands used to analyze IP packets in Network diagnosis. Preschool knowledge:The IP packet has a field TTL, which is the maximum number of jumps. Each time a router passes through, the value is-1. When the value is 0, the packet will be discarded by the router, and return the ICMP-Timeout packet to the Request Host. Implementation principle:1. traceroute first sends out three UDP packets (the three packets are mainly sent for statistics, so you don't need to worry too much here). The TTL field is 1 and the destination is the IP address of the target host, when the UDP packet passes through vro1-1, the TTL value is set to 0. The packet is discarded and ICMP-timeout is returned to the Request Host; 2. When receiving the "ICMP-Timeout" packet sent from vro1 1, traceroute will continue to issue three UDP packets, and its TTL field is set to 2, the UDP packet passes through vro1-1 smoothly. When vro2-2 is reached, the TTL value is 0 and is discarded. The ICMP-Timeout packet is returned to the requesting host; ............ Continue to repeat. Each time you receive a packet that returns ICMP-Timeout, The UDP packet with TTL value + 1 is sent. 3. After going through four routers, the UDP packet with TTL = 5 has finally arrived at the destination host, and you may feel that the destination host will accept the UDP packet with pleasure, but it is not, the target host is processed as follows:

• Discard (do not know you, dog belt)

• Return ICMP-destination inaccessibility package to Request Host

It may be strange to everyone. Why is it discarded? Simply put, the host does not listen to the UDP port process. 4. Request the traceroute program of the host to finish the work after receiving the ICMP-destination unattainable packet.

The following uses the tcpdump command to verify the traceroute process.

  [UDP packet] [ICMP-Timeout packet returned by the vro] [ICMP-destination inaccessible packet returned by the target host]1. Use commands to listen to packets related to the target host

tcpdump -i eno33554984 -vvnn host 119.146.184.98

2. Use the traceroute command to initiate a request to the target host

[Root @ www ~] # Traceroute failed to 119.146.184.98 (119.146.184.98), 30 hops max, 60 byte packets 1 192.168.0.1 (192.168.0.1) 2.217 MS 1.741 MS 1.509 MS 2 116.24.132.1 (116.24.132.1) 11.348 MS 11.117 MS 11.287 MS 3 113.106.47.93 (113.106.47.93) 7.111 MS 6.848 MS 7.123 MS 4 cores (59.38.107.5) 6.921 MS 6.712 MS 5 183.59.12.153 (183.59.12.153) 6.434 35 MS 7.664 MS 7.593 MS 6 183.61.222.102 (183.61.222.102) 11.923 MS 10.220 MS 9.423 MS 7 MS 15.779 MS 119.146.184.94 (119.146.184.94) 47.902 119.146.184.62 (119.146.184.62) 16.571 ms ##################################### return result explanation: # Column 1: [1] Route number; # column 2: [192.168.0.1] router IP address (also called Gateway); # column 3: [(113.106.47.93)] that is, the content in the brackets, the specific purpose is unknown, you can understand the ha; # column 4: [7.111 MS] return time, here can also be found, a total of 3 time, remember? Traceroute sends three UDP packets each time. Note that the last column contains three addresses, which is not hard to understand, A vro will find a proper path based on the actual situation;

3. Now let's take a look at the tcpdump collection results and observe the UDP packets sent by the Request Host.

18:56:27. 892318 IP (tos 0x0, ttl 1, id 10584, offset 0, flags [none], proto UDP (17), length 60) 192.168.0.200.39914> 119.146.184.98.33434: [bad udp cksum 0xf19e-> 0 xfaae!] UDP, length 3218: 56: 27.892798 IP (tos 0x0, ttl 1, id 10585, offset 0, flags [none], proto UDP (17), length 60) 192.168.0.200.38541> 119.146.184.98.33435: [bad udp cksum 0xf19e-> 0x000b!] UDP, length 3218: 56: 27.893869 IP (tos 0x0, ttl 1, id 10586, offset 0, flags [none], proto UDP (17), length 60) ##################################### explanation of returned results: # We can see that our host sends a UDP packet with TTL = 1 to 119.146.184.98, and there are three. You can be surprised here, not to say that the gateway will return an ICMP-Timeout packet? Why not? # Why? # Because the packet ICMP-timeout is not returned by 119.146.184.98, who returned it? Recall the above! Yes, router! Therefore, we need to use tcpdump to specify the ip address of the router to capture packets.

4. Observe the ICMP-Timeout packet returned by the vro.

Tcpdump-I eno33554984-vvnn host 116.24.132.1 # tip: After executing this command, you need to re-execute the traceroute 119.146.184.98 command to further observe the packets returned by 116.24.132.1 at 19:02:26. 210530 IP (tos 0xc0, ttl 254, id 52121, offset 0, flags [none], proto ICMP (1), length 56) 116.24.132.1> 192.168.0.200: ICMP time exceeded in-transit, length 36IP (tos 0x0, ttl 1, id 10619, offset 0, flags [none], proto UDP (17), length 60) 192.168.0.200.43604> 119.146.184 . 98.33437: UDP, length 32 ##################################### return result explanation: # Here we chose to collect data packets from the second hop router address 116.24.132.1 (why not use the first hop? Because the first hop is usually the router address of the home, there will be a lot of packets for this address, and it is not easy to observe the experiment # result) # From the returned results, we can see that the second hop router indeed returns the ICMP time exceeded packet. There are actually three, so we will not list them one by one.

5. Observe the ICMP-destination inaccessibility package returned by the target host.

# In [root @ www ~ /Test_traceroute] # view the result returned by the tcpdump-I eno33554984-vvnn host 119.146.184.98 command at 18:56:27. 972224 IP (tos 0x0, ttl 248, id 20689, offset 0, flags [none], proto ICMP (1), length 56) 119.146.184.98> 192.168.0.200: ICMP 119.146.184.98 udp port 33455 unreachable, length 36 IP (tos 0x0, ttl 2, id 10605, offset 0, flags [none], proto UDP (17), length 60) 192.168.0.200.56215> 119.146.184.98.33455: UDP, lengt H 32 ##################################### return result explanation: # You can see the ICMP 119.146.184.98 udp port 33455 unreachable at the end of the returned result.

 

 

Finally, let's summarize the Analysis of Common traceroute returned results: 1. When you are practicing, you may first think of using some well-known websites for testing, next we will test it with an IP address of Baidu.

[Root @ www ~] # Traceroute-m 10 failed to 14.215.177.38 (14.215.177.38), 10 hops max, 60 byte packets 1 192.168.0.1 (192.168.0.1) 2.395 MS 2.063 MS 1.583 MS 2 116.24.132.1 (116.24.132.1) 36.296 MS 36.939 MS 36.706 MS 3 diameter (183.56.71.225) 6.550 MS 6.304 MS 6.396 MS 4 183.56.66.93 (183.56.66.93) 5.716 MS 5.491 MS 5 183.56.64.50 (183.56.64.50) 8.059 MS 7.733 MS 7.513 MS 6 *** 7 14.29.121.194 (14.29.121.194) 9.082 MS 14.29.121.198 (14.29.121.198) 8.977 MS 14.29.121.206 (14.29.121.206) 9.700 MS 8 *** 9 *** 10 ***########################## ######### explanation of returned results: * indicates that the Outbound UDP packet does not receive the corresponding ICMP-Timeout packet. This is mainly because the ICMP-Timeout packet is rejected for some vro security reasons.

So we can see that the sixth hop record is "*", indicating that the sixth hop router did not return an ICMP-Timeout packet.

There are also the following questions:
Why does traceroute continue to be detected? (We specify the 10-hop detection parameter in the Command). If you are patient, you can specify the-m 128 parameter, and the traceroute will never end automatically, each time, all detection times need to be exhausted.

2. Why * is returned during the 8-9 10 hop? Let's reasonably guess:

• In my network, it takes at least 7 hops to access the Baidu website. After Article 7, the UDP packet with TTL = 8 may have arrived at the Baidu host, so why is traceroute not over?

• A reasonable assumption is that the host of Baidu 14.215.177.38 directly discards our UDP packet and refuses to return the ICMP-destination inaccessible packet;

• Because traceroute has never received the ICMP-destination unreachable packet, it will generate a UDP packet and add the TTL value until the number of detection hops we specified is reached (in this example, the number of hops we specify = 10 ).

• You can also use the following command:

[root@www ~/test_traceroute]#tcpdump -i eno33554984 -vvnn  host 14.215.177.38

This command can collect the related packages of 14.215.177.38. We can see that only the sent package does not return the package, and we can basically verify our speculation.