Lagi monitor queue tree di MikroTik, terus lihat kolom "dropped" angkanya naik terus — ratusan, ribuan, puluhan ribu paket dibuang? User mulai komplain internet lemot meskipun bandwidth utama masih lega? Tenang, ini masalah konfigurasi, bukan kerusakan router atau ISP.
Drop di queue tree itu by-design behavior MikroTik — paket yang exceed limit memang dibuang. Tapi kalau drop count terus naik tajam, ada 4 penyebab paling sering: max-limit terlalu ketat tanpa burst allowance, queue type yang salah pilih (FIFO vs PCQ), buffer queue-size yang kekecilan, atau CPU MikroTik yang sudah overload. Tiap penyebab punya fix yang spesifik.
Artikel ini bahas pattern drop di setup PPPoE cluster Indonesia — dari RT/RW Net 50 user sampai WISP 500+ subscriber. Step-by-step CLI command langsung executable, plus cara verify sebelum dan sesudah tweak. Kita pakai contoh real config (anonimized) supaya kamu tidak hanya paham teori, tapi tahu persis command apa yang harus dijalankan.
Apa Itu "Drop" di Queue Tree MikroTik?
Queue tree adalah mekanisme MikroTik untuk shaping bandwidth — bukan untuk forward paket, tapi untuk mengatur berapa cepat paket boleh keluar/masuk. Saat traffic dari user melebihi batas yang sudah di-set, MikroTik punya 2 pilihan: antri (queue) sampai bandwidth tersedia, atau buang (drop) kalau buffer antrian penuh.
Bayangkan queue tree seperti antrian kasir di supermarket. Kalau kasir cepat (bandwidth besar) dan antrian pendek (buffer cukup), semua pelanggan dilayani. Tapi kalau kasir lambat (bandwidth terbatas) dan antrian sudah penuh sampai pintu masuk, pelanggan baru disuruh keluar — itu yang disebut "drop". Beda dengan paket yang sukses lewat tapi kena delay, drop = paket hilang permanen.
/queue tree print statsAngka di kolom dropped-packets dan dropped-bytes = jumlah paket yang dibuang sejak counter terakhir di-reset.
Drop ≠ packet loss di internet. Drop terjadi di router kamu sendiri, sebelum paket sempat keluar ke ISP. Sedangkan packet loss internet terjadi di jalur transit (ISP backbone, peering, atau destination). Cara test bedanya: lakukan ping test langsung dari MikroTik ke server lokal (router gateway). Kalau loss di sini, masalah di MikroTik (queue/CPU). Kalau loss baru muncul saat ping ke server eksternal, masalah di luar router.
Cek Dulu: Berapa Banyak Drop di Router Kamu?
Sebelum tweak apa-apa, baseline dulu. Tanpa baseline kamu tidak akan tahu apakah tweak berhasil atau makin buruk. Reset counter dulu supaya angkanya fresh:
/queue tree reset-counters-allStep 2 — Tunggu 5-10 menit di jam ramai (peak hour, biasanya 19.00-22.00 WIB di Indonesia).
Step 3 — Print stats:
/queue tree print statsAtau filter cuma queue dengan drop > 0:
/queue tree print where dropped-packets>0| Drop Ratio | Interpretasi | Tindakan |
|---|---|---|
| < 0.1% | Excellent — config queue optimal | Tidak perlu tweak ✅ |
| 0.1% – 1% | Normal untuk jaringan oversubscribe | Monitor saja, baseline acceptable |
| 1% – 5% | Mulai mengganggu user (browsing lambat, video stutter) | Audit queue config (artikel ini) ⚠️ |
| 5% – 15% | Performance issue serius, banyak user complain | Wajib tweak burst/PCQ + cek CPU 🔴 |
| > 15% | Crisis — kemungkinan multiple issue compound | Audit holistic: routing, NAT, hardware ❌ |
Cara hitung drop ratio: bagi dropped-packets ÷ packets × 100%. Contoh: dropped 1,500 packets, total packets 50,000 → ratio = 3%. Di range 1-5% — audit queue config.
Root Cause #1: Max-Limit Tanpa Burst-Limit (50% Kasus)
Ini penyebab paling sering — terutama di setup admin MikroTik yang baru beralih dari simple queue ke queue tree. Config-nya kelihatan benar (max-limit sesuai paket user), tapi drop tetap tinggi. Kenapa?
Traffic internet itu bursty by nature — bukan flat. Buka YouTube? Burst 20 Mbps untuk 2 detik (buffer video), lalu turun ke 2 Mbps (stream rate). Buka website? Burst 10 Mbps untuk 0.5 detik (download asset), lalu nol (idle baca). Kalau max-limit kamu set 6M strict tanpa burst allowance, paket burst di awal langsung di-cap dan sisanya drop.
/queue tree add name=ppoe-user01 parent=global \
max-limit=6M packet-mark=ppoe-user01-markTidak ada burst-limit + burst-threshold + burst-time = paket burst langsung dibuang.
| Parameter | Fungsi | Nilai Rekomendasi (User 6 Mbps) |
|---|---|---|
| max-limit | Bandwidth maksimum saat traffic sustained | 6M (sesuai paket user) |
| burst-limit | Bandwidth maksimum saat burst (short spike) | 8M – 10M (1.5x max-limit) |
| burst-threshold | Threshold di mana burst mulai aktif | 4M (60-70% max-limit) |
| burst-time | Durasi maksimum burst diizinkan | 10s (cukup untuk YouTube buffer) |
/queue tree set [find name=ppoe-user01] \
max-limit=6M \
burst-limit=8M \
burst-threshold=4M \
burst-time=10sEffect: traffic boleh burst sampai 8 Mbps selama 10 detik, lalu turun ke 6 Mbps kalau sustained. YouTube buffer di awal lewat, drop berkurang signifikan.
Bulk update untuk semua queue user: kalau queue tree kamu punya 100+ entry per user, jangan edit satu-satu. Pakai script untuk apply burst config ke semua queue yang max-limit-nya sama:
:foreach q in=[/queue tree find max-limit=6M] do={ \
/queue tree set $q burst-limit=8M burst-threshold=4M burst-time=10s \
}Test di 1-2 queue dulu sebelum bulk apply, supaya kalau salah bisa rollback cepat.
Root Cause #2: Queue Type Salah Pilih (FIFO vs PCQ)
MikroTik default pakai queue type FIFO (First-In-First-Out) atau pfifo. Artinya: paket diproses urut datang. Sederhana, tapi tidak fair share. Kalau 1 user dari 50 lagi torrent berat, dia bisa "menguasai" queue, dan 49 user lain harus nunggu — termasuk paket pertama mereka di-drop karena buffer penuh.
Solusi: pakai PCQ (Per Connection Queue). PCQ otomatis bagi bandwidth secara fair berdasarkan koneksi (per IP source/destination, atau per address). User torrent tetap dapat bagian, user lain juga dapat bagian — proportional.
| Queue Type | Cara Kerja | Cocok Untuk | Drop Behavior |
|---|---|---|---|
| pfifo / default-small | First-in-first-out | Single user, single connection | Burst tinggi → drop banyak |
| red | Random early detection | Server enterprise | Drop random sebelum buffer penuh |
| sfq | Stochastic fair queueing | Network mix tanpa kontrol per-user | Drop fair antar koneksi |
| pcq ✅ | Per-connection queue (fair share) | PPPoE cluster, hotspot, WISP | Drop terdistribusi adil per user |
| wireless-default | Optimized untuk wireless | Interface wireless saja | Tidak cocok untuk PPPoE |
/queue type printBuat queue type PCQ baru:
/queue type add name=pcq-download-cekipsaya \
kind=pcq \
pcq-classifier=dst-address \
pcq-rate=6M/queue type add name=pcq-upload-cekipsaya \
kind=pcq \
pcq-classifier=src-address \
pcq-rate=6MApply ke queue tree:
/queue tree set [find name=ppoe-user01] queue=pcq-download-cekipsayaBehavior beda yang akan kamu liat: dengan PCQ, satu user heavy torrent tidak akan menggangu user lain. Bandwidth dibagi adil berdasarkan jumlah koneksi aktif. Total drop biasanya turun 40-60% setelah migrate dari pfifo ke PCQ.
Root Cause #3: Buffer Queue Size Terlalu Kecil
Default queue size MikroTik = 50 packets. Artinya kalau ada lebih dari 50 paket antri di queue, paket ke-51 langsung di-drop tanpa kesempatan menunggu. Untuk traffic modern (HTTP/2 multiplexing, video streaming, app real-time), 50 packets sering tidak cukup.
/queue type printLiat kolom pfifo-limit atau pcq-limit — itu jumlah maksimum paket di buffer.
Naikkan queue size:
/queue type set pfifo-default pfifo-limit=200Atau untuk PCQ custom:
/queue type set pcq-download-cekipsaya pcq-limit=200 pcq-total-limit=2000| Queue Size | Behavior | Cocok Untuk |
|---|---|---|
| 50 (default) | Strict — burst >50 packets langsung drop | Setup lama, low concurrent user |
| 100 | Moderate tolerance | RT/RW Net 20-50 user |
| 200 | Good tolerance untuk video streaming + browsing | PPPoE cluster 50-200 user ✅ |
| 500 | High tolerance, butuh RAM lebih | WISP 200+ subscriber |
| >1000 | Risk bufferbloat (latency naik karena over-buffer) | Hindari kecuali ada reason spesifik ⚠️ |
Root Cause #4: CPU/Memory MikroTik Overload
Queue tree itu CPU-intensive. Untuk shaping 1000+ koneksi simultan dengan PCQ + burst-limit + connection tracking, butuh CPU yang sanggup. Kalau hardware kamu RB750 (CPU 400 MHz, RAM 32 MB) dan dipakai untuk 100+ PPPoE user, sudah dijamin CPU saturated.
/system resource monitor(tekan Ctrl+C untuk stop monitor)
Atau snapshot sekali:
/system resource printThreshold worry:
- CPU sustained > 80% = mendekati limit hardware
- Free memory < 10% = swap thrashing
- CPU 100% bersamaan dengan queue drop = hardware bottleneck
| Hardware | CPU | RAM | Realistic Concurrent User Limit |
|---|---|---|---|
| hAP Lite (RB941) | 650 MHz (1 core) | 32 MB | ~20 user PPPoE basic |
| hAP ac² | 716 MHz (4 core) | 128 MB | ~50 user PPPoE + queue |
| RB750Gr3 / hEX | 880 MHz (2 core) | 256 MB | ~100 user PPPoE + queue + NAT |
| RB4011 | 1.4 GHz (4 core) | 1 GB | ~300-500 user PPPoE cluster ✅ |
| CCR1009 / CCR2004 | 1+ GHz (8-16 core) | 1-4 GB | 500-1000+ user (production grade) |
Kalau CPU sudah di atas 80% sustained, tweak queue config tidak akan banyak membantu — root cause-nya hardware. Pilihan: upgrade router, atau offload sebagian fungsi (misal pindah PPPoE server ke router terpisah, queue tree di router lain).
Special Case: Drop Muncul Setelah Restore Backup
Pola yang kami temui beberapa kali: admin MikroTik restore backup dari beberapa bulan lalu, tiba-tiba queue drop melonjak meskipun traffic terlihat normal. Ini bisa terjadi karena traffic profile sudah berubah sejak backup dibuat.
Contoh: backup dibuat saat user 50 orang dengan traffic mostly browsing (low bandwidth, low concurrent). Setelah 6 bulan, user jadi 80 orang dan banyak yang nonton YouTube/Netflix (high bandwidth, high concurrent). Config queue di backup masih pakai parameter lama yang sudah tidak cocok dengan beban traffic saat ini.
1. Bandingkan jumlah PPPoE active sekarang vs saat backup
2. Cek total bandwidth ISP saat ini vs saat backup
3. Re-evaluate burst-limit + queue-size berdasarkan beban traffic sekarang
4. Monitor 24 jam pertama setelah restore — kalau drop tinggi, sesuaikan parameter
Plus catatan multi-WAN: kalau setup kamu pakai multi-WAN (misal WAN utama + LTE backup) dan salah satu WAN tidak berfungsi, traffic akan menumpuk di WAN sehat. Queue jadi crowded → drop. Sebelum tuning queue, pastikan semua WAN routing sehat. Lihat threshold normal MTR untuk diagnostik jalur jaringan.
Verifikasi: Sudah Tidak Drop Banyak Lagi?
Setelah tweak config (burst-limit, ganti PCQ, naikkan queue-size, atau tambah hardware), baseline lagi. Reset counter, tunggu peak hour, ukur drop ratio baru. Kalau turun dari 5% ke <1%, congratulation — fix berhasil. Kalau masih tinggi, kemungkinan multi-cause (perlu apply >1 fix).
1. Reset counter:
/queue tree reset-counters-all2. Monitor selama 1 jam peak (19.00-20.00 WIB):
/queue tree print stats interval=30s3. Snapshot final stats setelah 1 jam:
/queue tree print where dropped-packets>04. Hitung drop ratio total. Target: <1% untuk PPPoE production.
Untuk monitoring jangka panjang, integrate dengan Grafana atau Smokeping (kalau pakai server monitoring eksternal). Snapshot drop count tiap jam, bikin trending chart — kalau drop ratio mulai naik perlahan dalam minggu/bulan, itu signal kapasitas planning: harus upgrade bandwidth ISP, atau hardware MikroTik.
FAQ — Pertanyaan yang Sering Ditanyakan
Kesimpulan
Drop paket di queue tree MikroTik bukan kerusakan jaringan — itu by-design behavior yang menandakan traffic melebihi alokasi bandwidth. Tapi kalau drop count makin tinggi atau user mulai komplain "internet lemot tiba-tiba", waktunya audit queue config. Empat root cause paling sering: max-limit tanpa burst-limit (paket burst langsung dibuang), queue type FIFO yang tidak fair share, buffer queue-size terlalu kecil, dan CPU MikroTik yang overload. Setiap penyebab punya solusi spesifik — burst-limit untuk traffic spike, PCQ untuk fairness antar-user, queue-size lebih besar untuk burst tolerance, atau upgrade hardware kalau CPU >80%. Pakai tools network cekipsaya untuk verify hasil setelah tweak. Drop tidak akan pernah 100% nol kalau bandwidth oversold — yang penting drop ratio terhadap total traffic tetap di bawah 1%.