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

Tunnelen er oppe, unicast-ping går igennem den, og modtageren viser stadig en sort skærm. I en PIM-SM-udrulning betyder det symptom næsten altid, at en af fire kontrolveje er brudt, og at datastien aldrig var problemet. Gå listen nedenfor igennem i rækkefølge, og stop ved det første trin, der fejler, fordi hvert senere trin afhænger af det foregående. Jeg har disse fem undersøgelser i en kladdefil og indsætter dem i en terminal, når en multicast-klage kommer ind, hvilket forhindrer, at diagnosen bliver til gætværk.

Start med modtageren, ikke tunnelen

En modtager, der aldrig har bedt om gruppen, skaber ingen tilstand på nogen router, så bekræft, at joinet findes på segmentet ud mod modtageren, før du undersøger noget andet. På Cisco-lignende platforme udskriver show ip igmp groups på routeren ved sidste hop de joinede grupper ved siden af det interface, der hørte dem. Når gruppen mangler i det output, er tunnelen en afledning: anmodningen døde i adgangsswitchen, i værtens socket eller i et VLAN uden querier.

To banale årsager forklarer de fleste manglende joins, jeg har set: en IGMP-version-uenighed mellem vært og router og en querier-afstemning, der havnede på en switch, som ikke router. En tredje er mere subtil: gruppen er joined, men på det forkerte VLAN, fordi værten har to netværkskort, og applikationen bandt sig til det forkerte. IPv6-modtagere har det tilsvarende problem med MLD, hvor show ipv6 mld groups svarer på det samme spørgsmål. Ingen af disse løses ved at røre tunnelen, og det er netop derfor, rækkefølgen betyder noget.

Når joinet er synligt, så bekræft, at PIM er aktiveret på både interfacet ud mod modtageren og interfacet, der fører mod rendezvous-punktet. En router med IGMP-medlemskab, men uden PIM på sit upstream-interface, holder gruppen i en lokal tabel og sender intet nogen steder hen.

Når BSR-sættet over til den anden side?

Bootstrap Router-beskeder bevæger sig hop for hop inden for ét PIM-domæne, og det er den retning, der brækker over en tunnel. Kandidat-RP'er sender deres annonceringer til den valgte BSR via unicast, så RP-til-BSR-benet overlever normalt en fungerende tunnel uændret. Flommen af Bootstrap-beskeder i den anden retning afhænger af, at hvert mellemliggende interface har PIM aktiveret, og af at intet stopper beskederne ved en grænse. RFC 5059 definerer den distribution og de administrative omfangsgrænser, som må afkorte den.

En ip pim bsr-border-sætning, en ACL der filtrerer protokol 103, eller en policybaseret IPsec-tunnel, der ikke kan bære multicast, vil hver især klippe flommen, mens unicast forbliver intakt. Netop den kombination får fejlen til at se ud som et RP-problem, når den i virkeligheden er et tilgængelighedsproblem, og derfor læser jeg BSR-tilstanden, før jeg læser RP-konfigurationen.

På routeren på den anden side angiver show ip pim bsr-router den valgte BSR og det RP-sæt, den har lært; er outputtet tomt, sidder den anden side i sit eget domæne, og ingen mængde RP-konfiguration vil forene de to. Sammenlign gruppeområderne og RP-adresserne i show ip pim rp mapping på begge sider af tunnelen. En mapping, der kun findes lokalt, skaber et delt træ, der ender det forkerte sted, og modtageren venter for evigt.

Få RP-mappingen til at passe på begge sider af tunnelen

Statisk RP, BSR og anycast-RP er tre måder at svare på det samme spørgsmål, og at blande dem over en tunnel er en sikker måde at bygge et domæne, der aldrig konvergerer. Hvis hovedenden bruger BSR, og grenen bruger en statisk ip pim rp-address, der peger på en anden adresse, bygger grenen sit delte træ mod en RP, der ikke aner, at modtageren findes. Mappingen skal stemme overens både på gruppeområdet og på adressen, eftersom et mere specifikt område vinder over et bredere.

Anycast-RP findes netop, for at to steder kan dele én RP-adresse, og det er værd at nævne her, fordi det ændrer, hvad «den samme RP» betyder. To RP'er, der annoncerer én adresse, er konsistente efter design; to RP'er, der annoncerer forskellige adresser for det samme område, er det ikke, uanset hvor sundt hvert sted ser ud på egen hånd.

For kildespecifik multicast inden for 232.0.0.0/8 bliver RP'en aldrig spurgt, så en tom RP-mapping er ikke automatisk en fejl. Beslut, hvilken servicemodel applikationen bruger, før du jager en RP, der aldrig var nødvendig.

Læs RPF-opslaget mod kilden

PIM bygger et træ ved at vende unicast-stien, så den kontrol, der betyder noget, er ruten tilbage mod kilden eller tilbage mod RP'en for et delt træ. Et join, der ankommer på et interface, som routeren ikke anser for upstream, bliver droppet, og årsagen logges som en RPF-fejl snarere end som en tunnelfejl. På en grenrouter med en standardrute over tunnelen og en mere specifik rute over WAN'et kan RPF-interfacet let være WAN'et, selvom kilden kun kan nås gennem tunnelen. Det er den enkelt mest almindelige grund til, at et join lydløst bliver kasseret.

show ip rpf 192.0.2.10 udskriver det valgte interface, næste hop og den rute, der skabte beslutningen, hvilket normalt er nok til at se uoverensstemmelsen. En statisk multicast-rute som ip mroute 192.0.2.0 255.255.255.0 tunnel0 tilsidesætter unicast-opslaget for det præfiks, og det er en legitim rettelse, når multicast-topologien reelt adskiller sig fra unicast-topologien. Behandl den som konfiguration, der skal dokumenteres, ikke som en lap, der påføres under en hændelse og derefter glemmes.

Bekræft joinet med kommandoer, ikke med en ping

Ping beviser, at unicast virker, hvilket du allerede vidste. Den end-to-end bekræftelse er en sekvens, der viser joinet, mappingen, naboen og træet i den rækkefølge, og hver kommando besvarer et forskelligt spørgsmå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 udfyldt (S,G)-post med et reelt indgående interface og en ikke-tom udgående liste betyder, at kontrolplanet har gjort sit arbejde. En post, hvis indgående interface står som Null, eller en tæller mærket RPF failed, der fortsætter med at stige, peger tilbage på det foregående afsnit snarere end på tunnelen.

Hvis alle fem kommandoer ser rigtige ud, og modtageren stadig ikke ser noget, er den resterende mistænkte tunnelens egen politik: en krypto-ACL eller firewall-regel, der tillader unicast-rutningsprotokollen, men ikke PIM, IGMP eller selve gruppetrafikken. På en policybaseret IPsec-tunnel bæres multicast slet ikke, så svaret er et GRE- eller VTI-design i stedet for endnu en filterundtagelse. Skriv ned, hvilken af de fem undersøgelser der fejlede, før du ændrer noget, og ændr så kun det lag.