PIM-SM VPN baten bidez: egiaztatu BSR, RP mapaketa eta RPF bideak

Tunela martxan dago, unicast ping-ak zeharkatzen du, eta hargailuak pantaila beltza erakusten du oraindik. PIM-SM ezarpen batean sintoma horrek ia beti esan nahi du lau kontrol-bidetako bat hautsi dela, eta datu-bidea ez zela inoiz arazoa izan. Irakurri beheko zerrenda ordenan eta gelditu huts egiten duen lehen urratsean, ondorengo urrats bakoitza aurrekoaren mende baitago. Bost proba hauek zirriborro fitxategi batean gordetzen ditut eta terminalean itsasten ditut multicast kexa bat iristen denean, eta horrek diagnostikoa asmakizun bihurtzea eragozten du.

Hasi hargailutik, ez tunelatik

Taldea inoiz eskatu ez duen hargailu batek ez du egoerarik sortzen inongo bideratzailetan, beraz egiaztatu konexioa hargailuaren aurkako segmentuan dagoela, beste ezer ikuskatu aurretik. Cisco estiloko plataformetan, show ip igmp groups azken jauziko bideratzailean elkartutako taldeak inprimatzen ditu entzun dituen interfazearen ondoan. Irteera horretan taldea falta denean, tunela distrazioa da: eskaera sarbide-kommutagailuan, ostalariaren socketan edo querier-ik gabeko VLAN batean hil zen.

Bi arrazoi arruntek azaltzen dute ikusi ditudan falta diren konexio gehienak: ostalariaren eta bideratzailearen arteko IGMP bertsio-desadostasuna, eta bideratzen ez duen kommutagailu batera iritsi zen querier hautaketa. Hirugarrena sotilagoa da: taldea elkartuta dago baina VLAN okerrean, ostalariak bi sare-txartel baititu eta aplikazioa okerrekoari lotu baitzaio. IPv6 hargailuek arazo baliokidea dute MLD-rekin, non show ipv6 mld groups galdera berari erantzuten dion. Horietako bat ere ez da konpontzen tunelari ukitzean, eta horregatik da garrantzitsua ordena.

Konexioa ikusgai dagoenean, egiaztatu PIM gaituta dagoela hargailuaren aurkako interfazean eta topaketa-punturantz doan interfazean ere. IGMP kidetza duen baina goiko interfazean PIM ez duen bideratzaile batek taldea tokiko taula batean mantenduko du eta ez du ezer bidaliko inora.

BSR multzoak beste aldera iristen al du?

Bootstrap Router mezuak jauzi batetik bestera mugitzen dira PIM domeinu bakar baten barruan, eta hori da tuneletik zehar hausten den norabidea. RP hautagaiek beren iragarkiak hautatutako BSR-ra unicast bidez bidaltzen dituzte, beraz RP-tik BSR-rako zatia lanean dagoen tunel batean aldaketarik gabe irauten du normalean. Beste norabideko Bootstrap mezuen uholdeak tartean dauden interfaze guztiek PIM gaituta izatearen eta ezerk mezuei muga batean eusteari zor zaio. RFC 5059 RFCak banaketa hori eta hura laburtzea onartzen duten administrazio-esparruaren mugak definitzen ditu.

ip pim bsr-border adierazpen batek, 103 protokoloa iragazten duen ACL batek edo multicast eramaterik ez duen politika oinarritutako IPsec tunel batek uholdea moztuko dute, unicast ukitu gabe geratzen dela. Konbinazio horrek egiten du hutsegitea RPren arazo dirudien arren benetan irismen-arazoa denean, eta horregatik irakurtzen dut BSR egoera RP konfigurazioa baino lehen.

Urruneko aldeko bideratzailean, show ip pim bsr-router aginduak hautatutako BSR eta ikasitako RP multzoa adierazten ditu; irteera hutsa bada, urruneko aldea bere domeinuan dago eta RP konfigurazioak ez du biak ados jarriko. Konparatu talde-barrutiak eta RP helbideak show ip pim rp mapping irteeran tunelaren bi aldeetan. Tokian bakarrik dagoen mapaketak leku okerrean amaitzen den zuhaitz partekatua sortzen du, eta hargailuak betiko itxaroten du.

Bat etorri RP mapaketa tunelaren bi aldeetan

RP estatikoa, BSR eta anycast-RP galdera berari erantzuteko hiru modu dira, eta horiek tuneletik zehar nahastea inoiz bat egiten ez duen domeinu bat eraikitzeko modu fidagarria da. Burualdeak BSR erabiltzen badu eta adarrak beste helbide bat seinalatzen duen ip pim rp-address estatikoa erabiltzen badu, adarrak bere zuhaitz partekatua hargailua badenik ez dakien RP baterantz eraikitzen du. Mapaketak talde-barrutian eta helbidean bat etorri behar du, barruti zehatzagoek zabalagoak irabazten baitituzte.

Anycast-RP hain zuzen ere bi guneek RP helbide bat partekatu ahal izateko dago, eta merezi du hemen aipatzea, «RP bera» zer den aldatzen baitu. Helbide bat iragartzen duten bi RP koherenteak dira diseinuz; barruti bererako helbide ezberdinak iragartzen dituzten bi RP ez dira koherenteak, gune bakoitza bere horretan zenbat ere osasuntsu egon.

232.0.0.0/8 barruko iturri-espezifikoko multicastarentzat, ez zaio inoiz RPri galdetzen, beraz RP mapaketa hutsa ez da automatikoki hutsegite bat. Erabaki zer zerbitzu-eredu erabiltzen duen aplikazioak inoiz behar ez zen RP baten atzetik hasi aurretik.

Irakurri RPF bilaketa iturriaren norabidean

PIM zuhaitza unicast bidea alderantziz bihurtuz eraikitzen du, beraz garrantzitsua den egiaztapena iturrira itzultzeko bidea da, edo RPra itzultzeko bidea zuhaitz partekatu batentzat. Bideratzaileak goiko jotzen ez duen interfaze batetik iristen den konexioa baztertu egiten da, eta arrazoia RPF hutsegite gisa erregistratzen da, tunel hutsegite gisa ez. Tunnelaren gaineko bide lehenetsia eta WANaren gaineko bide zehatzagoa dituen adar-bideratzaile batean, RPF interfazea WANa izan daiteke erraz, iturria tuneletik soilik iristekoa den arren. Hori da konexio bat isilki baztertzeko arrazoi arruntena.

show ip rpf 192.0.2.10 aginduak hautatutako interfazea, hurrengo jauzia eta erabakia sortu zuen bidea inprimatzen ditu, eta hori normalean nahikoa izaten da desadostasuna ikusteko. ip mroute 192.0.2.0 255.255.255.0 tunnel0 bezalako multicast bide estatiko batek aurrizki horretarako unicast bilaketa gainidazten du, eta zuzenketa zilegia da multicast topologia unicast topologiatik benetan ezberdina denean. Dokumentatu beharreko konfigurazio gisa hartu, ez istilu batean aplikatu eta gero ahaztu den adabaki gisa.

Egiaztatu konexioa aginduekin, ez ping batekin

Pingak unicast-a dabilela frogatzen du, hori bazekizun. Muturretik muturrerako egiaztapena konexioa, mapaketa, auzokidea eta zuhaitza ordena horretan erakusten dituen segida bat da, eta agindu bakoitzak galdera ezberdin bati erantzuten dio.

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

(S,G) sarrera betea, benetako sarrerako interfazearekin eta irteten diren zerrenda ez hutsarekin, kontrol-planoak bere lana amaitu duela esan nahi du. Sarrerako interfazea Null irakurtzen duen sarrera batek, edo gora egiten jarraitzen duen RPF failed etiketadun kontagailu batek, aurreko atalera seinalatzen dute, tunelera ez.

Bost aginduak zuzenak dirudite eta hargailuak oraindik ezer ikusten ez badu, geratzen den susmagarria tunelaren beraren politika da: unicast bideratze-protokoloa onartzen duen baina PIM, IGMP edo talde-trafikoa bera onartzen ez dituen kripto ACL edo suebaki arau bat. Politika oinarritutako IPsec tunel batean multicast ez da batere eramaten, beraz erantzuna GRE edo VTI diseinu bat da, ez beste iragazki-salbuesspen bat. Idatzi bost probetatik zein huts egin zuen ezer aldatu aurretik, eta gero aldatu bakarrik geruza hori.