PIM-SM üle VPN-i: kontrolli BSR-i, RP kaardistust ja RPF-marsruute

Tunnel on üleval, unicast-pingid läbivad selle ja vastuvõtja näitab ikkagi musta ekraani. PIM-SM-i juurutuses tähendab see sümptom peaaegu alati, et üks neljast juhtimisteest on katki ja andmetee ei olnud kunagi probleem. Käi allolev nimekiri järjekorras läbi ja peatu esimesel sammul, mis ebaõnnestub, sest iga järgnev samm sõltub eelmisest. Hoian neid viit kontrolli mustandfailis ja kleebin need terminali, kui saabub multicast-kaebus, mis hoiab diagnoosimise ära muutumast oletusteks.

Alusta vastuvõtjast, mitte tunnelist

Vastuvõtja, kes ei ole kunagi gruppi küsinud, ei tekita üheski ruuteris olekut, seega kinnita, et liitumine on vastuvõtja poole jäävas segmendis olemas, enne kui midagi muud uurid. Cisco-laadsetel platvormidel trükib show ip igmp groups viimase hüppe ruuteril liitunud grupid selle liidese kõrvale, mis need kuulis. Kui grupp selles väljundis puudub, on tunnel tähelepanu kõrvalejuhtimine: päring suri juurdepääsukommutatoris, hosti soklis või VLAN-is, kus pole querier-it.

Kaks tavalist põhjust seletavad enamikku puuduvaid liitumisi, mida olen näinud: IGMP versiooni lahknevus hosti ja ruuteri vahel ning querier-i valimine, mis maandus kommutaatoril, mis ei marsruudi. Kolmas on peenem: grupp on liitunud, aga vales VLAN-is, sest hostil on kaks võrgukaarti ja rakendus sidus end vale külge. IPv6 vastuvõtjatel on sama probleem MLD-ga, kus show ipv6 mld groups vastab samale küsimusele. Ükski neist ei parane tunnelit puudutades ja täpselt seetõttu on järjekord oluline.

Kui liitumine on nähtav, kinnita, et PIM on lubatud nii vastuvõtja poole jääval liidesel kui ka kohtumispunkti viival liidesel. Ruuter, millel on IGMP liikmelisus, aga ülesvoolu liidesel PIM-i pole, hoiab gruppi kohalikus tabelis ega saada midagi kuhugi.

Kas BSR-i komplekt jõuab teisele poole?

Bootstrap Routeri teated liiguvad hüppelt hüppele ühe PIM-domeeni sees ja just see suund murdub üle tunneli. Kandidaat-RP-d saadavad oma teated valitud BSR-ile unicastiga, seega RP-st BSR-ini lõik jääb töötava tunneli korral tavaliselt muutumatuks. Bootstrap-teadete voog vastassuunas sõltub sellest, et igal vaheliidesel on PIM lubatud, ja sellest, et miski ei peata teateid piiril. RFC 5059 määratleb selle jaotuse ja haldusulatuse piirid, millel on lubatud seda lühendada.

ip pim bsr-border lause, protokolli 103 filtreeriv ACL või poliitikal põhinev IPsec-tunnel, mis ei suuda multicast'i kanda, lõikavad igaüks voo katki, jättes unicast'i puutumata. Just see kombinatsioon paneb rikke näima RP probleemina, kui see on tegelikult kättesaadavuse probleem, ja seetõttu loen BSR-i olekut enne RP konfiguratsiooni.

Kaugema poole ruuteril nimetab show ip pim bsr-router valitud BSR-i ja õpitud RP komplekti; kui väljund on tühi, istub kaugem pool oma domeenis ja ükski RP konfiguratsioon ei lepita neid kahte. Võrdle grupi vahemikke ja RP aadresse show ip pim rp mapping väljundis tunneli mõlemal poolel. Ainult kohapeal eksisteeriv kaardistus tekitab jagatud puu, mis lõpeb vales kohas, ja vastuvõtja ootab igavesti.

Sovita RP kaardistus tunneli mõlemal poolel

Staatiline RP, BSR ja anycast-RP on kolm viisi sama küsimusele vastata ja nende segamine üle tunneli on usaldusväärne viis ehitada domeen, mis ei koondu kunagi. Kui peaots kasutab BSR-i ja haru staatilist ip pim rp-address-i, mis osutab teisele aadressile, ehitab haru oma jagatud puu RP poole, kes ei tea vastuvõtja olemasolust midagi. Kaardistus peab kokku sobima nii grupi vahemikus kui ka aadressis, sest konkreetsem vahemik võidab laiema ees.

Anycast-RP on olemas just selleks, et kaks kohta saaksid jagada üht RP aadressi, ja seda tasub siin nimetada, sest see muudab seda, mida tähendab „sama RP“. Kaks RP-d, mis kuulutavad üht aadressi, on disaini poolest kooskõlas; kaks RP-d, mis kuulutavad sama vahemiku jaoks erinevaid aadresse, ei ole, ükskõik kui terve iga koht iseenesest välja näeb.

Allikapõhise multicast'i jaoks vahemikus 232.0.0.0/8 RP-lt ei küsita kunagi, seega tühi RP kaardistus ei ole automaatselt rike. Otsusta, millist teenusemudelit rakendus kasutab, enne kui hakkad taga ajama RP-d, mida kunagi ei vajatud.

Loe RPF otsing allika suunas

PIM ehitab puu unicast-tee ümber pöörates, seega oluline kontroll on marsruut tagasi allika juurde või jagatud puu korral tagasi RP juurde. Liitumine, mis saabub liidesele, mida ruuter ülesvoolu liideseks ei pea, visatakse kõrvale ja põhjus logitakse RPF-i rikkena, mitte tunneli rikkena. Haru-ruuteril, millel on tunnelil põhinev vaikemarsruut ja WAN-il põhinev konkreetsem marsruut, võib RPF-i liides kergesti olla WAN, kuigi allikas on kättesaadav ainult tunneli kaudu. See on ainus kõige levinum põhjus, miks liitumine vaikselt kõrvale heidetakse.

show ip rpf 192.0.2.10 trükib valitud liidese, järgmise hüppe ja marsruudi, mis otsuse tekitas, ja tavaliselt piisab sellest lahknevuse nägemiseks. Staatiline multicast-marsruut nagu ip mroute 192.0.2.0 255.255.255.0 tunnel0 tühistab selle prefiksi unicast-otsingu ja on õiguspärane parandus, kui multicast-topoloogia erineb tõesti unicast-topoloogiast. Käsitle seda konfiguratsioonina, mis tuleb dokumenteerida, mitte plaastrina, mis intsidendi ajal peale pandi ja seejärel unustati.

Kinnita liitumine käskudega, mitte pingiga

Ping tõestab, et unicast töötab, mida sa juba teadsid. Otsast otsani kinnitus on jada, mis näitab liitumist, kaardistust, naabrit ja puud selles järjekorras ning iga käsk vastab erinevale küsimusele.

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

Täidetud (S,G) kirje tõelise sissetuleva liidesega ja mittetühja väljaminevate loendiga tähendab, et juhtimistasand on oma töö lõpetanud. Kirje, mille sissetulev liides on Null, või RPF failed märgistusega loendur, mis üha kasvab, osutab tagasi eelmisele jaotisele, mitte tunnelile.

Kui kõik viis käsku näivad õiged ja vastuvõtja ei näe ikkagi midagi, on allesjäänud kahtlusalune tunneli enda poliitika: krüpto-ACL või tulemüürireegel, mis lubab unicast-marsruutimisprotokolli, kuid mitte PIM-i, IGMP-d ega grupi liiklust ennast. Poliitikal põhineval IPsec-tunnelil ei kanta multicast'i üldse, seega on vastuseks GRE või VTI lahendus, mitte veel üks filtrite erand. Kirjuta üles, milline viiest kontrollist ebaõnnestus, enne kui midagi muudad, ja seejärel muuda ainult seda kihti.