PIM-SM preko VPN-a: provjerite BSR, mapiranje RP-a i RPF putanje

Tunel je podignut, unicast pingovi ga prelaze, a prijemnik i dalje prikazuje crni ekran. U PIM-SM postavci taj simptom gotovo uvijek znači da je jedna od četiri kontrolne putanje pokvarena, a podatkovna putanja nikada nije bila problem. Prođite donji spisak redom i zaustavite se na prvom koraku koji ne uspije, jer svaki kasniji korak zavisi od prethodnog. Držim ovih pet provjera u radnoj datoteci i zalijepim ih u terminal kada stigne prijava za multicast, što dijagnozu sprječava da se pretvori u nagađanje.

Počnite od prijemnika, ne od tunela

Prijemnik koji nikada nije tražio grupu ne stvara stanje ni na jednom ruteru, pa potvrdite da pridruživanje postoji na segmentu okrenutom prema prijemniku prije nego što provjerite bilo šta drugo. Na platformama u stilu Cisco show ip igmp groups na ruteru posljednjeg skoka ispisuje pridružene grupe pored interfejsa koji ih je čuo. Kada grupa nedostaje u tom izlazu, tunel odvlači pažnju: zahtjev je umro na pristupnom prekidaču, na soketu domaćina ili u VLAN-u bez querier-a.

Dva obična uzroka objašnjavaju većinu pridruživanja koja nedostaju, a koja sam vidio: neusklađenost verzije IGMP-a između domaćina i rutera, te izbor querier-a koji je pao na prekidač koji ne rutira. Treći je suptilniji: grupa je pridružena, ali na pogrešnom VLAN-u, jer domaćin ima dvije mrežne kartice, a aplikacija se vezala za pogrešnu. IPv6 prijemnici imaju ekvivalentan problem s MLD-om, gdje show ipv6 mld groups odgovara na isto pitanje. Nijedan od ovih se ne ispravlja diranjem tunela, i upravo zato redoslijed ima značaj.

Kada je pridruživanje vidljivo, potvrdite da je PIM uključen i na interfejsu okrenutom prema prijemniku i na interfejsu koji vodi prema točki susreta. Ruter s članstvom IGMP-a, ali bez PIM-a na svom uzlaznom interfejsu, držat će grupu u lokalnoj tablici i neće poslati ništa nikuda.

Dolazi li BSR skup do suprotne strane?

Poruke Bootstrap Router-a kreću se skok po skok unutar jednog PIM domena, a upravo taj smjer se lomi preko tunela. Kandidati RP-a šalju svoje oglase izabranom BSR-u unicastom, pa RP-do-BSR dionica obično preživi radni tunel nepromijenjena. Poplava Bootstrap poruka u drugom smjeru zavisi od toga da svaki posredni interfejs ima uključen PIM i da ništa ne zaustavlja poruke na granici. RFC 5059 definira tu distribuciju i granice administrativnog opsega kojima je dopušteno da je prekinu.

Naredba ip pim bsr-border, ACL koji filtrira protokol 103 ili IPsec tunel zasnovan na pravilima koji ne može nositi multicast, svaki će prekinuti poplavu dok unicast ostaje netaknut. Upravo ta kombinacija čini da kvar izgleda kao problem s RP-om kad je zapravo problem dostupnosti, i zato čitam stanje BSR-a prije konfiguracije RP-a.

Na ruteru sa suprotne strane show ip pim bsr-router navodi izabrani BSR i skup RP-a koji je naučio; ako je izlaz prazan, suprotna strana sjedi u vlastitom domenu i nikakva konfiguracija RP-a neće pomiriti njih dvoje. Uporedite opsege grupa i adrese RP-a u show ip pim rp mapping na obje strane tunela. Mapiranje koje postoji samo lokalno stvara dijeljeno stablo koje završava na pogrešnom mjestu, a prijemnik čeka zauvijek.

Uskladite mapiranje RP-a na obje strane tunela

Statički RP, BSR i anycast-RP tri su načina da se odgovori na isto pitanje, a njihovo miješanje preko tunela pouzdan je način da se izgradi domen koji se nikada ne konvergira. Ako glavni čvor koristi BSR, a podružnica statički ip pim rp-address koji pokazuje na drugu adresu, podružnica gradi svoje dijeljeno stablo prema RP-u koji nema pojma da prijemnik postoji. Mapiranje se mora slagati i po opsegu grupe i po adresi, jer konkretniji opseg pobjeđuje širi.

Anycast-RP postoji upravo zato da dva lokaliteta mogu dijeliti jednu RP adresu, i vrijedi ga ovdje imenovati jer mijenja značenje „isti RP“. Dva RP-a koji oglašavaju jednu adresu dosljedni su po dizajnu; dva RP-a koji oglašavaju različite adrese za isti opseg nisu, koliko god zdrav svaki lokalitet izgledao sam za sebe.

Za multicast specifičan za izvor unutar 232.0.0.0/8 RP se nikada ne pita, pa prazno mapiranje RP-a nije automatski kvar. Odlučite koji model usluge aplikacija koristi prije nego što jurite RP koji nikada nije bio potreban.

Pročitajte RPF pretragu prema izvoru

PIM gradi stablo obrćući unicast putanju, pa je provjera koja je važna ruta natrag prema izvoru, ili natrag prema RP-u za dijeljeno stablo. Pridruživanje koje stigne na interfejs koji ruter ne smatra uzlaznim biva odbačeno, a razlog se bilježi kao RPF kvar, a ne kao kvar tunela. Na ruteru podružnice s podrazumijevanom rutom preko tunela i konkretnijom rutom preko WAN-a RPF interfejs lako može biti WAN, iako je izvor dostupan samo kroz tunel. To je jedan najčešći razlog da pridruživanje bude tiho odbačeno.

show ip rpf 192.0.2.10 ispisuje izabrani interfejs, sljedeći skok i rutu koja je proizvela odluku, što je obično dovoljno da se vidi nesklad. Statička multicast ruta poput ip mroute 192.0.2.0 255.255.255.0 tunnel0 nadjačava unicast pretragu za taj prefiks, i to je legitimna ispravka kada se multicast topologija stvarno razlikuje od unicast topologije. Tretirajte je kao konfiguraciju koju treba dokumentirati, a ne kao zakrpu primijenjenu tokom incidenta i zatim zaboravljenu.

Potvrdite pridruživanje naredbama, ne pingom

Ping dokazuje da unicast radi, što ste već znali. Potvrda od kraja do kraja je slijed koji prikazuje pridruživanje, mapiranje, susjeda i stablo tim redom, a svaka naredba odgovara na različito pitanje.

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

Popunjen (S,G) zapis sa stvarnim ulaznim interfejsom i nepraznom izlaznom listom znači da je kontrolna ravan završila svoj posao. Zapis čiji ulazni interfejs glasi Null, ili brojač označen RPF failed koji stalno raste, upućuje natrag na prethodni odjeljak, a ne na tunel.

Ako svih pet naredbi izgleda ispravno, a prijemnik još uvijek ništa ne vidi, preostali sumnjivac je vlastita politika tunela: kripto ACL ili pravilo vatrozida koje dopušta unicast protokol rutiranja, ali ne PIM, IGMP ni sam saobraćaj grupe. Na IPsec tunelu zasnovanom na pravilima multicast se uopće ne prenosi, pa je rješenje GRE ili VTI dizajn, a ne još jedan izuzetak u filteru. Zapišite koja je od pet provjera pala prije nego što bilo šta promijenite, a zatim promijenite samo taj sloj.