Tracert vs traceroute
What is the difference between the package route and its path?
The standard packet routing mechanism on the Internet is per hop behavior — that is, each node in the network decides where to send the packet based on information obtained from dynamic routing protocols and routes that are statically specified by administrators.
The route is the interface to which we need to send a packet to reach some destination node and the address of the next router (next-hop):
What is the path? A path is a list of nodes through which a packet passes (passes):
The package path can be viewed using the tracert utilities in Windows OS and traceroute in GNU / Linux and Unix-like systems. (other commands, such as tracepath, we do not consider).
Many people believe that these utilities are the same principle of operation, but this is not so. Let's see.
So, the utility tracert.
The basis of this utility is the icmp protocol. Consider the following scheme:
Host sends an ICMP Echo-Request with ttl 1 to the ICMP Echo-Request specified in its routing table. After receiving such a packet, check the destination address — maybe a packet to it. Since this packet is addressed to another host, Router1 considers itself a transit node, decrements the ttl packet and discards it, since the packet lifetime becomes 0. Since the packet was dropped, Router1 sends a message to the source of the icmp packet indicating the cause of the drop - Time Exceeded . The tracert utility, having received this icmp message, specifies Router1 as the first hop (address information is specified in the icmp message). Then the process is repeated with incrementing ttl, until the request ttl icmp is equal to the number of hopes between the sending node and the receiving node. In this example, Server1 is the destination node. After receiving the packet, he will check the destination address, see that the request is addressed to him and send ICMP Echo-Reply, which will be a trigger for the tracert utility by the end of the trace.
')
Conclusion:
Icmp is a third-level protocol, and he knows nothing about ports. Therefore, it is impossible to make a tracert indicating the port. I hope we figured out here.
Traceroute - this utility works on a different principle, although the output of the command is similar to the output of the previous one.
Traceroute is not based on ICMP Echo-Request, but on sending udp fragments and receiving a message about port availability / unreachability. Let's go back to the previous scheme. Host generates a udp fragment, encapsulates it into an IP packet, and sets ttl = 1. Router1, being a transit node, will respond to this icmp packet with a message about the end of the packet's lifetime. The traceroute utility, upon receiving this message, indicates the source address of the icmp packet (Router1) as the address of the first hop. Then the process is repeated with incrementing the ttl package. Everything is almost the same as in tracert. But we don’t send ICMP Echo-Request, how will the traceroute utility understand that tracing is finished? It's simple - in the udp header there are fields source and destination port. It is logical that the source port will be any port above 1023. And what should I specify the destination port? As mentioned above, the work of the traceroute utility is based on receiving a message about the unreachability or availability of the destination port. That is, we send a udp fragment from port 45000 (for example) to port 33434 (this is the default port used). As in the previous case, Server1 is the destination node. Having received the packet, it unpacks it and must transfer it to the highest level protocols. But since the default port 33434 will be closed on the server, Server1 generates an icmp message about the unavailability of the destination port (ICMP Type 3 "Destination Unreachable" Code 3 "Port Unreachable"). Upon receiving this message, the traceroute utility considers the trace complete. During the tracing process, the destination port number will be incremented on every attempt (33434, 33435 and so on). It may happen that the destination port is open. In this case, the server will send to the initiator host, for example, TCP ACK if TCP SYN packets are used for tracing, which will also trigger the end of the trace.
Conclusion:
The utility traceroute allows you to make a trace with the destination port.
To do this, consider the example below:
Take the previous scheme and make a trace:
Using TCP SYN packets:
Using UDP packets:
As you can see the tracing was successful. We see the path to the specified host.
And now we will hang the filter on in on the interface Router4 (as shown in the figure):
Trace again:
Now the tracing is over on the next-to-last hop and signs appear in the output! X. Why did this happen? Router4 receiving a packet to Server1 drops it, since it falls under the prohibiting rule on the incoming interface and sends a message to the initiating host that the packet was filtered (ICMP Type 3 "Communication Administratively Prohibited"). This is also a message about the inaccessibility of the destination port. Therefore, when the traceroute utility receives such a message, it finishes its work without having reached the destination host. In this case, in the output it is important to understand that the packets were precisely filtered, as indicated by the! X (in Unix) or! A (in Cisco) sign:
Note: It is possible that packets will be dropped without sending ICMP messages (sending to the Null interface in Cisco / Huawei or discard in Juniper). In this case, the trace will go until the maximum TTL specified in the traceroute utility (by default, a maximum of 30 hops, but you can manually set up to 255, although usually 15-18 hops is enough) or the administrator will not interrupt, and the output will contain asterisks.
Note: The appearance of asterisks instead of host addresses may be due to various reasons and is well described here.
As a matter of fact, the traceroute utility can work like the tracert utility using ICMP Echo-Request. To do this, run it with the -I switch. In the examples above, the filter does not block ICMP, so tracing using this protocol will show us the entire packet path:
I hope we understand the basic principles of these utilities. If you need to make a trace on some port in Windows systems, you can use third-party utilities, for example tcptrace.
Thanks for attention!
The standard packet routing mechanism on the Internet is per hop behavior — that is, each node in the network decides where to send the packet based on information obtained from dynamic routing protocols and routes that are statically specified by administrators.
The route is the interface to which we need to send a packet to reach some destination node and the address of the next router (next-hop):
R1#sh ip rou | i 40. 40.0.0.0/8 is variably subnetted, 2 subnets, 2 masks O 40.0.0.0/31 [110/3] via 20.0.0.0, 00:01:54, FastEthernet0/0 O 40.1.1.1/32 [110/4] via 20.0.0.0, 00:00:05, FastEthernet0/0 What is the path? A path is a list of nodes through which a packet passes (passes):
1 10.0.0.1 16.616 ms 16.270 ms 15.929 ms 2 20.0.0.0 15.678 ms 15.157 ms 15.071 ms 3 30.0.0.1 26.423 ms 26.081 ms 26.744 ms 4 40.0.0.0 48.979 ms 48.674 ms 48.384 ms 5 100.0.0.2 58.707 ms 58.773 ms 58.536 ms The package path can be viewed using the tracert utilities in Windows OS and traceroute in GNU / Linux and Unix-like systems. (other commands, such as tracepath, we do not consider).
Many people believe that these utilities are the same principle of operation, but this is not so. Let's see.
So, the utility tracert.
The basis of this utility is the icmp protocol. Consider the following scheme:
Host sends an ICMP Echo-Request with ttl 1 to the ICMP Echo-Request specified in its routing table. After receiving such a packet, check the destination address — maybe a packet to it. Since this packet is addressed to another host, Router1 considers itself a transit node, decrements the ttl packet and discards it, since the packet lifetime becomes 0. Since the packet was dropped, Router1 sends a message to the source of the icmp packet indicating the cause of the drop - Time Exceeded . The tracert utility, having received this icmp message, specifies Router1 as the first hop (address information is specified in the icmp message). Then the process is repeated with incrementing ttl, until the request ttl icmp is equal to the number of hopes between the sending node and the receiving node. In this example, Server1 is the destination node. After receiving the packet, he will check the destination address, see that the request is addressed to him and send ICMP Echo-Reply, which will be a trigger for the tracert utility by the end of the trace.
')
Conclusion:
Icmp is a third-level protocol, and he knows nothing about ports. Therefore, it is impossible to make a tracert indicating the port. I hope we figured out here.
Traceroute - this utility works on a different principle, although the output of the command is similar to the output of the previous one.
Traceroute is not based on ICMP Echo-Request, but on sending udp fragments and receiving a message about port availability / unreachability. Let's go back to the previous scheme. Host generates a udp fragment, encapsulates it into an IP packet, and sets ttl = 1. Router1, being a transit node, will respond to this icmp packet with a message about the end of the packet's lifetime. The traceroute utility, upon receiving this message, indicates the source address of the icmp packet (Router1) as the address of the first hop. Then the process is repeated with incrementing the ttl package. Everything is almost the same as in tracert. But we don’t send ICMP Echo-Request, how will the traceroute utility understand that tracing is finished? It's simple - in the udp header there are fields source and destination port. It is logical that the source port will be any port above 1023. And what should I specify the destination port? As mentioned above, the work of the traceroute utility is based on receiving a message about the unreachability or availability of the destination port. That is, we send a udp fragment from port 45000 (for example) to port 33434 (this is the default port used). As in the previous case, Server1 is the destination node. Having received the packet, it unpacks it and must transfer it to the highest level protocols. But since the default port 33434 will be closed on the server, Server1 generates an icmp message about the unavailability of the destination port (ICMP Type 3 "Destination Unreachable" Code 3 "Port Unreachable"). Upon receiving this message, the traceroute utility considers the trace complete. During the tracing process, the destination port number will be incremented on every attempt (33434, 33435 and so on). It may happen that the destination port is open. In this case, the server will send to the initiator host, for example, TCP ACK if TCP SYN packets are used for tracing, which will also trigger the end of the trace.
Conclusion:
The utility traceroute allows you to make a trace with the destination port.
To do this, consider the example below:
Take the previous scheme and make a trace:
Using TCP SYN packets:
bormoglots@ubuntu-server-s1:~$ sudo traceroute -T -p 22 -w 1 -n 100.0.0.2 traceroute to 100.0.0.2 (100.0.0.2), 30 hops max, 60 byte packets 1 10.0.0.1 16.616 ms 16.270 ms 15.929 ms 2 20.0.0.0 15.678 ms 15.157 ms 15.071 ms 3 30.0.0.1 26.423 ms 26.081 ms 26.744 ms 4 40.0.0.0 48.979 ms 48.674 ms 48.384 ms 5 100.0.0.2 58.707 ms 58.773 ms 58.536 ms Using UDP packets:
bormoglots@ubuntu-server-s1:~$ sudo traceroute -U -p 22 -w 1 -n 100.0.0.2 traceroute to 100.0.0.2 (100.0.0.2), 30 hops max, 60 byte packets 1 10.0.0.1 7.102 ms 6.917 ms 6.680 ms 2 20.0.0.0 17.021 ms 16.838 ms 17.051 ms 3 30.0.0.1 31.035 ms 30.859 ms 30.658 ms 4 40.0.0.0 41.124 ms 40.941 ms 40.728 ms 5 100.0.0.2 51.291 ms 51.045 ms 50.720 ms As you can see the tracing was successful. We see the path to the specified host.
And now we will hang the filter on in on the interface Router4 (as shown in the figure):
R4#sh run int fa0/0 Building configuration... Current configuration : 121 bytes ! interface FastEthernet0/0 ip address 40.0.0.0 255.255.255.254 ip access-group deny-to-server in duplex half ! end R4#sh access-lists deny-to-server Extended IP access list deny-to-server 10 deny tcp any host 100.0.0.2 log (32 matches) 20 deny udp any host 100.0.0.2 log (29 matches) 30 permit ip any any (128 matches) Trace again:
bormoglots@ubuntu-server-s1:~$ sudo traceroute -T -p 22 -w 1 -n 100.0.0.2 traceroute to 100.0.0.2 (100.0.0.2), 30 hops max, 60 byte packets 1 10.0.0.1 4.575 ms 4.490 ms 4.367 ms 2 20.0.0.0 18.431 ms 18.359 ms 29.573 ms 3 30.0.0.1 30.579 ms 30.690 ms 30.722 ms 4 40.0.0.0 52.518 ms !X 62.977 ms !X 62.898 ms !X bormoglots@ubuntu-server-s1:~$ sudo traceroute -U -p 22 -w 1 -n 100.0.0.2 traceroute to 100.0.0.2 (100.0.0.2), 30 hops max, 60 byte packets 1 10.0.0.1 5.614 ms 5.523 ms 5.689 ms 2 20.0.0.0 18.364 ms 18.629 ms 18.556 ms 3 30.0.0.1 42.289 ms 42.225 ms 42.143 ms 4 40.0.0.0 41.984 ms !X 41.898 ms !X 41.815 ms !X Now the tracing is over on the next-to-last hop and signs appear in the output! X. Why did this happen? Router4 receiving a packet to Server1 drops it, since it falls under the prohibiting rule on the incoming interface and sends a message to the initiating host that the packet was filtered (ICMP Type 3 "Communication Administratively Prohibited"). This is also a message about the inaccessibility of the destination port. Therefore, when the traceroute utility receives such a message, it finishes its work without having reached the destination host. In this case, in the output it is important to understand that the packets were precisely filtered, as indicated by the! X (in Unix) or! A (in Cisco) sign:
R1#traceroute 100.0.0.2 Type escape sequence to abort. Tracing the route to 100.0.0.2 1 20.0.0.0 24 msec 24 msec 16 msec 2 30.0.0.1 16 msec 36 msec 40 msec 3 40.0.0.0 !A !A !A Note: It is possible that packets will be dropped without sending ICMP messages (sending to the Null interface in Cisco / Huawei or discard in Juniper). In this case, the trace will go until the maximum TTL specified in the traceroute utility (by default, a maximum of 30 hops, but you can manually set up to 255, although usually 15-18 hops is enough) or the administrator will not interrupt, and the output will contain asterisks.
Note: The appearance of asterisks instead of host addresses may be due to various reasons and is well described here.
As a matter of fact, the traceroute utility can work like the tracert utility using ICMP Echo-Request. To do this, run it with the -I switch. In the examples above, the filter does not block ICMP, so tracing using this protocol will show us the entire packet path:
bormoglots@ubuntu-server-s1:~$ sudo traceroute -I -w 1 -n 100.0.0.2 traceroute to 100.0.0.2 (100.0.0.2), 30 hops max, 60 byte packets 1 10.0.0.1 4.073 ms 3.986 ms 3.890 ms 2 20.0.0.0 19.474 ms 19.389 ms 19.294 ms 3 30.0.0.1 30.147 ms 30.276 ms 30.826 ms 4 40.0.0.0 42.316 ms 42.240 ms 42.145 ms 5 100.0.0.2 52.705 ms 52.622 ms 52.521 ms I hope we understand the basic principles of these utilities. If you need to make a trace on some port in Windows systems, you can use third-party utilities, for example tcptrace.
Thanks for attention!
Source: https://habr.com/ru/post/281272/
All Articles