Bayangkan skenario ini: speedtest 100 Mbps, ping ke Google 30ms tanpa loss, semua karyawan di satu departemen lapor browsing lemot. Anehnya, begitu user nyalakan VPN — internet langsung lancar. User di departemen lain juga aman. Apa yang sedang terjadi?
Pattern ini sering bikin admin jaringan buang waktu mengejar hipotesis salah seperti masalah ISP, bandwidth penuh, atau IP publik kena blacklist. Padahal penyebabnya satu yang sering dilewati: DNS cache busuk di router gateway. Studi kasus berikut adalah insiden nyata yang berhasil diselesaikan dalam hitungan menit setelah berjam-jam diagnosis salah arah.
Studi Kasus — Insiden Lemot di Departemen Riset
Sebuah unit kerja di institusi pendidikan tinggi melaporkan internet lemot pagi hari. Cluster jaringan unit ini terdiri dari empat VLAN (staf, lantai 1, lantai 2, dan WiFi tamu) yang dilayani oleh satu router Mikrotik gateway. Berikut kronologi diagnosa.
Test ke speedtest.net konsisten >50 Mbps download, latency rendah. Tidak ada indikasi bandwidth bermasalah.
Ping ke 8.8.8.8 dan 1.1.1.1 stabil di 25-35ms tanpa packet loss. Layer transport sehat.
User yang aktifkan VPN client (WireGuard/OpenVPN ke server eksternal) langsung browsing normal — semua website load cepat.
Unit kerja sebelah, masih dalam satu kampus dan satu ISP, internet lancar tanpa keluhan. Hanya satu cluster VLAN yang kena.
Halaman web sering stuck di "Looking up...", connection time-out, atau loading lama padahal speed bandwidth tinggi.
Diagnosis yang Salah Arah (Yang Sering Dilakukan)
Sebelum sampai ke akar masalah, tim teknis sempat mengejar empat hipotesis yang semuanya gagal — habiskan kurang lebih 2 jam. Berikut catatannya supaya Anda tidak ulangi kesalahan yang sama.
Cek di Spamhaus, Talos, AbuseIPDB — IP publik kantor bersih. Sebelumnya memang ada riwayat IP kotor yang sudah di-rotate, tapi IP baru yang sekarang sudah verified clean. Bukan ini.
Test ping -D -s 1472 8.8.8.8 dari client lemot — paket 1500 lewat tanpa drop. MTU jalur sehat. Bukan ini.
Traceroute dari router gateway ke 8.8.8.8 dan beberapa CDN populer — latency normal 24-34ms, tidak ada loop atau hop dengan loss real (loss di hop tengah cuma ICMP rate-limit, hop berikutnya 0%). Bukan ini.
Cek /ip firewall connection print count-only di Mikrotik — jumlah koneksi normal, tidak dekat limit. Memory router juga lega. Bukan ini.
Akar Masalah Sebenarnya — DNS Cache Busuk
Setelah eliminasi empat hipotesis di atas, tim coba command sederhana di router gateway:
/ip dns cache flushInternet langsung lancar untuk semua user di cluster. Tanpa restart, tanpa rotate IP, tanpa eskalasi ke ISP. Lima detik command, masalah selesai.
Mengapa DNS Cache Busuk Bisa Bikin "Lemot"?
Router/gateway biasanya bertindak sebagai DNS cache untuk semua client di belakangnya. Saat client query domain (misal google.com), router cek cache lokal dulu sebelum query ke DNS upstream. Cache ini punya umur (TTL) — biasanya menit hingga jam.
Kalau cache stale atau corrupt, record yang dikembalikan bisa salah: misal IP server yang sudah pindah, IP node CDN yang lambat untuk geografi user, atau IP edge server yang sedang down. Akibatnya client connect ke endpoint salah → koneksi lambat atau time-out.
Speedtest klien biasanya pakai DNS sendiri atau IP server speedtest yang sudah di-hardcode di aplikasinya. Tidak hit cache router yang busuk.
Ping ke 8.8.8.8 atau 1.1.1.1 langsung pakai IP — tidak butuh DNS resolve. Layer transport sehat, jadi ping pasti normal.
Aplikasi VPN biasa pakai DNS sendiri (Cloudflare, NextDNS, atau DNS dari VPN provider). Traffic enkripsi langsung ke VPN server, bypass cache router lokal.
Kalau setiap VLAN dilayani gateway/router berbeda, cache busuk di satu router tidak menular ke router lain. Hanya VLAN yang gateway-nya kena yang merasakan.
Setiap halaman web modern resolve puluhan domain (CDN, fonts, ads, analytics). Kalau cache router stuck di IP lambat untuk beberapa domain populer, halaman load berputar lama menunggu.
Solusi Cepat — Flush DNS Cache
Tergantung perangkat router/gateway yang dipakai, command flush DNS cache berbeda. Berikut command untuk merek paling umum di Indonesia:
Mikrotik RouterOS
/ip dns cache flush
# Cek jumlah cache sebelum & sesudah:
/ip dns cache print count-onlyCisco IOS
Router# clear ip dns cache
# Atau di mode global:
Router(config)# no ip dns server
Router(config)# ip dns serverRuijie RGOS
Switch# clear dns cache
# Atau restart DNS proxy:
Switch# clear ip dnsLinux/OpenWRT (router open source)
# OpenWRT (dnsmasq):
service dnsmasq restart
# systemd-resolved (Linux server):
sudo systemd-resolve --flush-caches
# unbound:
sudo unbound-control flush_zone .Tiga Perspektif — User, Admin, dan Operator IT
Masalah yang sama dilihat dari sudut pandang berbeda butuh respons berbeda. Berikut panduan untuk masing-masing peran.
👤 Sisi User — "Saya Cuma Mau Internet Lancar"
Anda bukan IT, tidak punya akses router, dan cuma mau kerjaan beres. Berikut langkah praktis sebelum lapor ke IT:
Cek apakah rekan kerja di lantai/ruangan sama juga lemot. Kalau iya — bukan device Anda, ini issue jaringan kantor. Lapor ke IT dengan info ini.
Tekan Ctrl+F5 (Windows) atau Cmd+Shift+R (Mac) di halaman yang lemot. Kalau jadi cepat — cuma cache browser Anda. Kalau masih lemot — masalah di luar perangkat Anda.
Buka command prompt sebagai admin, jalankan: ipconfig /flushdns (Windows). macOS: sudo dscacheutil -flushcache. Kalau sembuh — masalah cache lokal Anda saja.
Ganti DNS device Anda ke 1.1.1.1 atau 8.8.8.8 (lihat panduan setting DNS). Kalau langsung lancar — confirmed problem di DNS gateway kantor, bukan di Anda. Lapor IT dengan bukti ini.
Sertakan: jam mulai bermasalah, sudah berapa lama, situs apa yang lemot, hasil test point #1-#4 di atas. Tiket dengan data lengkap diselesaikan 5x lebih cepat.
🛠️ Sisi Admin Jaringan — Diagnose & Fix
Anda yang pegang akses router/gateway. Tiket masuk dengan keluhan "internet lemot di departemen X". Berikut urutan diagnose efisien — selesai dalam 10 menit kalau pattern match.
Tanya pelapor: "Apakah rekan se-VLAN/se-departemen juga merasakan?" Kalau ya — issue cluster, bukan single user. Cek dashboard monitoring: traffic egress wajar, bandwidth tidak saturated.
Dari client di cluster bermasalah: speedtest ✓, ping 8.8.8.8 ✓, traceroute 8.8.8.8. Kalau ketiganya OK tapi browsing lemot — confirmed bukan layer transport.
Suruh user nyalakan VPN apa saja (HotspotShield, ProtonVPN, atau VPN client kantor). Kalau langsung lancar = strong signal DNS atau IP reputation issue.
Sebelum diagnosis panjang IP reputation, MTU, peering — coba flush DNS cache di router yang melayani VLAN bermasalah. 80% kasus pattern ini selesai di sini. Kalau gak selesai, lanjut step 5.
Pastikan DNS server upstream router masih sehat: dig @1.1.1.1 google.com +stats. Kalau query time >300ms atau timeout, ganti DNS upstream. Set cache-max-ttl=1h untuk paksa refresh record.
Cek IP reputation, MTU blackhole, conntrack saturation, peering ke destination spesifik. Detail di artikel Troubleshooting Internet Step-by-Step.
# 1. DNS upstream reliable + cache max TTL 1 jam
/ip dns set servers=1.1.1.1,8.8.8.8 \
cache-max-ttl=1h cache-size=2048KiB
# 2. Auto-flush cache scheduled tiap 2 jam
/system scheduler
add name="dns-cache-flush" interval=2h \
on-event="/ip dns cache flush" \
comment="Mitigate stale DNS cache"
# 3. Allow client query ke DNS lokal router
/ip dns set allow-remote-requests=yes🎧 Sisi Operator IT / Helpdesk — SOP Tiket
Anda terima tiket "internet lemot" dari user. Tugas Anda: triage cepat, gali info yang berguna, eskalasi ke admin yang tepat. Berikut SOP-nya:
(a) Mulai jam berapa? (b) Departemen/lantai/VLAN? (c) Apakah rekan satu ruangan juga? (d) Sudah coba VPN? Hasilnya? (e) Apa nama situs yang dikeluhkan? Tiket tanpa data ini = bouncing kembali.
Single user → guide remote ke flush DNS lokal, hard refresh, ganti DNS. Cluster (>2 user satu lokasi) → langsung escalate ke admin jaringan dengan tag [CLUSTER].
Tiket dengan kombinasi "speedtest OK + VPN bypass lancar + cluster" — tag prioritas tinggi, biasanya gateway-level issue. Eskalasi langsung dengan template "suspect DNS cache".
Setelah eskalasi, balas user: "Tim jaringan sedang investigasi gateway departemen Anda. ETA 15-30 menit. Sementara workaround: gunakan tethering/personal hotspot atau VPN aktif." Set ekspektasi.
Setelah selesai, catat root cause + fix command di KB. Lain kali tiket serupa masuk, operator bisa langsung saran fix tanpa eskalasi.
"Halo [nama], terima kasih sudah lapor. Sebelum kami cek dari sisi server, mohon coba 3 hal cepat ini:
1. Tekan Ctrl+F5 di halaman yang lemot.
2. Buka Command Prompt → ketik
ipconfig /flushdns.3. Coba aktifkan VPN (kantor atau pribadi).
Kalau langkah 3 langsung bikin lancar — info ini sangat membantu kami diagnosa, balas tiket ini dengan jawaban ‘VPN bikin lancar’. Kalau tidak ada yang berubah, kami akan langsung cek dari sisi gateway departemen Anda. ETA 15 menit."
Toolkit Lengkap — Command Reference untuk Teknisi Indonesia
Kumpulan command yang wajib dikuasai teknisi jaringan untuk diagnose insiden "internet lemot" secara sistematis. Disusun dari yang paling sering dipakai ke yang advanced. Setiap command disertai versi Windows / macOS-Linux / Mikrotik-Cisco-Ruijie + interpretasi hasilnya.
1. Cek IP Publik & Reputation
Tujuan: verifikasi IP publik aktif yang dipakai client, dan apakah IP itu listed di blacklist (Spamhaus, Talos, AbuseIPDB).
# Cek IP publik aktif (Windows/macOS/Linux)
curl -s ipinfo.io/ip
curl -s https://api.ipify.org
# Atau dari browser, buka:
# https://cekipsaya.com → hero menampilkan IP
# Cek detail ASN, lokasi, ISP:
curl -s ipinfo.io/json | jq# Cek reputation IP — buka di browser:
https://check.spamhaus.org/results/?query=<IP>
https://talosintelligence.com/reputation_center/lookup?search=<IP>
https://www.abuseipdb.com/check/<IP>
https://mxtoolbox.com/SuperTool.aspx?action=blacklist:<IP>2. Test Latency & Packet Loss (Ping)
Tujuan: ukur latency end-to-end, deteksi packet loss, dan jitter. Layer transport sehat kalau ping stabil dengan loss 0%.
# Linux/macOS — 20 paket
ping -c 20 8.8.8.8
ping -c 20 1.1.1.1
# Windows — 20 paket
ping -n 20 8.8.8.8
ping -n 20 1.1.1.1
# Mikrotik
/tool ping count=20 8.8.8.8
# Cisco IOS
Router# ping 8.8.8.8 repeat 20
# Ruijie RGOS
Switch# ping 8.8.8.8 -count 20• Latency stabil (jitter <10ms) + loss 0% = layer transport sehat.
• Latency naik turun drastis (jitter >50ms) = congestion atau bufferbloat.
• Loss konsisten di destination publik = problem upstream/peering.
• Loss intermittent = kabel/optic/RF issue (kalau WiFi).
• Latency >100ms ke 8.8.8.8 dari Indonesia = abnormal, cek routing.
3. Test MTU & Path MTU Discovery (PMTUD)
Tujuan: deteksi link sempit di jalur (VPN, MPLS, PPPoE) yang bikin paket besar di-drop tapi paket kecil lolos. Gejala: speedtest+ping OK, tapi HTTPS large transfer stall.
# macOS/Linux — uji MTU 1500 (paket 1500 = 1472 payload + 28 header)
ping -D -s 1472 -c 10 8.8.8.8
# Test ladder turun:
ping -D -s 1452 -c 5 8.8.8.8 # MTU 1480
ping -D -s 1422 -c 5 8.8.8.8 # MTU 1450
ping -D -s 1372 -c 5 8.8.8.8 # MTU 1400 (biasanya lewat)
ping -D -s 1272 -c 5 8.8.8.8 # MTU 1300 (sangat sempit, abnormal)
# Windows (parameter berbeda)
ping -f -l 1472 -n 10 8.8.8.8
ping -f -l 1372 -n 5 8.8.8.8
# Mikrotik
/tool ping size=1472 do-not-fragment=yes count=10 8.8.8.8•
1472 sukses = MTU jalur 1500 (sehat) ✅•
1472 gagal, 1372 sukses = MTU jalur 1400 (ada link sempit, set MSS clamp di router)•
1372 gagal, 1272 sukses = MTU jalur 1300 (abnormal, ada double-tunnel atau misconfig)• Pesan "Frag needed and DF set (mtu = X)" = router kasih tau MTU jalur sebenarnya = X bytes.
Contoh Output Real — Jalur MTU Sehat
Berikut contoh output saat MTU jalur sehat (paket 1372 lewat tanpa fragmentasi). Perhatikan latency stabil 40-46 ms tanpa drop:
$ ping -D -s 1372 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 1372 data bytes
1380 bytes from 8.8.8.8: icmp_seq=0 ttl=117 time=40.786 ms
1380 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=45.897 ms
1380 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=46.603 ms
1380 bytes from 8.8.8.8: icmp_seq=3 ttl=117 time=42.876 ms
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 40.786/44.040/46.603/2.330 ms1380 bytes = 1372 payload + 8 ICMP header. 0% packet loss + latency konsisten = jalur MTU 1400 sehat. Kalau muncul "Message too long" atau "Frag needed", berarti ada link yang tidak bisa lewat paket sebesar ini.# Fix MTU blackhole — MSS clamp di Mikrotik
/ip firewall mangle
add chain=forward protocol=tcp tcp-flags=syn \
action=change-mss new-mss=1400 \
tcp-mss=1401-65535 \
comment="MSS clamp untuk PMTUD blackhole"4. Traceroute — Tracing Hop-by-Hop
Tujuan: identifikasi hop tempat latency naik, packet loss real, atau routing aneh (loop, asimetris).
# macOS/Linux
traceroute 8.8.8.8
traceroute -n 8.8.8.8 # tanpa reverse DNS, lebih cepat
mtr -r -c 100 8.8.8.8 # mtr = traceroute + ping continuous (best)
# Windows
tracert 8.8.8.8
pathping 8.8.8.8 # = mtr versi Windows
# Mikrotik (mode interaktif)
/tool traceroute 8.8.8.8
# Cisco IOS
Router# traceroute 8.8.8.8
# Ruijie RGOS
Switch# traceroute 8.8.8.85. Test DNS Resolution Speed
Tujuan: ukur kecepatan resolve domain. Kalau >300ms = DNS server lambat atau cache busuk — biang kerok "lemot subjektif".
# Linux/macOS — pakai dig (bind-tools)
dig @8.8.8.8 google.com +stats | grep "Query time"
dig @1.1.1.1 detik.com +stats | grep "Query time"
dig @<DNS-router-lokal> google.com +stats | grep "Query time"
# Cek DNS server yang sedang dipakai client
# macOS
scutil --dns | grep nameserver
# Windows
ipconfig /all | findstr DNS
# Linux
cat /etc/resolv.conf
# nslookup (Windows native, simpler)
nslookup detik.com
nslookup google.com 1.1.1.1• <50ms — sangat cepat, DNS sehat ✅
• 50-150ms — normal, OK
• 150-300ms — agak lambat, monitor
• >300ms — lambat, ganti DNS upstream atau flush cache
• Timeout / SERVFAIL — DNS server down atau cache corrupt, flush sekarang
6. HTTP Timing Breakdown — Pin-point Bottleneck
Tujuan: pisahkan waktu DNS resolve, TCP connect, TLS handshake, dan TTFB. Cara paling akurat untuk tahu di tahap mana yang lambat.
# All-in-one curl timing breakdown (Linux/macOS/Windows curl)
curl -w "\
DNS Lookup: %{time_namelookup}s\n\
TCP Connect: %{time_connect}s\n\
TLS Handshake: %{time_appconnect}s\n\
TTFB: %{time_starttransfer}s\n\
Total: %{time_total}s\n\
" -o /dev/null -s https://www.cloudflare.com
# Test tanpa & dengan VPN — bandingkan TTFB
# Tanpa VPN:
curl -w "DNS:%{time_namelookup}s TCP:%{time_connect}s TTFB:%{time_starttransfer}s\n" \
-o /dev/null -s https://www.google.com
# Dengan VPN aktif, ulang command sama• DNS Lookup tinggi (>0.5s) = DNS resolver lambat → ganti DNS atau flush cache
• TCP Connect tinggi (>1s) = network/routing buruk ke server tersebut
• TLS Handshake tinggi (>2s) = packet loss saat handshake (sering MTU issue)
• TTFB tinggi tapi yang lain normal = server destination yang lambat (bukan masalah Anda)
• Semua tinggi = problem layer transport, cek bandwidth/loss
7. Cek Conntrack & NAT di Router
Tujuan: deteksi NAT/conntrack table penuh — sering pada cluster dengan banyak user concurrent. Gejala: koneksi baru lambat establish, koneksi existing OK.
# Mikrotik — cek jumlah koneksi aktif
/ip firewall connection print count-only
# Cek detail per protokol
/ip firewall connection print where protocol=tcp
# Memory & CPU router
/system resource print
/system resource cpu print
# Flush conntrack (mild disruption, semua koneksi reset)
/ip firewall connection remove [find]# Cisco IOS — show NAT translations
Router# show ip nat translations
Router# show ip nat statistics
# Linux router (iptables/nftables)
sudo conntrack -L | wc -l # count koneksi
cat /proc/sys/net/netfilter/nf_conntrack_max # limit
cat /proc/sys/net/netfilter/nf_conntrack_count # current
# Naikan limit (Linux)
sudo sysctl -w net.netfilter.nf_conntrack_max=1310728. Flush Cache (Per Platform)
Tujuan: bersihkan stale cache di setiap layer — client OS, browser, dan router gateway.
# Windows (run as Administrator)
ipconfig /flushdns
ipconfig /release && ipconfig /renew
netsh winsock reset # reset network stack (perlu reboot)
netsh interface ip reset
# macOS
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
# Linux (systemd-resolved)
sudo systemd-resolve --flush-caches
sudo resolvectl flush-caches # newer
# Linux (nscd)
sudo systemctl restart nscd# Mikrotik RouterOS
/ip dns cache flush
/ip dns cache print count-only # cek jumlah cache
# Cisco IOS
Router# clear ip dns cache
# Ruijie RGOS
Switch# clear dns cache
# OpenWRT (dnsmasq)
service dnsmasq restart# Browser — flush DNS internal
# Chrome/Edge: buka chrome://net-internals/#dns → Clear host cache
# Chrome/Edge: buka chrome://net-internals/#sockets → Flush socket pools
# Firefox: about:networking#dns → Clear DNS Cache9. Bandwidth Test (CLI Tools)
Tujuan: ukur throughput tanpa browser — bisa di-script, masuk monitoring, atau test dari server tanpa GUI.
# speedtest CLI (install dari speedtest.net/apps/cli)
speedtest --accept-license --accept-gdpr
# fast.com CLI
npx fast-cli
# iperf3 — test internal throughput (butuh server iperf3)
iperf3 -c iperf.server.com -t 30 # client
iperf3 -s # server
# Mikrotik bandwidth test (built-in)
/tool bandwidth-test address=<IP> direction=both duration=30s10. Diagnostic Internal LAN (Layer 2)
Tujuan: deteksi problem di LAN sendiri sebelum eskalasi ke ISP. Cek MAC table, CDP/LLDP neighbor, broadcast storm.
# Cek ARP table client
arp -a # Windows
arp -a # macOS/Linux (sama)
ip neigh # Linux modern
# Mikrotik — cek MAC table & ARP
/ip arp print
/interface ethernet monitor [find] once # link speed/duplex
/interface monitor-traffic interface=ether1 once
# Cisco IOS
Switch# show mac address-table
Switch# show interfaces counters errors
Switch# show cdp neighbors
Switch# show spanning-tree summary
# Ruijie RGOS
Switch# show mac-address-table
Switch# show interface counters errors
Switch# show lldp neighbor
# Cek interface error/CRC
# Mikrotik
/interface ethernet print stats-detail
# Cisco
Switch# show interfaces gi0/1 | inc errors|CRC|drop• CRC errors / input errors naik terus = kabel/optic/SFP rusak, ganti
• Late collisions = duplex mismatch (auto-neg gagal)
• Broadcast packet >5% total traffic = potensi broadcast storm, cek STP
• MAC flapping = loop di network, langsung shut port suspect
Level Expert — Deep Analysis & Packet Capture
Saat 10 command di atas tidak cukup mengungkap akar masalah, masuk ke level expert: packet capture, TCP behavior analysis, real-time per-flow monitoring, dan performance tuning. Section ini untuk teknisi senior yang sudah nyaman dengan layer 4-7.
11. Packet Capture — tcpdump & Wireshark
Kapan dipakai: saat gejala spesifik (cuma satu aplikasi/destination lemot, TCP RST suspicious, retransmit tinggi) dan command standar tidak cukup.
# Linux/macOS — capture ringan ke file untuk dibuka di Wireshark
sudo tcpdump -i any -w /tmp/capture.pcap -G 60 -W 1
# (capture 60 detik, simpan ke capture.pcap)
# Filter spesifik destination — kurangi noise
sudo tcpdump -i any -w /tmp/dst.pcap host 1.1.1.1
sudo tcpdump -i any 'tcp port 443 and host google.com'
# Cari TCP retransmission live
sudo tcpdump -i any 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0'
sudo tcpdump -i any 'tcp[13] & 4 != 0' # TCP RST flag
# DNS query/response only
sudo tcpdump -i any port 53 -A -n# Mikrotik /tool sniffer — capture ke file
/tool sniffer set file-name=cap.pcap file-limit=10MiB
/tool sniffer set filter-ip-address=8.8.8.8
/tool sniffer set filter-port=443
/tool sniffer start
# ... tunggu 30-60 detik ...
/tool sniffer stop
# Download cap.pcap via Files, buka di Wireshark
# Live monitoring via Torch (per-IP/port real-time)
/tool torch interface=ether1 port=443
/tool torch interface=ether1 src-address=192.168.10.0/24tcp.analysis.flags untuk lihat retransmit, dup ack, zero window, out-of-order. Pakai Statistics → Conversations → TCP untuk identifikasi flow paling aktif. Pakai Statistics → I/O Graph untuk visualisasi traffic burst vs steady.12. TCP Connection Analysis
Tujuan: analisis behavior koneksi TCP aktif — RTT, retransmit, congestion window, window scaling. Indikator definitif untuk problem layer 4.
# Linux — ss (socket statistics)
ss -tin # all TCP connections + internal info
ss -ti dst 1.1.1.1 # specific destination
ss -tinH dst :443 | head -20 # HTTPS connections, no header
# Linux — netstat extended
netstat -ant | awk '{print $6}' | sort | uniq -c
# (count koneksi per state — TIME_WAIT tinggi = abnormal)
# TCP retransmits stats system-wide
nstat -az | grep -i retrans
cat /proc/net/snmp | grep -A1 Tcp
# Cek TCP congestion control algorithm
sysctl net.ipv4.tcp_congestion_control
# Modern: cubic, bbr — BBR lebih baik untuk Indonesia• retrans:N/M dengan rasio >2% = packet loss real di jalur
• cwnd selalu kecil (<10) padahal RTT rendah = congestion control aktif drop
• rcv_space stuck di nilai kecil = receive window tidak scale, perlu tuning
• TIME_WAIT ribuan = port exhaustion akan datang, cek
net.ipv4.tcp_tw_reuse13. NIC & Buffer Tuning
# Linux — ethtool: cek & tune NIC
ethtool eth0 # speed, duplex, link
ethtool -S eth0 | grep -i 'drop\|error' # statistics
ethtool -g eth0 # ring buffer size
ethtool -G eth0 rx 4096 tx 4096 # naikan ring buffer
ethtool -k eth0 # offload features
ethtool -K eth0 gso on tso on lro on # enable offload
# Cek drop di queue
tc -s qdisc show dev eth0
# Increase TX queue length
ip link set eth0 txqueuelen 10000
# Linux TCP buffer tuning (sysctl)
sysctl -w net.core.rmem_max=134217728
sysctl -w net.core.wmem_max=134217728
sysctl -w net.ipv4.tcp_rmem='4096 87380 67108864'
sysctl -w net.ipv4.tcp_wmem='4096 65536 67108864'
sysctl -w net.ipv4.tcp_congestion_control=bbr14. Mikrotik Real-time Monitoring
# Torch — paling powerful, per-IP per-port live
/tool torch interface=ether1 \
src-address=10.0.0.0/8 \
port=any \
src-port=any
# Profile — cek apa yang makan CPU
/tool profile duration=10s
# Graphing — built-in traffic graph
/tool graphing interface add interface=ether1
/tool graphing resource add
# Akses: http://router/graphs/
# Netwatch — auto-monitor host & trigger script
/tool netwatch
add host=8.8.8.8 interval=30s timeout=2s \
up-script=":log info \"Internet UP\"" \
down-script=":log warning \"Internet DOWN\"; /system script run notify-admin"
# SNMP-style query (untuk integrasi Grafana)
/snmp set enabled=yes
/snmp community add name=public addresses=10.0.0.0/8# Script auto-diagnose & alert
/system script add name="check-dns-health" source={
:local resolveTime [/resolve google.com server=1.1.1.1];
:local cacheCount [/ip dns cache print count-only];
:if ($cacheCount > 5000) do={
:log warning "DNS cache size: $cacheCount, auto-flush";
/ip dns cache flush;
};
}
# Schedule jalankan tiap 30 menit
/system scheduler add name="dns-health" interval=30m \
on-event="/system script run check-dns-health"15. Routing & BGP Analysis
Tujuan: verifikasi routing path optimal, deteksi asymmetric routing, cek prefix advertisement, dan compare dengan public looking glass.
# Cek BGP prefix lookup ke ASN target (looking glass online)
# https://bgp.he.net/ip/8.8.8.8
# https://radar.cloudflare.com/
# https://lg.he.net (Hurricane Electric Looking Glass)
# https://lg.bgp.tools
# Cek ASN-mu dari IP publik
curl -s https://ipinfo.io/AS<your_asn>
# Trace dengan AS path
mtr --aslookup 8.8.8.8
mtr -ezbw 8.8.8.8 # AS lookup + bandwidth
# Compare routing kampus vs public looking glass:
# 1. Trace dari Mikrotik kampus ke 8.8.8.8 — catat hop
# 2. Buka https://lg.he.net → input 8.8.8.8 dari node Asia
# 3. Bandingkan AS path — kalau jauh lebih panjang dari kampus,
# indikasi peering ISP suboptimal# Mikrotik dengan BGP — cek peer & prefix
/routing bgp peer print
/routing bgp peer print status
/ip route print where bgp
/ip route print count-only where bgp
# Cek route specific destination
/ip route check 8.8.8.8
# Cisco IOS BGP
Router# show ip bgp summary
Router# show ip bgp 8.8.8.8
Router# show ip route 8.8.8.816. DNS Deep Debug — DNSSEC, DoH, Propagation
# DNSSEC validation check
dig google.com +dnssec +short
dig google.com DNSKEY +short
dig +trace google.com # full chain validation
# DoH (DNS over HTTPS) test manual
curl -s 'https://cloudflare-dns.com/dns-query?name=google.com&type=A' \
-H 'accept: application/dns-json' | jq
# Propagation check across multiple resolvers
for dns in 1.1.1.1 8.8.8.8 9.9.9.9 208.67.222.222; do
echo "=== $dns ==="
dig @$dns google.com +short
dig @$dns google.com +stats | grep "Query time"
done
# Public propagation check (browser)
# https://dnschecker.org/
# https://www.whatsmydns.net/
# Cek TTL record (penting untuk planning migrasi)
dig google.com | grep -A1 ANSWER
# format: domain TTL IN A IP17. Bufferbloat Detection & Mitigation
Bufferbloat: kondisi di mana router/modem ISP buffer terlalu besar, menyebabkan latency naik drastis saat link saturated (download/upload kencang). Gejala: ping naik dari 30ms ke 300ms+ saat unduh file besar.
# Test bufferbloat — Waveform Bufferbloat Test
# Browser: https://www.waveform.com/tools/bufferbloat
# Hasil: skor A-F, kalau D/F = bufferbloat parah
# Manual test — saturate link, ukur ping naik berapa
# Terminal 1: ping continuous
ping -i 0.2 8.8.8.8
# Terminal 2: download file besar
curl -o /dev/null https://speed.cloudflare.com/__down?bytes=100000000
# Lihat ping naik di Terminal 1 — kalau naik >100ms = bufferbloat# Mitigasi bufferbloat di Mikrotik — pakai CAKE/FQ-CODEL queue
/queue type add name=cake-cake kind=cake \
cake-bandwidth=80M cake-rtt=30ms
# Apply ke interface WAN
/queue tree add name=wan-cake parent=ether1-wan \
queue=cake-cake max-limit=80M
# Atau pakai built-in PCQ + FQ
/queue type add name=pcq-down kind=pcq \
pcq-rate=0 pcq-classifier=dst-address pcq-total-limit=200018. Performance Benchmarking — End-to-End
# Cloudflare speed test — multiple destinations
curl -o /dev/null -w "\nDOWN: %{speed_download}\n" \
https://speed.cloudflare.com/__down?bytes=100000000
# Concurrent connection test (load test)
ab -n 1000 -c 50 https://www.google.com/
wrk -t12 -c400 -d30s https://www.google.com/
# DNS load test
for i in {1..100}; do
dig @1.1.1.1 google.com +stats | grep "Query time" &
done | tee dns-bench.log
# iperf3 advanced — parallel streams + window size
iperf3 -c iperf.he.net -P 8 -t 30 -w 4M19. Decision Matrix — Kapan Pakai Tool Apa
ping, speedtest, ipconfig /flushdns, hard refresh browser, cek user lain di lokasi sama. 80% kasus selesai di tier ini.
flush DNS gateway, dig query time, traceroute, cek conntrack, MTU test ladder. 15% kasus selesai di tier ini.
tcpdump/sniffer, ss/netstat retransmit analysis, NIC stats, BGP path comparison, looking glass cross-check. 4% kasus.
Bukti packet capture lengkap, statistik retransmit historis, traceroute dengan AS path, kontak NOC ISP/vendor dengan tiket terdokumentasi. 1% kasus, biasanya physical/peering issue.
Preventif — Supaya Tidak Terulang
Set scheduler di router gateway untuk flush DNS cache tiap 1-2 jam otomatis. Mencegah stale cache menumpuk. Lihat config Mikrotik di section sebelumnya.
Hindari DNS ISP yang sering lambat atau cache busuk. Set DNS upstream ke 1.1.1.1 (Cloudflare) dan 8.8.8.8 (Google) sebagai backup. Lihat DNS Terbaik Indonesia 2026.
Jangan biarkan TTL cache router default (kadang berhari-hari). Set cache-max-ttl=1h di Mikrotik supaya record refresh maksimal 1 jam — balance antara performa dan freshness.
Setup uptime monitor (UptimeRobot, StatusCake) yang test resolve domain populer setiap 5 menit. Alert kalau resolve time >500ms — early warning sebelum user merasakan.
Tulis runbook 1 halaman: "Tiket internet lemot di departemen X — flush DNS cache gateway dulu". Operator IT bisa langsung apply tanpa nunggu admin senior.
Sosialisasi ke user bahwa kalau "lemot tapi VPN lancar" — itu signal khusus yang harus disebutkan di tiket. Mempercepat triage hingga 10x.
Selasa pagi pukul 08:30 WIB. Tiket pertama masuk ke helpdesk: "Internet di lab riset lemot, browser stuck di Looking up." Operator mencatat. 09:00 — tiket kedua dari peneliti yang sama: "Saya coba pakai aplikasi VPN pribadi, langsung lancar. Tolong cek." 09:15 — admin jaringan login ke router gateway cluster bermasalah (Mikrotik RouterOS, melayani empat VLAN: staf-10, lantai1-101, lantai2-108, dan WiFi-109).
09:20-10:30 — Hipotesis #1: IP publik kotor. Hari sebelumnya cluster ini sempat ganti IP publik karena yang lama listed di Spamhaus. Admin curiga IP baru dapat dari pool yang sama. Cek di Spamhaus, Talos, AbuseIPDB — IP baru bersih. Eliminate.
10:30-11:00 — Hipotesis #2: MTU blackhole. User VPN bypass = sering MTU issue. Test
ping -D -s 1472 8.8.8.8 dari laptop di VLAN bermasalah — paket 1500 lewat tanpa drop, jitter normal. Eliminate.11:00-11:30 — Hipotesis #3: Peering ISP. Traceroute dari router ke 8.8.8.8, ke detik.com, ke beberapa CDN. Latency 24-34ms, hop tengah ada loss tapi destination 0% loss (cuma ICMP rate-limit cosmetic). Egress sehat. Eliminate.
11:35 — Tim mulai frustasi. Conntrack di Mikrotik dicek — masih jauh dari limit. Memory router lega. Apa lagi? Senior admin yang lewat ruangan iseng nyeletuk: "Coba flush DNS cache dulu deh."
11:36 — Command yang menyelesaikan masalah:
/ip dns cache flush11:36:05 — Reload halaman dari laptop test. Page load 1.2 detik. Reload Google. 0.8 detik. Buka tiket pelapor pertama, minta dia coba lagi: lancar. Tiket kedua: lancar. Semua user di empat VLAN: lancar.
Total waktu: 2 jam diagnosis, 5 detik fix. Postmortem hari berikutnya menghasilkan dua keputusan: (1) tambahkan scheduler auto-flush DNS cache tiap 2 jam di semua router gateway, (2) tulis runbook 1 halaman: "Pattern speedtest OK + VPN bypass lancar = flush DNS gateway DULU sebelum diagnosa lain." Sebulan kemudian, tiket dengan pattern serupa di departemen berbeda diselesaikan operator helpdesk dalam 3 menit tanpa eskalasi.
FAQ — Pertanyaan yang Sering Ditanyakan
Kesimpulan
Pattern "speedtest lancar + ping OK + VPN bypass auto cepat + browsing lemot" hampir selalu mengarah ke DNS cache router yang busuk — bukan ISP, bukan WiFi, bukan bandwidth. Sebelum diagnosis panjang yang menghabiskan waktu, lakukan flush DNS cache di gateway/router DULU. 5 detik command bisa selesaikan masalah yang dikira problem ISP. Cek My Connection Info untuk lihat DNS server aktif Anda saat ini.