ping, traceroute, dan mtr

Chapter Network Diagnostics ditutup dengan kesimpulan yang menjengkelkan: mesin kita sehat di semua lapisan lokal, tetapi tujuan di ujung sana tetap tidak menjawab. Pertanyaan diagnosis kini bergeser dari “apakah mesin saya baik-baik saja?” menjadi “di titik mana jalur menuju tujuan terputus?”. Tiga alat klasik menjawab pertanyaan itu secara berurutan: ping menguji jangkauan ujung-ke-ujung, traceroute menelusuri jalur hop demi hop, dan mtr menggabungkan keduanya menjadi satu laporan yang terus diperbarui. Chapter ini membahas cara kerja ketiganya, cara membaca angka-angkanya, serta jebakan interpretasi yang paling sering menjerumuskan.

ping: Mengukur Jangkauan dengan ICMP Echo #

ping bekerja dengan protokol ICMP: program mengirim paket ICMP Echo Request ke alamat tujuan, dan mesin tujuan menyuruh kernelnya membalas dengan ICMP Echo Reply — asalkan tidak ada perangkat di jalur yang memblokirnya. Selisih waktu kirim dan terima balasan adalah RTT (round-trip time), ukuran jeda bolak-balik yang jadi bahan utama diagnosis. Tiga opsi paling sering dipakai:

Materi buku ini diuji di dalam container — lingkungan yang sengaja dibatasi izinnya demi keamanan — dan di sana ping lebih cepat menunjukkan batasnya daripada alat lain:

ping -c 3 127.0.0.1 2>&1

Output yang Dihasilkan:

ping: socktype: SOCK_RAW
ping: socket: Operation not permitted
ping: => missing cap_net_raw+p capability or setuid?

Pesan tersebut sama sekali bukan tanda jaringan yang mati. Kernel menolak membuka raw socket yang dibutuhkan ping karena prosesnya tidak memiliki capability CAP_NET_RAW — izin khusus untuk menyusun paket ICMP sendiri. Perintah yang sama berjalan mulus di mesin fisik maupun virtual biasa, dan hasilnya itulah yang kita bedah di bagian berikutnya.

Membaca Angka pada Hasil ping #

Berikut contoh tampilan ping -c 5 server-kantor pada mesin yang sehat:

PING server-kantor (192.0.2.20) 56(84) bytes of data.
64 bytes from server-kantor (192.0.2.20): icmp_seq=1 ttl=63 time=12.4 ms
64 bytes from server-kantor (192.0.2.20): icmp_seq=2 ttl=63 time=11.9 ms
64 bytes from server-kantor (192.0.2.20): icmp_seq=3 ttl=63 time=12.1 ms
64 bytes from server-kantor (192.0.2.20): icmp_seq=4 ttl=63 time=13.7 ms
64 bytes from server-kantor (192.0.2.20): icmp_seq=5 ttl=63 time=12.0 ms

--- server-kantor ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4003ms
rtt min/avg/max/mdev = 11.912/12.420/13.701/0.682 ms

Setiap baris 64 bytes adalah satu balasan, dan tiap kolomnya punya arti diagnosis:

Angka-angka itu dibaca sebagai satu cerita. RTT kecil dengan mdev kecil berarti jalur stabil; RTT yang naik turun tajam menandakan kemacetan atau rute yang berubah-ubah; packet loss yang terus muncul menunjuk pada link jenuh atau firewall yang sengaja membatasi ICMP. Ingat pula batas alat ini: mesin yang menjawab ping belum menjamin layanannya hidup — ICMP hingga port aplikasi adalah dua lapisan yang berbeda.

traceroute: Menelusuri Jalur Hop demi Hop #

ping hanya berkata “sampai” atau “tidak sampai”. traceroute menjawab pertanyaan lanjutannya: lewat mana paket kita berjalan, dan di hop mana jalur putus? Kerjanya memanfaatkan field TTL (time to live) pada header IP. Setiap router yang melewatkan paket mengurangi TTL satu; ketika TTL mencapai nol, router membuang paket itu dan mengirim pesan ICMP Time Exceeded kembali ke pengirim. traceroute memanfaatkan mekanisme tersebut dengan sengaja: probe pertama dikirim TTL 1 (dijawab router pertama), lalu TTL 2 (dijawab router kedua), dan seterusnya sampai tujuan menjawab — sehingga sumber tiap pesan Time Exceeded memetakan jalur secara berurutan. Berikut contoh tampilan tipikalnya:

traceroute to server-kantor (192.0.2.20), 30 hops max, 60 byte packets
 1  192.0.2.1 (192.0.2.1)      1.296 ms  1.083 ms  1.045 ms
 2  198.51.100.9 (198.51.100.9)  8.513 ms  8.420 ms  8.634 ms
 3  * * *
 4  203.0.113.5 (203.0.113.5)  35.892 ms  36.014 ms  35.760 ms
 5  192.0.2.20 (192.0.2.20)    35.401 ms  35.553 ms  35.380 ms

Tiap baris mewakili satu hop dengan tiga probe dan RTT masing-masing. Lonjakan waktu antara hop 2 dan hop 4 — dari sekitar 8 ms ke 36 ms — mengindikasikan segmen jarak jauh (misalnya lintas kota atau laut). Baris * * * pada hop 3 adalah kejadian paling sering disalahartikan: router tersebut hidup dan meneruskan paket dengan baik, tetapi sengaja tidak menjawab pesan probe. Banyak router membatasi (rate-limit) ICMP balasan agar kontrol planenya tidak dipakai membanjiri trafik, dan sebagian firewall memblokirnya sama sekali. Kesimpilan yang benar dari contoh di atas justru terlihat di hop 4: paket masih berjalan melewati hop 3, jadi jalur tidak putus.

mtr: Memadukan ping dan traceroute dalam Satu Layar #

Kelemahan traceroute adalah potret sekali jalan: tiga probe per hop, selesai. mtr (my traceroute) menggabungkan keduanya menjadi pemantauan kontinu — program menjalankan traceroute sekali untuk menemukan daftar hop, lalu terus mengirim probe ke setiap hop sambil mengakumulasi statistiknya. Format laporannya yang paling berguna adalah mtr --report, yang berhenti setelah jumlah sampel tertentu lalu mencetak tabel per hop. Karena laporan seperti itu lambat dieksekusi di lingkungan uji buku ini, kita berlatih dengan berkas laporan yang sudah tersimpan, lalu menyaring hop yang kehilangan paket:

cat > laporan-mtr.txt <<'LAPORAN'
                              Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 192.0.2.1                  0.0%   120    1.2   1.4   0.9   8.3   0.9
 2. 198.51.100.9               0.0%   120    8.1   8.6   7.2  15.4   1.2
 3. 203.0.113.5               20.0%   120   35.2  36.8  33.1  60.2   5.4
 4. 192.0.2.20               18.3%   120   35.8  36.2  34.0  58.7   4.8
LAPORAN
awk 'NR > 1 && $3+0 > 0 {sub(/\.$/, "", $1); print "hop " $1 " (" $2 "): loss " $3}' laporan-mtr.txt

Output yang Dihasilkan:

hop 3 (203.0.113.5): loss 20.0%
hop 4 (192.0.2.20): loss 18.3%

Mari kita bedah baris penyaringnya:

1. NR > 1: melewati baris pertama berisi judul kolom, karena baris itu bukan data hop.
2. $3+0 > 0: kolom ketiga berisi Loss% dalam bentuk teks seperti 20.0%; menjumlahkannya dengan nol memaksa awk memperlakukannya sebagai angka, sehingga hanya hop dengan loss di atas nol yang lolos.
3. sub(/\.$/, "", $1): nomor hop pada laporan mtr berformat 3. dengan titik di ujung — titik itu dibuang agar kalimatnya rapi.
4. print "hop " $1 " (" $2 "): loss " $3: menyusun baris ringkas berisi nomor hop, alamat router, dan persentase paket yang hilang.

Pola pembacaannya begini: loss yang muncul di satu hop lalu bersih lagi di hop berikutnya biasanya cuma rate-limit ICMP — router itu tidak menjawab, padahal paket yang diteruskan sehat. Sebaliknya, loss yang berlanjut sampai hop tujuan adalah masalah nyata: pada laporan di atas hop 3 dan tujuan sama-sama kehilangan sekitar 20% paket, sehingga segmen di sekitar hop 3 pantas dicurigai. Kolom Snt menunjukkan berapa probe sudah dikirim — makin besar sampelnya, makin layak dipercaya persentasenya.

Memilih Alat yang Sesuai #

Ketiganya mengamati jalur dari luar — dari mesin kita menuju dunia. Pekeriksaan berikutnya bergerak ke arah sebaliknya: dari dunia menuju mesin kita, tepatnya ke socket mana saja yang sedang terbuka dan siapa proses di baliknya. Itulah pekerjaan ss, Chapter berikutnya.

Referensi lanjut: halaman manual ping(8) untuk daftar opsi lengkapnya, traceroute(8) untuk mode probe lain, serta mtr(8) untuk opsi laporan.