PIM-SM през VPN: проверка на BSR, съпоставяне на RP и RPF пътища

Тунелът е вдигнат, unicast ping-овете минават през него, а приемникът все още показва черен екран. При внедряване на 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 топологията. Отнасяйте се към него като към конфигурация, която трябва да се документира, а не като към кръпка, приложена по време на инцидент и после забравена.

Потвърдете присъединяването с команди, не с ping

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