PIM-SM prek VPN: preverite BSR, preslikavo RP in poti RPF

Predor je vzpostavljen, pingi unicast gredo skozenj, sprejemnik pa še vedno kaže črn zaslon. V namestitvi PIM-SM ta simptom skoraj vedno pomeni, da je ena od štirih krmilnih poti zlomljena in da podatkovna pot ni bila nikoli problem. Pojdite skozi spodnji seznam po vrsti in se ustavite pri prvem koraku, ki odpove, ker je vsak naslednji korak odvisen od prejšnjega. Teh pet preverjanj hranim v delovni datoteki in jih prilepim v terminal, ko pride pritožba glede multicast, kar prepreči, da bi diagnoza postala ugibanje.

Začnite s sprejemnikom, ne s predorom

Sprejemnik, ki skupine ni nikoli zahteval, ne ustvari nobenega stanja na nobenem usmerjevalniku, zato pred preverjanjem česarkoli drugega potrdite, da prijava obstaja v segmentu, obrnjenem proti sprejemniku. Na platformah v slogu Cisco show ip igmp groups na usmerjevalniku zadnjega skoka izpiše pridružene skupine ob vmesniku, ki jih je slišal. Ko skupine v tem izpisu ni, je predor odvračanje pozornosti: zahteva je umrla na dostopnem stikalu, v vtičnici gostitelja ali v VLAN brez querierja.

Dva vsakdanja vzroka pojasnita večino manjkajočih prijav, ki sem jih videl: neskladje različice IGMP med gostiteljem in usmerjevalnikom ter izbor querierja, ki je pristal na stikalu, ki ne usmerja. Tretji je bolj subtilen: skupina je pridružena, a v napačnem VLAN, ker ima gostitelj dve omrežni kartici in se je aplikacija vezala na napačno. Sprejemniki IPv6 imajo enako težavo z MLD, kjer show ipv6 mld groups odgovarja na isto vprašanje. Nobene od teh ne odpravi dotik predora, in prav zato je vrstni red pomemben.

Ko je prijava vidna, potrdite, da je PIM omogočen na vmesniku, obrnjenem proti sprejemniku, in na vmesniku, ki vodi proti zbirni točki. Usmerjevalnik s članstvom IGMP, a brez PIM na svojem nadrejenem vmesniku, bo skupino držal v lokalni tabeli in ne bo poslal ničesar nikamor.

Ali množica BSR doseže drugo stran?

Sporočila Bootstrap Router se premikajo skok za skokom znotraj ene domene PIM, in to je smer, ki se zlomi čez predor. Kandidati RP pošiljajo svoja obvestila izbranemu BSR prek unicast, zato odsek RP–BSR običajno preživi delujoč predor nespremenjen. Poplava sporočil Bootstrap v nasprotni smeri je odvisna od tega, da ima vsak vmesni vmesnik omogočen PIM in da nič ne ustavi sporočil na meji. RFC 5059 določa to razširjanje in meje upravnega obsega, ki ga smejo skrajšati.

Ukaz ip pim bsr-border, ACL, ki filtrira protokol 103, ali predor IPsec, ki temelji na pravilnikih in ne more prenašati multicast, bo vsak prerezal poplavo, medtem ko bo unicast ostal nedotaknjen. Prav ta kombinacija naredi okvaro videti kot težavo z RP, čeprav je v resnici težava dosegljivosti, in zato berem stanje BSR pred konfiguracijo RP.

Na usmerjevalniku na oddaljeni strani show ip pim bsr-router navaja izbrani BSR in naučeno množico RP; če je izpis prazen, oddaljena stran sedi v svoji domeni in nobena konfiguracija RP ne bo uskladila obeh. Primerjajte obsege skupin in naslove RP v show ip pim rp mapping na obeh straneh predora. Preslikava, ki obstaja le lokalno, ustvari deljeno drevo, ki se konča na napačnem mestu, in sprejemnik čaka večno.

Uskladite preslikavo RP na obeh straneh predora

Statični RP, BSR in anycast-RP so trije načini odgovora na isto vprašanje, in njihovo mešanje čez predor je zanesljiv način, da zgradite domeno, ki se nikoli ne konvergira. Če glavni konec uporablja BSR, veja pa statični ip pim rp-address, ki kaže na drug naslov, veja zgradi svoje deljeno drevo proti RP, ki ne ve, da sprejemnik obstaja. Preslikava se mora ujemati tako v obsegu skupine kot v naslovu, saj bolj natančen obseg premaga širšega.

Anycast-RP obstaja prav zato, da si lahko dve lokaciji delita en naslov RP, in ga je vredno omeniti tukaj, ker spreminja pomen »isti RP«. Dva RP, ki objavljata en naslov, sta po zasnovi skladna; dva RP, ki objavljata različne naslove za isti obseg, nista, ne glede na to, kako zdrava se zdi vsaka lokacija sama zase.

Za multicast, specifičen za vir, znotraj 232.0.0.0/8 RP ni nikoli vprašan, zato prazna preslikava RP ni samodejno okvara. Odločite se, kateri model storitve uporablja aplikacija, preden lovite RP, ki nikoli ni bil potreben.

Preberite iskanje RPF proti viru

PIM zgradi drevo z obračanjem poti unicast, zato je ključno preverjanje pot nazaj do vira ali nazaj do RP pri deljenem drevesu. Prijava, ki prispe na vmesnik, ki ga usmerjevalnik ne šteje za nadrejenega, se zavrže, razlog pa se zabeleži kot okvara RPF in ne kot okvara predora. Na vejnem usmerjevalniku s privzeto potjo čez predor in bolj natančno potjo čez WAN je vmesnik RPF lahko zlahka WAN, čeprav je vir dosegljiv le skozi predor. To je edini najpogostejši razlog, da je prijava tiho zavržena.

show ip rpf 192.0.2.10 izpiše izbrani vmesnik, naslednji skok in pot, ki je ustvarila odločitev, kar običajno zadostuje za vpogled v neskladje. Statična pot multicast, kot je ip mroute 192.0.2.0 255.255.255.0 tunnel0, preglasi iskanje unicast za to predpono, in to je zakonit popravek, ko se topologija multicast resnično razlikuje od topologije unicast. Obravnavajte jo kot konfiguracijo, ki jo je treba dokumentirati, ne kot obliž, nameščen med incidentom in pozneje pozabljen.

Prijavo potrdite z ukazi, ne s pingom

Ping dokazuje, da unicast deluje, kar ste že vedeli. Potrditev od konca do konca je zaporedje, ki v tem vrstnem redu pokaže prijavo, preslikavo, soseda in drevo, in vsak ukaz odgovarja na drugo vprašanje.

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

Izpolnjen vnos (S,G) z resničnim vhodnim vmesnikom in nepraznim seznamom izhodnih pomeni, da je krmilna ravnina opravila svoje delo. Vnos, katerega vhodni vmesnik se bere kot Null, ali števec z oznako RPF failed, ki še naprej narašča, kaže nazaj na prejšnji razdelek in ne na predor.

Če je vseh pet ukazov videti pravilnih in sprejemnik še vedno ne vidi ničesar, je preostali osumljenec politika samega predora: kripto ACL ali pravilo požarnega zidu, ki dovoli protokol usmerjanja unicast, ne pa PIM, IGMP ali prometa skupine samega. Na predoru IPsec, ki temelji na pravilnikih, se multicast sploh ne prenaša, zato je odgovor zasnova GRE ali VTI in ne še ena izjema v filtru. Zapišite, katero od petih preverjanj je spodletelo, preden kar koli spremenite, in nato spremenite le to plast.