Mengatasi Dropped Packets di MikroTik Akibat CPU Load Tinggi: 5 Langkah Diagnostik Lapangan

Lonjakan trafik saat jam sibuk sering kali menjadi ujian sesungguhnya bagi network engineer dan operator ISP lokal. Ketika latensi melonjak drastis, pelanggan mulai melapor bahwa koneksi putus-putus, dan pengecekan menunjukkan angka packet loss yang tinggi, tersangka utamanya biasanya adalah RouterOS yang kewalahan. CPU load menembus angka 90% hingga 100%.

Kenapa CPU load tinggi langsung memicu dropped packets? Artikel ini membahas tuntas penyebab utamanya serta 5 langkah diagnostik lapangan untuk mengatasinya tanpa harus buru-buru upgrade hardware.

---

Pendahuluan: Kenapa CPU Load Tinggi Menyebabkan Dropped Packets?

Secara arsitektur, RouterOS menangani paket data melalui dua jalur utama: fast path (hardware/software acceleration yang langsung meneruskan paket tanpa membebani CPU) dan jalur reguler yang memproses antrean (queue), firewall filter, NAT, dan connection tracking di tingkat CPU (software processing).

Ketika router dibebani aturan firewall yang terlalu rumit, jumlah koneksi aktif yang membludak, atau proses background yang memakan resource, CPU router akan kehabisan siklus pemrosesan. Akibatnya, paket data baru yang masuk ke antrean buffer (interface queue) tidak sempat diproses tepat waktu dan akhirnya dibuang (dropped packets). Dampaknya langsung terasa: lonjakan latensi (bufferbloat), VoIP patah-patah, hingga koneksi pelanggan terputus.

---

Langkah 1: Identifikasi Proses Penyebab di /system resource cpu & /tool profile

Jangan menebak-nebak penyebab lonjakan CPU. RouterOS menyediakan alat diagnostik bawaan yang sangat akurat untuk melihat fungsi mana yang paling memakan resource.

1. Cek Utilitas Keseluruhan

Gunakan perintah berikut di terminal untuk melihat penggunaan per core:

/system resource cpu print

Jika router Anda multi-core (seperti RB4011 atau CCR series), perhatikan apakah beban hanya menumpuk di satu core tertentu (biasanya Core 0 menangani interrupt management) sementara core lainnya santai. Ketimpangan ini sering menandakan proses single-threaded seperti queue sederhana atau rule mangle tertentu yang tidak terdistribusi merata.

2. Jalankan Tool Profile

Untuk mengetahui fungsi kernel yang melahap siklus CPU, jalankan perintah:

/tool profile

Perhatikan kolom usage terbesar. Apakah didominasi oleh firewall, networking, queues, bridging, atau profiling? Jika firewall mendominasi, Anda perlu memeriksa kembali aturan filter dan NAT Anda. Jika queues yang tinggi, batasan Simple Queues yang terlalu kompleks pada ribuan pelanggan mungkin menjadi akar masalahnya.

---

Langkah 2: Mengatasi Connection Tracking yang Meluber

Bagi pengelola RT/RW Net atau ISP skala kecil dengan banyak pelanggan NAT (Network Address Translation), tabel connection tracking sering kali menjadi bom waktu.

Setiap sesi koneksi (web browsing, streaming, game) dicatat dalam tabel RAM router. Ketika limit connections terlampaui atau timeout terlalu lama, router kehabisan memori dan siklus CPU habis hanya untuk mengelola tabel tersebut.

Cara Cek dan Optimasi Connection Tracking:

1. Cek jumlah koneksi aktif saat ini:

   /ip firewall connection print count-only
   

2. Jika jumlahnya mendekati atau melebihi batas maksimal perangkat, sesuaikan timeout atau aktifkan loose TCP tracking. Masuk ke menu:

   /ip firewall connection tracking set enabled=yes tcp-established-timeout=1d
   

3. Pastikan untuk mengecualikan trafik besar (seperti trafik CDN lokal atau backup besar) agar tidak masuk ke connection tracking jika memang tidak diperlukan, menggunakan rule notrack pada Raw table.

---

Langkah 3: Optimasi Rule Firewall & Filter yang Terlalu Berat

Aturan firewall yang disusun tanpa urutan efisien akan memaksa CPU memeriksa setiap paket melewati puluhan rule satu per satu.

1. Hindari Layer7 Protocol Berlebihan

Penggunaan layer7-protocol atau regex yang kompleks pada Firewall Filter untuk mendeteksi aplikasi tertentu sangat membebani CPU karena melakukan deep packet inspection (DPI) secara software. Batasi penggunaan L7 hanya pada kebutuhan mendesak.

2. Manfaatkan FastTrack

Pastikan rule FastTrack aktif untuk trafik yang sudah terotentikasi (established dan related). Ini membuat paket langsung melompati pemrosesan firewall reguler. Cek rule default Anda:

/ip firewall filter print

Pastikan rule FastTrack berada di urutan teratas setelah rule established/related. Anda juga bisa membaca panduan terkait di artikel kami mengenai PPPoE Sering Disconnect di MikroTik? Ini 6 Penyebab Utama & Cara Mengatasinya.

---

Langkah 4: Cek Proses Torch, Scan, atau Log yang Berjalan

Penyebab sepele namun sering terjadi di lapangan adalah tool diagnostik yang lupa dimatikan oleh teknisi setelah troubleshooting selesai.

1. Matikan Tool yang Boros Resource

Tool seperti /tool torch, /interface wireless sniffer, atau /interface wireless scan menyedot resource CPU secara masif karena merekam dan memproses seluruh frame data secara real-time. Selalu pastikan Anda menutup jendela torch setelah selesai mengamat-amati trafik pelanggan.

2. Batasi Logging ke Disk

Jika Anda mengatur /system logging dengan action=disk secara berlebihan (misalnya mencatat seluruh trafik packet drop ke media penyimpanan internal router), proses tulis I/O akan memicu lonjakan system load. Alihkan log penting ke server remote Syslog eksternal atau batasi memori buffer (memory).

---

Langkah 5: Evaluasi Queues dan Manajemen Bandwidth

Penerapan Simple Queues satu per satu untuk ribuan pelanggan pada RouterOS v6 ke bawah dapat membebani CPU secara signifikan karena sifatnya yang berurutan.

1. Migrasi ke Tree Queues

Untuk jaringan dengan kapasitas besar, gunakan Queue Tree yang dikombinasikan dengan PCQ (Per Connection Queue). Metode ini jauh lebih efisien dalam hal penggunaan siklus CPU dibanding membuat ribuan Simple Queues.

2. Periksa Penggunaan Interface Queues

Pastikan jenis antrean pada interface fisik (ether1, sfp-sfpplus1, dll.) disesuaikan dengan kapasitas bandwidth riil. Anda bisa membaca panduan konfigurasi lanjutan seputar manajemen jaringan dan troubleshooting melalui rubrik Troubleshooting kami.

---

FAQ (Pertanyaan yang Sering Diajukan)

1. Apakah CPU 100% selalu merusak router secara permanen? Tidak merusak fisik secara langsung, namun memicu packet loss parah, lonjakan latensi, dan ketidakstabilan koneksi bagi seluruh pelanggan yang melewati router tersebut.

2. Bagaimana cara mengaktifkan kembali FastTrack jika terhapus? Anda bisa menambahkannya lewat terminal dengan perintah: /ip firewall filter add chain=forward action=fasttrack-connection connection-state=established,related comment="defconf: fasttrack" pastikan diletakkan di urutan atas.

3. Apakah fitur Torch aman dibiarkan menyala terus di production? Sangat tidak aman. Torch dirancang murni untuk debugging sementara. Membiarkannya menyala di interface utama dapat membuat CPU router tersendat hingga 100%.

4. Berapa batas normal CPU Load MikroTik saat jam sibuk? Idealnya di bawah 70–80%. Jika CPU secara konsisten berada di atas 90% selama jam sibuk (pukul 19.00–22.00), itu tanda mutlak perlunya optimasi rule atau peningkatan kapasitas perangkat.

5. Kenapa connection tracking sering penuh pada RT/RW Net? Karena jumlah perangkat client di balik NAT router (HP, laptop, Smart TV) sangat banyak dan menghasilkan ratusan ribu sesi koneksi serentak yang melebihi alokasi memori default.

---

Kesimpulan

Lonjakan CPU load dan dropped packets di MikroTik bukan vonis mati yang harus diselesaikan dengan langsung membeli router baru yang mahal. Dengan melakukan diagnostik terstruktur menggunakan /tool profile, mengoptimalkan connection tracking, merapikan urutan rule firewall, serta menghindari tool diagnostik yang menyala terus, performa router dapat kembali stabil. Selalu pastikan jaringan Anda terpelihara dengan baik agar pelanggan tetap nyaman.

Butuh panduan teknis jaringan lainnya? Simak artikel mendalam kami yang lain seperti WiFi Nyala Tapi Internet Mati? Cek 5 Hal Berurutan.

---

built for better network.
Follow @netkarta untuk tips lapangan dan troubleshooting jaringan rutin lainnya.