Кратко

  • RFC 9625 вводит Supplementary Broadcast Domain без attachment circuits, чтобы интерес из обычного BD достигал PE того же Tenant Domain, даже если эти PE к BD не подключены.
  • PE может объединять IGMP/MLD-состояние нескольких BDs в SBD-SMET; AC без snooping или PE без поддержки RFC 9251 может считаться заинтересованным во всех потоках.
  • Проверяемая эксплуатация разделяет отчёт хоста, политику, сопоставление BD/SBD, агрегацию, импорт, выбор gateway, пригодность OIF для кадра, передачу, дубли и приём.

Состояние было действительным, но его причина уже стала непрозрачной

На удалённых PE существовала корректная SBD-SMET route. Она имела ожидаемые RT и не нарушала правила импорта. Однако по самой строке невозможно было определить, какой порт и какой обычный BD породили интерес, сколько получателей ещё живо и кто разрешил распространить локальный запрос на весь tenant.

Механизм решает нужную задачу. Источник и получатель могут находиться в разных подсетях, а ingress PE должен узнать о приёмнике за PE, с которым у него нет общей обычной BD. Общая SBD переносит интерес и устраняет лишний hairpin.

Но техническая видимость не создаёт полномочия. Полученный Join — наблюдение протокола. Identity, group/source policy, rate, budget и срок действия — отдельное решение до усиления масштаба.

SBD не содержит хостов, зато содержит проекцию

Все OISM PE одной Tenant Domain настраиваются на общую SBD и импортируют её SBD-RT. У SBD нет ACs. Это не дополнительная клиентская LAN, а контекст для источников и получателей, чья фактическая BD отсутствует на данном PE.

Когда реальная source BD не подключена, удалённый PE может считать SBD apparent source BD. Форвардинг сохраняется, а локальная детализация скрывается. Лог с одним значением SBD не восстанавливает обычную BD, EVI, Ethernet segment и порт, где возникла причина.

Сохраняйте пару real BD / projected SBD, Tenant Domain, mapping и epoch. Проекция объясняет охват, но не удостоверяет происхождение или право.

Семантическая проверка маршрута имеет узкий вердикт

IMET, SMET, S-PMSI и Leaf связываются с обычной BD или SBD через Route Targets и иногда Tag ID. Несколько SBD-RTs, RTs двух разных обычных BDs или смесь обычной BD одного tenant с SBD другого считаются ошибкой; принимающий PE применяет RFC 7606 treat-as-withdraw.

Проверка выполняется там, где известна EVPN-семантика, потому что промежуточные BGP-узлы обычно не видят противоречие. Успех доказывает соответствие локальной карте в конкретную эпоху.

Он не доказывает авторизованное назначение RT, право originator расширять интерес или одинаковую карту на остальных PE. Нужны NLRI, RTs, Tag ID, peer, origin, mapping и решение, а не только итог installed.

Слияние экономит маршруты и сжимает причинность

PE объединяет IGMP/MLD-состояние обычных BDs и выводит требуемые SBD-SMET. (*,G) одного BD может охватить (S,G) другого. Широкий маршрут притягивает необходимые потоки и уменьшает control-plane state.

После слияния объявление не обязано показывать первую BD, число оставшихся receivers или Leave, который удалит последнюю причину. Wildcard может оставаться корректным, когда большинство узких оснований уже исчезло.

Храните обратимый derivation ledger: ACs и BDs, Include/Exclude, membership epochs, правило, advertised key и withdrawal condition. Тогда агрегация остаётся оптимизацией, а не фактом без происхождения.

Совместимость превращает незнание в интерес

Если AC не выполняет IGMP/MLD snooping, RFC считает его заинтересованным во всех flows. Если remote PE не сигнализирует RFC 9251, он также предполагается заинтересованным во всём. Это защищает сервис при недостатке селективности.

Однако receiver не был измерен. Одна OIF entry может означать явный Join, другая — невозможность доказать отсутствие интереса. Они создают похожую нагрузку, но различаются уверенностью и сроком.

Помечайте причину: explicit report, static policy, no-snooping default или legacy-peer default. Нельзя выдавать compatibility flooding за measured demand в планировании.

Один BD получает рычаг над ресурсами всего домена

Security Considerations прямо говорит: атакующий с доступом к одному BD может вызвать SMET advertisements и повлиять на ресурсы всех PEs Tenant Domain. Неверные OISM, IPMG, MEG или PEG flags и Extended Communities способны вызвать loss или diversion.

Контроль ставится до SBD-SMET. Проверяйте access identity, group/source, частоту, state limit, wildcard privilege и tenant budget. После публикации измеряйте remote installations и фактический ресурсный эффект.

Завершение тоже распределено. Локальный timeout не доказывает очистку. Нужны recompute, BGP withdrawal, convergence каждого importer и освобождение ресурсов.

Выбор назначает исполнителя, а не доверенного субъекта

Смешанная сеть использует IP Multicast Gateways. Кандидаты объявляют capability, подтверждают присутствие IMET в BD и выбирают одного IPMG-DF по DF-процедуре. MEG и PEG выполняют похожие роли на внешних границах.

Единственный winner предотвращает двойное действие, но не авторизует кандидата. RFC предупреждает, что контролирующий gateway атакующий может повлиять на election и изменить forwarding. Детерминированный результат — факт алгоритма, не доверительный verdict.

Сохраняйте кандидатов, flags, routes, algorithm, preferences, winner, management authorization и epoch. Один неразрешённый победитель тоже является аварией.

OIF list лишь участвует в решении по кадру

Layer 2 выбирает (S,G) или fallback (*,G), определяет apparent source BD и применяет OIF list с учётом способа получения. Список включает ACs, tunnels и IRB, меняется со state и не использует здесь Layer-2 RPF check.

В multihoming требуется eligibility. При ESI label PE должен быть DF и не возвращать кадр на source segment. При local bias remote ingress identity показывает, обслужен ли segment. Внутренний traffic нельзя опускать в SBD IRB, иначе он распределится повторно.

Поэтому list membership не подтверждает transmit. Для кадра нужны selected state, apparent BD, версия OIF, ESI/local-bias inputs, suppressions и фактические выходы. Только так loop prevention отделяется от ошибочного недоставления.

Ограничение anycast разделяет адрес и событие

Если в Tenant Domain есть (*,G) receivers, RFC запрещает внутренние anycast sources для G. OISM распространил бы оба (S,G) flows и мог доставить дубли. Один source address не делает две передачи одним событием.

Проверяйте условие до запуска: source inventory, wildcard state и duplicate observation у receiver. Корректный control plane не доказывает отсутствия несовместимой топологии.

Цепочка квитанций повторяет расширение области

Начните с report, identity, port, AC, обычной BD, EVI, segment, tenant, policy и времени. Затем сохраните membership transition и multi-BD merge с contributors и withdrawal condition. Далее идут SBD-RT, BD-RT, Tag ID, origin, import и gateway elections.

Для данных соедините frame с apparent BD, selected state, OIF, eligibility, tunnel copies, AC transmits и suppression. Receiver arrival, copy count, application consumption и service outcome остаются последующими фактами.

RFC 9625 расширяет область видимости интереса. Квитанции не дают этому расширению незаметно расширить смысл доказательства.

Источники