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, а не ще один виняток у фільтрі. Запишіть, яка з п'яти перевірок не пройшла, перш ніж щось змінювати, і потім змініть лише той шар.