VPN арқылы PIM-SM: BSR, RP картасы және RPF жолдарын тексеру

Туннель жұмыс істеп тұр, unicast ping-тер одан өтеді, бірақ қабылдағыш әлі де қара экран көрсетеді. PIM-SM орналастыруында бұл симптом әрдайым дерлік төрт басқару жолының біреуі сынғанын және деректер жолы ешқашан мәселе болмағанын білдіреді. Төмендегі тізімді ретімен қарап шығып, сәтсіздікке ұшыраған бірінші қадамда тоқтаңыз, өйткені әрбір келесі қадам алдыңғысына тәуелді. Мен осы бес тексеруді жоба файлында ұстаймын және multicast туралы шағым келгенде терминалға қоямын, бұл диагностиканың болжамға айналуына жол бермейді.

Туннельден емес, қабылдағыштан бастаңыз

Топты ешқашан сұрамаған қабылдағыш ешқандай маршрутизаторда күй жасамайды, сондықтан кез келген басқа нәрсені тексерудің алдында қосылу қабылдағышқа қараған сегментте бар екенін растаңыз. Cisco тәрізді платформаларда соңғы секіріс маршрутизаторында show ip igmp groups қосылған топтарды оларды естіген интерфейстің қасында басып шығарады. Сол шығыста топ болмаса, туннель назарды бұрады: сұраныс қатынау коммутаторында, хост сокетінде немесе querier жоқ VLAN ішінде өлді.

Мен көрген жоғалған қосылулардың көбін екі қарапайым себеп түсіндіреді: хост пен маршрутизатор арасындағы 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 мәлімдемесі, 103 хаттамасын сүзетін ACL немесе multicast тасымалдай алмайтын саясатқа негізделген IPsec туннелі, әрқайсысы ағынды кесіп, unicast-ты бүтін қалдырады. Дәл осы үйлесім ақауды RP мәселесіне ұқсатады, ал шын мәнінде бұл жетімділік мәселесі, сондықтан мен RP конфигурациясын оқымас бұрын BSR күйін оқимын.

Арғы жақтағы маршрутизаторда show ip pim bsr-router сайланған BSR-ды және үйренген RP жиынын атайды; шығыс бос болса, арғы жақ өз доменінде отырады және ешбір RP конфигурациясы екеуін келістіре алмайды. Туннельдің екі жағында show ip pim rp mapping шығысындағы топ ауқымдары мен RP мекенжайларын салыстырыңыз. Тек жергілікті жерде бар карталау дұрыс емес жерде аяқталатын ортақ ағаш жасайды, ал қабылдағыш мәңгі күтеді.

RP картасын туннельдің екі жағында сәйкестендіріңіз

Статикалық RP, BSR және anycast-RP — бір сұраққа үш жауап, ал оларды туннель арқылы араластыру ешқашан жинақталмайтын домен құрудың сенімді жолы. Егер бас жақ BSR қолданса, ал тармақ басқа мекенжайға сілтейтін статикалық ip pim rp-address қолданса, тармақ өзінің ортақ ағашын қабылдағыштың бар екенін білмейтін RP-ға қарай салады. Карталау топ ауқымында да, мекенжайында да сәйкесуі керек, өйткені нақтырақ ауқым кеңірек ауқымды жеңеді.

Anycast-RP екі сайттың бір RP мекенжайын бөлісуі үшін дәл бар және оны осында атап өткен жөн, өйткені ол «сол RP» дегеннің мағынасын өзгертеді. Бір мекенжайды жариялайтын екі RP дизайн бойынша үйлесімді; бір ауқым үшін әртүрлі мекенжайларды жариялайтын екі RP ондай емес, әр сайт жеке-дара қаншалықты сау көрінсе де.

232.0.0.0/8 ішіндегі көзге тән multicast үшін RP-ға ешқашан жүгінбейді, сондықтан бос RP картасы автоматты түрде ақау емес. Ешқашан қажет болмаған RP-ның соңынан түспес бұрын қолданба қандай қызмет моделін қолданатынын шешіңіз.

RPF іздеуін көзге қарай оқыңыз

PIM ағашты unicast жолын кері бұру арқылы салады, сондықтан маңызды тексеру — көзге қайтатын маршрут немесе ортақ ағаш үшін RP-ға қайтатын жол. Маршрутизатор жоғарғы деп санамайтын интерфейске келген қосылу тасталады және себебі туннель ақауы ретінде емес, RPF ақауы ретінде тіркеледі. Туннель арқылы әдепкі маршруты және WAN арқылы нақтырақ маршруты бар тармақ маршрутизаторында RPF интерфейсі оңай WAN болуы мүмкін, тіпті көзге тек туннель арқылы жетуге болатын болса да. Бұл қосылудың үнсіз тасталуының ең кең тараған жалғыз себебі.

show ip rpf 192.0.2.10 таңдалған интерфейсті, келесі секірісті және шешімді туғызған маршрутты басып шығарады, бұл әдетте сәйкессіздікті көруге жетеді. ip mroute 192.0.2.0 255.255.255.0 tunnel0 тәрізді статикалық multicast маршруты сол префикс үшін 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 белгісі бар, үнемі өсіп тұрған санауыш — туннельге емес, алдыңғы бөлімге сілтейді.

Егер бес команданың бәрі дұрыс көрінсе, ал қабылдағыш әлі ештеңе көрмесе, қалған күдікті — туннельдің өз саясаты: unicast маршруттау хаттамасына рұқсат беріп, PIM, IGMP немесе топ трафигінің өзіне рұқсат бермейтін крипто ACL немесе firewall ережесі. Саясатқа негізделген IPsec туннелінде multicast мүлдем тасымалданбайды, сондықтан жауап — фильтрдің тағы бір ерекшелігі емес, GRE немесе VTI дизайны. Бірдеңені өзгертудің алдында бес тексерудің қайсысы сәтсіз болғанын жазыңыз, содан кейін тек сол қабатты өзгертіңіз.