PIM-SM per VPN: patikrinkite BSR, RP atvaizdavimą ir RPF maršrutus

Tunelis veikia, unicast pingai eina per jį, o imtuvas vis tiek rodo juodą ekraną. PIM-SM diegime šis simptomas beveik visada reiškia, kad sulaužytas vienas iš keturių valdymo kelių, o duomenų kelias niekada nebuvo problema. Peržiūrėkite toliau pateiktą sąrašą eilės tvarka ir sustokite ties pirmuoju nepavykusiu žingsniu, nes kiekvienas vėlesnis žingsnis priklauso nuo ankstesnio. Šiuos penkis patikrinimus laikau juodraščio faile ir įklijuoju į terminalą, kai ateina multicast skundas, ir tai neleidžia diagnostikai virsti spėliojimais.

Pradėkite nuo imtuvo, o ne nuo tunelio

Imtuvas, kuris niekada neprašė grupės, nesukuria jokios būsenos jokiame maršrutizatoriuje, todėl prieš tikrindami ką nors kita įsitikinkite, kad prisijungimas egzistuoja imtuvo pusėje esančiame segmente. Cisco stiliaus platformose paskutinio šuolio maršrutizatoriuje show ip igmp groups išspausdina prisijungtas grupes šalia sąsajos, kuri jas išgirdo. Kai grupės tame išvestyje nėra, tunelis yra dėmesio nukreipimas: užklausa mirė prieigos komutatoriuje, pagrindinio kompiuterio lizde arba VLAN, kuriame nėra querier.

Dvi kasdienės priežastys paaiškina daugumą mano matytų trūkstamų prisijungimų: IGMP versijos neatitikimas tarp pagrindinio kompiuterio ir maršrutizatoriaus bei querier rinkimai, kurie atsidūrė komutatoriuje, kuris nemaršrutizuoja. Trečioji yra subtilesnė: grupė prisijungta, bet netinkamame VLAN, nes pagrindinis kompiuteris turi dvi tinklo plokštes, o programa prisirišo prie netinkamos. IPv6 imtuvai turi tą pačią problemą su MLD, kur show ipv6 mld groups atsako į tą patį klausimą. Nė viena iš jų neištaisoma prisilietus prie tunelio, ir būtent todėl tvarka yra svarbi.

Kai prisijungimas matomas, patvirtinkite, kad PIM įjungtas tiek imtuvo pusėje esančioje sąsajoje, tiek sąsajoje, kuri veda link susitikimo taško. Maršrutizatorius, turintis IGMP narystę, bet neturintis PIM savo aukštutinėje sąsajoje, laikys grupę vietinėje lentelėje ir nieko niekur nesiųs.

Ar BSR rinkinys pasiekia kitą pusę?

Bootstrap Router pranešimai juda šuolis po šuolio vieno PIM domeno viduje, ir būtent ši kryptis lūžta per tunelį. Kandidatų RP savo skelbimus siunčia išrinktajam BSR unicast būdu, todėl RP–BSR atkarpa paprastai išlieka nepakitusi veikiančiame tunelyje. Bootstrap pranešimų srautas priešinga kryptimi priklauso nuo to, ar kiekviena tarpinė sąsaja turi įjungtą PIM, ir nuo to, ar niekas nesustabdo pranešimų prie ribos. RFC 5059 apibrėžia tą paskirstymą ir administracinės apimties ribas, kurioms leidžiama jį sutrumpinti.

ip pim bsr-border teiginys, 103 protokolą filtruojantis ACL arba politika pagrįstas IPsec tunelis, kuris negali perduoti multicast, kiekvienas nutrauks srautą, o unicast liks nepaliestas. Būtent šis derinys verčia gedimą atrodyti kaip RP problema, nors iš tikrųjų tai pasiekiamumo problema, ir todėl aš skaitau BSR būseną prieš skaitydamas RP konfigūraciją.

Tolimojoje pusėje esančiame maršrutizatoriuje show ip pim bsr-router nurodo išrinktą BSR ir išmoktą RP rinkinį; jei išvestis tuščia, tolimoji pusė sėdi savo domene ir jokia RP konfigūracija nesutaikys abiejų. Palyginkite grupių diapazonus ir RP adresus show ip pim rp mapping išvestyje abiejose tunelio pusėse. Atvaizdavimas, egzistuojantis tik vietoje, sukuria bendrą medį, kuris baigiasi netinkamoje vietoje, o imtuvas laukia amžinai.

Suderinkite RP atvaizdavimą abiejose tunelio pusėse

Statinis RP, BSR ir anycast-RP yra trys būdai atsakyti į tą patį klausimą, o jų maišymas per tunelį yra patikimas būdas sukurti domeną, kuris niekada nesusilieja. Jei pagrindinis galas naudoja BSR, o filialas naudoja statinį ip pim rp-address, nukreiptą į kitą adresą, filialas stato savo bendrą medį link RP, kuris net neįtaria, kad imtuvas egzistuoja. Atvaizdavimas turi sutapti ir pagal grupių diapazoną, ir pagal adresą, nes konkretesnis diapazonas nugali platesnį.

Anycast-RP egzistuoja būtent tam, kad du objektai galėtų dalytis vienu RP adresu, ir verta jį čia paminėti, nes jis pakeičia reikšmę to, kas yra „tas pats RP“. Du RP, skelbiantys vieną adresą, pagal projektą yra nuoseklūs; du RP, skelbiantys skirtingus adresus tam pačiam diapazonui, nėra, kad ir kaip sveikai atrodytų kiekvienas objektas atskirai.

Šaltinio specifiniam multicast diapazone 232.0.0.0/8 RP niekada neklausiama, todėl tuščias RP atvaizdavimas automatiškai nėra gedimas. Nuspręskite, kokį paslaugų modelį naudoja programa, prieš vaikydamiesi RP, kurio niekada neprireikė.

Perskaitykite RPF paiešką šaltinio link

PIM stato medį apversdamas unicast kelią, todėl svarbus patikrinimas yra maršrutas atgal į šaltinį arba atgal į RP bendro medžio atveju. Prisijungimas, atėjęs į sąsają, kurios maršrutizatorius nelaiko aukštutine, išmetamas, o priežastis registruojama kaip RPF gedimas, o ne kaip tunelio gedimas. Filialo maršrutizatoriuje, turinčiame numatytąjį maršrutą per tunelį ir konkretesnį maršrutą per WAN, RPF sąsaja gali lengvai būti WAN, nors šaltinis pasiekiamas tik per tunelį. Tai vienintelė dažniausia priežastis, kodėl prisijungimas tyliai išmetamas.

show ip rpf 192.0.2.10 išspausdina pasirinktą sąsają, kitą šuolį ir maršrutą, kuris lėmė sprendimą, ir to paprastai pakanka neatitikimui pamatyti. Statinis multicast maršrutas, toks kaip ip mroute 192.0.2.0 255.255.255.0 tunnel0, nepaiso unicast paieškos tam prefiksui, ir tai yra teisėta pataisa, kai multicast topologija iš tikrųjų skiriasi nuo unicast topologijos. Traktuokite jį kaip konfigūraciją, kurią reikia dokumentuoti, o ne kaip pleistrą, uždėtą per incidentą ir paskui pamirštą.

Patvirtinkite prisijungimą komandomis, o ne ping

Ping įrodo, kad unicast veikia, ką jūs jau žinojote. Patvirtinimas nuo galo iki galo yra seka, kuri rodo prisijungimą, atvaizdavimą, kaimyną ir medį būtent šia tvarka, ir kiekviena komanda atsako į kitą klausimą.

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

Užpildytas (S,G) įrašas su tikra įeinančia sąsaja ir netuščiu išeinančių sąrašu reiškia, kad valdymo plokštė baigė savo darbą. Įrašas, kurio įeinanti sąsaja rodoma kaip Null, arba skaitiklis, pažymėtas RPF failed, kuris vis kyla, nurodo atgal į ankstesnį skyrių, o ne į tunelį.

Jei visos penkios komandos atrodo teisingai, o imtuvas vis tiek nieko nemato, likęs įtariamasis yra paties tunelio politika: kriptografinis ACL arba ugniasienės taisyklė, leidžianti unicast maršrutizavimo protokolą, bet ne PIM, IGMP ar patį grupės srautą. Politikos pagrindu veikiančiame IPsec tunelyje multicast iš viso neperduodamas, todėl atsakymas yra GRE arba VTI projektas, o ne dar viena filtrų išimtis. Užsirašykite, kuris iš penkių patikrinimų nepavyko, prieš ką nors keisdami, ir tada keiskite tik tą sluoksnį.