Konfigurasi Mikrotik Load Balancing PCC: Autopsi Jaringan Anti Putus 2026

Suatu siang di tengah presentasi virtual dengan klien VIP, koneksi internet perusahaan Anda tiba tiba membeku. Layar Zoom patah-patah, suara putus-putus. Keringat dingin mulai bercucuran. Anda punya dua layanan Internet Service Provider (ISP) di kantor, satu fiber optik berkecepatan dewa dan satu lagi nirkabel sebagai cadangan. Secara matematis, Anda harusnya kebal dari kiamat jaringan. Namun faktanya, karena router Anda hanya disetting failover bodoh, saat ISP utama batuk, butuh waktu dua menit bagi sistem untuk berpindah ke cadangan. Dua menit yang terasa seperti dua tahun saat klien menatap wajah Anda yang membeku di layar. Ini adalah tragedi klasik B2B: Membayar dua tagihan internet tiap bulan, tapi hanya menikmati satu, sementara yang lainnya jadi pengangguran.

Menggabungkan dua atau lebih sumber internet dengan kecepatan berbeda bukanlah sihir, tapi matematika antrean (queuing) yang presisi. Jika Anda hanya mencolokkan kedua kabel ISP ke Mikrotik tanpa rekayasa routing yang benar, Anda tidak akan mendapatkan kecepatan gabungan. Sebaliknya, yang terjadi adalah bentrokan lalu lintas digital. Paket data dari satu PC akan keluar lewat ISP A, tapi balasannya nyasar masuk lewat ISP B, menyebabkan website perbankan Anda logout sendiri secara misterius karena mendeteksi perubahan IP di tengah transaksi. Konyol, bukan?

Kita akan membedah secara forensik prosedur konfigurasi mikrotik load balancing pcc (Per Connection Classifier). Lupakan metode statis usang. Kita akan menguliti bagaimana membelah trafik bukan berdasarkan paket, melainkan berdasarkan koneksi logis. Kita akan menjinakkan Mangle untuk memisahkan trafik browsing dari streaming, mengatasi sindrom internet banking yang sensitif, hingga meracik Failover otomatis berbasis deteksi ping gateway yang akan menyelamatkan nyawa meeting online Anda dalam hitungan detik.

Standar Kepatuhan Routing Multihoming B2B

Mendistribusikan beban jaringan ke beberapa gateway (Multihoming) menuntut kepatuhan pada protokol manajemen sesi yang ketat agar tidak merusak integritas aplikasi kelas Enterprise.

Berdasarkan dokumentasi teknis MikroTik RouterOS Routing & Policy Routing Guidelines:

• Penggabungan murni (Agregasi Bandwidth) yang menghasilkan kecepatan 1+1=2 secara harfiah pada satu unduhan tunggal (single thread) hanya dimungkinkan melalui protokol Bonding atau LACP, yang mensyaratkan dukungan dari pihak ISP.
• Untuk skenario tanpa campur tangan ISP (Multi-WAN standar), metode Per Connection Classifier (PCC) adalah standar industri. PCC mendistribusikan beban dengan mengingat (hashing) atribut koneksi (seperti Src-Address dan Dst-Address), memastikan satu sesi komunikasi penuh selalu melewati jalur ISP yang konsisten sejak awal hingga akhir.
• Skema Load Balancing wajib disandingkan dengan mekanisme Failover / Route Tracking. Router harus secara aktif mengirimkan paket ICMP (Ping) ke DNS global (misal 8.8.8.8) untuk memvalidasi ketersediaan jalur, bukan hanya mengecek status fisik antarmuka kabel.

Bagi Network Engineer Anda, pemahaman mendalam tentang algoritma PCC ini adalah syarat absolut sebelum Anda berani menjanjikan ketersediaan layanan (SLA) 99.9% ke manajemen, sama kritisnya dengan urgensi dalam merancang Arsitektur microservices vs monolithic untuk menangani lonjakan beban trafik.

Anatomi PCC: Kenapa 2 ISP Beda Kecepatan Sering Bentrok?

Bayangkan Anda punya ISP A dengan kecepatan 100 Mbps dan ISP B dengan 50 Mbps. Jika Anda menggunakan metode Load Balance “NTH” atau Ecmp yang kuno, router akan membagi paket data secara bergantian: Paket 1 lewat A, Paket 2 lewat B. Masalahnya, ISP A lebih cepat. Paket 1 sudah sampai di tujuan, sementara Paket 2 masih tertatih-tatih di ISP B. Server tujuan akan kebingungan menerima urutan paket yang berantakan (Out of Order Packets). Aplikasi HTTPS yang sangat mengutamakan keamanan (seperti Bank atau cPanel) akan langsung memutus koneksi karena mengira Anda sedang diserang Man-in-the-Middle.

Di sinilah PCC (Per Connection Classifier) menjadi pahlawan. PCC tidak membelah paket, melainkan membelah “Koneksi”.

Jika pengguna X membuka KlikBCA, PCC akan mencatat: “Oke, IP pengguna X dan IP KlikBCA ini akan saya lewatkan melalui ISP A.” Selama pengguna X masih bertransaksi dengan KlikBCA, koneksinya dikunci (Sticky) murni lewat ISP A. Saat pengguna Y membuka YouTube, PCC akan melihat beban ISP A sudah berat, maka koneksi pengguna Y dilempar utuh ke ISP B. Tidak ada bentrok. Kecepatan mungkin tidak menjumlah secara harfiah untuk satu orang, namun secara kumulatif untuk 50 karyawan kantor, total kapasitas (150 Mbps) terpakai semua secara adil.

Script Mangle: Pisau Bedah Pemisah Trafik

Jantung dari PCC berada di fitur Mangle (IP > Firewall > Mangle). Ini adalah ruang bedah di mana Anda menandai (Marking) paket data sebelum merutekannya.

Anda harus membuat dua rantai (Chain) utama: prerouting dan input/output. Kesalahan umum pemula adalah hanya menandai trafik dari LAN ke Internet, tapi lupa menandai trafik yang ditujukan ke Router itu sendiri (misalnya jika Anda mengakses Mikrotik dari rumah via VPN). Akibatnya, routing balasan (reply) menjadi kacau.

Untuk ISP dengan kecepatan asimetris (A=100M, B=50M), Anda tidak bisa membagi rasio 1:1. Anda harus menggunakan parameter per-connection-classifier dengan rasio 2:1. Artinya, dari 3 koneksi baru yang masuk, 2 akan dilempar ke ISP A, dan 1 akan dilempar ke ISP B.

Logika Mangle B2B:

Mark Connection: Beri stempel sementara pada koneksi awal berdasarkan algoritma both-addresses-and-ports (Paling seimbang).

Mark Routing: Berdasarkan stempel koneksi tadi, perintahkan paket untuk mengikuti rute tabel routing spesifik (Route-ISP1 atau Route-ISP2).

Mengatasi Internet Banking Logout Saat Load Balance

Ini adalah komplain paling mematikan dari divisi Keuangan (Finance). “Mas IT, kenapa saya lagi transfer token BCA tiba-tiba ter-logout tulisannya sesi tidak valid?!”

Sistem perbankan memiliki sekuritas tingkat tinggi. Mereka mencatat IP Publik Anda saat pertama kali login. Jika Anda menggunakan hashing PCC both-addresses-and-ports, ada kemungkinan saat browser membuka tab transaksi baru (menggunakan port baru), PCC melempar koneksi itu ke ISP B. Bank melihat IP Publik Anda mendadak berubah dari IP ISP A ke IP ISP B dalam hitungan detik. Algoritma anti-penipuan bank langsung menendang Anda keluar.

Solusi Autopsi: Bikin Bypass Rules (Pengecualian)

Anda harus membuat daftar Alamat (Address List) yang berisi IP dari semua portal perbankan atau aplikasi Enterprise yang sensitif. Di menu Mangle, buat satu rule di urutan paling atas (sebelum masuk ke rule PCC) yang mengatakan: “Jika tujuan (Dst-Address) adalah IP Bank, JANGAN LAKUKAN LOAD BALANCE (Action=Accept), paksa lewat ISP A secara eksklusif.” Dengan penguncian paksa ini, transaksi miliaran rupiah divisi finance Anda akan aman terkendali. Kecerobohan routing ini sekelas berbahayanya dengan kelalaian dalam setting vpn mikrotik untuk wfh yang membiarkan lalu lintas data bocor tanpa enkripsi.

Trik Failover Otomatis (Ping Gateway): Anti Putus Beneran

PCC hanya bertugas membagi beban. Ia tidak peduli apakah ISP di ujung sana hidup atau mati. Jika kabel fiber ISP A putus karena galian backhoe di depan kantor, PCC akan tetap melempar 50% koneksi ke ISP A, mengakibatkan setengah karyawan Anda berteriak internet mati.

Anda wajib mengaktifkan Failover dengan metode check-gateway=ping di menu IP > Routes. Namun, jangan tertipu! Menge-ping alamat gateway bawaan ISP (misal 192.168.1.1 dari modem Indihome) itu bodoh. Jika kabel telkom di luar putus, modem di meja Anda tetap hidup, dan Mikrotik akan menganggap internet ISP A “Masih Normal” karena ping ke modem berhasil.

Gunakan teknik Recursive Routing. Anda harus memerintahkan Mikrotik untuk menge-ping server global (seperti 8.8.8.8) SECARA SPESIFIK melalui rute ISP A. Jika ping ke 8.8.8.8 gagal dua kali berturut-turut, Mikrotik baru akan memvonis ISP A “Mati Total” (Unreachable), dan seketika 100% beban trafik akan dialihkan paksa (Failover) ke ISP B tanpa intervensi tangan manusia. Sistem cerdas ini adalah pelindung reputasi network engineer, selaras dengan pentingnya mekanisme otomatis pada mitigasi serangan ddos aplikasi b2b sebelum infrastruktur luluh lantak.

Sya inget case lucu tapi bikin tensi naik waktu audit jaringan di sebuah coworking space eksklusif di Jakarta Selatan. Mereka punya tiga ISP mahal, tapi membernya tiap hari ngamuk internetnya lemot parah buat main game atau sekadar loading database ringan. Pas sya remote mikrotiknya, sya pengen ketawa. IT sebelumnya bikin Load Balance pake script hasil kopas dari blog antah berantah taun 2012. Dia nyalain fitur Ecmp (Equal Cost Multi-Path) bulet-bulet. Ecmp itu ngebacok paket data bergiliran kaya orang bagi kartu remi. Akibatnya, paket TCP yang nyampe ke server tujuan itu berantakan banget urutannya (out-of-order). Server sibuk minta pengulangan (retransmission) terus-terusan, makanya ping jadi bengkak dan aplikasi freeze. Sya hapus semua rule abal-abal itu, sya tanem PCC murni dengan klasifikasi both-addresses. Dalam 10 menit, grafik trafik tiga ISP itu langsung naik merata kaya barisan tentara, rata banget. Keluhan lag ilang seketika. Di dunia jaringan, copas script tanpa paham filosofi algoritma di baliknya itu ibarat ngasih kunci Ferrari ke anak umur 5 tahun, ujung-ujungnya pasti nabrak tembok.

Pertanyaan Kritis Sekilas Mikrotik B2B (FAQ)

Mengapa beban bandwidth antara dua ISP tidak pernah bisa 50:50 persis meski rasio PCC sudah di set 1:1?

Karena PCC membagi berdasarkan koneksi, bukan berdasarkan byte data. Bayangkan 1 koneksi itu adalah pipa air. PCC mungkin membagi 10 pipa ke ISP A dan 10 pipa ke ISP B. Tapi jika 1 pipa di ISP A ternyata dipakai untuk download file 5 Gigabyte, sementara 10 pipa di ISP B cuma dipakai chatting WhatsApp, maka grafik trafik ISP A akan penuh sesak, sedangkan B kosong. Ketidakseimbangan visual pada grafik adalah hal yang wajar dalam filosofi PCC selama aplikasi tidak ada yang terputus.

Apakah fitur Load Balancing PCC bisa digabung dengan sistem pembatasan kecepatan (Simple Queue)?

Tentu bisa, namun Anda harus sangat berhati-hati dengan urutan rantai paket (Packet Flow). Mangle untuk PCC bekerja di tahap prerouting (sebelum paket masuk lebih jauh), sedangkan Simple Queue biasanya memotong di ujung. Pastikan Anda tidak membuat aturan Mangle (misal untuk prioritas game) yang saling menimpa (overwrite) mark-connection milik PCC. Gunakan fitur passthrough=yes dengan bijak.

Apa solusinya jika aplikasi e-faktur pajak pemerintah selalu gagal upload saat Load Balance aktif?

Sistem aplikasi pemerintah biasanya menggunakan protokol keamanan berbasis sesi yang sangat rentan terhadap perpindahan IP (IP Hopping). Sama seperti penanganan internet banking, Anda WAJIB membuat daftar IP statis (Address List) yang mengarah ke domain atau range IP server e-faktur tersebut. Pasang rule Mangle statis untuk Bypass (Accept) trafik ke daftar IP itu agar hanya dan selamanya keluar melalui ISP Utama (ISP A) saja.