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