PIM-SM přes VPN: kontrola BSR, mapování RP a cest RPF

Tunel je nahoře, unicastové pingy jím procházejí a přijímač přesto zobrazuje černou obrazovku. V nasazení PIM-SM tento příznak téměř vždy znamená, že jedna ze čtyř kontrolních cest je přerušená a že datová cesta nikdy nebyla problém. Projděte seznam níže popořadě a zastavte se u prvního kroku, který selže, protože každý další krok závisí na tom předchozím. Těchto pět sond držím v konceptovém souboru a vkládám je do terminálu, když přijde stížnost na multicast, což brání tomu, aby se diagnostika změnila v hádání.

Začněte přijímačem, ne tunelem

Přijímač, který o skupinu nikdy nepožádal, nevytváří na žádném routeru stav, takže než začnete zkoumat cokoli jiného, ověřte, že připojení existuje na segmentu obráceném k přijímači. Na platformách ve stylu Cisco vypíše show ip igmp groups na routeru posledního skoku připojené skupiny vedle rozhraní, které je slyšelo. Když v tomto výstupu skupina chybí, je tunel rozptýlením: požadavek zemřel na přístupovém přepínači, v socketu hostitele nebo ve VLAN bez querieru.

Dvě obyčejné příčiny vysvětlují většinu chybějících připojení, která jsem viděl: neshoda verze IGMP mezi hostitelem a routerem a volba querieru, která padla na přepínač, jenž neroutuje. Třetí je jemnější: skupina je připojená, ale ve špatné VLAN, protože hostitel má dvě síťové karty a aplikace se navázala na tu nesprávnou. Přijímače IPv6 mají ekvivalentní problém s MLD, kde show ipv6 mld groups odpovídá na stejnou otázku. Nic z toho se nespraví dotykem tunelu, a právě proto na pořadí záleží.

Jakmile je připojení viditelné, ověřte, že PIM je zapnutý jak na rozhraní obráceném k přijímači, tak na rozhraní vedoucím k rendezvous pointu. Router s členstvím IGMP, ale bez PIM na svém upstream rozhraní, podrží skupinu v lokální tabulce a nikam nic nepošle.

Dostane se sada BSR na druhou stranu?

Zprávy Bootstrap Router se pohybují skok za skokem v rámci jedné domény PIM, a to je směr, který se přes tunel láme. Kandidáti RP posílají svá oznámení zvolenému BSR unicastem, takže úsek RP-BSR obvykle funkční tunel přežije beze změny. Záplava zpráv Bootstrap v opačném směru závisí na tom, že každé mezilehlé rozhraní má zapnutý PIM a že nic zprávy nezastaví na hranici. RFC 5059 definuje toto šíření a hranice administrativního rozsahu, kterým je dovoleno je zkrátit.

Příkaz ip pim bsr-border, ACL filtrující protokol 103 nebo tunel IPsec založený na politikách, který neumí přenášet multicast, každý z nich záplavu přeruší, zatímco unicast zůstane nedotčen. Právě tato kombinace dělá z poruchy zdánlivě problém s RP, i když jde ve skutečnosti o problém dosažitelnosti, a proto čtu stav BSR dřív než konfiguraci RP.

Na routeru na opačné straně show ip pim bsr-router uvádí zvolený BSR a naučenou sadu RP; pokud je výstup prázdný, protější strana sedí ve své vlastní doméně a žádná konfigurace RP ty dvě nesladí. Porovnejte rozsahy skupin a adresy RP v show ip pim rp mapping na obou stranách tunelu. Mapování, které existuje jen lokálně, vytváří sdílený strom, který končí na špatném místě, a přijímač čeká navěky.

Slaďte mapování RP na obou stranách tunelu

Statický RP, BSR a anycast-RP jsou tři způsoby, jak odpovědět na stejnou otázku, a jejich míchání přes tunel je spolehlivý způsob, jak postavit doménu, která nikdy nezkonverguje. Pokud hlavní uzel používá BSR a pobočka statický ip pim rp-address ukazující na jinou adresu, pobočka staví svůj sdílený strom k RP, který netuší, že přijímač existuje. Mapování se musí shodovat jak v rozsahu skupiny, tak v adrese, protože konkrétnější rozsah vítězí nad širším.

Anycast-RP existuje právě proto, aby dvě lokality mohly sdílet jednu adresu RP, a stojí za to ho zde jmenovat, protože mění význam „stejný RP“. Dva RP inzerující jednu adresu jsou konzistentní záměrně; dva RP inzerující různé adresy pro stejný rozsah nikoli, ať už každá lokalita vypadá sama o sobě jakkoli zdravě.

Pro multicast specifický pro zdroj v rozsahu 232.0.0.0/8 se RP nikdy nedotazuje, takže prázdné mapování RP není automaticky porucha. Rozhodněte, který model služby aplikace používá, než začnete honit RP, který nebyl nikdy potřeba.

Přečtěte vyhledávání RPF směrem ke zdroji

PIM staví strom obrácením unicastové cesty, takže podstatná kontrola je cesta zpět ke zdroji, nebo zpět k RP u sdíleného stromu. Připojení, které dorazí na rozhraní, jež router nepovažuje za upstream, se zahodí a důvod se zaznamená jako selhání RPF, nikoli jako selhání tunelu. Na pobočkovém routeru s výchozí cestou přes tunel a konkrétnější cestou přes WAN může být rozhraním RPF snadno WAN, i když je zdroj dostupný jen tunelem. To je jediný nejčastější důvod, proč je připojení tiše zahozeno.

show ip rpf 192.0.2.10 vypíše zvolené rozhraní, další skok a cestu, která rozhodnutí vytvořila, což obvykle stačí k odhalení neshody. Statická multicastová cesta jako ip mroute 192.0.2.0 255.255.255.0 tunnel0 přebíjí unicastové vyhledání pro tento prefix a je to legitimní oprava, když se multicastová topologie skutečně liší od unicastové. Berte ji jako konfiguraci, kterou je třeba zdokumentovat, ne jako záplatu nasazenou během incidentu a pak zapomenutou.

Potvrďte připojení příkazy, ne pingem

Ping dokazuje, že unicast funguje, což jste už věděli. End-to-end potvrzení je posloupnost, která v tomto pořadí ukáže připojení, mapování, souseda a strom, a každý příkaz odpovídá na jinou 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

Naplněný záznam (S,G) se skutečným vstupním rozhraním a neprázdným seznamem odchozích znamená, že řídicí rovina dokončila svou práci. Záznam, jehož vstupní rozhraní se čte jako Null, nebo počítadlo označené RPF failed, které stále roste, ukazuje zpět na předchozí oddíl, nikoli na tunel.

Pokud všech pět příkazů vypadá správně a přijímač přesto nic nevidí, zbývajícím podezřelým je politika samotného tunelu: krypto ACL nebo pravidlo firewallu, které povoluje unicastový směrovací protokol, ale ne PIM, IGMP ani samotný provoz skupiny. Na tunelu IPsec založeném na politikách se multicast vůbec nepřenáší, takže odpovědí je návrh GRE nebo VTI, a ne další výjimka ve filtru. Zapište, která z pěti sond selhala, než cokoli změníte, a pak změňte jen tu vrstvu.