Failover yang gagal jarang mengeluarkan pesan error. Router tetap tenang, lampu modem tetap hijau, dan trafik tetap dikirim ke jalur yang sudah mati. Karena itu keterampilan yang paling berguna setelah berhasil memasang failover adalah **mendiagnosisnya ketika ia tidak bekerja**.
Artikel ini adalah sisi praktikum-diagnosa dari `Mikrotik : Failover Koneksi dengan Netwatch dan Recursive Route`. Di sini lab kita sengaja dirusak beberapa kali, supaya kamu tahu gejala, penyebab, dan perintah pemeriksanya.
🎯 Tujuan
Setelah menyelesaikan lab ini, kamu diharapkan bisa:
- Menyusun bukti kondisi sehat (baseline) sebelum jalur sengaja dirusak.
- Membaca flag rute `A` dan `I` serta kolom `immediate-gw` pada hasil `print`.
- Membedakan masalah **rute tidak aktif**, **probe salah baca**, dan **trafik tetap salah jalur**.
- Menemukan enam penyebab kegagalan failover yang paling sering terjadi di lapangan.
- Mengukur sendiri waktu failover dan failback di lab sekolahmu.
📍 Konteks nyata
Bayangkan rem darurat pada kendaraan yang tidak pernah diuji. Lampunya menyala, pedalnya bisa ditekan, dan di atas kertas sistemnya "ada". Masalahnya baru ketahuan saat dipakai dalam keadaan darurat — dan saat itu sudah terlambat.
Failover bekerja dengan pola yang sama. Rute recursive dan Netwatch bisa tampak rapi di Winbox, tetapi kalau belum pernah diuji dengan gangguan buatan, kita tidak tahu apakah ia benar-benar memindahkan trafik atau hanya diam.
🔥 Kasus nyata: Sebuah koperasi sekolah memakai dua jalur internet dan memasang rute recursive dengan satu host pantau `8.8.8.8`. Pengujian awal dengan mencabut kabel LAN jalur utama berhasil — trafik pindah ke jalur cadangan. Masalahnya, di jalur utama pihak penyedia ternyata memblokir ICMP ke alamat itu, sehingga router selalu menganggap jalur utama mati walau internetnya normal. Seluruh trafik menumpuk di modem cadangan berbasis kuota, dan kuota habis di tengah jam ujian. Setelah dipasang dua host pantau serta probe `tcp-conn` ke port 443, jalur utama kembali dipakai dan biaya kuota kembali normal.
🧠 Konsep singkat
Diagnosa failover dikerjakan **berlapis dari bawah**, jangan menebak dari atas.
- **Lapis 1 — rute.** Apakah rute default recursive benar-benar aktif dan punya gateway nyata (`immediate-gw`)? Kalau lapis ini gagal, tidak ada yang perlu diperiksa di atasnya.
- **Lapis 2 — probe.** Apakah host pantau memang bisa dijangkau dari router, dan apakah hasil bacanya masuk akal? Probe yang salah baca akan memindahkan jalur sehat, atau sebaliknya diam saat jalur mati.
- **Lapis 3 — trafik.** Kalau rute sudah pindah tetapi client tetap tidak bisa internet, masalahnya bukan di routing, melainkan di NAT, mangle, atau routing rule yang masih memaksa jalur lama.
- **Lapis 4 — pengawasan.** Netwatch memberi tahu kapan jalur berpindah. Kalau script notifikasinya tidak jalan, operasional tetap buta walau failover-nya sehat.
📊 Angka penting: pemeriksaan gateway pada rute (`check-gateway`) berjalan tiap 10 detik dengan timeout 1 detik; setelah dua kali gagal gateway dianggap tidak terjangkau. Netwatch tipe `icmp` default mengirim `packet-count=10` dengan `packet-interval=50ms`, ambang gagal `thr-loss-percent=85%` dan `thr-max=1s`, sedangkan `interval` 10 detik, `timeout` 3 detik, `start-delay` 3 detik, dan `startup-delay` 5 menit.
💡 Tips: selalu catat hasil `print` sebelum dan sesudah gangguan buatan. Failover adalah soal *perubahan*, jadi bukti berupa dua potret kondisi jauh lebih kuat daripada ingatan.
🧩 Istilah penting
| Istilah | Arti sederhana |
|---|---|
| Baseline | Potret kondisi normal yang kita pakai sebagai pembanding saat ada gangguan. |
| Flag `A` | Rute aktif dan dipakai untuk meneruskan paket. |
| Flag `I` | Rute tidak aktif: belum terpilih, atau gateway-nya tidak bisa dicari. |
| Immediate gateway | Gateway yang benar-benar dipakai setelah pencarian next-hop selesai. |
| Probe | Cara Netwatch menguji host: `simple`, `icmp`, `tcp-conn`, `http-get`, `https-get`, `dns`. |
| Failover palsu | Jalur sehat dianggap mati sehingga trafik dipindah tanpa alasan nyata. |
| Flapping | Jalur bolak-balik berpindah karena ambang deteksi terlalu ketat atau `distance` terlalu berdekatan. |
| `thr-loss-percent` | Ambang persentase paket hilang yang membuat probe dianggap gagal. |
| `since` | Waktu perubahan status terakhir pada kolom status Netwatch. |
🔧 Praktik: Memburu Penyebab Failover yang Tidak Jalan
Asumsi lab: ether1 menuju ISP1 (`10.111.0.1`), ether2 menuju ISP2 (`10.112.0.1`), LAN di `bridge-LAN` (`192.168.88.1/24`).
Supaya bisa diuji di lab tanpa internet sungguhan, host pantau dipalsukan di router simulasi ISP memakai rentang dokumentasi: `192.0.2.10` untuk jalur 1 dan `198.51.100.10` untuk jalur 2. Rentang `192.0.2.0/24`, `198.51.100.0/24`, dan `203.0.113.0/24` memang disediakan khusus untuk contoh, jadi aman dipakai di lab.
🔹 Persiapan lab
- Pasang alamat LAN dan kedua uplink di router yang diuji.
- Aktifkan NAT masquerade ke kedua interface uplink.
- Buat rute host pantau bertanda `scope=10`, lalu rute default recursive bertanda `target-scope=11`.
- Setelah lapis routing sehat, baru pasang Netwatch untuk notifikasi.
/ip/firewall/nat
add chain=srcnat action=masquerade out-interface=ether1 comment="NAT ISP1"
add chain=srcnat action=masquerade out-interface=ether2 comment="NAT ISP2"
/ip/route
add dst-address=192.0.2.10/32 scope=10 gateway=10.111.0.1 comment="probe ISP1"
add dst-address=198.51.100.10/32 scope=10 gateway=10.112.0.1 comment="probe ISP2"
/ip/route
add distance=1 gateway=192.0.2.10 target-scope=11 check-gateway=ping comment="default ISP1"
add distance=2 gateway=198.51.100.10 target-scope=11 check-gateway=ping comment="default ISP2"
Di router simulasi ISP, pasang alamat gateway plus dua alamat host pantau di kedua interface-nya:
/ip/address
add address=10.111.0.1/24 interface=ether1
add address=192.0.2.10/32 interface=ether1 comment="palsu: host pantau ISP1"
add address=10.112.0.1/24 interface=ether2
add address=198.51.100.10/32 interface=ether2 comment="palsu: host pantau ISP2"
🔹 Langkah 1: baseline, kumpulkan bukti kondisi sehat
Sebelum merusak apa pun, catat dulu keadaan normalnya. Ini yang nanti kita bandingkan.
/ip route print detail where active
/routing nexthop print detail
/ip route check 192.0.2.10
/tool netwatch print detail
Yang harus terlihat: rute default `distance=1` bertanda `AS` (aktif + static) dengan `immediate-gw=10.111.0.1`, dan daftar nexthop memuat baris untuk kedua jalur. Kalau salah satu rute default tidak muncul sebagai aktif, jangan lanjut dulu — perbaiki di langkah 3.
🔹 Langkah 2: uji A, buktikan `check-gateway` buta ke modem
Matikan host pantau di jalur 1 sementara alamat gateway `10.111.0.1` tetap hidup. Ini meniru kondisi "modem menyala, internet di baliknya mati".
# di router simulasi ISP
/ip address disable [find address="192.0.2.10/32"]
# di router yang diuji
/ip route print where !active
/log print where topics~"route"
Hasil yang benar: rute default jalur 1 berubah menjadi tidak aktif dan rute `distance=2` mengambil alih. Kalau kamu ingin melihat kontrasnya, buat rute pembanding yang menunjuk langsung ke modem dengan `check-gateway=ping` — rute itu tetap aktif walau host di balik modem sudah tidak terjangkau. Itulah titik buta yang membuat recursive route dipakai.
⚠️ Hati-hati: pada percobaan ini alamat gateway tetap bisa di-ping, jadi jangan berhenti di "ping gateway masih jalan berarti aman". Ping yang sukses ke modem tidak membuktikan internet di baliknya bisa dipakai.
🔹 Langkah 3: uji B, sengaja salah `target-scope`
Ini kesalahan penulisan yang paling sering terjadi. Samakan `target-scope` dengan `scope` rute host, lalu lihat akibatnya.
/ip route set [find comment="default ISP1"] target-scope=10
/ip route print where !active
/ip route print detail where comment~"default ISP1"
Rute default jalur 1 tidak akan pernah aktif karena tidak ada rute host yang boleh dipakai untuk mencari next-hop. Perbaikannya: rute host tetap `scope=10`, rute default memakai `target-scope=11` (harus lebih besar dari scope rute yang dipakai mencari gateway).
/ip route set [find comment="default ISP1"] target-scope=11
/ip route print detail where active
🧪 Uji cepat: kalau `/routing nexthop print detail` menampilkan status pencarian yang gagal atau tidak menemukan gateway, curigai `scope` dan `target-scope` sebelum mencurigai kabel atau ISP.
🔹 Langkah 4: uji C, probe diblok sehingga failover palsu
Tiru kebijakan penyedia yang memblokir ICMP ke host pantau. Buat aturan tolak ICMP menuju `192.0.2.10` di router simulasi, lalu amati rute jalur 1.
# di router simulasi ISP
/ip firewall filter
add chain=input protocol=icmp dst-address=192.0.2.10 action=drop comment="UJI: blokir ICMP"
# di router yang diuji
/tool netwatch print detail
Gejalanya: jalur 1 pindah ke jalur 2 walau internet sebenarnya sehat — failover palsu. Perbaikannya dua arah: tambah host pantau kedua per jalur supaya rute menjadi ECMP, dan atau ganti tipe probe agar tidak bergantung pada ICMP.
/tool/netwatch
set [find name=net-isp1] type=tcp-conn port=443
📊 Angka penting: satu host pantau berarti satu titik gagal. Dua host per jalur membuat jalur baru dinyatakan mati hanya kalau **semua** host di jalur itu tidak terjangkau.
🔹 Langkah 5: uji D, script Netwatch tidak jalan karena policy
Netwatch menjalankan script sebagai user `*sys` dengan batas policy `read,write,test,reboot`. Script yang meminta policy lebih luas tidak akan dieksekusi sama sekali.
/system script
add name=uji-policy policy=read,write,test,reboot,ftp source=":log info \"UJI: script jalan\""
/system script print detail where name="uji-policy"
Jalankan script itu dari Netwatch, lalu cari jejaknya di log. Kalau tidak ada baris log sama sekali, periksa kembali daftar policy script-nya dan sederhanakan sampai tidak melebihi `read,write,test,reboot`.
/log print where topics~"script"
🔹 Langkah 6: uji E, peringatan palsu saat router menyala
Hapus `ignore-initial-up` dan `ignore-initial-down` dari satu probe, reboot router, lalu lihat log. Status awal `Unknown` bisa dianggap perubahan status sehingga notifikasi berbunyi padahal belum ada gangguan apa pun.
/tool/netwatch
set [find name=net-isp1] ignore-initial-up=yes ignore-initial-down=yes
/tool netwatch print detail
🔹 Langkah 7: uji F, jalur bolak-balik karena ambang terlalu ketat
Buat kedua rute default punya `distance` yang sama tanpa alasan, lalu perketat `timeout` probe sampai lebih kecil dari waktu jawab jaringan. Amati kolom `since` dan log: jalur akan berpindah bolak-balik dalam waktu singkat.
/tool/netwatch
set [find name=net-isp1] interval=10s timeout=1s
/tool netwatch print detail
/log print where message~"NETWATCH"
Perbaikan: jalur utama harus punya `distance` lebih kecil, ambang probe disesuaikan dengan kualitas jaringan nyata, dan jangan menaruh dua rute dengan `distance` sama kecuali memang ingin ECMP.
💡 Tips: `since` pada status Netwatch adalah alat diagnosa paling cepat. Kalau `since` baru berubah beberapa detik lalu, berarti jalur baru saja berpindah — cocokkan dengan jam kejadian yang dilaporkan pengguna.
🔹 Langkah 8: uji G, rute sudah pindah tetapi client tetap mati
Bila rute aktif dan `immediate-gw` benar, tetapi client masih tidak bisa internet, masalahnya ada di luar routing. Periksa berurutan: NAT kedua uplink, routing rule, dan mangle yang menandai jalur.
/ip firewall nat print stats
/routing rule print
/ip firewall mangle print stats
/ip route check 192.0.2.10
Penyebab yang paling sering: NAT masquerade hanya dibuat untuk satu interface, ada `routing rule` yang memaksa tabel tertentu, atau ada mangle `mark-routing` yang masih mengarah ke jalur lama. Perbaiki dengan menambah NAT pada interface kedua dan mengecualikan lalu lintas uji dari aturan pemaksa tersebut.
🔹 Langkah 9: uji H, ukur failover dan failback
Ukur waktunya, jangan hanya merasa "sudah pindah". Nyalakan ping berjalan dari client LAN, matikan host pantau jalur 1, dan catat berapa detik paket hilang. Setelah itu hidupkan kembali dan catat waktu kembali ke jalur utama.
# dari client LAN
ping 192.0.2.10 -t
# di router, pantau perubahan rute dan status probe
/ip route print where active
/tool netwatch print detail
🔹 Langkah 10: bersih-bersih lab
Selalu kembalikan lab ke keadaan bersih supaya uji berikutnya tidak terkontaminasi.
/ip firewall filter remove [find comment~"UJI"]
/ip firewall nat remove [find comment~"UJI"]
/system script remove [find name~"uji-"]
/ip route remove [find comment~"default ISP1"]
/ip route remove [find comment~"default ISP2"]
/ip route remove [find comment~"probe ISP1"]
/ip route remove [find comment~"probe ISP2"]
🔹 Versi Winbox
- **IP → Routes**: klik dua kali rute default, lihat tab **Status** untuk membaca flag dan gateway yang benar-benar dipakai.
- **Tools → Netwatch**: buka tab **Status** untuk melihat `status`, `since`, dan statistik probe tanpa menunggu log.
- **Log**: aktifkan topik `script` dan `route` sementara saat melakukan uji, lalu matikan lagi setelah selesai.
- **Terminal** tetap paling cepat untuk uji massal: simpan perintah diagnosa favoritmu jadi script kecil.
🏭 Dipakai di dunia kerja
- **Sekolah:** lab ujian berbasis komputer hanya punya satu kesempatan jalan. Kalau failover ternyata salah baca probe, ujian 30 siswa tersendat dan guru tidak bisa input nilai. Uji gangguan berkala mencegah kejutan di hari-H.
- **Kantor:** absensi online dan rapat video butuh jalur yang benar-benar berpindah. Tim IT memakai hasil pengukuran waktu failover sebagai bukti saat rapat evaluasi dengan manajemen.
- **Warnet dan ISP kecil:** kuota jalur cadangan itu mahal. Failover palsu yang terus menumpuk trafik di modem kuota bisa menghabiskan biaya bulanan dalam hitungan hari.
- **Retail, klinik, dan koperasi:** mesin EDC, kasir, dan sistem antrean harus tetap jalan. Operator butuh satu perintah cepat untuk memastikan jalur mana yang sedang dipakai saat pelanggan mengeluh.
- **Industri dan gedung bertingkat:** jalur monitoring mesin dan CCTV dituntut hidup terus. Catatan log Netwatch menjadi bukti kapan gangguan terjadi dan berapa lama, untuk keperluan SLA.
✅ Verifikasi
Jalankan berurutan setelah lab selesai dirapikan.
- Pastikan rute recursive aktif dan punya immediate gateway.
/ip route print detail where active
/routing nexthop print detail
/ip route check 192.0.2.10
- Pastikan tidak ada rute uji yang tertinggal tidak aktif.
/ip route print where !active
- Pastikan probe Netwatch melaporkan status yang benar dan script-nya tercatat di log.
/tool netwatch print detail
/log print where topics~"script"
- Uji ulang satu kali: matikan host pantau jalur utama, hitung detik sampai trafik pindah, lalu hidupkan kembali dan hitung waktu failback.
🧪 Uji cepat: jalankan `ping 192.0.2.10 -t` dari client, matikan host pantau, dan hitung berapa paket yang hilang. Sekitar 10–30 detik hilang masih wajar untuk `check-gateway` standar; kalau hilang terus, mulai lagi dari lapis 1.
⚠️ Kesalahan umum & troubleshooting
| Gejala | Perintah pemeriksa | Penyebab dan perbaikan |
|---|---|---|
| Rute default recursive tidak pernah aktif | `/ip route print where !active` | `target-scope` tidak lebih besar dari `scope` rute host; kembalikan ke `scope=10` dan `target-scope=11` |
| Rute aktif tetapi gateway kosong | `/routing nexthop print detail` | Alamat host pantau belum punya rute sendiri; tambahkan rute host bertanda `scope=10` |
| Failover tidak pindah padahal internet mati | `/ip route print detail where active` | Jalur hanya diawasi ke modem; ganti ke rute recursive menuju host publik |
| Jalur pindah padahal internet normal | `/tool netwatch print detail` | Host pantau memblokir ICMP atau sedang gangguan; pakai dua host per jalur atau probe `tcp-conn` |
| Jalur bolak-balik pindah | `/log print where message~"NETWATCH"` | `distance` jalur utama tidak lebih kecil, atau ambang probe terlalu ketat |
| Notifikasi palsu saat router baru menyala | `/log print` | Status awal `Unknown` dianggap perubahan; set `ignore-initial-up=yes` dan `ignore-initial-down=yes` |
| Script Netwatch tidak berjalan | `/system script print detail` | Policy script melebihi `read,write,test,reboot`; sederhanakan script dan policy-nya |
| Rute sudah pindah tetapi client tetap tidak bisa internet | `/ip firewall nat print stats` | NAT masquerade belum ada di interface uplink kedua |
| Trafik tetap melewati jalur lama | `/routing rule print` dan `/ip firewall mangle print stats` | Ada routing rule atau mangle `mark-routing` yang memaksa tabel tertentu |
🔐 Catatan keamanan & etika
- Netwatch menjalankan script sebagai `*sys` dengan batas policy `read,write,test,reboot`. Jangan mematikan pemeriksaan policy script demi kemudahan, karena itu melemahkan keamanan router secara keseluruhan.
- Jangan menaruh password, token, atau alamat internal sensitif di dalam script dan pesan log. Log router bisa dibaca oleh user lain di router yang sama.
- Saat menguji gangguan buatan, lakukan hanya pada jam lab atau jendela pemeliharaan. Mencabut jalur produksi di jam kerja berisiko mengganggu ujian, absensi, atau transaksi.
- Pemantauan jalur dan trafik menyangkut data operasional. Gunakan untuk keperluan teknis, bukan untuk mengintip aktivitas orang lain.
📌 Kesimpulan
Failover yang sehat bukan yang tampak hijau di Winbox, melainkan yang pernah diuji gagal dan terbukti pindah. Diagnosanya selalu berlapis: rute dulu, lalu probe, lalu trafik, terakhir pengawasan.
Langkah berikutnya: ulangi lab ini setiap kali kamu menambah jalur baru atau mengganti perangkat uplink, dan simpan hasil pengukuran waktunya sebagai baseline tim IT sekolahmu.
🔗 Materi terkait
- `Mikrotik : Failover Koneksi dengan Netwatch dan Recursive Route` — konsep yang diuji di artikel ini.
- `Mikrotik : Praktikum Failover Otomatis dengan Netwatch dan Recursive Route` — lab pemasangan langkah demi langkah, sebelum masuk ke sisi diagnosa.
- `Mikrotik : Praktikum Uji Route Selection dan Failover di Tabel Routing v7` — dasar `distance`, `check-gateway`, dan ECMP.
- `Mikrotik : Tabel Routing dan Manajemen Rute di RouterOS v7` — membaca RIB, FIB, dan kolom `fib`.
- `Mikrotik : Policy Routing (Memilih Jalur Internet Tertentu)` — penyebab trafik tetap melewati jalur tertentu.
- `Mikrotik : Praktikum Cek Firewall Filter dengan Counter dan Log` — membaca counter saat memeriksa NAT dan filter.
- `Mikrotik : Monitoring Dasar dengan Torch Traffic Log dan Resource` — melihat trafik saat gangguan terjadi.
📚 Referensi
- MikroTik RouterOS Documentation — Failover (WAN Backup): https://help.mikrotik.com/docs/spaces/ROS/pages/26476608/Failover+WAN+Backup
- MikroTik RouterOS Documentation — Netwatch: https://help.mikrotik.com/docs/spaces/ROS/pages/8323208/Netwatch
- MikroTik RouterOS Documentation — IP Routing: https://help.mikrotik.com/docs/spaces/ROS/pages/328084/IP+Routing
- MikroTik RouterOS Manual — Netwatch: https://manual.mikrotik.com/docs/diagnostics-monitoring-and-troubleshooting/netwatch/
- IETF RFC 5737 — IPv4 Address Blocks Reserved for Documentation: https://datatracker.ietf.org/doc/html/rfc5737