Načela rada PIM protokola

PIM протокол je skup protokola za prenos multicast informacija u mreži između rutera. Veze susedstva se uspostavljaju na sličan način kao u slučaju dinamičkih protokola usmeravanja. PIMv2 šalje svakih 30 sekundi Hello poruke na rezervisanu multicast adresu 224.0.0.13 (All-PIM-Routers). Poruka sadrži Hold Timers - obično jednak 3.5*Hello Timer, odnosno 105 sekundi po defaultu.

PIM koristi dva osnovna režima rada - Dense i Sparse mode. Počnimo sa Dense mode.
Source-Based Distribution Trees.
Dense-mode režim je prikladno koristiti u slučaju velikog broja klijenata iz različitih multicast grupa. Kada ruter primi multicast saobraćaj, prvo proverava pravilo RPF. RPF - ovo pravilo se koristi za proveru izvora multicast-a u tabeli usmeravanja unicast. Saobraćaj treba da dolazi na onaj interfejs na kojem se nalazi dati host prema verziji unicast tabele usmeravanja. Ovaj mehanizam rešava problem nastanka petlji prilikom prenosa multicast-a.

R3 iz multicast poruke saznaje izvor multicast-a (Source IP) i proverava dva toka od R1 i R2 u svojoj unicast tabeli. Tok sa onog interfejsa kojem se ukazuje u tabeli (R1 ka R3) biće proslijeđen dalje, dok će tok od R2 biti odbijen, pošto je potrebno slati pakete po S0/1 da bi se došlo do izvora multicast-a.
Pitanje je šta će se dogoditi ako imate dva ekvivalentna rute sa istom metrikom? U tom slučaju ruter će birati prema next-hop ovih ruta. Onaj sa višom IP adresom će pobediti. Ako je potrebno promeniti ovo ponašanje, može se koristiti ECMP. Više informacija. tukaj.
Nakon provere pravila RPF, ruter šalje multicast paket svim svojim PIM susedima, osim onome od kojeg je primio ovaj paket. Ostali PIM ruteri ponavljaju ovaj proces. Put kojim je multicast paket prošao od izvora do krajnjih primaoca formira drvo koje se naziva - source-based distribution tree, shortest-path tree (SPT), source tree. Tri različita naziva, izaberite bilo koji.
Kako rešiti pitanje da neki ruteri nisu primili određeni multicast tok i nemaju kome da ga šalju, ali im viši ruter šalje. Za ovo je izumljen Prune mehanizam.
Prune Message.
Na primer, R2 bo nadaljeval s pošiljanjem R3 multicast, čeprav R3 v skladu s pravili RPF zavrne to. Zakaj obremenjevati omrežje? R3 pošlje PIM Prune sporočilo, R2 pa ob prejemu tega sporočila odstrani vmesnik S0/1 iz seznama (outgoing interface list) za to stanje, seznam vmesnikov, s katerih je potrebno pošiljati ta promet.

Naslednja opredelitev PIM Prune sporočila je bolj formalna:
PIM Prune sporočilo pošlje ena usmerjevalnik drugemu usmerjevalniku, da povzroči, da drugi usmerjevalnik odstrani povezavo, na kateri je Prune prejet, iz določenega (S,G) SPT.

Po prejetju Prune sporočila R2 nastavi Prune časovnik na 3 minute. Čez tri minute bo spet začel pošiljati promet, dokler ne prejme naslednjega Prune sporočila. To velja za PIMv1.
V PIMv2 je dodan State Refresh časovnik (privzeto 60 sekund). Takoj ko je bilo poslano Prune sporočilo z R3, se ta časovnik aktivira na R3. Po poteku tega časovnika bo R3 poslalo State Refresh sporočilo, ki bo ponastavilo 3-minutni Prune Timer na R2 za to skupino.
Razlogi za pošiljanje Prune sporočila:

• Ko multicast paket ni prestal RPF preverjanja.
• Ko ni lokalno povezanih strank, ki bi zahtevale multicast skupino (IGMP Join) in ni PIM sosedov, katerim bi lahko pošiljali multicast promet (Non-prune Interface).

Graft Message.
Predstavljajte si, da R3 noče prometa od R2, pošlje Prune in prejemati multicast od R1. Ampak nenadoma je propadla povezava med R1 in R3 in R3 je ostal brez multicast. Čakati je treba 3 minute, da Prune Timer na R2 poteče. Čakanje 3 minute je dolgo, da bi skrajšali to, je treba poslati sporočilo, ki takoj odstrani ta vmesnik S0/1 na R2 iz pruned stanja. Tako sporočilo bo Graft sporočilo. Po prejemu Graft sporočila bo R2 odgovorilo z Graft-ACK.
Prune Override.

Poglejmo to shemo. R1 oddaja multicast v segment z dvema usmerjevalnikoma. R3 prejme in oddaja promet, R2 ga prejme, vendar mu ni nikogar, da bi oddajal promet. Pošlje Prune sporočilo R1 v ta segment. R1 mora odstraniti Fa0/0 s seznama in prenehati oddajati v ta segment, toda kaj bo s R3? R3 je v istem segmentu, prav tako je prejelo to Prune sporočilo in spoznalo, kako resna je situacija. Preden R1 preneha oddajati, nastavi časovnik na 3 sekunde in preneha oddajati čez 3 sekunde. 3 sekunde — ravno toliko časa ima R3, da ne izgubi svojega multicast-a. Zato R3 čim prej pošlje Pim Join sporočilo za to skupino in R1 že ne razmišlja več o prenehanju oddaje. O Join sporočilih spodaj.
Assert sporočilo.

Predstavljajmo si takšno situacijo: v eno omrežje oddajajo kar dva usmerjevalnika. Prejemata isti tok iz vira in oba ga oddajata v eno omrežje preko vmesnika e0. Zato morata določiti, kdo bo edini oddajalec za to omrežje. Za to se uporabljajo Assert sporočila. Ko R2 in R3 zaznata dupliciranje multicast prometa, torej na R2 in R3 pride multicast, ki ga sama oddajata, usmerjevalnika razumeta, da nekaj ne štima. V takem primeru usmerjevalniki pošljejo Assert sporočila, v katerih so vključeni Administrative Distance in metrika poti, preko katere se doseže vir multicast-a — 10.1.1.10. Zmagovalec se določi na ta način:

1. Tisti, ki ima nižji AD.
2. Če sta AD enaka, potem tisti, ki ima nižjo metriko.
3. Če je tudi tu enakost, potem tisti, ki ima višji IP v omrežju, v katero oddajajo ta multicast.

Zmagovalec tega glasovanja postane Designated Router. Za izbiro DR se uporabljajo tudi Pim Hello. Na začetku članka je bilo prikazano PIM Hello sporočilo, tam lahko opazite DR polje. Zmaga tisti, ki ima višje IP naslove na tej povezavi.
Koristen tabelar.

MROUTE tabela.
Po začetnem pregledu delovanja protokola PIM se moramo poglobiti v to, kako delati z multicast tabelo usmerjanja. V mroute tabeli so shranjeni podatki o tem, kateri tokovi so bili zahtevani s strani strank in kateri tokovi tečejo z multicast strežnikov.
Na primer, ob prejemu IGMP Membership Report ali PIM Join na nekem vmesniku se v tabelo usmerjanja doda zapis tipa ( *, G ):

Ta zapis pomeni, da je bil prejet zahtevek za promet z naslovom 238.38.38.38. Zastavica DC pomeni, da bo multicast deloval v gostotnem načinu, C pa pomeni, da je sprejemnik neposredno povezan z usmerjevalnikom, kar pomeni, da je usmerjevalnik prejel IGMP Membership Report in PIM Join.
Če obstaja zapis tipa (S,G), to pomeni, da imamo multicast tok:

V polju S — 192.168.1.11, imamo zapisan IP naslov vira multicast-a, ta bo preverjen s pravilo RPF. V primeru težav je najprej potrebno preveriti unicast tabelo za pot do vira. V polju Incoming Interface je naveden vmesnik, na katerega prihaja multicast. V unicast usmerjevalni tabeli mora pot do vira kazati na vmesnik, naveden tukaj. V Outgoing Interface pa je navedeno, kam bo multicast preusmerjen. Če je prazno, to pomeni, da do usmerjevalnika niso prišli zahtevki za ta promet. Več informacij o vseh zastavicah lahko najdete ovde.
PIM Sparse-mode.
Strategija Sparse-mode je nasprotna Dense-mode. Ko Sparse-mode prejme multicast promet, bo pošiljal promet samo preko tistih vmesnikov, kjer so bili zahtevki za ta tok, na primer Pim Join ali IGMP Report sporočila z zahtevkom za ta promet.
Podobni elementi pri SM in DM:

• Sosednje povezave se gradijo enako kot v PIM DM.
• Deluje pravilo RPF.
• Izbira DR je podobna.
• Mehanizem Prune Overrides in sporočila Assert sta podobna.

Za nadzor tega, komu, kje in kakšen multicast promet je potreben v omrežju, je potreben skupni informacijski center. Tak center je Rendezvous Point (RP). Vsi, ki želijo kakšen multicast promet ali prejmejo multicast promet od vira, pošljejo zahtevo na RP.
Ko RP prejme multicast promet, ga pošlje tistim usmerjevalnikom, ki so prej zahtevali ta promet.

Predstavljajmo si to topologijo, kjer je RP R3. Takoj, ko R1 prejme promet od S1, bo inkapsuliral ta multicast paket v unicast PIM Register sporočilo in ga poslal na RP. Kako ve, kdo je RP? V tem primeru je nastavljen statično, o dinamični nastavitvi RP pa se bomo pogovorili pozneje.

ip pim rp-address 3.3.3.3

RP bo se vprašal, ali je bila informacija od koga, ki bi želel prejemati to promet? Predpostavimo, da ne. Takrat bo RP poslal R1 sporočilo PIM Register-Stop, kar pomeni, da nihče ne potrebuje tega multicast, registracija je zavrnjena. R1 ne bo pošiljal multicast. Ampak gostitelj, ki izvaja multicast, ga bo pošiljal, zato bo R1 po prejemu Register-Stop zagnal števec Register-Suppression timer, ki traja 60 sekund. 5 sekund pred iztekom tega števca bo R1 poslal prazno Register sporočilo z Null-Register bit (to pomeni brez vdelanega multicast paketa) proti RP. RP pa bo ukrepal takole:

• Če prejemnikov ni bilo, jih ne bo odzvala z Register-Stop sporočilom.
• Če se prejemniki pojavijo, se na to ne bo odzvala. R1, ki v 5 sekundah ne prejme zavrnitve za svojo registracijo, bo vesel in poslal Register sporočilo z vdelanim multicastom proti RP.

Zdaj smo razumeli, kako multicast pride do RP, poskusimo odgovoriti na vprašanje, kako RP dostavi promet do prejemnikov. Tu je treba uvesti nov koncept — root-path tree (RPT). RPT je drevo s korenom v RP, ki raste proti prejemnikom in se razveja na vsakem PIM-SM usmerjevalniku. RP ga ustvari, ko prejme PIM Join sporočila in doda novo vejo v drevo. In tako stori vsak spodnji usmerjevalnik. Splošno pravilo je videti takole:

• Ko PIM-SM usmerjevalnik prejme PIM Join sporočilo na katerem koli vmesniku, razen vmesnika, za katerim se skriva RP, doda novo vejo v drevo.
• Veja se tudi doda, ko PIM-SM usmerjevalnik prejme IGMP Membership Report z neposredno povezanega gostitelja.

Predstavljajmo si, da imamo multicast stranko na usmerjevalniku R5 na skupini 228.8.8.8. Takoj ko R5 prejme IGMP Membership Report od gostitelja, R5 pošlje PIM Join v smeri RP in doda v drevo vmesnik, ki gleda na gostitelja. Nato R4 prejme PIM Join od R5, doda v drevo vmesnik Gi0/1 in pošlje PIM Join v smeri RP. Nazadnje ga RP (R3) prejme PIM Join in doda Gi0/0 v drevo. Tako dobimo registracijo prejemnika multicast. Gradimo drevo s korenom R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0.
Nato, bo se poslal PIM Join k R1 in R1 bo začel pošiljati multicast promet. Pomembno je omeniti, da, če je gostitelj zahteval promet, preden se je začelo multicast predvajanje, RP ne bo poslal PIM Join in sploh ne bo ničesar poslal proti R1.
Če med pošiljanjem multicast promet neha gostitelj želel prejemati, takoj ko RP prejme PIM Prune na vmesniku Gi0/0, bo takoj poslal PIM Register-Stop neposredno na R1, nato pa sporočilo PIM Prune preko vmesnika Gi0/1. PIM Register-stop se pošilja unicast na naslov, od katerega je prišel PIM Register.
Kot smo že prej omenili, ko usmerjevalnik pošlje PIM Join drugemu, na primer R5 na R4, se na R4 doda vnos:

In se zažene časovnik, ki ga mora R5 neprekinjeno pošiljati PIM Join sporočila, ali pa bo R4 izključil iz outgoing list. R5 bo pošiljal PIM Join sporočila vsakih 60.
Preklop na Shortest-Path Tree.
Dodali bomo vmesnik med R1 in R5, da vidimo, kako se bo promet pretakal pri tej topologiji.

Recimo, da je promet potekal po stari shemi R1-R2-R3-R4-R5 in smo tukaj priključili in nastavili vmesnik med R1 in R5.
Na začetku se bo na R5 preoblikovala unicast tabela usmerjanja in sedaj se omrežje 192.168.1.0/24 doseže preko vmesnika R5 Gi0/2. Sedaj, ko R5 prejema multicast na vmesniku Gi0/1, razume, da pravilo RPF ni zadovoljeno in da bi bilo logičneje prejemati multicast na Gi0/2. Moral bi se odjaviti iz RPT in zgraditi krajše drevo, ki se imenuje Shortest-Path Tree (SPT). Za to pošlje preko Gi0/2 PIM Join na R1 in R1 začne pošiljati multicast tudi preko Gi0/2. Zdaj se mora R5 odjaviti iz RPT, da ne prejema dveh kopij. Za to pošlje sporočilo Prune, označuje naslov ip vira in vstavlja poseben bit - RPT-bit. To pomeni, da mi ne pošiljajte prometa, imam tukaj boljše drevo. RP tudi pošilja PIM Prune sporočila proti R1, vendar ne pošilja Register-Stop sporočila. Še ena značilnost: R5 bo zdaj stalno poslal PIM Prune na RP, saj R1 še naprej pošilja PIM Register na RP vsakih minut. Dokler ne bo novih zanimanja za ta promet, bo RP odgovarjal z zavrnitvijo. R5 obvešča RP, da še naprej prejema multicast preko SPT.
Dinamično iskanje RP.
Auto-RP.
Tehnologija je lastniška od Cisco in ni posebej priljubljena, a še vedno obstaja. Delo Auto-RP temelji na dveh glavnih korakih:
1) RP pošilja RP-Announce sporočila na rezerviran naslov — 224.0.1.39, deklarirajoč sebe kot RP bodisi za vse bodisi za določene skupine. To sporočilo se pošilja vsakih minut.
2) Potreben je RP mapping agent, ki bo pošiljal RP-Discovery sporočila z navedbo, za katere skupine mora kateri RP biti poslušan. Na podlagi teh sporočil bodo običajni PIM usmerjevalniki določili svoj RP. Mapping Agent je lahko kot sam RP usmerjevalnik, pa tudi kateri koli drug PIM usmerjevalnik. RP-Discovery se pošilja na naslov 224.0.1.40 s časovnikom enega minute.
Poglejmo proces podrobneje:
Nastavimo R3 kot RP:

ip pim send-rp-announce loopback 0 scope 10

R2 kot mapping agent:

ip pim send-rp-discovery loopback 0 scope 10

Na vseh drugih se bomo pripravljali na RP preko Auto-RP:

ip pim autorp listener

Ko enkrat nastavimo R3, bo začel pošiljati RP-Announce:

R2 bo po nastavitvi mapping agenta začel pričakovati sporočila RP-Announce. Le ko najde vsaj en RP, bo začel pošiljati RP-Discovery:

Tako, ko običajni usmerjevalniki (PIM RP Listener) prejmejo ta sporočila, bodo vedeli, kje iskati RP.
Ena glavnih težav Auto-RP je, da za prejemanje sporočil RP-Announce in RP-Discovery moramo pošiljati PIM Join na naslove 224.0.1.39-40, a da bi to storili, moramo vedeti, kje se nahaja RP. Klasika problematike piščanca in jajca. Za rešitev te težave je bil izumljen način PIM Sparse-Dense-Mode. Če usmerjevalnik ne pozna RP, deluje v načinu Dense-mode, če ga pozna, pa v načinu Sparse-mode. Ko so na vmesnikih običajnih usmerjevalnikov nastavljeni PIM Sparse-mode in ukaz ip pim autorp listener, bo usmerjevalnik deloval v načinu Dense-mode le za multicast Auto-RP protokola (224.0.1.39-40).
BootStrap Router (BSR).
Ta funkcija deluje podobno kot Auto-RP. Vsak RP pošilja sporočilo mapping agentu, ki zbira informacije o mapiranju in nato pove ostalim usmerjevalnikom. Opisali bomo proces podobno kot pri Auto-RP:
1) Ko enkrat nastavimo R3 kot kandidata za RP z ukazom:

ip pim rp-candidate loopback 0

Bo R3 sprva miroval; da bi začel pošiljati posebna sporočila, mora najprej najti mapping agenta. Tako preidemo na drugi korak.
2) Nastavimo R2 kot mapping agenta:

ip pim bsr-kandidat loopback 0

R2 začne posílávat PIM Bootstrap zprávy, ve kterých se uvádí jako mapping agent:

Tato zpráva je odeslána na adresu 224.0.0.13, kterou protokol PIM používá také pro další své zprávy. Tyto zprávy jsou odesílány ve všech směrech a proto není problém s kuřetem a vejcem, jak tomu bylo u Auto-RP.
3) Jakmile RP obdrží zprávu od BSR routeru, okamžitě odešle unicastovou zprávu na adresu BSR routeru:

Poté, co BSR obdrží informace o RP, rozešle je multicastem na adresu 224.0.0.13, kterou sledují všechny PIM routery. Proto neexistuje ekvivalent příkazu ip pim autorp listener pro běžné routery v BSR.
Anycast RP s protokolem Multicast Source Discovery (MSDP).
Auto-RP a BSR nám umožňují rozložit zátěž na RP následujícím způsobem: Každá multicastová skupina má pouze jedno aktivní RP. Není možné rozložit zátěž pro jednu multicastovou skupinu mezi více RP. MSDP to provádí pomocí poskytování RP routerům se stejnou IP adresou s maskou 255.255.255.255. MSDP získává informace pomocí jedné z metod: statiky, Auto-RP nebo BSR.

Na obrázku máme konfiguraci Auto-RP s MSDP. Oba RP jsou nastaveny se IP adresou 172.16.1.1/32 na rozhraní Loopback 1 a používají se pro všechny skupiny. Při RP-Announce oba routery informují o sobě, odkazujíce na tuto adresu. Auto-RP mapping agent, obdrževší informace, rozesílá RP-Discovery o RP s adresou 172.16.1.1/32. O síti 172.16.1.1/32 informujeme routery pomocí IGP a, odpovídajícím způsobem. Tímto způsobem PIM routery požadují nebo registrují toky od RP, který je uveden jako next-hop v cestě k síti 172.16.1.1/32. Samotný protokol MSDP je určen pro RP, aby si vyměňovali zprávy o informacích o multicastu.
Zvažme takovou topologii:

Switch6 vysílá provoz na adresu 238.38.38.38 a zatím o něm ví pouze RP-R1. Switch7 a Switch8 požádali o tuto skupinu. Routery R5 a R4 odešlou PIM Join na R1 a R3, odpovídajícím způsobem. Proč? Trasa do 13.13.13.13 u R5 bude odkazovat na R1 podle metriky IGP, stejně jako u R4.
RP-R1 ví o toku a začne jej vysílat směrem k R5, ale R4 o něm nic neví, protože R1 ho prostě nebude takto odesílat. Proto je nutný 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

Mezi sebou navážou relaci a při obdržení jakéhokoli toku budou informovat svého sousedního RP.
RP-R1, as soon as it receives a stream from Switch6, will immediately send a unicast MSDP Source-Active message containing information of type (S, G) — information about the source and destination of the multicast. Now, when RP-R3 knows that there is a source like Switch6, upon receiving a request from R4 for this stream, it will send a PIM Join towards Switch6, guided by the routing table. Consequently, R1, upon receiving such a PIM Join, will start sending traffic towards RP-R3.
MSDP operates over TCP, with RPs sending keepalive messages to each other to verify their liveliness. The timer is set to 60 seconds.
The function of partitioning MSDP peers into different domains remains unclear, as the Keepalive and SA messages do not indicate affiliation with any domain. Additionally, in this topology, a configuration indicating different domains was tested — there was no difference in operation.
If anyone can provide clarity, I would gladly read it in the comments.

Izvor: habr.com