Building Blue Canoe · 2 of 2
10Gb Where It Matters: Building the Back Channel
Why Blue Canoe separated ordinary service traffic from a 10Gb backend network for replication, backups and infrastructure operations.
Originally published on LinkedIn on 20 August 2026. This is the permanent Blue Canoe edition, with dated technical updates where the work subsequently progressed.
An 8Gb Internet connection creates an obvious temptation: put 10Gb everywhere.
That was not the design goal.
Most individual servers do not need an 8Gb Internet path. What matters is that the infrastructure can use the available bandwidth in aggregate without forcing internal work to compete with customer-facing traffic.
Two different traffic problems
We separated the problem into north/south and east/west traffic.
Each server retains a 1Gb path for ordinary north/south service traffic. The MikroTik RB4011 connects directly to the ONT at 10Gb and can therefore aggregate traffic from multiple hosts. Alongside that sits a 10Gb switching fabric used for the traffic that belongs inside the infrastructure: replication, backups, migrations, logging, repositories and other server-to-server work.
That distinction matters. A single machine topping out around gigabit is not evidence that an 8Gb edge is wasted. Several independent machines doing useful work are a different proposition.
The back channel is not theoretical
Mail replication, migrations, backups, repositories, logs and VM operations all create east/west traffic that users should not have to notice. The backend network gives those jobs room without making them compete with ordinary service traffic.
It also changes how services can be designed. Worker systems and operational tools can talk to the machines they manage over a private path, while public and user-facing identities remain deliberately separate.
Testing more than one client can deliver
Testing an 8Gb service is slightly absurd when the available clients are deliberately connected at 1Gb. No single workstation here should be able to pull 8Gb from the Internet. Aggregate load is the useful measurement, but generating and interpreting it turned out to be a project of its own.
Our first measured attempt moved 13.3GB through the WAN over 92 seconds and added no interface errors or drops. It also appeared to hit a ceiling around 2.4Gbps. Much of the traffic came from Ubuntu mirrors, so the source servers and paths were uncontrolled. That made the result evidence of what happened, not proof of where the limit lived.
The next attempt found another trap. Debian's older Python speedtest-cli confidently selected a list of supposedly nearby servers beginning in Portugal, more than 1,200km away. The browser on the same public address located us correctly in the UK. The client was wrong, and letting five machines use its automatic choice would merely have measured a bad discovery path several times at once.
Qualify the generators before trusting the aggregate
We replaced the legacy client with Ookla's native tool on five Proxmox nodes and qualified five independent UK endpoints individually. YouFibre, MyHostingSpace, KCOM, Truespeed and BeFibre each delivered roughly 940Mbps to a single 1Gb host. That established that the clients and destinations could produce the intended load before we asked them to do it together.
The synchronized run recorded two-second WAN receive intervals of 2.96Gbps and 2.88Gbps, with a best four-second average of 2.53Gbps. That was enough to contradict the suspected hard 2.5Gbps ceiling. It was not enough to claim that we had proved an 8Gb service.
During the synchronized production test, while multiple Speedtest clients' download and upload phases overlapped and the router continued doing its normal work, RB4011 CPU briefly reached 93% and 266 outbound queue drops were added. There were no added RX drops, TX drops, RX errors or TX errors. Router temperature remained between 27°C and 31°C; the MikroTik S+RJ10 copper module ranged from 63°C to 66°C.
A speed test stops being a test plan
The exercise exposed how difficult it is to verify an Internet service once its capacity exceeds ordinary client interfaces. Enough independent traffic generators are required. Their destinations need qualifying. Workloads need synchronising. Router counters, CPU, temperatures, errors and queue behaviour need recording. Even then, the first component to saturate becomes part of what is being measured.
Rather amusingly, I do not currently have enough online hardware to generate the full advertised bandwidth through the deliberately 1Gb service paths. That is a limitation of the test, not evidence against the circuit.
Capacity without contention
The value of the 10Gb fabric is not a large number on a speed-test page. It is that internal work has room to happen without becoming somebody else's problem, and that several ordinary hosts can use the edge concurrently without one of them defining the infrastructure's capacity. We disproved one convenient theory and exposed the next questions. At this scale, “run a speed test” stops being a test plan.