Dua WAN sudah masuk, PCC sudah dipasang mengikuti panduan, lalu speedtest dijalankan — angkanya tetap 10 Mbps. Kesimpulan yang langsung muncul: PCC-nya gagal.
Padahal itu justru tanda PCC-nya jalan.
PCC nggak menggabungkan bandwidth
Ini yang harus diluruskan sebelum apa pun. PCC membagi koneksi, bukan memecah satu koneksi jadi dua jalur.
Satu download besar dari satu server adalah satu koneksi. Dia keluar lewat satu WAN, dan cuma dapat kecepatan WAN itu. Dua WAN 10 Mbps nggak akan pernah bikin satu file turun di 20 Mbps.
Yang Anda dapat: dua puluh orang yang browsing bareng akan tersebar ke dua WAN, jadi total lalu lintas yang tertampung memang naik. Buat RT/RW Net atau kantor, itu persis yang dibutuhkan. Buat satu orang yang lagi menguji speedtest, itu nggak kelihatan sama sekali.
Kenapa harus per koneksi, bukan per paket
Sekilas membagi per paket kelihatan lebih adil dan lebih rata. Tapi paket dari satu koneksi yang sama akan keluar dari dua IP publik yang berbeda, bergantian.
Dari sisi server tujuan, itu terlihat seperti dua orang berbeda yang memakai satu sesi. Akibatnya nyata dan bikin repot: HTTPS putus di tengah, internet banking logout sendiri, dan sebagian situs langsung menolak.
PCC menghindari itu dengan cara yang sederhana — dia menghitung sidik dari alamat dan port, membaginya, lalu menandai koneksinya. Selama koneksi itu hidup, dia tetap di WAN yang sama.
Classifier menentukan hasilnya, dan sering dipilih asal
Bagian yang ditulis sebagai per-connection-classifier=both-addresses:2/0 itu punya arti, dan pilihannya berdampak:
| Classifier | Yang terjadi |
|---|---|
src-address | satu pelanggan menempel di satu WAN terus |
both-addresses | pembagian per pasangan pengirim dan tujuan |
both-addresses-and-ports | pembagian paling merata |
Kalau memakai src-address, pembagiannya jadi timpang begitu ada satu pelanggan yang jauh lebih rakus daripada yang lain — dia menyeret seluruh WAN-nya sendiri. Untuk jaringan pelanggan, both-addresses-and-ports biasanya yang paling rata.
Angka 2/0 dan 2/1 artinya: bagi jadi dua, ambil sisa bagi nol untuk yang pertama dan satu untuk yang kedua. Kalau WAN-nya tiga, jadi 3/0, 3/1, 3/2 — dan semua angka pembaginya harus ikut diganti. Menambah WAN ketiga tanpa mengubah pembagi adalah kesalahan yang sering terjadi, dan gejalanya WAN ketiga nggak pernah kebagian apa-apa.
Generator PCC Load Balance MikroTik nyusun seluruh rangkaian mangle-nya beserta NAT dan route-nya, dengan pembagi yang ikut menyesuaikan jumlah WAN.
Urutan aturannya yang menentukan, bukan isinya
Rangkaian PCC selalu tiga lapis, dan urutannya nggak boleh tertukar:
- Tandai koneksinya di chain prerouting, berdasarkan hasil pembagian PCC.
- Tandai routing-nya dari koneksi yang sudah bertanda tadi.
- Buat route untuk tiap routing mark ke gateway masing-masing.
Yang paling sering salah di langkah kedua: routing mark dibuat langsung dari PCC, bukan dari connection mark. Bedanya baru terasa nanti — paket balasan dan paket lanjutan koneksi yang sama bisa nyasar ke WAN yang lain.
Perhatikan juga passthrough. Aturan penanda koneksi butuh passthrough=yes supaya paketnya lanjut ke aturan berikutnya; aturan penanda routing sebaiknya passthrough=no supaya berhenti di situ.
FastTrack membunuh PCC tanpa suara
Kalau ada aturan FastTrack di firewall — dan di konfigurasi bawaan RouterOS memang ada — sebagian besar paket akan melompati seluruh mangle. PCC-nya nggak salah, cuma nggak pernah dilewati.
Gejalanya bikin bingung karena setengah jalan: sebagian koneksi terbagi rapi, sebagian lagi ngotot lewat satu WAN. Uraiannya ada di Load balance 2 WAN MikroTik tidak jalan atau berat sebelah, termasuk cara memastikan mangle-nya benar-benar kena.
PCC nggak tahu WAN Anda mati
Ini yang paling sering baru ketahuan pas kejadian. PCC membagi koneksi ke dua gateway tanpa pernah memeriksa apakah gateway itu masih hidup. Kalau satu WAN putus, separuh pelanggan Anda tetap dilempar ke sana — dan mereka mati total sementara yang separuh lagi baik-baik saja.
Failover itu pekerjaan terpisah: recursive route atau Netwatch. Generator WAN Failover MikroTik nyusun bagian itu.
Kalau setelah semua ini pembagiannya masih kadang jalan kadang tidak, kemungkinan besar yang bermasalah bukan PCC melainkan cara routing mark-nya dibaca — dan itu dibahas di Policy route kadang jalan kadang tidak.