Summary

  • RIPE NCC said a DE-CIX peer began sending an unusually high number of BGP messages to route collector RRC12 at 01:30 UTC on 2 October, after which its Kafka-consuming processing pipeline repeatedly timed out.
  • At a 19:10 UTC check that day, RRC12’s public October archive still ended at 01:00 UTC. That is a publication gap in a measurement service, not evidence of missing Internet routes or disrupted traffic.

Analysis

RIPE NCC opened a status incident for “RRC12 MRT update files are not produced” at 09:42 CEST on 2 October. Its first notice said the latest RRC12 update file was timestamped 01:00 UTC and its latest BVIEW snapshot 00:00 UTC. At 13:26 CEST, the organisation said a DE-CIX peer had started sending an unusually high number of BGP messages to RRC12 at 01:30 UTC. The process consuming updates from Kafka could not keep up, it said; each restart timed out again before making sufficient progress. RIPE also reported delays in producing update files for other RRCs.

RRC12 is a route collector in Frankfurt attached to DE-CIX. Route collectors receive BGP data from peers; they do not choose the routes used by those networks. RIPE’s documentation says it stores captured data per collector, with “update” files recording changes over an interval and BVIEW files storing a state snapshot. It says update files are normally created every five minutes. This is the publication cadence of an observation feed, not a promise that every collector always meets it.

A read-only check of RIPE’s public archive at 19:10 UTC found no RRC12 update newer than updates.20261002.0100.gz—18 hours and 10 minutes before the check. The RRC18 archive had reached 19:05 UTC. That comparison shows the visible freshness gap between those two public directories at that moment; it does not establish that all other collectors were unaffected, identify which ones had earlier delays, or explain why RRC18 had newer files.

The status record remained identified and under troubleshooting at the review cutoff. It did not name the peer or publish its message rate, the routes involved, the duration of any other collector’s delay, the queue’s replay state, or the recovery plan. Nor did it say that routes were lost or that traffic was disrupted. A delayed file means an analyst must check the file timestamp before interpreting an empty interval; it cannot be read as proof that no BGP changes occurred.

The useful next update is a short recovery receipt: the latest update and BVIEW timestamps for affected collectors, whether delayed intervals were replayed, and when normal publication resumed. That would let users of RIS data distinguish collection, processing and publication status without implying that an archive delay changed the routing system itself.

Sources