Кратко
- RFC 2918 позволяет запросить текущий Adj-RIB-Out способного peer для согласованного AFI/SAFI; его export policy сохраняет власть.
- RFC 7313 ограничивает повтор BoRR и EoRR, помечает старое stale, заменяет вернувшееся и удаляет отсутствующее в конце.
- Успешная команда и стабильная сессия не доказывают эффект: сравниваются prefix, attribute, выбор, FIB и трафик.
Оператор исправляет inbound filter, ошибочно отклонявший двести разрешённых prefix. Commit принят, но отброшенные объявления сами не вернутся. Без сырой копии новому правилу нечего оценивать.
Более строгая policy имеет ту же проблему: ранее принятые routes могут остаться в RIB. Репозиторий уже новый, а работающий выбор старый.
Inbound soft reconfiguration хранила все updates без изменений, включая отклонённые. Она давала локальную независимость ценой постоянной memory и CPU.
RFC 2918 переносит место хранения. Capability code 2 сообщает способность принять ROUTE-REFRESH. Requester отправляет его лишь после получения capability от peer и указывает согласованный AFI/SAFI.
Peer повторно объявляет текущий Adj-RIB-Out по своей outbound policy. Запрашивающий не читает удалённую database и не принуждает к отфильтрованной route. Он снова слышит то, что сосед экспортирует сегодня.
Это не исторический архив. Старая route могла исчезнуть, attributes и remote policy измениться, новая — появиться. Итог пересекает два текущих состояния.
Поэтому count не объясняет причину. Минус пятьсот routes может быть новым local filter, remote withdraw или другим export. Нужны exact sets, attributes и время.
Базовый RFC 2918 не отмечал начало и конец полного повтора. Обычные UPDATE смешивались, и временное отсутствие не отличало удалённую route от ещё не пришедшей.
RFC 7313 вводит Enhanced Route Refresh code 70. BoRR открывает эпоху, EoRR закрывает. После BoRR получатель помечает routes peer для AFI/SAFI stale. Вернувшиеся заменяют записи; EoRR удаляет остаток.
Поток остаётся живым. Изменения во время цикла объявляются. EoRR подтверждает завершение эпохи, но не истинность routes и не восстановление прошлого.
Получатель может задать локальный предел stale retention и очистить без бесконечного ожидания. Слишком короткий timer удалит здоровые routes при медленном replay.
EoRR отличается от End-of-RIB в Graceful Restart. Один закрывает повтор, другой координирует continuity при control-plane restart. RFC 7313 разделяет их ради безопасной очистки.
Inbound и outbound soft reset имеют разных владельцев state. Первый просит remote replay или использует local copy; второй регенерирует собственные объявления. Общее слово скрывает зависимость.
Документация Cisco показывает три пути: динамический request с capability, локальная сохранённая копия или hard reset при отсутствии обоих. Последний уничтожает session и затрагивает всю reachability.
Выбор меняет ресурс на зависимость. Raw storage покупает автономию памятью. Route Refresh экономит её, но зависит от peer и текущего export. Hard reset увеличивает blast radius.
FRRouting отмечает, что некоторым controls нужны rejected routes, например отдельным режимам maximum-prefix. Повтор текущего feed не создаёт исторический inventory для любой задачи.
RFC 5291 задаёт ORF как отдельную capability. Receiver может передать фильтры sender, но обычный ROUTE-REFRESH не редактирует remote policy.
Доказательство начинается до изменения. Запишите advertised и received basic/enhanced capability по направлениям и AFI/SAFI. Local support не доказывает ответ peer; basic не доказывает BoRR/EoRR.
Baseline включает exact prefix/attribute, accepted set, best paths, policy version, uptime и FIB next hop. Невидимые rejected routes — явный пробел.
Начинайте с одного peer и family. Записывайте request, BoRR, EoRR и длительность. Следите за missing end, stale timeout, CPU, reset, withdraw и best-path change.
Сравнивайте множества. Десять удалений и десять добавлений сохраняют count. Aggregate и more-specifics меняют объём. Attribute меняет результат при том же NLRI.
Проверьте forwarding. Accepted route может проиграть, next hop не разрешиться, link оказаться мал. Refresh даёт input, не пакетную гарантию.
Rollback также требует replay. Старый файл не возвращает решения автоматически. При изменившемся remote export точный исходный snapshot может быть невоспроизводим.
Automation ограничивает concurrency. Массовые requests создают UPDATE и расчёты. Soft означает отсутствие намеренного teardown, а не отсутствие работы.
Минимальная спецификация Heng Lu проявляется в малом объекте: peer, family, request. Каждый AS сохраняет policy. Running-code primacy требует capability, наблюдаемую эпоху, RIB diff и FIB вместо сообщения успеха.
Route Refresh отделяет исправление policy от разрушения session, но не от доказательства. Только вернувшиеся, переоценённые и видимые в forwarding routes показывают практическую власть нового правила.
Sources
- RFC 2918: Route Refresh Capability
- RFC 7313: Enhanced Route Refresh
- RFC 4271: BGP-4
- RFC 5291: Outbound Route Filtering
- RFC 4724: Graceful Restart
- Cisco: Dynamic Inbound Soft Reset
- Cisco IOS XR: Soft Clear
- FRRouting: документация BGP
- Heng Lu: Running-Code Primacy
- Heng Lu: Minimum Initial Specification
- Heng Lu: Data Sovereignty
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
