Prioritas dan Batasan: Mengelola Lalu Lintas Internet per VLAN

Prioritas dan Batasan: Mengelola Lalu Lintas Internet per VLAN

Setelah memahami dasar-dasar konektivitas, kita masuk ke kerja sunyi yang menentukan kenyamanan bersama: bagaimana membagi pipa internet yang terbatas secara adil dan terkendali di antara berbagai divisi atau VLAN, tanpa mengganggu percakapan internal jaringan.

Semua bermula dari keluhan. Itu hukumnya. Jarang sekali manajemen datang dengan senyum, menepuk bahumu, dan berkata, "Hei, bandwidth kita sepertinya didistribusikan dengan prinsip keadilan Rawlsian yang sangat baik." Tidak. Biasanya yang datang adalah surel dari kepala keuangan, yang suaranya lewat tulisan saja sudah terdengar kesal, "Mengapa setiap hari pukul 11 siang video conference dari marketing selalu putus-putus?" Atau tatapan kosong dari tim desain saat Adobe Creative Cloud mereka bilang "offline" untuk kesekian kalinya. Atau—yang paling klasik—staf admin yang bisik-bisik, "Yah, katanya internet perusahaan, kok buka TikTok saja loadingnya satu tahun."

Kamu berdiri di depan whiteboard yang kotor bekas spidol biru dan merah dari meeting sebelumnya. Kamu menggambar kotak. Satu kotak untuk ISP A, yang kamu labeli "Primer 100Mbps". Satu kotak lagi untuk ISP B, "Backup 50Mbps". Lalu kamu gambar sebuah kotak besar: Router MikroTik kamu, entah itu RB4011 atau CCR yang sudah mulai berdebu. Dari situ, kamu tarik garis-garis ke beberapa kotak lain: VLAN 10 (Manajemen & IT), VLAN 20 (Keuangan & HR), VLAN 30 (Marketing), VLAN 40 (Operasional), VLAN 50 (Guest), dan VLAN 99 (Server).

Masalahnya bukan di koneksinya. Semua sudah tersambung. Ping ke 8.8.8.8 cuma 5ms. Masalahnya ada di dalam pipa itu sendiri, saat puluhan atau ratusan orang mulai menarik napas secara bersamaan. Saat itulah muncul yang namanya "noise" atau "lalu lintas sembarangan". Dan di sinilah kerja sunyi itu dimulai: bukan sekadar memberi akses, tapi mengatur lalu lintasnya.

Prinsip pertama yang harus diterima: Internet di kantor bukanlah hak tanpa batas. Ia adalah sumber daya bersama yang terbatas, seperti air di menara air. Kalau satu departemen menyedotnya untuk menyiram halaman digitalnya yang luas, departemen lain akan kehausan. Tugas kita adalah memasang katup dan pengukur aliran di setiap cabang pipa. Di dunia jaringan, katup dan pengukur itu bernama Mangle dan Queue Tree di MikroTik.

Logikanya begini. Kita punya dua ISP. Asumsi awal semua orang: ISP Primer pasti aktif dan jadi tulang punggung. Salah. Di kenyataannya, "primer" itu status di kertas. Di lapangan, routing bisa membelok ke mana saja karena metric, karena latency, karena kebijakan load-balance yang kamu buat setahun lalu dan lupa. Jadi, langkah pertama kerja sunyi adalah: tandai semua lalu lintas yang akan keluar lewat ISP A, dan semua yang lewat ISP B. Ini pakai Mangle.

Kamu buka terminal, atau WinBox, dan mulai mengetik perintah yang bagi orang lain kelihatan seperti mantra alien:

/ip firewall mangle add chain=prerouting action=mark-connection new-connection-mark=conn-ISP1 passthrough=yes in-interface=bridge-local dst-address-type=!local per-connection-classifier=src-address-and-port:2/0

dan

/ip firewall mangle add chain=prerouting action=mark-connection new-connection-mark=conn-ISP2 passthrough=yes in-interface=bridge-local dst-address-type=!local per-connection-classifier=src-address-and-port:2/1

Apa yang kamu lakukan? Kamu sedang "mengklasifikasikan" setiap koneksi baru dari LAN internal ke dalam dua keranjang imajiner: keranjang koneksi ISP1 dan keranjang koneksi ISP2. Algoritma per-connection-classifier itu yang bekerja, membagi berdasarkan kombinasi alamat IP sumber dan port, sehingga beban terdistribusi cukup merata. Ini pondasi. Tanpa ini, semua aturan batasan bandwidth berikutnya bisa salah sasaran, karena tidak tahu suatu paket data mau lewat ISP yang mana.

Berikutnya, dari "koneksi" yang sudah ditandai, kita tandai "paket"-nya. Karena Queue Tree bekerja berdasarkan packet-mark.

/ip firewall mangle add chain=prerouting action=mark-packet new-packet-mark=packet-ISP1 passthrough=no connection-mark=conn-ISP1

/ip firewall mangle add chain=prerouting action=mark-packet new-packet-mark=packet-ISP2 passthrough=no connection-mark=conn-ISP2

Sekarang, setiap paket data yang berasal dari komputer staf marketing, server, atau tamu yang nyambung ke WiFi, sudah punya "cap" tidak terlihat: paket-ISP1 atau paket-ISP2. Mereka siap diatur.

Tapi ingat, ini hanya untuk lalu lintas ke internet (dst-address-type=!local). Lalu lintas internal—dari komputer ke server file, dari printer ke laptop, obrolan di LAN—harus tetap bebas, tanpa cap, tanpa antrian. Mereka adalah percakapan privat di dalam rumah, jangan sampai ikut antrian di gerbang tol. Ini prinsip penting yang sering terlupa: bandwidth management hanya untuk keluar-masuk internet, bukan untuk membelenggu jaringan lokal.

Sekarang kita masuk ke jantung masalah: membagi kuota kecepatan per VLAN. Inilah politik digital sesungguhnya. Berapa porsi yang adil untuk marketing yang butuh YouTube dan sosial media? Berapa untuk keuangan yang cuma butuh akses ke portal bank dan e-faktur? Berapa untuk guest yang sebaiknya jangan serakah?

Kamu buat Queue Tree. Pikirkan ini seperti pohon sungai. Akarnya adalah antarmuka fisik menuju ISP (ether1 untuk ISP1, ether2 untuk ISP2). Dari setiap akar itu, tumbuh cabang-cabang besar bernama "parent queue". Misal, untuk ISP1 100Mbps, kamu buat parent queue global dengan max-limit=100M. Dari parent global ini, kamu cabangkan lagi menjadi parent queue untuk setiap VLAN.

Di sinilah seni bernegosiasi dengan dirimu sendiri terjadi. Misal, kamu putuskan:

• VLAN 30 (Marketing): Dapat 40M dari ISP1, 15M dari ISP2. Mereka butuh banyak.
• VLAN 10 & 20 (Manajemen & Keuangan): Masing-masing 20M dari ISP1, 10M dari ISP2. Cukup untuk yang penting-penting.
• VLAN 40 (Operasional): 15M dari ISP1, 10M dari ISP2.
• VLAN 50 (Guest): 5M dari ISP1 saja. Cukup buat baca berita, jangan streaming.

Konfigurasinya kira-kira seperti ini untuk satu cabang:

/queue tree add name="VLAN30-ISP1" parent=global-ISP1 packet-mark=packet-ISP1 src-address=10.30.0.0/24 limit-at=30M max-limit=40M priority=4

Kamu lihat parameter priority? Itu adalah jurus rahasia lain. Priority 1 adalah tertinggi (paling diutamakan), 8 adalah terendah. Lalu lintas critical seperti VoIP atau video conference bisa kamu beri priority tinggi di dalam batas VLAN-nya, sehingga meski penuh, paketnya tetap dilayani duluan. Tapi hati-hati, memberi priority rendah pada guest itu wajar, tapi memberi priority rendah pada divisi tertentu bisa berarti perang dingin di dunia nyata.

Setelah semua aturan selesai, kamu simpan konfigurasi. Lalu kamu buka grafik Queue Tree. Awalnya, garis-garisnya datar. Lalu, saat jam kerja dimulai, grafik itu mulai hidup seperti musik visual. Garis hijau untuk marketing melonjak tajam pukul 10 pagi—mungkin lagi upload campaign. Garis biru untuk operasional konstan—akses SAP atau ERP. Garis merah untuk guest muncul sesekali, kecil, seperti ikan kecil di antara ikan besar.

Dan kamu duduk di sana, memantau. Ini adalah kerja sunyi yang sesungguhnya. Tidak ada tepuk tangan. Yang ada justru, jika grafik itu datar semua dan tidak ada keluhan, itu artinya kamu berhasil. Kesuksesan di dunia ini sering diukur dari tidak adanya kegaduhan.

Tantangan sebenarnya bukan di teknisnya. Itu bisa dipelajari. Tantangannya ada di asumsi dan ekspektasi. Asumsi bahwa "primer pasti dipakai". Asumsi bahwa "batas 5Mbps itu cukup". Asumsi dari pengguna bahwa internet itu seperti udara, tersedia tanpa batas. Dan ekspektasi bahwa semua ini bisa diselesaikan dalam semalam.

Pelajaran terbesar dari mengatur bandwidth per VLAN ini adalah tentang pengakuan. Mengakui bahwa setiap divisi punya kebutuhan digital yang berbeda. Mengakui bahwa sumber daya itu terbatas. Dan mengakui bahwa keadilan tidak selalu berarti pembagian yang sama rata, tetapi pembagian yang proporsional berdasarkan kebutuhan dan kontribusi terhadap tujuan bersama. Memberi marketing bandwidth besar bukan karena mereka favorit, tapi karena tools mereka memang haus data. Membatasi guest bukan karena pelit, tapi untuk melindungi inti bisnis.

Lalu, bagaimana dengan lalu lintas internal? Itu tetap bebas, tak tersentuh aturan ini. Biarkan percakapan antara server dan workstation, antara printer dan laptop, mengalir lancar di dalam jaringan lokal. Itu adalah wilayah kedaulatan internal. Jangan sampai aturan untuk internet justru mencekik produktivitas di dalam rumah sendiri. Pastikan aturan mangle kamu sudah benar dengan dst-address-type=!local, sehingga paket dengan tujuan IP lokal diabaikan oleh proses marking.

Dan dalam kerja sunyi sistem inilah, keputusan teknis tentang seberapa besar bandwidth untuk siapa, menjadi penjaga keseimbangan antara produktivitas dan disiplin digital di balik layar.

Beberapa Pertanyaan yang Mungkin Muncul (dan Jawaban yang Berdasar Pengalaman)

Q: Kenapa pakai Queue Tree, bukan Simple Queue? Kan lebih mudah?
A: Simple Queue memang mudah untuk skala kecil. Tapi coba bayangkan kamu punya 10 VLAN, masing-masing perlu aturan di 2 ISP. Itu 20 antrian. Lalu di tiap VLAN ada need untuk prioritas internal (misal, VoIP vs download). Simple Queue akan jadi monster yang tak terkelola. Queue Tree dengan marking lebih fleksibel dan powerful untuk skala dan kompleksitas menengah-ke-atas.

Q: Apa risiko salah konfigurasi priority?
A: Bisa fatal tapi tak terlihat. Misal, kamu kasih priority 8 (terendah) untuk VLAN keuangan yang butuh akses real-time ke portal bank. Saat jaringan ramai, transaksi mereka bisa timeout, laporan gagal generate. Tapi error-nya akan dilaporkan sebagai "internet lambat", bukan "priority salah". Debugging-nya seperti mencari jarum dalam tumpukan jerami.

Q: Bagaimana memastikan lalu lintas internal benar-benar tidak kena aturan?
A> Uji dengan transfer file besar antar komputer di VLAN yang sama, sambil pantau grafik Queue Tree untuk VLAN tersebut. Jika grafiknya tetap flat (hanya lalu lintas internet yang terlihat), berarti marking-mu dengan dst-address-type=!local sudah bekerja. Jika naik, ada yang salah di rule mangle-mu.

Q: Apakah ada dampak CPU/RAM Router dengan konfigurasi kompleks begini?
A> Ada. Mangle dan Queue Tree itu bekerja di kernel. Semakin banyak aturan dan semakin tinggi throughput, semakin berat. Router kelas konsumen (RB750) bisa kolaps. Pilih hardware yang sesuai. Monitor resource lewat menu "Resources". Jika CPU sering di atas 70% hanya karena traffic shaping, saatnya upgrade.

Q: Bagaimana menghadapi user yang protes karena "dibatasi"?
A> Jelaskan dengan analogi jalan tol. Semua dapat akses, tapi dengan lajur dan batas kecepatan agar tidak macet total. Siapkan data grafik (yang tadi kamu pantau) untuk menunjukkan bahwa saat divisinya "ngebut", divisi lain terkena dampak. Tekankan bahwa ini untuk kepentingan bersama. Kadang, menunjukkan data adalah bahasa paling efektif.

Q: Berapa frekuensi revisi aturan bandwidth?
A> Tidak ada jadwal tetap. Revisi saat ada perubahan struktur organisasi, penambahan aplikasi cloud baru yang rakus bandwidth, atau saat upgrade paket ISP. Intinya: aturan jaringan adalah living document, bukan batu ukir.

Q: Apa tanda bahwa konfigurasi ini berhasil?
A> Tanda paling jelas: keluhan "internet lambat" yang bersifat general berkurang drastis. Keluhan yang muncul menjadi spesifik: "upload ke YouTube lagi lambat", yang artinya kamu bisa fokus ke aturan untuk VLAN marketing saja. Spesifiknya keluhan adalah indikator bahwa mekanisme pembagianmu bekerja—masalahnya kini terisolasi, bukan meluas.

Priority and Limits: Managing Internet Traffic per VLAN

After grasping the basics of connectivity, we enter the quiet work that determines collective comfort: how to fairly and controllably divide a limited internet pipe among various divisions or VLANs, without disrupting the internal network's conversations.

It always starts with a complaint. That's the rule. It's rare for management to come with a smile, pat your shoulder, and say, "Hey, our bandwidth seems to be distributed with excellent Rawlsian principles of justice." No. Usually, it's an email from the head of finance, whose annoyance is palpable even through text: "Why does the video conference from marketing buffer every day at 11 AM?" Or the blank stare from the design team when their Adobe Creative Cloud says "offline" for the umpteenth time. Or—the most classic—the admin staff whispering, "Well, it's supposed to be company internet, but loading TikTok takes a year."

You stand in front of a whiteboard dirty with blue and red marker remnants from a previous meeting. You draw boxes. One box for ISP A, labeled "Primary 100Mbps". Another box for ISP B, "Backup 50Mbps". Then you draw a big box: Your MikroTik Router, be it an RB4011 or a CCR starting to gather dust. From there, you draw lines to several other boxes: VLAN 10 (Management & IT), VLAN 20 (Finance & HR), VLAN 30 (Marketing), VLAN 40 (Operations), VLAN 50 (Guest), and VLAN 99 (Servers).

The problem isn't connectivity. Everything's connected. Ping to 8.8.8.8 is just 5ms. The problem is inside that pipe, when tens or hundreds of people start breathing simultaneously. That's when "noise" or "reckless traffic" appears. And this is where the quiet work begins: not just providing access, but managing the traffic.

The first principle to accept: Office internet is not an unlimited right. It's a finite shared resource, like water in a water tower. If one department siphons it off to water their vast digital lawn, others will be left thirsty. Our job is to install valves and flow meters on every pipe branch. In the networking world, those valves and meters are called Mangle and Queue Tree in MikroTik.

The logic goes like this. We have two ISPs. Everyone's initial assumption: the Primary ISP is always active and the backbone. Wrong. In reality, "primary" is a status on paper. In the field, routing can go anywhere due to metrics, latency, or load-balance policies you made a year ago and forgot. So, the first step of quiet work is: mark all traffic that will exit via ISP A, and all via ISP B. Use Mangle for this.

You open the terminal, or WinBox, and start typing commands that look like alien incantations to others:

/ip firewall mangle add chain=prerouting action=mark-connection new-connection-mark=conn-ISP1 passthrough=yes in-interface=bridge-local dst-address-type=!local per-connection-classifier=src-address-and-port:2/0

and

/ip firewall mangle add chain=prerouting action=mark-connection new-connection-mark=conn-ISP2 passthrough=yes in-interface=bridge-local dst-address-type=!local per-connection-classifier=src-address-and-port:2/1

What are you doing? You are "classifying" each new connection from the internal LAN into two imaginary baskets: the ISP1 connection basket and the ISP2 connection basket. The per-connection-classifier algorithm does the work, dividing based on source IP address and port combinations, so the load is distributed fairly evenly. This is the foundation. Without this, all subsequent bandwidth limiting rules could miss their target, because they wouldn't know which ISP a data packet intends to use.

Next, from the already "marked" connections, we mark their "packets". Because Queue Tree works based on packet-mark.

/ip firewall mangle add chain=prerouting action=mark-packet new-packet-mark=packet-ISP1 passthrough=no connection-mark=conn-ISP1

/ip firewall mangle add chain=prerouting action=mark-packet new-packet-mark=packet-ISP2 passthrough=no connection-mark=conn-ISP2

Now, every data packet originating from a marketing staff computer, a server, or a guest connected to WiFi, has an invisible "stamp": packet-ISP1 or packet-ISP2. They are ready to be managed.

But remember, this is only for traffic to the internet (dst-address-type=!local). Internal traffic—from computer to file server, from printer to laptop, LAN chats—must remain free, without stamps, without queues. They are private conversations inside the house, they shouldn't queue at the toll gate. This is an important, often forgotten principle: bandwidth management is only for internet traffic, not for shackling the local network.

Now we get to the heart of the matter: dividing speed quotas per VLAN. This is real digital politics. What's a fair share for marketing, which needs YouTube and social media? How much for finance, which only needs access to bank portals and e-invoices? How much for guests, who shouldn't be greedy?

You create a Queue Tree. Think of it like a river tree. The roots are the physical interfaces to the ISPs (ether1 for ISP1, ether2 for ISP2). From each root, large branches called "parent queues" grow. For example, for ISP1 100Mbps, you create a global parent queue with max-limit=100M. From this global parent, you branch out again into parent queues for each VLAN.

This is where the art of negotiating with yourself happens. For instance, you decide:

• VLAN 30 (Marketing): Gets 40M from ISP1, 15M from ISP2. They need a lot.
• VLAN 10 & 20 (Management & Finance): 20M from ISP1, 10M from ISP2 each. Enough for the essentials.
• VLAN 40 (Operations): 15M from ISP1, 10M from ISP2.
• VLAN 50 (Guest): 5M from ISP1 only. Enough to read news, not for streaming.

The configuration for one branch would look something like this:

/queue tree add name="VLAN30-ISP1" parent=global-ISP1 packet-mark=packet-ISP1 src-address=10.30.0.0/24 limit-at=30M max-limit=40M priority=4

See the priority parameter? That's another secret technique. Priority 1 is the highest (most prioritized), 8 is the lowest. Critical traffic like VoIP or video conferencing can be given higher priority within its VLAN's limit, so even when it's full, its packets are served first. But be careful, giving low priority to guests is normal, but giving low priority to certain divisions can mean cold war in the real world.

After all the rules are done, you save the configuration. Then you open the Queue Tree graph. At first, the lines are flat. Then, when work hours begin, the graph comes alive like visual music. The green line for marketing spikes sharply at 10 AM—maybe they're uploading a campaign. The blue line for operations is steady—accessing SAP or ERP. The red line for guests appears occasionally, small, like little fish among big ones.

And you sit there, monitoring. This is the real quiet work. No applause. In fact, if that graph is mostly flat and there are no complaints, that means you've succeeded. Success in this world is often measured by the absence of noise.

The real challenge isn't the technical part. That can be learned. The challenge lies in assumptions and expectations. The assumption that "primary is definitely used." The assumption that "a 5Mbps limit is enough." The users' assumption that the internet is like air, available without limits. And the expectation that all this can be solved overnight.

The biggest lesson from managing bandwidth per VLAN is about acknowledgment. Acknowledging that each division has different digital needs. Acknowledging that resources are limited. And acknowledging that fairness doesn't always mean equal division, but proportional division based on need and contribution to common goals. Giving marketing more bandwidth isn't because they're favorites, but because their tools are data-hungry. Limiting guests isn't stinginess, but protecting the business core.

And what about internal traffic? It remains free, untouched by these rules. Let the conversations between servers and workstations, printers and laptops, flow smoothly within the local network. That is the realm of internal sovereignty. Don't let internet rules end up strangling productivity within your own house. Make sure your mangle rules are correct with dst-address-type=!local, so packets destined for local IPs are ignored by the marking process.

And in this quiet work of the system, the technical decisions about how much bandwidth for whom become the guardians of balance between productivity and digital discipline behind the screen.

Some Questions That Might Arise (and Experience-Based Answers)

Q: Why use Queue Tree, not Simple Queue? It's easier.
A: Simple Queue is indeed easier for small scales. But imagine you have 10 VLANs, each needing rules on 2 ISPs. That's 20 queues. Then within each VLAN, there's a need for internal priority (e.g., VoIP vs download). Simple Queue would become an unmanageable monster. Queue Tree with marking is more flexible and powerful for medium-to-large scales and complexity.

Q: What's the risk of misconfiguring priority?
A: Can be fatal but invisible. For example, if you give priority 8 (lowest) to the finance VLAN that needs real-time access to bank portals. When the network is busy, their transactions could timeout, reports fail to generate. But the error will be reported as "slow internet", not "wrong priority". Debugging it is like finding a needle in a haystack.

Q: How to ensure internal traffic is truly not affected by the rules?
A> Test by transferring a large file between computers on the same VLAN, while monitoring the Queue Tree graph for that VLAN. If the graph remains flat (only internet traffic is visible), your marking with dst-address-type=!local is working. If it spikes, something's wrong with your mangle rule.

Q: Is there a CPU/RAM impact on the Router with complex configurations like this?
A> Yes. Mangle and Queue Tree work in the kernel. The more rules and the higher the throughput, the heavier the load. Consumer-grade routers (RB750) can collapse. Choose appropriate hardware. Monitor resources via the "Resources" menu. If CPU is often above 70% just due to traffic shaping, it's time to upgrade.

Q: How to deal with users who complain about being "limited"?
A> Explain with a toll road analogy. Everyone gets access, but with lanes and speed limits to prevent total gridlock. Have the graph data (the one you monitored) ready to show that when their division "speeds", others are affected. Emphasize that it's for the common good. Sometimes, showing data is the most effective language.

Q: How often to revise bandwidth rules?
A> No fixed schedule. Revise when there are organizational structure changes, additions of new bandwidth-hungry cloud applications, or when upgrading ISP plans. The point is: network rules are a living document, not stone carvings.

Q: What's a sign this configuration is successful?
A> The clearest sign: general complaints of "slow internet" decrease drastically. The complaints that do emerge become specific: "upload to YouTube is slow again", which means you can focus on the rules for the marketing VLAN only. The specificity of complaints is an indicator that your distribution mechanism is working—problems are now isolated, not widespread.