PIM-SM përmes një VPN: kontrolloni BSR, hartëzimin e RP dhe rrugët RPF

Tuneli është aktiv, ping-et unicast kalojnë nëpër të, dhe marrësi ende shfaq një ekran të zi. Në një vendosje PIM-SM ai simptom pothuajse gjithmonë do të thotë që një nga katër rrugët e kontrollit është thyer, dhe se rruga e të dhënave nuk ishte kurrë problemi. Kaloni listën më poshtë sipas radhës dhe ndaloni në hapin e parë që dështon, sepse çdo hap pasues varet nga ai i mëparshmi. I mbaj këto pesë kontrolle në një skedar drafti dhe i ngjit në një terminal kur vjen një ankesë për multicast, gjë që e pengon diagnozën të kthehet në hamendje.

Filloni te marrësi, jo te tuneli

Një marrës që nuk e ka kërkuar kurrë grupin nuk krijon asnjë gjendje në asnjë router, prandaj përpara se të inspektoni çdo gjë tjetër konfirmoni që bashkimi ekziston në segmentin përballë marrësit. Në platformat e stilit Cisco, show ip igmp groups në router-in e hopit të fundit shtyp grupet e bashkuara pranë ndërfaqes që i dëgjoi. Kur grupi mungon në atë dalje, tuneli është shpërqendrim: kërkesa vdiq në komutatorin e aksesit, në socket-in e hostit ose në një VLAN pa querier.

Dy shkaqe të zakonshme shpjegojnë shumicën e bashkimeve që mungojnë që kam parë: një mospërputhje e versionit IGMP midis hostit dhe router-it, dhe një zgjedhje querier që përfundoi në një komutator që nuk bën routing. E treta është më delikate: grupi është bashkuar por në VLAN-in e gabuar, sepse hosti ka dy karta rrjeti dhe aplikacioni u lidh me atë të gabuarën. Marrësit IPv6 kanë të njëjtin problem me MLD, ku show ipv6 mld groups përgjigjet për të njëjtën pyetje. Asnjëra prej tyre nuk rregullohet duke prekur tunelin, dhe pikërisht për këtë rendi ka rëndësi.

Pasi bashkimi të jetë i dukshëm, konfirmoni që PIM është aktiv si në ndërfaqen përballë marrësit ashtu edhe në ndërfaqen që të çon drejt pikës së takimit. Një router me anëtarësim IGMP por pa PIM në ndërfaqen e tij të sipërme do ta mbajë grupin në një tabelë lokale dhe nuk do të dërgojë asgjë askund.

A arrin grupi BSR në anën tjetër?

Mesazhet Bootstrap Router lëvizin hop pas hopi brenda një domeni të vetëm PIM, dhe pikërisht ky drejtim thyhet përmes një tuneli. RP-të kandidate i dërgojnë njoftimet e tyre BSR-së të zgjedhur me unicast, kështu që segmenti RP-deri-BSR zakonisht i mbijeton të paprekur një tuneli që funksionon. Përmbytja e mesazheve Bootstrap në drejtimin tjetër varet nga fakti që çdo ndërfaqe e ndërmjetme ka PIM të aktivizuar dhe nga fakti që asgjë nuk i ndalon mesazhet në një kufi. RFC 5059 përcakton atë shpërndarje dhe kufijtë e shtrirjes administrative që lejohen ta shkurtojnë atë.

Një deklaratë ip pim bsr-border, një ACL që filtron protokollin 103, ose një tunel IPsec i bazuar në politika që nuk mund të mbajë multicast, secili prej tyre do ta presë përmbytjen duke e lënë unicast-in të paprekur. Pikërisht ai kombinim e bën dështimin të duket si problem RP kur në të vërtetë është problem arritshmërie, dhe për këtë arsye e lexoj gjendjen e BSR-së përpara konfigurimit të RP-së.

Në router-in e anës së largët, show ip pim bsr-router emërton BSR-në e zgjedhur dhe grupin e RP-ve të mësuar; nëse dalja është bosh, ana e largët rri në domenin e vet dhe asnjë konfigurim RP nuk do t'i pajtojë të dyja. Krahasoni intervalet e grupeve dhe adresat e RP-ve në show ip pim rp mapping në të dyja anët e tunelit. Një hartëzim që ekziston vetëm lokalisht prodhon një pemë të përbashkët që përfundon në vendin e gabuar, dhe marrësi pret përgjithmonë.

Përputhni hartëzimin e RP-së në të dyja anët e tunelit

RP statike, BSR dhe anycast-RP janë tre mënyra për t'iu përgjigjur të njëjtës pyetje, dhe përzierja e tyre përmes një tuneli është një mënyrë e sigurt për të ndërtuar një domen që nuk konvergjon kurrë. Nëse skaji kryesor përdor BSR dhe dega përdor një ip pim rp-address statike që tregon një adresë tjetër, dega e ndërton pemën e saj të përbashkët drejt një RP që nuk e di se marrësi ekziston. Hartëzimi duhet të pajtohet si në intervalin e grupit ashtu edhe në adresë, pasi një interval më specifik fiton mbi një më të gjerë.

Anycast-RP ekziston pikërisht që dy site të mund të ndajnë një adresë RP, dhe ia vlen të përmendet këtu sepse ndryshon kuptimin e «të njëjtit RP». Dy RP që shpallin një adresë janë konsistente nga dizajni; dy RP që shpallin adresa të ndryshme për të njëjtin interval nuk janë, sado i shëndetshëm të duket secili site më vete.

Për multicast specifik për burimin brenda 232.0.0.0/8, RP-ja nuk pyetet kurrë, prandaj një hartëzim RP bosh nuk është automatikisht defekt. Vendosni cilin model shërbimi përdor aplikacioni përpara se të ndiqni një RP që nuk ishte kurrë i nevojshëm.

Lexoni kërkimin RPF drejt burimit

PIM ndërton një pemë duke përmbysur rrugën unicast, prandaj kontrolli që ka rëndësi është rruga përsëri drejt burimit, ose përsëri drejt RP-së për një pemë të përbashkët. Një bashkim që arrin në një ndërfaqe që router-i nuk e konsideron të sipërme hidhet poshtë, dhe arsyeja regjistrohet si dështim RPF dhe jo si dështim tuneli. Në një router dege me një rrugë parazgjedhje mbi tunelin dhe një rrugë më specifike mbi WAN, ndërfaqja RPF mund të jetë lehtësisht WAN, edhe pse burimi është i arritshëm vetëm përmes tunelit. Kjo është arsyeja më e zakonshme e vetme që një bashkim hidhet poshtë në heshtje.

show ip rpf 192.0.2.10 shtyp ndërfaqen e zgjedhur, hopin e ardhshëm dhe rrugën që prodhoi vendimin, dhe zakonisht kjo mjafton për të parë mospërputhjen. Një rrugë multicast statike si ip mroute 192.0.2.0 255.255.255.0 tunnel0 anashkalon kërkimin unicast për atë prefiks, dhe është një rregullim legjitim kur topologjia multicast ndryshon vërtet nga topologjia unicast. Trajtojeni si konfigurim që duhet dokumentuar, jo si një arnë e vendosur gjatë një incidenti dhe më pas e harruar.

Konfirmoni bashkimin me komanda, jo me ping

Ping provon se unicast funksionon, gjë që ju e dinit tashmë. Konfirmimi nga fundi në fund është një sekuencë që tregon bashkimin, hartëzimin, fqinjin dhe pemën në atë rend, dhe çdo komandë përgjigjet për një pyetje tjetër.

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

Një hyrje (S,G) e plotësuar me një ndërfaqe të vërtetë hyrëse dhe një listë dalëse jo të zbrazët do të thotë që plani i kontrollit e ka përfunduar punën e tij. Një hyrje ndërfaqja hyrëse e së cilës lexohet si Null, ose një numërues i etiketuar RPF failed që vazhdon të rritet, tregon përsëri në seksionin e mëparshëm dhe jo te tuneli.

Nëse të pesë komandat duken të sakta dhe marrësi ende nuk sheh asgjë, i dyshuari i mbetur është politika e vetë tunelit: një ACL kripto ose një rregull muri zjarri që lejon protokollin e routing unicast por jo PIM, IGMP ose vetë trafikun e grupit. Në një tunel IPsec të bazuar në politika, multicast-i nuk transportohet fare, prandaj përgjigjja është një dizajn GRE ose VTI dhe jo një tjetër përjashtim filtri. Shkruani cila nga të pesë kontrollet dështoi përpara se të ndryshoni çdo gjë, dhe pastaj ndryshoni vetëm atë shtresë.