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-tinyb. CentOs/RHEL/Fedora
yum update
yum install mtrc. 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 mtratau
port install mtrGenerate 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.idApabila Anda ingin memeriksa konektifitas ke server Anda bisa menggunakan IP Host/Server Anda miliki, semisal:
mtr -rw 103.58.xxx.xxxNamun jika Anda ingin MTR dari server/host Anda ke ISP lokal yang Anda gunakan bisa menggunakan perintah :
mtr -rw 192.168.0.1192.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.1Note
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.Trending
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.3Pada 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.2Selain 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.5Analisis 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:
root@localhost:~# 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.2Pada 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.
root@localhost:~# 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.2Pada 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:
root@localhost:~# 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.2Dari 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:
root@localhost:~# 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.2Sekilas 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.
root@localhost:~# 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.0Trafik 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.5100% 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:
root@localhost:~# 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.0Tanda 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:
root@localhost:~# 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.0Terlihat 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.
root@localhost:~# 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.2Report 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:
root@localhost:~# 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.2Timeout 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.comResolve 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/
