Кратко

  • Политика BGP может быть правильной до изменения и после него, но опасной в промежутке. При немедленном исполнении разрешающее действие способно включиться до появления условий, а удалённое правило — остаться отсутствующим после сбоя.
  • Редакция 03 связывает риск перехода с порядком правил, нагрузкой на control plane, атомарной заменой, идемпотентностью и сбоем генератора. Доказательством служат фактически действовавшая политика и наблюдаемый маршрутный delta, а не только ответ об успешном commit.

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

После завершения конфигурация снова выглядела безупречно.

Именно этот невидимый интервал делает редакцию 03 документа Current Options for Securing Global Routing важной. Текст опубликован 2 октября 2026 года как активный Internet-Draft рабочей группы GROW в потоке IETF; предполагаемый статус — Informational, срок действия — до 5 апреля 2027 года. Это не RFC, не окончательный консенсус IETF, не Best Current Practice, не проверка соответствия продукта и не свидетельство инцидента в конкретной сети. Сам проект называет себя современным, неполным и неавторитетным собранием вариантов.

Но он точно формулирует проблему: безопасность политики зависит от способа её вступления в силу.

Незавершённое правило уже может получить полномочия

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

Проект показывает это на route-map. Оператор создаёт новое правило, задаёт action permit, а затем добавляет условие large community. В системе немедленного исполнения permit действует уже после второго шага. Если запись стоит до правила, отвергающего маршруты от upstream, незавершённая запись может принять всё и экспортировать upstream-маршруты peers.

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

Desired policy выражает намерение контроллера. Effective policy на маршрутизаторе определяет, что он принимает и анонсирует сейчас. Во время in-place-редактирования эти состояния расходятся. Источником операционной истины становится второе, даже если первое прошло более тщательный обзор.

Перестановка — это не единое событие

В развёрнутом примере экспортная политика отвергает префиксы, полученные от upstream, затем bogons, затем RPKI Invalid NLRI и принимает оставшееся. Требуется лишь поменять местами bogon- и RPKI-проверки.

Без атомарности перестановка раскладывается на удаление старого bogon-правила, добавление RPKI-правила на свободную позицию, удаление старого RPKI-правила и добавление bogon-правила на новом месте. Между первыми двумя командами bogon способен пройти. Если процесс остановится после удаления, промежуточное состояние перестанет быть кратким и станет рабочим.

Фраза «окно должно быть ничтожным» не является квитанцией. Ограниченный или загруженный control plane может растянуть применение команд. Timeout управляющего клиента не означает rollback на устройстве. Повторная попытка может попасть на уже частично изменённое состояние.

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

Однако атомарность самого переключения нужно доказать для конкретной платформы. Candidate и running datastores вместе с commit в NETCONF иллюстрируют транзакционную модель, но не гарантируют одновременную смену всех маршрутных решений в любом продукте. Различие intended и operational state в NMDA возвращает к правильному вопросу: что действительно действовало и когда?

Порядок правил расходует запас безопасности

Одинаковое итоговое решение можно получить с разной вычислительной ценой. В редакции 03 дан гипотетический peer, который присылает один миллион IPv4 NLRI, хотя разрешённому cone принадлежат лишь 60.

При неудачном порядке политика сначала добавляет две communities, проверяет private AS, bogons и RPKI invalidity и только затем отклоняет маршруты вне cone. В примере это 5 986 500 операций. Если поставить высокоселективную проверку cone первой, остаётся 1 000 300.

Это иллюстративные числа проекта, а не результаты измерения названного оборудования. Реальная стоимость зависит от реализации. Рекомендация рассматривать scalar operations перед tree lookup, list lookup и regular expressions тоже не задаёт универсальную шкалу производительности.

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

Идемпотентность не даёт атомарности

Создавать префиксные фильтры на выделенной системе и развёртывать их только при изменении содержимого — полезная дисциплина. Неизменный результат не вызывает повторной работы на маршрутизаторе.

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

Цепочку доказательств следует разделить. Нужны собственные digests и отметки времени для входных данных генератора, желаемой политики, сгенерированной конфигурации устройства, effective state до изменения, staged validation, ответа активации, effective state после неё и наблюдаемого route delta. Единый статус «deployed» скрывает, какие границы подтверждены.

Сбой генератора сам становится маршрутным решением

Генерация фильтра может завершиться неудачно. Редакция 03 советует выявлять явно неожиданный результат: набор, который резко увеличился, сократился или стал пустым. Универсальный fallback не задаётся, потому что каждый вариант отдаёт разную ценность.

Accept-all сохраняет связность ценой безопасности. Reject-all защищает границу, но может направить слишком много трафика к upstreams и усилить ущерб. Повторное использование старого набора поддерживает стабильность, но накапливает устаревание и начинает ошибочно принимать или отклонять изменившиеся префиксы. Нейтрального программного значения по умолчанию здесь нет.

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

Default reject из RFC 8212 остаётся важным минимумом для eBGP-сессии без политики. Он не доказывает безопасный переход между двумя присутствующими политиками. RPKI origin validation, BGP Roles и OTC дают ценные предикаты, но не делают их установку атомарной транзакцией.