PIM protokol je skup protokola za prijenos multicast u mreži između rutera. Susjedski odnosi se grade na isti način kao iu slučaju dinamičkih protokola rutiranja. PIMv2 šalje Hello poruke svakih 30 sekundi na rezerviranu multicast adresu 224.0.0.13 (All-PIM-Routeri). Poruka sadrži tajmere čekanja - obično jednako 3.5*Hello Timer, odnosno 105 sekundi prema zadanim postavkama.
PIM koristi dva glavna načina rada - gusti i rijetki način rada. Počnimo sa Gusti način.
Stabla distribucije zasnovana na izvoru.
Gusti način rada je preporučljivo koristiti u slučaju velikog broja klijenata različitih multicast grupa. Kada ruter primi multicast promet, prva stvar koju radi je da provjeri da li ima RPF pravilo. RPF - ovo pravilo se koristi za provjeru izvora višestrukog prijenosa s jednostrukom tablicom rutiranja. Neophodno je da saobraćaj stiže na interfejs iza kojeg je ovaj host skriven prema verziji tabele unicast rutiranja. Ovaj mehanizam rješava problem petlje koja se javlja tokom multicast prijenosa.
R3 će prepoznati višestruki izvor (IP izvora) iz multicast poruke i provjeriti dva toka od R1 i R2 koristeći svoju unicast tablicu. Stream sa interfejsa na koji ukazuje tabela (R1 do R3) će se dalje prenositi, a tok sa R2 će biti ispušten, jer da biste došli do multicast izvora, morate da pošaljete pakete preko S0/1.
Pitanje je, šta se dešava ako imate dve ekvivalentne rute sa istom metrikom? U tom slučaju, ruter će odabrati sljedeći skok od ovih ruta. Ko ima veću IP adresu pobjeđuje. Ako trebate promijeniti ovo ponašanje, možete koristiti ECMP. Više detalja .
Nakon provjere RPF pravila, ruter šalje multicast paket svim svojim PIM susjedima, osim onog od koga je paket primljen. Drugi PIM ruteri ponavljaju ovaj proces. Putanja koju je multicast paket prošao od izvora do krajnjih primalaca formira stablo koje se zove stablo distribucije zasnovano na izvoru, stablo najkraćeg puta (SPT), stablo izvora. Tri različita imena, izaberite bilo koje.
Kako resiti problem sto neki ruteri nisu odustali od nekog multicast streama i nema kome da ga posalje, nego mu ga upstream ruter salje. Za to je izmišljen mehanizam Prune.
Prune Message.
Na primjer, R2 će nastaviti da šalje multicast na R3, iako ga R3, prema RPF pravilu, odbacuje. Zašto učitavati kanal? R3 šalje PIM Prune poruku i R2, nakon što primi ovu poruku, će ukloniti interfejs S0/1 sa liste odlaznih interfejsa za ovaj tok, liste interfejsa sa kojih ovaj saobraćaj treba da bude poslat.
U nastavku slijedi formalnija definicija PIM Prune poruke:
Poruku PIM Prune šalje jedan ruter drugom ruteru kako bi drugi ruter uklonio vezu na kojoj se prima Prune od određenog (S,G) SPT-a.
Nakon prijema poruke Prune, R2 postavlja tajmer za Prune na 3 minute. Nakon tri minute, ponovo će početi slati promet dok ne primi drugu Prune poruku. Ovo je u PIMv1.
A u PIMv2 je dodat tajmer za osvježavanje stanja (60 sekundi po defaultu). Čim je poruka Prune poslana sa R3, ovaj tajmer se pokreće na R3. Po isteku ovog tajmera, R3 će poslati poruku za osvježavanje stanja, koja će resetirati 3-minutni tajmer za orezivanje na R2 za ovu grupu.
Razlozi za slanje Prune poruke:
- Kada višestruki 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 može poslati višestruki promet (Sučelje bez smanjenja).
Graft Message.
Zamislimo da R3 nije želio promet od R2, poslao Prune i primio multicast od R1. Ali iznenada, kanal između R1-R3 je pao i R3 je ostao bez multicast. Možete pričekati 3 minute dok ne istekne tajmer Prune Timer na R2. 3 minuta je dugo čekanje, da ne biste čekali, morate poslati poruku koja će odmah dovesti ovaj S0/1 interfejs na R2 iz isključenog stanja. Ova poruka će biti Graft poruka. Nakon što primi poruku o kalemljenju, R2 će odgovoriti Graft-ACK.
Prune Override.
Pogledajmo ovaj dijagram. R1 emituje multicast u segment sa dva rutera. R3 prima i emituje saobraćaj, R2 prima, ali nema kome da emituje saobraćaj. Šalje Prune poruku na R1 u ovom segmentu. R1 bi trebao ukloniti Fa0/0 sa liste i zaustaviti emitovanje u ovom segmentu, ali šta će biti sa R3? I R3 je u istom segmentu, takođe je primio ovu poruku od Prune i shvatio tragediju situacije. Prije nego što R1 prekine emitiranje, postavlja tajmer od 3 sekunde i zaustavit će emitiranje nakon 3 sekunde. 3 sekunde - to je tačno koliko vremena R3 ima da ne izgubi svoj multicast. Stoga R3 šalje poruku Pim Join za ovu grupu što je prije moguće i R1 više ne razmišlja o zaustavljanju emitiranja. O porukama za pridruživanje ispod.
Potvrdite poruku.
Zamislimo ovu situaciju: dva rutera emituju na jednu mrežu odjednom. Oni primaju isti stream od izvora i oba ga emituju na istu mrežu iza interfejsa e0. Stoga treba da odrede ko će biti jedan i jedini emiter za ovu mrežu. Za to se koriste poruke potvrđivanja. Kada R2 i R3 otkriju dupliranje multicast saobraćaja, odnosno, R2 i R3 prime multicast koji sami emituju, ruteri shvataju da tu nešto nije u redu. U ovom slučaju, ruteri šalju Assert poruke, koje uključuju administrativnu udaljenost i metriku rute sa kojom se dostiže multicast izvor - 10.1.1.10. Pobjednik se utvrđuje na sljedeći način:
- Onaj sa nižim AD.
- Ako su AD jednaki, ko ima nižu metriku.
- Ako je ovdje jednakost, onda onaj koji ima veći IP u mreži na koju emituju ovaj multicast.
Pobjednik ovog glasanja postaje imenovani ruter. Pim Hello se također koristi za odabir DR. Na početku članka je prikazana poruka PIM Hello, tamo možete vidjeti DR polje. Pobjeđuje onaj sa najvećom IP adresom na ovom linku.
Koristan znak:
MROUTE Table.
Nakon početnog pogleda na to kako PIM protokol funkcionira, moramo razumjeti kako raditi sa tabelom za višestruko rutiranje. Mroute tabela pohranjuje informacije o tome koji tokovi su zatraženi od klijenata i koji tokovi teku sa multicast servera.
Na primjer, kada se na nekom sučelju primi IGMP Izvještaj o članstvu ili PIM Join, zapis tipa ( *, G ) se dodaje u tabelu usmjeravanja:
Ovaj unos znači da je primljen prometni zahtjev sa adresom 238.38.38.38. Oznaka DC znači da će multicast raditi u gustom režimu, a C znači da je primalac direktno povezan sa ruterom, odnosno da je ruter 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, registrovali smo IP adresu multicast izvora, to će biti provereno RPF pravilom. Ako postoje problemi, prva stvar koju trebate učiniti je provjeriti unikast tablicu za rutu do izvora. U polju Incoming Interface označava sučelje na koje se prima multicast. U jednoj tablici usmjeravanja, ruta do izvora mora se odnositi na sučelje specificirano ovdje. Odlazni interfejs specificira gdje će se višestruko slanje preusmjeriti. Ako je prazan, onda ruter nije primio nijedan zahtjev za ovaj promet. Više informacija o svim zastavama možete pronaći .
PIM Sparse-mode.
Strategija Sparse-mode je suprotna od Gustog-moda. Kada Sparse-mode prima višestruki promet, on će samo slati promet kroz ona sučelja gdje su postojali zahtjevi za ovaj tok, na primjer Pim Join ili IGMP Report poruke koje zahtijevaju ovaj promet.
Slični elementi za SM i DM:
- Susjedski odnosi se grade na isti način kao u PIM DM-u.
- RPF pravilo funkcionira.
- Izbor DR je sličan.
- Mehanizam poruka za poništavanje i potvrđivanje je sličan.
Za kontrolu kome, gdje i kakav multicast promet je potreban na mreži, potreban je zajednički informacioni centar. Naš centar će biti Rendezvous Point (RP). Svako ko želi neku vrstu multicast saobraćaja ili je neko počeo da prima multicast saobraćaj sa izvora, onda ga šalje u RP.
Kada RP primi multicast saobraćaj, on će ga poslati onim ruterima koji su prethodno zatražili ovaj saobraćaj.
Zamislimo topologiju u kojoj je RP R3. Čim R1 primi promet od S1, on enkapsulira ovaj višestruki paket u jednosmjernu poruku PIM Register i šalje je RP-u. Kako on zna ko je RP? U ovom slučaju se konfigurira statički, a o dinamičkoj RP konfiguraciji ćemo kasnije.
ip pim rp-adresa 3.3.3.3
RP će pogledati - je li bilo informacija od nekoga ko bi želio primiti ovaj promet? Pretpostavimo da nije. Tada će RP poslati R1 poruku PIM Register-Stop, što znači da nikome nije potreban ovaj multicast, registracija je odbijena. R1 neće slati multicast. Ali multicast izvorni host će ga poslati, tako da će R1, nakon što primi Register-Stop, pokrenuti tajmer za suzbijanje registra jednak 60 sekundi. 5 sekundi prije isteka ovog tajmera, R1 će poslati praznu poruku registra sa bitom Null-Register (to jest, bez inkapsuliranog multicast paketa) prema RP-u. RP će se zauzvrat ponašati ovako:
- Ako nije bilo primalaca, onda će odgovoriti porukom Register-Stop.
- Ako se primaoci pojave, on na to neće odgovoriti ni na koji način. R1, nakon što nije primio odbijenicu da se registruje u roku od 5 sekundi, će biti sretan i poslati Register poruku sa 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 primaocima. Ovdje je potrebno uvesti novi koncept - root-path tree (RPT). RPT je stablo ukorijenjeno u RP, koje raste prema primaocima, granajući se na svakom PIM-SM ruteru. RP ga kreira primanjem PIM Join poruka i dodaje novu granu stablu. I tako, svaki downstream ruter radi. Opšte pravilo izgleda ovako:
- Kada PIM-SM ruter primi poruku PIM Join na bilo kom interfejsu osim interfejsa iza kojeg je RP skriven, on dodaje novu granu stablu.
- Grana se također dodaje kada PIM-SM ruter primi izvještaj o članstvu IGMP-a od direktno povezanog hosta.
Zamislimo da imamo multicast klijenta na R5 ruteru za grupu 228.8.8.8. Čim R5 primi izvještaj o članstvu IGMP-a od hosta, R5 šalje PIM Join u pravcu RP-a i sam dodaje interfejs stablu koje gleda na host. Zatim, R4 prima PIM Join od R5, dodaje interfejs Gi0/1 stablu i šalje PIM Join u pravcu RP. Konačno, RP (R3) prima PIM Join i dodaje Gi0/0 stablu. Dakle, multicast primalac je registrovan. Gradimo stablo s korijenom R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0.
Nakon toga, PIM Join će biti poslan na R1 i R1 će početi slati višestruki 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 poslati ništa R1.
Ako iznenada dok se multicast šalje, host prestane da želi da ga primi, čim RP primi PIM Prune na Gi0/0 interfejsu, odmah će poslati PIM Register-Stop direktno na R1, a zatim PIM Prune poruka preko Gi0/1 interfejsa. PIM Register-stop se šalje putem unicast na adresu sa koje je PIM registar došao.
Kao što smo ranije rekli, čim ruter pošalje PIM Join drugom, na primjer R5 na R4, tada se zapis dodaje u R4:
Pokreće se i tajmer koji R5 mora stalno resetovati ovaj tajmer PIM Join poruke konstantno, inače će R4 biti isključen sa odlazne liste. R5 će poslati svakih 60 PIM Join poruka.
Prebacivanje na stablo najkraćeg puta.
Dodaćemo interfejs između R1 i R5 i videti kako saobraćaj teče sa ovom topologijom.
Pretpostavimo da je promet poslat i primljen po staroj šemi R1-R2-R3-R4-R5, a ovdje smo spojili i konfigurirali sučelje između R1 i R5.
Prije svega, moramo ponovo izgraditi unicast tabelu rutiranja na R5 i sada se do mreže 192.168.1.0/24 dolazi preko R5 Gi0/2 interfejsa. Sada R5, koji prima multicast na interfejsu Gi0/1, shvata da RPF pravilo nije zadovoljeno i bilo bi logičnije da primi multicast na Gi0/2. Trebalo bi da se odvoji od RPT-a i napravi kraće stablo pod nazivom Stablo najkraćeg puta (Shortest-Path Tree (SPT). Da bi to uradio, on šalje PIM Join na R0 preko Gi2/1 i R1 počinje slati multicast također preko Gi0/2. Sada R5 treba da se odjavi sa RPT-a kako ne bi primio dve kopije. Da bi to učinio, on šalje Pruneu poruku koja naznačuje izvornu IP adresu i ubacuje poseban bit - RPT-bit. To znači da mi ne morate slati promet, ovdje imam bolje drvo. RP takođe šalje PIM Prune poruke na R1, ali ne šalje Register-Stop poruku. Još jedna karakteristika: R5 će sada kontinuirano slati PIM Prune RP-u, jer R1 nastavlja da šalje PIM Register RP-u svake minute. Dok ne bude novih ljudi koji žele ovaj saobraćaj, RP će ga odbiti. R5 obavještava RP da nastavlja primati multicast putem SPT-a.
Dinamička RP pretraga.
Auto-RP.
Ova tehnologija je vlasništvo Cisco-a i nije posebno popularna, ali je još uvijek živa. Auto-RP operacija se sastoji od dvije glavne faze:
1) RP šalje RP-Announce poruke na rezerviranu adresu - 224.0.1.39, proglašavajući se RP ili za sve ili za određene grupe. Ova poruka se šalje svake minute.
2) Potreban je agent za RP mapiranje, koji će slati RP-Discovery poruke koje ukazuju na grupe koje RP treba slušati. Iz ove poruke će obični PIM ruteri sami odrediti RP. Agent za mapiranje može biti ili sam RP ruter ili zasebni PIM ruter. RP-Discovery se šalje na adresu 224.0.1.40 sa tajmerom od jedne minute.
Pogledajmo proces detaljnije:
Konfigurirajmo R3 kao RP:
ip pim send-rp-announce loopback 0 opseg 10
R2 kao agent za mapiranje:
ip pim send-rp-discovery loopback 0 opseg 10
A na svim ostalima očekujemo RP preko Auto-RP-a:
ip pim autorp slušalac
Nakon što konfiguriramo R3, on će početi slati RP-Announce:
A R2 će, nakon postavljanja agenta za mapiranje, početi čekati poruku RP-Announce. Tek kada pronađe barem jedan RP, počeće slati RP-Discovery:
Na ovaj način, čim obični ruteri (PIM RP Listener) prime ovu poruku, oni će znati gdje da traže RP.
Jedan od glavnih problema sa Auto-RP je to što da biste primali RP-Announce i RP-Discovery poruke, morate poslati PIM Join na adrese 224.0.1.39-40, a da biste poslali, morate znati gdje RP se nalazi. Klasični problem piletine i jaja. Da bi se riješio ovaj problem, izmišljen je PIM Sparse-Dense-Mode. Ako ruter ne poznaje RP, onda radi u gustom režimu; ako zna, onda u režimu sparse. Kada su PIM Sparse-mode i ip pim autorp listener komanda konfigurisani na sučeljima običnih rutera, ruter će raditi u gustom režimu samo za multicasting direktno iz Auto-RP protokola (224.0.1.39-40).
BootStrap Router (BSR).
Ova funkcija radi slično kao Auto-RP. Svaki RP šalje poruku agentu za mapiranje, koji prikuplja informacije o mapiranju i zatim govori svim ostalim ruterima. Hajde da opišemo proces slično kao Auto-RP:
1) Kada konfigurišemo R3 kao kandidata da bude RP, naredbom:
ip pim rp-kandidat loopback 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 loopback 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 koristi i za svoje ostale poruke. Šalje ih u svim smjerovima i stoga nema problema s kokošima i jajima kao što je bilo u Auto-RP-u.
3) Čim RP primi poruku od BSR rutera, odmah će poslati unicast poruku na adresu BSR rutera:
Nakon toga, BSR, nakon što je primio informacije o RP-ovima, će ih poslati multicastom na adresu 224.0.0.13, koju slušaju svi PIM ruteri. Dakle, analog naredbe ip pim autorp slušalac za obične rutere koji nisu u BSR-u.
Anycast RP s protokolom za otkrivanje višestrukog izvora (MSDP).
Auto-RP i BSR nam omogućavaju da rasporedimo opterećenje na RP na sljedeći način: Svaka multicast grupa ima samo jedan aktivan RP. Neće biti moguće raspodijeliti opterećenje za jednu multicast grupu na nekoliko RP-ova. MSDP to radi tako što RP ruterima daje istu IP adresu sa maskom 255.255.255.255. MSDP uči informacije koristeći jednu od metoda: statički, Auto-RP ili BSR.
Na slici imamo Auto-RP konfiguraciju sa MSDP-om. Oba RP-a su konfigurisana sa IP adresom 172.16.1.1/32 na Loopback 1 interfejsu i koriste se za sve grupe. Sa RP-Announce, oba rutera se oglašavaju pozivanjem na ovu adresu. Agent za automatsko-RP mapiranje, nakon što je primio informaciju, šalje RP-Discovery o RP-u sa adresom 172.16.1.1/32. Ruterima govorimo o mreži 172.16.1.1/32 koja koristi IGP i, shodno tome. Dakle, PIM ruteri zahtijevaju ili registruju tokove od RP-a koji je specificiran kao sljedeći skok na ruti do mreže 172.16.1.1/32. Sam MSDP protokol je dizajniran da sami RP razmjenjuju poruke o multicast informacijama.
Razmotrite ovu topologiju:
Switch6 emituje saobraćaj na adresu 238.38.38.38 i za sada samo RP-R1 zna za to. Switch7 i Switch8 su zatražili ovu grupu. Ruteri R5 i R4 će poslati PIM Join na R1 i R3, respektivno. Zašto? Ruta do 13.13.13.13 za R5 će se odnositi 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 tome, jer ga R1 neće jednostavno poslati. Stoga je MSDP neophodan. Konfiguriramo ga na R1 i 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 će pokrenuti međusobnu sesiju i kada prime bilo koji tok će to prijaviti svom RP susjedu.
Čim RP-R1 primi stream od Switch6, on će odmah poslati jednosmjernu 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 tabelom rutiranja. Prema tome, R1 nakon što je primio takav PIM Join će početi slati promet prema RP-R3.
MSDP radi preko TCP-a, RP-ovi šalju jedni drugima poruke o održavanju aktivnosti kako bi provjerili živost. Tajmer je 60 sekundi.
Funkcija podjele MSDP peer-a na različite domene ostaje nejasna, budući da Keepalive i SA poruke ne ukazuju na članstvo u bilo kojoj domeni. Takođe, u ovoj topologiji smo testirali konfiguraciju koja ukazuje na različite domene - nije bilo razlike u performansama.
Ako neko može pojasniti, rado bih pročitao u komentarima.
izvor: www.habr.com