Кратко

  • Необязательный транзитивный класс позволяет расширению BGP пройти через устройства, не знающие его семантики. Если такой говорящий принимает и переанонсирует путь, он сохраняет атрибут и ставит Partial; последующая AS не вправе стереть эту отметку.
  • Partial фиксирует неполную семантическую опеку, но не проверяет целостность. Он не называет неосведомлённый узел, не аутентифицирует источник, не подтверждает корректность значения, всеобщую поддержку или согласие с политическим смыслом.
  • RFC 7606 позволяет выбросить атрибут или считать маршруты отозванными, сохранив сессию. Поэтому эксплуатация должна связывать входные и выходные байты, действие при ошибке, RIB, FIB и реальные пакеты.

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

Внешняя структура UPDATE корректна: флаги, тип, длина, значение и IPv4-префикс. Транзит видит границы объекта, но не располагает декодером. Поскольку Optional и Transitive установлены, он принимает путь, сохраняет байты, ставит Partial и анонсирует маршрут получателю.

Там меняется граница полномочий. Получатель знает тип и применяет его внутреннюю грамматику. Значение не соответствует спецификации, поэтому маршрут обрабатывается как отозванный. TCP остаётся открыт, KEEPALIVE приходят, а транзит по-прежнему считает префикс. Исчезает только клиентский путь за получателем.

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

Четыре бита дают четыре разных обещания

Старшие четыре бита Attribute Flags имеют отдельные роли. Optional отделяет расширение от well-known атрибутов, обязательных к распознаванию. Transitive определяет, может ли неизвестный необязательный атрибут пересечь границу BGP. Partial сообщает о неполноте информации в необязательном транзитивном атрибуте. Extended Length лишь выбирает поле длины в один или два октета. Младшие четыре бита зарезервированы.

Well-known атрибут обязан быть понятен; Transitive в нём установлен, но Partial должен быть нулём. Необязательный нетранзитивный атрибут может работать между совместимыми устройствами, однако не знающий его получатель тихо игнорирует объект и не передаёт дальше. Partial там также равен нулю.

Пространство для постепенного развития создаёт необязательный транзитивный класс. RFC 4271 не ожидает знания всех расширений от каждой реализации. Путь с неизвестным атрибутом такого класса следует принять. При переанонсе атрибут идёт вместе с путём, а Partial становится единицей.

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

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

Partial — не оценка доверия

Название легко прочитать как «повреждено», «не проверено» или «малодостоверно». Протокол говорит точнее. Не знающий атрибут говорящий ставит Partial при передаче. Если последующий узел распознаёт тип, но уже видит единицу, сбросить её нельзя. Неисточниковый узел, добавляющий новый атрибут этого класса, также устанавливает бит.

След остаётся как признание: нельзя предполагать непрерывную семантическую опеку от источника. Он не указывает незнающую AS, не перечисляет, кто понимал объект, не сообщает о допустимом изменении и не доказывает право отправителя добавить его.

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

Ценность в скромности. Бит сохраняет признание, что объект пересёк границу без полного владельца смысла. Это основание для расследования и локального правила, а не для автоматического доверия или тотального запрета.

Обновление сдвигает границу знания

«Неизвестный» зависит от реализации, выпуска, AFI/SAFI, активной функции и времени. Одни и те же байты во вторник непрозрачны, в среду разбираются.

Пока тип неизвестен, внутреннее значение не проверяется. После распознавания действуют разрешённые флаги, длина, подструктуры, семантика и действие при ошибке. Значение, которое месяцами проходило сеть, может вызвать attribute discard или treat-as-withdraw на первом декодере либо после обновления существующего узла.

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

Перед обновлением нужен реестр маршрутов с неизвестными атрибутами: код, флаги, длина, хеш значения, сосед, AFI/SAFI, NLRI и Partial. После — какие коды стали известны, какая проверка включилась, какое действие последовало и какие маршруты изменились.

Без реестра потерю назовут «ошибкой ПО». С ним различимы дефект парсера, правильный отказ, чрезмерная изоляция и отправитель, нарушивший контракт атрибута.

Сохранённая сессия не означает сохранённый сервис

Исходная модель ошибок BGP-4 могла сбросить всю сессию из-за одного неправильного атрибута и удалить посторонние корректные маршруты. Необязательные транзитивные атрибуты увеличивали охват: незнающие узлы распространяли непроверенное значение множеству систем, которые его понимали.

RFC 7606 сужает многие ошибки до трёх действий. Session reset остаётся самым сильным. Treat-as-withdraw удаляет маршруты ошибочного UPDATE из Adj-RIB-In и сохраняет сессию. Attribute discard удаляет атрибут и продолжает обработку.

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

Treat-as-withdraw показывает дефект как потерю маршрута, но скрывается от мониторинга сессий. Сосед Established, Hold Timer в норме, KEEPALIVE идут. Ни один признак не доказывает присутствие NLRI.

Если Optional или Transitive противоречит спецификации известного атрибута, RFC 7606 обычно требует treat-as-withdraw, если собственная спецификация не задаёт иное. Дубликат MP_REACH_NLRI или MP_UNREACH_NLRI означает treat-as-withdraw для всех маршрутов в UPDATE при сохранении сессии; для большинства других атрибутов последующие экземпляры выбрасываются. При нескольких ошибках выбирается самое сильное действие.

Поэтому «поддержка RFC 7606» не является доказательством результата. Нужны реальная классификация, правило атрибута и итоговый набор маршрутов. Реализация может правильно спасти сессию и серьёзно нарушить сервис.

Локальная сеть сохраняет право на изоляцию

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

Текущая документация Juniper показывает два разных решения: удалить неизвестные необязательные транзитивные атрибуты, сохранив маршрут, либо снять маршруты, несущие их. Можно исключить отдельные коды и задать область глобально, по группе или соседу. Readback показывает отброшенные атрибуты и причины снятия.

Это локальные возможности, не всеобщий закон BGP. Удаление атрибута может сохранить пакеты, стерев нужный смысл. Снятие всех маршрутов с новым кодом превращает постепенное внедрение в недоступность. Слишком широкое исключение возвращает исходный риск.

Правильный вопрос: какой код пересекает какую связь и AFI/SAFI, после какого доказательства, с каким действием при неопределённости? Для клиента, route server, внутреннего рефлектора, peer и лаборатории ответы могут отличаться.

Документация Cisco NX-OS показывает нужную детализацию: список префиксов с неизвестными или отброшенными атрибутами и флаги, тип, длина, значение конкретного пути. Общий счётчик не отличит безопасный опыт от дефектного объекта на сотнях тысяч маршрутов.

Передача — это хранение, а не согласие

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

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

Неизвестное не обязательно враждебно, а назначенный IANA код не обязательно безопасен. Реестр даёт стабильную идентичность, но не подтверждает корректность отправителя или отсутствие ошибок ресурсов, парсинга и логики.

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

Доказательство должно хранить хеши входных и выходных байтов, а не только CLI. Вывод может нормализовать флаги, сокращать значения или опускать атрибут. Сырой UPDATE вместе с pre- и post-policy Adj-RIB показывает сохранение, изменение или удаление.

Канарейка должна сделать незнание наблюдаемым

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

Сохраняются четыре этапа: исходный UPDATE с точными байтами; незнающий hop с Partial до и после и выходным анонсом; знающий hop с версией декодера, проверкой, действием и Adj-RIB-In; плоскость данных с выбранным маршрутом, FIB и пакетами.

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

Затем прежний незнающий узел обновляется, а тот же UPDATE повторяется. Изменение результата может быть правильным. Эта репетиция показывает главное: распознавание переносит границу проверки.

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

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