PIM-SM cez VPN: skontrolujte BSR, mapovanie RP a trasy RPF

Tunel je hore, unicastové pingy ním prechádzajú a prijímač napriek tomu zobrazuje čiernu obrazovku. V nasadení PIM-SM tento príznak takmer vždy znamená, že jedna zo štyroch riadiacich ciest je prerušená a že dátová cesta nikdy nebola problém. Prejdite zoznam nižšie poporiadku a zastavte sa pri prvom kroku, ktorý zlyhá, pretože každý ďalší krok závisí od predchádzajúceho. Týchto päť sond držím v konceptovom súbore a vkladám ich do terminálu, keď príde sťažnosť na multicast, čo bráni tomu, aby sa diagnostika zmenila na hádanie.

Začnite prijímačom, nie tunelom

Prijímač, ktorý o skupinu nikdy nepožiadal, nevytvára na žiadnom routeri stav, takže predtým, než začnete skúmať čokoľvek iné, overte, že pripojenie existuje na segmente obrátenom k prijímaču. Na platformách v štýle Cisco vypíše show ip igmp groups na routeri posledného skoku pripojené skupiny vedľa rozhrania, ktoré ich počulo. Keď v tomto výstupe skupina chýba, tunel je rozptýlením: požiadavka zomrela na prístupovom prepínači, v sockete hostiteľa alebo vo VLAN bez queriera.

Dve obyčajné príčiny vysvetľujú väčšinu chýbajúcich pripojení, ktoré som videl: nezhoda verzie IGMP medzi hostiteľom a routerom a voľba queriera, ktorá padla na prepínač, ktorý neroutuje. Tretia je jemnejšia: skupina je pripojená, ale v nesprávnej VLAN, pretože hostiteľ má dve sieťové karty a aplikácia sa naviazala na tú nesprávnu. Prijímače IPv6 majú rovnaký problém s MLD, kde show ipv6 mld groups odpovedá na tú istú otázku. Nič z toho sa nespraví dotykom tunela, a práve preto na poradí záleží.

Keď je pripojenie viditeľné, overte, že PIM je zapnutý na rozhraní obrátenom k prijímaču aj na rozhraní vedúcom k miestu stretnutia. Router s členstvom IGMP, ale bez PIM na svojom nadradenom rozhraní, podrží skupinu v lokálnej tabuľke a nikam nič nepošle.

Dostane sa sada BSR na druhú stranu?

Správy Bootstrap Router sa pohybujú skok za skokom v rámci jednej domény PIM, a to je smer, ktorý sa cez tunel láme. Kandidáti RP posielajú svoje oznámenia zvolenému BSR cez unicast, takže úsek RP-BSR zvyčajne prežije fungujúci tunel bez zmien. Záplava správ Bootstrap v opačnom smere závisí od toho, že každé medziľahlé rozhranie má zapnutý PIM a že nič správy nezastaví na hranici. RFC 5059 definuje toto šírenie a hranice administratívneho rozsahu, ktorým je dovolené ho skrátiť.

Príkaz ip pim bsr-border, ACL filtrujúci protokol 103 alebo tunel IPsec založený na politikách, ktorý nedokáže prenášať multicast, každý z nich preruší záplavu, pričom unicast zostane nedotknutý. Práve táto kombinácia robí z poruchy zdanlivo problém s RP, hoci v skutočnosti ide o problém dosiahnuteľnosti, a preto čítam stav BSR skôr než konfiguráciu RP.

Na routeri na opačnej strane show ip pim bsr-router uvádza zvolený BSR a naučenú sadu RP; ak je výstup prázdny, protistrana sedí vo svojej vlastnej doméne a žiadna konfigurácia RP tie dve nezladí. Porovnajte rozsahy skupín a adresy RP v show ip pim rp mapping na oboch stranách tunela. Mapovanie, ktoré existuje len lokálne, vytvára zdieľaný strom, ktorý končí na nesprávnom mieste, a prijímač čaká navždy.

Zlaďte mapovanie RP na oboch stranách tunela

Statický RP, BSR a anycast-RP sú tri spôsoby, ako odpovedať na tú istú otázku, a ich miešanie cez tunel je spoľahlivý spôsob, ako postaviť doménu, ktorá nikdy nekonverguje. Ak hlavný uzol používa BSR a pobočka statický ip pim rp-address ukazujúci na inú adresu, pobočka stavia svoj zdieľaný strom k RP, ktorý netuší, že prijímač existuje. Mapovanie sa musí zhodovať v rozsahu skupiny aj v adrese, pretože konkrétnejší rozsah vyhráva nad širším.

Anycast-RP existuje práve preto, aby dve lokality mohli zdieľať jednu adresu RP, a stojí za to ho tu spomenúť, pretože mení význam „ten istý RP“. Dva RP inzerujúce jednu adresu sú konzistentné zámerne; dva RP inzerujúce rôzne adresy pre ten istý rozsah nie sú, nech už každá lokalita vyzerá sama o sebe akokoľvek zdravo.

Pre multicast špecifický pre zdroj v rozsahu 232.0.0.0/8 sa RP nikdy nedopytuje, takže prázdne mapovanie RP nie je automaticky porucha. Rozhodnite, ktorý model služby aplikácia používa, než začnete naháňať RP, ktorý nebol nikdy potrebný.

Prečítajte vyhľadávanie RPF smerom k zdroju

PIM stavia strom obrátením unicastovej cesty, takže podstatná kontrola je cesta späť k zdroju alebo späť k RP pri zdieľanom strome. Pripojenie, ktoré dorazí na rozhranie, ktoré router nepovažuje za nadradené, sa zahodí a dôvod sa zaznamená ako zlyhanie RPF, nie ako zlyhanie tunela. Na pobočkovom routeri s predvolenou cestou cez tunel a konkrétnejšou cestou cez WAN môže byť rozhraním RPF ľahko WAN, aj keď je zdroj dostupný len cez tunel. To je jediný najčastejší dôvod, prečo je pripojenie ticho zahodené.

show ip rpf 192.0.2.10 vypíše zvolené rozhranie, ďalší skok a cestu, ktorá vytvorila rozhodnutie, čo zvyčajne stačí na odhalenie nezhody. Statická multicastová cesta ako ip mroute 192.0.2.0 255.255.255.0 tunnel0 prebíja unicastové vyhľadanie pre tento prefix a je to legitímna oprava, keď sa multicastová topológia skutočne líši od unicastovej. Berte ju ako konfiguráciu, ktorú treba zdokumentovať, nie ako záplatu nasadenú počas incidentu a potom zabudnutú.

Potvrďte pripojenie príkazmi, nie pingom

Ping dokazuje, že unicast funguje, čo ste už vedeli. End-to-end potvrdenie je postupnosť, ktorá v tomto poradí ukáže pripojenie, mapovanie, suseda a strom, a každý príkaz odpovedá na inú otázku.

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

Naplnený záznam (S,G) so skutočným vstupným rozhraním a neprázdnym zoznamom odchádzajúcich znamená, že riadiaca rovina dokončila svoju prácu. Záznam, ktorého vstupné rozhranie sa číta ako Null, alebo počítadlo označené RPF failed, ktoré stále rastie, ukazuje späť na predchádzajúcu časť, nie na tunel.

Ak všetkých päť príkazov vyzerá správne a prijímač napriek tomu nič nevidí, zostávajúcim podozrivým je politika samotného tunela: krypto ACL alebo pravidlo firewallu, ktoré povoľuje unicastový smerovací protokol, ale nie PIM, IGMP ani samotnú prevádzku skupiny. Na tuneli IPsec založenom na politikách sa multicast vôbec neprenáša, takže odpoveďou je návrh GRE alebo VTI, a nie ďalšia výnimka vo filtri. Zapíšte, ktorá z piatich sond zlyhala, skôr než čokoľvek zmeníte, a potom zmeňte len tú vrstvu.