Before moving to the next part, I thought it was relevant to have a background on what network architecture was backing all of this. I was never the person to take what an ISP would sell as a useless excuse of a modem/router, but I was still using a stock TP-Link router with reasonably good wireless and gigabit networking support.
What I now have are two ISPs, both providing FTTH (fiber to the home). The first one provides 300Mbps symmetrical, and the second one reaches 200Mbps. Each has its ONT (Optical network terminal) and provides a gigabit port or two bundled with unusable WiFi. There is nothing I can do about this, but it is good enough for the job.
For the router in front of this, I repurposed the one I said I had before, the TP-Link Archer C6 , and installed OpenWRT on it . OpenWRT is an open-source project which provides a Linux operating system for a vast range of CPU types targeted at networking. It can even be installed on a VM as a router if needed, has package management, and provides a writable filesystem.
I use a custom compiled build to include the packages I need and none that I don’t to reduce the file size and make it fit in the tiny 8MB flash the router has. It disables all IPv6-related features since my provider does not have support and adds other packages such as a custom theme, mwan3 that I’ll come to in a minute, and files for tailscale which deserves its separate post.
I use mwan3 for policy-based routing (PBR) to utilize both of my ISPs, and I can connect both their ONT/modems to this router since the concept of a WAN port on a router is software-based, which happens to be in our control with OpenWRT, how convenient! The router is “technically” not a router since all the five ports it has (4 “LAN” and 1 “WAN” ports) are all on the same switch. As a result, the CPU makes all routing decisions by tagging traffic to VLANs, so in reality, this is a layer-3 switch rather than a full-fledged router!
That’s not an issue for us, as, for Linux, subinterfaces are as good as the regular interfaces anyway. So, creating two VLANs for the two ISPs and keeping the VLAN 1 for LAN works pretty well. Correctly configure tagging so that the untagged traffic on a port belongs to the VLAN (access, no trunking). So, I have rules on what traffic should go where such as youtube works better on one ISP versus another, and for playing VALORANT to get the lowest ping times, only one ISP is good. For the rest, I usually leave it on load balancing with sticky flag enabled so that it can play nice with session-based traffic.
My PC and the NUC all have gigabit (my PC can do 2.5, but routers are scarce and expensive) connectivity between them now, and they have pretty decent internet available as well.
Now for some screenshots :)
Just trust me when I say that this was the internet speed I got (both upload and download) because I do not have better pictures, and I am lazy to get new ones :). The setup here is with two tabs open doing a speed test on fast.com and Ookla Speedtest together, and the load balancing picked one ISP for each.
I get the full use of my money here at 110+ MBps (~900+ Mbps) of local network bandwidth, and that is good enough for now as it is what I would expect the HDD read speeds to be at around. Look at that stability of file transfer speeds!
With that, let’s get back on track for this series by looking at CloudFlare, and what it does for this setup.