Traceroute vs Ping vs Mtr

Dear Blog Reader,
Someone asked which tools is a better tool to use.

I think its better to start with the roots. We should first understand the internal working to these 3 network utilities u asked in question.

So lets go one-by-one.

We know all these 3 guys (Ping, Traceroute and MTR) uses ICMP.

ICMP
Internet Control Message Protocol (ICMP) is a part of the RFC 792 defined Internet protocol suite. ICMP is used for sending error messages like “destination could not be reached”, “time to live exceeded” etc. An ICMP packet will have an IP header and the ICMP message data. The first 32 bits in the ICMP message data contains the type of the ICMP packet, the code and the checksum. The Data field contains the payload. It has variable size depending on the type of the ICMP message.

PING

The name “ping” was named after the sound of the sonar used to locate objects. It is the basic connectivity testing tool between 2 machines running TCP/IP.

ICMP packets with a Type 8 Code 0 echo requests are send out by the ping utility. Every packet’s sequence number will be increased by 1 but each of them will have the same identifier. If a connection is established with the other host, an ICMP Type 0 Code 0 echo reply packet having the same identifier will be received. A judgment on whether the connection is reliable or not can be made by checking if all the packets are received back in sequence.

[alok@legacy ~]$ ping http://www.google.com
PING http://www.l.google.com (209.85.231.104) 56(84) bytes of data.
64 bytes from maa03s01-in-f104.1e100.net (209.85.231.104): icmp_seq=1 ttl=54 time=71.5 ms
64 bytes from maa03s01-in-f104.1e100.net (209.85.231.104): icmp_seq=2 ttl=54 time=84.3 ms
64 bytes from maa03s01-in-f104.1e100.net (209.85.231.104): icmp_seq=3 ttl=54 time=103 ms
64 bytes from maa03s01-in-f104.1e100.net (209.85.231.104): icmp_seq=4 ttl=54 time=71.9 ms
64 bytes from maa03s01-in-f104.1e100.net (209.85.231.104): icmp_seq=5 ttl=54 time=84.4 ms

— http://www.l.google.com ping statistics —
5 packets transmitted, 5 received, 0% packet loss, time 4965ms
rtt min/avg/max/mdev = 71.579/83.163/103.495/11.644 ms

Fields in the ping output:

The ping utility resolved the hostname http://www.google.com to the hostname aa03s01-in-f104.1e100.net. The next field in the output shows the number of data bytes to be send – which is 56. Combined with the 8 bytes of ICMP header data, this translates to 64 data bytes which is shown at the beginning of each ping request. The Sequence Number of each request is denoted by the icmp_seq field in the ping output, which gets incremented. The “ttl” or “Time To Live” field in the Internet Protocol (IP) specifies how many more hops a packet can travel before being discarded or returned.

The ping program shows the ttl value of the packet sent to it from a remote location. These remote systems can change the TTL values to different ones in the reply (values can be 255, 128, 60 etc). The value seen above is the initial value minus the round-trip number of hops. The time shown in milliseconds is the round trip time or round trip delay time(RTT). RTT is the time required for a transmitted pulse to reach a target and for the echo reply to return to the receiver.

At the end of the output, a statistics is displayed, which shows the packet loss percentage, the minimum/maximum/average RTT.

TRACEROUTE

traceroute (tracert in Windows) prints the route which the packets takes in a TCP/IP network on their way to destination.

The command traceroute hostname sends three UDP packets having a TTL value of 1. On arrival of the packets at the closest router, the router decreases the TTL value by one, thus making it 0. When a packet with TTL value 0 is noticed by the router, it responds by sending an ICMP packet “time exceeded” (Type 11 Code 0) as “time to live exceeded in transit.” The IP address of the router that sends back the 3 ICMP packets is noted by the traceroute utility. It will then calculate the time to receive each of the packets and then sends out three more UDP packets, this time with a TTL value of 2.

Since these packets now have a TTL value of 2, they should be returned by the router that is away by 2 hops from the one sending the packets. Upon receiving these packets, they will be noted by the traceroute utility and it sends out three more UDP packets, with a TTL value of 3.This process is continued by the traceroute utility until it either reaches the final destination or it has gone through the default maximum value of 30 routers. Since these datagrams try to access an invalid port at the destination host, the message returned will be ICMP Port Unreachable, indicating an unreachable port. This event signals the traceroute program that it is finished.

The outgoing packets from traceroute are sent towards the destination using UDP at very high port numbers, typically in the range of 32,768 and higher. This is because no one usually runs UDP services in those ports, so when the packet finally reaches the destination, traceroute can know that.

[alok@legacy ~]$ traceroute http://www.networknuts.net
traceroute to http://www.networknuts.net (216.97.226.210), 30 hops max, 60 byte packets
1 172.24.0.250 (172.24.0.250) 0.127 ms 0.095 ms 0.115 ms
2 192.168.1.1 (192.168.1.1) 4.070 ms 6.080 ms 11.216 ms
3 * * *
4 rasBTNLDel-static-142.215.56.202.mantraonline.com (202.56.215.142) 103.693 ms 106.036 ms 108.673 ms
5 ABTS-North-Static-237.230.160.122.airtelbroadband.in (122.160.230.237) 110.391 ms 112.599 ms 114.792 ms
6 203.101.83.197 (203.101.83.197) 116.913 ms 93.544 ms 95.615 ms
7 125.21.167.70 (125.21.167.70) 152.998 ms 178.997 ms 181.664 ms
8 if-7-0-1.core1.S2E-Singapore.as6453.net (216.6.91.69) 208.427 ms 210.515 ms 212.641 ms
9 Vlan1124.icore1.S9U-Singapore.as6453.net (116.0.83.17) 216.709 ms 218.630 ms 233.201 ms
10 Vlan1146.icore2.LAA-LosAngeles.as6453.net (116.0.83.34) 403.646 ms 418.302 ms *
11 * * Vlan1130.icore1.LAA-LosAngeles.as6453.net (216.6.12.14) 349.678 ms
12 4.68.63.65 (4.68.63.65) 347.157 ms 376.635 ms 377.285 ms
13 ae-71-70.ebr1.LosAngeles1.Level3.net (4.69.144.114) 372.514 ms ae-81-80.ebr1.LosAngeles1.Level3.net (4.69.144.178) 371.181 ms 382.693 ms
14 ae-5-5.car1.SanDiego1.Level3.net (4.69.133.205) 467.009 ms 532.268 ms 517.989 ms
15 ae-11-11.car2.SanDiego1.Level3.net (4.69.133.210) 543.214 ms 543.630 ms 487.403 ms
16 * ADD2NET-INC.car2.SanDiego1.Level3.net (4.53.122.70) 443.180 ms *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *

Fields in the traceroute output:

The output shows the maximum number of hops traceroute attempts which is 30 in this case and a 60 byte packet has been used. The third hop in this output shows timeout. In the subsequent hops, we can see 3 fields at the end of each hop, which denotes the RTT of the 3 packets sent to each of the systems. In the 13th hop, we can see that the 2nd packet was sent to a different IP. This is because of the load balancing setup there, which takes each access to different systems.

MTR

mtr combines the functionalities of the ‘traceroute’ and ‘ping’ utilities. When mtr starts, it investigates the network connection between the host in which it runs, and a user-specified destination host. After determining the address of each network hop between these machines, it sends out a sequence of ICMP ECHO requests to each machine to check the quality of the link to each of them. mtr uses ICMP Time Exceeded (type 11) packets returning from routers, or ICMP Echo Reply packets when the packets have hit their destination host. Running statistics about each machine is printed out as the process is being run.

The real advantage of mtr over ping or traceroute is, it shows where exactly the packet loss is happening in the route to the destination host in realtime. It shows the loss percentage on each hosts, which can give us valuable information on which specific provider is having a network issue. Also, since mtr is using ICMP ECHO requests, it will go through the routers which have blocked udp packets. So mtr may work where traceroute is not working.

[root@legacy ~]# mtr http://www.google.com –report -c 5
HOST: legacy.example.com Loss% Snt Last Avg Best Wrst StDev
1. 172.24.0.250 0.0% 5 0.2 16.0 0.2 45.3 22.0
2. 192.168.1.1 0.0% 5 0.5 9.3 0.5 44.5 19.7
3. rasBTNLDel-static-135.215.56 20.0% 5 194.9 110.0 41.9 194.9 63.2
4. ABTS-North-Static-141.230.16 20.0% 5 29.2 133.7 18.8 424.4 194.7
5. ABTS-North-Static-154.220.16 20.0% 5 14.8 37.4 14.8 60.2 23.7
6. 203.101.83.197 0.0% 5 46.7 34.9 14.4 60.1 20.1
7. 203.101.100.214 0.0% 5 22.8 85.2 22.8 113.6 35.7
8. 216.239.43.142 40.0% 5 45.6 809.9 45.6 1311. 672.6
9. 72.14.216.229 20.0% 5 18.9 29.4 7.5 76.3 31.6
10. 216.239.43.142 0.0% 5 15.9 59.0 15.9 85.3 28.1
11. 72.14.238.90 0.0% 5 39.0 90.9 39.0 130.0 37.5
12. maa03s01-in-f99.1e100.net 20.0% 5 107.2 116.6 72.8 167.7 39.2

Since the mtr output is dynamic, it is difficult to copy the output from konsole. For this either the –report option can be used, which I had used for display. Note that you should have root privileges to run mtr.

Now it upto you to decide which tools will work for you in a given conditions.

Taggato su:
Loading Facebook Comments ...

Lascia un commento