Кратко

  • Отказ сессии LDP не обязательно означает отказ канала данных, а успешное возвращение сессии не означает, что данные продолжали идти. Для управления, сохранённой таблицы и пакетов нужны разные свидетели.
  • Сохранённые привязки действуют лишь временно: они должны получить подтверждение до истечения срока, не столкнуться с новым назначением той же метки и пройти независимую проверку пересылки.

Протокол согласился сам с собой

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

Это не придирка к телеметрии, а граница объекта. Управляющий протокол знает о сообщениях, таймерах и привязках. Аппаратная таблица знает, что было установлено локально. Только наблюдение плоскости данных может показать, что пакет встретил ожидаемую последовательность значений и достиг нужного конца.

RFC 3612 опубликован в сентябре 2003 года как информационный документ потока IETF. Он сравнивает graceful restart из RFC 3478 и fault tolerance из RFC 3479. Это руководство по применимости, а не стандарт результата и не отчёт о конкретной сети. Упомянутая в нём спецификация LDP RFC 3036 позднее была заменена RFC 5036.

Базовая модель связывала потерю TCP-сессии с удалением LSP и освобождением меток. Механизмы восстановления разрешают некоторому состоянию пережить сессию. Это снижает объём повторной работы, но продлевает действие утверждений, источник авторитета которых временно отсутствует.

Четыре состояния вместо одного индикатора

RFC 3612 различает отказ сессии и отказ узла. В первом случае оба LSR продолжают работать, а сессия между ними пропадает. Документ подчёркивает: это не означает отказ канала данных даже при внутриполосном управлении. Во втором узел или компонент LDP перезапускается, хотя аппаратура может сохранить или потерять таблицу пересылки.

Поэтому событие следует разложить на состояние TCP/LDP, состояние процесса управления, наличие конкретных аппаратных записей и фактическое движение пакетов. Каждая строка может измениться отдельно. Защитные пути, защита каналов и туннелей вынесены за рамки RFC 3612; восстановление состояния не является свидетельством fast reroute.

Для отсутствия влияния на трафик оба конца сессии должны по меньшей мере сохранить состояние пересылки. Если его сохранил только один, RFC 3478 помогает позже восстановить таблицы, но трафик в интервале отказа затронут. Объявленная capability, реальное сохранение и непрерывность услуги — три разных утверждения.

Время ожидания не превращает старую запись в истину

RFC 3478 передаёт FT Reconnect Timeout: сколько соседу предлагается держать существующее состояние после потери связи. Recovery Time показывает, как долго перезапущенный LSR готов сохранять пережившее состояние. Ноль означает, что состояние не сохранилось или уже недоступно.

Сохранённые записи помечаются stale. Новые отображения могут их подтвердить; оставшиеся удаляются после таймера. Долгий срок помогает обработать большую LIB и продлевает жизнь ошибке. Короткий ограничивает риск и способен удалить полезную запись до завершения синхронизации.

Реальный бюджет зависит от числа LSP, пропускной способности управления, вычислительной мощности и частоты изменений. Тихая targeted-сессия и discovery-сессия, реагирующая на IGP, не получают одинаковой надёжности от одинакового значения таймера.

RFC 5919 позднее добавил End-of-LIB. Это сообщение помогает отметить конец начальной рекламы меток, но не гарантируется одной лишь смежной capability; при отсутствии сообщения локальный таймер может продолжить работу так, словно оно пришло. Маркер завершает фазу сообщений. Он не доказывает установку на удалённой аппаратуре, согласие других распределителей или доставку пакетов.

ACK подтверждает сохранение, а не итог

RFC 3479 добавляет последовательные номера защищённых операций, ACK, контрольные точки, остановку изменений перед плановым обслуживанием и повтор операций после возвращения TCP. Оба соседа должны участвовать, а реконструированное управление требуется сверять с пересылкой.

ACK можно отправить после надёжной записи сообщения, не ожидая его полной обработки. Сохранённый Label Request ещё не породил Label Mapping. Обработанный Mapping ещё не установлен в аппаратуре. Установленная запись ещё не наблюдалась на пути пакета. Если мониторинг называет все четыре шага «применено», он создаёт вывод, которого протокол не выдавал.

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

Сохранение может увековечить причину отказа

RFC 3612 предупреждает: сохранение неправильного состояния оставляет его неправильным; в крайнем случае именно оно стало причиной сбоя. Механизм может идеально выполнить задачу долговечности и ухудшить качество восстановления.

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

Во время синхронизации возможен прямой конфликт. Upstream продолжает посылать одну FEC со старой меткой, пока downstream назначает тот же номер другой FEC. Два локальных рассказа выглядят последовательными; совместный путь пересылает неверно.

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

Последствие относится к безопасности. Применение метки после сессии, которая её авторизовала, может доставить данные не туда. RFC 3479 рассматривает раннее повторное использование как возможную основу несанкционированной услуги или отказа в обслуживании. Это описание риска, не сообщение о реальном инциденте.

Добавить показания пакета

Проверяемая квитанция начинается с peer, эпохи сессии, класса отказа, capabilities и обоих таймеров. Для каждой сохранённой записи она указывает allocator, пространство, FEC, next hop, признак stale и исход: подтверждена, заменена, отозвана или истекла.

Затем отдельно фиксируются получение, долговечная запись, обработка, установка и наблюдение. Сохраняются checkpoint, повторённые операции, фактический End-of-LIB либо его таймерная замена, а также конфликты новых назначений.

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

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

Источники