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

Tunnelen er oppe, unicast-ping går gjennom den, og mottakeren viser fortsatt en svart skjerm. I en PIM-SM-utrulling betyr det symptomet nesten alltid at én av fire kontrollveier er brutt, og at dataveien aldri var problemet. Gå gjennom listen nedenfor i rekkefølge og stopp ved det første trinnet som feiler, fordi hvert senere trinn avhenger av det forrige. Jeg har disse fem undersøkelsene i en kladdefil og limer dem inn i en terminal når en multicast-klage kommer inn, noe som hindrer at diagnosen blir gjetting.

Start med mottakeren, ikke tunnelen

En mottaker som aldri har bedt om gruppen, lager ingen tilstand på noen ruter, så bekreft at medlemskapet finnes på segmentet ut mot mottakeren før du undersøker noe annet. På Cisco-lignende plattformer skriver show ip igmp groups på ruteren ved siste hopp ut de påmeldte gruppene ved siden av grensesnittet som hørte dem. Når gruppen mangler i den utskriften, er tunnelen en avledning: forespørselen døde i aksessbryteren, i vertens socket eller i et VLAN uten querier.

To banale årsaker forklarer de fleste manglende påmeldingene jeg har sett: en IGMP-versjonsforskjell mellom vert og ruter og en querier-avstemming som havnet på en bryter som ikke ruter. En tredje er mer subtil: gruppen er påmeldt, men på feil VLAN, fordi verten har to nettverkskort og applikasjonen bandt seg til det feil. IPv6-mottakere har det tilsvarende problemet med MLD, der show ipv6 mld groups svarer på det samme spørsmålet. Ingen av disse løses ved å ta på tunnelen, og det er nettopp derfor rekkefølgen betyr noe.

Når påmeldingen er synlig, bekreft at PIM er aktivert både på grensesnittet mot mottakeren og på grensesnittet som fører mot møtepunktet. En ruter med IGMP-medlemskap, men uten PIM på oppstrømsgrensesnittet, holder gruppen i en lokal tabell og sender ingenting noe sted.

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

Bootstrap Router-meldinger beveger seg hopp for hopp innenfor ett PIM-domene, og det er den retningen som bryter over en tunnel. Kandidat-RP-er sender kunngjøringene sine til den valgte BSR-en via unicast, så RP-til-BSR-delen overlever vanligvis en fungerende tunnel uendret. Flommen av Bootstrap-meldinger i den andre retningen avhenger av at hvert mellomliggende grensesnitt har PIM aktivert, og av at ingenting stopper meldingene ved en grense. RFC 5059 definerer den distribusjonen og de administrative områdegrensene som har lov til å avkorte den.

En ip pim bsr-border-setning, en ACL som filtrerer protokoll 103, eller en policybasert IPsec-tunnel som ikke kan bære multicast, vil hver av dem kutte flommen mens unicast forblir intakt. Nettopp den kombinasjonen får feilen til å se ut som et RP-problem når den egentlig er et tilgjengelighetsproblem, og derfor leser jeg BSR-tilstanden før jeg leser RP-konfigurasjonen.

På ruteren på den andre siden angir show ip pim bsr-router den valgte BSR-en og RP-settet den har lært; hvis utskriften er tom, sitter den andre siden i sitt eget domene, og ingen mengde RP-konfigurasjon vil forene de to. Sammenlign gruppeområdene og RP-adressene i show ip pim rp mapping på begge sider av tunnelen. En mapping som bare finnes lokalt, lager et delt tre som ender på feil sted, og mottakeren venter i det uendelige.

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

Statisk RP, BSR og anycast-RP er tre måter å svare på det samme spørsmålet, og å blande dem over en tunnel er en pålitelig måte å bygge et domene som aldri konvergerer. Hvis hodeenden bruker BSR og filialen bruker en statisk ip pim rp-address som peker på en annen adresse, bygger filialen sitt delte tre mot en RP som ikke aner at mottakeren finnes. Mappingen må stemme både på gruppeområdet og på adressen, siden et mer spesifikt område vinner over et bredere.

Anycast-RP finnes nettopp for at to steder skal kunne dele én RP-adresse, og det er verdt å nevne her fordi det endrer hva «den samme RP-en» betyr. To RP-er som kunngjør én adresse, er konsistente etter design; to RP-er som kunngjør forskjellige adresser for det samme området, er det ikke, uansett hvor sunt hvert sted ser ut på egen hånd.

For kildespesifikk multicast innenfor 232.0.0.0/8 blir RP-en aldri spurt, så en tom RP-mapping er ikke automatisk en feil. Bestem hvilken tjenestemodell applikasjonen bruker, før du jager en RP som aldri var nødvendig.

Les RPF-oppslaget mot kilden

PIM bygger et tre ved å snu unicast-stien, så kontrollen som betyr noe, er ruten tilbake mot kilden, eller tilbake mot RP-en for et delt tre. En påmelding som kommer inn på et grensesnitt som ruteren ikke anser som oppstrøm, blir forkastet, og årsaken logges som en RPF-feil snarere enn som en tunnelfeil. På en filialruter med en standardrute over tunnelen og en mer spesifikk rute over WAN-et kan RPF-grensesnittet lett være WAN-et, selv om kilden bare er tilgjengelig gjennom tunnelen. Det er den enkelt mest vanlige grunnen til at en påmelding blir stille forkastet.

show ip rpf 192.0.2.10 skriver ut det valgte grensesnittet, neste hopp og ruten som skapte avgjørelsen, og det er vanligvis nok til å se avviket. En statisk multicast-rute som ip mroute 192.0.2.0 255.255.255.0 tunnel0 overstyrer unicast-oppslaget for det prefikset, og det er en legitim rettelse når multicast-topologien virkelig avviker fra unicast-topologien. Behandle den som konfigurasjon som skal dokumenteres, ikke som en lapp som påføres under en hendelse og deretter glemmes.

Bekreft påmeldingen med kommandoer, ikke med en ping

Ping beviser at unicast fungerer, noe du allerede visste. Bekreftelsen fra ende til ende er en sekvens som viser påmeldingen, mappingen, naboen og treet i den rekkefølgen, og hver kommando svarer på et forskjellig 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

En utfylt (S,G)-oppføring med et reelt inngående grensesnitt og en ikke-tom utgående liste betyr at kontrollplanet har gjort jobben sin. En oppføring der det inngående grensesnittet leses som Null, eller en teller merket RPF failed som fortsetter å stige, peker tilbake på forrige avsnitt og ikke på tunnelen.

Hvis alle fem kommandoene ser riktige ut og mottakeren fortsatt ikke ser noe, er den gjenværende mistenkte tunnelens egen politikk: en krypto-ACL eller brannmurregel som tillater unicast-rutingsprotokollen, men ikke PIM, IGMP eller selve gruppetrafikken. På en policybasert IPsec-tunnel bæres ikke multicast i det hele tatt, så svaret er et GRE- eller VTI-design i stedet for nok et filterunntak. Skriv ned hvilken av de fem undersøkelsene som feilet før du endrer noe, og endre deretter bare det laget.