Summary

  • RIPE NCC says its 16:00 UTC RIS bview files were generated but not published because of a misconfiguration following a failover; it also acknowledged a monitoring gap.
  • The evidence supports a publication-layer failure, not a claim that BGP, every collector, RIS Live or all routing data failed.
  • The next control should be a consumer-edge completeness check that names the expected files, confirms backfill and timestamps the moment the public set becomes whole.

At 16:00 UTC, the files existed on one side of RIPE NCC’s system and were missing on the side that researchers could use. The status notice says the bviews had been generated. An infrastructure misconfiguration following a failover prevented publication. RIPE NCC said the configuration issue was fixed and the missing files were being published, while the incident remained in monitoring when this briefing’s evidence was frozen.

The most important sentence in the notice is not the recovery claim. It is the admission that the event “highlighted a gap” in monitoring. RIPE NCC says it was notified that the files were absent; the notice does not say who notified it or whether an automated alert had already fired. That leaves a precise accountability question: was success being measured at generation, while users depended on publication?

A routing snapshot is not delivered until it is retrievable

RIS collects BGP data per route collector. Its raw-data documentation distinguishes bview dumps, which store routing-system state at a point in time, from update files, which record subsequent changes. The documented cadence is one dump every eight hours and updates every five minutes. RFC 6396 defines the MRT structures used to carry those records.

None of that makes a generated file public. Between a collector and a researcher sit processing, object creation, indexing, storage and retrieval. The 25 August notice places the observed failure in that downstream chain. That is a narrower finding than a RIS outage, but it is not cosmetic. An analysis that expects a complete run across collectors can silently change when one cohort is absent or late.

The current record does not identify the affected collectors, the number of missing objects, the publication delay or the completion time of the backfill. It does not report corrupted files or lost routing data. RIS Live is a separately documented near-real-time stream, so the bview incident cannot be stretched into a claim that every delivery surface failed. The evidence also does not establish user impact, even though missing snapshots can affect reproducibility and time-sensitive analysis.

May makes provenance relevant, not guilt automatic

This was not RIPE NCC’s first 2026 notice about the bview publication layer. In May, an infrastructure change caused historical bviews to be recopied. Modification times changed, and some files covering 1 March through 21 May could be incomplete for copies downloaded after 26 May. RIPE NCC later reported that the files had been restored.

The two incidents must not be merged into one unproved root cause. The May event concerned historical copies after an infrastructure change; the August event concerned a scheduled run not reaching publication after a failover. Their legitimate connection is architectural: a publication layer can alter the availability, apparent freshness and completeness of data even when collection or generation has succeeded.

Monitor the object that the consumer receives

The minimum control is finite and testable. For every scheduled dump, RIPE NCC can derive an expected matrix of active collectors and bview objects. A monitor outside the publication path should ask whether each expected object is listed, retrievable, non-empty, structurally parseable and published within a declared latency. If a failover changes the writer or storage target, the same check should run against the public endpoint rather than the internal queue.

Backfill needs its own state. “Missing files are now being published” begins recovery; it does not tell a downstream operator when the set became complete or whether an earlier download should be replaced. A compact incident inventory could name the run, affected collectors, first missing time, public completion time and any integrity caveat. That would let users make their own risk decision without asking RIPE NCC to disclose sensitive infrastructure detail.

The incident is small enough to repair cleanly and specific enough to learn from. The right conclusion is not that public routing data cannot be trusted. It is that trust must attach to the consumer-visible object, not to an internal stage that users cannot observe.

Sources