Кратко

  • В серии 23421 публичный Routinator 0.14.2 AFRINIC показал 39 059 валидных входных VRP, 8 212 дублей и 30 847 итоговых VRP.
  • В серии 23422 значения стали 39 058 и 8 211, но итог сохранился на уровне 30 847; единичное изменение полностью пришлось на IPv4.
  • В документации Routinator дублями названы VRP, возникающие из ROA с одинаковым разрешением. При нескольких якорях или репозиториях их отнесение зависит от порядка обработки.
  • Снимки не называют изменившийся tuple, исходную ROA или сетевой эффект. Нужна квитанция происхождения, связывающая исходные объекты, число вхождений, итоговый набор и отдельное доказательство со стороны маршрутизатора.

Одна и та же разность пережила смену серии

Валидация с серийным номером 23421 завершилась 29 августа в 06:37:53 UTC. В разделе якоря AFRINIC сервис насчитал 39 059 присутствующих и валидных VRP. Из них 8 212 были отнесены к дубликатам. Опасных и локально отфильтрованных VRP не было, поэтому итог выводился непосредственно: 39 059 минус 8 212 равнялось 30 847.

Следующая завершённая валидация, серия 23422, получила отметку 06:57:08 UTC. Входное число снизилось до 39 058, число дублей — до 8 211. Итог остался 30 847. Иными словами, исчезновение одного входного вхождения полностью поглотилось на стадии устранения множественности.

Разбивка показывает, где именно двигался счётчик. Для IPv4 общее число изменилось с 37 804 на 37 803, дубли — с 8 136 на 8 135, финальные VRP остались 29 668. Строка IPv6 не изменилась: 1 255 всего, 76 дублей, 1 179 в финале. В обоих снимках было 1 408 валидных точек публикации и ни одной отклонённой.

Рядом есть ещё одна разница. Сначала сервис показывал 12 171 валидную ROA и ни одной невалидной; затем — 12 170 валидных и одну невалидную. Арифметически это хорошо ложится в простой рассказ. Документально — нет. Ответ API не связывает конкретную ROA с пропавшим дублирующим вхождением и не сообщает её хеш, URI или цепочку сертификатов.

Поэтому доказанная формулировка ограничена: между двумя завершёнными запусками валидатор стал относить к AFRINIC на одну валидную входную VRP и один дубль меньше, сохранив то же итоговое количество. Не доказаны отзыв, переиздание, исправление, намерение держателя или действие AFRINIC. Не зафиксировано и изменение маршрута.

Даже тождество итогового содержимого пока не установлено. Одинаковый размер двух множеств допускает замену одного элемента другим. Наблюдаемая пара изменений совместима с исчезновением лишнего источника уже представленного разрешения, но установить это может лишь сравнение самих tuples.

Файл ROA, payload и маршрут принадлежат разным журналам

ROA — подписанный объект RPKI. Он указывает один исходный AS и содержит одно или несколько разрешений для адресных префиксов, при необходимости с максимальной длиной. У файла есть сертификатный контекст и место публикации. Одна ROA способна породить несколько валидированных payload.

VRP — компактная запись для проверки происхождения: IP-адрес, длина префикса, максимальная длина и ASN источника. Это не сам файл ROA и не BGP-маршрут. Разные файлы или пути публикации могут дать один и тот же tuple.

Дубликат в метрике Routinator — дополнительное вхождение уже представленного разрешения. В финальном наборе маршрутизатору не требуются две одинаковые инструкции. Удаление повторного вхождения не означает, что оставшееся разрешение признано ошибочным, и ничего не говорит о наличии «дублирующего маршрута» в BGP.

Маршрут — отдельное наблюдение: префикс и путь AS, из которого выводится исходный ASN. RFC 6811 разделяет результат на Valid, если хотя бы одна VRP совпадает; Invalid, если есть покрытие, но нет совпадения; и NotFound, если покрытия нет. Число дублей под якорем не определяет состояние конкретного маршрута.

Наконец, есть решение оператора. Кэш готовит набор и может передавать его по RPKI-to-Router, но оператор выбирает источник данных и локальную политику. Получение серии, установка данных, наличие BGP-маршрута и действие политики — четыре проверяемых состояния, а не один вывод из панели валидатора.

Разделение объектов сохраняет и разделение полномочий. Держатель ресурса подписывает разрешение. Оператор репозитория обеспечивает публикацию. Оператор валидатора задаёт конфигурацию, выполняет проверку и относит вхождения к источникам. Сетевой оператор принимает решение о маршруте. AFRINIC управляет наблюдаемым сервисом и своим якорем доверия, но не становится автором каждой ROA и владельцем каждого downstream-решения.

Слово «дубль» сообщает о кратности, а не о виновнике

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

Routinator прямо предупреждает о ещё одном механизме. Если VRP встречается в нескольких якорях доверия или репозиториях, то, какое вхождение будет названо дубликатом, зависит от порядка обработки. Порядок может меняться между запусками, поэтому атрибуция и число способны неожиданно колебаться.

Эта оговорка превращает дубли в локальную измерительную величину. Она относится к конкретной версии валидатора, его конфигурации, набору источников, моменту и порядку. Без этих координат цифра теряет точность, даже если записана до единицы.

Поэтому нельзя ранжировать RIR по столбцу дублей одного снимка. Большое значение не доказывает плохое управление, ноль не доказывает безупречность. Отличаться могут топология репозиториев и правила отнесения. Содержательное сравнение должно фиксировать инструмент и следить за одними и теми же объектами.

Неизменные 30 847 в данном случае работают как ограничитель. Изменение входной кратности не отразилось в итоговом количестве уникальных VRP. Это весомый повод не называть единичное движение потерей разрешения для маршрутизаторов. Но это ещё не доказательство неизменности состава и не квитанция от конкретного роутера.

Так появляется правильный вопрос: какие хеши исходных ROA создавали один tuple до и после запуска, сколько было вхождений и вошёл ли тот же tuple в финальный набор? Ответ на него отделяет обычную избыточность от значимого изменения авторизации.

Подробный endpoint остаётся снимком, а не журналом причин

Публичный endpoint предоставляет немало. Документация называет его исчерпывающим JSON-источником сведений о якорях доверия, репозиториях, соединениях RRDP и rsync, а также сессиях RTR и HTTP. На нём построен пользовательский интерфейс со статистикой последнего запуска. Версия, серия и время делают снимок воспроизводимым.

Но исчерпывающим является состояние сервиса, не история каждого перехода. Между сериями нет публичной таблицы, где старый и новый хеш ROA соединены с URI, сертификатом, tuple, числом вхождений и причиной изменения. Мы знаем, что агрегат сдвинулся, но не получаем его подлежащее.

Сведения о сессиях RTR не закрывают разрыв. Подключённый клиент не обязательно уже получил конкретную серию, а получение серии не доказывает применение к определённому BGP-маршруту. Для утверждения о влиянии нужны квитанция клиента, номер серии, маршрут во времени и политика.

Публичность не требует раскрывать внутреннюю топологию или личности клиентов. Достаточно хешей общедоступных объектов, VRP tuples, кратности, атрибуции и финального diff. Закрытая часть может содержать больше деталей. Главное, чтобы у счётчика был обратный путь к объекту.

Квитанция происхождения должна фиксировать переход, а не домысливать его

В заголовке нужны версия валидатора и отпечаток конфигурации, серийный номер, время начала и завершения, отпечатки набора якорей и репозиториев. Эти поля определяют измерительный контекст.

Для каждого затронутого уникального tuple записываются исходный ASN, префикс и максимальная длина. Рядом — хеши исходных ROA, URI публикации и ограниченные ссылки на сертификатную цепочку. Для каждой серии указываются кратность и то, как валидатор распределил оригинальное и дублирующее вхождения.

Причина остаётся контролируемым статусом. Наблюдаемый отзыв, переиздание, ошибка валидации, недоступность репозитория или смена атрибуции допустимы только при наличии соответствующего доказательства. В остальных случаях честное значение — не установлено, с последующим дополнением без стирания первоначальной неопределённости.

Затем фиксируется diff финального набора: tuple вошёл, вышел или остался, с привязкой к серии кэша. Сетевой эффект начинается в отдельной цепочке, где есть получивший данные роутер, BGP-наблюдение и действие политики. Так валидатор не говорит от имени тех, чьих решений он не контролирует.

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

Узкая запись полезнее широкого вывода

В снимках нет пострадавшей сети, маршрута или владельца. Нет доказательства, что AFRINIC исправила плохую ROA. Нет доказательства, что маршрутизатор принял иное решение. Есть только две точные версии состояния и документированное ограничение метрики дублей.

Это хороший масштаб для реестровой функции. Организация не обязана превращать показатель валидатора в оценку глобальной реальности. Она обязана, насколько возможно, сохранять связь между подписанным объектом, результатом проверки, версией итогового набора и последующей поправкой.

Институциональная сила здесь состоит в отказе от лишнего полномочия. AFRINIC может свидетельствовать о своём валидаторе. Держатель — о своём разрешении. Оператор — о своём маршруте. Квитанция происхождения даёт им общую, но не смешанную основу.

Источники