Кратко

  • RFC 9784 даёт каждому виртуальному Ethernet Segment собственный vESI и требует независимого наблюдения за EVC: общий порт ещё не означает общий отказ.
  • Отказ одного EVC должен затронуть связанный vES или сервис; лишь подтверждённый отказ ENNI позволяет групповым отзывом охватить все действительно связанные vES.
  • BGP withdrawal — управляющее сообщение, а не доказательство правильного диагноза, актуального состава группы, завершённых выборов DF, очистки MAC или восстановления трафика.

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

Именно эту проблему власти решает RFC 9784. Документ расширяет модель Ethernet Segment для EVPN и PBB-EVPN, но его практический смысл шире синтаксиса маршрутов: наблюдение на логическом уровне не получает полномочия физического уровня только из-за общего оборудования.

При настоящем отказе ENNI ситуация обратная. Тысячи vES одновременно теряют один путь, а ожидание тысяч отдельных withdrawal замедляет восстановление. Тогда группе нужен один ранний сигнал. Безопасность определяется способностью различить эти два случая.

Агрегация не отменяет идентичность

В исходной модели EVPN Ethernet Segment состоит из физических линий между клиентской площадкой и PE. RFC 9784 позволяет строить виртуальный сегмент из EVC, групп EVC, псевдопроводов или LSP. На одном ENNI оказываются single-homed, Single-Active и All-Active сервисы разных клиентов и доменов.

Каждый vES обязан иметь собственный vESI. Выборы Designated Forwarder выполняются для пары (vESI, Ethernet Tag), где VID или I-SID задаёт сервисный контекст. Эта идентичность определяет, какая группа резервирования вправе реагировать.

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

Масштаб датчика должен соответствовать масштабу действия

Каждый EVC следует контролировать отдельно. При отказе одного EVC среди множества на ENNI RFC требует выборов DF для связанного vES. В журнале должны остаться датчик, время, объект и существовавшая тогда цепочка EVC–vESI–service instance–redundancy group.

Состояние up порта не доказывает здоровье EVC. Состояние down EVC не доказывает смерть порта. Полномочие действию даёт связь объектов, а не цвет одной лампы.

Отказ или восстановление EVC в single-homed либо All-Active vES не должны влиять на другие EVC. В Single-Active воздействие ограничено своим сервисом; очистка C-MAC — соответствующим I-SID и адресами нужной multihomed сети.

Поэтому проверка включает отрицательный результат: соседние здоровые сервисы не изменились. На плотно заполненном порту это один из главных показателей корректности.

Портовая очистка способна создать аварию

В PBB-EVPN один B-MAC может представлять много сервисов физического порта. Если процедуру MAC Mobility для физического сегмента применить к одному EVC, удалённые PE могут очистить C-MAC всех EVC порта. Исправные услуги теряют выученные адреса, и восстановление расширяет инцидент.

RFC 9784 использует маршрут B-MAC/I-SID из RFC 9541, чтобы сузить приказ. Получатель очищает C-MAC указанного B-MAC только в указанном I-SID. Для EVC с несколькими VLAN и I-SID может понадобиться несколько сообщений; при большом наборе разумнее отдельный B-MAC на vES и его отзыв.

Слова не задают правильный размер. Один EVC может включать несколько broadcast domain, а один порт — тысячи EVC. Границу определяет проверенная на тот момент инвентарная связь.

Реальный отказ ENNI можно сжать в групповой сигнал

Если отказал сам порт, все связанные с ним EVC теряют путь. Route coloring заранее отмечает эту принадлежность: PE добавляет к маршрутам vES цвет физического порта, обычно его MAC через EVPN Router’s MAC Extended Community из RFC 9135. Получатели ведут список vES для каждого цвета.

Специальный Grouping Ethernet A-D per ES route или Grouping B-MAC route в PBB-EVPN представляет весь набор. Его приоритетный отзыв позволяет начать выборы DF и failover для известных участников. Затем отдельные vES withdrawals очищают таблицы BGP и не должны повторно запускать те же выборы.

Цвет не является датчиком. Он доказывает объявленную связь. Групповой маршрут доказывает объявленный набор. Отзыв доказывает заявление отправителя. Ни один из них отдельно не подтверждает физическую причину, одинаковый свежий список у получателей или результат передачи данных.

Минимальная общая спецификация оставляет будущее решение локальным. Каждый PE применяет своё состояние, проводит выборы и меняет forwarding. Координационный идентификатор не наследует право объявлять последующий результат.

Порядок сообщений входит в доказательство

Групповой и индивидуальные отзывы выполняют разную работу. Первый быстро запускает действие по заранее собранному membership. Вторые удаляют конкретные routes. Финальная пустая таблица не покажет, сработал ли ранний failover, возникли ли повторные выборы или устаревшая группа задела чужой vES.

Возврат сервиса тоже состоит из этапов. Advertisement делает путь допустимым. DF election назначает роль. MAC update меняет локальную достижимость. Лишь наблюдение data plane показывает прохождение кадров и отсутствие ущерба соседям.

Оператору нужны отдельные записи: датчик и объект, карта EVC–vESI–service–color, membership на каждом PE, причина выбора индивидуальной или групповой реакции, порядок BGP, результат DF, операция MAC, изменение forwarding, тест клиента и состояние неповреждённых услуг. Фраза «EVPN сошёлся» — вывод, а не первичное свидетельство.

Общая инфраструктура требует более узких полномочий

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

Примат работающего кода разделяет уровни. RFC доказывает публикацию процедуры; конфигурация — намерение применить; BGP trace — обмен сообщениями; состояние устройства — локальное действие; traffic record — сервисный эффект. Ранний уровень не может говорить голосом следующего.

Достижение RFC 9784 — не только быстрая конвергенция. Скорость подчиняется доказанному масштабу. Отказ канала остаётся отказом канала. Отказ порта может получить групповое выражение. Но групповой withdrawal всё равно не становится доказательством восстановления.

Источники

  1. RFC 9784 — Virtual Ethernet Segments для EVPN и PBB-EVPN
  2. RFC 7432 — BGP MPLS-Based Ethernet VPN
  3. RFC 7623 — Provider Backbone Bridging вместе с EVPN
  4. RFC 8214 — Поддержка VPWS в EVPN
  5. RFC 8584 — Расширяемые выборы DF в EVPN
  6. RFC 7023 — Управление отказами Ethernet-соединений
  7. RFC 9135 — Интегрированная маршрутизация и коммутация в EVPN
  8. RFC 9541 — Маршруты B-MAC и B-MAC/I-SID для PBB-EVPN
  9. Lu Heng — Примат работающего кода
  10. Lu Heng — Минимальная начальная спецификация и локальное будущее решение
  11. Lu Heng — Слои реальности, символическая власть и ясность