PIM protokol je skup protokola za prijenos multicast-a u mrežama između usmjerivača. Odnosi susjedstva se uspostavljaju na sličan način kao i u slučaju dinamičkih protokola usmjeravanja. PIMv2 šalje svakih 30 sekundi Hello poruke na rezerviranu multicast adresu 224.0.0.13 (All-PIM-Routers). Poruka sadrži Hold Timers — obično jednako 3.5*Hello Timer, što je 105 sekundi prema zadanim postavkama.
PIM koristi dva osnovna načina rada — Dense i Sparse mode. Počnimo s Dense mode.
Stabla na temelju izvora.
Dense-mode je korisno koristiti kada ima mnogo klijenata različitih multicast grupa. Kada usmjerivač primi multicast promet, prvo provjerava pravilo RPF. RPF — to pravilo koristi se za provjeru izvora multicast-a s unicast tablicom usmjeravanja. Potrebno je da promet dolazi na onaj sučelje, iza kojeg se nalaze navedeni host prema unicast tablici usmjeravanja. Ovaj mehanizam rješava problem nastanka petlje tijekom prijenosa multicast-a.
R3 iz multicast poruke saznaje izvor multicast-a (Source IP) i provjerava dva toka od R1 i R2 prema svojoj unicast tablici. Tok s tog sučelja na koje ukazuje tablica (R1 prema R3) bit će proslijeđen dalje, dok će tok od R2 biti odbijen, jer da bi došao do izvora multicast-a, potrebno je slati pakete putem S0/1.
Pitanje je što će se dogoditi ako imate dva ekvivalentna puta s istom metričkom vrijednošću? U tom slučaju, usmjerivač će birati prema next-hop ovih puteva. Tko ima višu ip adresu, taj pobjeđuje. Ako je potrebno promijeniti ovo ponašanje, može se koristiti ECMP. Više informacija. .
Nakon provjere pravila RPF, usmjerivač šalje multicast paket svim svojim PIM susjedima, osim onome od kojeg je primio ovaj paket. Ostali PIM usmjerivači ponavljaju ovaj proces. Put koji je multicast paket prošao od izvora do krajnjih primatelja oblikuje stablo koje se naziva — source-based distribution tree, shortest-path tree (SPT), source tree. Tri različita naziva, birajte bilo koji.
Kako riješiti problem kada nekim usmjerivačima nije potreban neki multicast tok i ne mogu ga proslijediti, a viši usmjerivač ga šalje? Za to je zamišljen Prune mehanizam.
Prune poruka.
Na primjer, R2 će nastaviti slati R3 multicast, iako R3 prema RPF pravilu odbacuje to. Zašto opterećivati kanal? R3 šalje PIM Prune poruku, a R2 će, prilikom primanja ove poruke, ukloniti sučelje S0/1 iz popisa (outgoing interface list) za taj tok, popis sučelja s kojih treba slati taj promet.
Sljedeća je formalnija definicija PIM Prune poruke:
PIM Prune poruka se šalje od jednog usmjerivača drugom usmjerivaču kako bi se drugom usmjerivaču naložilo da ukloni vezu na kojoj je primljena Prune poruka iz određenog (S,G) SPT.
Nakon primanja Prune poruke, R2 postavlja Prune tajmer na 3 minute. Nakon tri minute ponovno će početi slati promet, sve dok ne primi novu Prune poruku. Ovo je u PIMv1.
U PIMv2 dodan je State Refresh tajmer (prema zadanim postavkama 60 sekundi). Čim se pošalje Prune poruka s R3, ovaj tajmer se pokreće na R3. Nakon isteka ovog tajmera, R3 će poslati State Refresh poruku koja će resetirati trominutni Prune tajmer na R2 za tu grupu.
Razlozi za slanje Prune poruke:
- 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 može slati multicast promet (Non-prune Interface).
Graft Poruka.
Zamislite da R3 nije želio promet od R2, poslao je Prune i primao multicast od R1. No, odjednom, veza između R1 i R3 je pala i R3 je ostao bez multikasta. Možete čekati 3 minute dok ne istekne Prune tajmer na R2. 3 minute čekanja je dugo, kako ne biste čekali, potrebno je poslati poruku koja će odmah izvesti ovo sučelje S0/1 na R2 iz pruned stanja. Takva poruka će biti Graft poruka. Nakon primanja Graft poruke, R2 će poslati Graft-ACK kao odgovor.
Prune Override.
Pogledajmo ovaj dijagram. R1 emitira multicast u segment s dva usmjerivača. R3 prima i emitira promet, dok R2 prima, ali nije koga da emitira promet. R2 šalje Prune poruku R1 u taj segment. R1 mora ukloniti Fa0/0 iz popisa i prestati emitirati u taj segment, ali što je s R3? R3 se također nalazi u istom segmentu, također je primio ovu Prune poruku i shvatio je svu tragediju situacije. Prije nego što R1 prestane emitirati, postavlja tajmer na 3 sekunde i prestat će emitirati nakon 3 sekunde. 3 sekunde — to je vrijeme koje R3 ima da ne izgubi svoj multicast. Stoga R3 što je brže moguće šalje Pim Join poruku za ovu grupu i R1 više ne razmišlja o prestanku emitiranja. O Join porukama više u nastavku.
Assert poruka.
Zamislimo sljedeću situaciju: u jednu mrežu emitiraju dva usmjerivača. Primaju isti tok od izvora, i oboje ga emitiraju u jednu mrežu iza sučelja e0. Stoga moraju odrediti tko će biti jedini emitator za ovu mrežu. Za to se koriste Assert poruke. Kada R2 i R3 otkriju dupliciranje multicast prometa, to jest, kada na R2 i R3 stigne multicast koji oni sami emitiraju, usmjerivači shvaćaju da nešto nije u redu. U tom slučaju, usmjerivači šalju Assert poruke koje uključuju Administrativnu udaljenost i metriku rute pomoću koje se dolazi do izvora multicast-a — 10.1.1.10. Pobjednik se određuje na sljedeći način:
- Onaj s nižom AD.
- Ako su AD isti, tada onaj s nižom metrikom.
- Ako je i ovdje jednako, pobjednik je onaj s višim IP-om u mreži u koju emitiraju ovaj multicast.
Pobjednik u ovoj glasovnoj akciji postaje Designated Router. Za odabir DR-a također se koriste Pim Hello. Na početku članka pokazana je PIM Hello poruka, gdje se može primijetiti DR polje. Pobjednik je onaj s višim IP adresama na ovoj vezi.
Korisna tablica:
MROUTE Tablica.
Nakon prvotnog pregleda rada PIM protokola, potrebno je shvatiti kako raditi s multicast tablicom usmjeravanja. U mroute tablici pohranjuje se informacija o tome koji su tokovi zatraženi od strane klijenata i koji tokovi dolaze s multicast poslužitelja.
Na primjer, prilikom primanja IGMP Membership Report ili PIM Join na nekom sučelju, u tablicu usmjeravanja dodaje se zapis tipa ( *, G ):
Ova je evidencija koja označava da je primljen zahtjev za promet s adresom 238.38.38.38. Zastavica DC označava da će multicast raditi u režimu Dense mode, a C označava da je primatelj izravno povezan s usmjerivačem, tj. usmjerivač je primio IGMP Membership Report i PIM Join.
Ako postoji zapis tipa (S,G) to znači da imamo multicast protok:
U polju S - 192.168.1.11, naveli smo IP adresu izvora multicast-a, koja će biti provjeravana prema RPF pravilu. U slučaju problema, prvo treba provjeriti unicast tablicu za putanju do izvora. U polju Incoming Interface navodi se sučelje na koje dolazi multicast. U unicast tablici usmjeravanja, putanja do izvora treba pokazivati na sučelje navedeno ovdje. U Outgoing Interface označeno je prema gdje će multicast biti preusmjeren. Ako je prazno, to znači da nije bilo zahtjeva za taj promet prema usmjerivaču. Detaljnije informacije o svim zastavicama mogu se naći. .
PIM Sparse-mode.
Strategija Sparse-mode je suprotna Dense-mode. Kada Sparse-mode primi multicast promet, šalje promet samo preko onih sučelja na kojima su bili zahtjevi za tim protokom, poput Pim Join ili IGMP Report poruka koje traže taj promet.
Slični elementi za SM i DM:
- Odnosi susjedstva se grade na isti način kao u PIM DM.
- Primjenjuje se RPF pravilo.
- Odabir DR je sličan.
- Mehanizam Prune Overrides i poruke Assert su slične.
Za kontrolu toga kome, gdje i koji multicast promet je potreban u mreži, potreban je zajednički informacijski centar. Takav centar će biti Rendezvous Point (RP). Svi koji žele neki multicast promet ili su počeli primati multicast promet od izvora, šalju ga na RP.
Kada RP primi multicast promet, poslat će ga onim usmjerivačima koji su ranije zatražili taj promet.
Zamislimo takvu topologiju, gdje je RP R3. Čim R1 primi promet od S1, inkapsulira ovaj multicast paket u unicast PIM Register poruku i šalje je na RP. Kako on zna tko je RP? U ovom slučaju, postavljen je statički, a o dinamičkom postavljanju RP razgovarat ćemo kasnije.
ip pim rp-address 3.3.3.3
RP će pregledati je li bilo informacija od nekoga tko bi želio primati ovaj promet? Pretpostavimo da nije bilo. Tada će RP poslati R1 poruku PIM Register-Stop, što znači da nikome nije potreban ovaj multicast i registracija je odbijena. R1 neće slati multicast. No, izvor hosta multicast-a će ga slati, tako da će R1, nakon primanja Register-Stop, pokrenuti tajmer Register-Suppression timer, koji traje 60 sekundi. Pet sekundi prije isteka ovog tajmera, R1 će poslati praznu Register poruku s Null-Register bit (znači bez inkapsuliranog multicast paketa) prema RP-u. RP će sa svoje strane djelovati na slijedeći način:
- Ako nije bilo primatelja, tako da ih ni nema, on će odgovoriti porukom Register-Stop.
- Ako su se primatelji pojavili, neće mu na nikakav način odgovoriti. R1, ne primivši odbijenicu na svoju registraciju u roku od 5 sekundi, obradovat će se i poslati Register poruku s inkapsuliranim multicastom prema RP-u.
Sada kada smo shvatili kako multicast dolazi do RP-a, pokušajmo odgovoriti na pitanje kako RP dostavlja promet do primatelja. Ovdje je potrebno uvesti novi pojam — root-path tree (RPT). RPT je stablo s korijenom u RP-u, koje raste prema primateljima, razgranavajući se na svakom PIM-SM usmjerivaču. RP ga stvara primajući PIM Join poruke i dodaje novu granu u stablo. I tako svaki niži usmjerivač čini. Opće pravilo glasi:
- Kada PIM-SM usmjerivač primi PIM Join poruku na nekom sučelju, osim sučelja iza kojeg se skriva RP, dodaje novu granu u stablo.
- Također, grana se dodaje kada PIM-SM usmjerivač primi IGMP Membership Report s neposredno povezane hosta.
Pretpostavimo da imamo multicast klijenta na usmjerivaču R5 na grupi 228.8.8.8. Čim R5 primi IGMP Membership Report od hosta, R5 šalje PIM Join prema RP-u, a sam dodaje sučelje koje gleda na host u stablo. Nadalje, R4 prima PIM Join od R5, dodaje sučelje Gi0/1 u stablo i šalje PIM Join prema RP-u. Na kraju, RP (R3) prima PIM Join i dodaje Gi0/0 u stablo. Tako se događa registracija primatelja multicast-a. Stablo se gradi s korijenom R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0.
Nakon toga će biti poslan PIM Join R1, a R1 će početi slati multicast promet. Važno je napomenuti da ako host zatraži promet prije nego što je multicast emitiranje započelo, RP neće poslati PIM Join i uopće ništa neće slati prema R1.
Ako tijekom slanja multimedijalnog sadržaja host odluči prekinuti primanje, čim RP primi PIM Prune na sučelju Gi0/0, odmah će poslati PIM Register-Stop izravno na R1, a zatim i PIM Prune poruku preko sučelja Gi0/1. PIM Register-Stop se šalje unicastom na adresu s koje je primljen PIM Register.
Kao što smo ranije spomenuli, čim usmjerivač pošalje PIM Join drugom, primjerice R5 na R4, na R4 se dodaje zapis:
I pokreće se tajmer, koji mora stalno slati PIM Join poruke kako bi se tajmer resetirao, inače će R4 isključiti iz outgoing liste. R5 će slati PIM Join poruke svakih 60 sekundi.
Prebacivanje najkraćeg putanjskog stabla.
Dodati ćemo sučelje između R1 i R5, vidjet ćemo kako će promet teći u ovoj topologiji.
Pretpostavimo da je promet slao i priman prema staroj shemi R1-R2-R3-R4-R5 i sada smo povezali i postavili sučelje između R1 i R5.
Prvo, unicast tablica usmjeravanja na R5 će se prestrukturirati i sada se mreža 192.168.1.0/24 može doseći putem sučelja R5 Gi0/2. Sada, kada R5 prima multicast kroz sučelje Gi0/1, shvaća da pravilo RPF nije zadovoljeno i logičnije je primati multicast na Gi0/2. Mora se isključiti iz RPT-a i izgraditi kraće stablo, koje se naziva Najkraće putanjsko stablo (SPT). Za to, kroz Gi0/2 šalje PIM Join na R1, a R1 počinje slati multicast i preko Gi0/2. Sada se R5 mora odjaviti iz RPT-a da ne bi primao dva primjerka. Za to šalje Prune poruku navodeći IP adresu izvora i ubacujući posebnu bit — RPT-bit. To znači da ne trebam slati promet, ovdje imam bolje stablo. RP također šalje PIM Prune poruke prema R1, ali ne šalje Register-Stop poruku. Još jedna posebnost: R5 će stalno slati PIM Prune na RP, jer R1 svakih minuta nastavlja slati PIM Register na RP. Dok ne bude novih zainteresiranih za taj promet, RP će mu odbijati zahtjev. R5 obavještava RP da nastavlja primati multicast preko SPT-a.
Dinamičko traženje RP.
Auto-RP.
Ova tehnologija je vlasnička od Cisco-a i ne uživa posebnu popularnost, ali i dalje je prisutna. Rad Auto-RP se sastoji od dva osnovna koraka:
1) RP šalje RP-Announce poruke na rezerviranu adresu — 224.0.1.39, objavljujući se kao RP ili za sve ili za određene grupe. Ova poruka se šalje svake minute.
2) Potreban je RP mapping agent koji će slati RP-Discovery poruke sa naglaskom na to koje grupe treba da slušaju koji RP. Upravo iz ove poruke, obični PIM ruteri će odrediti svoj RP. Mapping agent može biti ili sam RP ruter, ili neki drugi PIM ruter. RP-Discovery se šalje na adresu 224.0.1.40 sa tajmerom od jedne minute.
Pogledajmo proces detaljnije:
Postavićemo R3 kao RP:
ip pim send-rp-announce loopback 0 scope 10
R2 kao mapping agent:
ip pim send-rp-discovery loopback 0 scope 10
A na svim ostalim očekujemo RP preko Auto-RP:
ip pim autorp listener
Čim postavimo R3, on će početi slati RP-Announce:
A R2, nakon podešavanja kao mapping agent, će početi čekati RP-Announce poruke. Tek kada pronađe bar jedan RP, počeće slati RP-Discovery:
Na taj način, čim obični ruteri (PIM RP Listener) prime ovu poruku, znaće gde da traže RP.
Jedan od glavnih problema Auto-RP-a je to što da bi primali RP-Announce i RP-Discovery poruke, potrebno je slati PIM Join na adrese 224.0.1.39-40, a da bi se to učinilo, potrebno je znati gde se nalazi RP. Klasičan problem kokoške i jaja. Da bi se ovaj problem rešio, osmišljen je režim PIM Sparse-Dense-Mode. Ako ruter ne zna RP, onda radi u režimu Dense-mode, ako zna, onda u režimu Sparse-mode. Kada su na interfejsima običnih rutera podešeni PIM Sparse-mode i komanda ip pim autorp listener, ruter će raditi u režimu Dense-mode samo za multicast direktno Auto-RP protokola (224.0.1.39-40).
BootStrap Router (BSR).
Ova funkcija radi slično kao Auto-RP. Svaki RP šalje poruku mapping agentu, koji prikuplja mapiranje informacije i zatim obaveštava sve ostale rutere. Opisaćemo proces na sličan način kao Auto-RP:
1) Čim postavimo R3 kao kandidata za RP, komandom:
ip pim rp-candidate loopback 0
R3 neće raditi ništa, da bi počeo slati specijalne poruke, prvo mora pronaći mapping agent-a. Tako dolazimo do drugog koraka.
2) Postavljamo R2 kao mapping agent:
ip pim bsr-kandidat loopback 0
R2 započinje slanje PIM Bootstrap poruka, u kojima se predstavlja kao mapping agent:
Ova poruka se šalje na adresu 224.0.0.13, koju PIM protokol koristi i za druge svoje poruke. Ona se šalje u svim smjerovima, stoga nema problema s kokoši i jajeta, kao što je bilo u Auto-RP.
3) Čim RP primi poruku od BSR usmjerivača, odmah će poslati unicast poruku na adresu BSR usmjerivača:
Nakon toga, BSR, dobivši informacije o RP-u, poslat će ih multicastom na adresu 224.0.0.13, koju slušaju svi PIM usmjerivači. Zato ne postoji ekvivalentna naredba ip pim autorp listener za obične usmjerivače u BSR-u.
Anycast RP s Multicast Source Discovery Protocol (MSDP).
Auto-RP i BSR omogućuju nam raspodjelu opterećenja na RP na sljedeći način: Svaka multicast grupacija ima samo jednog aktivnog RP-a. Nije moguće raspodijeliti opterećenje za jednu multicast grupu između više RP-ova. MSDP to omogućava dodjeljujući RP usmjerivačima istu IP adresu s maskom 255.255.255.255. MSDP saznaje informacije putem jednog od metoda: statike, 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 Loopback 1 sučelju i koriste se za sve grupe. Tijekom RP-Announce oba usmjerivača govore o sebi, pozivajući se na ovu adresu. Auto-RP mapping agent, dobivši informacije, šalje RP-Discovery o RP-u s adresom 172.16.1.1/32. O mreži 172.16.1.1/32, obavještavamo usmjerivače putem IGP-a. Tako, PIM usmjerivači traže ili registriraju tokove s RP-a, koji je označen kao next-hop u ruti do mreže 172.16.1.1/32. Sam protokol MSDP je osmišljen za RP-ove, kako bi razmjenjivali poruke o informacijama o multicastu.
Razmotrimo sljedeću topologiju:
Switch6 emitira promet na adresu 238.38.38.38 i za to za sada zna samo RP-R1. Evo, Switch7 i Switch8 su zatražili ovu grupu. Usmjerivači R5 i R4 će poslati PIM Join na R1 i R3, redom. Zašto? Ruta do 13.13.13.13 kod R5 će se referirati na R1 prema IGP metri, kao i kod R4.
RP-R1 zna o toku i počne će ga emitirati prema R5, dok za R4 ništa o tome nije poznato, budući da mu R1 to ne može slati bez razloga. Zato je potreban MSDP. 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 uspostaviti sesiju između sebe i pri primanju bilo kojeg toka će obavijestiti svog susjeda RP-a o tome.
RP-R1 će odmah nakon primanja struje od Switch6 poslati unicast MSDP Source-Active poruku, koja će sadržavati informacije poput (S, G) — informacije o izvoru i odredištu multicast-a. Sada kada RP-R3 zna da takav izvor kao Switch6 postoji, prilikom primanja zahtjeva od R4 za tu struju, poslat će PIM Join prema Switch6, vodi se na osnovu tablice usmjeravanja. Stoga će R1, nakon primanja takvog PIM Joina, početi slati promet prema RP-R3.
MSDP radi putem TCP-a, RP međusobno šalju keepalive poruke za provjeru ispravnosti. Tajmer iznosi 60 sekundi.
Funkcija razdvajanja MSDP peerova u različite domene ostaje nejasna, jer se u Keepalive i SA porukama ne navodi pripadnost određenoj domeni. Također, u ovoj topologiji testirana je konfiguracija sa različitim domenskim nazivima — nije bilo razlike u radu.
Ako netko može pojasniti, rado ću pročitati u komentarima.
Izvor: habr.com
