PIM-SM over ein VPN: kontroller BSR, RP-mapping og RPF-ruter

Tunnelen er oppe, unicast-ping går gjennom han, og mottakaren viser framleis ein svart skjerm. I ein PIM-SM-utrulling tyder det symptomet nesten alltid at éin av fire kontrollvegar er broten, og at datavegen aldri var problemet. Gå gjennom lista nedanfor i rekkjefølgje og stopp ved det første trinnet som sviktar, fordi kvart seinare trinn er avhengig av det førre. Eg har desse fem undersøkingane i ei kladdefil og limer dei inn i ein terminal når ei multicast-klage kjem inn, noko som hindrar at diagnosen blir gissing.

Start med mottakaren, ikkje tunnelen

Ein mottakar som aldri har bede om gruppa, lagar ingen tilstand på nokon ruter, så stadfest at medlemskapet finst på segmentet ut mot mottakaren før du undersøkjer noko anna. På Cisco-liknande plattformer skriv show ip igmp groups på ruteren ved siste hopp ut dei påmelde gruppene ved sida av grensesnittet som høyrde dei. Når gruppa manglar i den utskrifta, er tunnelen ei avleiing: førespurnaden døydde i aksessbrytaren, i sokkelen til verten eller i eit VLAN utan querier.

To banelege årsaker forklarar dei fleste manglande påmeldingane eg har sett: ein IGMP-versjonsforskjell mellom vert og ruter og ei querier-røysting som hamna på ein brytar som ikkje rutar. Ei tredje er meir subtil: gruppa er påmeld, men på feil VLAN, fordi verten har to nettverkskort og applikasjonen batt seg til det feil. IPv6-mottakarar har det tilsvarande problemet med MLD, der show ipv6 mld groups svarar på det same spørsmålet. Ingen av desse blir løyste ved å ta på tunnelen, og det er nettopp difor rekkjefølgja har noko å seie.

Når påmeldinga er synleg, stadfest at PIM er slått på både på grensesnittet mot mottakaren og på grensesnittet som fører mot møtepunktet. Ein ruter med IGMP-medlemskap, men utan PIM på oppstraumsgrensesnittet, held gruppa i ein lokal tabell og sender ingenting nokon stad.

Når BSR-settet over til den andre sida?

Bootstrap Router-meldingar flyttar seg hopp for hopp innanfor eitt PIM-domene, og det er den retninga som bryt over ein tunnel. Kandidat-RP-ar sender kunngjeringane sine til den valde BSR-en via unicast, så RP-til-BSR-delen overlever vanlegvis ein fungerande tunnel uendra. Fløymda av Bootstrap-meldingar i den andre retninga er avhengig av at kvart mellomliggjande grensesnitt har PIM slått på, og av at ingenting stoppar meldingane ved ei grense. RFC 5059 definerer den distribusjonen og dei administrative områdegrensene som har lov til å korte han ned.

Ei ip pim bsr-border-setning, ein ACL som filtrerer protokoll 103, eller ein policybasert IPsec-tunnel som ikkje kan bera multicast, vil kvar av dei kutte fløymda medan unicast blir intakt. Nettopp den kombinasjonen får feilen til å sjå ut som eit RP-problem når han eigentleg er eit tilgjengeproblem, og difor les eg BSR-tilstanden før eg les RP-konfigurasjonen.

På ruteren på den andre sida oppgir show ip pim bsr-router den valde BSR-en og RP-settet han har lært; om utskrifta er tom, sit den andre sida i sitt eige domene, og inga mengd RP-konfigurasjon vil sameine dei to. Samanlikn gruppeområda og RP-adressene i show ip pim rp mapping på begge sider av tunnelen. Ein mapping som berre finst lokalt, lagar eit delt tre som endar på feil stad, og mottakaren ventar i det uendelege.

Få RP-mappinga til å stemme på begge sider av tunnelen

Statisk RP, BSR og anycast-RP er tre måtar å svare på det same spørsmålet, og å blande dei over ein tunnel er ein påliteleg måte å byggje eit domene som aldri konvergerer. Om hovudenden brukar BSR og filialen brukar ein statisk ip pim rp-address som peikar på ei anna adresse, byggjer filialen det delte treet sitt mot ein RP som ikkje anar at mottakaren finst. Mappinga må stemme både på gruppeområdet og på adressa, sidan eit meir spesifikt område vinn over eit breiare.

Anycast-RP finst nettopp for at to stader skal kunne dele éi RP-adresse, og det er verdt å nemne her fordi det endrar kva «den same RP-en» tyder. To RP-ar som kunngjer éi adresse, er konsistente etter design; to RP-ar som kunngjer ulike adresser for det same området, er det ikkje, uansett kor sunt kvar stad ser ut på eiga hand.

For kjeldespesifikk multicast innanfor 232.0.0.0/8 blir RP-en aldri spurd, så ein tom RP-mapping er ikkje automatisk ein feil. Avgjer kva tenestemodell applikasjonen brukar, før du jagar ein RP som aldri var nødvendig.

Les RPF-oppslaget mot kjelda

PIM byggjer eit tre ved å snu unicast-stien, så kontrollen som tel, er ruta tilbake mot kjelda, eller tilbake mot RP-en for eit delt tre. Ei påmelding som kjem inn på eit grensesnitt som ruteren ikkje reknar som oppstraum, blir kasta, og årsaka blir logga som ein RPF-feil snarare enn som ein tunnelfeil. På ein filialruter med ei standardrute over tunnelen og ei meir spesifikk rute over WAN-et kan RPF-grensesnittet lett vere WAN-et, sjølv om kjelda berre er tilgjengeleg gjennom tunnelen. Det er den einaste mest vanlege grunnen til at ei påmelding blir stille kasta.

show ip rpf 192.0.2.10 skriv ut det valde grensesnittet, neste hopp og ruta som skapte avgjerda, og det er vanlegvis nok til å sjå avviket. Ei statisk multicast-rute som ip mroute 192.0.2.0 255.255.255.0 tunnel0 overstyrer unicast-oppslaget for det prefikset, og det er ei legitim retting når multicast-topologien verkeleg avvik frå unicast-topologien. Handsame ho som konfigurasjon som skal dokumenterast, ikkje som ei lapp som blir sett på under ei hending og deretter gløymd.

Stadfest påmeldinga med kommandoar, ikkje med ein ping

Ping beviser at unicast fungerer, noko du alt visste. Stadfestinga frå ende til ende er ein sekvens som viser påmeldinga, mappinga, naboen og treet i den rekkjefølgja, og kvar kommando svarar på eit anna spørsmål.

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

Ein utfylt (S,G)-oppføring med eit reelt inngåande grensesnitt og ei ikkje-tom utgåande liste tyder på at kontrollplanet har gjort jobben sin. Ei oppføring der det inngåande grensesnittet blir lese som Null, eller ein teljar merkt RPF failed som held fram med å stige, peikar tilbake på det førre avsnittet og ikkje på tunnelen.

Om alle fem kommandoane ser riktige ut og mottakaren framleis ikkje ser noko, er den gjenverande mistenkte politikken til sjølve tunnelen: ein krypto-ACL eller ein brannmurregel som tillèt unicast-rutingsprotokollen, men ikkje PIM, IGMP eller sjølve gruppetrafikken. På ein policybasert IPsec-tunnel blir multicast ikkje boren i det heile, så svaret er eit GRE- eller VTI-design i staden for nok eit filterunntak. Skriv ned kva av dei fem undersøkingane som svikta før du endrar noko, og endre deretter berre det laget.