PIM-SM trans VPN: kontrolu BSR, RP-mapadon kaj RPF-vojojn

La tunelo funkcias, unuvoĉaj pingoj trapasas ĝin, kaj la ricevilo ankoraŭ montras nigran ekranon. En PIM-SM-ekspluatado tiu simptomo preskaŭ ĉiam signifas, ke unu el kvar regaj vojoj estas rompita, kaj ke la datena vojo neniam estis la problemo. Trairu la suban liston laŭorde kaj haltu ĉe la unua paŝo, kiu malsukcesas, ĉar ĉiu posta paŝo dependas de la antaŭa. Mi tenas ĉi tiujn kvin kontrolojn en malneta dosiero kaj gluas ilin en terminalon, kiam venas plendo pri multicast, kio malhelpas, ke la diagnozo fariĝu divenado.

Komencu ĉe la ricevilo, ne ĉe la tunelo

Ricevilo, kiu neniam petis la grupon, produktas neniun staton sur iu ajn enkursigilo, do konfirmu, ke la aliĝo ekzistas sur la segmento fronte al la ricevilo, antaŭ ol vi kontrolos ion alian. Sur Cisco-similaj platformoj, show ip igmp groups sur la enkursigilo de la lasta salto presas la aliĝintajn grupojn apud la interfaco, kiu aŭdis ilin. Kiam la grupo mankas en tiu eligo, la tunelo estas distro: la peto mortis ĉe la alira komutilo, ĉe la ingo de la gastiganto aŭ en VLAN sen querier.

Du ordinaraj kaŭzoj klarigas la plej multajn mankantajn aliĝojn, kiujn mi vidis: malakordo de IGMP-versio inter gastiganto kaj enkursigilo, kaj querier-elekto, kiu surteriĝis sur komutilo, kiu ne enkursigas. Tria estas pli subtila: la grupo estas aliĝinta, sed en la malĝusta VLAN, ĉar la gastiganto havas du retkartojn kaj la aplikaĵo ligiĝis al la malĝusta. IPv6-riceviloj havas la saman problemon kun MLD, kie show ipv6 mld groups respondas la saman demandon. Neniu el tiuj ĉi ripariĝas per tuŝado de la tunelo, kaj ĝuste tial la ordo gravas.

Post kiam la aliĝo estas videbla, konfirmu, ke PIM estas ŝaltita kaj sur la interfaco fronte al la ricevilo kaj sur la interfaco kondukanta al la rendevua punkto. Enkursigilo kun IGMP-membreco sed sen PIM sur sia supra interfaco tenos la grupon en loka tabelo kaj sendos nenion ien ajn.

Ĉu la BSR-aro atingas la alian flankon?

Bootstrap Router-mesaĝoj moviĝas saltante de salto al salto ene de unu PIM-domajno, kaj tiu estas la direkto, kiu rompiĝas trans tunelo. Kandidataj RP-oj sendas siajn anoncojn al la elektita BSR per unicast, do la parto RP-al-BSR kutime postvivas funkciantan tunnelon senŝanĝe. La inundo de Bootstrap-mesaĝoj en la alia direkto dependas de tio, ke ĉiu intera interfaco havas PIM ŝaltita, kaj de tio, ke nenio haltigas la mesaĝojn ĉe limo. RFC 5059 difinas tiun disdonadon kaj la administrajn amplekslimojn, kiuj rajtas mallongigi ĝin.

ip pim bsr-border-deklaro, ACL filtranta protokolon 103, aŭ politiko-bazita IPsec-tunelo, kiu ne povas porti multicast, ĉiu el ili tranĉos la inundon dum unicast restos sendifekta. Ĝuste tiu kombinaĵo igas la paneon aspekti kiel RP-problemo, kiam ĝi fakte estas atingebla-problemo, kaj tial mi legas la BSR-staton antaŭ ol legi la RP-agordon.

Sur la enkursigilo de la malproksima flanko, show ip pim bsr-router nomas la elektitan BSR kaj la lernitan RP-aron; se la eligo estas malplena, la malproksima flanko sidas en sia propra domajno kaj neniu kvanto da RP-agordo repacigos la du. Komparu la grupampleksojn kaj la RP-adresojn en show ip pim rp mapping sur ambaŭ flankoj de la tunelo. Mapado, kiu ekzistas nur loke, produktas komunan arbon, kiu finiĝas en la malĝusta loko, kaj la ricevilo atendas eterne.

Kongruigu la RP-mapadon sur ambaŭ flankoj de la tunelo

Statika RP, BSR kaj anycast-RP estas tri manieroj respondi la saman demandon, kaj miksi ilin trans tunelo estas fidinda maniero konstrui domajnon, kiu neniam konverĝas. Se la ĉefa kapo uzas BSR kaj la filio uzas statikan ip pim rp-address montrantan al alia adreso, la filio konstruas sian komunan arbon al RP, kiu tute ne scias, ke la ricevilo ekzistas. La mapado devas kongrui kaj pri la grupamplekso kaj pri la adreso, ĉar pli specifa amplekso venkas pli larĝan.

Anycast-RP ekzistas ĝuste por ke du ejoj povu kunhavigi unu RP-adreson, kaj indas nomi ĝin ĉi tie, ĉar ĝi ŝanĝas tion, kion signifas «la sama RP». Du RP-oj reklamantaj unu adreson estas kongruaj laŭdezajne; du RP-oj reklamantaj malsamajn adresojn por la sama amplekso ne estas, kiom ajn sana aspektas ĉiu ejo memstare.

Por font-specifa multicast ene de 232.0.0.0/8, la RP neniam estas demandita, do malplena RP-mapado ne aŭtomate estas paneo. Decidu, kiun servomodelon la aplikaĵo uzas, antaŭ ol postkuri RP-on, kiu neniam estis bezonata.

Legu la RPF-serĉon direkte al la fonto

PIM konstruas arbon inversigante la unicast-vojon, do la kontrolo, kiu gravas, estas la itinero reen al la fonto, aŭ reen al la RP por komuna arbo. Aliĝo, kiu alvenas sur interfacon, kiun la enkursigilo ne konsideras supra, estas forĵetata, kaj la kialo estas registrata kiel RPF-paneo anstataŭ kiel tunela paneo. Sur filia enkursigilo kun apriora itinero trans la tunelo kaj pli specifa itinero trans la WAN, la RPF-interfaco povas facile esti la WAN, kvankam la fonto atingeblas nur tra la tunelo. Tio estas la unuopa plej ofta kialo, ke aliĝo estas silente forĵetata.

show ip rpf 192.0.2.10 presas la elektitan interfacon, la sekvan salton kaj la itinero, kiu produktis la decidon, kio kutime sufiĉas por vidi la malakordon. Statika multicast-itinero kiel ip mroute 192.0.2.0 255.255.255.0 tunnel0 superregas la unicast-serĉon por tiu prefikso, kaj ĝi estas legitima korekto, kiam la multicast-topologio vere diferencas de la unicast-topologio. Traktu ĝin kiel agordon, kiun oni dokumentu, ne kiel flikaĵon aplikitan dum okazaĵo kaj poste forgesitan.

Konfirmu la aliĝon per komandoj, ne per ping

Ping pruvas, ke unicast funkcias, kion vi jam sciis. La fin-al-fin-konfirmo estas sinsekvo, kiu montras la aliĝon, la mapadon, la najbaron kaj la arbon en tiu ordo, kaj ĉiu komando respondas alian demandon.

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

Plenigita (S,G)-ero kun reala ena interfaco kaj ne-malplena ela listo signifas, ke la rega ebeno finis sian laboron. Ero, kies ena interfaco estas legata kiel Null, aŭ nombrilo etikedita RPF failed, kiu daŭre grimpas, indikas reen al la antaŭa sekcio anstataŭ al la tunelo.

Se ĉiuj kvin komandoj aspektas ĝustaj kaj la ricevilo ankoraŭ vidas nenion, la restanta suspektato estas la propra politiko de la tunelo: kripto-ACL aŭ fajroŝirma regulo, kiu permesas la unicast-enkursigan protokolon sed ne PIM, IGMP aŭ la grupan trafikon mem. Sur politiko-bazita IPsec-tunelo, multicast tute ne estas portata, do la respondo estas GRE- aŭ VTI-dezajno anstataŭ plia filtrila escepto. Notu, kiu el la kvin kontroloj malsukcesis, antaŭ ol vi ŝanĝos ion, kaj poste ŝanĝu nur tiun tavolon.