Кратко

  • Два доступных валидатора RPKI могут публиковать разные наборы проверенных данных, поскольку сбор и проверка не завершаются одновременно во всех точках.
  • Выбор или смена кэша для маршрутизатора может изменить доказательную основу проверки источника; доступность и полномочие политики — разные контуры управления.
  • Протокол расхождений должен фиксировать отпечатки наборов, результаты сбора, назначение маршрутизаторов, владельца решения, условия переключения и доказательство отката.

Во время технических работ валидаторы A и B исправны. Сеансы RTR установлены, красных сигналов нет. Однако A уже завершил цикл, отражающий недавний отзыв ROA, а B для одной точки публикации ещё использует прежний проверенный объект. Группы маршрутизаторов, подключённые к A и B, могут по-разному классифицировать одну пару префикса и источника.

Для этого не нужен сбой протокола. RFC 7115 называет глобальную RPKI слабо согласованной: публикация, получение, проверка и доставка идут по разным часам. Несколько relying party повышают доступность, но не создают единого мгновенного ответа во всём мире.

Проверенный кэш не является пассивной копией. Он собирает объекты, оценивает их действительность и передаёт маршрутизаторам итоговый набор payload. Переход с A на B может восстановить связь и одновременно изменить разрешения источника, на которых основана локальная политика. Даже автоматическое переключение реализует операционный выбор.

RFC 9286 показывает одну причину расхождений: manifest после nextUpdate считается устаревшим, а получение — неудачным, хотя проблема может касаться одной точки публикации. RFC 8182 отдельно проверяет сеанс, серийный номер и хэш RRDP. Переход к snapshot — штатный путь восстановления и сам по себе не доказывает ошибку валидатора.

RFC 8210 добавляет границу маршрутизатора. Он принимает состояние кэша после полного ответа, отмеченного End of Data. Интервалы refresh, retry и expire управляют повторными запросами и хранением. Зелёное соединение не доказывает одинаковые результаты валидаторов, завершение одного обновления на всех маршрутизаторах или нейтральность переключения для политики.

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

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

Источники