Summary

  • BGP End-of-RIB сообщает о завершении начального обновления для одного семейства после установления сессии; это не подтверждение актуальности всех AFI/SAFI.
  • Graceful Restart намеренно разрешает сохранять маршруты с отметкой stale, пока пересылка продолжается. Замена, удаление, локальный выбор, FIB и жизнеспособность data plane требуют отдельных доказательств.
  • Для каждой пары peer и address family нужен операционный журнал проверки, связывающий причину рестарта, capability, сохранённые маршруты, EOR, удаление устаревшего состояния, FIB и реальные проверки пути.

Сессия вернулась раньше доказательств

Представим восстановленную после перезапуска BGP-сессию. Приходит EOR для IPv4 unicast, и мониторинг показывает зелёный статус. В то же время второе семейство ещё содержит маршруты старой сессии, а один поток использует запись пересылки, созданную до рестарта.

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

Graceful Restart создан для непрерывности, поэтому такое расширение кажется естественным. Сохранение пересылки уменьшает churn и временные потери. Но оно же создаёт интервал, когда «продолжает пересылать» не равно «проверено заново».

Что действительно закрывает EOR

RFC 4724 определяет IPv4-unicast EOR как UPDATE без достижимой и отозванной NLRI. Для других семейств это сообщение только с MP_UNREACH_NLRI без отозванных маршрутов для конкретного <AFI, SAFI>. Speaker отправляет его после завершения начального обновления семейства, даже если отправлять было нечего.

Область встроена в кодирование. IPv4 EOR ничего не сообщает об IPv6, VPN, EVPN или другом семействе. Даже в своём семействе он лишь говорит, что отправитель завершил предназначенные обновления. Получателю ещё предстоит применить их, заменить stale маршруты, удалить остатки, выполнить локальный выбор и запрограммировать пересылку.

RFC также отделяет EOR от способности сохранять forwarding. Speaker может рекламировать Graceful Restart без единого семейства только ради намерения генерировать EOR и поддерживать перезапускающийся peer. Поэтому capability или маркер не доказывают наличие сохранённого пригодного состояния.

Restart State решает другую задачу координации. Перезапускающийся speaker устанавливает этот бит в новом OPEN, и peer не должен ждать EOR от него, прежде чем снова объявить ему маршруты. После восстановления сессии перезапускающийся speaker откладывает выбор маршрутов для семейства, пока не получит EOR от соответствующих peers или не истечёт Selection_Deferral_Timer. Только после этого он выполняет выбор, обновляет пересылку, удаляет собственную stale информацию и отправляет EOR для семейства. Время EOR без этой последовательности не позволяет отличить окончание обновлений peers от завершения локальной пересылки.

Сохранённые маршруты явно помечены stale

Если получатель теряет сессию peer, который объявил Graceful Restart для семейства, он сохраняет маршруты этого семейства и отмечает их stale. При пересылке он не отличает их от прочей информации. Это намеренная непрерывность, а не заявление об актуальности.

Правила очистки задают часы. Если сессия не вернулась за Restart Time, сохранённые маршруты удаляются. После возврата они также удаляются сразу, если новая capability не включает семейство, не установлен Forwarding State или capability отсутствует. Новые UPDATE заменяют stale маршруты; EOR семейства удаляет всё, что осталось stale.

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

Жизнеспособность forwarding — другое наблюдение

Forwarding State для семейства относится к сохранению пересылки во время рестарта. RFC 4724 связывает его с фактическим сохранением, с оговоркой о конфигурации. Это не пакетный тест. Конкретный механизм определения жизнеспособности peer остаётся вне области RFC; BFD и наблюдение layer 2 приведены лишь как примеры.

Сохранённый next hop может перестать работать, пока маршруты остаются. Локальный FIB может отстать от RIB. Blackhole или loop возможны после возврата сессии и EOR. И наоборот, stale не означает отказ: сохранённая пересылка может выполнять свою задачу.

RFC 8538 расширяет процедуры Graceful Restart при обмене N bit на допустимые NOTIFICATION и истечение Hold Time. Оба speaker действуют как receiving speaker и хранят маршруты друг друга; Hard Reset требует полного сброса. При обмене N bit смягчается правило, удалявшее уже помеченный stale маршрут при последовательных перезапусках; поэтому stale timer становится ключевой границей против бессрочного хранения. Расширение делает этот настраиваемый таймер обязательным, предлагает 180 секунд и предупреждает о долгом или бесконечном хранении.

Источники