Кратко

  • RIPE NCC сообщила, что 2 октября в 01:30 UTC пир DE-CIX начал отправлять на коллектор маршрутов RRC12 необычно большое число сообщений BGP; после этого процесс, читающий обновления из Kafka, неоднократно завершался по тайм-ауту.
  • При проверке в 19:10 UTC того же дня публичный архив RRC12 не содержал обновлений позднее 01:00 UTC. Это задержка публикации в службе измерений, а не доказательство отсутствия интернет-маршрутов или перебоя трафика.

Анализ

2 октября в 09:42 CEST RIPE NCC создала инцидент «RRC12 MRT update files are not produced». В первом сообщении говорилось, что последний файл обновлений RRC12 датирован 01:00 UTC, а последний снимок состояния BVIEW — 00:00 UTC. В 13:26 CEST организация сообщила, что с 01:30 UTC пир DE-CIX отправлял на RRC12 необычно много сообщений BGP. По словам RIPE, процесс, потреблявший обновления из Kafka, не справлялся с объёмом; после каждого перезапуска он снова истекал по тайм-ауту, не успев продвинуться достаточно далеко. RIPE также сообщила о задержках при создании файлов обновлений других RRC.

RRC12 — коллектор маршрутов во Франкфурте, подключённый к DE-CIX. Коллекторы получают BGP-данные от пиров, но не выбирают маршруты, которые используют эти сети. В документации RIPE сказано, что собранные данные хранятся отдельно для каждого коллектора: файлы «update» фиксируют изменения за интервал, а BVIEW содержит снимок состояния. Обычно файлы обновлений создаются каждые пять минут. Это штатный ритм публикации потока наблюдений, а не гарантия того, что каждый коллектор всегда его выдерживает.

При проверке публичного архива RIPE в режиме чтения в 19:10 UTC файл обновлений RRC12 новее updates.20261002.0100.gz не обнаружился; его временная метка отстояла от проверки на 18 часов и 10 минут. Архив RRC18 к тому времени доходил до 19:05 UTC. Сравнение показывает разницу в видимой актуальности этих двух каталогов на тот момент. Оно не доказывает, что все прочие коллекторы работали без задержек, не указывает, какие из них задерживались раньше, и не объясняет, почему у RRC18 были более новые файлы.

На момент проверки инцидент оставался в статусе «identified» и расследовался. В сообщении не назывались пир или его ASN, интенсивность сообщений, затронутые маршруты, длительность задержек других коллекторов, состояние повторной обработки очереди или план восстановления. RIPE также не сообщала о потере маршрутов или нарушении трафика. Если файл запаздывает, аналитик должен проверить его временную метку, прежде чем истолковывать пустой интервал; это не доказывает, что изменений BGP не было.

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

Источники