Кратко

  • Join Attribute Option в PIM Hello по RFC 5384 подтверждает готовность принять Encoded-Source Address типа 1, но не знание всех типов атрибутов внутри него.
  • При конфликте значений одного типа от разных нижестоящих смежностей общая процедура выбирает численно меньший IP-адрес, если спецификация атрибута не установила иное. Для IPv6 берётся link-local address, а равенство адресов разрешает индекс интерфейса. Это детерминированное состояние, а не свидетельство полномочия, смысла или доставки.

Авария меняет победителя, а не создаёт новое разрешение

Представим журнал инцидента. До сбоя активен атрибут от смежности A. Смежность B всё это время передавала другой набор для того же дерева, но проигрывала общей процедуре. Когда A истекает, маршрутизатор немедленно делает эффективным сохранённый набор B. Трафик может продолжаться, а управляющее требование меняется.

RFC 5384 позволяет помнить проигравшие наборы именно ради быстрой сходимости. Победитель определяется адресом: численно меньшая PIM-смежность имеет приоритет; в IPv6 сравнивается link-local address; при одинаковых адресах используется индекс интерфейса. Если тип атрибута определяет специальную процедуру, применяется она.

Ни один из этих числовых признаков не является бизнес-мандатом. Меньший адрес не предъявил владельца услуги, согласованный change request или более безопасную топологию. Он оказался раньше в стабильном порядке.

Поэтому послесобытийная запись только активного значения недостаточна. Она покажет смену состояния, но не покажет, что новый «победитель» существовал до отказа и был подавлен. Быстрое восстановление может скрыть смену политики.

Способность прочесть контейнер не равна знанию атрибута

PIM Join задаёт дерево через Encoded-Source Address в контексте Encoded-Group Address. RFC 5384 назначает encoding type 1, чтобы добавить к дереву TLV-атрибуты. В типе 1 должен быть хотя бы один атрибут; отсутствие атрибутов кодируется типом 0.

Маршрутизатор не должен отправлять type 1 через интерфейс, если хотя бы один PIM-сосед не объявил Join Attribute Option в Hello. Это касается не только upstream: другим соседям нужен парсер для подавления или переопределения Join.

Заявление узкое. Устройство с этой опцией не обязано понимать каждый возможный тип. Общей Hello-опции для каждого типа нет. Следовательно, доказана готовность встретить контейнер type 1, но не единая семантика его содержимого.

RFC 6420 вводит для MT-ID собственную capability, проверку и разрешение конфликтов. RFC 6807 делает отдельное объявление для Population Count. RFC 7887 позволяет кодировать общие значения на уровне сообщения, группы или источника, не меняя значения атрибутов. Эти документы добавляют именно то, чего нет в общем конверте.

В акте приёмки следует раздельно указывать парсер type 1, конкретные поддержанные типы, версию, интерфейсы и локальные правила. Строка «PIM Join Attributes supported» не подтверждает совместимость нужной функции.

Неизвестный тип может пройти дальше

F-bit определяет поведение при незнакомом типе. F=1 означает transitive: атрибут требуется переслать. F=0 означает non-transitive: атрибут требуется отбросить. Остальные продолжают обрабатываться; если ничего не осталось, вверх уходит Join типа 0.

Сохранение TLV на следующем участке не означает понимание на каждом узле. Маршрутизатор мог исполнить обязанность по передаче байтов, не умея объяснить их смысл.

Более того, он может получить два конфликтующих транзитивных набора незнакомого типа. Если число экземпляров и их байты не совпадают полностью, применяется общее разрешение конфликта. Непонимающий узел выбирает непрозрачный смысл по порядку адресов.

Операционный словарь должен быть точным: получено, контейнер разобран, тип понят, неизвестное переслано, неизвестное отброшено, набор выбран. Слово «проверено» требует отдельной проверки смысла и полномочия.

Происхождение состояния привязано к смежности

Если обработка меняет построение дерева или набор, передаваемый вверх, RFC 5384 требует связать атрибут с той смежностью, от которой он получен. При Prune или истечении снимается именно её вклад.

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

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

Новый Join полностью заменяет старый набор

Изменение не является патчем. Если новый Join несёт не точно тот же набор, он становится полным новым состоянием. Отсутствующие атрибуты считаются отозванными. Пустое множество использует type 0. Prune также отзывает значения, ранее связанные с его смежностью.

Если вчера приходили A и B, а сегодня только B, атрибут A удалён без отдельного сообщения «delete A». Лог, который добавляет новые TLV и не реконструирует полные снимки, сохранит призрачный A.

RFC 7887 расширяет область компактного кодирования до всего сообщения, группы или источника. Экономия места не уменьшает область ошибки. Нужно сохранять полные состояния до и после для каждого уровня и явно вычислять отозванное отсутствием.

Аутентификация устанавливает автора, но не компетенцию

RFC 5384 связывает защищённость Join Attribute с защищённостью PIM-пакета и оставляет дополнительные требования спецификации типа. RFC 5796 способна поддержать происхождение и целостность link-local PIM-сообщений.

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

Нужна внешняя политика полномочий: разрешённые principals, диапазоны источников и групп, типы и значения, приоритет локальной конфигурации, процедура эскалации. RFC 6420 для MT-ID показывает пример, где локальная конфигурация имеет приоритет; тогда конфигурация и её одобрение входят в доказательство.

Построенное дерево ещё не является результатом

Понятый, выбранный и аутентифицированный атрибут остаётся фактом control plane. Он может изменить upstream или RPF-топологию, но не доказывает установку multicast-состояния, фактический путь, отсутствие дубликатов, права получателей или полезный результат приложения.

Цепочка должна быть раздельной: настроенное намерение; объявления capability; точный Join; интерпретация; выбор при конфликте; upstream Join; установленное состояние; наблюдение пакетов; результат у получателя. Успех одного этапа не выдаёт квитанцию за следующий.

Существующая статья о RFC 9798 владеет темой Receiver RLOC, выбором underlay-группы, репликацией ITR и доказательством доставки. Статья о RFC 9739 владеет PIM Light без Hello, DR, Assert и обработкой отказа. Здесь рассматривается только граница общей процедуры RFC 5384.

Испытание, которое не стирает проигравшего

Создайте две downstream-смежности и один upstream-маршрутизатор. Проверьте type 1 capability каждого соседа интерфейса. Выберите атрибут с известной спецификацией и сохраните исходные байты, ключ source/group, адрес, интерфейс и время.

Отправьте разные значения одного типа. Сначала выясните, есть ли специальная процедура; иначе подтвердите выбор меньшего адреса. Поменяйте только адресный порядок и повторите. Затем завершите победившую смежность и наблюдайте активацию сохранённого кандидата и новый upstream Join.

Замените A+B на B и подтвердите отзыв A. Раздельно проверьте неизвестный transitive и non-transitive тип. В финале сопоставьте control plane, packet capture и canary-получателей как разные доказательства.

Отчёт должен утверждать: «X выбран по правилу Y». Он не должен без дополнительных данных превращать это в «X был уполномочен» или «данные доставлены».

Источники