Summary

  • Trade coverage retained for this reading reports that the London Internet Exchange rebuilt its LON2 secondary fabric, that the fabric spans seventeen London sites, and that the equipment replaced had run for nearly twenty-five years.
  • Seventeen sites is a meaningful statement about dispersion across buildings. It is not a count of failure domains, because route-server configuration, addressing plans, monitoring views and the engineering team are configured once and used everywhere.
  • The operator's status page and a support service-status page were located on 19 October 2026, but no dated maintenance notice, incident entry or post-incident report was obtained as text for this review.
  • A member holding a port on each of two named platforms has bought two physical paths and one counterparty. Whether those paths fail together is unresolved on the retained material, and the document class that would close it is a dated notice log.

What the retained record actually says

The two retained trade items describe the same piece of work. Computer Weekly's report describes a project to update a seventeen-site LON2 network after nearly twenty-five years of service, with Nokia as technical partner. A syndicated account of the rebuild describes the completed refresh of a seventeen-site secondary interconnection fabric incorporating Nokia technology. Both were retrieved on 19 October 2026 and both arrived as provider-written summaries rather than page text, so what follows is reported material, not quoted operator language.

The two items carry the same figures and the same framing. They read as two publications narrating one announcement rather than as two independent confirmations, and that sameness is my reading of the pair, not a claim either publication makes. Nothing retained dates the completion more sharply than the month of the reporting, and the operator's own announcement was not obtained as text in this review.

Three quantities are therefore in play: seventeen sites, a fabric described as secondary, and a service life of nearly a quarter century before replacement. All three are reported. None of them is a resilience measurement.

Why the site count is the wrong unit

Seventeen facilities is not a small number, and it does real work. It bounds the failure class that a single building imposes: one site's power feed, one site's cooling plant, one site's water ingress, one site's fire suppression, one site's fibre entry point. A fabric that spans seventeen buildings cannot be taken out by the loss of any one of them, and that is a genuine structural property worth stating plainly.

The trouble is that the number invites a second inference it does not support. A failure domain is bounded by what is shared, not by what is separated. Two facilities that draw on the same change-control process, the same peering addressing plan, the same route-server configuration and the same engineering rota are not two failure domains; they are one domain with two addresses. Seventeen sites tells you how many places the equipment sits. It does not tell you how many independent ways the service can fail.

The elements that do not multiply are specific and unglamorous. A route-server configuration is authored once and propagated. A peering LAN addressing plan is designed once and applied. Monitoring, looking-glass views and alerting run on a common management layer. The people who turn the change are the same people. None of that is a criticism of the operator; it is how an exchange is run. It is simply the layer where a building count stops being informative.

What a member with two ports has actually bought

This part is argument rather than record, and worth flagging as such. A member who takes a port on each of two named platforms has bought two physical paths and two service interfaces. What the member has not bought, by construction, is a second counterparty. The contract, the escalation path, the engineering judgement and the commercial continuity all point at one organisation. Platform plurality diversifies where traffic enters. It does not diversify who is responsible when it does not enter.

That distinction matters more in procurement than in architecture. A resilience claim built on port count per platform can be entirely truthful and still leave a buyer with a single correlated dependency, because the buyer and the operator have been counting different things: the operator counts facilities, the buyer needs to count independent ways of failing.

Where the record stops

This is the boundary, and it is dated. The operator's principal site was retained as a summary only (linx.net). So were the operator's status page, its support service-status page and an operational account used to supplement the status page. Each was characterised by the retrieval layer as the place where planned maintenance and incident reports are communicated. None yielded page text.

A request that specifically asked for the status pages' dated entries, their affected-service scope and their platform naming returned a connection failure against both addresses. An attempt to reach a structured exchange-registry record that would have carried a dated facility count per platform was blocked. Later attempts to force quoted passages failed outright.

So the honest statement is narrow: no dated maintenance notice, incident entry or post-incident report was read for this review. That is not the same as reporting that none exists, and this article does not report that. What it reports is that the independence of two named London platforms was not settled by the material actually read on 19 October 2026, and that the surface where it would be settled was reachable by name but not by text.

The one thing the retained summaries do establish is weaker than it looks. A status page characterised as the place where maintenance and incidents are communicated suggests a reporting practice exists. It shows nothing about whether any published entry names a platform, whether any entry has ever covered both at once, or whether a post-incident account has ever been written. Visibility without legibility preserves the marketing benefit of a resilience claim while withholding its test.

What would settle it

The falsifiers can be named in advance, which is the useful part of an inconclusive record. A dated notice showing one London platform out of service while the other carried traffic would establish separation as an observed event rather than an asserted property. A dated notice placing both platforms inside a single maintenance window or a single incident would establish a shared bound, and the window plus the stated scope would be the finding.

A published separation, availability or restoration commitment with an effective date would establish an obligation — a different document class from an observed outcome, and one that binds when the architecture does not. And a readable notice log containing no platform-level entries at all would itself be a finding about what a buyer cannot verify.

The near-twenty-five-year service life belongs in the same category. It describes replacement cadence, not robustness. An equipment generation that ran that long tells you the operator does not turn its fabric over often; it does not tell you whether the fabric's two named halves were ever tested against each other.

For a buyer or a valuers' file, the practical consequence is a discount for unverified redundancy, not a rejection of the claim. The claim may well be true. The directory record for London Internet Exchange Ltd. is the right place to track the entity; the architectural question sits outside it, in a notice archive nobody in this review was able to open.