Кратко

  • RIPE NCC объяснила остановку файлов RRC12 2 октября необычно большим числом сообщений BGP от пира DE-CIX, нагрузкой на один раздел Kafka и повторным сканированием, которое завершалось по тайм-ауту после каждого перезапуска.
  • Оператор сообщил о задержке файлов обновлений и у других сборщиков. Исправление конфигурации вернуло обработку в работу; структурное исправление скрытого дефекта оставалось будущей задачей.

Главный факт в сообщении — не только отсутствие файлов у RRC12. RIPE NCC указала, что задержались также файлы обновлений других route collectors. Это сбой производства данных наблюдения за маршрутизацией. В сообщении нет утверждения, что передача пакетов через Интернет прекратилась.

В записи об инциденте говорится, что 2 октября в 01:30 UTC пир DE-CIX начал отправлять в RRC12 необычно много сообщений BGP. Процесс, считывавший данные из Kafka, не справился с объёмом и завершился по тайм-ауту. После перезапуска он пытался повторно просканировать большой объём данных, но снова раз за разом истекало время до появления прогресса. Позже RIPE NCC сообщила, что из-за ошибки конфигурации сканирование занимало на порядок больше времени, чем должно было. Исправление конфигурации позволило процессу продолжиться. Структурное исправление скрытого дефекта оператор отложил на следующий спринт.

В последовательности видны две разные нагрузки. Сначала входящий поток превысил способность пути обработки справляться с работой. Затем восстановление повторяло крупное сканирование в конфигурации, которая его замедляла. Первая нагрузка создала очередь; вторая мешала выйти из неё обычным перезапуском. Публичная запись не раскрывает имя пира, скорость сообщений, структуру разделов, глубину очереди, параметры тайм-аутов или детали сканирования. Можно передать объяснение оператора, но нельзя дополнять его не опубликованными числами.

RIS собирает данные BGP, чтобы отслеживать маршрутизацию. Документация сборщиков маршрутов описывает физические и виртуальные машины, получающие данные через пиринговые сеансы; RRC12 указан во Франкфурте, на DE-CIX. Документация MRT говорит о хранении данных отдельно по каждому сборщику: dump показывает состояние маршрутов в определённый момент, а update-файл фиксирует изменения за интервал. Обычный график — каждые восемь часов для dump и каждые пять минут для update. Это штатный график, а не свидетельство того, что каждый файл во время сбоя был полным и своевременным.

В 09:42 CEST 2 октября статус-страница сообщала, что последняя доступная update-запись RRC12 имела метку 01:00 UTC, а последний bview — 00:00 UTC. Это снимок актуальности архива в момент сообщения, но не точное время остановки производства и не максимальный размер очереди. Позже RIPE NCC заявила, что после восстановления исходного процесса опубликовала bview и update-файлы начиная со 2 октября. Это подтверждение догоняющей публикации от самого оператора, а не проверка целостности каждого файла или оценка влияния на пользователей.

Нужно различать маршрут в сети и его архивную запись. RFC 6396 определяет формат MRT для экспорта информации о маршрутизации. Задержка файла ограничивает, что аналитик может увидеть в архиве за конкретный момент. Но сама по себе она не доказывает разрыв BGP-сеанса, отзыв маршрута в действующей сети или потерю связи у клиента. При этом архивные данные нужны операторам и исследователям для восстановления хронологии событий. RIPE NCC не измерила последствия для таких пользователей в этом уведомлении, поэтому предполагать их нельзя.

Задержка других сборщиков ставит вопрос об изоляции отказов. Поток поступил в RRC12; RIPE NCC указала нагрузку на один раздел Kafka и одновременно задержку файлов обновлений других RRC. Это указывает на общую зависимость в описанном пути обработки, но не раскрывает полную архитектуру и распределение всех данных. Надёжно утверждать можно только то, что, по словам оператора, воздействие не ограничилось входным сборщиком. Поэтому управленчески важны метрики актуальности по нескольким сборщикам и защита выходов от перегрузки в одном месте.

План работ, опубликованный до инцидента, даёт контекст, но не объясняет его причину. В плане RIS на четвёртый квартал 2026 года, обновлённом 17 сентября, уже значилось улучшение мониторинга обработки данных RIS/RIPEstat — как задача в работе с ограничением по сроку на квартал. Замена оборудования Kafka и переход на новую версию также шли как проект; план отмечал, что раньше работа откладывалась из-за нехватки ресурсов. Параллельно исследовались альтернативные архитектуры хранения, призванные уменьшить зависимость от HBase. Страница не связывает эти проекты с октябрьским сбоем и не говорит, что они привели к восстановлению.

В этом же плане говорится о пересмотре пиринга: сохранить полезный и разнообразный набор пиров, одновременно удерживая рост объёма данных на приемлемом уровне. Дополнительные источники могут обогатить архив, но требуют обработки. Из инцидента нельзя заключить, что пир был лишним, действовал неправильно или отвечал за конструкцию конвейера. Операционная задача — сохранить полезный поток и одновременно сделать его стоимость видимой, не допуская, чтобы всплеск одного ввода задерживал файлы остальных сборщиков.

Следующая запись о восстановлении должна показывать, какие файлы задержались, какой интервал они должны были покрыть, когда публикация возобновилась, были ли данные воспроизведены без пропусков и дублей и как это проверили. Тест нагрузки должен описывать испробованный объём входящих данных, максимальное отставание, поведение перезапуска при накопленной очереди и условие, при котором затронут другой сборщик. Тогда статус «решено» будет объяснять, какие данные восстановлены, а какой структурный риск остался.

Note 70 Хэн Лу о различии между технической возможностью и практической реальностью служит только редакционным ориентиром: технический сигнал не разрешает делать любые выводы о последствиях. Это не источник сведений об RIPE. Факты и статус работ приведены по материалам самой RIPE NCC; предлагаемые требования к надёжности — редакционный анализ.

RIPE NCC отметила инцидент как решённый 6 октября. Исправление конфигурации, позволившее продолжить обработку, и обещанное структурное исправление скрытого дефекта — разные этапы. Первое восстановило работу в моменте. Второе должно сопровождаться нагрузочным тестом и проверкой перезапуска, чтобы показать, что следующий всплеск не запустит тот же цикл. Публичная запись подтверждает различие, но результатов такого испытания пока не содержит.

Источники