Protokol PIM je súbor protokolov na prenos multicastu v sieti medzi smerovačmi. Vzťahy susedstva sa budujú podobne ako v prípade dynamických smerovacích protokolov. PIMv2 posiela každých 30 sekúnd správy Hello na vyhradenú multicastovú adresu 224.0.0.13 (All-PIM-Routers). Správa obsahuje Hold Timers – zvyčajne je nastavený na 3,5-násobok Hello Timera, teda 105 sekúnd ako predvolené.
PIM používa dva hlavné režimy prevádzky – Dense a Sparse mode. Začneme s Dense mode.
Distribučné stromy založené na zdroji.
Režim Dense-mode je rozumné použiť v prípade veľkého počtu klientov v rôznych multicastových skupinách. Keď smerovač dostane multicastový prenos, najprv skontroluje pravidlo RPF. RPF – toto pravidlo sa používa na kontrolu zdroja multicastu s jednosmernou smerovacou tabuľkou. Trafik musí prichádzať na ten rozhranie, za ktorým sa nachádza daný host podľa jednosmernej smerovacej tabuľky. Tento mechanizmus rieši problém vzniku slučiek pri prenose multicastu.
R3 z multicastových správ zistí zdroj multicastu (Source IP) a skontroluje dva toky od R1 a R2 podľa svojej jednosmernej tabuľky. Tok z toho rozhrania, na ktoré odkazuje tabuľka (R1 k R3), bude prenášaný ďalej, zatiaľ čo tok od R2 bude zrušený, pretože na to, aby sa dostalo k zdroju multicastu, je potrebné posielať pakety cez S0/1.
Čo sa stane, ak máte dve ekvivalentné trasy s rovnakou metrikou? V tomto prípade smerovač vyberá podľa next-hop týchto trás. Kto má vyššiu IP adresu, ten vyhráva. Ak je potrebné zmeniť toto správanie, je možné použiť ECMP. Viac informácií. .
Po overení pravidla RPF smerovač odosiela multicastový paket všetkým svojim PIM susedom, okrem toho, od koho bol tento paket prijatý. Ostatné PIM smerovače opakujú tento proces. Cesta, ktorou prešiel multicastový paket od zdroja k konečným prijímateľom, vytvára strom, ktorý sa nazýva – strom založený na zdroji, strom najkratšej cesty (SPT), zdrojový strom. Tri rôzne názvy, vyberte si akýkoľvek.
Ako vyriešiť problém s tým, že niektoré smerovače nezískali nejaký multicastový prenos a nemá ho komu odoslať, zatiaľ čo im vyšší smerovač posiela. Na tento účel bol vymyslený mechanizmus Prune.
Prune Message.
Napríklad, R2 bude naďalej posielať R3 multicast, aj keď R3 podľa pravidla RPF ho odmieta. Prečo zaťažovať prenosovú linku? R3 posiela PIM Prune Message a R2, pri prijatí tejto správy, odstráni rozhranie S0/1 zo zoznamu (outgoing interface list) pre tento tok, zoznam rozhraní, z ktorých sa má posielať tento prenos.
Nasleduje formálnejšia definícia PIM Prune správy:
PIM Prune správa je odoslaná jedným smerovačom druhému smerovaču, aby spôsobil, že druhý smerovač odstráni odkaz, na ktorom bola prijatá Prune správa, z konkrétneho (S,G) SPT.
Po prijatí Prune správy, R2 nastaví Prune časovač na 3 minúty. Po uplynutí troch minút začne opäť posielať prenos, pokiaľ neobdrží ďalšiu Prune správu. To platí pre PIMv1.
A v PIMv2 bol pridaný State Refresh časovač (predvolene 60 sekúnd). Keď bola odoslaná Prune správa z R3, tento časovač sa spustí na R3. Po uplynutí tohto časovača, R3 odošle State Refresh správu, ktorá resetuje 3-minútový Prune časovač na R2 pre túto skupinu.
Dôvody na odoslanie Prune správy:
- Keď multicastový paket neprejde RPF kontrolou.
- Keď neexistujú lokálne pripojení klienti, ktorí požiadali o multicastovú skupinu (IGMP Join) a niet PIM susedov, ktorým by bolo možné odosielať multicastový prenos (Non-prune Interface).
Graft Správa.
Predstavme si, že R3 nechcel prenos od R2, poslal Prune a dostával multicast od R1. Ale zrazu, došlo k výpadku linky medzi R1-R3 a R3 ostal bez multicastu. Čaká sa 3 minúty, kým na R2 nevyprší Prune časovač. Čakanie 3 minúty je dlhé, aby sme nemuseli čakať, je potrebné poslať správu, ktorá okamžite vyvedie toto rozhranie S0/1 na R2 z pruned stavu. Takou správou bude Graft správa. Po prijatí Graft správy, R2 odošle späť Graft-ACK.
Prune Override.
Pozrime sa na túto schému. R1 vysiela multicast do segmentu s dvoma smerovačmi. R3 prijíma a vysiela prevádzku, R2 prijíma, ale nemá komu vysielať. Posiela Prune správu k R1 do tohto segmentu. R1 by mal odstrániť Fa0/0 zo zoznamu a prestať vysielať do tohto segmentu, ale čo sa stane s R3? R3 je v tom istom segmente, tiež prijal túto Prune správu a pochopil celú tragédiu situácie. Pred tým, ako R1 prestane vysielať, nastaví časovač na 3 sekundy a prestane vysielať o 3 sekundy. 3 sekundy — presne toľko času má R3 na to, aby nestratil svoj multicast. Preto R3 čo najskôr posiela Pim Join správu pre túto skupinu a R1 už neuvažuje o tom, že prestane vysielať. O Join správach nižšie.
Assert Message.
Predstavme si takú situáciu: do jednej siete vysielajú naraz dva smerovače. Prijímajú ten istý prúd zo zdroja, a obaja ho vysielajú do jednej siete za rozhraním e0. Preto musia určiť, kto bude jediným vysielateľom pre túto sieť. Na tento účel sa používajú Assert správy. Keď R2 a R3 zistia duplicitu multicastovej prevádzky, t.j. na R2 a R3 prichádza multicast, ktorý sami vysielajú, smerovače chápu, že tu je niečo v neporiadku. Smerovače v tomto prípade posielajú Assert správy, do ktorých zahrnujú Administratívnu vzdialenosť a metriku trasy, pomocou ktorej sa dosahuje zdroj multicastu — 10.1.1.10. Víťaz sa určuje takto:
- Ten, kto má nižšiu AD.
- Ak sú AD rovnaké, tak ten, kto má nižšiu metriku.
- Ak je aj tu rovnosť, tak ten, kto má vyššiu IP v sieti, do ktorej vysielajú tento multicast.
Víťaz v tomto hlasovaní sa stáva Designated Router-om. Na výber DR sa taktiež používajú Pim Hello. Na začiatku článku bolo zobrazené PIM Hello správa, tam môžete spozorovať pole DR. Víťazí ten, kto má vyššie IP adresy na tomto linku.
Užitočná tabuľka:
MROUTE Table.
Po prvotnom preskúmaní fungovania PIM protokolu musíme pochopiť, ako pracovať s multicastovou routovacou tabuľkou. V tabuľke mroute sa uchováva informácia o tom, aké prúdy boli požadované zo strany klientov a aké prúdy prichádzajú z multicastových serverov.
Napríklad, pri prijatí IGMP Membership Report alebo PIM Join na nejakom rozhraní sa do routovacej tabuľky pridáva záznam typu ( *, G ):
Táto záznam znamená, že bola prijatá žiadosť o prenos z adresy 238.38.38.38. Príznak DC znamená, že multicast bude fungovať v režime Dense mode a C znamená, že prijímač je priamo pripojený k smerovaču, t.j. smerovač prijal IGMP Membership Report, a PIM Join.
Ak je záznam typu (S,G), znamená to, že máme multicastový prenos:
V poli S — 192.168.1.11, máme uvedenú IP adresu zdroja multicastu, ktorá bude overovaná pravidlom RPF. V prípade problémov je prvé, čo treba skontrolovať, smerovaciu tabuľku unicastu na trasu k zdroju. V poli Incoming Interface sa uvádza interface, na ktorý prichádza multicast. V smerovacej tabuľke unicastu by mala trasa k zdroju odkazovať na interface, ktorý je tu uvedený. V Outgoing Interface sa uvádza, kam bude multicast presmerovaný. Ak je prázdne, znamená to, že k smerovaču neprišli žiadosti o tento prenos. Podrobnejšie informácie o všetkých príznakoch nájdete .
PIM Sparse-mode.
Stratégia Sparse-mode je opačná k Dense-mode. Keď Sparse-mode dostane multicastový prenos, pošle prenos iba cez tie interface, kde boli žiadosti o daný prenos, napríklad Pim Join alebo IGMP Report správy s žiadosťou o tento prenos.
Podobné prvky u SM a DM:
- Vztahy susedstva sa budujú rovnako ako v PIM DM.
- Pravidlo RPF funguje.
- Výber DR je podobný.
- Mechanizmus Prune Overrides a správy Assert sú analogické.
Na kontrolu toho, kto, kde a aký multicastový prenos potrebuje v sieti, potrebujeme spoločné informačné centrum. Týmto centrom bude Rendezvous Point (RP). Všetci, ktorí chcú nejaký multicastový prenos alebo niekto začal prijímať multicastový prenos od zdroja, ho pošlú na RP.
Keď RP obdrží multicastový prenos, pošle ho tým smerovačom, ktoré predtým požiadali o tento prenos.
Predstavme si takú topológiu, kde RP je R3. Hneď ako R1 získa prenos od S1, zabalí tento multicastový paket do unicastového PIM Register správy a pošle ho na RP. Odkiaľ vie, kto je RP? V tomto prípade je nastavený staticky, a o dynamickom nastavení RP si povieme neskôr.
ip pim rp-address 3.3.3.3
RP skontroluje, či existovala informácia od niekoho, kto by chcel dostávať tento traffic. Predpokladajme, že nie. Potom RP pošle R1 správu PIM Register-Stop, čo znamená, že nikto nemá záujem o tento multicast, registrácia bola zamietnutá. R1 nebude posielať multicast. Ale hostiteľ zdroja multicastu ho bude posielať, takže R1 po obdržaní Register-Stop spustí časovač Register-Suppression timer s hodnotou 60 sekúnd. 5 sekúnd pred uplynutím tohto časovača R1 pošle prázdnu Register správu s Null-Register bit (teda bez zapuzdreného multicast paketu) smerom k RP. RP na svoju stranu zareaguje takto:
- Ak príjemcov nebolo, tak ani nie je, takže odpovie správou Register-Stop.
- Ak sa príjemcovia objavia, na správu nijako nezareaguje. R1, ak v priebehu 5 sekúnd nedostane odmietnutie svojej registrácie, sa poteší a pošle Register správu so zapuzdreným multicastom na RP.
Ako multicast dosahuje RP, zdá sa, že sme si už objasnili, teraz sa pokúsime odpovedať na otázku, ako RP dopravuje traffic k prijímateľom. Je potrebné zaviesť nový pojem — root-path tree (RPT). RPT je strom s koreňom v RP, rastúci smerom k prijímateľom, rozvetvujúci sa na každom PIM-SM routeri. RP ho vytvára prijímaním PIM Join správ a do stromu pridáva novú vetvu. A takto robí každý podradený router. Všeobecné pravidlo znie:
- Keď PIM-SM router prijme PIM Join správu na niektorom rozhraní, okrem rozhrania, za ktorým sa skrýva RP, pridáva do stromu novú vetvu.
- Vetva sa tiež pridáva, keď PIM-SM router prijme IGMP Membership Report od priamo pripojeného hosta.
Predstavme si, že máme klienta multicastu na routeri R5 pre skupinu 228.8.8.8. Hneď ako R5 prijme IGMP Membership Report od hosta, R5 pošle PIM Join smerom k RP a zároveň pridá do stromu rozhranie, ktoré smeruje k hostu. Následne R4 prijme PIM Join od R5, pridá do stromu rozhranie Gi0/1 a pošle PIM Join smerom k RP. Nakoniec RP (R3) prijme PIM Join a pridá Gi0/0 do stromu. Týmto vzniká registrácia prijímateľa multicastu. Vytvárame strom s koreňom R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0.
Po tomto sa odošle PIM Join k R1 a R1 začne posielať multicast dopravu. Je dôležité poznamenať, že ak hostiteľ požiadal o dopravu pred začiatkom vysielania multicastu, RP neodošle PIM Join a vôbec nič neodošle smerom k R1.
Ak náhodou, počas posielania multicastu, hostiteľ prestane chcieť ho prijímať, hneď ako RP dostane PIM Prune na rozhraní Gi0/0, okamžite pošle PIM Register-Stop priamo k R1 a potom aj PIM Prune správu cez rozhranie Gi0/1. PIM Register-stop sa posiela unicastom na tú adresu, z ktorej prišlo PIM Register.
Ako sme už spomínali, akonáhle router pošle PIM Join inému, napríklad R5 na R4, na R4 sa pridá záznam:
A spustí sa časovač, ktorý resetuje tento časovač R5 musí neustále posielať PIM Join správy, inak R4 vylúči z outgoing list. R5 bude posielať každých 60 sekúnd PIM Join správy.
Prechod na tree s najkratšou cestou.
Pridáme rozhranie medzi R1 a R5 a pozrieme sa, ako sa bude prenášať doprava pri takejto topológii.
Predpokladajme, že doprava sa posielala a prijímala podľa starej schémy R1-R2-R3-R4-R5 a teraz sme pripojili a nastavili rozhranie medzi R1 a R5.
Najprv sa nám prestavia unicastová tabuľka smerovania na R5 a teraz je sieť 192.168.1.0/24 dostupná 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. Musí sa odpojiť od RPT a postaviť kratší strom, ktorý sa nazýva Shortest-Path Tree (SPT). Na to cez Gi0/2 odosiela PIM Join k R1 a R1 začne posielať multicast aj cez Gi0/2. Teraz sa R5 musí odhlásiť od RPT, aby neprijímal dve kópie. Na to posiela Prune správu so špecifickou IP adresou zdroja a vkladá špeciálny bit — RPT-bit. To znamená, že mi nemôžete posielať dopravu, mám tu lepší strom. RP tiež posiela smerom k R1 PIM Prune správy, ale neodosiela Register-Stop správu. Ďalším špeciálnym rysom je, že R5 teraz neustále posiela PIM Prune k RP, keďže R1 naďalej posiela PIM Register k RP každú minútu. Kým nebudú noví záujemcovia o túto dopravu, bude RP odpovedať odmietnutím. R5 informuje RP, že naďalej prijíma multicast cez SPT.
Dynamické vyhľadávanie RP.
Auto-RP.
Táto technológia je proprietárna od spoločnosti Cisco a nie je príliš populárna, ale stále prežíva. Činnosť Auto-RP pozostáva z dvoch hlavných etáp:
1) RP posiela RP-Announce správy na rezervovanú adresu — 224.0.1.39, oznamujúc sa ako RP buď pre všetkých, alebo pre určité skupiny. Správa sa odosiela každú minútu.
2) Je potrebný RP mapping agent, ktorý bude posielať RP-Discovery správy s informáciou, pre ktoré skupiny je potrebné počúvať ktorého RP. Práve z tejto správy zvyčajné PIM smerovače určia, ktorý RP si majú zvoliť. Mapping agent môže byť buď samotný RP smerovač, alebo akýkoľvek iný samostatný PIM smerovač. RP-Discovery sa posiela na adresu 224.0.1.40 s časovačom jedna minúta.
Pozrime sa na proces podrobnejšie:
Nastavíme R3 ako RP:
ip pim send-rp-announce loopback 0 scope 10
R2 ako mapping agent:
ip pim send-rp-discovery loopback 0 scope 10
A na všetkých ostatných budeme čakať na RP cez Auto-RP:
ip pim autorp listener
Akonáhle nastavíme R3, začne odosielať RP-Announce:
A R2, po nastavení ako mapping agent, začne čakať na správy RP-Announce. Iba keď nájde aspoň jeden RP, začne odosielať RP-Discovery:
Týmto spôsobom, akonáhle obyčajné smerovače (PIM RP Listener) dostanú túto správu, budú vedieť, kde hľadať RP.
Jedným z hlavných problémov Auto-RP je, že na prijímanie správ RP-Announce a RP-Discovery je potrebné odoslať PIM Join na adresy 224.0.1.39-40, a na to, aby sa mohlo odeslať, je potrebné vedieť, kde sa nachádza RP. Klasický problém sliepky a vajca. Na riešenie tohto problému bol navrhnutý režim PIM Sparse-Dense-Mode. Ak smerovač nepozná RP, funguje v režime Dense-mode, ak pozná, tak v režime Sparse-mode. Keď sú na rozhraní obyčajných smerovačov nastavené PIM Sparse-mode a príkaz ip pim autorp listener, smerovač bude fungovať v Dense-mode iba pre multicast Auto-RP protokolu (224.0.1.39-40).
BootStrap Router (BSR).
Táto funkcia funguje podobne ako Auto-RP. Každý RP posiela správu mapping agentovi, ktorý zhromažďuje mapovacie informácie a potom ich odovzdáva všetkým ostatným smerovačom. Proces opíšeme podobne ako Auto-RP:
1) Akonáhle nastavíme R3 za kandidáta na RP, príkazom:
ip pim rp-candidate loopback 0
R3 nič neurobí, aby začal posielať špeciálne správy, najprv musí nájsť mapping agenta. Tak sa posunieme k druhému kroku.
2) Nastavíme R2 ako mapping agent:
ip pim bsr-candidate loopback 0
R2 začne rozosielať PIM Bootstrap správy, kde se označuje ako mapping agent:
Toto hlásenie je odosielané na adresu 224.0.0.13, ktorú PIM protokol používa aj pre iné svoje správy. Odesílají se do všetkých smerov, a preto nie je problém s kurčatami a vajcami, ako to bolo pri Auto-RP.
3) Akonáhle RP dostane správu od BSR smerovača, okamžite odešle unicastovú správu na adresu BSR smerovača:
Potom, čo BSR dostane informácie o RP, rozosiela ich multicastom na adresu 224.0.0.13, ktorú počúvajú všetci PIM smerovače. Preto neexistuje ekvivalent príkazu ip pim autorp listener pre bežné smerovače v BSR.
Anycast RP s Multicast Source Discovery Protocol (MSDP).
Auto-RP a BSR nám umožňujú rozložiť záťaž na RP nasledovne: Každá multicast skupina má iba jedno aktívne RP. Nepodarí sa rozložiť záťaž pre jednu multicast skupinu na niekoľko RP. MSDP to robí pomocou prideľovania RP smerovačom rovnakú IP adresu s maskou 255.255.255.255. MSDP získava informácie jedným z metód: staticky, Auto-RP alebo BSR.
Na obrázku máme Auto-RP konfiguráciu s MSDP. Obe RP sú nastavené s IP adresou 172.16.1.1/32 na Loopback 1 rozhraní a používajú sa pre všetky skupiny. Pri RP-Announce obidva smerovače hovoria o sebe, odvolávajúc sa na túto adresu. Auto-RP mapping agent, získavujúc informácie, rozosiela RP-Discovery o RP s adresou 172.16.1.1/32. O sieti 172.16.1.1/32 hovoríme smerovačom pomocou IGP a, samozrejme. Takto PIM smerovače požadujú alebo registrujú toky od toho RP, ktorý je uvedený ako next-hop v trase k sieti 172.16.1.1/32. Samotný protokol MSDP je určený pre RP, aby si vymenili správy o informáciách o multicast.
Zvážme takúto topológiu:
Switch6 vysiela prenos na adresu 238.38.38.38 a zatiaľ o ňom vie iba RP-R1. Tu Switch7 a Switch8 požiadali o túto skupinu. Smerovače R5 a R4 odošlú PIM Join na R1 a R3, príslušne. Prečo? Trasa k 13.13.13.13 u R5 bude odkazovať na R1 podľa metriky IGP, rovnako ako u R4.
RP-R1 vie o toku a začne ho vysielať smerom k R5, ale R4 o ňom nič nevie, pretože R1 ho jednoducho takto posielať nebude. Preto je potrebný MSDP. Nastavíme 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
Oni nadviažu reláciu medzi sebou a pri prijímaní akéhokoľvek toku budú informovať o ňom svojho RP suseda.
Keď RP-R1 získa prúd zo Switch6, okamžite pošle unikastom správu MSDP Source-Active, ktorá bude obsahovať informácie typu (S, G) — informácie o zdroji a určenia multicastu. Teraz, keď RP-R3 vie, že existuje zdroj ako Switch6, pri prijatí požiadavky od R4 na tento prúd, pošle smerom k Switch6 PIM Join podľa smerovacej tabuľky. Tým pádom, ak R1 prijme taký PIM Join, začne posielať prevádzku smerom k RP-R3.
MSDP funguje cez TCP, RP si navzájom posielajú keepalive správy na overenie životaschopnosti. Časovač je nastavený na 60 sekúnd.
Funkcia rozdeľovania MSDP peerov do rôznych domén zostáva nejasná, pretože v správach keepalive a SA nie je uvedená príslušnosť k žiadnej doméne. V tejto topológii bola testovaná aj konfigurácia s uvedením rôznych domén — rozdiel v prevádzke nebol.
Ak niekto môže objasniť, s radosťou si prečítam v komentároch.
Zdroj: habr.com
