MikroTik as a home router

I'd been thinking about setting up a homelab for a while. I wanted to play with my own projects without relying on cloud providers and to have my own storage space to store backups, as cloud storage prices are getting more expensive.

No homelab is complete without a proper networking setup. Given my experiences of performance and security issues with Internet Service Provider (ISP) routers, I wanted to have better control over the traffic on my home network. I decided to heavily focus traffic on wired connections, offload Wi-Fi, and ensure connections between devices over the local network are as fast as possible.

That's where Mikrotik L009UiGS-RM comes into play. It has enough gigabit Ethernet ports to connect all my Ethernet devices. Power over Ethernet (PoE) is a nice bonus, as I can power my access point without a plug. The router has a small form factor, so I could mount it on the wall.

Know your ISP

Nevertheless, before I touched the router, I needed to find out how my ISP actually hands off the Internet connection. Two things decide your setup, and they are independent of each other:

1. How the Wide Area Network (WAN) authenticates
2. What kind of IPv4 address it gets

Find the answers to those two questions with a quick web search, or call your ISP's support line.

IPoE or PPPoE

In Poland, some providers hand you an address over Dynamic Host Configuration Protocol (DHCP) through an Ethernet cable; this is Internet Protocol over Ethernet (IPoE). Others require a Point-to-Point Protocol over Ethernet (PPPoE) username and password, sometimes using a dedicated virtual local area network (VLAN). The right setup path depends entirely on this detail.

Public or private WAN IPv4

The protocol only tells you how the router logs in.

Separately, check whether the address you receive is public or private. A private IPv4 address on the WAN port always means Carrier-Grade Network Address Translation (CGNAT) - your ISP shares one public IPv4 among many customers and translates it upstream, so nothing routes back to you unsolicited.

For my fibre connection, the ISP uses PPPoE over VLAN 35 with a private IPv4 address. The rest of this post follows that path.

Setting up the MikroTik router

Start by powering on the router. Run an Ethernet cable from your computer to any LAN port on the MikroTik numbered two or higher. Leave port one free for the Optical Network Terminal (ONT) uplink - that becomes your WAN port later.

Open WinBox, switch to the tab, and you should see the router listed at (or its default MAC address). Log in using the user with no password, then change the default admin password immediately, because RouterOS still ships with blank or default credentials on some units.

After that, run through Quick Set just enough to give the router a stable management address and local subnet. You will come back later to replace the default wireless bridge with a cleaner configuration.

Getting Internet

The ONT sits at the edge of your home network. Run an Ethernet cable from the ONT to port one on the MikroTik. Once the link light comes up, the router can see the carrier signal.

Some ISPs (mine included) bind the service to the MAC address of the router they shipped. Plug in a MikroTik with a different MAC, and the connection never authenticates, even when the VLAN and PPPoE settings are correct. The fix is to clone the original router's MAC onto the WAN port. You can read that MAC from the sticker on the ISP router, or from its status page.

Clone it onto . Because the VLAN interface and the PPPoE client both ride on , they inherit this MAC automatically, so the ISP sees the address it expects.

The cloned MAC persists across reboots. If you ever move the connection back to the original router, revert with to restore the port's factory address.

My ISP tags the PPPoE traffic with VLAN 35. RouterOS needs a VLAN interface on top of before it can speak PPPoE. Add it with a descriptive name so future-you does not have to guess what means.

With the VLAN in place, create the PPPoE client. Tell it to use the VLAN interface, accept the default route from the ISP, and use the ISP's DNS servers. Leave the username and password empty at first - you will fill those in once the interface exists.

Now set the credentials your ISP provided. The status should change from to within a few seconds.

Confirm the default route appeared. If the output shows as the gateway, traffic can reach the Internet.

Let's get a clean Wi-Fi setup

For wireless, I use a separate Wireless Access Point (WAP) powered over Ethernet. Port eight on the router feeds both data and power to the Access Point (AP). Enable PoE output on that port, and the WAP boots without a plug.

Managing every AP individually does not scale. RouterOS includes CAPsMAN, which lets the router act as a central controller. You define a single security profile and datapath, plus channel templates for 2.4 GHz and 5 GHz, and the access point downloads that configuration automatically.

On the controller, create the shared objects first.

On the access point, enable CAP mode and point the radios at the manager.

Back on the controller, you should see dynamic radio entries appear. Each radio adopts the configuration that matches its band.

Understanding bufferbloat

During a typical evening on the weekend, I noticed something strange. I was playing Counter-Strike, but then it started lagging due to ping fluctuations. It turned out an iOS update started on another device, and a phone began uploading photos to cloud backup.

The culprit was bufferbloat, meaning that the router's queue filled and latency spiked, leaving game packets stuck behind a backlog of bulk traffic.

With no competing traffic, the latency stays low. The game sends small packets, and the queue rarely holds more than a frame or two.

Then, a download starts from another device on the network. The buffers absorb the burst, but do not drain fast enough, so latency climbs as game packets wait behind the buffers.

An upload joins the mix, and upload queues are usually the worst offenders on asymmetric links. The game now faces queuing in both directions.

The result: The buffer is full. Even tiny game packets wait until the bulk traffic ahead of them clears, which shows up as rubber-banding and delayed voice chat.

You can measure this with online tests - I use the Cloudflare Speed Test. It reports both loaded and unloaded latency so you can read the bufferbloat grade directly. You can get a rough picture by running any speed test while pinging a stable host in a terminal.

FQ-CoDel to the rescue

RouterOS supports several queue disciplines. The default First In, First Out (FIFO) queue simply stores packets in the order it receives them. When the link is full, every flow waits behind every other flow. Fair/Flow Queue Controlled Delay (FQ-CoDel) splits traffic into many small flows and gives each one a fair turn, dropping packets that linger in the queue. This keeps latency low without complex firewall mangle rules.

To use FQ-CoDel, first create a queue type, since RouterOS does not include one by default.

The default parameters are a sensible starting point. The target of 5ms defines the acceptable standing queue delay. The interval of 100ms matches a rough worst-case round-trip-time (RTT) budget.

The important part is the max-limit. It must sit below your real line rate, not at it. If you shape at 100% of the link, the ISP's equipment still saturates first, and the bloated queue forms there, outside your control. A common rule of thumb is to set the limit at about 90 to 95% of the measured download and upload speeds. That keeps the bottleneck on your router, where FQ-CoDel can actually manage the queue.

Replace the placeholders below with your own measured values: The first number is upload, the second is download.

Simple queues do not apply to packets that are fast-tracked by the firewall. Fast track bypasses the queue subsystem for performance. For the queue to work, disable the rule or remove it entirely.

If a rule exists, either disable it or remove it. Be careful: removing increases Central Processing Unit (CPU) load on high-throughput links. On a modern MikroTik with a CPU that can handle line-rate forwarding, the trade-off is worth it for improved latency.

After making the change, run the Cloudflare Speed Test again. You should see the bufferbloat grade improve, especially under upload load.

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.