Jak funguje protokol PIM

Protokol PIM je sada protokolů pro přenos multicastu v síti mezi routery. Sousedské vztahy jsou budovány stejným způsobem jako v případě dynamických směrovacích protokolů. PIMv2 posílá zprávy Hello každých 30 sekund na vyhrazenou adresu vícesměrového vysílání 224.0.0.13 (All-PIM-Routers). Zpráva obsahuje časovače Hold - obvykle se rovná 3.5*Hello Timer, to znamená 105 sekund ve výchozím nastavení.

PIM používá dva hlavní provozní režimy – režim Hustý a Sparse. Začněme režimem Dense.
Distribuční stromy založené na zdroji.
Režim Dense-mode je vhodné použít v případě velkého počtu klientů různých skupin multicast. Když router přijme vícesměrový provoz, první věc, kterou udělá, je zkontrolovat, zda neobsahuje pravidlo RPF. RPF – toto pravidlo se používá ke kontrole zdroje multicastu s unicastovou směrovací tabulkou. Je nutné, aby provoz dorazil na rozhraní, za kterým je tento hostitel skryt podle verze unicastové směrovací tabulky. Tento mechanismus řeší problém smyčky vyskytující se při multicastovém přenosu.

R3 rozpozná zdroj multicastu (Source IP) ze zprávy multicast a zkontroluje dva toky z R1 a R2 pomocí své tabulky unicast. Stream z rozhraní, na které ukazuje tabulka (R1 až R3) bude přenášen dále a stream z R2 bude vynechán, protože k tomu, abyste se dostali ke zdroji multicastu, musíte posílat pakety přes S0/1.
Otázkou je, co se stane, když máte dvě ekvivalentní trasy se stejnou metrikou? V tomto případě router vybere další skok z těchto tras. Kdo má vyšší IP adresu, vyhrává. Pokud potřebujete toto chování změnit, můžete použít ECMP. Více informací zde.
Po kontrole pravidla RPF router odešle multicastový paket všem svým PIM sousedům, kromě toho, od kterého byl paket přijat. Ostatní PIM routery tento proces opakují. Cesta, kterou paket vícesměrového vysílání prošel od zdroje ke konečným příjemcům, tvoří strom nazývaný zdrojový distribuční strom, strom nejkratší cesty (SPT), zdrojový strom. Tři různá jména, vyberte si libovolné.
Jak vyřešit problém, že některé routery to nedaly na nějaký multicast stream a nemá to komu poslat, ale upstream router mu to posílá. K tomu byl vynalezen mechanismus Prune.
Prune Message.
Například R2 bude nadále posílat multicast na R3, ačkoli R3 jej podle pravidla RPF zahodí. Proč načítat kanál? R3 odešle PIM Prune Message a R2 po přijetí této zprávy odstraní rozhraní S0/1 ze seznamu odchozích rozhraní pro tento tok, ze seznamu rozhraní, ze kterých by měl být tento provoz odeslán.

Následuje formálnější definice zprávy PIM Prune:
Zpráva PIM Prune je odeslána jedním směrovačem druhému směrovači, aby způsobila, že druhý směrovač odstranil spojení, na kterém je zpráva Prune přijata od konkrétního (S,G) SPT.

Po obdržení zprávy Prune nastaví R2 časovač Prune na 3 minuty. Po třech minutách začne znovu odesílat provoz, dokud neobdrží další zprávu Prune. Toto je v PIMv1.
A v PIMv2 byl přidán časovač obnovení stavu (ve výchozím nastavení 60 sekund). Jakmile byla z R3 odeslána zpráva Prune, spustí se tento časovač na R3. Po vypršení tohoto časovače odešle R3 zprávu State Refresh, která resetuje 3minutový časovač prořezávání na R2 pro tuto skupinu.
Důvody pro odeslání zprávy Prune:

• Když paket vícesměrového vysílání selže při kontrole RPF.
• Pokud neexistují žádní lokálně připojení klienti, kteří požádali o multicastovou skupinu (IGMP Join), a neexistují žádní sousedé PIM, kterým lze posílat multicastový provoz (Neprune Interface).

Zpráva o štěpu.
Představme si, že R3 nechtěl provoz z R2, poslal Prune a přijal multicast z R1. Ale najednou kanál mezi R1-R3 spadl a R3 zůstal bez multicastu. Můžete počkat 3 minuty, než vyprší časovač prořezávání na R2. 3 minuty jsou dlouhé čekání, abyste nečekali, musíte odeslat zprávu, která toto rozhraní S0/1 do R2 okamžitě převede z ořezaného stavu. Tato zpráva bude zprávou Graft. Po přijetí zprávy o štěpu R2 odpoví hlášením Graft-ACK.
Přepsání prořezávání.

Podívejme se na tento diagram. R1 vysílá multicast do segmentu se dvěma směrovači. R3 přijímá a vysílá provoz, R2 přijímá, ale nemá komu provoz vysílat. Odešle zprávu Prune do R1 v tomto segmentu. R1 by měla odstranit Fa0/0 ze seznamu a zastavit vysílání v tomto segmentu, ale co se stane s R3? A R3 je ve stejném segmentu, také obdržel tuto zprávu od Prune a pochopil tragédii situace. Než R1 zastaví vysílání, nastaví časovač na 3 sekundy a po 3 sekundách zastaví vysílání. 3 sekundy – přesně tolik času má R3, aby neztratil svůj multicast. R3 proto co nejdříve posílá Pim Join zprávu pro tuto skupinu a R1 už nepomýšlí na zastavení vysílání. O Připojit zprávy níže.
Tvrdit zprávu.

Představme si tuto situaci: dva routery vysílají do jedné sítě najednou. Přijímají stejný proud ze zdroje a oba jej vysílají do stejné sítě za rozhraním e0. Proto musí určit, kdo bude jediným vysílatelem pro tuto síť. K tomu slouží asert message. Když R2 a R3 detekují duplikaci multicastového provozu, to znamená, že R2 a R3 přijímají multicast, který samy vysílají, routery pochopí, že je zde něco špatně. V tomto případě směrovače odesílají zprávy Assert, které zahrnují administrativní vzdálenost a metriku trasy, se kterou je dosaženo zdroje vícesměrového vysílání - 10.1.1.10. Výherce je určen následovně:

1. Ten s nižším AD.
2. Pokud se AD rovnají, kdo má nižší metriku.
3. Pokud je zde rovnost, tak ten, kdo má vyšší IP v síti, do které tento multicast vysílají.

Vítěz tohoto hlasování se stává Určeným směrovačem. Pim Hello se také používá k výběru DR. Na začátku článku byla zobrazena zpráva PIM Hello, tam vidíte pole DR. Vyhrává ten s nejvyšší IP adresou na tomto odkazu.
Užitečné znamení:

Tabulka MROUTE.
Po úvodním pohledu na to, jak funguje protokol PIM, musíme pochopit, jak pracovat s vícesměrovou směrovací tabulkou. Tabulka mroute uchovává informace o tom, které proudy byly požadovány od klientů a které proudy proudí ze serverů vícesměrového vysílání.
Když je například na některém rozhraní přijata zpráva o členství IGMP nebo připojení PIM, do směrovací tabulky se přidá záznam typu ( *, G ):

Tento záznam znamená, že byl přijat požadavek na provoz s adresou 238.38.38.38. Příznak DC znamená, že multicast bude fungovat v režimu Dense a C znamená, že příjemce je přímo připojen k routeru, to znamená, že router obdržel zprávu o členství IGMP a připojení PIM.
Pokud existuje záznam typu (S,G), znamená to, že máme multicastový stream:

V poli S - 192.168.1.11 jsme zaregistrovali IP adresu zdroje multicastu, právě ta bude kontrolována pravidlem RPF. Pokud se vyskytnou problémy, první věc, kterou musíte udělat, je zkontrolovat unicastovou tabulku pro cestu ke zdroji. V poli Příchozí rozhraní označuje rozhraní, na které je přijímáno vícesměrové vysílání. V unicastové směrovací tabulce musí cesta ke zdroji odkazovat na zde specifikované rozhraní. Odchozí rozhraní určuje, kam bude vícesměrové vysílání přesměrováno. Pokud je prázdný, pak router neobdržel žádné požadavky na tento provoz. Více informací o všech vlajkách naleznete zde.
PIM řídký režim.
Strategie Sparse-mode je opakem Dense-mode. Když Sparse-mode přijme multicastový provoz, odešle provoz pouze přes ta rozhraní, kde byly požadavky na tento tok, například zprávy Pim Join nebo IGMP Report požadující tento provoz.
Podobné prvky pro SM a DM:

• Sousedské vztahy se budují stejným způsobem jako v PIM DM.
• Pravidlo RPF funguje.
• Výběr DR je podobný.
• Mechanismus zpráv Prune Overrides a Assert je podobný.

Ke kontrole toho, kdo, kde a jaký druh multicastového provozu je v síti potřeba, je zapotřebí společné informační centrum. Naším centrem bude Rendezvous Point (RP). Každý, kdo chce nějaký multicastový provoz nebo někdo začal přijímat multicastový provoz ze zdroje, pak ho pošle do RP.
Když RP přijme multicastový provoz, odešle ho těm směrovačům, které si tento provoz dříve vyžádaly.

Představme si topologii, kde RP je R3. Jakmile R1 přijme provoz z S1, zapouzdří tento multicastový paket do zprávy unicast PIM Register a odešle ji do RP. Jak ví, kdo je RP? V tomto případě se konfiguruje staticky a o dynamické konfiguraci RP si povíme později.

ip pim rp-adresa 3.3.3.3

RP se podívá - byly informace od někoho, kdo by chtěl tento provoz přijímat? Předpokládejme, že nebylo. Poté RP pošle R1 zprávu PIM Register-Stop, což znamená, že nikdo nepotřebuje toto multicast, registrace je zamítnuta. R1 nebude odesílat multicast. Ale hostitel zdroje vícesměrového vysílání to odešle, takže R1 po obdržení zastavení registru spustí časovač potlačení registru rovný 60 sekundám. 5 sekund před vypršením tohoto časovače odešle R1 prázdnou zprávu Register s bitem Null-Register (tj. bez zapouzdřeného paketu vícesměrového vysílání) směrem k RP. RP se bude chovat takto:

• Pokud nebyli žádní příjemci, odpoví zprávou Registrovat-Stop.
• Pokud se příjemci objeví, nebude na to nijak reagovat. R1, který neobdržel odmítnutí registrace do 5 sekund, bude rád a pošle zprávu Register se zapouzdřeným multicastem do RP.

Zdá se, že jsme přišli na to, jak multicast dosahuje RP, nyní se pokusme odpovědět na otázku, jak RP doručuje provoz příjemcům. Zde je nutné zavést nový koncept - root-path tree (RPT). RPT je strom zakořeněný v RP, roste směrem k příjemcům a větví se na každém PIM-SM routeru. RP jej vytvoří přijetím zpráv PIM Join a přidá do stromu novou větev. A tak to dělá každý downstream router. Obecné pravidlo vypadá takto:

• Když PIM-SM router přijme zprávu PIM Join na jakémkoli jiném rozhraní, než je rozhraní, za kterým je RP skrytý, přidá do stromu novou větev.
• Pobočka je také přidána, když router PIM-SM obdrží zprávu o členství IGMP od přímo připojeného hostitele.

Představme si, že máme multicastového klienta na routeru R5 pro skupinu 228.8.8.8. Jakmile R5 obdrží IGMP Membership Report od hostitele, R5 odešle PIM Join směrem k RP a sám přidá do stromu rozhraní, které se dívá na hostitele. Dále R4 přijme PIM Join od R5, přidá rozhraní Gi0/1 do stromu a odešle PIM Join ve směru RP. Nakonec RP ( R3 ) obdrží PIM Join a přidá Gi0/0 do stromu. Příjemce vícesměrového vysílání je tedy registrován. Stavíme strom s kořenem R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0.
Poté bude PIM spojení odesláno na R1 a R1 začne odesílat multicastový provoz. Je důležité si uvědomit, že pokud hostitel požadoval provoz před zahájením vysílání vícesměrového vysílání, pak RP neodešle PIM Join a nepošle do R1 vůbec nic.
Pokud náhle během odesílání multicastu hostitel přestane chtít je přijímat, jakmile RP přijme PIM Prune na rozhraní Gi0/0, okamžitě odešle PIM Registr-Stop přímo do R1 a poté PIM Prune zprávu přes rozhraní Gi0/1. PIM Register-stop je odeslán přes unicast na adresu, ze které přišel registr PIM.
Jak jsme řekli dříve, jakmile router odešle spojení PIM do jiného, ​​například R5 až R4, přidá se záznam do R4:

A spustí se časovač, který musí R5 neustále resetovat zprávy PIM Join, jinak bude R4 vyloučen ze seznamu odchozích zpráv. R5 odešle každých 60 zpráv PIM Join.
Přepnutí stromu nejkratší cesty.
Přidáme rozhraní mezi R1 a R5 a uvidíme, jak provoz s touto topologií proudí.

Předpokládejme, že provoz byl odesílán a přijímán podle starého schématu R1-R2-R3-R4-R5 a zde jsme připojili a nakonfigurovali rozhraní mezi R1 a R5.
Nejprve musíme přestavět unicastovou směrovací tabulku na R5 a nyní je síť 192.168.1.0/24 dosažena přes rozhraní R5 Gi0/2. Nyní R5, přijímající multicast na rozhraní Gi0/1, chápe, že pravidlo RPF není splněno a bylo by logičtější přijímat multicast na Gi0/2. Měl by se odpojit od RPT a vytvořit kratší strom s názvem Shortest-Path Tree (SPT). K tomu pošle PIM Join do R0 přes Gi2/1 a R1 začne posílat multicast také přes Gi0/2. Nyní se R5 potřebuje odhlásit z RPT, aby nedostal dvě kopie. Za tímto účelem odešle Prune zprávu s uvedením zdrojové IP adresy a vložením speciálního bitu - RPT-bit. To znamená, že mi nemusíte posílat provoz, tady mám lepší strom. RP také odesílá zprávy PIM Prune na R1, ale neodesílá zprávu Register-Stop. Další funkce: R5 bude nyní nepřetržitě posílat PIM Prune do RP, protože R1 pokračuje v odesílání PIM Register do RP každou minutu. Dokud nebudou žádní noví lidé, kteří chtějí tento provoz, RP to odmítne. R5 oznámí RP, že nadále přijímá multicast přes SPT.
Dynamické vyhledávání RP.
Auto-RP.
Tato technologie je majetkem společnosti Cisco a není příliš populární, ale je stále naživu. Provoz Auto-RP se skládá ze dvou hlavních fází:
1) RP posílá zprávy RP-Announce na vyhrazenou adresu - 224.0.1.39, deklaruje se RP buď pro všechny, nebo pro konkrétní skupiny. Tato zpráva je odesílána každou minutu.
2) Je vyžadován agent pro mapování RP, který bude odesílat zprávy RP-Discovery s uvedením, pro které skupiny by měl být který RP naslouchán. Z této zprávy si běžné PIM routery určí RP samy. Mapping Agent může být buď samotný RP router, nebo samostatný PIM router. RP-Discovery je odeslán na adresu 224.0.1.40 s časovačem jedné minuty.
Podívejme se na proces podrobněji:
Nakonfigurujme R3 jako RP:

ip pim send-rp-announce loopback 0 rozsah 10

R2 jako mapovací agent:

ip pim send-rp-discovery loopback 0 rozsah 10

A na všech ostatních budeme očekávat RP přes Auto-RP:

ip pim autorp posluchač

Jakmile nakonfigurujeme R3, začne odesílat RP-Announce:

A R2 po nastavení mapovacího agenta začne čekat na zprávu RP-Announce. Teprve když najde alespoň jeden RP, začne odesílat RP-Discovery:

Tímto způsobem, jakmile běžné routery (PIM RP Listener) obdrží tuto zprávu, budou vědět, kde hledat RP.
Jedním z hlavních problémů s Auto-RP je, že abyste mohli přijímat zprávy RP-Announce a RP-Discovery, musíte odeslat PIM Join na adresy 224.0.1.39-40, a abyste mohli odeslat, musíte vědět, kam RP se nachází. Klasický problém slepice a vejce. K vyřešení tohoto problému byl vynalezen PIM Sparse-Dense-Mode. Pokud router nezná RP, pak pracuje v režimu Dense, pokud ano, pak v režimu Sparse. Když jsou na rozhraních běžných směrovačů nakonfigurovány PIM Sparse-mode a příkaz ip pim autorp listener, bude router fungovat v režimu Dense pouze pro multicasting přímo z protokolu Auto-RP (224.0.1.39-40).
BootStrap Router (BSR).
Tato funkce funguje podobně jako Auto-RP. Každý RP odešle zprávu mapovacímu agentovi, který shromáždí informace o mapování a poté je sdělí všem ostatním směrovačům. Popišme proces podobně jako Auto-RP:
1) Jakmile nakonfigurujeme R3 jako kandidáta na RP, pomocí příkazu:

ip pim rp-candidate loopback 0

Pak R3 nic neudělá, aby mohl začít posílat speciální zprávy, musí nejprve najít mapovacího agenta. Přejdeme tedy k druhému kroku.
2) Nakonfigurujte R2 jako mapovacího agenta:

ip pim bsr-candidate loopback 0

R2 začne odesílat zprávy PIM Bootstrap, kde se označuje jako mapovací agent:

Tato zpráva je odeslána na adresu 224.0.013, kterou protokol PIM používá i pro své další zprávy. Posílá je všemi směry, a proto nedochází k problémům s kuřecím masem a vejci jako v Auto-RP.
3) Jakmile RP obdrží zprávu z routeru BSR, okamžitě odešle unicast zprávu na adresu routeru BSR:

Poté BSR, který obdrží informace o RP, je pošle multicastem na adresu 224.0.0.13, kterou poslouchají všechny PIM routery. Proto analog příkazu ip pim autorp posluchač pro běžné routery, které nejsou v BSR.
Anycast RP s Multicast Source Discovery Protocol (MSDP).
Auto-RP a BSR nám umožňují rozložit zátěž na RP následovně: Každá skupina multicastu má pouze jeden aktivní RP. Nebude možné rozložit zátěž pro jednu multicastovou skupinu na několik RP. MSDP to dělá tak, že směrovačům RP přidělí stejnou IP adresu s maskou 255.255.255.255. MSDP se učí informace pomocí jedné z metod: statické, Auto-RP nebo BSR.

Na obrázku máme konfiguraci Auto-RP s MSDP. Oba RP jsou nakonfigurovány s IP adresou 172.16.1.1/32 na rozhraní Loopback 1 a používají se pro všechny skupiny. S RP-Announce se oba směrovače oznámí odkazem na tuto adresu. Mapovací agent Auto-RP po obdržení informace odešle RP-Discovery o RP s adresou 172.16.1.1/32. Směrovačům říkáme o síti 172.16.1.1/32 pomocí IGP a podle toho. Směrovače PIM tedy požadují nebo registrují toky z RP, který je specifikován jako další skok na trase do sítě 172.16.1.1/32. Samotný protokol MSDP je určen pro samotné RP k výměně zpráv o multicastových informacích.
Zvažte tuto topologii:

Switch6 vysílá provoz na adresu 238.38.38.38 a zatím o něm ví jen RP-R1. Switch7 a Switch8 požádali o tuto skupinu. Směrovače R5 a R4 pošlou spojení PIM na R1 a R3. Proč? Cesta k 13.13.13.13 pro R5 bude odkazovat na R1 pomocí metriky IGP, stejně jako pro R4.
RP-R1 o streamu ví a začne ho vysílat směrem k R5, ale R4 o něm nic neví, protože R1 to prostě nepošle. Proto je MSDP nezbytný. Nakonfigurujeme to na R1 a R5:

ip msdp peer 3.3.3.3 connect-source Loopback1 na R1

ip msdp peer 1.1.1.1 connect-source Loopback3 na R3

Vyvolají mezi sebou relaci a když obdrží jakýkoli tok, oznámí to svému sousedovi RP.
Jakmile RP-R1 přijme stream z Switch6, okamžitě odešle unicast MSDP Source-Active zprávu, která bude obsahovat informace jako (S, G) - informace o zdroji a cíli multicastu. Nyní, když RP-R3 ví, že zdroj, jako je Switch6, když obdrží požadavek od R4 na tento tok, pošle PIM Join směrem k Switch6, vedený směrovací tabulkou. Následně R1 po přijetí takového spojení PIM začne posílat provoz směrem k RP-R3.
MSDP běží přes TCP, RP si navzájem posílají udržovací zprávy pro kontrolu živosti. Časovač je 60 sekund.
Funkce rozdělení MSDP peerů do různých domén zůstává nejasná, protože Keepalive a SA zprávy neoznačují členství v žádné doméně. V této topologii jsme také testovali konfiguraci označující různé domény – nebyl zde žádný rozdíl ve výkonu.
Pokud to někdo může upřesnit, rád si to přečtu v komentářích.

Zdroj: www.habr.com