PIM protokol skup je protokola za prijenos multicasta u mreži između usmjerivača. Odnosi susjedstva grade se na isti način kao u slučaju protokola dinamičkog usmjeravanja. PIMv2 šalje Hello poruke svakih 30 sekundi na rezerviranu multicast adresu 224.0.0.13 (All-PIM-Routers). Poruka sadrži mjerače čekanja - obično jednaki 3.5*Hello Timer, odnosno 105 sekundi prema zadanim postavkama.
PIM koristi dva glavna načina rada - Dense i Sparse način. Počnimo s Dense modom.
Stabla distribucije temeljena na izvoru.
Način gustog načina rada preporučljivo je koristiti u slučaju velikog broja klijenata različitih multicast grupa. Kada usmjerivač primi multicast promet, prva stvar koju radi je provjeriti postoji li RPF pravilo. RPF - ovo se pravilo koristi za provjeru izvora multicasta s unicast tablicom usmjeravanja. Potrebno je da promet stigne do sučelja iza kojeg je taj host skriven prema verziji unicast tablice usmjeravanja. Ovaj mehanizam rješava problem petlje koja se javlja tijekom multicast prijenosa.
R3 će prepoznati višestruki izvor (izvorni IP) iz multicast poruke i provjeriti dva toka iz R1 i R2 pomoću svoje unicast tablice. Stream sa sučelja na koje pokazuje tablica (R1 do R3) bit će poslat dalje, a stream s R2 će biti ispušten, jer da biste došli do multicast izvora, morate poslati pakete preko S0/1.
Pitanje je što se događa ako imate dvije ekvivalentne rute s istom metrikom? U tom slučaju, usmjerivač će odabrati sljedeći skok među ovim rutama. Pobjeđuje onaj tko ima veću IP adresu. Ako trebate promijeniti ovo ponašanje, možete koristiti ECMP. Više detalja .
Nakon provjere RPF pravila, usmjerivač šalje multicast paket svim svojim PIM susjedima, osim onog od kojeg je paket primljen. Drugi PIM usmjerivači ponavljaju ovaj postupak. Put kojim je multicast paket prošao od izvora do krajnjih primatelja tvori stablo koje se naziva izvorno stablo distribucije, stablo najkraćeg puta (SPT), izvorno stablo. Tri različita imena, odaberite bilo koje.
Kako riješiti problem da neki ruteri nisu odustali od nekog multicast streama i nema ga kome poslati, nego upstream ruter šalje njemu. Za to je izumljen mehanizam Prune.
Orezati poruku.
Na primjer, R2 će nastaviti slati multicast R3, iako ga R3, prema RPF pravilu, ispušta. Zašto učitavati kanal? R3 šalje PIM Prune Message i R2 će, po primitku ove poruke, ukloniti sučelje S0/1 s popisa odlaznih sučelja za ovaj tok, popisa sučelja s kojih bi ovaj promet trebao biti poslan.
Slijedi formalnija definicija PIM Prune poruke:
Poruku PIM Prune šalje jedan usmjerivač drugom usmjerivaču kako bi drugi usmjerivač uklonio vezu na kojoj je primljena Prune od određenog (S,G) SPT-a.
Nakon primitka poruke za obrezivanje, R2 postavlja mjerač vremena za obrezivanje na 3 minute. Nakon tri minute, ponovno će početi slati promet dok ne primi još jednu Prune poruku. Ovo je u PIMv1.
A u PIMv2 dodan je timer State Refresh (60 sekundi prema zadanim postavkama). Čim je poruka orezivanja poslana s R3, ovaj se mjerač vremena pokreće na R3. Po isteku ovog mjerača vremena, R3 će poslati poruku o osvježavanju stanja, koja će poništiti 3-minutni mjerač vremena za obrezivanje na R2 za ovu grupu.
Razlozi za slanje poruke orezivanja:
- Kada multicast paket ne prođe RPF provjeru.
- Kada nema lokalno povezanih klijenata koji su zatražili multicast grupu (IGMP Join) i nema PIM susjeda kojima se multicast promet može slati (Non-prune Interface).
Graft Poruka.
Zamislimo da R3 nije želio promet od R2, poslao je Prune i primio multicast od R1. Ali iznenada je kanal između R1-R3 pao i R3 je ostao bez multicasta. Možete pričekati 3 minute dok ne istekne mjerač vremena za obrezivanje na R2. 3 minute je dugo čekanje, kako ne biste čekali, morate poslati poruku koja će trenutno dovesti ovo S0/1 sučelje na R2 iz očišćenog stanja. Ova će poruka biti Graft poruka. Nakon što primi Graft poruku, R2 će odgovoriti s Graft-ACK.
Obrezivanje Nadjačavanje.
Pogledajmo ovaj dijagram. R1 emitira multicast u segment s dva usmjerivača. R3 prima i emitira promet, R2 prima, ali nema kome emitirati promet. Šalje poruku Prune R1 u ovom segmentu. R1 bi trebao ukloniti Fa0/0 s liste i prestati emitirati u ovom segmentu, ali što će biti s R3? I R3 je u istom segmentu, također je primio ovu poruku od Prune i shvatio tragediju situacije. Prije nego što R1 prestane emitirati, postavlja mjerač vremena od 3 sekunde i prestat će emitirati nakon 3 sekunde. 3 sekunde - točno toliko vremena R3 ima da ne izgubi svoj multicast. Stoga R3 šalje Pim Join poruku za ovu grupu što je prije moguće, a R1 više ne pomišlja prekinuti emitiranje. O Join porukama u nastavku.
Potvrdi poruku.
Zamislimo ovu situaciju: dva usmjerivača emitiraju na jednu mrežu odjednom. Oni primaju isti tok od izvora i oba ga emitiraju u istu mrežu iza sučelja e0. Stoga trebaju odrediti tko će biti jedan i jedini emiter za ovu mrežu. Za to se koriste poruke potvrđivanja. Kada R2 i R3 otkriju dupliciranje multicast prometa, odnosno R2 i R3 prime multicast koji sami emitiraju, ruteri shvaćaju da tu nešto nije u redu. U ovom slučaju, usmjerivači šalju Assert poruke, koje uključuju administrativnu udaljenost i metriku rute kojom se dolazi do multicast izvora - 10.1.1.10. Pobjednik se određuje na sljedeći način:
- Onaj s nižim AD-om.
- Ako su AD jednaki, tko ima nižu metriku.
- Ako je tu jednakost, onda onaj koji ima viši IP u mreži na koju emitiraju ovaj multicast.
Pobjednik ovog glasovanja postaje imenovani usmjerivač. Pim Hello također se koristi za odabir DR-ova. Na početku članka prikazana je poruka PIM Hello, tamo možete vidjeti polje DR. Pobjeđuje onaj s najvišom IP adresom na ovoj poveznici.
Koristan znak:
Tablica MROUTE.
Nakon početnog pogleda na način rada PIM protokola, moramo razumjeti kako raditi s multicast tablicom usmjeravanja. Tablica mroute pohranjuje informacije o tome koji su tokovi zatraženi od klijenata i koji tokovi teku s multicast poslužitelja.
Na primjer, kada se IGMP Membership Report ili PIM Join primi na nekom sučelju, zapis tipa ( *, G ) dodaje se u tablicu usmjeravanja:
Ovaj unos znači da je primljen prometni zahtjev s adresom 238.38.38.38. Oznaka DC znači da će multicast raditi u gustom načinu rada, a C znači da je primatelj izravno povezan s usmjerivačem, odnosno da je usmjerivač primio IGMP Membership Report i PIM Join.
Ako postoji zapis tipa (S,G) to znači da imamo multicast stream:
U polju S - 192.168.1.11 registrirali smo IP adresu multicast izvora, to će biti provjereno RPF pravilom. Ako postoje problemi, prva stvar koju trebate učiniti je provjeriti unicast tablicu za rutu do izvora. U polju Dolazno sučelje označava sučelje na koje se prima multicast. U unicast tablici usmjeravanja, ruta do izvora mora se odnositi na sučelje navedeno ovdje. Odlazno sučelje određuje kamo će multicast biti preusmjeren. Ako je prazan, usmjerivač nije primio zahtjeve za ovaj promet. Više informacija o svim zastavama možete pronaći .
PIM Sparse način rada.
Strategija Sparse-moda je suprotna od Dense-moda. Kada Sparse-mode prima multicast promet, slat će promet samo kroz ona sučelja gdje su postojali zahtjevi za ovaj protok, na primjer Pim Join ili IGMP Report poruke koje zahtijevaju ovaj promet.
Slični elementi za SM i DM:
- Međususjedski odnosi se grade na isti način kao u PIM DM-u.
- RPF pravilo funkcionira.
- Izbor DR je sličan.
- Mehanizam poruka Prune Overrides i Assert sličan je.
Za kontrolu tko, gdje i kakav multicast promet je potreban na mreži, potreban je zajednički informacijski centar. Naš centar će biti Rendezvous Point (RP). Svatko tko želi nekakav multicast promet ili je netko počeo primati multicast promet sa izvora, onda to šalje na RP.
Kada RP primi multicast promet, poslat će ga onim usmjerivačima koji su prethodno zatražili ovaj promet.
Zamislimo topologiju u kojoj je RP R3. Čim R1 primi promet od S1, on enkapsulira ovaj multicast paket u unicast PIM Register poruku i šalje je RP-u. Kako on zna tko je RP? U ovom slučaju se konfigurira statički, ao dinamičkoj konfiguraciji RP ćemo govoriti kasnije.
ip pim rp-adresa 3.3.3.3
RP će pogledati - je li bilo informacija od nekoga tko bi želio primiti ovaj promet? Pretpostavimo da nije. Tada će RP poslati R1 PIM Register-Stop poruku, što znači da nikome ne treba ovaj multicast, registracija je odbijena. R1 neće slati multicast. Ali višesmjerni izvorni host će ga poslati, tako da će R1, nakon što primi Register-Stop, pokrenuti mjerač vremena za suzbijanje registra koji iznosi 60 sekundi. 5 sekundi prije isteka vremena, R1 će poslati praznu poruku Register s bitom Null-Register (to jest, bez enkapsuliranog multicast paketa) prema RP-u. RP će se zauzvrat ponašati ovako:
- Ako nije bilo primatelja, tada će odgovoriti porukom Register-Stop.
- Ako se primatelji pojave, on na to nikako neće odgovoriti. R1, nakon što nije dobio odbijenicu za registraciju u roku od 5 sekundi, bit će sretan i poslati poruku Registriraj se s inkapsuliranim multicastom na RP.
Čini se da smo shvatili kako multicast dolazi do RP-a, sada pokušajmo odgovoriti na pitanje kako RP isporučuje promet primateljima. Ovdje je potrebno uvesti novi koncept - root-path tree (RPT). RPT je stablo ukorijenjeno u RP, raste prema primateljima, granajući se na svakom PIM-SM usmjerivaču. RP ga stvara primanjem PIM Join poruka i dodaje novu granu stablu. I tako, svaki nizvodni usmjerivač radi. Opće pravilo izgleda ovako:
- Kada PIM-SM usmjerivač primi PIM Join poruku na bilo kojem sučelju osim sučelja iza kojeg je skriven RP, on dodaje novu granu stablu.
- Grana se također dodaje kada PIM-SM usmjerivač primi izvješće o članstvu u IGMP-u od izravno povezanog glavnog računala.
Zamislimo da imamo multicast klijenta na R5 ruteru za grupu 228.8.8.8. Čim R5 primi IGMP Membership Report od glavnog računala, R5 šalje PIM Join u smjeru RP-a i sam dodaje sučelje stablu koje gleda na glavno računalo. Zatim R4 prima PIM Join od R5, dodaje sučelje Gi0/1 stablu i šalje PIM Join u smjeru RP-a. Konačno, RP ( R3 ) prima PIM Join i dodaje Gi0/0 stablu. Tako je multicast primatelj registriran. Gradimo stablo s korijenom R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0.
Nakon toga, PIM pridruživanje bit će poslano R1 i R1 će početi slati multicast promet. Važno je napomenuti da ako je domaćin zatražio promet prije početka multicast emitiranja, tada RP neće poslati PIM Join i neće uopće ništa poslati R1.
Ako iznenada dok se multicast šalje, domaćin prestane željeti da ga primi, čim RP primi PIM Prune na Gi0/0 sučelju, odmah će poslati PIM Register-Stop izravno na R1, a zatim PIM Prune poruka putem sučelja Gi0/1. PIM Register-stop šalje se putem unicast-a na adresu s koje je došao PIM registar.
Kao što smo ranije rekli, čim ruter pošalje PIM Join drugom, na primjer R5 do R4, tada se zapis dodaje u R4:
Pokreće se mjerač vremena koji R5 stalno mora poništavati ovaj mjerač PIM Join poruka, inače će R4 biti isključen s odlaznog popisa. R5 će poslati svakih 60 PIM Join poruka.
Prebacivanje stabla najkraćeg puta.
Dodat ćemo sučelje između R1 i R5 i vidjeti kako promet teče ovom topologijom.
Pretpostavimo da je promet poslan i primljen prema staroj shemi R1-R2-R3-R4-R5, a ovdje smo spojili i konfigurirali sučelje između R1 i R5.
Prije svega, moramo ponovno izgraditi unicast tablicu usmjeravanja na R5 i sada se do mreže 192.168.1.0/24 dolazi preko R5 Gi0/2 sučelja. Sada R5, primajući multicast na sučelju Gi0/1, razumije da RPF pravilo nije zadovoljeno i bilo bi logičnije primati multicast na Gi0/2. Trebao bi se odspojiti s RPT-a i izgraditi kraće stablo nazvano Stablo najkraćeg puta (SPT). Da bi to učinio, on šalje PIM Join R0 preko Gi2/1 i R1 počinje slati multicast također preko Gi0/2. Sada se R5 mora odjaviti s RPT-a kako ne bi primao dvije kopije. Da bi to učinio, šalje Prune poruku u kojoj se navodi izvorna IP adresa i umeće poseban bit - RPT-bit. To znači da mi ne trebate slati promet, ja ovdje imam bolje stablo. RP također šalje PIM Prune poruke na R1, ali ne šalje Register-Stop poruku. Još jedna značajka: R5 će sada kontinuirano slati PIM Prune RP-u, dok R1 nastavlja slati PIM Register RP-u svake minute. Sve dok ne bude novih ljudi koji žele ovaj promet, RP će ga odbijati. R5 obavještava RP da nastavlja primati multicast putem SPT-a.
Dinamičko RP pretraživanje.
Auto-RP.
Ova tehnologija je u vlasništvu Cisca i nije osobito popularna, ali je još uvijek živa. Rad Auto-RP-a sastoji se od dvije glavne faze:
1) RP šalje RP-Announce poruke na rezerviranu adresu - 224.0.1.39, proglašavajući se RP za sve ili za određene grupe. Ova se poruka šalje svake minute.
2) Potreban je agent za mapiranje RP-a, koji će poslati RP-Discovery poruke koje pokazuju za koje grupe koji RP treba slušati. Na temelju te poruke obični PIM usmjerivači sami će odrediti RP. Agent za mapiranje može biti ili sam RP usmjerivač ili zasebni PIM usmjerivač. RP-Discovery se šalje na adresu 224.0.1.40 s mjeračem vremena od jedne minute.
Pogledajmo detaljnije proces:
Konfigurirajmo R3 kao RP:
ip pim send-rp-announce povratna petlja 0 opseg 10
R2 kao agent za mapiranje:
ip pim slanje-rp-otkrivanje povratna petlja 0 opseg 10
A na svim ostalima očekujemo RP putem Auto-RP-a:
ip pim autorp slušatelj
Nakon što konfiguriramo R3, počet će slati RP-najavu:
I R2 će, nakon postavljanja agenta za mapiranje, početi čekati poruku RP-Announce. Tek kada pronađe barem jedan RP, počet će slati RP-Discovery:
Na ovaj način, čim redovni usmjerivači (PIM RP Listener) prime ovu poruku, znat će gdje tražiti RP.
Jedan od glavnih problema s Auto-RP-om je da za primanje RP-Announce i RP-Discovery poruka morate poslati PIM Join na adrese 224.0.1.39-40, a za slanje morate znati gdje RP se nalazi. Klasičan problem kokoši i jajeta. Kako bi se riješio ovaj problem, izumljen je PIM Sparse-Dense-Mode. Ako usmjerivač ne poznaje RP, tada radi u Dense-modu, ako poznaje, onda u Sparse-modu. Kada su PIM Sparse-mode i ip pim autorp listener naredba konfigurirani na sučeljima uobičajenih usmjerivača, usmjerivač će raditi u Dense-modu samo za multicasting izravno iz Auto-RP protokola (224.0.1.39-40).
BootStrap usmjerivač (BSR).
Ova funkcija radi slično kao Auto-RP. Svaki RP šalje poruku agentu za mapiranje, koji prikuplja informacije o mapiranju i zatim ih obavještava svim ostalim usmjerivačima. Opišimo proces sličan Auto-RP-u:
1) Nakon što konfiguriramo R3 kao kandidata da bude RP, naredbom:
ip pim rp-kandidat povratna petlja 0
Tada R3 neće učiniti ništa; da bi počeo slati posebne poruke, prvo mora pronaći agenta za mapiranje. Dakle, prelazimo na drugi korak.
2) Konfigurirajte R2 kao agenta za mapiranje:
ip pim bsr-kandidat povratna petlja 0
R2 počinje slati PIM Bootstrap poruke, gdje se označava kao agent za mapiranje:
Ova poruka se šalje na adresu 224.0.013, koju PIM protokol također koristi za svoje druge poruke. Šalje ih u svim smjerovima i stoga nema problema s kokošju i jajetom kao u Auto-RP-u.
3) Čim RP primi poruku od BSR rutera, odmah će poslati unicast poruku na adresu BSR rutera:
Nakon toga će BSR, nakon što primi informaciju o RP-ovima, poslati multicast na adresu 224.0.0.13, koju slušaju svi PIM ruteri. Dakle, analog naredbe ip pim autorp slušatelj za obične usmjerivače koji nisu u BSR-u.
Anycast RP s Multicast Source Discovery Protocol (MSDP).
Auto-RP i BSR dopuštaju nam da rasporedimo opterećenje na RP na sljedeći način: Svaka multicast grupa ima samo jedan aktivni RP. Neće biti moguće raspodijeliti opterećenje za jednu multicast grupu na nekoliko RP-ova. MSDP to čini izdavanjem RP usmjerivačima iste IP adrese s maskom 255.255.255.255. MSDP uči informacije pomoću jedne od metoda: statičke, Auto-RP ili BSR.
Na slici imamo Auto-RP konfiguraciju s MSDP-om. Oba RP-a su konfigurirana s IP adresom 172.16.1.1/32 na sučelju Loopback 1 i koristi se za sve grupe. Uz RP-Announce, oba usmjerivača se oglašavaju upućivanjem na ovu adresu. Agent Auto-RP mapiranja, nakon što primi informaciju, šalje RP-Discovery o RP-u s adresom 172.16.1.1/32. Usmjerivačima govorimo o mreži 172.16.1.1/32 koristeći IGP i, sukladno tome. Stoga PIM usmjerivači zahtijevaju ili registriraju tokove od RP-a koji je naveden kao sljedeći skok na ruti do mreže 172.16.1.1/32. Sam MSDP protokol dizajniran je za same RP-ove za razmjenu poruka o multicast informacijama.
Razmotrite ovu topologiju:
Switch6 emitira promet na adresu 238.38.38.38 i za sada za to zna samo RP-R1. Switch7 i Switch8 zatražili su ovu grupu. Usmjerivači R5 i R4 će poslati PIM Join na R1 odnosno R3. Zašto? Ruta do 13.13.13.13 za R5 odnosit će se na R1 koristeći IGP metriku, baš kao i za R4.
RP-R1 zna za stream i počet će ga emitirati prema R5, ali R4 ne zna ništa o njemu, budući da ga R1 neće jednostavno poslati. Stoga je MSDP neophodan. Konfiguriramo ga na R1 i R5:
ip msdp peer 3.3.3.3 povezivanje-izvor Loopback1 na R1
ip msdp peer 1.1.1.1 povezivanje-izvor Loopback3 na R3
Međusobno će pokrenuti sesiju i kada prime bilo kakav tok, prijavit će to svom RP susjedu.
Čim RP-R1 primi stream od Switch6, odmah će poslati unicast MSDP Source-Active poruku, koja će sadržavati informacije poput (S, G) - informacije o izvoru i odredištu multicasta. Sada kada RP-R3 zna da će izvor kao što je Switch6, kada primi zahtjev od R4 za ovaj tok, poslati PIM Join prema Switch6, vođen tablicom usmjeravanja. Posljedično, R1 nakon što primi takav PIM Join počet će slati promet prema RP-R3.
MSDP radi preko TCP-a, RP-ovi šalju jedni drugima poruke za provjeru ispravnosti. Mjerač vremena je 60 sekundi.
Funkcija dijeljenja MSDP peera u različite domene ostaje nejasna, budući da Keepalive i SA poruke ne ukazuju na članstvo u bilo kojoj domeni. Također, u ovoj topologiji testirali smo konfiguraciju koja ukazuje na različite domene - nije bilo razlike u izvedbi.
Ako netko može pojasniti, rado ću to pročitati u komentarima.
Izvor: www.habr.com