PIM-SM över en VPN: kontrollera BSR, RP-mappning och RPF-vägar

Tunneln är uppe, unicast-ping går igenom den, och mottagaren visar fortfarande en svart skärm. I en PIM-SM-distribution betyder det symtomet nästan alltid att en av fyra kontrollvägar är bruten och att datavägen aldrig var problemet. Gå igenom listan nedan i ordning och stanna vid det första steget som misslyckas, eftersom varje senare steg beror på det föregående. Jag har dessa fem kontroller i en utkastfil och klistrar in dem i en terminal när ett multicast-ärende kommer in, vilket hindrar diagnosen från att bli gissningar.

Börja med mottagaren, inte tunneln

En mottagare som aldrig har bett om gruppen skapar inget tillstånd på någon router, så bekräfta att anslutningen finns på segmentet mot mottagaren innan du undersöker något annat. På Cisco-liknande plattformar skriver show ip igmp groups på routern vid sista hoppet ut de anslutna grupperna bredvid det gränssnitt som hörde dem. När gruppen saknas i den utskriften är tunneln en distraktion: begäran dog i access-switchen, i värdens socket eller i ett VLAN utan querier.

Två banala orsaker förklarar de flesta saknade anslutningar jag har sett: en IGMP-versionsskillnad mellan värd och router, och ett querier-val som landade på en switch som inte routar. En tredje är mer subtil: gruppen är ansluten men i fel VLAN, eftersom värden har två nätverkskort och programmet bands till det felaktiga. IPv6-mottagare har samma problem med MLD, där show ipv6 mld groups svarar på samma fråga. Inget av detta åtgärdas genom att röra tunneln, och det är just därför ordningen spelar roll.

När anslutningen är synlig, bekräfta att PIM är aktiverat både på gränssnittet mot mottagaren och på gränssnittet som leder mot mötespunkten. En router med IGMP-medlemskap men utan PIM på sitt uppströmsgränssnitt håller gruppen i en lokal tabell och skickar ingenting någonstans.

Når BSR-uppsättningen den andra sidan?

Bootstrap Router-meddelanden rör sig hopp för hopp inom en enda PIM-domän, och det är den riktningen som bryts över en tunnel. Kandidat-RP:er skickar sina annonser till den valda BSR:n via unicast, så RP-till-BSR-delen överlever vanligtvis en fungerande tunnel oförändrad. Floden av Bootstrap-meddelanden i den andra riktningen beror på att varje mellanliggande gränssnitt har PIM aktiverat och att ingenting stoppar meddelandena vid en gräns. RFC 5059 definierar den distributionen och de administrativa omfångsgränser som får förkorta den.

En ip pim bsr-border-sats, en ACL som filtrerar protokoll 103, eller en policybaserad IPsec-tunnel som inte kan bära multicast, skär var och en av floden medan unicast förblir intakt. Just den kombinationen får felet att se ut som ett RP-problem när det i själva verket är ett nåbarhetsproblem, och därför läser jag BSR-tillståndet innan jag läser RP-konfigurationen.

På routern på den bortre sidan anger show ip pim bsr-router den valda BSR:n och den inlärda RP-uppsättningen; om utskriften är tom sitter den bortre sidan i sin egen domän och ingen mängd RP-konfiguration förenar de två. Jämför gruppintervallen och RP-adresserna i show ip pim rp mapping på båda sidor av tunneln. En mappning som bara finns lokalt skapar ett delat träd som slutar på fel ställe, och mottagaren väntar för evigt.

Få RP-mappningen att stämma på båda sidor av tunneln

Statisk RP, BSR och anycast-RP är tre sätt att svara på samma fråga, och att blanda dem över en tunnel är ett pålitligt sätt att bygga en domän som aldrig konvergerar. Om huvudänden använder BSR och filialen använder en statisk ip pim rp-address som pekar på en annan adress, bygger filialen sitt delade träd mot en RP som inte vet att mottagaren finns. Mappningen måste stämma både i gruppintervallet och i adressen, eftersom ett mer specifikt intervall vinner över ett bredare.

Anycast-RP finns just för att två platser ska kunna dela en RP-adress, och det är värt att nämna här eftersom det ändrar vad «samma RP» betyder. Två RP:er som annonserar en adress är konsekventa genom design; två RP:er som annonserar olika adresser för samma intervall är det inte, hur sunt varje plats än ser ut på egen hand.

För källspecifik multicast inom 232.0.0.0/8 frågas RP:n aldrig, så en tom RP-mappning är inte automatiskt ett fel. Bestäm vilken tjänstemodell programmet använder innan du jagar en RP som aldrig var nödvändig.

Läs RPF-uppslaget mot källan

PIM bygger ett träd genom att vända unicast-vägen, så kontrollen som betyder något är vägen tillbaka mot källan, eller tillbaka mot RP:n för ett delat träd. En anslutning som kommer in på ett gränssnitt som routern inte anser vara uppströms kastas, och orsaken loggas som ett RPF-fel snarare än som ett tunnelfel. På en filialrouter med en standardväg över tunneln och en mer specifik väg över WAN kan RPF-gränssnittet lätt vara WAN, även om källan bara nås genom tunneln. Det är den enskilt vanligaste orsaken till att en anslutning tyst kastas.

show ip rpf 192.0.2.10 skriver ut det valda gränssnittet, nästa hopp och den väg som skapade beslutet, vilket vanligtvis räcker för att se avvikelsen. En statisk multicast-väg som ip mroute 192.0.2.0 255.255.255.0 tunnel0 åsidosätter unicast-uppslaget för det prefixet, och det är en legitim rättelse när multicast-topologin verkligen avviker från unicast-topologin. Behandla den som konfiguration som ska dokumenteras, inte som en lapp som appliceras under en incident och sedan glöms bort.

Bekräfta anslutningen med kommandon, inte med en ping

Ping bevisar att unicast fungerar, vilket du redan visste. Bekräftelsen från ände till ände är en sekvens som visar anslutningen, mappningen, grannen och trädet i den ordningen, och varje kommando svarar på en annan fråga.

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 ifylld (S,G)-post med ett verkligt inkommande gränssnitt och en icke-tom utgående lista betyder att kontrollplanet har gjort sitt jobb. En post där det inkommande gränssnittet läses som Null, eller en räknare märkt RPF failed som fortsätter att stiga, pekar tillbaka på föregående avsnitt och inte på tunneln.

Om alla fem kommandona ser korrekta ut och mottagaren fortfarande inte ser något, är den kvarvarande misstänkta tunnelns egen policy: en krypto-ACL eller brandväggsregel som tillåter unicast-routingprotokollet men inte PIM, IGMP eller själva grupptrafiken. På en policybaserad IPsec-tunnel bärs multicast inte alls, så svaret är en GRE- eller VTI-design i stället för ännu ett filterundantag. Skriv ner vilken av de fem kontrollerna som misslyckades innan du ändrar något, och ändra sedan bara det lagret.