Rollout plan for the new UK network

Following our March announcement of the 100G layer 1 circuit between Telehouse and UK-B, here's how we're rolling it out. Work begins in June 2026.

Current state

Computle operates its own ASN and announces its IPv4 space globally. Today that space is leased from IPv4 brokers and announced from our sites via local IP transit. Customer traffic from London reaches us via the public internet, traversing four or five carrier networks each way. Each hop adds latency and a point at which a carrier might reroute traffic suboptimally. We have no control over what happens between the customer's ISP and our edge.

The new infrastructure adds a second announcement point in London and a private fibre between the two sites, making Computle the carrier between Telehouse and UK-B. It also lays the foundation for connecting our UKA and UKC sites to the same carrier hotel.

Stage 1: dual-site announcement [June]

We've installed our own routers at Telehouse and UK-B. The first stage is announcing our /24 from both sites - peering at LINX in London and continuing to use our existing transit providers at UK-B.

The effect is that London networks peering with us at LINX start sending their traffic directly to Telehouse rather than crossing multiple carriers to reach UK-B. From Telehouse, their traffic crosses our own fibre north. Networks without a LINX presence continue reaching us as before.

No customers migrate at this stage. The new path exists in parallel with the old one.

Stage 2: test with internal traffic [June]

Before any customer traffic touches the new path, we migrate our own services onto it - monitoring, internal tooling, etc. This lets us validate the circuit under real load and catch any operational issues before customers are affected.

Stage 3: redundancy [June]

Before any customer migrates, we build:

• A backup tunnel between Telehouse and UK-B riding the public internet, ready to carry traffic if the primary L1 fails
• Automatic failure detection that shifts traffic to the backup in under a second
• Automatic route withdrawal as a final fallback if both paths fail, so traffic falls back to UK-B's transits cleanly rather than black-holing

In a fibre cut, customers see a brief increase in latency (the backup tunnel is slower than the dedicated fibre) for the duration of the outage. When the fibre is repaired, traffic shifts back automatically. No outage, no manual intervention.

Stage 4: customer migration [July/August]

Customer traffic moves to the new path one customer at a time. Each migration is two steps:

1. Allocate a new public IP from our /24, served from both sites
2. Cut over the endpoint the customer connects to, once the new IP is verified working

We migrate serially. Before moving the next customer, we verify the previous one's latency improvement against their baseline. The old IP stays live during the migration window, so rollback takes minutes if anything looks wrong.

Stage 5: measure

For each customer migration, we record RTT, jitter, and path stability before and after. The target is the latency figure from the original announcement — a consistent ~7ms between London and UK-B with no variance from intermediate carriers.