PIM-SM a través d'una VPN: comproveu BSR, mapatge d'RP i camins RPF

El túnel està aixecat, els pings unicast el travessen i el receptor encara mostra una pantalla negra. En una implantació de PIM-SM aquest símptoma gairebé sempre vol dir que un dels quatre camins de control està trencat, i que el camí de dades mai no va ser el problema. Seguiu la llista de sota en ordre i atureu-vos al primer pas que falli, perquè cada pas posterior depèn de l'anterior. Tinc aquestes cinc comprovacions en un fitxer d'esborrany i les enganxo en un terminal quan arriba una queixa de multicast, cosa que evita que el diagnòstic es converteixi en conjectures.

Comenceu pel receptor, no pel túnel

Un receptor que mai no ha demanat el grup no genera cap estat a cap encaminador, així que confirmeu que la unió existeix al segment orientat al receptor abans d'inspeccionar qualsevol altra cosa. A les plataformes d'estil Cisco, show ip igmp groups a l'encaminador de l'últim salt mostra els grups units al costat de la interfície que els ha sentit. Quan el grup falta en aquesta sortida, el túnel és una distracció: la petició va morir al commutador d'accés, al sòcol de l'amfitrió o en una VLAN sense querier.

Dues causes mundanes expliquen la majoria d'unions que falten que he vist: una discrepància de versió d'IGMP entre l'amfitrió i l'encaminador, i una elecció de querier que va caure en un commutador que no encamina. La tercera és més subtil: el grup està unit però en una VLAN equivocada, perquè l'amfitrió té dues targetes de xarxa i l'aplicació es va enllaçar a la incorrecta. Els receptors IPv6 tenen el problema equivalent amb MLD, on show ipv6 mld groups respon la mateixa pregunta. Cap d'aquestes no es corregeix tocant el túnel, i és exactament per això que l'ordre importa.

Un cop la unió és visible, confirmeu que PIM està activat tant a la interfície orientada al receptor com a la interfície que porta cap al punt de trobada. Un encaminador amb pertinença IGMP però sense PIM a la interfície ascendent retindrà el grup en una taula local i no enviarà res enlloc.

Arriba el conjunt de BSR a l'altre costat?

Els missatges de Bootstrap Router avancen salt a salt dins d'un sol domini PIM, i aquesta és la direcció que es trenca a través d'un túnel. Els RP candidats envien els seus anuncis al BSR elegit per unicast, així que el tram RP-a-BSR normalment sobreviu intacte en un túnel que funciona. La inundació de missatges Bootstrap en l'altra direcció depèn que cada interfície intermèdia tingui PIM activat i que res no aturi els missatges en una frontera. RFC 5059 defineix aquesta distribució i les fronteres d'abast administratiu que poden escurçar-la.

Una declaració ip pim bsr-border, una ACL que filtri el protocol 103 o un túnel IPsec basat en polítiques que no pugui transportar multicast tallaran cadascun la inundació mentre deixen l'unicast intacte. Aquesta combinació és el que fa que la fallada sembli un problema d'RP quan en realitat és un problema d'abastabilitat, i és per això que llegeixo l'estat del BSR abans de la configuració de l'RP.

A l'encaminador del costat llunyà, show ip pim bsr-router indica el BSR elegit i el conjunt d'RP après; si la sortida és buida, el costat llunyà seu en el seu propi domini i cap configuració d'RP no reconciliarà els dos. Compareu els rangs de grup i les adreces d'RP a show ip pim rp mapping als dos costats del túnel. Un mapatge que només existeix localment produeix un arbre compartit que acaba al lloc equivocat, i el receptor espera per sempre.

Feu coincidir el mapatge d'RP als dos costats del túnel

RP estàtic, BSR i anycast-RP són tres maneres de respondre la mateixa pregunta, i barrejar-les a través d'un túnel és una manera fiable de construir un domini que no convergeix mai. Si el capdavant usa BSR i la sucursal usa un ip pim rp-address estàtic apuntant a una adreça diferent, la sucursal construeix el seu arbre compartit cap a un RP que no sap que el receptor existeix. El mapatge ha de coincidir tant en el rang de grup com en l'adreça, ja que un rang més específic guanya sobre un de més ampli.

Anycast-RP existeix precisament perquè dos llocs puguin compartir una adreça d'RP, i val la pena anomenar-lo aquí perquè canvia què vol dir «el mateix RP». Dos RP que anuncien una adreça són consistents per disseny; dos RP que anuncien adreces diferents per al mateix rang no ho són, per molt que sembli cada lloc per si sol.

Per al multicast específic de font dins de 232.0.0.0/8, no es consulta mai l'RP, així que un mapatge d'RP buit no és automàticament una fallada. Decidiu quin model de servei usa l'aplicació abans de perseguir un RP que mai no calia.

Llegiu la consulta RPF cap a la font

PIM construeix un arbre invertint el camí unicast, així que la comprovació que importa és la ruta de tornada a la font, o de tornada a l'RP per a un arbre compartit. Una unió que arriba per una interfície que l'encaminador no considera ascendent es descarta, i el motiu es registra com a fallada d'RPF i no com a fallada de túnel. En un encaminador de sucursal amb una ruta per defecte sobre el túnel i una ruta més específica sobre la WAN, la interfície RPF pot ser fàcilment la WAN tot i que la font només és abastable a través del túnel. Aquesta és la raó més comuna que una unió es descarti silenciosament.

show ip rpf 192.0.2.10 mostra la interfície triada, el salt següent i la ruta que va produir la decisió, cosa que normalment n'hi ha prou per veure la discrepància. Una ruta multicast estàtica com ip mroute 192.0.2.0 255.255.255.0 tunnel0 anul·la la consulta unicast per a aquest prefix, i és una correcció legítima quan la topologia multicast difereix realment de la topologia unicast. Tracteu-la com a configuració que cal documentar, no com un pedaç aplicat durant un incident i després oblidat.

Confirmeu la unió amb ordres, no amb un ping

El ping demostra que l'unicast funciona, cosa que ja sabíeu. La confirmació d'extrem a extrem és una seqüència que mostra la unió, el mapatge, el veí i l'arbre en aquest ordre, i cada ordre respon una pregunta diferent.

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

Una entrada (S,G) poblada amb una interfície d'entrada real i una llista de sortida no buida vol dir que el pla de control ha acabat la feina. Una entrada la interfície d'entrada de la qual diu Null, o un comptador etiquetat RPF failed que no para de pujar, assenyala la secció anterior i no el túnel.

Si les cinc ordres semblen correctes i el receptor encara no veu res, el sospitós restant és la política del propi túnel: una ACL de criptografia o una regla de tallafoc que permet el protocol d'encaminament unicast però no PIM, IGMP ni el trànsit del grup mateix. En un túnel IPsec basat en polítiques, el multicast no es transporta gens, així que la resposta és un disseny GRE o VTI i no una altra excepció de filtre. Anoteu quina de les cinc comprovacions ha fallat abans de canviar res, i després canvieu només aquella capa.