Cara Membaca MTR Pelanggan untuk Memastikan Masalah Peering IIX

Tiket keluhan server lambat sering kali masuk hanya dengan lampiran tangkapan layar ping empat baris atau klaim sepihak bahwa server sedang down. Sebagai tim support hosting, data seperti itu tidak cukup untuk menentukan letak kendala. Kita membutuhkan pembacaan rute yang lengkap menggunakan MTR (My Traceroute), sebuah perkakas diagnostik yang menggabungkan fungsi traceroute dan ping secara berulang untuk melihat performa tiap hop di jaringan. Masalah rute domestik di Indonesia umumnya berpusat di titik pertukaran trafik atau Internet Exchange Point (IXP), terutama IIX (Indonesia Internet Exchange) yang dikelola APJII dan OpenIXP (NiCE). Ketika pelanggan di ISP lokal mengeluhkan latensi melonjak atau koneksi putus-nyambung, letak masalahnya belum tentu ada di server tujuan. Sering kali kendala tersebut merupakan traffic flapping atau saturasi link di peering exchange. Melalui MTR, kita bisa memetakan letak masalah secara objektif sebelum memutuskan eskalasi.

Meminta Data MTR dengan Parameter yang Benar

Langkah pertama adalah memastikan pelanggan menjalankan MTR dengan parameter yang tepat. Perintah traceroute standar hanya mengirim tiga paket per hop, yang sangat rentan memberikan kesimpulan keliru jika ada paket yang kebetulan terbuang akibat rate limiting di router transit. MTR yang valid memerlukan sampel paket yang cukup banyak. Minta pelanggan atau teknisi di sisi klien untuk menjalankan perintah MTR dengan mengirimkan minimal 50 hingga 100 paket dalam mode laporan (report mode):

BASH

mtr --report --report-cycles 100 --show-ips target-ip-atau-domain.id

Untuk pengguna Windows yang menggunakan perkakas GUI seperti WinMTR, minta mereka membiarkan proses berjalan hingga kolom Sent mencapai angka minimal 100 sebelum menyalin hasilnya. Jika sampel paket di bawah itu, lonjakan sesaat tidak terbaca dengan akurat.

Memeriksa Hop Awal di Jaringan Lokal Pelanggan

Saat menerima output MTR, jangan langsung melompat ke baris terakhir. Mulai analisis dari hop 1 sampai hop 3. Hop ini mewakili lingkungan lokal pelanggan, seperti router Wi-Fi kantor atau rumah, serta gateway pertama milik ISP lokal mereka. Perhatikan kolom loss percentage (Loss%) dan rata-rata latensi (Avg). Jika hop 1 menunjukkan packet loss sebesar 10% atau latensinya melonjak tidak wajar (misalnya menyentuh 80 ms pada gateway lokal 192.168.1.1), kendala hampir pasti ada pada perangkat lokal atau koneksi nirkabel pelanggan. Aturan dasar dalam membaca MTR: packet loss yang merupakan masalah jaringan riil akan terus terbawa (persistent) ke semua hop berikutnya sampai hop tujuan akhir. Jika hop 2 menunjukkan loss 20%, lalu hop 3 sampai hop 10 juga menunjukkan loss sekitar 20%, masalah berakar di hop 2 (ISP lokal pelanggan). Namun, jika hop 2 menunjukkan loss 40% tetapi hop 3 dan seterusnya turun kembali ke 0%, angka di hop 2 hanyalah router yang membatasi respon ICMP (control plane rate limiting), bukan packet loss nyata. Berikut contoh format output MTR saat terjadi packet loss riil di segmen peering:

TEXT

HOST: client-pc            Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.1.1         0.0%   100    1.2   1.4   0.9   4.2   0.6
  2.|-- 10.x.x.x (ISP-GW)   0.0%   100    8.5   9.1   7.8  18.4   1.5
  3.|-- 182.253.x.x         0.0%   100   12.1  13.0  11.2  24.5   2.1
  4.|-- iix.net.id          8.0%   100   74.2  72.5  35.1 140.2  21.3
  5.|-- target-datacenter   8.0%   100   75.1  73.1  35.8 138.9  20.8
  6.|-- 103.x.x.x (Server)  8.0%   100   74.8  72.9  35.4 139.1  20.7

Mengidentifikasi Titik Peering IIX dan OpenIXP

Langkah berikutnya adalah memeriksa hop tengah tempat ISP pelanggan menyerahkan paket ke upstream atau exchange point domestik. Di Indonesia, hop peering biasanya memiliki reverse DNS (PTR record) yang memuat label exchange seperti iix.net.id, openixp, atau nama fasilitas interkoneksi di gedung sentral seperti Cyber Building atau Duren Tiga. Ada dua gejala utama yang menandakan masalah di level peering:

Lonjakan latensi permanen: Latensi dari ISP pelanggan ke hop sebelum exchange biasanya stabil di rentang 5–15 ms untuk rute sesama Jakarta atau pulau Jawa. Begitu masuk ke hop IIX, latensi melonjak drastis (misalnya menjadi 70–120 ms) dan angka tinggi ini bertahan sampai hop server tujuan. Ini menandakan antrean paket atau kongesti rute interkoneksi antar Autonomous System (ASN).
Packet loss berlanjut: Muncul packet loss pada hop IIX (seperti contoh output di atas, sebesar 8%) yang angkanya konsisten terbawa hingga ke hop server target. Jika server hosting tidak mengalami saturasi CPU dan tidak membuang paket di firewall, angka loss yang persisten dari titik IIX membuktikan kendala terjadi pada link peering antar-penyedia.

Gejala lain yang kerap terjadi pada jam sibuk adalah traffic flapping. Pada MTR, flapping terlihat dari nilai standar deviasi (StDev) yang sangat tinggi pada hop exchange dan hop target, serta selisih tajam antara kolom Best dan Wrst. Ketika jalur utama exchange penuh, beberapa router BGP melakukan rerouting secara dinamis, menyebabkan latensi berfluktuasi liar antar-detik.

Menentukan Langkah Eskalasi yang Tepat

Sebelum mengajukan eskalasi ke tim upstream network atau NOC datacenter, lakukan uji dua arah (two-way MTR). Rute pergi dari pelanggan ke server belum tentu sama dengan rute pulang dari server ke pelanggan karena sifat routing BGP yang asimetris. Jalankan MTR dari sisi server hosting Anda menuju alamat IP publik pelanggan:

Jika MTR dari sisi server menuju pelanggan menunjukkan rute yang bersih tanpa packet loss, tetapi MTR dari pelanggan ke server menunjukkan loss di titik IIX, bottleneck berada di jalur masuk (ingress) ISP pelanggan ke exchange.
Jika MTR dari kedua arah sama-sama menunjukkan loss atau lonjakan latensi di hop exchange yang sama, link interkoneksi ASN antara upstream server Anda dan ISP pelanggan sedang mengalami saturasi.

Dengan memegang data MTR dua arah yang menunjukkan packet loss persisten mulai dari titik exchange, Anda dapat menghubungi penyedia bandwidth atau NOC datacenter dengan bukti yang tidak terbantahkan. Sertakan output teks MTR lengkap, IP asal, IP tujuan, serta waktu pengujian agar tim upstream dapat menyesuaikan rute BGP peering atau mengalihkan trafik sementara ke rute transit alternatif.