Ako funguje protokol PIM

Protokol PIM je súbor protokolov na prenos multicastu v sieti medzi smerovačmi. Susedské vzťahy sa budujú rovnakým spôsobom ako v prípade dynamických smerovacích protokolov. PIMv2 posiela správy Hello každých 30 sekúnd na vyhradenú multicast adresu 224.0.0.13 (All-PIM-Routers). Správa obsahuje časovače Hold – zvyčajne sa rovnajú 3.5*Hello Timer, to znamená 105 sekúnd predvolene.

PIM používa dva hlavné prevádzkové režimy – režim Hustý a Sparse. Začnime s režimom Hustý.
Distribučné stromy založené na zdroji.
Režim Dense-mode je vhodné použiť v prípade veľkého počtu klientov rôznych skupín multicast. Keď smerovač prijme multicastovú prevádzku, prvá vec, ktorú urobí, je skontrolovať, či sa v ňom nachádza pravidlo RPF. RPF – toto pravidlo sa používa na kontrolu zdroja multicastu s unicastovou smerovacou tabuľkou. Je potrebné, aby prevádzka prichádzala na rozhranie, za ktorým je tento hostiteľ skrytý podľa verzie unicast smerovacej tabuľky. Tento mechanizmus rieši problém slučky vyskytujúcej sa počas multicast prenosu.

R3 rozpozná zdroj multicastu (Source IP) zo správy multicast a skontroluje dva toky z R1 a R2 pomocou svojej tabuľky unicast. Prúd z rozhrania, na ktoré ukazuje tabuľka (R1 až R3) sa bude prenášať ďalej a prúd z R2 sa zahodí, pretože na to, aby ste sa dostali k zdroju multicastu, musíte posielať pakety cez S0/1.
Otázkou je, čo sa stane, ak máte dve ekvivalentné trasy s rovnakou metrikou? V tomto prípade router vyberie ďalší skok z týchto trás. Kto má vyššiu IP adresu, vyhráva. Ak potrebujete zmeniť toto správanie, môžete použiť ECMP. Viac informácií tu.
Po skontrolovaní pravidla RPF router odošle multicastový paket všetkým svojim susedom PIM, okrem toho, od ktorého bol paket prijatý. Ostatné PIM smerovače opakujú tento proces. Cesta, ktorou sa paket multicast dostane od zdroja ku konečným príjemcom, tvorí strom nazývaný zdrojový distribučný strom, strom najkratšej cesty (SPT), zdrojový strom. Tri rôzne mená, vyberte si ľubovoľné.
Ako riesit problem, ze niektore routery to nevzdali na nejaky multicast stream a nema to komu poslat, ale upstream router mu to posiela. Na to bol vynájdený mechanizmus Prune.
Správa o reze.
Napríklad R2 bude naďalej posielať multicast na R3, hoci R3 ho podľa pravidla RPF zruší. Prečo načítať kanál? R3 odošle správu PIM Prune Message a R2 po prijatí tejto správy odstráni rozhranie S0/1 zo zoznamu odchádzajúcich rozhraní pre tento tok, teda zo zoznamu rozhraní, z ktorých by mala byť táto prevádzka odoslaná.

Nasleduje formálnejšia definícia správy PIM Prune:
Správa PIM Prune je odoslaná jedným smerovačom druhému smerovaču, aby spôsobila, že druhý smerovač odstráni spojenie, na ktorom je od konkrétneho (S,G) SPT prijaté.

Po prijatí správy Prune R2 nastaví časovač Prune na 3 minúty. Po troch minútach začne znova odosielať prevádzku, kým nedostane ďalšiu správu Prune. Toto je v PIMv1.
A v PIMv2 bol pridaný časovač obnovy stavu (štandardne 60 sekúnd). Hneď po odoslaní správy Prune z R3 sa tento časovač spustí na R3. Po uplynutí tohto časovača R3 odošle správu State Refresh, ktorá resetuje 3-minútový časovač prerezávania na R2 pre túto skupinu.
Dôvody odoslania správy Prune:

• Keď paket multicast zlyhá pri kontrole RPF.
• Keď nie sú žiadni lokálne pripojení klienti, ktorí si vyžiadali multicastovú skupinu (IGMP Join) a neexistujú žiadni PIM susedia, ktorým je možné posielať multicastovú prevádzku (Non-prune Interface).

Správa o štepe.
Predstavme si, že R3 nechcela prevádzku z R2, poslala Prune a prijala multicast z R1. Zrazu však kanál medzi R1-R3 padol a R3 zostal bez multicastu. Môžete počkať 3 minúty, kým uplynie platnosť časovača prerezávania na R2. 3 minúty sú dlhé čakanie, aby ste nečakali, musíte poslať správu, ktorá okamžite uvedie toto rozhranie S0/1 do R2 z orezaného stavu. Táto správa bude správou Graft. Po prijatí správy o štepe, R2 odpovie potvrdením štepu.
Prune Override.

Pozrime sa na tento diagram. R1 vysiela multicast do segmentu s dvoma smerovačmi. R3 prijíma a vysiela prevádzku, R2 prijíma, ale nemá komu vysielať prevádzku. V tomto segmente pošle R1 správu Prune. R1 by mala odstrániť Fa0/0 zo zoznamu a zastaviť vysielanie v tomto segmente, ale čo bude s R3? A R3 je v rovnakom segmente, tiež dostal túto správu od Prune a pochopil tragédiu situácie. Predtým, ako R1 zastaví vysielanie, nastaví časovač na 3 sekundy a po 3 sekundách zastaví vysielanie. 3 sekundy – presne toľko má R3 času, aby neprišiel o svoj multicast. R3 preto čo najskôr posiela Pim Join správu pre túto skupinu a R1 už nepomýšľa na zastavenie vysielania. Informácie o správach Pripojiť sa nižšie.
Tvrdiť správu.

Predstavme si túto situáciu: dva smerovače vysielajú do jednej siete naraz. Prijímajú rovnaký tok zo zdroja a obe ho vysielajú do rovnakej siete za rozhraním e0. Preto musia určiť, kto bude jediným vysielateľom pre túto sieť. Na to slúžia asert správy. Keď R2 a R3 zistia duplicitu multicastovej prevádzky, to znamená, že R2 a R3 prijímajú multicast, ktorý sami vysielajú, smerovače pochopia, že tu niečo nie je v poriadku. V tomto prípade smerovače odosielajú správy Assert, ktoré zahŕňajú administratívnu vzdialenosť a metriku trasy, s ktorou sa dosiahne zdroj multicastu - 10.1.1.10. Výherca je určený nasledovne:

1. Ten s nižším AD.
2. Ak sú AD rovnaké, potom kto má nižšiu metriku.
3. Ak je tu rovnosť, tak ten, kto má vyššiu IP v sieti, do ktorej vysielajú tento multicast.

Víťaz tohto hlasovania sa stáva Určeným smerovačom. Pim Hello sa používa aj na výber DR. Na začiatku článku bola zobrazená správa PIM Hello, tam vidíte pole DR. Ten s najvyššou IP adresou na tomto odkaze vyhráva.
Užitočný znak:

Tabuľka MROUTE.
Po úvodnom pohľade na to, ako funguje protokol PIM, musíme pochopiť, ako pracovať s tabuľkou multicast smerovania. Tabuľka mroute uchováva informácie o tom, ktoré toky boli vyžiadané od klientov a ktoré toky prúdia zo serverov multicast.
Napríklad, keď sa na niektorom rozhraní prijme IGMP Membership Report alebo PIM Join, do smerovacej tabuľky sa pridá záznam typu ( *, G ):

Tento záznam znamená, že bola prijatá požiadavka na prevádzku s adresou 238.38.38.38. Príznak DC znamená, že multicast bude fungovať v hustom režime a C znamená, že príjemca je priamo pripojený k smerovaču, to znamená, že smerovač prijal IGMP Membership Report a PIM Join.
Ak existuje záznam typu (S,G), znamená to, že máme multicast stream:

V poli S - 192.168.1.11 sme zaregistrovali IP adresu multicast zdroja, práve tá bude kontrolovaná pravidlom RPF. Ak sa vyskytnú problémy, prvá vec, ktorú musíte urobiť, je skontrolovať smerovanie k zdroju v tabuľke unicast. V poli Prichádzajúce rozhranie označuje rozhranie, na ktoré sa prijíma multicast. V smerovacej tabuľke unicast musí cesta k zdroju odkazovať na rozhranie špecifikované tu. Outgoing Interface určuje, kam bude multicast presmerovaný. Ak je prázdny, smerovač neprijal žiadne požiadavky na tento prenos. Viac informácií o všetkých vlajkách nájdete tu.
Zriedkavý režim PIM.
Stratégia Sparse-mode je opakom Dense-mode. Keď Sparse-mode prijme multicastovú prevádzku, bude posielať prevádzku iba cez tie rozhrania, kde boli požiadavky na tento tok, napríklad správy Pim Join alebo IGMP Report požadujúce túto prevádzku.
Podobné prvky pre SM a DM:

• Susedské vzťahy sa budujú rovnakým spôsobom ako v PIM DM.
• Pravidlo RPF funguje.
• Výber DR je podobný.
• Mechanizmus správ Prune Overrides a Assert je podobný.

Na kontrolu toho, kto, kde a aký druh multicastovej prevádzky je v sieti potrebný, je potrebné spoločné informačné centrum. Naším centrom bude Rendezvous Point (RP). Každý, kto chce nejaký druh multicastovej prevádzky alebo niekto začal prijímať multicastovú prevádzku zo zdroja, potom ju pošle do RP.
Keď RP prijme multicastovú prevádzku, odošle ju tým smerovačom, ktoré predtým požadovali túto prevádzku.

Predstavme si topológiu, kde RP je R3. Hneď ako R1 prijme prevádzku z S1, zapuzdruje tento multicastový paket do správy unicast PIM Register a odošle ju do RP. Ako vie, kto je RP? V tomto prípade sa konfiguruje staticky a o dynamickej konfigurácii RP si povieme neskôr.

ip pim rp-adresa 3.3.3.3

RP sa pozrie - boli informácie od niekoho, kto by chcel prijímať túto návštevnosť? Predpokladajme, že to tak nebolo. Potom RP pošle R1 správu PIM Register-Stop, čo znamená, že nikto nepotrebuje toto multicast, registrácia je odmietnutá. R1 nepošle multicast. Ale hostiteľ zdroja multicast to odošle, takže R1 po prijatí Register-Stop spustí časovač potlačenia registra rovný 60 sekundám. 5 sekúnd pred uplynutím tohto časovača pošle R1 prázdnu správu Register s bitom Null-Register (to znamená bez zapuzdreného paketu multicast) smerom k RP. RP sa bude správať takto:

• Ak neexistujú žiadni príjemcovia, odpovie správou Register-Stop.
• Ak sa príjemcovia objavia, nebude na to nijako reagovať. R1, ktorý nedostal odmietnutie registrácie do 5 sekúnd, bude rád a pošle RP správu Register so zapuzdreným multicastom.

Zdá sa, že sme prišli na to, ako multicast dosahuje RP, teraz sa pokúsme odpovedať na otázku, ako RP doručuje príjem príjemcom. Tu je potrebné zaviesť nový pojem - strom koreňovej cesty (RPT). RPT je strom zakorenený v RP, rastúci smerom k príjemcom, vetviaci sa na každom PIM-SM routeri. RP ho vytvorí prijatím správ PIM Join a pridá do stromu novú vetvu. A tak to robí každý downstream router. Všeobecné pravidlo vyzerá takto:

• Keď smerovač PIM-SM prijme správu PIM Join na akomkoľvek inom rozhraní, než je rozhranie, za ktorým je skrytý RP, pridá do stromu novú vetvu.
• Pobočka sa pridá aj vtedy, keď smerovač PIM-SM prijme správu o členstve IGMP od priamo pripojeného hostiteľa.

Predstavme si, že na routeri R5 máme multicast klienta pre skupinu 228.8.8.8. Hneď ako R5 dostane správu o členstve IGMP od hostiteľa, R5 odošle PIM pripojenie v smere RP a sám pridá do stromu rozhranie, ktoré sa pozerá na hostiteľa. Potom R4 prijme PIM Join od R5, pridá rozhranie Gi0/1 do stromu a odošle PIM Join v smere RP. Nakoniec RP ( R3 ) dostane PIM Join a pridá Gi0/0 do stromu. Príjemca multicast je teda zaregistrovaný. Staviame strom s koreňom R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0.
Potom sa na R1 odošle PIM Join a R1 začne odosielať multicastovú prevádzku. Je dôležité si uvedomiť, že ak hostiteľ požadoval prevádzku pred začatím vysielania multicast, potom RP nepošle PIM Join a nepošle vôbec nič do R1.
Ak náhle počas odosielania multicastu ho hostiteľ prestane chcieť prijímať, akonáhle RP prijme PIM Prune na rozhraní Gi0/0, okamžite odošle PIM Register-Stop priamo do R1 a potom PIM Prune správu cez rozhranie Gi0/1. PIM Register-stop sa posiela cez unicast na adresu, z ktorej prišiel register PIM.
Ako sme už povedali, akonáhle smerovač odošle pripojenie PIM inému, napríklad R5 až R4, potom sa k R4 pridá záznam:

A spustí sa časovač, ktorý musí R5 neustále resetovať správy PIM Join, inak bude R4 vylúčený zo zoznamu odchádzajúcich. R5 odošle každých 60 správ PIM Join.
Prepnutie stromu najkratšej cesty.
Pridáme rozhranie medzi R1 a R5 a uvidíme, ako s touto topológiou prúdi premávka.

Predpokladajme, že prevádzka bola odoslaná a prijatá podľa starej schémy R1-R2-R3-R4-R5 a tu sme pripojili a nakonfigurovali rozhranie medzi R1 a R5.
Najprv musíme prebudovať unicastovú smerovaciu tabuľku na R5 a teraz je sieť 192.168.1.0/24 dosiahnutá cez rozhranie R5 Gi0/2. Teraz R5, prijímajúci multicast na rozhraní Gi0/1, chápe, že pravidlo RPF nie je splnené a bolo by logickejšie prijímať multicast na Gi0/2. Mal by sa odpojiť od RPT a vybudovať kratší strom s názvom Strom najkratšej cesty (SPT). Aby to urobil, pošle PIM Join do R0 cez Gi2/1 a R1 začne posielať multicast tiež cez Gi0/2. Teraz sa R5 musí odhlásiť z RPT, aby nedostal dve kópie. Aby to urobil, pošle Prune správu s uvedením zdrojovej IP adresy a vložením špeciálneho bitu - RPT-bit. To znamená, že mi nemusíte posielať návštevnosť, mám tu lepší strom. RP tiež posiela správy PIM Prune na R1, ale neposiela správu Register-Stop. Ďalšia funkcia: R5 bude teraz nepretržite posielať PIM Prune do RP, pretože R1 naďalej posiela PIM Register do RP každú minútu. Kým nebudú žiadni noví ľudia, ktorí by chceli túto návštevnosť, RP ju odmietne. R5 oznámi RP, že naďalej prijíma multicast cez SPT.
Dynamické vyhľadávanie RP.
Auto-RP.
Táto technológia je majetkom spoločnosti Cisco a nie je príliš populárna, ale stále je nažive. Operácia Auto-RP pozostáva z dvoch hlavných etáp:
1) RP posiela správy RP-Announce na rezervovanú adresu - 224.0.1.39, pričom sa deklaruje ako RP pre každého alebo pre konkrétne skupiny. Táto správa sa odosiela každú minútu.
2) Vyžaduje sa mapovací agent RP, ktorý bude posielať správy RP-Discovery s uvedením, pre ktoré skupiny sa má ktorý RP počúvať. Z tejto správy si bežné PIM routery určia RP pre seba. Mapovacím agentom môže byť buď samotný RP router alebo samostatný PIM router. RP-Discovery sa odošle na adresu 224.0.1.40 s časovačom na jednu minútu.
Pozrime sa na proces podrobnejšie:
Nakonfigurujme R3 ako RP:

ip pim send-rp-announce loopback 0 rozsah 10

R2 ako mapovací agent:

ip pim send-rp-discovery loopback 0 rozsah 10

A na všetkých ostatných budeme očakávať RP cez Auto-RP:

ip pim autorp poslucháč

Keď nakonfigurujeme R3, začne odosielať RP-Announce:

A R2, po nastavení mapovacieho agenta, začne čakať na správu RP-Announce. Až keď nájde aspoň jeden RP, začne odosielať RP-Discovery:

Týmto spôsobom, akonáhle bežné smerovače (PIM RP Listener) dostanú túto správu, budú vedieť, kde hľadať RP.
Jedným z hlavných problémov s Auto-RP je, že ak chcete prijímať správy RP-Announce a RP-Discovery, musíte poslať PIM Join na adresy 224.0.1.39-40 a aby ste mohli odosielať, musíte vedieť, kam RP sa nachádza. Klasický problém s kuracím mäsom a vajcom. Na vyriešenie tohto problému bol vynájdený režim PIM Sparse-Dense-Mode. Ak router nepozná RP, potom pracuje v hustom režime, ak áno, potom v riedkom režime. Keď sú PIM Sparse-mode a príkaz ip pim autorp listener nakonfigurované na rozhraniach bežných smerovačov, bude smerovač fungovať v režime Dense iba pre multicasting priamo z protokolu Auto-RP (224.0.1.39-40).
BootStrap Router (BSR).
Táto funkcia funguje podobne ako Auto-RP. Každý RP pošle správu mapovaciemu agentovi, ktorý zhromažďuje informácie o mapovaní a potom to oznámi všetkým ostatným smerovačom. Popíšme si proces podobne ako Auto-RP:
1) Keď nakonfigurujeme R3 ako kandidáta na RP, pomocou príkazu:

ip pim rp-candidate loopback 0

Potom R3 neurobí nič, aby mohol začať posielať špeciálne správy, musí najprv nájsť mapovacieho agenta. Prejdeme teda k druhému kroku.
2) Nakonfigurujte R2 ako mapovacieho agenta:

ip pim bsr-candidate loopback 0

R2 začne odosielať správy PIM Bootstrap, kde sa označuje ako mapovací agent:

Táto správa je odoslaná na adresu 224.0.013, ktorú PIM protokol používa aj pre svoje ďalšie správy. Posiela ich všetkými smermi, a preto nie je problém s kurčatami a vajcami ako v Auto-RP.
3) Hneď ako RP prijme správu z routera BSR, okamžite odošle unicast správu na adresu routera BSR:

Potom BSR po prijatí informácií o RP ich odošle multicastom na adresu 224.0.0.13, ktorú počúvajú všetky smerovače PIM. Preto je analógom príkazu ip pim autorp poslucháč pre bežné routery, ktoré nie sú v BSR.
Anycast RP s protokolom Multicast Source Discovery Protocol (MSDP).
Auto-RP a BSR nám umožňujú rozložiť záťaž na RP nasledovne: Každá multicastová skupina má len jeden aktívny RP. Nebude možné rozložiť záťaž pre jednu multicastovú skupinu na viacero RP. MSDP to robí tak, že RP smerovačom pridelí rovnakú IP adresu s maskou 255.255.255.255. MSDP sa učí informácie pomocou jednej z metód: statickej, Auto-RP alebo BSR.

Na obrázku máme konfiguráciu Auto-RP s MSDP. Obidva RP sú nakonfigurované s IP adresou 172.16.1.1/32 na rozhraní Loopback 1 a používajú sa pre všetky skupiny. S RP-Announce sa oba smerovače ohlásia odkazom na túto adresu. Mapovací agent Auto-RP po prijatí informácií odošle RP-Discovery o RP s adresou 172.16.1.1/32. Hovoríme smerovačom o sieti 172.16.1.1/32 pomocou IGP a podľa toho. Smerovače PIM teda požadujú alebo registrujú toky z RP, ktoré je špecifikované ako ďalší skok na trase do siete 172.16.1.1/32. Samotný protokol MSDP je určený pre samotné RP na výmenu správ o multicastových informáciách.
Zvážte túto topológiu:

Switch6 vysiela prevádzku na adresu 238.38.38.38 a zatiaľ o nej vie len RP-R1. Switch7 a Switch8 si vyžiadali túto skupinu. Smerovače R5 a R4 pošlú spojenie PIM na R1 a R3. prečo? Trasa k 13.13.13.13 pre R5 bude odkazovať na R1 pomocou metriky IGP, rovnako ako pre R4.
RP-R1 o streame vie a začne ho vysielať smerom k R5, ale R4 o ňom nič nevie, keďže R1 ho jednoducho nepošle. Preto je potrebný MSDP. Konfigurujeme ho 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ú medzi sebou reláciu a pri prijatí akéhokoľvek toku to nahlásia svojmu susedovi RP.
Akonáhle RP-R1 prijme stream z Switch6, okamžite odošle unicast MSDP Source-Active správu, ktorá bude obsahovať informácie ako (S, G) - informácie o zdroji a cieli multicastu. Teraz, keď RP-R3 vie, že zdroj, akým je Switch6, pri prijatí požiadavky od R4 na tento tok pošle PIM Join smerom k Switch6 podľa smerovacej tabuľky. Následne R1 po prijatí takéhoto spojenia PIM začne posielať prevádzku smerom k RP-R3.
MSDP beží cez TCP, RP si navzájom posielajú udržiavacie správy na kontrolu životnosti. Časovač je 60 sekúnd.
Funkcia rozdelenia MSDP peerov do rôznych domén zostáva nejasná, keďže správy Keepalive a SA neindikujú členstvo v žiadnej doméne. V tejto topológii sme tiež testovali konfiguráciu označujúcu rôzne domény – vo výkone nebol žiadny rozdiel.
Ak to niekto vie objasniť, rád si to prečítam v komentároch.

Zdroj: hab.com