Where Websites Come To Life
Troubleshooting with MTR procedures (Windows)
Posted: March 26th, 2015
KEKhost/KEKhosting Technical support may require you to complete a MyTraceRoute (MTR) report since firewalls may compromise results. The procedure is simple. Follow these steps:
Generate an MTR report with Windows
1) Download a winMTR program, such as http://sourceforge.net/projects/winmtr/
2) Once installation is complete, open the application. It is not necessary to install it since opening the executable file is sufficient.
3) In the 'Host' section, enter the remote server information (domain name or IP address).
4) Click 'Start'.
5) Wait while the program completes each hop. There is no indication the program has completed but it will continuously run to make the data more accurate. It has scanned all 'hops' when no more are generated.
6) Click 'Export Text'.
7) Save the results as a text file.
Providing your IP address to KEKhost/KEKhosting
In order to interpret the results, KEKhost/KEKhosting will need your public IP address. It is common for clients to use local IPs at their workstations. In this case, you will need to use a tool to determine your public IP. This one is reliable and easy: http://www.whatismyip.com/
Interpreting MTR results
The results of the MTR report provide information used in diagnosing problems. Based on the the scan, the results include:
> Network hop testing
> Number and distance between hops
> Percentage of lost packets (average packet lost in percentage)
> Amount of sent packets (total sent)
> Amount of received packets
> Quickest hop response time
> Average hop response time
> Slowest hop response time
> Response delay of the final hop
The most important information used to diagnose and resolve connectivity problems is the percentage of lost packets.
Here are two visual examples of MTR reports, the first one displaying an extreme case of lost packets (bold).
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 67.205.87.182 - 4 | 771 | 747 | 0 | 0 | 122 | 3 |
| te8-3.cr2.mtl.kekhosting.com - 4 | 762 | 736 | 0 | 2 | 198 | 3 |
| po21.cr1.mtl.kekhosting.com - 5 | 740 | 709 | 0 | 1 | 170 | 0 |
| xe-0-0-0.er1.dc.kekhosting.com - 5 | 721 | 687 | 0 | 8 | 81 | 7 |
| gw-google.washdcinternetxchange.net - 3 | 802 | 785 | 0 | 9 | 83 | 7 |
| 216.239.47.114 - 2 | 811 | 796 | 8 | 8 | 38 | 9 |
| 216.239.46.160 - 20 | 464 | 373 | 0 | 23 | 43 | 27 |
| 209.85.248.214 - 63 | 229 | 85 | 0 | 35 | 50 | 36 |
| 216.239.43.219 - 17 | 506 | 423 | 0 | 35 | 80 | 36 |
| No response from host - 100 | 159 | 0 | 0 | 0 | 0 | 0 |
| google-public-dns-a.google.com - 91 | 173 | 17 | 0 | 34 | 36 | 34 |
|________________________________________________|______|______|______|______|______|______|
---------------------------------------------------------------------------------------------------------------------------------------------------------
Hop Hostname (IP) Loss Sent Rcvd Min (ms) Avg (ms) Max (ms)
1 69.42.85.82 0 % 5 5 0.341 4.312 17.362
2 csd180.gsc.webair.net(173.239.0.53) 0 % 5 5 0.506 0.705 1.206
3 csc180.gsc.webair.net(173.239.32.1) 0 % 5 5 0.415 0.728 1.047
4 es0.nyc2.webair.net(173.239.0.25) 0 % 5 5 0.887 1.123 1.468
5 208.178.245.149 0 % 5 5 0.881 16.704 22.378
6 ae7-70G.scr4.NYC1.gblx.net(67.16.142.53) 0 % 5 5 0.855 4.814 19.778
7 po4-40G.ar5.NYC1.gblx.net(67.17.105.238) 0 % 5 5 1.003 1.487 2.956
8 64.215.195.214 0 % 5 5 0.835 1.184 1.641
9 vlan60.csw1.NewYork1.Level3.net(4.69.155.62) 0 % 5 5 8.233 8.324 8.504
10 ae-62-62.ebr2.NewYork1.Level3.net(4.69.148.33) 0 % 5 5 8.356 8.618 8.927
11 ae-5-5.car1.Montreal2.Level3.net(4.69.141.5) 0 % 5 5 8.355 10.300 13.459
12 te6-2.cl-core05.level3.mtl.iweb.com(4.59.176.10)20 % 4 5 8.894 13.456 22.702
13 te8-3.dr10.mtl.iweb.com(67.205.127.238) 0 % 5 5 9.152 14.627 25.000
--------------------------------------------------------------------------------------------------------------------------
The second image shows no lost packets except within the second to last hop (bold). If your results are similar to this, it is important to note that in order to isolate and minimize ping, trace route and MTR hops, iWeb controls the inflow of ICMP protocols on our own routers. This helps us diagnose results by focusing on the last hop in an MTR report. In cases similar to these results, there is no connectivity problem.