Кратко

  • Breizh-IX сообщает о ночной генерации строгих списков префиксов, проверке ROA и учёте настройки PeeringDB «Never via route servers». Авторы RS-API на RIPE 93 добавляют к проверке реестра оценку числа маршрутов и отдельный вопрос о желании клиента участвовать в переобъявлении.
  • PeeringDB называет настройку подсказкой для точки обмена: оператору нужно регулярно читать её и соблюдать. Дата записи в профиле и дата действия политики на сервере могут различаться.

Правильная строка в реестре не выдаёт мандат

Маршрут совпал с набором AS-SET клиента. Для его префикса есть route-объект. Количество объявлений не выглядит странным. Все три наблюдения могут быть полезны сетевому инженеру, но только первые два относятся к данным и размеру списка. Третье — к воле владельца подключения: хочет ли он, чтобы посредник разослал объявление другим участникам обмена?

В официальном описании доклада на RIPE 93 Evann Dreumont и Alarig Le Lay из Breizh-IX формулируют именно такую тройку проверок. IRR должен связывать маршрут с клиентским AS-SET. Число маршрутов должно оставаться разумным, особенно когда вложенный набор затягивает огромную часть глобальной таблицы. Затем нужно установить согласие клиента на переобъявление через маршрутный сервер. Расширение набора может быть безошибочным и при этом ничего не сообщать о последнем решении.

RFC 7947 описывает маршрутный сервер как посредника для многостороннего обмена BGP-информацией. Участнику не приходится заводить отдельную сессию с каждой соседней сетью. Удобство сосредоточивает правило раздачи в одном месте. Ошибочное включение или исключение маршрута действует сразу на круг клиентов сервера. Реестровая запись помогает строить политику приёма; разрешение на раздачу по конкретному каналу требует отдельного источника.

От профиля до работающей конфигурации

Сайт Breizh-IX приводит подробности действующих проверок. Некоммерческая организация из Ренна, работающая силами добровольцев, говорит о ночном построении списков с bgpq4 в строгом режиме: без route-объекта префикс отвергается. Серверы проверяют ROA в RPKI региональных регистратур и атрибут OTC; второй сервер также смотрит ASPA. Организация утверждает, что учитывает поле PeeringDB «Never via route servers». Это описание работы, опубликованное самим оператором. Анонс RS-API не даёт оснований приписывать новому инструменту уже измеренный эффект.

В официальной справке PeeringDB настройка называется info_never_via_route_servers. Её статус — подсказка. Точке обмена следует регулярно получать значение, оценивать его и соблюдать. Участник выражает выбор через профиль. База хранит запись. Оператор переводит её в правило, загружает на сервер и проверяет исходящие объявления. Галочка в профиле не имеет прямого доступа к работающему BGP-процессу.

У каждого этапа свой момент времени. Участник может запретить переобъявление днём, а ночной список IRR будет обновлён позже; частота чтения PeeringDB может быть иной. Проверенные публичные материалы не показывают для каждой перемены Breizh-IX время чтения поля и вступления правила в силу. Здесь нет утверждения о случившемся сбое. Есть требование к доказательству: журнал должен связать действие участника, загрузку данных, версию политики на двух серверах и последующий экспорт маршрута.

Числовая проверка тоже нуждается в авторе. Вложенный AS-SET способен раздуть набор префиксов до размера, которого клиент не планировал. Программа раскроет набор правильно; слишком высокий порог max-prefix пропустит результат. Авторы доклада предлагают RS-API как прослойку для сопоставления существующих инструментов и сведений. В анонсе нет опубликованного кода, числа внедрений или частоты ошибочных решений. Оценивать будущую систему нужно по тому, умеет ли она показать источник раздувания, выбранный предел и порядок отмены неверного правила.

Квитанция на исходящее объявление

Для каждого поколения политики нужна цепочка: версия AS-SET и route-объектов, полученное число префиксов, установленный предел, значение поля PeeringDB и время его получения, версия конфигурации каждого сервера, список адресатов объявления. Отвергнутый маршрут получит понятную причину. Принятый маршрут получит обоснование, почему сервер передал его дальше от имени клиента. Одного зелёного индикатора происхождения для этого мало.

Пробел в опубликованных источниках точен: как RS-API поступит, если настройка недоступна, устарела или противоречит другим данным? Документированное правило по умолчанию и журнал его применения позволят судить о системе предметно. Сегодня проект ставит правильный вопрос. Ответ должен дойти до запущенного сервера.

Источники