Transit

Upstream diversity

Each location takes transit from more than one upstream, on separate physical paths into the building. Capacity is planned so that the site can lose its largest upstream at peak and still carry the traffic without congestion.

Routing

We prefer peering over transit, and within transit we steer per-destination on measured performance rather than sending everything to the cheapest port. Outbound policy uses local preference and communities; inbound uses prepending and community-based traffic engineering with our upstreams.

Redundancy

• Routers deployed in pairs, with each upstream terminated on a different router.
• Separate power feeds and separate fibre entries where the facility allows it.
• Automatic failover on session loss, with no manual step required.
• Regular drain tests so failover is exercised rather than assumed.

Geographic connectivity

Locations are not backhauled to a single hub. Every site has its own uplinks, so a problem in one region does not remove another region from the internet.

Who we buy from

Upstream names are published from the routing data our BGP backend returns, not typed into this page. Until that feed is connected, the table below shows demo records and this section stays empty rather than naming providers we have not confirmed.

Transit provider list: data unavailable