PIM-SM через VPN: проверка BSR, сопоставления RP и путей RPF

Туннель поднят, unicast-пинги проходят через него, а получатель по-прежнему показывает чёрный экран. В развёртывании PIM-SM такой симптом почти всегда означает, что один из четырёх путей управления сломан, а путь данных никогда не был проблемой. Пройдите список ниже по порядку и остановитесь на первом шаге, который не сработает, потому что каждый следующий шаг зависит от предыдущего. Я держу эти пять проверок в черновом файле и вставляю их в терминал, когда приходит жалоба на multicast, и это не даёт диагностике превратиться в догадки.

Начните с получателя, а не с туннеля

Получатель, который ни разу не запросил группу, не создаёт состояния ни на одном маршрутизаторе, поэтому прежде чем проверять что-либо ещё, убедитесь, что подписка существует на сегменте со стороны получателя. На платформах в стиле Cisco show ip igmp groups на маршрутизаторе последнего перехода печатает присоединённые группы рядом с интерфейсом, который их услышал. Если группы в этом выводе нет, туннель — это отвлечение: запрос умер на коммутаторе доступа, в сокете хоста или в VLAN без querier.

Две обыденные причины объясняют большинство замеченных мной пропавших подписок: расхождение версий IGMP между хостом и маршрутизатором и выбор querier, который пришёлся на коммутатор, не выполняющий маршрутизацию. Третья тоньше: группа присоединена, но в неправильной VLAN, потому что у хоста две сетевые карты, а приложение привязалось к неверной. У получателей IPv6 та же проблема с MLD, где show ipv6 mld groups отвечает на тот же вопрос. Ни одна из них не исправляется прикосновением к туннелю, и именно поэтому порядок важен.

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

Доходит ли набор BSR до дальней стороны?

Сообщения Bootstrap Router движутся переход за переходом внутри одного домена PIM, и именно это направление ломается через туннель. Кандидаты RP отправляют свои объявления выбранному BSR посредством unicast, поэтому участок RP-до-BSR обычно переживает работающий туннель без изменений. Поток сообщений Bootstrap в обратном направлении зависит от того, включён ли PIM на каждом промежуточном интерфейсе и не останавливает ли что-то сообщения на границе. RFC 5059 определяет это распространение и границы административной области, которым разрешено его сокращать.

ip pim bsr-border, ACL, фильтрующий протокол 103, или туннель IPsec на основе политик, который не может нести multicast, — каждый из них оборвёт поток, оставив unicast нетронутым. Именно это сочетание заставляет сбой выглядеть проблемой RP, хотя на самом деле это проблема доступности, и поэтому я читаю состояние BSR раньше конфигурации RP.

На маршрутизаторе дальней стороны show ip pim bsr-router называет выбранный BSR и изученный набор RP; если вывод пуст, дальняя сторона находится в своём домене, и никакая конфигурация RP не согласует эти две части. Сравните диапазоны групп и адреса RP в show ip pim rp mapping на обеих сторонах туннеля. Сопоставление, существующее только локально, создаёт общее дерево, которое заканчивается не в том месте, и получатель ждёт вечно.

Согласуйте сопоставление RP на обеих сторонах туннеля

Статический RP, BSR и anycast-RP — три способа ответить на один вопрос, и смешивать их через туннель — надёжный способ построить домен, который никогда не сходится. Если головной узел использует BSR, а филиал — статический ip pim rp-address, указывающий на другой адрес, филиал строит своё общее дерево к RP, который не знает о существовании получателя. Сопоставление должно совпадать и по диапазону групп, и по адресу, поскольку более конкретный диапазон побеждает более широкий.

Anycast-RP существует именно для того, чтобы два сайта могли разделять один адрес RP, и его стоит назвать здесь, потому что он меняет смысл «того же RP». Два RP, объявляющих один адрес, согласованы по замыслу; два RP, объявляющих разные адреса для одного диапазона, — нет, как бы здраво ни выглядел каждый сайт по отдельности.

Для multicast, специфичного для источника, внутри 232.0.0.0/8 RP не запрашивается никогда, поэтому пустое сопоставление RP не является автоматически неисправностью. Решите, какую модель обслуживания использует приложение, прежде чем гнаться за RP, который никогда не был нужен.

Прочитайте поиск RPF в сторону источника

PIM строит дерево, обращая путь unicast, поэтому важная проверка — это маршрут обратно к источнику или обратно к RP для общего дерева. Подписка, пришедшая на интерфейс, который маршрутизатор не считает вышестоящим, отбрасывается, и причина записывается как сбой RPF, а не как сбой туннеля. На маршрутизаторе филиала с маршрутом по умолчанию через туннель и более конкретным маршрутом через WAN интерфейс RPF может легко оказаться WAN, хотя источник доступен только через туннель. Это единственная самая частая причина, по которой подписка тихо отбрасывается.

show ip rpf 192.0.2.10 печатает выбранный интерфейс, следующий переход и маршрут, породивший решение, и обычно этого достаточно, чтобы увидеть несоответствие. Статический маршрут multicast, такой как ip mroute 192.0.2.0 255.255.255.0 tunnel0, перекрывает поиск unicast для этого префикса, и это законная правка, когда топология multicast действительно отличается от топологии unicast. Относитесь к нему как к конфигурации, которую нужно документировать, а не как к заплатке, применённой во время инцидента и затем забытой.

Подтвердите подписку командами, а не пингом

Пинг доказывает, что unicast работает, о чём вы уже знали. Подтверждение от конца до конца — это последовательность, показывающая подписку, сопоставление, соседа и дерево именно в этом порядке, и каждая команда отвечает на свой вопрос.

show ip igmp groups 239.1.1.1
show ip pim rp mapping
show ip pim neighbor
show ip rpf 192.0.2.10
show ip mroute 239.1.1.1

Заполненная запись (S,G) с реальным входящим интерфейсом и непустым списком исходящих означает, что плоскость управления закончила работу. Запись, у которой входящий интерфейс читается как Null, или счётчик с меткой RPF failed, который продолжает расти, указывает назад на предыдущий раздел, а не на туннель.

Если все пять команд выглядят правильно, а получатель всё равно ничего не видит, оставшийся подозреваемый — политика самого туннеля: крипто-ACL или правило межсетевого экрана, разрешающее протокол маршрутизации unicast, но не PIM, IGMP или сам трафик группы. На туннеле IPsec на основе политик multicast вообще не переносится, поэтому ответ — проект GRE или VTI, а не ещё одно исключение в фильтре. Запишите, какая из пяти проверок не прошла, прежде чем что-то менять, и затем меняйте только этот слой.