Кратко

  • RFC 5291 позволяет получателю отправить типизированные Outbound Route Filters, которые сосед может применить дополнительно к локальной экспортной политике и не создавать UPDATE, всё равно отбрасываемые получателем.
  • ADD, REMOVE и REMOVE-ALL меняют лишь переданное peer состояние на срок данной сессии; PERMIT и DENY выражают предпочтение. Они не удаляют локальные фильтры отправителя, который вправе не выполнить просьбу.
  • IMMEDIATE применяет изменение и запускает переобъявление; DEFER только сохраняет его до commit. Доказательство проходит источник, кодирование, received ORF, local export, Adj-RIB-Out, UPDATE и RIB получателя и строится заново после каждой сессии.

Первый отчёт выглядит убедительно: у клиента остаются сотни маршрутов вместо почти миллиона, снижаются память и CPU. Команда пишет, что провайдер уже передаёт только сокращённый feed.

Обычный inbound prefix-list создаёт тот же экран, даже если провайдер отправляет всё. Клиент доказал свой отказ, а не экономию соседа. ORF позволяет остановить работу раньше, но эффект доказывается только с обеих сторон.

Предпочтение движется навстречу маршрутам

Обычно отправитель строит peer-specific Adj-RIB-Out из Loc-RIB и локальной outbound policy. Получатель применяет inbound policy. Каждая сеть сохраняет собственную границу.

ORF добавляет ограниченный обратный сигнал. Получатель посылает entries, которые отправитель может включить в фильтр, предназначенный именно этому получателю. Маршруты идут от провайдера к клиенту, просьба о меньшем количестве — обратно.

RFC 5291 задаёт композицию. Полученный ORF действует вместе с локальными фильтрами. Клиент может попросить меньше, но не снять защиту, коммерческое правило или ограничение раскрытия провайдера. REMOVE-ALL удаляет entries указанного received ORF, а не всю outbound policy.

Entries выражают local preference, которую peer может не соблюдать. Capability создаёт интерфейс координации, а не право удалённого исполнения. Получатель сохраняет inbound-защиту и наблюдает реальный feed.

Capability — пересечение семейства, типа и направления

Код 3 объявляется в OPEN вместе с AFI/SAFI, ORF type и Send/Receive. Единого флага «ORF включён» нет.

Работает только точное пересечение. Если клиент хочет посылать Address Prefix ORF для IPv4, а провайдер принимает тип лишь для IPv6, IPv4 не покрыт. Умение отправлять не доказывает приём; одна семья не доказывает другую.

Пересечение влияет на старт. При непустом наборе RFC 5291 рекомендует будущему отправителю дождаться квалифицирующего Route Refresh: plain либо с entries и IMMEDIATE. Получатель может установить просьбу до первой большой таблицы.

При пустом пересечении действуют обычные процедуры. Одна Established-сессия может ждать в IPv4 и сразу говорить в IPv6. Зелёный статус скрывает type, direction и first commit.

Нужно хранить фактически обменённые OPEN по session epoch. Конфигурация — намерение; negotiated intersection — исполняемый интерфейс.

Локальный список и состояние соседа — разные объекты

Entry содержит AFI/SAFI, type, action, match и type-specific value. ADD устанавливает, REMOVE удаляет entry, REMOVE-ALL очищает ORF. PERMIT просит пропускать совпадения, DENY — не пропускать.

RFC 5292 определяет Address Prefix ORF через Sequence, Prefix, Length, Minlen и Maxlen. Он выражает точный префикс и диапазоны more-specific, а Sequence задаёт порядок.

Редактируемый файл, локальная компиляция, bytes Route Refresh и декодированный peer state — четыре идентичности. Генератор может перепутать sequence, потерять deny, выбрать неверный AFI или послать старую версию. Хэш источника не доказывает конец цепочки.

Canary включает exact permit, more-specific внутри диапазона, один за Maxlen, explicit deny и маршрут, который блокируется локальным export независимо от ORF.

При нескольких непустых типах маршрут проходит каждый. PERMIT вместе с DENY даёт DENY. Панель одного prefix ORF может завысить effective feed.

DEFER записывает, IMMEDIATE меняет видимый набор

Мутации используют Route Refresh с транзакционным выбором. IMMEDIATE обрабатывает entries и переобъявляет затронутые маршруты. Отправитель обязан отправить затронутые и может добавить остальные.

DEFER сохраняет изменение без немедленного изменения feed. Последующий plain refresh или ORF с IMMEDIATE выполняет commit. Если изменилась и local policy, требующая полного переобъявления, применяется DEFER, затем plain refresh.

Разделение позволяет подготовить согласованную версию. Но обе стороны могут показывать новые entries, пока старый Adj-RIB-Out остаётся эффективным.

Каждый DEFER получает ID, expected hash, владельца, commit, срок и rollback. Просроченный pending state — незавершённая транзакция.

Plain Route Refresh не очищает ORF; он переобъявляет с учётом ранее полученного. Enhanced Route Refresh отмечает границы обмена, но не заменяет запись мутации.

Удаление просьбы не удаляет локальный запрет

Удаление remote DENY может расширить feed; удаление последнего entry убирает ORF. Расширение ограничено local outbound policy и решением отправителя.

Rollback асимметричен. Клиент восстанавливает, очищает или перестаёт договариваться. Ничто не должно ослабить правила провайдера. ORF клиента как единственный барьер означает смешение эффективности с авторизацией.

Получатель сохраняет inbound filter. Peer может игнорировать, потерять state или согласовать другой type. Оптимизация не заменяет admission control.

Неизвестное значение может удалить весь прежний ORF

Несогласованные type или family игнорируются. REMOVE отсутствующего entry тоже игнорируется.

Но неизвестное поле в выбранном ORF ведёт к удалению всего ранее полученного ORF данного типа. Это исключает полуинтерпретированный фильтр, но feed может расшириться до local boundary.

Ветка тестируется на изолированном peer. Заранее прогнозируется удаление message, entry или ORF, затем проверяется Adj-RIB-Out. Parser log не доказывает маршрутный эффект.

Частота, количество и область мутаций ограничиваются. Компрометированный получатель вызывает расчёты и re-advertisement; отправитель может симулировать соблюдение. Неограниченная автоматизация становится поверхностью истощения.

Сессия задаёт срок жизни

ORF существует только в сессии обмена. При её завершении peer-provided state исчезает. Screenshot до reset не доказывает новую epoch.

Новая сессия повторно согласует capabilities и при необходимости ждёт first qualifying refresh. Race, потерянный initial request или иной intersection меняют feed без изменения файла.

Session epoch связывает OPEN, первый ORF/plain refresh, received entries, activation и первый Adj-RIB-Out. Маршруты до ожидаемой просьбы — наблюдаемая аномалия.

Reset очищает state, но затрагивает всё соседство. Нормальный rollback — наблюдаемая обратная мутация; reconnect допустим при полной модели реконструкции.

Двусторонний canary доказывает сэкономленную работу

Начинают с малого peer и одной семьи. Baseline измеряет outbound candidates, UPDATEs, remote input и local rejects.

После negotiation до первого feed отправляют узкий IMMEDIATE с permit и deny. Отправитель проверяет decoded entries и local export intersection. Adj-RIB-Out, wire и receiver доказывают, что исключённое вообще не отправлялось.

Вторая версия использует DEFER: stored state меняется, feed нет. Plain refresh выполняет commit и сравнивается exact delta. Отдельно тестируются REMOVE, отсутствующий REMOVE, REMOVE-ALL и last-entry removal.

Наконец reset доказывает исчезновение старого state и реконструкцию через capability и first refresh. Процедура повторяется для каждого AFI/SAFI.

Приёмка — не “ORF enabled”. Это журнал работы и полномочий: какие UPDATE не созданы, какие local rules сохранили запрет раскрытия, какая точная просьба дала delta и что увидел получатель.

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