Кратко
- Warm Standby подавляет копии на PE рядом с источниками, а Hot Standby переносит их через сеть и дает каждому нижестоящему PE выбрать одну.
- Single Flow Group — настроенное и объявленное объединение, а не проверка нагрузки, последовательности, часов, состояния кодировщика или готовности приложения.
- Акт резервирования должен раздельно фиксировать основание эквивалентности, полномочие фильтрации, активное состояние, BGP, наблюдение получателя, время переключения и откат.
Нулевая величина счетчика дубликатов выглядит как завершенный тест. На деле она подтверждает лишь то, что один конкретный получатель в данный момент пропустил одну копию. Из нее нельзя узнать, одинаковы ли были источники, что увидели другие получатели и где находился разрыв между последним старым и первым новым пакетом.
RFC 9856 опубликован IETF в статусе Standards Track в сентябре 2025 года. Он расширяет multicast-процедуры EVPN из RFC 9251 и RFC 9625 для нескольких источников, которые передают считающийся одинаковым IP-multicast-поток в один домен арендатора. Задача стандарта — не допустить дубликаты на стороне получателей. Это точное сетевое обещание, а не приемка приложения.
SFG сообщает решение, но не принимает его
Single Flow Group может быть задан как (*,G), объединяя все источники для группы G, или как (S,G), где S допускает префикс любой длины. Бит SFG в Multicast Flags Extended Community сообщает это значение в маршруте S-PMSI A-D.
Устройства получают общий способ обозначить, какие пакеты считать резервными копиями. RFC предполагает, что источники отправляют один поток и не работают редкими всплесками, однако не задает сверку номеров последовательности, временных меток, состояния кодека, поколения приложения или актуальности материала. Источник с устаревшим содержимым может быть правильно включен в SFG и правильно выбран сетью.
Поэтому доказательная цепочка начинается с основания эквивалентности: какие источники сравнивались, на какой выборке, каким методом, с какими допусками времени и последовательности и кто со стороны приложения принял результат. SFG переносит это решение в совместимый сетевой формат, но не заменяет его.
Warm Standby принимает решение до переноса копий
При Warm Standby подключенные к резервным источникам PE выбирают один Single Forwarder. Остальные PE отбрасывают пакеты SFG со своих локальных линий. Сам SF пересылает поток только с одной линии; выбор между несколькими локальными линиями остается деталью реализации.
Выбор использует механизм DF из RFC 8584. Предпочтение может назначить нужный PE, а при несовпадении алгоритма или возможностей RFC 9856 выбирает наименьший объявленный IP PE. Это детерминированное решение уровня управления, а не измерение качества потока.
S-PMSI A-D объявляется после первого пакета настроенного SFG и отзывается после прекращения трафика. Рекомендован таймер неактивности без универсального значения. После отказа SF и отзыва маршрута роль получает другой PE. Раннее подавление экономит полосу tenant-сети, но стандарт прямо отмечает более длительное переключение по сравнению с Hot Standby.
RFC не обещает универсальный нулевой ущерб и не ограничивает время переключения. Испытание должно связать выбранную линию, значение таймера, обнаружение сбоя, приход отзыва, новые выборы и первые полезные пакеты у получателей.
Hot Standby распределяет решение по точкам приема
При Hot Standby копии проходят через tenant-сеть. Каждый источник связывается с Ethernet Segment, даже при одном подключении, а пакеты различаются по метке S-ESI. Каждый нижестоящий PE по локальной политике принимает основной S-ESI и отбрасывает остальные.
Резервная копия оказывается ближе к получателю, но расходуются дополнительная полоса и ресурсы управления. Объявление S-PMSI A-D запускается конфигурацией SFG, а не фактом поступления трафика. Наличие маршрута подтверждает настроенное членство, но не полезные пакеты. Опциональный multipoint BFD следит за P-туннелями, а не за кодировщиком, часами или смыслом передачи.
Разные нижестоящие PE могут выбирать разные основные S-ESI. Получатель в одном месте примет источник A, в другом — B, и каждый увидит одну копию. Поэтому единого глобального значения «активный источник» может не существовать.
Отзыв последнего релевантного A-D per-EVI или per-ES меняет выбор. Массовый отзыв общего S-ES способен затронуть несколько tenant-доменов. При исчезновении последнего S-PMSI A-D для SFG снимается RPF-проверка по метке S-ESI. Изменение фильтра требует наблюдения и само по себе не гарантирует непрерывность.
Семь полей операционного акта
Предлагаемый акт не расширяет протокол. Он не позволяет смешать семь разных видов доказательств:
- Основание эквивалентности: tenant, выражение SFG, источники, метод сравнения нагрузки/последовательности/времени, допуски, выборка и ответственный за приложение.
- Полномочие подавления: режим, место решения, идентификатор выборов или политики, версия конфигурации и фактические возможности.
- Активное состояние: SF PE и линия для Warm либо основной S-ESI каждого относящегося к потоку нижестоящего PE для Hot.
- Сигнализация BGP: S-PMSI A-D, A-D per-ES/EVI, RT, бит SFG, приоритет DF, метки ESI/DCB и поколение отзывов в каждой точке решения.
- Наблюдение получателя: принятый источник или метка, счетчики, пропуски, повторы, переупорядочение, актуальность приложения и выборка с минимизацией персональных данных.
- Хронология переключения: отказ, детектор, получение отзыва, смена выбора, последний старый и первый новый пакет, измеренный период потерь или повторов.
- Откат: прежний выбор, обратимая настройка, полномочие восстановить, критерий отмены, срок действия и оставшийся операционный долг.
Это предложение Daniel Kade для эксплуатации, а не поле RFC 9856 и не сертификат IETF. BGP доказывает состояние управления, метка — правило фильтра, выборка — опыт получателей, а проверка приложения — эквивалентность.
Узкий стандарт требует ясной местной ответственности
RFC 9856 не требует реализации обоих режимов. В смешанной инфраструктуре нужно фиксировать реальные возможности каждой точки. Выделение IANA битов SFG и ESI-DCB задает общую лексику, но не доказывает поддержку, настройку, распространение или программирование функции на конкретном устройстве.
Сетевой протокол не должен доказывать содержание приложения. Но его ограниченный предмет нельзя использовать как оправдание отсутствию проверки. Общий минимум определяет классификацию, выборы, сигнализацию и фильтр; местная эксплуатация отвечает за эквивалентность, наблюдение, риск и возврат.
Тогда одна чистая копия становится последним звеном проверяемой цепочки. Источники сопоставлены, полномочия выбора названы, BGP и метки записаны, получатели наблюдались, переход измерен, откат подготовлен. Только такая связь превращает подавление копии в подтвержденное резервирование.
Источники
- RFC 9856 — Multicast Source Redundancy in EVPNs
- RFC 9625 — Optimized Inter-Subnet Multicast in EVPN
- RFC 9251 — EVPN Optimized Ingress Replication
- RFC 8584 — Расширяемые выборы DF в EVPN
- RFC 9572 — Обновления процедур BUM в EVPN
- RFC 9573 — Расширения EVPN multihoming
- RFC 9746 — Фильтрация split-horizon в EVPN
- RFC 9780 — BFD для резервирования multicast-источников
- RFC 7432 — BGP MPLS-Based Ethernet VPN
- Реестр IANA BGP Extended Communities
- Статус RFC 9856
- Поиск errata RFC 9856
- RFC 3935 — Миссия IETF
- Minimum Initial Specification — Lu Heng
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
