Internet mati tidak selalu berarti kabelnya putus. Kadang modem di meja kita masih menyala dan masih menjawab ping, tetapi jalan di baliknya sudah tidak bisa dilewati. Di kondisi seperti itu, failover biasa yang hanya mengawasi modem akan diam saja — router tetap mengirim semua trafik ke jalur yang sudah mati.
Artikel ini membahas konsep untuk menutup celah itu: **recursive route** supaya router memantau host di internet, dan **Netwatch** sebagai pengawas tambahan yang mencatat kejadian serta bisa menjalankan aksi. Sisi praktikum langkah demi langkah ada di artikel pasangannya, `Mikrotik : Praktikum Failover Otomatis dengan Netwatch dan Recursive Route`.
🎯 Tujuan
Setelah membaca artikel ini, kamu diharapkan bisa:
- Menjelaskan kenapa `check-gateway=ping` ke modem belum cukup untuk failover yang andal.
- Memahami peran `scope`, `target-scope`, dan nexthop lookup pada rute recursive.
- Membedakan tugas **routing** (memindahkan trafik) dan tugas **Netwatch** (mengawasi dan memberi notifikasi).
- Merangkai failover dua uplink bertingkat: gateway lokal, host publik, lalu notifikasi.
- Memilih host pemantau dan nilai threshold dengan alasan yang masuk akal.
📍 Konteks nyata
Bayangkan jalan menuju sekolah. Ada jalan utama dan jalan alternatif. Pos satpam di ujung jalan utama hanya memeriksa apakah gerbangnya masih terpasang, bukan apakah jalan di balik gerbang masih bisa dilewati.
Itulah `check-gateway=ping`: ia hanya bertanya "modem tetangga masih jawab?" Kalau kabel fiber putus di sisi penyedia, modem tetap menyala dan tetap menjawab, jadi router menganggap semuanya sehat dan semua trafik tetap diarahkan ke jalur mati.
Recursive route memindahkan pos pemeriksaan. Router tidak lagi menanyakan modem, tetapi menanyakan host di internet yang jauh di balik jalur itu. Kalau host itu tidak terjangkau, jalur dianggap mati dan rute cadangan yang aktif.
🔥 Kasus nyata: Sebuah warnet 12 PC di dekat SMK memakai dua uplink — fiber dari ISP1 sebagai jalur utama dan modem 4G sebagai cadangan. Suatu sore backbone ISP1 bermasalah, tetapi modem fiber di warnet tetap hidup dan tetap menjawab ping. Karena jalur cadangan hanya diawasi `check-gateway=ping` ke modem, router tidak pernah pindah. Transaksi QRIS kasir gagal dan siswa yang sedang kelas online ikut terputus hampir 30 menit. Setelah rute cadangan dibuat recursive (memantau `8.8.8.8` dan `1.1.1.1`) dan dipasangi Netwatch, gangguan sejenis terdeteksi dalam belasan detik, trafik pindah otomatis, dan operator warnet melihat peringatan di log.
🧠 Konsep singkat
Failover yang rapi itu bertingkat, tidak sekali pasang lalu selesai.
- **Lapis 1 — link lokal.** Router tahu port fisik dan gateway langsungnya hidup atau mati. Murah dan cepat, tapi buta terhadap masalah di sisi penyedia.
- **Lapis 2 — host publik.** Router memantau alamat di internet lewat rute recursive. Ini yang benar-benar membuktikan "internetnya masih bisa dipakai".
- **Lapis 3 — pengawas dan notifikasi.** Netwatch menembak host secara berkala, menulis status ke log, dan bisa menjalankan script sendiri.
- **Rute recursive** adalah rute yang gateway-nya bukan perangkat yang terhubung langsung. Router harus mencari dulu alamat itu lewat rute lain sebelum bisa memakainya.
- **Nexthop lookup** adalah proses pencarian gateway yang benar-benar bisa dijangkau. Hasil akhirnya disebut `immediate-gw`.
- **`scope` dan `target-scope`** membatasi rute mana yang boleh dipakai saat pencarian next-hop. Kalau nilainya salah, rute recursive tidak akan pernah aktif.
- **Netwatch tidak ikut memindahkan paket.** Ia berada di luar jalur forwarding dan bekerja dengan menjalankan script. Kalau routing sudah bisa menyelesaikan masalah, pakai routing; Netwatch untuk pengamatan, notifikasi, atau aksi tambahan.
📊 Angka penting: rute recursive punya `check-gateway=ping` yang memeriksa sekitar tiap 10 detik dengan toleransi 2 kali gagal, jadi failover realistis di kisaran 10 sampai 30 detik. Netwatch default `interval=10s`, `timeout=3s`, `start-delay=3s`, `startup-delay=5m`.
💡 Tips: satu host pemantau per jalur itu rapuh. Pakai dua host per uplink supaya rute default di jalur itu menjadi ECMP — router baru pindah total kalau **semua** host di jalur tersebut tidak terjangkau, bukan karena satu alamat kebetulan sedang menolak ping.
🔹 Kenapa Netwatch bukan pengganti routing
Banyak contoh di internet memakai Netwatch untuk mengaktifkan atau menonaktifkan rute lewat script. Cara itu bisa jalan, tetapi ribet: script harus menangani waktu, status awal, dan risiko salah baca.
Pendekatan yang lebih bersih adalah membiarkan mesin routing sendiri yang memutuskan, memakai rute recursive dengan `check-gateway=ping`. Netwatch ditempatkan sebagai pengawas dan pemberi tanda, bukan sebagai penentu jalur.
🧩 Istilah penting
| Istilah | Arti sederhana |
|---|---|
| Failover | Berpindah otomatis ke jalur cadangan saat jalur utama bermasalah. |
| Failback | Kembalinya trafik ke jalur utama setelah jalur utama sehat lagi. |
| Recursive route | Rute yang gateway-nya tidak terhubung langsung; harus dicari dulu lewat rute lain. |
| `scope` | Seberapa "jauh" sebuah gateway dari router. Nilai lebih kecil berarti makin langsung. |
| `target-scope` | Batas maksimal scope gateway yang boleh dipakai untuk mencari next-hop rute ini. |
| Immediate gateway | Gateway yang benar-benar dipakai mengirim paket setelah pencarian selesai. |
| ECMP | Dua rute dengan tujuan sama yang dianggap setara, lalu dijadikan satu grup. |
| Netwatch | Alat pemantau host dengan probe `simple`, `icmp`, `tcp-conn`, `http-get`, `https-get`, dan `dns`. |
| Probe | Cara Netwatch menguji host: ping, koneksi TCP, permintaan HTTP, atau kueri DNS. |
🔧 Praktik: Merangkai Failover Bertingkat
Bagian ini hanya garis besar rangkaiannya. Langkah lab lengkap, termasuk cara membuktikan titik buta `check-gateway=ping`, ada di artikel praktikum pasangan artikel ini.
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`).
🔹 Langkah 1: pastikan kedua jalur bisa dipakai
- Pasang alamat LAN dan alamat kedua uplink.
- Aktifkan NAT masquerade keluar kepada kedua jalur, supaya client LAN bisa memakai jalur apa pun.
- Uji dulu client bisa ping ke internet lewat masing-masing jalur sebelum menambah routing pintar.
/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"
🔹 Langkah 2: buat rute host sebagai titik pantau
Setiap jalur mendapat rute kecil menuju host pemantau, dan rute itu ditandai `scope=10` supaya dianggap dekat.
/ip/route
add dst-address=8.8.8.8 scope=10 gateway=10.111.0.1 comment="probe ISP1"
add dst-address=8.8.4.4 scope=10 gateway=10.112.0.1 comment="probe ISP2"
🔹 Langkah 3: default route recursive
Rute default tidak lagi menunjuk ke modem, melainkan ke host pemantau. `target-scope=11` artinya router boleh memakai rute host bertanda `scope=10` tadi untuk mencari next-hop.
/ip/route
add distance=1 gateway=8.8.8.8 target-scope=11 check-gateway=ping comment="default via ISP1"
add distance=2 gateway=8.8.4.4 target-scope=11 check-gateway=ping comment="backup via ISP2"
🔹 Langkah 4: tambah host kedua per jalur
Ini meningkatkan keandalan deteksi. Dua rute dengan `distance` sama akan menjadi ECMP, dan jalur baru dinyatakan mati kalau semua host di jalur itu tidak terjangkau.
/ip/route
add dst-address=1.1.1.1 scope=10 gateway=10.111.0.1 comment="probe ISP1 kedua"
add dst-address=208.67.222.222 scope=10 gateway=10.112.0.1 comment="probe ISP2 kedua"
add distance=1 gateway=1.1.1.1 target-scope=11 check-gateway=ping
add distance=2 gateway=208.67.222.222 target-scope=11 check-gateway=ping
🔹 Langkah 5: pasang Netwatch untuk notifikasi
Netwatch tidak mengubah rute di contoh ini. Ia menulis kejadian ke log supaya admin tahu kapan jalur pindah.
/tool/netwatch
add name=net-isp1 host=8.8.8.8 type=icmp interval=10s timeout=1s \
up-script=":log info \"NETWATCH: ISP1 kembali normal\"" \
down-script=":log warning \"NETWATCH: ISP1 tidak terjangkau\"" \
ignore-initial-up=yes ignore-initial-down=yes \
policy=read,write,test,reboot
add name=net-isp2 host=8.8.4.4 type=icmp interval=10s timeout=1s \
up-script=":log info \"NETWATCH: ISP2 kembali normal\"" \
down-script=":log warning \"NETWATCH: ISP2 tidak terjangkau\"" \
ignore-initial-up=yes ignore-initial-down=yes \
policy=read,write,test,reboot
⚠️ Hati-hati: `ignore-initial-up=yes` dan `ignore-initial-down=yes` mencegah script berbunyi saat probe baru ditambahkan atau router baru menyala. Tanpa ini, peringatan palsu sering muncul di log sebelum status probe stabil.
🔹 Versi Winbox
- **IP → Routes**: buat dua rute host menuju alamat pemantau, isi `Scope` = 10.
- Tambahkan dua rute default dengan `Gateway` berupa alamat host tadi, `Target Scope` = 11, `Distance` 1 dan 2, lalu centang **Check Gateway: ping**.
- **Tools → Netwatch**: klik **+**, isi `Host`, pilih `Type: icmp`, isi `Interval`, `Timeout`, lalu tempel script pada `Up` dan `Down`.
- Klik tab **Status** untuk melihat keadaan probe saat ini tanpa menunggu log.
🏭 Dipakai di dunia kerja
- **Sekolah:** lab ujian berbasis komputer memakai dua ISP. Kalau jalur utama bermasalah di sisi penyedia, ujian 30 siswa langsung tersendat dan guru tidak bisa input nilai. Failover recursive menjaga ujian tetap jalan tanpa admin harus turun tangan.
- **Kantor:** absensi online dan rapat video bergantung pada satu jalur. Rute cadangan yang hanya mengawasi modem sering terlambat pindah, sehingga rapat putus-putus padahal "internetnya kelihatan hidup".
- **Warnet dan ISP kecil:** pelanggan membayar untuk koneksi yang stabil. Pindah jalur otomatis dalam belasan detik jauh lebih murah daripada kehilangan pelanggan saat jam ramai.
- **Retail dan klinik:** mesin EDC, kasir, dan aplikasi antrean butuh jalur cadangan yang benar-benar berfungsi, bukan sekadar lampu modem yang menyala.
- **Industri dan gedung bertingkat:** jalur monitoring mesin atau CCTV harus hidup terus. Recursive route plus notifikasi Netwatch memberi tim IT bukti kapan dan berapa lama gangguan terjadi.
✅ Verifikasi
Uji satu per satu, jangan langsung percaya tampilan "hijau".
- Pastikan rute recursive benar-benar aktif dan punya immediate gateway.
/routing route print where active
/routing nexthop print detail
/ip route check 8.8.8.8
- Putuskan jalur utama di lab, lalu ukur berapa detik trafik pindah ke jalur cadangan.
- Hidupkan kembali jalur utama, lalu ukur waktu failback ke jalur utama.
- Pastikan Netwatch melaporkan perubahan status di log.
/tool/netwatch print detail
/log print where message~"NETWATCH"
🧪 Uji cepat: nyalakan `ping 8.8.8.8` dari client LAN sambil kamu mematikan uplink utama. Kalau ping hanya hilang beberapa paket lalu lanjut kembali, failover bekerja. Kalau hilang terus, periksa `scope`, `target-scope`, dan urutan `distance`.
⚠️ Kesalahan umum & troubleshooting
| Gejala | Penyebab umum | Tindakan |
|---|---|---|
| Rute default recursive tidak aktif | `scope` rute host dan `target-scope` rute default tidak nyambung | Pastikan host bertanda `scope=10` dan default bertanda `target-scope=11` |
| Failover tidak jalan walau internet mati | Jalur cadangan hanya memakai `check-gateway=ping` ke modem | Ganti ke rute recursive menuju host publik |
| Jalur pindah padahal internet normal | Host pemantau menolak ICMP atau sedang gangguan | Pakai dua host per jalur, jangan bergantung pada satu alamat |
| Jalur bolak-balik pindah | Kedua rute punya `distance` sama tanpa alasan ECMP yang jelas | Pastikan jalur utama punya `distance` lebih kecil |
| Notifikasi Netwatch berbunyi sendiri saat router menyala | Status awal `Unknown` dianggap perubahan | Gunakan `ignore-initial-up=yes` dan `ignore-initial-down=yes` |
| Script Netwatch tidak berjalan | Policy script melebihi batas `read,write,test,reboot` | Sederhanakan script dan sesuaikan policy |
| Ping dari router berhasil tetapi client tidak bisa internet | NAT atau firewall mengarah hanya ke satu jalur | Periksa NAT masquerade pada kedua interface uplink |
🔐 Catatan keamanan & etika
- Netwatch menjalankan script sebagai user `*sys`, dan policy scriptnya dibatasi `read,write,test,reboot`. Jangan mematikan pemeriksaan policy script kecuali benar-benar terpaksa, karena itu menurunkan keamanan router.
- Jangan menaruh kredensial atau informasi sensitif di dalam script dan pesan log, karena log bisa dibaca user lain pada router.
- Hindari menggantungkan pemantauan pada satu alamat pihak ketiga saja. Kalau layanan itu memblokir ICMP, jalur sehat bisa dianggap mati dan sebaliknya.
- Pemantauan trafik dan status jalur menyangkut data pengguna. Gunakan hanya untuk kebutuhan operasional, bukan untuk mengintip aktivitas orang.
📌 Kesimpulan
Failover yang andal butuh dua hal: router yang melihat lebih jauh dari modem, dan pengawas yang memberi tahu saat jalur berpindah. Rute recursive dengan `scope` dan `target-scope` menyelesaikan bagian pertama, Netwatch menyelesaikan bagian kedua.
Langkah berikutnya: kerjakan lab lengkapnya di `Mikrotik : Praktikum Failover Otomatis dengan Netwatch dan Recursive Route`, lalu ukur sendiri waktu failover dan failback di lab sekolahmu.
🔗 Materi terkait
- `Mikrotik : Praktikum Failover Otomatis dengan Netwatch dan Recursive Route` — praktik langkah demi langkah dari konsep di artikel ini.
- `Mikrotik : Tabel Routing dan Manajemen Rute di RouterOS v7` — dasar RIB dan FIB, `scope`, `target-scope`.
- `Mikrotik : Praktikum Uji Route Selection dan Failover di Tabel Routing v7` — uji `distance`, `check-gateway`, dan ECMP.
- `Mikrotik : Static Route Dasar` — dasar gateway dan next-hop.
- `Mikrotik : Policy Routing (Memilih Jalur Internet Tertentu)` — memilih jalur untuk jenis trafik tertentu.
- `Mikrotik : Monitoring Dasar dengan Torch Traffic Log dan Resource` — membaca log dan trafik saat gangguan terjadi.
- `Mikrotik : Firewall Filter Dasar` — melindungi router, terutama interface WAN.
📚 Referensi
- MikroTik RouterOS Documentation — Netwatch: https://help.mikrotik.com/docs/spaces/ROS/pages/8323208/Netwatch
- MikroTik RouterOS Documentation — Failover (WAN Backup): https://help.mikrotik.com/docs/spaces/ROS/pages/26476608/Failover+WAN+Backup
- MikroTik RouterOS Documentation — IP Routing: https://help.mikrotik.com/docs/spaces/ROS/pages/24805377/IP+Routing
- MikroTik RouterOS Manual — Netwatch: https://manual.mikrotik.com/docs/diagnostics-monitoring-and-troubleshooting/netwatch/