Кратко

  • Алгоритмы Highest-Preference и Lowest-Preference из RFC 9785 лишь упорядочивают подходящих кандидатов PE; операционная готовность каждого из них является исходным допущением стандарта.
  • Допуск в список кандидатов, настроенное предпочтение, объявленное рабочее значение, результат выборов, запрограммированная пересылка и наблюдаемый клиентом итог — разные факты.
  • Don't Preempt уменьшает риск второго переключения после возврата предпочтительного PE, но может сохранить действующий DF, который уже не является административным фаворитом.

Предпочтение отвечает только на один вопрос

В режиме All-Active Designated Forwarder отправляет Broadcast, Unknown Unicast и Multicast к устройству или сети с несколькими подключениями. В Single-Active к этой ответственности добавляется обычный unicast. Роль определена в RFC 7432, а RFC 8584 задаёт расширяемую процедуру выбора.

RFC 9785 вводит два управляемых оператором порядка. Алгоритм 2 выбирает наибольшее числовое Preference, алгоритм 3 — наименьшее. Двухоктетное поле имеет диапазон от 0 до 65535 и значение по умолчанию 32767. В реестре IANA зафиксированы оба алгоритма и бит D, обозначающий Don't Preempt.

Это даёт реальный рычаг: перед обслуживанием можно понизить ранг текущего DF, а локальная политика может менять его динамически. Но стандарт формулирует границу прямо — ранжирование применяется при условии, что кандидаты уже operationally ready. Значение 500 не является квитанцией о состоянии attachment circuit, установке таблицы пересылки или прохождении кадров до клиента.

Сначала членство в списке, затем место в нём

RFC 8584 описывает не простой числовой тест, а последовательность обнаружения PE, ведения списка кандидатов, ожидания DF_WAIT и расчёта победителя. При включённом AC-DF RFC 9785 не допускает PE к выборам для соответствующего ES и EVI, пока не получены маршруты Ethernet A-D per ES и per EVI.

Такой критерий ограничивает ложную кандидатуру, но остаётся свидетельством контрольной плоскости. Он не показывает завершение программирования FIB, правильность BUM-репликации или отсутствие потерь Single-Active unicast. RFC 7432 учитывает переходный интервал, когда два PE могут считать себя DF одновременно. Split horizon снижает риск петли, но не превращает запись о победителе в сквозное подтверждение.

Требуется и согласованность алгоритма. Если один PE объявляет Highest-Preference, а другой Lowest-Preference, все участники возвращаются к базовому алгоритму RFC 7432. Запись «DF = PE3» без набора алгоритмов, списка кандидатов и признака fallback скрывает причину результата.

Don't Preempt сохраняет срок полномочий

Пусть предпочтительный PE отказал, а следующий кандидат принял роль. Когда прежний DF возвращается, немедленное восстановление исходного порядка создаёт ещё одно изменение в плоскости данных. RFC 9785 допускает нереверсивное поведение, чтобы оставить текущий PE на месте.

После boot- или hold-таймера вернувшийся PE изучает полученные маршруты Ethernet Segment и выбирает опорный PE. Если его настроенное предпочтение вытеснило бы действующего участника, он может объявить унаследованное от опорного участника operational in-use Preference с DP=0. Действующий PE продолжает объявлять DP=1 и выигрывает разрешение равенства.

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

Нереверсивность не гарантирует безопасность сама по себе. Она избегает одного перехода, но может удерживать PE, который больше не подходит по ёмкости, расположению или политике. Отзыв маршрута, отказ опорного PE, явное изменение Preference или конфликт алгоритмов запускают новый расчёт. При несовместимых алгоритмах Don't Preempt не предотвращает возврат к базовой процедуре.

Доступ к конфигурации меняет путь трафика

В разделе безопасности RFC 9785 сказано, что конфигурация получает абсолютный контроль над победителем для Ethernet Tag. Злоумышленник с таким доступом способен изменить Preference и перенаправить ответственность за трафик; намеренный конфликт алгоритмов способен отключить нереверсивное поведение через fallback.

Локальные переопределения по Tag позволяют распределить теги между PE, но обязаны совпадать на всех участниках. Разные представления могут вызвать потери или дубликаты. Поэтому аудит должен связывать автора изменения, административные и in-use значения, DP, алгоритм, членство в кандидатах, победителя для каждого тега, программирование плоскости данных и фактические наблюдения трафика.

RFC 9784 распространяет эти алгоритмы на виртуальные Ethernet Segments, однако границы отказов EVC/ENNI, vESI и групповые withdrawals принадлежат другому механизму. Резервирование источников multicast также находится вне темы этой статьи.

Карточка RFC Editor, IETF Datatracker и не показавший совпадений на момент проверки поиск errata подтверждают состояние документа, но не внедрение и не производительность сети.