Jaringan yang terasa putus-putus tidak selalu berarti ISP bermasalah. Di lapangan, cukup sering penyebabnya justru konfigurasi MikroTik yang sudah lama dipakai, ditambal sana-sini, lalu tidak pernah diaudit lagi. Audit tidak harus rumit. Mulai dari bagian yang paling sering bikin masalah dan cek dampaknya ke trafik nyata.
1. Rapikan rule firewall yang sudah tidak relevan
Buka IP > Firewall, lalu periksa filter rule, NAT, dan mangle. Cari rule duplikat, rule lama untuk layanan yang sudah dimatikan, atau rule yang urutannya tidak masuk akal. Rule firewall dibaca dari atas ke bawah; satu rule accept yang terlalu longgar bisa membuat rule pengaman di bawahnya tidak pernah bekerja.
Contoh sederhana: ada rule drop akses Winbox dari internet, tetapi di atasnya sudah ada accept untuk semua koneksi masuk. Hasilnya, rule drop tersebut hanya terlihat aman di daftar konfigurasi.
Kapan dipakai: setelah beberapa kali perubahan jaringan, pergantian admin, atau saat CPU router naik tanpa pola yang jelas.
2. Cek interface yang tidak terpakai dan beri nama yang jelas
Nama bawaan seperti ether1, ether2, atau wlan1 cepat membingungkan saat perangkat mulai banyak. Ganti menjadi nama yang menjelaskan fungsi, misalnya WAN-Fiber, LAN-Office, atau AP-Lantai2. Interface yang benar-benar tidak digunakan sebaiknya dinonaktifkan.
Ini bukan sekadar urusan rapi. Port kosong yang masih aktif bisa dipakai orang untuk colok perangkat sembarangan. Pada kasus tertentu, loop juga berawal dari port yang dianggap tidak penting.
Kapan dipakai: saat audit dokumentasi, pindah lokasi, atau setelah ada penambahan switch dan access point.
3. Pastikan bridge tidak membawa loop diam-diam
Untuk jaringan dengan beberapa switch, aktifkan RSTP pada bridge dan cek port mana saja yang menjadi bagian bridge. Jangan asal memasukkan port WAN, trunk, dan access port ke bridge yang sama tanpa desain yang jelas.
Contohnya, kabel dari switch lantai satu dan lantai dua sama-sama kembali ke router melalui jalur berbeda. Tanpa proteksi loop, broadcast bisa berputar terus dan jaringan terasa lambat padahal bandwidth internet masih besar.
Kapan dipakai: ketika ping lokal melonjak, CPU switch/router naik, atau jaringan mendadak lumpuh setelah teknisi memindahkan kabel.
4. Audit DHCP: scope, lease, dan DNS yang dibagikan
Cek apakah rentang IP DHCP cukup untuk jumlah perangkat saat ini. Kantor kecil yang awalnya memakai pool 50 alamat bisa cepat penuh ketika tamu, CCTV, printer Wi-Fi, dan perangkat IoT ikut masuk jaringan.
Periksa juga DNS yang diberikan ke klien. Jika router dijadikan DNS cache, pastikan allow-remote-requests tidak terbuka ke internet. Untuk jaringan internal, konfigurasi ini berguna; untuk WAN, itu bisa mengundang penyalahgunaan.
Kapan dipakai: saat pengguna sering mendapat pesan IP conflict, tidak mendapat IP, atau keluhan “internet ada tapi situs tidak kebuka”.
5. Tinjau queue dan pembagian bandwidth berdasarkan kebutuhan sekarang
Simple Queue yang menumpuk sering membuat troubleshooting jadi melelahkan. Cek apakah ada queue lama untuk perangkat yang sudah tidak ada, target yang saling tumpang tindih, atau limit yang terlalu kecil untuk kebutuhan aplikasi saat ini.
Misalnya, staf video call tersendat karena seluruh kantor dibatasi queue global tanpa prioritas. Lebih masuk akal memberi batas yang sehat per divisi atau menerapkan prioritas untuk trafik penting, bukan memotong rata semua pengguna.
Kapan dipakai: saat internet terasa lambat pada jam sibuk, sementara hasil speedtest dari router terlihat normal.
6. Periksa mangle, routing mark, dan FastTrack
Konfigurasi load balancing, policy routing, dan QoS biasanya memakai mangle. Bagian ini perlu dicek pelan-pelan karena satu rule yang salah bisa membuat koneksi perbankan, VPN, atau aplikasi kantor berpindah jalur di tengah sesi.
FastTrack juga perlu disesuaikan. Fitur ini membantu performa, tetapi trafik yang dilewati FastTrack dapat melewati proses queue atau mangle tertentu. Jika QoS atau marking terasa tidak bekerja, FastTrack adalah salah satu titik pertama yang layak diperiksa.
Kapan dipakai: setelah memasang load balancing, VPN, QoS, atau ketika beberapa aplikasi hanya gagal di jaringan tertentu.
7. Validasi DNS, NTP, dan waktu router
Waktu router yang meleset sering dianggap sepele, padahal bisa menyulitkan pembacaan log, validasi sertifikat, sinkronisasi VPN, sampai jadwal backup. Atur NTP client ke server yang tepercaya dan pastikan zona waktu sesuai lokasi operasional.
DNS router juga sebaiknya tidak hanya mengandalkan satu resolver. Gunakan resolver cadangan, lalu uji resolusi nama domain dari terminal. Catatan teknisi: kalau log dan jam perangkat tidak nyambung, mencari akar masalah bisa dua kali lebih lama.
Kapan dipakai: saat log terasa membingungkan, VPN kadang gagal, atau ada masalah akses situs HTTPS tertentu.
8. Cek resource router dan trafik yang tidak wajar
Lihat CPU, RAM, disk, connection tracking, serta daftar trafik aktif di Torch. Jangan langsung menyimpulkan router lemah hanya karena CPU tinggi. Cari proses atau interface yang memicu lonjakan terlebih dahulu.
Contohnya, CPU tinggi hanya muncul saat jam makan siang. Setelah dicek dengan Torch, ternyata ada perangkat yang mengunggah backup besar ke cloud. Solusinya mungkin cukup menjadwalkan backup di luar jam kerja, bukan langsung mengganti perangkat.
Kapan dipakai: ketika router lambat diakses, ping melonjak, atau throughput tidak sesuai kapasitas perangkat.
9. Backup, export konfigurasi, lalu uji perubahan kecil
Sebelum mengubah apa pun, buat backup biner dan export konfigurasi teks. Simpan dengan nama yang mudah dicari, misalnya tanggal dan lokasi perangkat. Backup biner berguna untuk pemulihan cepat, sedangkan export teks memudahkan membandingkan perubahan konfigurasi.
Jangan mengubah banyak hal sekaligus. Ubah satu bagian, uji koneksi penting seperti internet, VPN, DNS, dan akses manajemen, lalu lanjut ke tahap berikutnya. Kebiasaan ini terasa lambat di awal, tetapi jauh lebih cepat saat ada masalah.
Kapan dipakai: setiap kali melakukan audit, upgrade RouterOS, perubahan routing, atau optimasi firewall.
Penutup
Audit MikroTik yang baik bukan soal membuat konfigurasi terlihat kompleks. Targetnya sederhana: jalur trafik jelas, akses manajemen aman, resource tidak terbebani tanpa alasan, dan perubahan bisa dilacak. Jika dilakukan rutin, banyak gangguan kecil bisa tertangkap sebelum berubah menjadi keluhan satu kantor.
