The Exchange Caught Fire: An Acceptance Test We Didn't Order

Originally published on LinkedIn on 3 September 2026. This is the permanent Blue Canoe edition, with dated technical updates where the work subsequently progressed.

We had plans for testing the new MikroTik edge. None of them involved the exchange catching fire.

Shortly after the new network went live, a fire in an exchange cabinet took out our lines. The primary service eventually returned, but the recovery process added its own entertainment: repeated interruptions, support scripts aimed at replacing customer equipment, and finally an incorrectly assigned VLAN that I had been pointing at for most of the day.

As acceptance testing goes, it was fairly comprehensive.

The useful distinction: our failure or theirs?

One of the reasons for replacing the ISP router was to make the boundary clearer. The ONT provides the fibre handoff. The MikroTik owns our routing. The internal fabric is ours. When something fails, I want to know which side of that boundary it belongs to.

During the incident the new edge behaved impeccably. Carrier disappeared and returned. Upstream configuration changed. The MikroTik continued doing exactly what its configuration said it should do.

That was more valuable than any synthetic benchmark because it converted “this seems stable” into evidence gathered during an ugly real-world event.

Support systems have failure modes too

The technical fault was frustrating. The support process was more interesting.

First-line support has a necessary job: most consumer broadband faults really can be solved by checking Wi-Fi, rebooting equipment or replacing customer-premises hardware. The problem comes when the process cannot recognise that a fault domain has already been isolated.

If an experienced network engineer inside an ISP had to report every fault through a domestic call-centre script, I suspect the limitations would become obvious fairly quickly.

Eventually the issue reached people who could engage with the network itself, and a senior member of YouFibre’s team gave me a direct route for future faults. That is not about wanting special treatment. It is about matching the support path to the technical nature of the fault.

Quiet customers are profitable until the transport disappears

We have taken on most of the heavy lifting ourselves. We own and manage the edge, the servers, DNS, mail and the internal network. That makes us a comparatively low-maintenance customer right up until the transport layer fails.

When we do raise a fault, it is therefore useful if the provider can distinguish “customer Wi-Fi is slow” from “the service is on the wrong VLAN.”

The router earned its place

The incident also changed how I felt about the RB4011. I had selected it because the price/performance case was extremely strong. Trust came later.

Since deployment, both MikroTiks have handled everything we have asked of them. The primary has dealt with the 10Gb ONT handoff, routed public addressing, aggregate traffic, firewalling, WireGuard and deliberate stress testing. During the earlier measured run described in the previous article, it moved 13.3GB in 92 seconds without adding a WAN RX drop, TX drop, outbound queue drop, RX error or TX error.

Speed was the reason the project started. Stability became the bigger win.

Boring is good

The best network equipment gradually disappears from your attention. You stop wondering whether it will survive the next change and start assuming it will continue forwarding packets while you work on something more interesting.

That is where the MikroTik has ended up. The exchange fire, the recovery and the VLAN mistake were not tests I would have chosen. They were, however, much more convincing than the tests I had planned.

The edge had become boring. That was exactly what I wanted.