PIM-SM prin VPN: verificați BSR, maparea RP și căile RPF

Tunelul este activ, pingurile unicast îl traversează, iar receptorul afișează în continuare un ecran negru. Într-o implementare PIM-SM acest simptom înseamnă aproape întotdeauna că una dintre cele patru căi de control este ruptă și că calea de date nu a fost niciodată problema. Parcurgeți lista de mai jos în ordine și opriți-vă la primul pas care eșuează, pentru că fiecare pas ulterior depinde de cel anterior. Țin aceste cinci verificări într-un fișier de schiță și le lipesc într-un terminal când apare o reclamație despre multicast, ceea ce împiedică diagnosticul să devină presupuneri.

Începeți cu receptorul, nu cu tunelul

Un receptor care nu a cerut niciodată grupul nu creează nicio stare pe niciun router, așa că înainte de a inspecta orice altceva confirmați că alăturarea există pe segmentul orientat spre receptor. Pe platforme de tip Cisco, show ip igmp groups pe routerul ultimului salt tipărește grupurile alăturate lângă interfața care le-a auzit. Când grupul lipsește din acea ieșire, tunelul este o distragere: cererea a murit la switchul de acces, la socketul gazdei sau într-un VLAN fără querier.

Două cauze banale explică majoritatea alăturărilor lipsă pe care le-am văzut: o nepotrivire de versiune IGMP între gazdă și router și o alegere de querier care a ajuns pe un switch care nu rutează. A treia este mai subtilă: grupul este alăturat, dar în VLAN-ul greșit, pentru că gazda are două plăci de rețea și aplicația s-a legat de cea greșită. Receptorii IPv6 au aceeași problemă cu MLD, unde show ipv6 mld groups răspunde la aceeași întrebare. Niciuna dintre acestea nu se rezolvă atingând tunelul, și exact de aceea ordinea contează.

Odată ce alăturarea este vizibilă, confirmați că PIM este activat atât pe interfața orientată spre receptor, cât și pe interfața care duce spre punctul de întâlnire. Un router cu apartenență IGMP dar fără PIM pe interfața sa superioară va ține grupul într-un tabel local și nu va trimite nimic nicăieri.

Ajunge setul BSR în partea cealaltă?

Mesajele Bootstrap Router se deplasează salt cu salt în interiorul unui singur domeniu PIM, iar aceasta este direcția care se rupe printr-un tunel. RP-urile candidate își trimit anunțurile către BSR-ul ales prin unicast, așa că porțiunea RP-spre-BSR supraviețuiește de obicei neschimbată într-un tunel funcțional. Fluxul de mesaje Bootstrap în cealaltă direcție depinde de faptul că fiecare interfață intermediară are PIM activat și că nimic nu oprește mesajele la o frontieră. RFC 5059 definește acea distribuție și frontierele sferei administrative care au voie să o scurteze.

O instrucțiune ip pim bsr-border, o ACL care filtrează protocolul 103 sau un tunel IPsec bazat pe politici care nu poate transporta multicast vor tăia fiecare fluxul, lăsând unicast-ul intact. Exact această combinație face defecțiunea să pară o problemă de RP când de fapt este o problemă de accesibilitate, și de aceea citesc starea BSR înainte de configurația RP.

Pe routerul din partea îndepărtată, show ip pim bsr-router numește BSR-ul ales și setul RP învățat; dacă ieșirea este goală, partea îndepărtată stă în propriul domeniu și nicio configurație RP nu le va împăca pe cele două. Comparați intervalele de grup și adresele RP din show ip pim rp mapping pe ambele părți ale tunelului. O mapare care există doar local produce un arbore partajat care se termină în locul greșit, iar receptorul așteaptă la nesfârșit.

Aliniați maparea RP pe ambele părți ale tunelului

RP static, BSR și anycast-RP sunt trei moduri de a răspunde la aceeași întrebare, iar amestecarea lor printr-un tunel este o modalitate sigură de a construi un domeniu care nu converge niciodată. Dacă capătul principal folosește BSR iar filiala folosește un ip pim rp-address static care indică o altă adresă, filiala își construiește arborele partajat spre un RP care nu știe că receptorul există. Maparea trebuie să fie de acord atât asupra intervalului de grup, cât și asupra adresei, deoarece un interval mai specific câștigă în fața unuia mai larg.

Anycast-RP există exact pentru ca două locații să poată împărți o singură adresă RP, și merită menționat aici pentru că schimbă ce înseamnă „același RP”. Două RP-uri care anunță o adresă sunt consecvente prin proiectare; două RP-uri care anunță adrese diferite pentru același interval nu sunt, oricât de sănătoasă ar părea fiecare locație în parte.

Pentru multicast specific sursei în interiorul 232.0.0.0/8, RP-ul nu este niciodată consultat, așa că o mapare RP goală nu este automat o defecțiune. Decideți ce model de serviciu folosește aplicația înainte de a urmări un RP care nu a fost niciodată necesar.

Citiți căutarea RPF spre sursă

PIM construiește un arbore inversând calea unicast, așa că verificarea care contează este ruta înapoi spre sursă, sau înapoi spre RP pentru un arbore partajat. O alăturare care sosește pe o interfață pe care routerul nu o consideră superioară este eliminată, iar motivul este înregistrat ca eșec RPF și nu ca eșec al tunelului. Pe un router de filială cu o rută implicită peste tunel și o rută mai specifică peste WAN, interfața RPF poate fi cu ușurință WAN, deși sursa este accesibilă doar prin tunel. Acesta este cel mai frecvent motiv pentru care o alăturare este eliminată în tăcere.

show ip rpf 192.0.2.10 tipărește interfața aleasă, următorul salt și ruta care a produs decizia, ceea ce de obicei este suficient pentru a vedea nepotrivirea. O rută multicast statică precum ip mroute 192.0.2.0 255.255.255.0 tunnel0 ignoră căutarea unicast pentru acel prefix, și este o corectare legitimă atunci când topologia multicast diferă cu adevărat de topologia unicast. Tratați-o ca pe o configurație care trebuie documentată, nu ca pe un plasture aplicat în timpul unui incident și apoi uitat.

Confirmați alăturarea cu comenzi, nu cu un ping

Ping-ul dovedește că unicast-ul funcționează, ceea ce știați deja. Confirmarea de la un capăt la altul este o secvență care arată alăturarea, maparea, vecinul și arborele în acea ordine, iar fiecare comandă răspunde la o întrebare diferită.

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

O intrare (S,G) populată cu o interfață de intrare reală și o listă de ieșire nevidă înseamnă că planul de control și-a terminat treaba. O intrare a cărei interfață de intrare se citește ca Null, sau un contor etichetat RPF failed care continuă să crească, indică înapoi spre secțiunea anterioară și nu spre tunel.

Dacă toate cele cinci comenzi par corecte și receptorul tot nu vede nimic, suspectul rămas este politica tunelului însuși: o ACL criptografică sau o regulă de firewall care permite protocolul de rutare unicast dar nu PIM, IGMP sau traficul grupului în sine. Pe un tunel IPsec bazat pe politici, multicast-ul nu este transportat deloc, așa că răspunsul este un design GRE sau VTI și nu încă o excepție de filtru. Notați care dintre cele cinci verificări a eșuat înainte de a schimba ceva, apoi schimbați doar acel strat.