Verified client result
Industry: Small & Mid-sized Business
Rebuilding an Inherited Four-Link Office Network
- MikroTik RouterOS
- Firewall filter rules
- PCC load balancing
- PCQ queue trees
- Policy routing
- DHCP
- RouterOS scripting
Delivery duration: August–September 2026 (documented work period)
Overview
An office of about 75 devices depended on a firewall and four internet links that were set up before this work began. We rebuilt the parts that were not doing their job. The clearest example was a workstation lockdown that had blocked nothing: none of its twelve rules had matched a single packet.
The Challenge
The network looked properly configured, but important parts of it were not doing their job. A workstation that was supposed to reach only approved websites was never actually held to that restriction. Internet traffic was meant to be shared across the lines, yet one link carried 51 Mbps while two sat near idle. And any change to how traffic was shared had to keep logins to banks and tax portals working.
The Solution
The firewall's own counters showed why the lockdown failed: every rule above a blanket LAN-to-WAN accept had live traffic, and all twelve lockdown rules below it read exactly zero. We rebuilt the lockdown as two rules above that accept, scoped to the WAN interface list so internal access still worked, and moved the device policy above a DHCP classifier that would have put the machine back on a bypass whitelist the next time it connected. Balancing was a two-bucket PCC hash on source address that permanently bound each device to one of two links and left the third out entirely. We replaced it with five buckets weighted by measured capacity and hashed on both addresses, with the LTE line on standby, and pinned session-sensitive destinations such as banks to one line so logins survive. We redesigned the per-device PCQ bandwidth tiers and removed a plaintext administrator password from a router script that the configuration export had been copying into every backup on network storage. One fault was our own: our nightly speed-test script hung instead of finishing, four copies stacked up over four days, and the router CPU was pinned at 100% while staff reported internet that was connected but dead. We killed them, made the scheduler clear leftovers before each run, and added an hourly watchdog that stops and reports any job still running from a previous day.
The Results
Measured at the time of the work, before and after the changes: router CPU under load fell from 100% to about 50% as soon as the stuck jobs were killed; throughput went from 51 Mbps on one link to 112+ Mbps across three; devices escaping bandwidth shaping went from 41 to 0; and the automated router backup, broken for weeks, was restored to a verified nightly run. We also reported a risk we did not fix, because fixing it requires hardware changes: both storage volumes on the server host were RAID 0, so losing a single drive would destroy a volume.
Measurement & evidence
Readings taken from the equipment itself during the work: firewall rule packet counters, the router's CPU profiler and running-job list, per-link traffic and connection counts, and before-and-after checks of bandwidth-shaping coverage and of the automated router backup. The link capacities used to weight load balancing were measured line by line rather than taken from provider ratings. All figures describe the network at the time of the work (August–September 2026), not its current state. They are our own engineering measurements, not a formal audit, compliance certification or penetration test.