Кратко

  • RFC 9494 добавляет второе окно хранения для каждой AFI/SAFI, однако объявленное значение LLST ничего не доказывает о сохранности next hop, FIB или самой услуги.
  • Управляемая схема связывает согласованные capabilities с локальным пределом времени, исключениями, выбором и распространением маршрута, пакетными измерениями и однозначным выходом через EoR, истечение таймера либо действие оператора.
  • Даже маршрут с самой низкой предпочтительностью может продолжить пересылку, если он специфичнее свежего агрегата. Поэтому наличие нового пути в BGP не является доказательством восстановления трафика.

Представим диагностический эпизод. Сессия BGP с соседом обрывается. Обычный Graceful Restart заканчивается, но helper оставляет более специфичный префикс ещё на шесть часов. Маршрут помечен stale и переведён в категорию наименьшей предпочтительности. Одновременно от здорового источника приходит свежий агрегат. В таблице есть два ответа, и новый кажется лучше. Но для адресов внутри сохранённого префикса действует longest-prefix match. Пакеты по-прежнему уходят к старому next hop, за которым сервис уже исчез.

Для такого результата не нужен дефект реализации. RFC 9494 специально допускает длительное сохранение, когда control plane восстанавливается медленно или BGP переносит сведения, больше похожие на распределённую конфигурацию, чем на обычную достижимость. Цена той же терпимости — продлённая чёрная дыра, несовместимый выбор или просроченная привязка сервиса.

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

Второе окно наследует первое

RFC 4724 описывает Graceful Restart для BGP. Capability 64 переносит Restart Time и сведения о состоянии по семействам. После разрыва сессии receiving speaker может временно сохранить маршруты перезапускающегося speaker. End-of-RIB обозначает завершение первичного набора обновлений для конкретной пары AFI/SAFI.

Причина reset относится к доказательствам, а не к второстепенным журналам. Согласно RFC 8538, после обмена N bit graceful-процедуры могут применяться к многим NOTIFICATION и к истечению Hold Time. Напротив, Cease с подкодом Hard Reset требует полного прекращения. Запись «neighbor down» без кода, подкода и времени не объясняет, почему старые маршруты сохранились.

RFC 9494 вводит capability 71. Каждая запись включает AFI, SAFI, flags и 24-битное Long-Lived Stale Time. LLST выражается в секундах; универсального значения по умолчанию нет. Обычная IP-достижимость, Route Target constraints, FlowSpec и discovery имеют разные сроки безопасной жизни.

LLGR не является автономным обходом GR. Если capability LLGR получена без capability GR, её следует игнорировать. Механизм использует EoR, конечный автомат и reset-логику обычного GR. Поэтому число 71 в выводе команды не доказывает действующее соглашение: нужны также capability 64, нужная семья, параметры обеих сторон и применённая локальная политика.

Два этапа могут идти последовательно. В период GR сохранённый маршрут не получает понижение лишь из-за GR. После перехода в LLGR он становится least preferred. До восстановления сессии верхняя протокольная граница для одной AFI/SAFI равна полученному Restart Time плюс полученный LLST, но принимающая сторона вправе применить локальные верхние или нижние пределы. Любой из этапов может иметь нулевую длину.

Последнее место в выборе ещё не означает удаление

При входе в LLGR helper запускает таймер для AFI/SAFI, добавляет к оставшимся маршрутам LLGR_STALE, удаляет маршруты с NO_LLGR и применяет правила предпочтения и распространения. Реестры IANA для capability codes и well-known communities фиксируют значения: LLGR_STALE0xFFFF0006, или 65535:6, а NO_LLGR0xFFFF0007, или 65535:7.

RFC 1997 определяет классический атрибут communities. Корректно записанное число не аутентифицирует соседа, не подтверждает право на префикс и не доказывает жизнеспособность маршрута. Это переносимый сигнал для политики, а не аттестат состояния.

LLGR-stale должен проигрывать любому маршруту, который не относится к least preferred. Если все кандидаты находятся в этой категории, между ними снова действуют обычные tie-break rules. Но BGP selection и сопоставление адреса — разные решения. Базовая модель RFC 4271 заканчивается выбранным маршрутом, тогда как пересылка использует наиболее специфичное совпадение. Старый /24 всё ещё способен перехватить адреса у свежего /16. RFC 9494 прямо предупреждает о потере связности в таком случае.

Кроме того, понижение зависит от локального состояния сессии и может различаться у iBGP speakers. При hop-by-hop forwarding два узла способны выбрать несовместимые направления и образовать петлю. RFC 9494 не рекомендует LLGR для таких наборов маршрутов. Это ограничение топологии и согласованности, которое нельзя устранить просто более коротким таймером.

Право маршрута отказаться от долгого хранения

Community NO_LLGR позволяет исключить маршрут из второй фазы. При переходе в LLGR helper должен удалить такой маршрут, а не продлевать его. Но это просьба внутри двусторонней политики. Она не доказывает, что каждый промежуточный узел сохранил или исполнил метку. Аудит должен увидеть community в реальном Adj-RIB-In и результат policy, а не только намерение в шаблоне конфигурации.

LLGR-stale также не следует объявлять соседу, который не рекламировал LLGR. RFC 9494 описывает необязательную процедуру частичного внедрения, но ограничивает её iBGP или confederation и требует NO_EXPORT вместе с LOCAL_PREF ноль. Это не общее разрешение выносить stale reachability во внешнюю BGP. Семантика NO_EXPORT всё равно зависит от корректной передачи community и политики получателя.

Практическое полномочие остаётся у принимающей сети. Отправитель предлагает LLST и набор AFI/SAFI; helper решает, включать ли функцию, каким пределом обрезать время, какие маршруты исключить и куда их передавать. RFC 9494 требует не включать процедуру по умолчанию и настраивать её явно для каждой AFI/SAFI. Чужое capability не должно превращаться в безусловный договор на хранение чужого старого состояния.

Пределы следует связывать с природой данных. Для информации, которая строится часами и меняется редко, длинное окно может быть разумным. Для обычного транзитного префикса next hop способен потерять смысл за секунды. Единая фраза «нам нужна непрерывность» скрывает это различие и противоречит самой причине, по которой стандарт не установил общий LLST.

Зелёная сессия не останавливает старый таймер

Возвращение TCP и состояние Established не обновляют маршруты автоматически. После повторного соединения LLST продолжает идти, пока соответствующая AFI/SAFI не синхронизируется. Синхронизация наступает по EoR либо по истечении GR Selection_Deferral_Timer. Если раньше закончится LLST, helper удаляет все stale-маршруты, которые peer не обновил.

F bit сообщает, было ли состояние данной семьи сохранено во время предыдущего restart. Если новая сессия не содержит AFI/SAFI, нужные capabilities исчезли или соответствующий F bit сброшен, helper обязан немедленно удалить сохранённые маршруты этой семьи. Расследование должно сопоставить согласование до и после сбоя, а не ограничиться строкой «session up».

Таймер LLST не обновляется в период отказа просто потому, что где-то появилось новое capability. Без явного ручного вмешательства его параметры меняются лишь после установления и синхронизации новой сессии. Иначе серия автоматических продлений превращает конечный бюджет в бессрочную аренду.

EoR доказывает завершение начальной эпохи обновлений для семьи, но не доставку пакетов. В этот момент next hop может остаться неразрешимым, FIB — непрограммированной, label — устаревшим, а сервис — недоступным. Завершение control-plane синхронизации не отменяет отдельную data-plane проверку.

Где состояние похоже на конфигурацию

Наиболее убедительный сценарий LLGR связан с дорогим, медленно строящимся state: данными VPN, discovery или ограничениями распространения, а не с обычной hop-by-hop reachability. Однако «конфигурационный» характер не даёт бессрочного иммунитета. Сохранённая запись может указывать на label, encapsulation или сервис, значение которых уже изменилось.

RFC 9494 отдельно предупреждает о повторном использовании MPLS label. Если stale VPN route продолжает ссылаться на label, уже выданный другой VPN, старый маршрут способен направить трафик в новый контекст. Период до повторной выдачи должен превышать максимальное реальное окно stale либо другой механизм обязан исключить смешение. Здесь LLST становится границей изоляции и безопасности, а не только настройкой доступности.

Разрешимость next hop остаётся обязательным условием. BFD в подходящих случаях может дать дополнительный сигнал жизнеспособности, но не превращает timer или community в гарантию. Наблюдение должно соответствовать утверждению: доступность next hop не доказывает исправность приложения, а прикладная проба сама по себе не объясняет путь распространения маршрута.

Наконец, реализации различаются. Документация Cisco 8000 описывает BGP persistence, Juniper — LLGR в Junos, а Nokia — взаимодействие GR и LLGR в SR OS. Их defaults, команды и поддерживаемые семейства не являются требованиями протокола. Любое эксплуатационное утверждение должно быть привязано к конкретной платформе и release.

Доказательства полной stale-эпохи

Цепочка начинается до отказа. Нужно сохранить локальные и удалённые GR/LLGR capabilities, точные AFI/SAFI, Restart Time, LLST, N и F bits, локальные пределы, исключения и export policy. RFC 5492 определяет механизм объявления BGP capabilities, но сообщение об объявлении ещё не говорит, какое значение система фактически приняла.

Во время события фиксируют причину reset, код, подкод и время, вход сначала в GR, затем в LLGR, маршрут на входе, communities после policy, best-path result и распространение. Далее трасса проходит через recursive next hop, RIB, FIB, label или encapsulation state, счётчики пакетов и сервисные пробы. Один снимок подтверждает наличие маршрута, но не его работоспособность на протяжении нескольких часов.

У хранения должен быть наблюдаемый конец: EoR и обновление, истечение LLST с удалением неподтверждённых маршрутов либо ручной clear с владельцем и причиной. После него проверяют исчезновение старой записи из FIB, чистое повторное объявление и успешный пакетный путь. Если команда не может назвать момент, когда старый маршрут потерял полномочие, то у неё нет бюджета времени — есть только надежда.

Источники

  1. RFC 9494 — Long-Lived Graceful Restart for BGP
  2. RFC 4724 — Graceful Restart Mechanism for BGP
  3. RFC 8538 — Notification Message Support for BGP Graceful Restart
  4. RFC 5492 — Capabilities Advertisement with BGP-4
  5. RFC 1997 — BGP Communities Attribute
  6. RFC 4271 — A Border Gateway Protocol 4
  7. IANA — Capability Codes
  8. IANA — BGP Well-known Communities
  9. Cisco — Understanding BGP Persistence
  10. Juniper — Long-Lived Graceful Restart
  11. Nokia — BGP Graceful Restart and Long-Lived Graceful Restart