Protokol PIM je nabor protokolov za prenos multicast v omrežju med usmerjevalniki. Sosedski odnosi so zgrajeni na enak način kot v primeru dinamičnih usmerjevalnih protokolov. PIMv2 pošlje pozdravna sporočila vsakih 30 sekund na rezervirani večnamenski naslov 224.0.0.13 (vsi usmerjevalniki PIM). Sporočilo vsebuje časovnike zadrževanja - običajno enako 3.5*Hello Timer, kar je privzeto 105 sekund.
PIM uporablja dva glavna načina delovanja – gost in redek način. Začnimo z načinom Dense.
Na izvoru temelječa distribucijska drevesa.
Način zgoščenega načina je priporočljivo uporabljati v primeru velikega števila odjemalcev različnih skupin multicast. Ko usmerjevalnik prejme multicast promet, najprej preveri za pravilo RPF. RPF - to pravilo se uporablja za preverjanje vira multicast z usmerjevalno tabelo za enooddajanje. Potrebno je, da promet prispe na vmesnik, za katerim je ta gostitelj skrit glede na različico unicast usmerjevalne tabele. Ta mehanizem rešuje problem zanke, ki se pojavi med multicast prenosom.
R3 bo prepoznal multicast vir (izvorni IP) iz multicast sporočila in preveril dva toka iz R1 in R2 s svojo tabelo unicast. Tok iz vmesnika, na katerega kaže tabela (R1 do R3), bo prenesen naprej, tok iz R2 pa bo opuščen, saj morate za dostop do multicast vira poslati pakete prek S0/1.
Vprašanje je, kaj se zgodi, če imate dve enakovredni poti z isto metriko? V tem primeru bo usmerjevalnik iz teh poti izbral naslednji skok. Zmaga tisti, ki ima višji naslov IP. Če morate spremeniti to vedenje, lahko uporabite ECMP. Več podrobnosti .
Po preverjanju pravila RPF usmerjevalnik pošlje multicast paket vsem svojim PIM sosedom, razen tistemu, od katerega je bil paket prejet. Drugi usmerjevalniki PIM ponovijo ta postopek. Pot, ki jo je multicast paket opravil od vira do končnih prejemnikov, tvori drevo, imenovano izvorno distribucijsko drevo, drevo najkrajše poti (SPT), izvorno drevo. Tri različna imena, izberite poljubno.
Kako rešiti problem, da nekateri routerji niso obupali nad nekim multicast streamom in ga nimajo komu poslati, upstream router pa pošlje njemu. Mehanizem Prune je bil izumljen za to.
Obrezovanje sporočila.
Na primer, R2 bo še naprej pošiljal multicast R3, čeprav ga R3 v skladu s pravilom RPF opusti. Zakaj naložiti kanal? R3 pošlje PIM Prune Message in R2 bo po prejemu tega sporočila odstranil vmesnik S0/1 s seznama odhodnih vmesnikov za ta tok, seznama vmesnikov, s katerih naj bi bil poslan ta promet.
Sledi bolj formalna definicija sporočila PIM Prune:
Sporočilo PIM Prune pošlje en usmerjevalnik drugemu usmerjevalniku, da povzroči, da drugi usmerjevalnik odstrani povezavo, na kateri prejme Prune od določenega (S,G) SPT.
Po prejemu sporočila za obrezovanje R2 nastavi časovnik za obrezovanje na 3 minute. Po treh minutah bo znova začel pošiljati promet, dokler ne prejme novega sporočila Prune. To je v PIMv1.
In v PIMv2 je bil dodan časovnik za osvežitev stanja (privzeto 60 sekund). Takoj ko je iz R3 poslano sporočilo Prune, se ta časovnik zažene na R3. Po poteku tega časovnika bo R3 poslal sporočilo o osvežitvi stanja, ki bo ponastavilo 3-minutni časovnik za obrezovanje na R2 za to skupino.
Razlogi za pošiljanje sporočila Prune:
- Ko multicast paket ne uspe preveriti RPF.
- Ko ni lokalno povezanih odjemalcev, ki so zahtevali multicast skupino (IGMP Join), in ni sosedov PIM, ki bi jim lahko poslal multicast promet (Non-prune Interface).
Graft Message.
Predstavljajmo si, da R3 ni želel prometa od R2, je poslal Prune in prejel multicast od R1. Toda nenadoma je kanal med R1-R3 padel in R3 je ostal brez multicasta. Počakate lahko 3 minute, da poteče časovnik za obrezovanje na R2. 3 minute je dolgo čakanje, da ne bi čakali, morate poslati sporočilo, ki bo ta vmesnik S0/1 v R2 takoj preneslo iz obrezanega stanja. To sporočilo bo sporočilo presaditve. Po prejemu sporočila Graft bo R2 odgovoril z Graft-ACK.
Preglasitev obrezovanja.
Poglejmo ta diagram. R1 oddaja multicast v segment z dvema usmerjevalnikoma. R3 sprejema in oddaja promet, R2 sprejema, vendar nima komu oddajati prometa. Pošlje sporočilo Prune na R1 v tem segmentu. R1 bi moral odstraniti Fa0/0 s seznama in prenehati oddajati v tem segmentu, kaj pa bo z R3? In R3 je v istem segmentu, prav tako je prejel to sporočilo od Prune in razumel tragičnost situacije. Preden R1 preneha z oddajanjem, nastavi časovnik na 3 sekunde in preneha z oddajanjem po 3 sekundah. 3 sekunde - točno toliko časa ima R3, da ne izgubi svojega multicasta. Zato R3 čim prej pošlje sporočilo Pim Join za to skupino in R1 ne pomisli več na prekinitev oddajanja. Spodnja sporočila o pridružitvi.
Uveljavi sporočilo.
Predstavljajmo si to situacijo: dva usmerjevalnika hkrati oddajata v eno omrežje. Od vira prejemata isti tok in ga oba oddajata v isto omrežje za vmesnikom e0. Zato morajo določiti, kdo bo edini izdajatelj za to omrežje. Za to se uporabljajo potrditvena sporočila. Ko R2 in R3 zaznata podvajanje multicast prometa, to pomeni, da R2 in R3 prejmeta multicast, ki ga sama oddajata, usmerjevalniki razumejo, da tukaj nekaj ni v redu. V tem primeru usmerjevalniki pošljejo sporočila Assert, ki vključujejo administrativno razdaljo in metriko poti, s katero je dosežen vir multicast - 10.1.1.10. Zmagovalec je določen na naslednji način:
- Tisti z nižjim AD.
- Če sta AD enaka, kdo ima nižjo meritev.
- Če je tukaj enakost, potem tisti, ki ima višji IP v omrežju, kamor oddajajo ta multicast.
Zmagovalec tega glasovanja postane imenovani usmerjevalnik. Pim Hello se uporablja tudi za izbiro DR. Na začetku članka je bilo prikazano sporočilo PIM Hello, tam lahko vidite polje DR. Zmaga tisti z najvišjim naslovom IP na tej povezavi.
Uporaben znak:
Tabela MROUTE.
Po začetnem pogledu na delovanje protokola PIM moramo razumeti, kako delati z usmerjevalno tabelo za večvrstno oddajanje. Tabela mroute shranjuje informacije o tem, kateri tokovi so bili zahtevani od odjemalcev in kateri tokovi tečejo iz strežnikov za večvrstno oddajanje.
Na primer, ko na nekem vmesniku prejme poročilo o članstvu IGMP ali PIM Join, se v usmerjevalno tabelo doda zapis vrste ( *, G ):
Ta vnos pomeni, da je bila prejeta prometna zahteva z naslovom 238.38.38.38. Zastavica DC pomeni, da bo multicast deloval v gostem načinu, C pa pomeni, da je prejemnik 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 polje S - 192.168.1.11 smo registrirali naslov IP multicast vira, prav tega bo preverjalo pravilo RPF. Če pride do težav, je prva stvar, ki jo morate storiti, preveriti unicast tabelo za pot do vira. V polju Dohodni vmesnik označuje vmesnik, na katerega je prejeto multicast. V enoposteljni usmerjevalni tabeli se mora pot do vira nanašati na tukaj naveden vmesnik. Odhodni vmesnik določa, kam bo multicast preusmerjen. Če je prazen, potem usmerjevalnik ni prejel nobenih zahtev za ta promet. Več informacij o vseh zastavah lahko najdete .
PIM Sparse način.
Strategija redkega načina je nasprotje gostega načina. Ko Sparse-mode prejme multicast promet, bo poslal samo promet prek tistih vmesnikov, kjer so bile zahteve za ta tok, na primer sporočila Pim Join ali IGMP Report, ki zahtevajo ta promet.
Podobni elementi za SM in DM:
- Sosedski odnosi se gradijo na enak način kot v PIM DM.
- Pravilo RPF deluje.
- Izbor DR je podoben.
- Mehanizem sporočil Prune Overrides in Assert je podoben.
Za nadzor, kdo, kje in kakšen multicast promet je potreben v omrežju, je potreben skupni informacijski center. Naše središče bo Rendezvous Point (RP). Kdor hoče nekakšen multicast promet ali je nekdo začel prejemati multicast promet od vira, potem ga pošlje na RP.
Ko RP prejme multicast promet, ga bo poslal tistim usmerjevalnikom, ki so predhodno zahtevali ta promet.
Predstavljajmo si topologijo, kjer je RP R3. Takoj ko R1 prejme promet od S1, enkapsulira ta multicast paket v unicast PIM Register sporočilo in ga pošlje RP. Kako ve, kdo je RP? V tem primeru je konfiguriran statično, o dinamični konfiguraciji RP pa bomo govorili kasneje.
ip pim rp-naslov 3.3.3.3
RP bo pogledal - ali so bile informacije od nekoga, ki bi želel prejeti ta promet? Predpostavimo, da ni bilo. Nato bo RP poslal R1 sporočilo PIM Register-Stop, kar pomeni, da nihče ne potrebuje tega multicasta, registracija je zavrnjena. R1 ne bo pošiljal multicast. Toda izvorni gostitelj večvrstnega oddajanja ga bo poslal, tako da bo R1 po prejemu Register-Stop zagnal časovnik za zatiranje registra, ki je enak 60 sekundam. 5 sekund pred iztekom tega časovnika bo R1 proti RP poslal prazno sporočilo Register z bitom Null-Register (to je brez inkapsuliranega paketa za večoddajanje). RP pa bo deloval takole:
- Če ni bilo prejemnikov, se bo odzval s sporočilom Register-Stop.
- Če se prejemniki pojavijo, se na to nikakor ne bo odzval. R1, ki v 5 sekundah ni prejel zavrnitve registracije, bo vesel in RP poslal sporočilo o registraciji z inkapsuliranim multicastom.
Zdi se, da smo ugotovili, kako multicast doseže RP, zdaj pa poskusimo odgovoriti na vprašanje, kako RP dostavlja promet prejemnikom. Tukaj je potrebno uvesti nov koncept - drevo korenske poti (RPT). RPT je drevo, ki ima korenine v RP, raste proti prejemnikom in se razveja na vsakem usmerjevalniku PIM-SM. RP ga ustvari tako, da prejme sporočila PIM Join in drevesu doda novo vejo. In tako vsak spodnji usmerjevalnik počne. Splošno pravilo izgleda takole:
- Ko usmerjevalnik PIM-SM prejme sporočilo PIM Join na katerem koli vmesniku, razen vmesniku, za katerim je skrit RP, doda novo vejo v drevo.
- Podružnica je dodana tudi, ko usmerjevalnik PIM-SM prejme poročilo o članstvu IGMP od neposredno povezanega gostitelja.
Predstavljajmo si, da imamo multicast odjemalca na usmerjevalniku R5 za skupino 228.8.8.8. Takoj, ko R5 od gostitelja prejme poročilo o članstvu IGMP, pošlje PIM Join v smeri RP in sam doda vmesnik drevesu, ki gleda na gostitelja. Nato R5 prejme PIM Join od R4, doda vmesnik Gi5/0 v drevo in pošlje PIM Join v smeri RP. Končno RP ( R1 ) prejme pridružitev PIM in v drevo doda Gi3/0. Tako je multicast prejemnik registriran. Gradimo drevo s korenom R0-Gi3/0 → R0-Gi4/0 → R1-Gi5/0.
Po tem bo PIM Join poslan R1 in R1 bo začel pošiljati multicast promet. Pomembno je upoštevati, da če je gostitelj zahteval promet pred začetkom multicast oddajanja, RP ne bo poslal PIM Join in R1 sploh ne bo poslal ničesar.
Če nenadoma med pošiljanjem multicast-a gostitelj preneha več želeti, da bi ga prejel, takoj ko RP prejme PIM Prune na vmesniku Gi0/0, bo takoj poslal PIM Register-Stop neposredno na R1 in nato PIM Prune sporočilo prek vmesnika Gi0/1. PIM Register-stop se pošlje prek unicast na naslov, s katerega je prišel register PIM.
Kot smo že povedali, takoj ko usmerjevalnik pošlje PIM Join drugemu, na primer R5 v R4, se v R4 doda zapis:
Zažene se časovnik, da mora R5 stalno ponastavljati ta časovnik PIM Join sporočila, sicer bo R4 izključen iz odhodnega seznama. R5 bo poslal vsakih 60 PIM Join sporočil.
Preklop drevesa po najkrajši poti.
Dodali bomo vmesnik med R1 in R5 ter videli, kako poteka promet s to topologijo.
Predpostavimo, da je bil promet poslan in sprejet po stari shemi R1-R2-R3-R4-R5, tukaj pa smo povezali in konfigurirali vmesnik med R1 in R5.
Najprej moramo znova zgraditi usmerjevalno tabelo za enoposteljno usmerjanje na R5 in zdaj je omrežje 192.168.1.0/24 doseženo prek vmesnika R5 Gi0/2. Zdaj R5, ki sprejema multicast na vmesniku Gi0/1, razume, da pravilo RPF ni izpolnjeno in bi bilo bolj logično prejemati multicast na Gi0/2. Moral bi prekiniti povezavo z RPT in zgraditi krajše drevo, imenovano Shortest-Path Tree (SPT). Da bi to naredil, pošlje PIM Join na R0 prek Gi2/1 in R1 začne pošiljati multicast tudi prek Gi0/2. Zdaj se mora R5 odjaviti iz RPT, da ne bi prejel dveh izvodov. Da bi to naredil, pošlje Prune sporočilo, ki navaja izvorni naslov IP in vstavi poseben bit - RPT-bit. To pomeni, da mi ni treba pošiljati prometa, tukaj imam boljše drevo. RP pošlje tudi sporočila PIM Prune na R1, vendar ne pošlje sporočila Register-Stop. Druga funkcija: R5 bo zdaj nenehno pošiljal PIM Prune v RP, medtem ko R1 še naprej pošilja PIM Register v RP vsako minuto. Dokler ne bo novih ljudi, ki bi želeli ta promet, ga bo RP zavrnil. R5 obvesti RP, da še naprej sprejema multicast prek SPT.
Dinamično iskanje RP.
Avto-RP.
Ta tehnologija je v lasti Cisca in ni posebej priljubljena, vendar je še vedno živa. Delovanje Auto-RP je sestavljeno iz dveh glavnih stopenj:
1) RP pošlje sporočila RP-Announce na rezerviran naslov - 224.0.1.39, pri čemer se razglasi za RP za vse ali za določene skupine. To sporočilo je poslano vsako minuto.
2) Potreben je agent za preslikavo RP, ki bo poslal sporočila RP-Discovery, ki nakazujejo, za katere skupine je treba kateri RP poslušati. Iz tega sporočila bodo običajni usmerjevalniki PIM sami določili RP. Agent za preslikavo je lahko sam usmerjevalnik RP ali ločen usmerjevalnik PIM. RP-Discovery se pošlje na naslov 224.0.1.40 s časovnikom ene minute.
Oglejmo si postopek podrobneje:
Konfigurirajmo R3 kot RP:
ip pim send-rp-announce povratna zanka 0 obseg 10
R2 kot agent za preslikavo:
ip pim send-rp-discovery povratna zanka 0 obseg 10
In na vseh drugih bomo pričakovali RP preko Auto-RP:
ip pim avtorp poslušalec
Ko konfiguriramo R3, bo začel pošiljati RP-Announce:
In R2 bo po nastavitvi agenta za preslikavo začel čakati na sporočilo RP-Announce. Šele ko najde vsaj en RP, začne pošiljati RP-Discovery:
Na ta način bodo običajni usmerjevalniki (PIM RP Listener) prejeli to sporočilo, vedeli, kje naj iščejo RP.
Ena glavnih težav pri Auto-RP je ta, da morate za prejemanje sporočil RP-Announce in RP-Discovery poslati PIM Join na naslove 224.0.1.39-40, za pošiljanje pa morate vedeti, kje RP se nahaja. Klasični problem kokoš in jajce. Da bi rešili to težavo, je bil izumljen PIM Sparse-Dense-Mode. Če usmerjevalnik ne pozna RP, potem deluje v gostem načinu, če ga pozna, pa v redkem načinu. Ko sta redki način PIM in ukaz poslušalca ip pim autorp konfigurirana na vmesnikih navadnih usmerjevalnikov, bo usmerjevalnik deloval v gostem načinu samo za večoddajanje neposredno iz protokola Auto-RP (224.0.1.39-40).
BootStrap Router (BSR).
Ta funkcija deluje podobno kot Auto-RP. Vsak RP pošlje sporočilo agentu za preslikavo, ki zbere informacije o preslikavi in nato sporoči vsem drugim usmerjevalnikom. Opišimo postopek podobno kot Auto-RP:
1) Ko konfiguriramo R3 kot kandidata za RP, z ukazom:
ip pim rp-kandidat povratna zanka 0
Potem R3 ne bo naredil ničesar; da bi začel pošiljati posebna sporočila, mora najprej najti agenta za preslikavo. Tako preidemo na drugi korak.
2) Konfigurirajte R2 kot agenta za preslikavo:
ip pim bsr-kandidat povratna zanka 0
R2 začne pošiljati sporočila PIM Bootstrap, kjer se označi kot agent za preslikavo:
To sporočilo je poslano na naslov 224.0.013, ki ga protokol PIM uporablja tudi za svoja druga sporočila. Pošilja jih v vse smeri in zato ni problema s piščancem in jajcem, kot je bil v Auto-RP.
3) Takoj, ko RP prejme sporočilo od usmerjevalnika BSR, bo nemudoma poslal enoposlano sporočilo na naslov usmerjevalnika BSR:
Po tem jih bo BSR, ko prejme informacije o RP-jih, poslal z multicastom na naslov 224.0.0.13, ki ga poslušajo vsi usmerjevalniki PIM. Zato je analog ukaza ip pim avtorp poslušalec za običajne usmerjevalnike, ki niso v BSR.
Anycast RP s protokolom Multicast Source Discovery Protocol (MSDP).
Auto-RP in BSR nam omogočata, da obremenitev RP porazdelimo na naslednji način: Vsaka multicast skupina ima samo en aktiven RP. Obremenitve za eno multicast skupino ne bo mogoče porazdeliti na več RP-jev. MSDP to naredi tako, da usmerjevalnikom RP dodeli isti naslov IP z masko 255.255.255.255. MSDP se uči informacij z uporabo ene od metod: statično, Auto-RP ali BSR.
Na sliki imamo konfiguracijo Auto-RP z MSDP. Oba RP-ja sta konfigurirana z naslovom IP 172.16.1.1/32 na vmesniku Loopback 1 in se uporabljata za vse skupine. Z RP-Announce se oba usmerjevalnika oglasita s sklicevanjem na ta naslov. Agent za preslikavo Auto-RP po prejemu informacij pošlje RP-Discovery o RP z naslovom 172.16.1.1/32. Usmerjevalnikom povemo o omrežju 172.16.1.1/32 z uporabo IGP in v skladu s tem. Tako usmerjevalniki PIM zahtevajo ali registrirajo tokove iz RP, ki je določen kot naslednji skok na poti do omrežja 172.16.1.1/32. Sam protokol MSDP je zasnovan tako, da si RP-ji sami izmenjujejo sporočila o informacijah o multicastu.
Razmislite o tej topologiji:
Switch6 oddaja promet na naslov 238.38.38.38 in zaenkrat zanj ve samo RP-R1. Switch7 in Switch8 sta zahtevala to skupino. Usmerjevalniki R5 in R4 bodo poslali PIM Join na R1 oziroma R3. Zakaj? Pot do 13.13.13.13 za R5 se bo nanašala na R1 z uporabo metrike IGP, tako kot za R4.
RP-R1 ve za tok in ga bo začel oddajati proti R5, R4 pa o njem ne ve ničesar, saj ga R1 ne bo preprosto poslal. Zato je MSDP potreben. Konfiguriramo ga na R1 in R5:
ip msdp peer 3.3.3.3 povezovalni izvor Loopback1 na R1
ip msdp peer 1.1.1.1 povezovalni izvor Loopback3 na R3
Med seboj bodo vzpostavili sejo in ko bodo prejeli kakršen koli pretok, bodo o tem poročali svojemu sosedu RP.
Takoj, ko RP-R1 prejme tok od Switch6, bo nemudoma poslal sporočilo Unicast MSDP Source-Active, ki bo vsebovalo informacije, kot so (S, G) - informacije o viru in cilju multicasta. Zdaj, ko RP-R3 ve, da vir, kot je Switch6, ko prejme zahtevo od R4 za ta tok, pošlje PIM Join proti Switch6, ki ga vodi usmerjevalna tabela. Posledično bo R1, ki prejme takšno pridružitev PIM, začel pošiljati promet proti RP-R3.
MSDP deluje prek TCP, RP-ji si pošiljajo sporočila o ohranjanju delovanja, da preverijo živost. Časovnik je 60 sekund.
Funkcija delitve vrstnikov MSDP na različne domene ostaja nejasna, saj sporočila Keepalive in SA ne nakazujejo članstva v nobeni domeni. Prav tako smo v tej topologiji preizkusili konfiguracijo, ki označuje različne domene - ni bilo nobene razlike v zmogljivosti.
Če lahko kdo pojasni, bom z veseljem prebral v komentarjih.
Vir: www.habr.com