Summary

  • RIPE NCC marked the RRC18 incident resolved at 09:19 CEST on 7 September after restarting two backend services, but said the root cause was still unclear and troubleshooting would continue.
  • At 09:33 CEST it opened an RRC24 incident with a similar update/bview publication symptom, suspected a common but unidentified cause and said other RRCs could not yet be ruled out.

Fourteen minutes is a small interval and a dangerous invitation. It is tempting to turn it into a technical chronology: one collector failed, two services were restarted, the fault moved to another collector. The public record does not prove that sequence. The two timestamps mark what RIPE NCC posted on its status service, not when either technical failure began. “Similar” and “suspect” are the institution’s own uncertainty words, not a finding of shared causation.

What the interval does establish is narrower and more useful. At 09:19 CEST on 7 September, RIPE NCC closed its RRC18 incident as resolved. The resolution note said two backend services had been restarted, that the root cause was not yet clear and that troubleshooting was continuing. At 09:33, 801 seconds later, RIPE NCC posted a new incident for RRC24. It said the RIS publication system had stopped publishing update and bview files for that collector, that the problem mirrored RRC18, that a common root cause was suspected but unidentified, and that other RRCs could experience the issue in the coming hours or days.

That is not evidence that the restart was wrong. It is evidence that service restoration and causal closure had separated.

What was restored at RRC18

The RRC18 record began on 4 September at 18:14 CEST. RIPE NCC said RIS update and bview files were not being published. It named the latest update file as updates.20260904.1335.gz and the latest bview as bview.20260904.0800.gz. Those are last-named public object timestamps. They do not reveal the moment of detection, the full affected-file count or the state of every other RIS interface.

On 5 September, RIPE NCC said that a thorough review of the RRC18 message-processing system had not identified the root cause. Later that day it said the missing updates and bviews had been published, the RRC18 publication flow had been restored, and monitoring would continue. The 7 September resolution then supplied the recovery action—restarting two backend services—while keeping the causal question explicitly open.

This distinction matters because “resolved” can answer two different questions. Can users retrieve the expected public output again? Has the institution identified and contained the condition that made the output stop? The RRC18 record answered the first affirmatively. Its own wording withheld the second.

Why RRC24 changed the meaning of the closure

RRC18 and RRC24 are not interchangeable boxes. RIPE NCC’s route-collector documentation lists RRC18 as an IXP collector at CATNIX in Barcelona, Spain. It lists RRC24 as a multihop collector hosted at LACNIC in Montevideo, Uruguay, serving a regional scope. Their visible roles and locations differ. A similar publication symptom at both therefore raises a fault-domain question: which shared layer, deployment cohort or operational dependency can touch both?

It does not answer that question. A common cause may exist, or two different causes may produce the same external symptom. The RRC24 post was still in the investigating state in the captured record. No public source identified the two restarted services, a configuration change, a failing host, a software release or a failover as the cause. No responsible account can fill those blanks by inference.

The public warning about possible further RRCs is consequential for a different reason. RIS publishes MRT data per collector. Its documentation says bview dumps represent routing state and are created every eight hours, while update files record changes and are created every five minutes. Researchers and operators use those public objects as evidence. This article does not establish that routing was affected, that captured BGP data was lost, or that every access method stopped working.

It establishes that the publication state of a per-collector evidence service became uncertain across more than one named collector while the suspected shared cause remained open.

The strongest case for RIPE NCC

Operational teams need permission to restore first and investigate second. A restart can be the fastest safe containment when a service is failing and the cause is not yet known. RIPE NCC also did several things a trustworthy operator should do: it said the cause was unclear, continued troubleshooting, reported that missing RRC18 files had been published, connected the RRC24 symptom to the earlier investigation without pretending the connection was proven, and warned that the observable scope might widen.

Keeping RRC18 in an active incident state after its publication service had recovered could also mislead users. A single red or amber status cannot cleanly express “output restored; causal investigation open”. Closing the service incident may therefore have been the most accurate action available in the status tool.

That defence sharpens the governance issue. The problem is not the decision to restart or the use of the word “resolved” for availability. It is the absence of a second, durable state for the unresolved fault domain. Once a green service tile replaces an incident, the institution’s continuing causal obligation becomes prose buried inside a closed page. The RRC24 post happened to keep it visible. A later recurrence might not.

A small fault-domain receipt

RIPE NCC does not need to publish sensitive topology or a post-mortem before it has facts. It can expose a compact receipt that separates operational restoration from causal closure.

The receipt would bind an incident identifier and collector to the observed symptom class, the recovery action, the time service was restored and the current cause state. Where RIPE NCC suspects a shared cause, it could publish the hypothesis as suspected, supported, rejected or confirmed, with a stable, non-sensitive token for the relevant deployment or failover cohort. It could also state which recurrence-watch scope is active, when that watch expires, who owns the follow-up, and when the causal investigation is closed or corrected.

Those fields are not a demand for hostnames, credentials or configuration. They are a way to preserve two truths at once: RRC18 publication was restored, and the condition behind the symptom had not been closed. If RRC24 proves unrelated, the record can say so. If the same layer is implicated, the record can join the incidents without rewriting their original timelines.

An earlier 25 August RIS incident reported that bview files had been generated but not published after a failover misconfiguration and acknowledged a monitoring gap. That separate incident already supports a different argument about generation, delivery and per-file monitoring. It is not evidence that the September RRC18 and RRC24 events share its cause, and this article does not reuse its delivery-ledger remedy. The present issue begins where that one ends: what public state should survive after output returns but the fault domain remains unknown?

Sources