Кратко

  • AC-Flag 0x10, определённый RFC 9983 для OSPFv2 Extended Prefix TLV, означает только то, что префикс предназначен для объявления несколькими узлами.
  • Конфигурация, распространение LSA, локальная FIB, выбор потока, состояние реплики и результат приложения — отдельные факты, требующие разных доказательств.

В отчёте можно увидеть несколько объявлений одного префикса, тот же AC-Flag в телеметрии и копию свойства в BGP-LS. После этого хочется сказать: «anycast работает». Но наблюдалась декларация плоскости управления, а не выбор конкретного пакета и не завершение операции на стороне сервиса.

RFC 9983, опубликованный IETF Standards Track в мае 2026 года, описывает OSPFv2 Anycast Property Advertisement. Он выделяет 0x10 как Anycast Flag в реестре флагов Extended Prefix TLV. Смысл намеренно узок: префикс предназначен для объявления более чем одним узлом. Настроенный как anycast префикс обязан нести флаг; не настроенный как anycast обязан его очищать.

Это устраняет существенную неоднозначность. Несколько объявлений сами по себе могут быть результатом anycast-дизайна, миграции, временной топологии или ошибки. Флаг делает намерение общей переносимой семантикой. При переобъявлении Extended Prefix Opaque LSA в другую область флаг должен сохраняться; граница области не должна уничтожать это свойство.

Сохранение свойства не создаёт квитанцию о работе услуги.

Между символом и действием есть несколько решений

Сначала существует утверждённая конфигурация и личность управления, которая её записала. Затем — LSAs, реально принятые отдельными маршрутизаторами. Затем каждый ingress выполняет свой SPF-расчёт, применяет фильтры и политику, возможно устанавливая маршрут в FIB. Потом конкретный поток под действием ECMP-хеша, рекурсии и обратного пути достигает одной реплики. И только после этого можно наблюдать, здорова ли реплика, имеет ли верное состояние и выполнила ли нужное приложению действие.

Верность предыдущей стадии не гарантирует следующую. Корректный AC-Flag может не дойти до нужной области. Маршрут может быть в RIB, но локальная политика не пустит его в FIB. FIB может быть установлена, а отдельный ECMP-поток попадёт в выведенную из обслуживания или перегруженную реплику. Транспортная проверка может быть успешной, пока аутентифицированная операция приложения отвергается.

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

Редакционное прочтение идеи Heng Lu о минимальной начальной спецификации помогает не размывать эту границу. В общем слое достаточно общей необходимости: префикс предполагается многонодовым. Порог здоровья, политика распределения, владелец услуги и критерий бизнес-успеха являются локальными решениями. Они требуют локального свидетельства, а не расширенного толкования общего бита.

Конфликт AC/N нельзя нормализовать до зелёного статуса

RFC 9983 запрещает одновременно устанавливать AC-Flag и N-flag из RFC 7684. Получив оба, маршрутизатор обязан считать это аномалией конфигурации, проигнорировать N-flag и должен журналировать конфликт с ограничением частоты.

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

Расширенная видимость не равна операционной власти

Для префикса, объявленного несколькими маршрутизаторами, RFC 9983 считает anycast наличие AC-Flag хотя бы в одном объявлении; одиночное объявление без флага остаётся узлоспецифичным. Документ рекомендует согласованное управление и строгий контроль устаревшей конфигурации, поскольку флаг имеет приоритет при определении свойства.

RFC 9085 позволяет BGP-LS переносить соответствующие флаги префикса. Коллектор тем самым получает хорошую видимость декларации. Он не получает права доказывать, какая FIB была у каждого ingress, какую реплику выбрал ECMP и завершила ли она транзакцию. Совпадение одной исходной декларации в нескольких системах — это копирование, а не независимое подтверждение.

RFC 9983 добавляет записываемые данные anycast-flag к моделям YANG OSPF и управления маршрутизацией из RFC 9129 и RFC 8349. Поэтому управление становится поверхностью контроля: запись меняет утверждение, на которое опираются другие системы. RFC требует защищённый транспорт, взаимную аутентификацию и указывает NACM для ограничения доступа. Если флаг влияет на forwarding или безопасность, должны быть проверяемы автор записи, обзор, версия реализации и правило для конфликтов.

Называть вывод по уровню наблюдения

Для критичного префикса стоит связать утверждённую конфигурацию и её автора, LSAs по областям и конфликты AC/N, расчёт маршрута и FIB в существенных ingress, выбор на плоскости данных, здоровье/ёмкость каждой реплики и результат приложения. Это не означает ожидать все шесть видов данных перед тревогой. Это означает, что «AC-Flag наблюдался» — честный и сильный вывод, а «услуга anycast здорова» требует полной цепи.

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