Cara Membaca Hasil MTR

Pada post sebelumnya saya sudah pernah share tentang cara membaca hasil report traceroute. Nah pada kali ini saya akan share cara membaca hasil report mtr. Namun sebelumnya, apa sih MTR itu ? Dan bedanya dengan traceroute itu apa ? Simak penjelasan berikut ini.

MTR merupakan tool yang powerfull untuk membantu administrator dalam mendiagnosa dan mengisolasi kesalahan jaringan dan menyediakan laporan status jaringan ke penyedia upstream. MTR merepresentasikan evolusi perintah traceroute dengan menyediakan sampel data yang lebih besar seolah-olah gabungan dari traceroute dan output ping.

Diagnosa Jaringan

Tool untuk diagnosa jaringan termasuk ping, traceroute, dan mtr menggunakan paket Internet Control Message Protocol (ICMP) untuk tes koneksi dan trafik antara dua point pada internet. Ketika user ping sebuah host di internet, serangkaian paket ICMP dikirim ke tujuan host dan akan mengirimkan paket respon kembali. Sehingga user bisa menghitung berapa waktu yang berjalan antara dua point tersebut.

Sebaliknya, tool termasuk traceroute dan MTR mengirimkan paket ICMP dengan meningkatkan TTLs secara bertahap untuk melihat rute atau rangkaian hop yang dibuat dari sumber host ke tujuan host. TTL atau Time to Live, mengontrol seberapa banyak paket hop yang akan dikirim dan mengembalikannya ke host. Dengan mengirimkan serangkaian paket dan mengembalikan paket tersebut ke host awal setelah satu hop, dua hop, tiga hop dan seterusnya maka mtr bisa mengumpulkan rute trafik yang dikirimkan antara host di internet.

Selain itu, MTR juga berguna untuk mengoleksi informasi tambahan seperti status, koneksi, dan responsifitas hosts. Nah dengan adanya informasi tambahan MTR tersebut, MTR bisa menyediakan informasi koneksi yang lengkap antara dua host yang ada di internet. Berikut beberapa cara install MTR dan cara membaca hasil report MTR.

Install MTR

a. Debian/Ubuntu

apt update && apt upgrade
apt install mtr-tiny

b. CentOs/RHEL/Fedora

yum update
yum install mtr

c. Windows
Untuk MTR pada windows, Anda bisa download software beranama "WinMTR" pada link berikut.

d. macOS
Install MTR pada MacOs bisa menggunakan tool Homebrew atau MacPorts:

brew install mtr

atau

port install mtr

Generate report MTR

Karena MTR menyediakan gambaran trafik dari satu host ke host tujuan, maka hal ini disebut sebagai directional tool. Rute yang diambil dari satu host ke host tujuan yang terdapat di internet memiliki hasil yang bervariasi. Maka, jika Anda memiliki kendala konektifitas bisa melakukan test MTR dari kedua sisi.
Biasanya terdapat beberapa customer yang saya minta generate MTR dari kedua sisi, hal ini dikarenakan hasil report MTR tidak akan mendeteksi kesalahan dari satu arah ketika masih ada paket loss dari arah yang berlawanan.

a. Menggunakan perintah Unix

mtr -rw [destination_host]

Sebagai contoh, Anda bisa mengarahkan destination host sesuai dengan kebutuhan, semisal:

mtr -rw imron.my.id

Apabila Anda ingin memeriksa konektifitas ke server Anda bisa menggunakan IP Host/Server Anda miliki, semisal:

mtr -rw 103.58.xxx.xxx

Namun jika Anda ingin MTR dari server/host Anda ke ISP lokal yang Anda gunakan bisa menggunakan perintah :

mtr -rw 192.168.0.1

192.168.0.1 adalah sebagai contoh IP Address lokal saja, jika Anda tidak mengetahui IP Address ISP lokal Anda bisa akses website WhatsMyIP.
Jika tidak ada packet loss sama sekali, Anda bisa menaikkan interfalnya menjadi 50:

mtr -rwc 50 -rw 192.168.0.1

Note
Opsi flag "r" digunakan untuk mengenerate hasil report, kependekan dari flag (--report)
Opsi flag "w" digunakan untuk menampilkan full hostname setiap hopnya, kependekan dari flag (--report-wide)
Opsi flag "c" digunakan untuk setup jumlah paket yang berhasil dikirim dan direkam pada hasil reportnya. Secara default valuenya bernilai 10, hal ini akan terasa lebih cepat. Namun jika ingin memastikannya bisa menggunakan value bernial 50 atau 100.

b. Menggunakan MTR pada Windows
Jika Anda menggunakan windows, Anda bisa generate hasil report MTR menggunakan aplikasi WinMTR. Ketikkan alamat destinasi pada formnya dan klik start untuk mulai generate hasil MTR.

Membaca Hasil MTR

Hasil generate MTR berisi informasinya yang banyak dan sulit untuk diinterpretasikan. Namun Anda tidak usah khawatir berikut akan dijelaskan cara menganalisa hasil report MTR.
Contoh hasil MTR dari local server saya ke website biznetgio.com :

~ $mtr --report biznetgio.com  
Start: 2022-01-18T10:36:59+0000  
HOST: jumper-imonk Loss% Snt Last Avg Best Wrst StDev  
1.|-- _gateway 0.0% 10 0.2 0.2 0.2 0.2 0.0  
2.|-- ip-253-101-150-103.btn-1. 0.0% 10 0.6 0.7 0.6 1.6 0.3  
3.|-- ip-49-127-59-137.core.biz 0.0% 10 1.2 0.5 0.4 1.2 0.3  
4.|-- ip-61-127-59-137.core.biz 0.0% 10 23.5 7.5 1.8 23.7 9.5  
5.|-- ip-225-127-59-137.core.bi 0.0% 10 2.6 2.6 2.5 2.6 0.0  
6.|-- ip-118-127-59-137.core.bi 0.0% 10 2.5 2.5 2.5 2.6 0.0  
7.|-- ip-166-127-59-137.core.bi 0.0% 10 10.2 30.8 10.2 193.1 57.1  
8.|-- ip-8-104-77-103.wjv-1.biz 0.0% 10 2.5 2.7 2.5 3.6 0.3

Pada contoh generate MTR diatas menggunakan flag --report , jika tidak menggunakannya maka MTR akan berjalan secara interaktif. Biasanya opsi flag tersebut cukup untuk digunakan kebutuhan report data.

_gateway, ip-253-101-150-103.btn-1 dan seterusnya adalah hostname / reverse DNS pada setiap hop nya. Jika Anda tidak ingin menampilkannya cukup menggunakan opsi flag --no-dns.

~ $mtr --no-dns --report biznetgio.com  
Start: 2022-01-18T10:42:56+0000  
HOST: jumper-imonk Loss% Snt Last Avg Best Wrst StDev  
1.|-- 10.9.9.1 0.0% 10 0.2 0.2 0.2 0.2 0.0  
2.|-- 103.150.101.253 0.0% 10 0.5 0.5 0.5 0.6 0.0  
3.|-- 137.59.127.49 0.0% 10 0.4 1.8 0.4 13.1 4.0  
4.|-- 137.59.127.61 0.0% 10 1.8 2.0 1.7 3.2 0.5  
5.|-- 137.59.127.225 0.0% 10 2.6 2.6 2.5 2.7 0.0  
6.|-- 137.59.127.118 0.0% 10 2.5 2.6 2.5 2.6 0.0  
7.|-- 137.59.127.166 0.0% 10 21.3 15.4 12.1 21.3 3.4  
8.|-- 103.77.104.8 0.0% 10 2.6 2.6 2.5 3.2 0.2

Selain melihat jalur paket yang dikirimkan dari sumber host ke host tujuan, MTR memberikan data statistik yang berkualitas pada 7 kolom setelahnya. Kolom Loss% menginformasikan persentase koneksi yang loss pada setiap hop. Adapun untuk kolom Snt menghitung jumlah nomor paket yang terkirim.
Opsi flag --report akan mengirimkan 10 paket kecuali jika dispesifikkan menggunakan opsi --report-cycles=[number-of-packets], dimana [number-of-packets] merepresentasikan total nomor paket yang ingin Anda kirim ke target host.

4 kolom selanjutnya yakni Last, Avg, Best dan Wrst menggunakan satuan ukuran lantency dalam milliseconds (semisal: ms). Last merupakan latency terakhir yang dikirim, Avg merupakan rata-rata latency dari semua paket, sementara untuk Best dan Wrst menggambarkan waktu yang paling cepat dan paling lama selama paket dikirimkan ke host. Pada banyak case, biasanya kolom Avg yang harus menjadi titik fokus untuk analisa MTR.

Pada kolom yang terakhir yakni StDev menyediakan standart deviasi dari latency untuk setiap host. Semakin tinggi standar deviasi, maka semakin besar ukuran latensi. Standar deviasi memungkinkan Anda untuk menilai apakah mean (rata-rata) yang diberikan mewakili data sebenarnya dari kumpulan data, atau terjadi kesalahan pengukuran. Jika standar deviasi tinggi, maka pengukuran latensi tidak konsisten.
Setelah rata-rata latensi dari 10 paket yang terkirim, rata-rata terlihat normal tetapi tidak bisa dijadikan acuan bahwa hasil MTR sangat bagus. Jika standar deviasi tinggi, Anda bisa melihat pada kolom Best dan Wrst apakah memang data tersebut merepresentasikan ukuran dari kolom StDev.

Pada banyak case, hop pertama, dua dan tiga sering mereprentasikan ISP sumber host, sementara 2 atau 3 hop paling terakhir merepresentasikan ISP host tujuan. Adapun hop yang terletak diantara awal dan akhir merupakan router yang melintasinya.
Sebagai contoh jika Anda generate MTR dari local komputer/laptop Anda ke Server Biznet Gio Cloud, maka 3 hop pertama merupakan koneksi local ISP Anda, adapun untuk 3 hop terakhir merupakan koneksi internet data center Biznet Gio Cloud. Jika Anda mengalami gangguan koneksi yang mendekati dari 3 hop pertama, maka Anda bisa menghubungi ISP lokal Anda. Namun, jika terdapat gangguan koneksi pada 3 hop terakhir, Anda bisa menghubungi Support Biznet Gio.
Berikut contoh hasil MTR ke server Biznet Gio Cloud :

~$ mtr --report 103.150.100.10  
Start: 2022-01-19T17:00:24+0700  
HOST: kangimonk Loss% Snt Last Avg Best Wrst StDev  
1.|-- 10.20.204.254 0.0% 10 2.0 4.1 2.0 8.2 2.1  
2.|-- ip-22-103-58-103.wjv-1.bi 0.0% 10 5.7 10.0 5.7 20.0 4.4  
3.|-- ip-165-127-59-137.core.bi 0.0% 10 6.2 3.9 2.4 6.2 1.5  
4.|-- ip-117-127-59-137.core.bi 0.0% 10 2.6 2.8 2.2 5.3 0.9  
5.|-- ip-42-127-59-137.core.biz 0.0% 10 4.3 5.9 4.3 7.4 1.5  
6.|-- ip-10-100-150-103.btn-1.b 0.0% 10 5.0 5.7 4.3 8.6 1.5

Analisis Report MTR

Verifikasi Packet Loss

Ketika Anda menganalisa output MTR, Anda sedang mencari dua hal yakni loss dan latency. Jika Anda melihat persentase loss pada beberapa hop tertentu, maka bisa menjadi indikasi terdapat kendala pada router tersebut. Walaupun pada beberapa provider ada yang membatasi koneksi ICMP sehingga tidak bisa menjadi acuan jika terdapat loss pada hop tersebut. Jika Anda ingin melihat bahwa memang terdapat loss atau tidaknya, maka Anda bisa melihat hop selanjutnya, jika persentase loss nya 0%, maka dipastikan bahwa terdapat limitasi trafik ICMP dan bukan real loss.
Contoh:

[email protected]:~# mtr --report www.google.com
HOST: example                       Loss%   Snt   Last  Avg  Best  Wrst   StDev
   1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.3
   2. 63.247.64.157                50.0%    10    0.4   1.0   0.4   6.1   1.8
   3. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.7
   4. aix.pr1.atl.google.com        0.0%    10    6.7   6.8   6.7   6.9   0.1
   5. 72.14.233.56                  0.0%    10    7.2   8.3   7.1  16.4   2.9
   6. 209.85.254.247                0.0%    10   39.1  39.4  39.1  39.7   0.2
   7. 64.233.174.46                 0.0%    10   39.6  40.4  39.4  46.9   2.3
   8. gw-in-f147.1e100.net          0.0%    10   39.6  40.5  39.5  46.7   2.2

Pada contoh case ini, loss yang direport antara 1 dan 2 sepertinya terkena pembatasan pada hop kedua. Walaupun trafik setelahnya tidak ada yang loss. Jika packet loss berkelanjutan lebih dari 1 pada hop selanjutnya, maka kemungkinan terdapat beberapa packet loss atau kendala routing.

[email protected]:~# mtr --report www.google.com
HOST: localhost                      Loss%   Snt   Last  Avg  Best  Wrst   StDev
   1. 63.247.74.43                   0.0%    10    0.3   0.6   0.3   1.2   0.3
   2. 63.247.64.157                  0.0%    10    0.4   1.0   0.4   6.1   1.8
   3. 209.51.130.213                60.0%    10    0.8   2.7   0.8  19.0   5.7
   4. aix.pr1.atl.google.com        60.0%    10    6.7   6.8   6.7   6.9   0.1
   5. 72.14.233.56                  50.0%    10    7.2   8.3   7.1  16.4   2.9
   6. 209.85.254.247                40.0%    10   39.1  39.4  39.1  39.7   0.2
   7. 64.233.174.46                 40.0%    10   39.6  40.4  39.4  46.9   2.3
   8. gw-in-f147.1e100.net          40.0%    10   39.6  40.5  39.5  46.7   2.2

Pada contoh kasus diatas, terlihat antara hop 2 dan 3 terdapat packet loss sebesar 60% seperti halnya pada hop 3 dan 4. Anda bisa berasumsi bahwa hop ketiga dan keempat terdapat packet loss dikarenakan hop selanjutnya terdapat packet loss. Bagaimanapun beberapa packet loss bisa juga terjadi karena limitasi trafik seperti penjelasan saya sebelumnya, pada case ini juga demikian dikarenakan hop selanjutnya terlihat packet loss nya menurun menjadi 40%. Ketika terdapat perbedaan jumlah loss yang dilaporkan, maka selalu jadikan acuan hasil report hop selanjutnya.

Hasil pengujian MTR terlihat normal ke host/server tujuan, namun jika pengujian MTR dari host tujuan ke local belum tentu normal. Maka sebaiknya untuk menganalisa secara akurat, Anda bisa melakukan generate MTR kembali dari kedua sisi.

Network Latency

Selain daripada menghitung packet loss, MTR juga bisa berguna untuk menghitung jumlah latency dari sumber host ke target host. Jika terjadi kendala, biasanya jumlah latensi dari hop 1 ke hop yang lain memiliki jumlah yang linear dan kenaikannya konsisten. Namun, latensi seringkali relatif dan sangat bergantung pada kualitas koneksi kedua host dan jarak fisiknya.

Kualitas network juga berpengaruh pada trafik latensi, koneksi yang bersumber dari wireless memiliki latensi lebih tinggi daripada koneksi yang bersumber dari kabel. Berikut contoh hasil MTR yang menujukkan latensi tinggi:

[email protected]:~# mtr --report www.google.com
HOST: localhost                      Loss%   Snt   Last   Avg  Best  Wrst  StDev
    1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.3
    2. 63.247.64.157                 0.0%    10    0.4   1.0   0.4   6.1   1.8
    3. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.7
    4. aix.pr1.atl.google.com        0.0%    10  388.0 360.4 342.1 396.7   0.2
    5. 72.14.233.56                  0.0%    10  390.6 360.4 342.1 396.7   0.2
    6. 209.85.254.247                0.0%    10  391.6 360.4 342.1 396.7   0.4
    7. 64.233.174.46                 0.0%    10  391.8 360.4 342.1 396.7   2.1
    8. gw-in-f147.1e100.net          0.0%    10  392.0 360.4 342.1 396.7   1.2

Dari hasil generate diatas menunjukkan bahwa antara hop 3 dan 4 menunjukkan hasil latensi yang tinggi. Dan setelahnya juga tidak ada penurunan. Biasanya penyebab dari latensi yang tinggi ini adalah konfigurasi router yang buruk.

Sayangnya, latensi tinggi tidak selalu berarti masalah dengan rute saat ini. Laporan seperti di atas berarti bahwa meskipun ada masalah dengan hop ke-4, lalu lintas masih mencapai target host dan kembali ke sumber host. Latensi dapat disebabkan oleh masalah dengan rute kembali juga. Rute kembali tidak akan terlihat dalam laporan MTR Anda, dan paket dapat mengambil rute yang sama sekali berbeda ke dan dari tujuan tertentu.

Pada contoh diatas, terlihat latency tinggi pada hop ke-4 dan kenaikannya juga tidak biasa. Sehingga bisa dipastikan bahwa kendala terjadi pada router ke-4.

Selain itu, pembatasan trafik ICMP juga hampir sama seperti indikasi latensi besar. Berikut contohnya:

[email protected]:~# mtr --report www.google.com
HOST:  localhost                     Loss%   Snt   Last  Avg  Best  Wrst   StDev
    1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.3
    2. 63.247.64.157                 0.0%    10    0.4   1.0   0.4   6.1   1.8
    3. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.7
    4. aix.pr1.atl.google.com        0.0%    10    6.7   6.8   6.7   6.9   0.1
    5. 72.14.233.56                  0.0%    10  254.2 250.3 230.1 263.4   2.9
    6. 209.85.254.247                0.0%    10   39.1  39.4  39.1  39.7   0.2
    7. 64.233.174.46                 0.0%    10   39.6  40.4  39.4  46.9   2.3
    8. gw-in-f147.1e100.net          0.0%    10   39.6  40.5  39.5  46.7   2.2

Sekilas pada hop antara 4 dan 5 menarik perhatian. Dimana pada hop ke-5 naik dan pada hop ke-6 turun secara drastis. Latensi yang diukur disini adalah 40 ms. Nah pada case seperti ini tidak menunjukkan kendala pada sisi layanan, sehingga untuk acuan report MTR bisa dilihat hop terakhir.

Report MTR secara Umum

Beberapa kendala jaringan biasanya dieskalasikan ke Upstream Network. Bagaimanapun juga disini ada beberapa contoh report MTR secara umum. Jika Anda memiliki beberapa kendala/issue jaringan layanan Anda dan ingin melakukan diagnosa, Anda bisa mengikuti contoh dibawah ini:

Jaringan Target Host tidak Dikonfigurasi dengan Benar

Pada contoh dibawah ini, muncul paket loss sebesar 100% di tujuan host dikarenakan konfigurasi yang tidak benar. Sekilas, sepertinya paket tidak sampai ke tujuan host.

[email protected]:~# mtr --report www.google.com
HOST:  localhost                     Loss%   Snt   Last  Avg  Best  Wrst  StDev
    1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.3
    2. 63.247.64.157                 0.0%    10    0.4   1.0   0.4   6.1   1.8
    3. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.7
    4. aix.pr1.atl.google.com        0.0%    10    6.7   6.8   6.7   6.9   0.1
    5. 72.14.233.56                  0.0%    10    7.2   8.3   7.1  16.4   2.9
    6. 209.85.254.247                0.0%    10   39.1  39.4  39.1  39.7   0.2
    7. 64.233.174.46                 0.0%    10   39.6  40.4  39.4  46.9   2.3
    8. gw-in-f147.1e100.net         100.0    10    0.0   0.0   0.0   0.0   0.0

Trafik diatas tidak mencapai target host. Bagaimanapun juga report MTR menunjukkan loss karena host tidak mengirimkan balasan. Hal ini bisa terjadi dikarenakan konfigurasi network atau rule firewall (iptables) yang tidak benar.
Cara untuk melihat hasil MTR terdapat packet loss atau kesalahan konfigurasi jaringan yakni terdapat packet loss sebesar 100%.

Residential or Business Router

Residental gateway terkadang menyebabkan report yang keliru:

% mtr --no-dns --report google.com
HOST:  deleuze                       Loss%   Snt   Last  Avg  Best  Wrst  StDev
    1. 192.168.1.1                   0.0%    10    2.2   2.2   2.0   2.7   0.2
    2. ???                          100.0    10    8.6  11.0   8.4  17.8   3.0
    3. 68.86.210.126                 0.0%    10    9.1  12.1   8.5  24.3   5.2
    4. 68.86.208.22                  0.0%    10   12.2  15.1  11.7  23.4   4.4
    5. 68.85.192.86                  0.0%    10   17.2  14.8  13.2  17.2   1.3
    6. 68.86.90.25                   0.0%    10   14.2  16.4  14.2  20.3   1.9
    7. 68.86.86.194                  0.0%    10   17.6  16.8  15.5  18.1   0.9
    8. 75.149.230.194                0.0%    10   15.0  20.1  15.0  33.8   5.6
    9. 72.14.238.232                 0.0%    10   15.6  18.7  14.1  32.8   5.9
   10. 209.85.241.148                0.0%    10   16.3  16.9  14.7  21.2   2.2
   11. 66.249.91.104                 0.0%    10   22.2  18.6  14.2  36.0   6.5

100% loss pada hop ke-2 tidak menandakan adanya kendala. Anda bisa melihat tidak ada loss pada hop selanjutnya.

ISP Router tidak Terkonfigurasi dengan Baik

Terkadang router yang terdapat pada rute tidak terkonfigurasi dengan baik dan paket Anda bisa jadi tidak sampai ke tujuan host:

[email protected]:~# mtr --report www.google.com
HOST:  localhost                     Loss%   Snt   Last  Avg  Best  Wrst   StDev
    1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.3
    2. 63.247.64.157                 0.0%    10    0.4   1.0   0.4   6.1   1.8
    3. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.7
    4. aix.pr1.atl.google.com        0.0%    10    6.7   6.8   6.7   6.9   0.1
    5. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0
    6. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0
    7. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0
    8. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0
    9. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0
   10. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0

Tanda tanya (?) muncul ketika tidak ada informasi rute tambahan. Terkadang, router yang dikonfigurasi dengan buruk akan mengirim paket secara looping. Anda dapat melihatnya dalam contoh berikut:

[email protected]:~# mtr --report www.google.com
HOST:  localhost                     Loss%   Snt   Last  Avg   Best  Wrst  StDev
    1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.3
    2. 63.247.64.157                 0.0%    10    0.4   1.0   0.4   6.1   1.8
    3. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.7
    4. aix.pr1.atl.google.com        0.0%    10    6.7   6.8   6.7   6.9   0.1
    5. 12.34.56.79                   0.0%    10    0.0   0.0   0.0   0.0   0.0
    6. 12.34.56.78                   0.0%    10    0.0   0.0   0.0   0.0   0.0
    7. 12.34.56.79                   0.0%    10    0.0   0.0   0.0   0.0   0.0
    8. 12.34.56.78                   0.0%    10    0.0   0.0   0.0   0.0   0.0
    9. 12.34.56.79                   0.0%    10    0.0   0.0   0.0   0.0   0.0
   10. 12.34.56.78                   0.0%    10    0.0   0.0   0.0   0.0   0.0
   11. 12.34.56.79                   0.0%    10    0.0   0.0   0.0   0.0   0.0
   12. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0
   13. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0
   14. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0

Terlihat pada report diatas router pada hop ke-4 tidak dikonfigurasikan secara benar. Ketika situasi ini terjadi, satu-satunya jalan untuk memperbaiki issue ini adalah menghubungi Tim Network Administrator pada sumber host.

Pembatasan Rate ICMP

Batasan rate ICMP bisa menyebabkan adanya packet loss. Ketika terjadi paket loss pada hop pertama saja dan tidak lanjut ke hop setelahnya, maka bisa disebabkan terjadi adanya pembatasan trafik ICMP.

[email protected]:~# mtr --report www.google.com
HOST:  localhost                     Loss%   Snt   Last  Avg  Best  Wrst   StDev
    1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.3
    2. 63.247.64.157                 0.0%    10    0.4   1.0   0.4   6.1   1.8
    3. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.7
    4. aix.pr1.atl.google.com        0.0%    10    6.7   6.8   6.7   6.9   0.1
    5. 72.14.233.56                 60.0%    10   27.2  25.3  23.1  26.4   2.9
    6. 209.85.254.247                0.0%    10   39.1  39.4  39.1  39.7   0.2
    7. 64.233.174.46                 0.0%    10   39.6  40.4  39.4  46.9   2.3
    8. gw-in-f147.1e100.net          0.0%    10   39.6  40.5  39.5  46.7   2.2

Report ini tidak menujukan adanya concern. Pembatasan rate seperti ini biasanya umum terjadi untuk menurunkan penyumbatan untuk memperioritaskan trafik yang lebih usable.

Timeouts

Timeouts bisa tejadi pada beberapa alasan. Beberapa router akan men-discard ICMP dan ketika tidak ada feedback trafik maka timeouts ditandai dengan (???) atau mungkin terdapat masalah pada rute kembali:

[email protected]:~# mtr --report www.google.com
HOST:  localhost                     Loss%   Snt   Last  Avg  Best  Wrst   StDev
    1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.3
    2. 63.247.64.157                 0.0%    10    0.4   1.0   0.4   6.1   1.8
    3. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.7
    4. aix.pr1.atl.google.com        0.0%    10    6.7   6.8   6.7   6.9   0.1
    5. ???                           0.0%    10    7.2   8.3   7.1  16.4   2.9
    6. ???                           0.0%    10   39.1  39.4  39.1  39.7   0.2
    7. 64.233.174.46                 0.0%    10   39.6  40.4  39.4  46.9   2.3
    8. gw-in-f147.1e100.net          0.0%    10   39.6  40.5  39.5  46.7   2.2

Timeout tidak selalu mengindikasikan adanya packet loss. Packet masih tetap sampai tujuan tanpa adanya packet loss atau latency secara signifikan. Timeout bisa menjadi atribut pada router untuk dropping packet guna kebutuhan QoS (Quality of Service) atau bisa terjadi karena memang adanya beberapa issue rute kembali yang menyebabkan timeout.

Advanced MTR Techniques

Versi MTR yang lebih baru sekarang mampu berjalan dalam mode TCP pada port TCP tertentu, dibandingkan dengan penggunaan standar protokol ICMP (ping). Namun, dalam kebanyakan kasus, mode ini tidak boleh digunakan karena laporan TCP dapat menyebabkan hasil yang ambigu dalam menganalisa antar-rute. TCP MTR akan menggunakan paket SYN sebagai pengganti ping ICMP, dan sebagian besar router internet-level tidak merespon ini yang bisa menujukkan adanya packet loss.

Tes TCP berguna untuk menentukan apakah aturan firewall pada router di suatu tempat memblokir protokol atau port, mungkin karena port forwarding belum dikonfigurasi dengan benar. Salah satu kelebihan tes MTR menggunakan TCP melalui port tertentu ini dapat menunjukkan report dengan lebih jelas sedangkan tes ICMP mungkin tidak.

sudo mtr --tcp --port 80 --report --report-cycles 10 biznetgio.com
sudo mtr --tcp --port 22 --report --report-cycles 10 biznetgio.com

Resolve Routing dan Isue Jaringan dengan Identifikasi Hasil MTR

Sebagian besar masalah routing yang terjadi pada layanan Anda bisa terjadi dari sisi sumber host maupun target host. Anda bisa melampirkan hasil MTR dari kedua sisi untuk mempermudah penyedia layanannya dalam menganalisa kendala yang dialami.

Sementara jika terdapat kendala pada routing jaringan, itu bukan satu-satunya penyebab penurunan performa. Network congestion, terutama jarak routing yang jauh bisa menjadi penyebab yang parah. Nah dalam kasus ini, Anda disarankan untuk memposisikan sumber dan target host sedekat mungkin secara geografis.

Apabila Anda membutuhkan informasi lebih lanjut atau konsultasi terkait MTR bisa comment dibawah ini.

Referensi: https://www.linode.com/docs/guides/diagnosing-network-issues-with-mtr/