Pernah lapor internet lemot ke ISP, tapi dijawab "itu masih normal Pak, speedtest 50 Mbps kok"? Atau kamu sysadmin yang tahu ada yang salah dengan jaringan kantor pas jam 14:00, tapi tidak punya angka untuk membuktikan? MTR (Matt's Traceroute) sebenarnya sudah memberi semua bukti yang kamu butuh — tapi cuma kalau kamu tahu metric mana yang harus dilihat dan berapa angka threshold-nya. Artikel ini membongkar threshold MTR untuk tiga level teknisi: basic (helpdesk & pengguna rumahan), medium (sysadmin & IT lapangan), dan expert (NOC & network engineer). Setiap tier dijangkar dengan kasus sehari-hari, bukan teori dulu.
8.8.8.8, 1.1.1.1, cekipsaya.com).Kenapa Banyak Engineer Salah Baca MTR
Tiga miskonsepsi yang bikin diagnostik MTR jadi tidak akurat: (1) fokus cuma ke kolom Loss% — padahal banyak masalah jaringan tidak menyentuh packet loss sama sekali. (2) Mengabaikan kolom StDev — padahal di sinilah jitter (variance) bersembunyi, dan jitter yang membunuh SSH, VoIP, dan video meeting. (3) Salah artikan ??? dengan 100% loss sebagai bukti router rusak, padahal itu hanya filter ICMP — paket tetap lewat, cuma ICMP yang tidak dijawab.
Dampak konkret: kamu lapor ke ISP cuma berdasarkan "feeling lemot" → ISP mintai speedtest → speedtest jalan 50 Mbps → tiket di-close "jaringan normal". Padahal MTR run 100 paket di jam yang sama menunjukkan StDev 80ms di hop ketiga — angka yang seharusnya bikin NOC ISP langsung bergerak. Bedanya cuma satu: kamu punya bukti angka, atau tidak.
Tier 1 — BASIC: Untuk Helpdesk & Pengguna Rumahan
Target di tier ini: kamu hanya perlu dua kolom MTR — Loss% dan Avg. Sisanya abaikan dulu. Tujuan: tahu apakah masalah ada di rumah/kantor sendiri, atau sudah waktunya lapor ke ISP dengan bukti.
4 Skenario Sehari-hari untuk Tier Basic
Speedtest mengukur kapasitas (bandwidth), bukan stabilitas. Run MTR ke 8.8.8.8 100 paket. Kalau Loss% 0% di semua hop dan Avg di hop terakhir < 30ms — speedtest benar, masalah lebih dalam (lihat Tier 2). Kalau Loss% > 2% di hop pertama — masalah ada di WiFi/router rumah kamu, bukan ISP.
Run MTR ke 1.1.1.1 selama Zoom berlangsung. Kalau Loss% tetap 0% tapi suara/video tetap putus — masalahnya jitter, lompat ke Tier 2. Kalau Loss% 5–10% di hop ke-3 atau ke-4 — itu sudah bukti packet loss di sisi ISP, simpan output untuk lapor.
Lag spike = jitter, hampir tidak pernah masalah bandwidth. Tapi sebagai cek awal, run MTR ke game.server.com (atau IP server gaming). Loss% > 1% di hop manapun = sudah cukup alasan komplain ISP. Avg latency > 80ms ke server SEA = wajar untuk WiFi padat, tapi > 150ms = ada routing aneh.
Buffering = packet drop sustained. Run MTR ke youtube.com via traceroute online. Lihat hop terakhir (server tujuan): Loss% 0% berarti video bisa di-cache normal — masalah mungkin di DNS resolver (cek DNS Lookup). Loss% 2–5% di hop terakhir = ISP throttle YouTube atau peering bermasalah, lapor.
Cara Run MTR yang Paling Mudah
Download: https://winmtr.net (versi portable, tanpa install)
1. Jalankan WinMTR.exe
2. Host: 8.8.8.8
3. Klik Start
4. Tunggu 60 detik (~100 paket terkumpul)
5. Klik Copy Text to Clipboard untuk lampiran komplain# Install (sekali saja)
brew install mtr # Mac
sudo apt install mtr # Linux Debian/Ubuntu
# Run report 100 paket
sudo mtr --report --report-cycles 100 8.8.8.8
# Tanpa sudo (Mac, butuh -u untuk UDP mode)
mtr -u --report --report-cycles 100 8.8.8.8Rule Praktis Tier Basic — 3 Aturan Saja
- Loss% > 1% di hop terakhir → ada masalah, jangan ragu lapor ke ISP.
- Loss% 0% tapi Avg > 100ms ke
8.8.8.8→ routing tidak optimal, indikasi peering ISP bermasalah, lapor. - Loss% > 5% hanya di hop pertama (router rumah) → masalah ada di WiFi atau kabel LAN kamu sendiri, bukan ISP. Restart router dulu.
Loss 0% di semua hop dan Avg wajar — tapi kamu masih merasa lemot — masalahnya hampir pasti jitter. Lompat ke Tier 2 untuk membaca kolom StDev.Tier 2 — MEDIUM: Untuk Sysadmin & IT Lapangan
Di tier ini kamu menambah tiga kolom baru ke radar: StDev (jitter — variance latency), Wrst (latency outlier maksimal dari 100 paket), dan Best (latency terbaik). StDev adalah smoking gun untuk masalah yang paling sering dilewatkan helpdesk: jaringan yang "sehat di angka rata-rata" tapi membuat SSH dan video meeting jadi tidak bisa dipakai.
3 Skenario Kantor yang Cuma Tier Medium yang Bisa Diagnose
Run MTR dari workstation user yang lagi meeting. Pola yang biasa muncul: Loss 0%, Avg hop ke-3 atau ke-4 = 25ms, tapi StDev di hop yang sama = 60–120ms, Wrst = 800ms+. Itu peering exchange ISP yang penuh di jam sibuk. Bukan WiFi kantor (cek dengan run dari ethernet langsung — pola sama). Bawa angka ini ke ISP sebagai bukti.
SSH sangat sensitif ke jitter karena tiap keystroke = paket terpisah. Browsing tidak — TCP buffer absorb jitter. Run MTR ke IP VPS-mu. Kalau Avg 30ms tapi StDev 40ms — itu kenapa SSH terasa "tersendat-sendat" walau angka rata-rata bagus. Solusi sementara: pakai mosh atau SSH multiplex (ControlMaster) sambil tunggu ISP fix peering.
Aplikasi kasir biasanya pakai HTTPS keep-alive ke server cloud. Saat banyak transaksi paralel + jitter naik = TCP retransmit naik = response time meledak. Run MTR ke IP API kasir. Kalau StDev hop terakhir > 30ms saat jam ramai & < 5ms saat sepi — itu congestion, bukan aplikasi. Eskalasi: ganti CPE ke router yang support QoS atau minta ISP upgrade port.
StDev (Jitter) — Threshold yang Wajib Dihafal
StDev bukan latency rata-rata. StDev adalah standar deviasi latency dari 100 paket — semakin tinggi, semakin "tidak konsisten" pengiriman paket di hop tersebut. Untuk konteks Indonesia (path domestik 5–30ms baseline), tabel berikut adalah threshold lapangan yang dipakai sysadmin berpengalaman:
| StDev (ms) | Status | Pengaruh ke User |
|---|---|---|
| < 2 | 🟢 Excellent | Tidak terasa di semua use case |
| 2 – 5 | 🟢 Sangat baik | VoIP HD jernih, gaming kompetitif lancar |
| 5 – 10 | 🟢 Normal | SSH responsif, video meeting tanpa freeze |
| 10 – 20 | 🟡 Mulai terasa | SSH "tersendat", video kadang freeze 1 detik |
| 20 – 50 | 🟡 Bermasalah | VoIP echo, video meeting drop, gaming lag spike |
| 50 – 100 | 🔴 Buruk | SSH unbearable, video meeting tidak bisa dipakai |
| > 100 | 🔴 Catastrophic | Hampir semua aplikasi real-time gagal — bukti kuat lapor NOC |
Wrst — Kapan Outlier Layak Diabaikan, Kapan Tidak
Wrst (worst) adalah latency tertinggi dari 100 paket. Wrst tinggi sendirian belum tentu masalah — bisa cuma satu paket buffer terlambat. Tapi kalau Wrst lebih dari 5 kali Avg, itu indikasi microbursts (kepadatan trafik sesaat) yang signifikan. Rasio Wrst/Avg adalah signal yang bagus.
| Rasio Wrst / Avg | Interpretasi | Aksi |
|---|---|---|
| < 2× | 🟢 Stabil | Abaikan, jaringan konsisten |
| 2× – 5× | 🟡 Microburst kecil | Pantau, biasa pada jam puncak |
| 5× – 10× | 🟡 Microburst signifikan | Cek pattern jam — peering exchange overload |
| > 10× | 🔴 Outlier ekstrem | Buffer router meledak atau routing flap, lapor NOC |
Threshold Per Use Case (Sysadmin Wajib Hafal)
| Use Case | StDev Maks | Loss Maks | Catatan |
|---|---|---|---|
| SSH interaktif | 15ms | 0.5% | Tiap keystroke = paket terpisah, sangat sensitif |
| VoIP HD (G.711) | 30ms | 1% | Codec adaptive lebih toleran, tapi MOS turun di 30ms+ |
| Video conference | 50ms | 1% | Zoom/Meet adaptive bitrate; di atas 50ms freeze |
| Streaming buffered | 200ms | 2% | YouTube/Netflix tahan jitter karena pre-buffer |
| Gaming kompetitif | 15ms | 0.5% | FPS & MOBA paling sensitif ke jitter |
| Web browsing (HTTPS) | 100ms | 2% | TCP keep-alive absorb jitter, paling toleran |
| File transfer (SCP) | 500ms | 5% | TCP retransmit recover, hampir tidak terasa |
Rule of Thumb 3-Cek (Cheat Sheet Sysadmin)
Saat lihat output MTR, jalankan tiga pertanyaan ini berurutan. Kalau satu jawaban "ya" saja, sudah cukup bukti untuk eskalasi:
- 1. Apakah Loss% > 1% di hop selain hop terakhir? Kalau ya = packet loss intermediate, bukti routing/peering bermasalah.
- 2. Apakah StDev > 10ms di hop manapun yang bukan hop pertama? Kalau ya = jitter signifikan di sisi ISP, bukan LAN sendiri.
- 3. Apakah Wrst > 5× Avg di hop yang sama? Kalau ya = microburst signifikan, indikasi buffer overflow router.
Sebuah kantor klien (anonim — disamarkan sebagai "[Klien B2B]") melaporkan video meeting putus-putus konsisten jam 14:00. Speedtest menunjukkan 200/200 Mbps — ISP menutup tiket dengan "jaringan normal". Run MTR 100 paket ke
1.1.1.1 dari workstation user pukul 14:05: Loss 0%, Avg hop ke-3 = 28ms (normal), StDev hop ke-3 = 72ms, Wrst = 410ms. Pola yang sama tidak ada saat run jam 09:00 (StDev 4ms). Kesimpulan: peering exchange ISP overload jam kerja siang. Eskalasi ke account manager dengan output MTR plus rasio Wrst/Avg = 14× → ISP upgrade port keesokan harinya.Tier 3 — EXPERT: Untuk NOC & Network Engineer
Di tier ini kamu sudah berurusan dengan peering exchange, RPKI, AS path, dan koordinasi multi-NOC. Output MTR bukan cuma bukti tiket — tapi alat untuk merumuskan hipotesis routing yang spesifik. Tiga konsep yang membedakan tier ini dari Tier Medium: microbursts vs sustained jitter, ICMP filter trap, dan protocol probe selection.
Skenario Anonim — VPN Paradox di ISP B2B Premium
Kasus dunia nyata yang sudah dianonimkan: sebuah kampus negeri di Sumatra langganan ISP B2B premium (anonim — sebut "[ISP B2B]"). Engineer keluhan: "SSH ke VPS Singapore lemot tanpa VPN, lancar pakai VPN." Counterintuitive — VPN menambah hop, enkripsi, dan overhead, tapi malah mempercepat. Run MTR 100 paket ke 8.8.8.8 direct (tanpa VPN):
HOST: workstation Loss% Snt Last Avg Best Wrst StDev
1. 192.168.x.x 0.0% 100 1.2 1.4 0.9 3.2 0.5
2. xxx.xxx.xxx.xxx (CPE) 0.0% 100 2.1 2.3 1.8 5.0 0.7
3. xxx.xxx.xxx.xxx (gateway-isp) 0.0% 100 8.5 8.8 7.9 18.4 2.1
4. xxx.xxx.xxx.xxx (core-isp) 0.0% 100 15.2 15.8 14.3 29.7 3.4
5. xxx.xxx.xxx.xxx (border-isp) 0.0% 100 18.4 19.1 17.8 34.5 3.9
6. <peering-router>.[isp].net.id 0.0% 100 22.5 250.4 20.8 1030.0 100.9
7. xxx.xxx.xxx.xxx 0.0% 100 24.8 28.4 23.1 85.2 8.7
8. dns.google 0.0% 100 25.1 29.0 24.5 92.4 9.4
--- run via VPN provider X ---
Avg path latency: 45ms (lebih tinggi karena hop tambahan)
StDev all hops: < 4ms
Wrst all hops: < 80msBagaimana VPN bisa lebih cepat? VPN provider biasanya punya peering langsung ke major exchange (Equinix SG, etc.) yang berbeda dari peering ISP retail/B2B. Saat peering ISP overload jam sibuk, VPN tunnel ke datacenter mereka yang punya jalur lebih sehat — paradoks "lebih banyak hop, lebih cepat" terjelaskan. Dari sisi lapangan, ini bukti kuat untuk eskalasi NOC: "peering exchange kalian saturated, kami punya 100 paket bukti dengan StDev 100ms."
Microbursts vs Sustained Jitter
- Wrst >> Avg, tapi StDev moderat
- Buffer router penuh sesaat (millisecond)
- Tidak terdeteksi speedtest
- Penyebab: trafik bursty (video, backup)
- Mitigasi: WRED / shaping di edge
- Pattern: outlier ekstrem terisolasi
Avg 25ms, Wrst 800ms, StDev 18ms
- StDev tinggi terus-menerus
- Peering link saturated atau routing flap
- User merasa "lemot konsisten"
- Penyebab: kapasitas peering kurang
- Mitigasi: NOC upgrade port atau re-peering
- Pattern: rentang Best–Wrst lebar konsisten
Avg 45ms, Wrst 280ms, StDev 65ms
ICMP Filter Trap — "??? 100% Loss" yang Menyesatkan
Kalau MTR menampilkan ??? dengan Loss 100% di hop tengah (tapi hop setelahnya normal) — itu bukan packet loss. Itu router yang mem-filter ICMP TTL Exceeded reply (sangat umum di backbone untuk mengurangi noise). Paket forward jalan lurus, hanya identifikasi hop yang hilang. Trap-nya: engineer tier menengah sering laporkan ini sebagai "router mati" — padahal jaringan baik-baik saja.
??? 100% loss tapi hop ke-(N+1) menunjukkan Avg latency normal — berarti hop ke-N hanya filter ICMP, bukan rusak. Bukti packet loss real: hop ke-N ??? + hop berikutnya juga ??? + Loss% di destination > 0.Probe Selection — TCP / UDP / ICMP
mtr 8.8.8.8. ICMP echo, paling banyak diteruskan router. Tapi paling banyak juga di-filter atau de-prioritized di backbone — false positive jitter mungkin muncul.mtr -u 8.8.8.8. UDP packet ke port acak — biasanya lewat ICMP filter. Tapi banyak firewall corporate block UDP outbound, jadi tidak universal.mtr -T -P 443 8.8.8.8. TCP SYN ke port 443 — sama dengan trafik HTTPS user. Cara paling akurat untuk reproduce path aplikasi nyata. Caveat: di macOS ada bug lama di mode -T yang membuat hop kosong — workaround: pakai mtr-tiny via Homebrew atau jalan dari Linux box.Asymmetric Routing — Saat Forward Path ≠ Reverse Path
MTR cuma menampilkan path forward (kamu → tujuan). Tapi latency = forward + reverse. Kalau MTR dari kamu ke server menunjukkan path bersih, tapi latency tetap tinggi — kemungkinan reverse path (server → kamu) lewat jalur berbeda yang bermasalah. Cara verify: minta admin server jalankan MTR balik. Asymmetric routing umum di Indonesia karena BGP policy ISP retail seringkali tidak simetris dengan ISP B2B atau cloud provider.
RFC & Standar Industri untuk Eskalasi
| Standar | Threshold | Konteks |
|---|---|---|
| RFC 4594 Telephony class | Jitter < 30ms, Loss < 1% | DiffServ EF — voice service level |
| ITU-T Y.1541 Class 0 | Jitter < 50ms, Loss < 0.1% | IP performance objective real-time |
| ITU-T Y.1541 Class 1 | Jitter < 50ms, Loss < 0.1% | Highly interactive (gaming, trading) |
| ITU-T G.114 One-way delay | < 150ms ideal, < 400ms tolerable | Voice quality threshold |
| VoIP MOS 4.0+ | Jitter < 20ms, Loss < 0.5% | Excellent call quality |
Multi-Target MTR + Time-Series untuk Bukti Pattern
Satu MTR = satu titik waktu. Untuk membuktikan pattern (misal "lemot tiap jam 14:00") kamu butuh time-series. Cara cepat: jalankan MTR setiap 15 menit ke 3 target berbeda (1 domestik IIX, 1 SG, 1 US), simpan ke file. Tools seperti smokeping atau script bash sederhana dengan mtr --report-cycles 100 --json sudah cukup untuk dokumentasi pattern selama 24 jam.
#!/bin/bash
# log-mtr.sh — jalan via cron */15 * * * *
DATE=$(date '+%Y%m%d-%H%M')
for TARGET in 8.8.8.8 1.1.1.1 example.com; do
mtr --report --report-cycles 100 --json "$TARGET" \
> "/var/log/mtr/$DATE-$TARGET.json"
doneCheat Sheet — Threshold Lengkap untuk Lampiran Tiket
Tabel berikut adalah ringkasan threshold yang bisa langsung dilampirkan ke tiket NOC. Susun seperti template "angka aktual vs threshold standar" agar NOC tidak bisa mendeflect.
| Metric | Excellent | Normal | Warning | Critical |
|---|---|---|---|---|
| Loss% (destination) | 0% | < 0.5% | 0.5% – 2% | > 2% |
| Loss% (intermediate) | 0% | < 1% | 1% – 3% | > 3% (atau ICMP filter) |
| StDev (Avg ≈ 25ms) | < 5ms | 5 – 15ms | 15 – 50ms | > 50ms |
| Wrst / Avg ratio | < 2× | 2 – 5× | 5 – 10× | > 10× |
| Jumlah hop normal | 5 – 15 | 15 – 25 | 25 – 30 | > 30 atau loop |
Template Lampiran Tiket NOC
Pelaporan Performa Jaringan — [tanggal & jam]
Target probe : 8.8.8.8 (referensi netral)
Probe count : 100 paket
Mode : ICMP --report
Run lokasi : kantor [unit], LAN ethernet
Metric kritis di hop ke-[N]:
- Avg : XX ms
- StDev : XX ms (threshold ITU-T Y.1541 Class 1: 50ms)
- Wrst : XX ms (rasio Wrst/Avg = X×)
- Loss% : X%
Pattern temporal: [muncul setiap jam HH:MM, hilang di luar window]
Lampiran: output MTR full (JSON & TXT) untuk verifikasi.Kesalahan Umum yang Bikin Diagnosa Salah
- Lihat hop tengah
???100% loss dan menyimpulkan router rusak. Cek hop berikutnya — kalau jalan normal, itu cuma ICMP filter. - Lapor ISP cuma berdasarkan satu run MTR 10 paket. 10 paket terlalu kecil untuk statistik. Selalu pakai 100+ paket (
--report-cycles 100). - Membandingkan latency Avg lintas hop sebagai "kenaikan latency". Itu salah — yang penting latency Avg di hop terakhir (destination), bukan delta antar hop. Router intermediate sering de-prioritize ICMP.
- Run MTR sekali jam 03:00 (sepi) dan menyimpulkan jaringan sehat. Pattern hanya kelihatan saat jam sibuk yang sama dengan keluhan user. Reproduce dulu.
- Tidak run MTR balik dari sisi server. Asymmetric routing umum — masalah mungkin di reverse path yang tidak terlihat dari sisi kamu.
Tools CekIPSaya yang Mempercepat Diagnosa MTR
Saat lapor ke ISP atau NOC, kamu butuh data pendukung selain MTR — IP publik kamu saat probing, DNS resolver yang dipakai, dan blacklist status. Berikut tools internal yang sering jadi pasangan output MTR di lampiran tiket:
NOC ISP butuh tahu IP publik kamu saat masalah terjadi. Cek IP Saya menunjukkan IP + ASN + geolokasi untuk lampiran tiket.
Banyak "lemot" sebenarnya bottleneck DNS, bukan path. DNS Lookup memvalidasi resolver yang dipakai dan response time.
Untuk tiket NOC, satu screenshot dari Network Dashboard mencakup IP, DNS, ping, headers — copy lebih cepat daripada buka 5 tools terpisah.
FAQ — Pertanyaan yang Sering Ditanyakan
Kesimpulan
Membaca MTR bukan sekadar lihat angka — tapi tahu metric mana yang penting untuk skenario kamu. Tier basic cukup pegang Loss + Avg untuk lapor ke ISP rumahan. Tier medium wajib paham StDev untuk diagnose video conference & SSH lemot di jam sibuk. Tier expert butuh microburst, ICMP-filter trap, dan RFC reference untuk eskalasi peering ke NOC. Bookmark halaman ini sebagai cheat sheet — dan saat kamu menemukan StDev > 50ms di hop yang sama berulang, kamu sudah punya bukti angka yang jauh lebih kuat dari sekadar "internet lemot, Pak". Kombinasi dengan Network Dashboard CekIPSaya mempercepat agregasi bukti untuk lampiran tiket.