Кратко

  • RFC 9786 переносит выбор DF с отдельных Ethernet Tag на порт ES целиком, но не проверяет здоровье всех собранных на нём сервисов.
  • Port Mode требует единогласия по алгоритму и bitmap возможностей; одна отличающаяся PE способна вернуть весь ES к процедуре по умолчанию.
  • LACP, ARP/ND, MAC, VRF, объявления P/B, FIB, пакеты и подтверждение клиента относятся к разным слоям доказательств.

Одна команда для нескольких плоскостей

RFC 9786 задаёт интерфейсный active/standby для EVPN multihoming. Вместо выбора по [ES, Ethernet Tag], знакомого по RFC 7432, из расчёта исключается Tag. Одна PE держит access-порт активным, остальные — резервными. Все L2, VPWS, L3 и IRB-сервисы на интерфейсе следуют одному решению.

CE сохраняет единый LAG, а PEs должны показывать одинаковые LACP system ID, port priority и port key. Детерминированный путь полезен для QoS. Механизм не зависит от MPLS, VXLAN или SRv6 и не требует ICCP либо LDP.

Такая агрегация делает простым управление, но не область отказа. DF обязан держать порт up и forwarding; non-DF должны двусторонне блокировать все VLAN и могут оставить порт down либо LACP Out of Sync. Запись о DF сообщает победителя вычисления. Она не измеряет, выполнены ли эти требования.

Общий bitmap — это согласие о процедуре

В реестре IANA BGP Extended Communities бит 5 закреплён за Port Mode DF Election. При P=1 Modulo и HRW работают на уровне ES без Ethernet Tag. Preference из RFC 9785 может ранжировать порты, а Don’t Preempt — сохранить действующий DF после возврата предпочтительной PE.

RFC 8584 требует совпадения алгоритма и полного bitmap во всех полученных ES Route Type 4. Отсутствующая, повторная или отличающаяся community означает Algorithm 0 без возможностей. RFC 9786 называет это unanimity.

Поэтому локальная ошибка становится изменением режима всего ES. Изменение одной PE может вызвать fallback у всех участников; среди возможных последствий RFC называет несправедливое распределение, перерыв, потерю и дублирование. Проверять нужно набор объявлений каждого участника, а не только локальную конфигурацию.

Даже идеальное единогласие доказывает лишь выбор правила. Оно ничего не говорит о стабильности линка, LACP partner, collecting/distributing, adjacency, VRF или FIB. DF — вывод контрольной плоскости, а не акт приёмки данных.

У резервного порта нет одной температуры

Standby может быть operational down и при переключении ждать подъёма и стабилизации. RFC 9786 рекомендует заранее синхронизировать ARP и Neighbor Discovery для IRB/L3, возможно VRF-таблицы, а для L2 — MAC-таблицы. Выбор DF такую передачу не выполняет.

LACP Out of Sync создаёт warm standby и сокращает часть задержки запуска. Но OOS не доказывает свежесть соседей, MAC, FIB или удалённого пути. И наоборот: синхронизированная таблица не означает, что CE выбрал member и начал collecting/distributing. Каждый сигнал отвечает только на свой вопрос.

Биты Primary и Backup описывают ещё один участок. RFC 8214 определяет L2-Attr Extended Community; RFC 9786 рекомендует в Ethernet A-D per-ES только P или B. Родительское per-ES P/B должно перекрывать per-EVI. Это ускоряет удалённый выбор пути, но не является наблюдением прошедшего пакета.

Старые реализации RFC 7432/RFC 8214 игнорируют per-ES L2-Attr и продолжают стандартный path resolution, видя Single-Active через ESI Label. В смешанном ES разные устройства могут принимать решение по разным данным. Совместимость требует инвентаризации и фактической трассы объявлений.

Неизменный DF не означает исправный EVI

Port Mode исключает AC-DF: при P=1 A должен быть нулём, а полученный A=1 игнорируется. Отказ sub-interface и withdrawal Ethernet A-D per-EVI не меняет портовый выбор. Это намеренная изоляция. Одновременно она показывает, почему постоянный DF не является индикатором здоровья сервиса.

Нужны две связанные картины. Портовая содержит ESI, участников, алгоритм, bitmap, timers, DF/BDF, LACP и per-ES P/B. Сервисная содержит VLAN/EVI/VPWS/VRF, ARP/ND, MAC, FIB, adjacency, счётчики, удалённую достижимость и клиентские probes. Первая определяет полномочие, вторая доказывает эффект.

RFC 9722 выравнивает окна активации и уменьшает отдельные переходные риски, но не измеряет приложение. RFC 9784 посвящён vES, границе EVC/ENNI и групповым withdrawals; RFC 9785 — предпочтению. RFC 9786 использует эти элементы для другого объекта управления и не наследует от них гарантию готовности.

Запись RFC Editor, IETF Datatracker и поиск errata подтверждают статус документа. В снимке от 11 сентября 2026 года соответствующих errata не было. Это не доказывает реализацию, внедрение, время сходимости или SLA.