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, а не још један изузетак у филтеру. Запишите која од пет провера није успела пре него што било шта промените, а затим промените само тај слој.