Protokolli PIM Ă«shtĂ« njĂ« grup protokollesh pĂ«r transmetimin e multicast-it nĂ« rrjet midis ruterĂ«ve. MarrĂ«dhĂ«niet e fqinjĂ«sisĂ« ndĂ«rtohen nĂ« mĂ«nyrĂ« tĂ« ngjashme si te protokollet dinamike tĂ« rutimit. PIMv2 dĂ«rgon mesazhe Hello çdo 30 sekonda nĂ« adresĂ«n e rezervuar multicast 224.0.0.13 ( All-PIM-Routers ). Mesazhi pĂ«rmban Hold Timers â zakonisht Ă«shtĂ« i barabartĂ« me 3.5*Hello Timer, pra 105 sekonda si parazgjedhje.
PIM pĂ«rdor dy mĂ«nyra kryesore pune â Dense dhe Sparse mode. Le tĂ« fillojmĂ« me Dense mode.
Pemët e shpërndarjes të bazuara te burimi.
Regjimi Dense-mode Ă«shtĂ« i pĂ«rshtatshĂ«m kur ka njĂ« numĂ«r tĂ« madh klientĂ«sh tĂ« grupeve tĂ« ndryshme multicast. Kur ruteri merr trafik multicast, gjĂ«ja e parĂ« qĂ« bĂ«n Ă«shtĂ« ta kontrollojĂ« sipas rregullit RPF. RPF â ky rregull pĂ«rdoret pĂ«r tĂ« verifikuar burimin e multicast-it ndaj tabelĂ«s sĂ« rutimit unicast. ĂshtĂ« e nevojshme qĂ« trafiku tĂ« vijĂ« nĂ« atĂ« interfejs pas tĂ« cilit ndodhet ky host sipas tabelĂ«s sĂ« rutimit unicast. Ky mekanizĂ«m zgjidh problemin e krijimit tĂ« lakut gjatĂ« transmetimit tĂ« multicast-it.
Nga mesazhi multicast, R3 identifikon burimin e multicast-it ( Source IP ) dhe kontrollon dy flukset nga R1 dhe R2 sipas tabelës së vet të rutimit unicast. Fluksi nga ai interfejs të cilit i referohet tabela ( R1 te R3 ) do të përcillet më tej, ndërsa fluksi nga R2 do të hidhet poshtë, sepse për të arritur te burimi i multicast-it, paketat duhet të dërgohen përmes S0/1.
Po çfarë ndodh nëse keni dy rrugë ekuivalente me të njëjtën metrikë? Në këtë rast, ruteri do të zgjedhë sipas next-hop të këtyre rrugëve. Fiton ai që ka adresën IP më të lartë. Nëse duhet ndryshuar kjo sjellje, mund të përdoret ECMP. Më shumë detaje .
Pas verifikimit tĂ« rregullit RPF, ruteri dĂ«rgon paketĂ«n multicast te tĂ« gjithĂ« fqinjĂ«t e tij PIM, me pĂ«rjashtim tĂ« atij nga i cili u mor kjo paketĂ«. RuterĂ«t e tjerĂ« PIM e pĂ«rsĂ«risin kĂ«tĂ« proces. Rruga qĂ« ka pĂ«rshkuar paketa multicast nga burimi deri te marrĂ«sit pĂ«rfundimtarĂ« formon njĂ« pemĂ« qĂ« quhet â source-based distribution tree, shortest-path tree (SPT), source tree. Tre emĂ«rtime tĂ« ndryshme, zgjidhni cilindo.
Si zgjidhet problemi kur disa ruterĂ« nuk kanĂ« fare nevojĂ« pĂ«r njĂ« fluks tĂ« caktuar multicast dhe nuk kanĂ« kujt tâia dĂ«rgojnĂ«, ndĂ«rsa ruteri nĂ« nivel mĂ« tĂ« lartĂ« vazhdon tâua nisĂ«? PĂ«r kĂ«tĂ« Ă«shtĂ« krijuar mekanizmi Prune.
Mesazhi Prune.
PĂ«r shembull, R2 do tĂ« vazhdojĂ« tâi dĂ«rgojĂ« multicast R3, edhe pse R3, sipas rregullit RPF, e hedh poshtĂ« atĂ«. Pse tĂ« ngarkohet kanali? R3 dĂ«rgon njĂ« mesazh PIM Prune dhe R2, pasi ta marrĂ« kĂ«tĂ« mesazh, do ta heqĂ« ndĂ«rfaqen S0/1 nga lista ( outgoing interface list ) pĂ«r kĂ«tĂ« rrjedhĂ«, pra nga lista e ndĂ«rfaqeve ku duhet tĂ« dĂ«rgohet ky trafik.
Më poshtë është një përkufizim më formal i një mesazhi PIM Prune:
Mesazhi PIM Prune dërgohet nga një router te një router i dytë për të bërë që routeri i dytë të heqë lidhjen në të cilën është marrë Prune nga një (S,G) SPT i caktuar.
Pas marrjes së mesazhit Prune, R2 vendos një kohëmatës Prune prej 3 minutash. Pas tre minutash, ai do të nisë sërish të dërgojë trafik, derisa të marrë një tjetër mesazh Prune. Kjo vlen për PIMv1.
Në PIMv2 është shtuar kohëmatësi State Refresh ( si parazgjedhje 60 sekonda ). Sapo dërgohet mesazhi Prune nga R3, ky kohëmatës niset në R3. Me përfundimin e këtij afati, R3 do të dërgojë një mesazh State Refresh, i cili do të rivendosë kohëmatësin 3-minutësh Prune në R2 për këtë grup.
Arsyet për dërgimin e një mesazhi Prune:
- Kur paketa multicast nuk e kalon kontrollin RPF.
- Kur nuk ka klientĂ« tĂ« lidhur lokalisht qĂ« kanĂ« kĂ«rkuar grupin multicast ( IGMP Join) dhe nuk ka fqinjĂ« PIM tĂ« cilĂ«ve mund tâu dĂ«rgohet trafiku multicast ( Non-prune Interface).
Mesazhi Graft.
Le të supozojmë se R3 nuk e donte trafikun nga R2, dërgoi Prune dhe po merrte multicast nga R1. Por papritur, lidhja mes R1-R3 bie dhe R3 mbetet pa multicast. Mund të pritet 3 minuta derisa në R2 të skadojë Prune Timer. Të presësh 3 minuta është shumë, ndaj për të mos pritur, duhet të dërgohet një mesazh që e nxjerr menjëherë këtë ndërfaqe S0/1 në R2 nga gjendja pruned. Ky mesazh është mesazhi Graft. Pas marrjes së mesazhit Graft, R2 do të dërgojë si përgjigje Graft-ACK.
Prune Override.
Le ta shohim kĂ«tĂ« skemĂ«. R1 dĂ«rgon multicast nĂ« segmentin ku ka dy routerĂ«. R3 e merr dhe e shpĂ«rndan trafikun, ndĂ«rsa R2 e merr, por nuk ka kujt tâia shpĂ«rndajĂ« mĂ« tej. Ai dĂ«rgon njĂ« mesazh Prune te R1 nĂ« kĂ«tĂ« segment. R1 duhet ta heqĂ« Fa0/0 nga lista dhe tĂ« ndalojĂ« sĂ« shpĂ«rndari nĂ« kĂ«tĂ« segment, por çfarĂ« ndodh me R3? Edhe R3 ndodhet nĂ« tĂ« njĂ«jtin segment, e mori po ashtu kĂ«tĂ« mesazh Prune dhe e kuptoi seriozitetin e situatĂ«s. Para se R1 tĂ« ndalojĂ« shpĂ«rndarjen, ai vendos njĂ« timer prej 3 sekondash dhe do ta ndĂ«rpresĂ« transmetimin pas 3 sekondash. 3 sekonda janĂ« pikĂ«risht koha qĂ« ka R3 pĂ«r tĂ« mos humbur multicast-in e vet. Prandaj R3, sa mĂ« shpejt tĂ« jetĂ« e mundur, dĂ«rgon njĂ« mesazh Pim Join pĂ«r kĂ«tĂ« grup dhe R1 nuk mendon mĂ« tĂ« ndalojĂ« shpĂ«rndarjen. PĂ«r mesazhet Join mĂ« poshtĂ«.
Mesazhi Assert.
Le tĂ« imagjinojmĂ« kĂ«tĂ« situatĂ«: nĂ« tĂ« njĂ«jtin rrjet po shpĂ«rndajnĂ« njĂ«kohĂ«sisht dy routerĂ«. Ata marrin tĂ« njĂ«jtin rrjedhĂ« nga burimi dhe tĂ« dy e shpĂ«rndajnĂ« atĂ« nĂ« tĂ« njĂ«jtin rrjet pas ndĂ«rfaqes e0. Prandaj duhet tĂ« pĂ«rcaktojnĂ« se cili do tĂ« jetĂ« i vetmi shpĂ«rndarĂ«s pĂ«r kĂ«tĂ« rrjet. PĂ«r kĂ«tĂ« pĂ«rdoren mesazhet Assert. Kur R2 dhe R3 zbulojnĂ« duplikim tĂ« trafikut multicast, pra kur nĂ« R2 dhe R3 mbĂ«rrin multicast-i qĂ« ata vetĂ« po e shpĂ«rndajnĂ«, routerĂ«t kuptojnĂ« se diçka nuk Ă«shtĂ« nĂ« rregull. NĂ« kĂ«tĂ« rast, routerĂ«t dĂ«rgojnĂ« mesazhe Assert, ku pĂ«rfshihen Administrative Distance dhe metrika e rrugĂ«s pĂ«rmes sĂ« cilĂ«s arrihet burimi i multicast-it â 10.1.1.10. Fituesi pĂ«rcaktohet kĂ«shtu:
- Ai që ka AD më të ulët.
- Nëse AD janë të barabarta, fiton ai që ka metrikën më të ulët.
- Nëse edhe këtu ka barazi, fiton ai që ka IP më të lartë në rrjetin ku po e shpërndajnë këtë multicast.
Routeri që fiton këtë votim bëhet Designated Router. Për zgjedhjen e DR përdoren gjithashtu mesazhet Pim Hello. Në fillim të artikullit u paraqit mesazhi PIM Hello, ku mund të vihet re fusha DR. Fiton ai që ka adresën IP më të lartë në këtë link.
Një tabelë e dobishme:
Tabela MROUTE.
Pas shqyrtimit fillestar të funksionimit të protokollit PIM, duhet të kuptojmë se si të punojmë me tabelën e rutimit multicast. Në tabelën mroute ruhet informacioni se cilët flukse janë kërkuar nga klientët dhe cilët flukse vijnë nga serverët multicast.
Për shembull, kur merret një IGMP Membership Report ose një PIM Join në një ndërfaqe të caktuar, në tabelën e rutimit shtohet një hyrje e tipit ( *, G ):
Ky regjistrim do të thotë se është marrë një kërkesë për trafik nga adresa 238.38.38.38. Flamuri DC tregon se multicast do të funksionojë në modalitetin Dense mode, ndërsa C do të thotë se marrësi është i lidhur drejtpërdrejt me router-in, pra router-i ka marrë një IGMP Membership Report, jo një PIM Join.
Nëse ka një regjistrim të tipit (S,G), kjo do të thotë se kemi një rrjedhë multicast:
NĂ« fushĂ«n S â 192.168.1.11, Ă«shtĂ« pĂ«rcaktuar adresa IP e burimit tĂ« multicast-it; pikĂ«risht ajo do tĂ« kontrollohet nga rregulli RPF. NĂ« rast problemesh, gjĂ«ja e parĂ« qĂ« duhet kontrolluar Ă«shtĂ« tabela unicast pĂ«r rrugĂ«n drejt burimit. Fusha Incoming Interface tregon ndĂ«rfaqen nĂ« tĂ« cilĂ«n mbĂ«rrin multicast-i. NĂ« tabelĂ«n e rutimit unicast, rruga drejt burimit duhet t'i referohet ndĂ«rfaqes sĂ« treguar kĂ«tu. Te Outgoing Interface tregohet se ku do tĂ« pĂ«rcillet multicast-i. NĂ«se Ă«shtĂ« bosh, kjo do tĂ« thotĂ« se router-i nuk ka marrĂ« kĂ«rkesa pĂ«r kĂ«tĂ« trafik. Informacion mĂ« tĂ« detajuar pĂ«r tĂ« gjithĂ« flamujt mund ta gjeni .
PIM Sparse-mode.
Strategjia Sparse-mode është e kundërta e Dense-mode. Kur Sparse-mode merr trafik multicast, ai do ta dërgojë trafikun vetëm përmes atyre ndërfaqeve ku ka pasur kërkesa për këtë rrjedhë, për shembull mesazhe Pim Join ose IGMP Report me kërkesë për këtë trafik.
Elementet e ngjashme te SM dhe DM:
- Marrëdhëniet e fqinjësisë ndërtohen njësoj si në PIM DM.
- Rregulli RPF funksionon.
- Përzgjedhja e DR është e njëjtë.
- Mekanizmi Prune Overrides dhe mesazhet Assert janë të ngjashme.
Për të kontrolluar se kujt, ku dhe çfarë trafiku multicast i nevojitet në rrjet, duhet një qendër e përbashkët informacioni. Kjo qendër është Rendezvous Point ( RP ). Të gjithë ata që duan një trafik të caktuar multicast ose që kanë filluar të marrin trafik multicast nga burimi, e dërgojnë atë te RP.
Kur RP të marrë trafik multicast, ai do ta dërgojë te ata router-a që e kanë kërkuar më parë këtë trafik.
Le të imagjinojmë një topologji të tillë ku RP është R3. Sapo R1 të marrë trafik nga S1, ai do ta enkapsulojë këtë paketë multicast në një mesazh unicast PIM Register dhe do ta dërgojë te RP. Si e di ai se kush është RP? Në këtë rast, ai është konfiguruar statikisht, ndërsa për konfigurimin dinamik të RP do të flasim më vonë.
ip pim rp-address 3.3.3.3
RP do të kontrollojë nëse ka pasur informacion nga ndokush që dëshiron ta marrë këtë trafik. Le të supozojmë se nuk ka pasur. Atëherë RP do t'i dërgojë R1 mesazhin PIM Register-Stop, që do të thotë se askujt nuk i nevojitet ky multicast dhe regjistrimi refuzohet. R1 nuk do të dërgojë multicast. Por hosti-burim i multicast-it do të vazhdojë ta dërgojë atë, prandaj pasi të marrë Register-Stop, R1 do të nisë timer-in Register-Suppression, me vlerë 60 sekonda. 5 sekonda para skadimit të këtij timer-i, R1 do të dërgojë një mesazh bosh Register me bit-in Null-Register (pra, pa paketë multicast të inkapsuluar) drejt RP. Nga ana e vet, RP do të veprojë kështu:
- Nëse marrësit ende nuk ekzistojnë, ai do të përgjigjet me mesazhin Register-Stop.
- Nëse janë shfaqur marrës, ai nuk do t'i përgjigjet fare. Nëse R1 nuk merr refuzim për regjistrimin e tij brenda 5 sekondash, do ta konsiderojë këtë si konfirmim dhe do të dërgojë te RP një mesazh Register me multicast të inkapsuluar.
Tani qĂ« e kuptuam si arrin multicast te RP, le tĂ« pĂ«rpiqemi t'i pĂ«rgjigjemi pyetjes se si RP ua çon trafikun marrĂ«sve. KĂ«tu duhet tĂ« prezantojmĂ« njĂ« koncept tĂ« ri â root-path tree (RPT). RPT Ă«shtĂ« njĂ« pemĂ« me rrĂ«njĂ« nĂ« RP, qĂ« zgjatet drejt marrĂ«sve dhe degĂ«zohet nĂ« çdo router PIM-SM. RP e krijon atĂ« duke marrĂ« mesazhe PIM Join dhe duke shtuar njĂ« degĂ« tĂ« re nĂ« pemĂ«. TĂ« njĂ«jtĂ«n gjĂ« bĂ«n edhe çdo router i nivelit mĂ« tĂ« ulĂ«t. Rregulli i pĂ«rgjithshĂ«m duket kĂ«shtu:
- Kur një router PIM-SM merr një mesazh PIM Join në cilindo interfejs, me përjashtim të interfejsit pas të cilit ndodhet RP, ai shton një degë të re në pemë.
- Gjithashtu, një degë shtohet kur një router PIM-SM merr një IGMP Membership Report nga një host i lidhur drejtpërdrejt.
Le tĂ« supozojmĂ« se kemi njĂ« klient multicast nĂ« routerin R5 pĂ«r grupin 228.8.8.8. Sapo R5 tĂ« marrĂ« njĂ« IGMP Membership Report nga hosti, R5 dĂ«rgon njĂ« PIM Join nĂ« drejtim tĂ« RP dhe njĂ«kohĂ«sisht shton nĂ« pemĂ« interfejsin qĂ« sheh nga hosti. MĂ« pas, R4 merr PIM Join nga R5, shton nĂ« pemĂ« interfejsin Gi0/1 dhe dĂ«rgon PIM Join nĂ« drejtim tĂ« RP. MĂ« nĂ« fund, RP (R3) merr PIM Join dhe shton Gi0/0 nĂ« pemĂ«. KĂ«shtu kryhet regjistrimi i marrĂ«sit multicast. Formohet njĂ« pemĂ« me rrĂ«njĂ« R3-Gi0/0 â R4-Gi0/1 â R5-Gi0/0.
Pas kĂ«saj, do tĂ« dĂ«rgohet njĂ« PIM Join te R1 dhe R1 do tĂ« nisĂ« tĂ« dĂ«rgojĂ« trafikun multicast. ĂshtĂ« e rĂ«ndĂ«sishme tĂ« theksohet se nĂ«se hosti ka kĂ«rkuar trafik para se tĂ« fillojĂ« transmetimi multicast, RP nuk do tĂ« dĂ«rgojĂ« PIM Join dhe nĂ« pĂ«rgjithĂ«si nuk do tĂ« dĂ«rgojĂ« asgjĂ« nĂ« drejtim tĂ« R1.
Nëse gjatë transmetimit multicast hosti nuk dëshiron më ta marrë atë, sapo RP të marrë PIM Prune në interfejsin Gi0/0, ai menjëherë do të dërgojë PIM Register-Stop direkt te R1 dhe më pas edhe një mesazh PIM Prune përmes interfejsit Gi0/1. PIM Register-Stop dërgohet me unicast në atë adresë nga e cila është marrë PIM Register.
Siç e thamë më parë, sapo një router i dërgon PIM Join një tjetri, për shembull R5 te R4, në R4 shtohet regjistrimi i mëposhtëm:
Dhe niset një timer; që ky timer të mos skadojë, R5 duhet të dërgojë vazhdimisht mesazhe PIM Join, përndryshe R4 do ta heqë nga outgoing list. R5 do të dërgojë mesazhe PIM Join çdo 60 sekonda.
Kalimi në Shortest-Path Tree.
Do të shtojmë një interfejs midis R1 dhe R5 dhe do të shohim si do të rrjedhë trafiku në këtë topologji.
Le të supozojmë se trafiku dërgohej dhe merrej sipas skemës së vjetër R1-R2-R3-R4-R5, dhe më pas ne lidhëm dhe konfiguruam interfejsin midis R1 dhe R5.
SĂ« pari, nĂ« R5 do tĂ« rindĂ«rtohet tabela e rutimit unicast dhe tani rrjeti 192.168.1.0/24 arrihet pĂ«rmes interfejsit Gi0/2 tĂ« R5. Tani, kur R5 merr multicast nĂ« interfejsin Gi0/1, ai kupton se rregulli RPF nuk pĂ«rmbushet dhe se multicast do tĂ« ishte mĂ« logjike tĂ« merrej nĂ« Gi0/2. Ai duhet tĂ« shkĂ«putet nga RPT dhe tĂ« ndĂ«rtojĂ« njĂ« pemĂ« mĂ« tĂ« shkurtĂ«r, e cila quhet Shortest-Path Tree ( SPT ). PĂ«r kĂ«tĂ«, pĂ«rmes Gi0/2 ai dĂ«rgon PIM Join te R1 dhe R1 nis tĂ« dĂ«rgojĂ« multicast edhe pĂ«rmes Gi0/2. Tani R5 duhet tĂ« çabonohet nga RPT, qĂ« tĂ« mos marrĂ« dy kopje. PĂ«r kĂ«tĂ« ai dĂ«rgon njĂ« mesazh Prune duke specifikuar adresĂ«n IP tĂ« burimit dhe duke vendosur njĂ« bit tĂ« veçantĂ« â RPT-bit. Kjo do tĂ« thotĂ«: mos mĂ« dĂ«rgo trafik kĂ«tu, unĂ« kam njĂ« pemĂ« mĂ« tĂ« mirĂ«. RP gjithashtu dĂ«rgon mesazhe PIM Prune nĂ« drejtim tĂ« R1, por nuk dĂ«rgon mesazh Register-Stop. NjĂ« veçori tjetĂ«r Ă«shtĂ« se R5 tani do tĂ« dĂ«rgojĂ« vazhdimisht PIM Prune te RP, sepse R1 vazhdon tâi dĂ«rgojĂ« RP-sĂ« PIM Register çdo minutĂ«. RP, pĂ«r sa kohĂ« nuk ka kĂ«rkues tĂ« rinj pĂ«r kĂ«tĂ« trafik, do tâi pĂ«rgjigjet me refuzim. R5 e njofton RP-nĂ« se vazhdon ta marrĂ« multicast pĂ«rmes SPT.
Zbulimi dinamik i RP.
Auto-RP.
Kjo teknologji është pronësore e Cisco-s dhe nuk gëzon ndonjë popullaritet të veçantë, por ende përdoret. Funksionimi i Auto-RP përbëhet nga dy faza kryesore:
1) RP dërgon mesazhe RP-Announce në adresën e rezervuar 224.0.1.39, duke deklaruar veten si RP ose për të gjitha grupet, ose për grupe të caktuara. Ky mesazh dërgohet çdo minutë.
2) Kërkohet një RP mapping agent, i cili do të dërgojë mesazhe RP-Discovery duke treguar se për cilat grupe duhet përdorur cili RP. Pikërisht nga ky mesazh, routerat e zakonshëm PIM do të përcaktojnë RP-në për veten e tyre. Mapping Agent mund të jetë si vetë routeri RP, ashtu edhe ndonjë router i veçantë PIM. RP-Discovery dërgohet në adresën 224.0.1.40 me një interval prej një minute.
Le ta shohim procesin më në detaje:
Le të konfigurojmë R3 si RP:
ip pim send-rp-announce loopback 0 scope 10
R2 si mapping agent:
ip pim send-rp-discovery loopback 0 scope 10
Ndërsa në të gjithë të tjerët do të presim RP përmes Auto-RP:
ip pim autorp listener
Sapo të konfigurojmë R3, ai do të fillojë të dërgojë RP-Announce:
Ndërsa R2, pas konfigurimit si mapping agent, do të fillojë të presë mesazhet RP-Announce. Vetëm kur të gjejë të paktën një RP, do të fillojë të dërgojë RP-Discovery:
Kështu, sapo routerat e zakonshëm ( PIM RP Listener ) ta marrin këtë mesazh, ata do të dinë ku ta kërkojnë RP-në.
Një nga problemet kryesore të Auto-RP është se, për të marrë mesazhet RP-Announce dhe RP-Discovery, duhet të dërgohet PIM Join në adresat 224.0.1.39-40, ndërsa për ta dërguar këtë kërkesë, duhet ditur se ku ndodhet RP. Problemi klasik i vezës dhe pulës. Për ta zgjidhur këtë problem, u krijua modaliteti PIM Sparse-Dense-Mode. Nëse routeri nuk e njeh RP-në, ai punon në modalitetin Dense-mode; nëse e njeh, punon në modalitetin Sparse-mode. Kur në ndërfaqet e routerave të zakonshëm konfigurohen PIM Sparse-mode dhe komanda ip pim autorp listener, routeri do të punojë në modalitetin Dense-mode vetëm për multicast-in e vetë protokollit Auto-RP ( 224.0.1.39-40 ).
BootStrap Router (BSR).
Ky funksion punon nĂ« mĂ«nyrĂ« tĂ« ngjashme me Auto-RP. Ădo RP i dĂ«rgon njĂ« mesazh mapping agent-it, i cili mbledh informacionin e mapimit dhe mĂ« pas ua shpĂ«rndan tĂ« gjithĂ« routerave tĂ« tjerĂ«. Le ta pĂ«rshkruajmĂ« procesin njĂ«soj si te Auto-RP:
1) Sapo të konfigurojmë R3 si kandidat për RP, me komandën:
ip pim rp-candidate loopback 0
R3 nuk do të bëjë asgjë, sepse që të fillojë të dërgojë mesazhe të posaçme, fillimisht duhet të gjejë mapping agent-in. Prandaj kalojmë te hapi i dytë.
2) Konfigurojmë R2 si mapping agent:
ip pim bsr-candidate loopback 0
R2 fillon të dërgojë mesazhe PIM Bootstrap, ku e deklaron veten si mapping agent:
Ky mesazh dërgohet në adresën 224.0.0.13, të cilën protokolli PIM e përdor edhe për mesazhe të tjera. Ai i dërgon në të gjitha drejtimet, prandaj këtu nuk ka problemin e "pulës dhe vezës", siç ndodhte me Auto-RP.
3) Sapo RP të marrë mesazhin nga ruteri BSR, ai menjëherë dërgon një mesazh unicast në adresën e ruterit BSR:
Më pas, pasi BSR të marrë informacionin për RP, ai do ta shpërndajë atë me multicast në adresën 224.0.0.13, të cilën e dëgjojnë të gjithë ruterët PIM. Prandaj, një analog i komandës ip pim autorp listener nuk ekziston për ruterët e zakonshëm në BSR.
Anycast RP me Multicast Source Discovery Protocol (MSDP).
Auto-RP dhe BSR na lejojnë të shpërndajmë ngarkesën në RP në këtë mënyrë: çdo grup multicast ka vetëm një RP aktiv. Nuk është e mundur të bëhet shpërndarja e ngarkesës për një grup multicast të vetëm midis disa RP-ve. MSDP e realizon këtë duke u caktuar RP-ve të njëjtën adresë IP me maskën 255.255.255.255. MSDP e merr këtë informacion përmes një prej metodave: statikisht, me Auto-RP ose me BSR.
Në figurë kemi një konfigurim Auto-RP me MSDP. Të dy RP-të janë konfiguruar me adresën IP 172.16.1.1/32 në ndërfaqen Loopback 1 dhe ajo përdoret për të gjitha grupet. Gjatë RP-Announce, të dy ruterët njoftojnë për veten duke iu referuar kësaj adrese. Mapping agent i Auto-RP, pasi merr informacionin, dërgon RP-Discovery për RP me adresën 172.16.1.1/32. Për rrjetin 172.16.1.1/32, ne i njoftojmë ruterët përmes IGP-së. Si rezultat, ruterët PIM kërkojnë ose regjistrojnë rrjedhat te ai RP që shfaqet si next-hop në rrugën drejt rrjetit 172.16.1.1/32. Vetë protokolli MSDP shërben për RP-të, që të shkëmbejnë mesazhe me informacion për multicast-in.
Le të shqyrtojmë këtë topologji:
Switch6 dërgon trafik në adresën 238.38.38.38 dhe për të aktualisht di vetëm RP-R1. Ndërkohë, Switch7 dhe Switch8 e kanë kërkuar këtë grup. Ruterët R5 dhe R4 do të dërgojnë PIM Join te R1 dhe R3, përkatësisht. Pse? Rruga drejt 13.13.13.13 te R5 do të tregojë te R1 sipas metrikës IGP, po ashtu edhe te R4.
RP-R1 e njeh rrjedhën dhe do të fillojë ta transmetojë atë në drejtim të R5, ndërsa R4 nuk di asgjë për të, sepse R1 nuk do ta dërgojë pa arsye. Prandaj nevojitet MSDP. E konfigurojmë atë në R1 dhe R5:
ip msdp peer 3.3.3.3 connect-source Loopback1 në R1
ip msdp peer 1.1.1.1 connect-source Loopback3 në R3
Ata do të krijojnë një sesion mes njëri-tjetrit dhe, kur të marrin çfarëdo rrjedhe, do ta njoftojnë për të fqinjit të tyre RP.
RP-R1, sapo tĂ« marrĂ« stream-in nga Switch6, menjĂ«herĂ« do tĂ« dĂ«rgojĂ« me unicast njĂ« mesazh MSDP Source-Active, i cili do tĂ« pĂ«rmbajĂ« informacion tĂ« tipit (S, G) â tĂ« dhĂ«na pĂ«r burimin dhe destinacionin e multicast-it. Tani, kur RP-R3 ta dijĂ« se ekziston njĂ« burim i tillĂ« si Switch6, me tĂ« marrĂ« kĂ«rkesĂ«n nga R4 pĂ«r kĂ«tĂ« stream, do tĂ« dĂ«rgojĂ« njĂ« PIM Join nĂ« drejtim tĂ« Switch6, duke u bazuar nĂ« tabelĂ«n e rutimit. Si rrjedhojĂ«, R1, pasi tĂ« marrĂ« njĂ« PIM Join tĂ« tillĂ«, do tĂ« nisĂ« tĂ« dĂ«rgojĂ« trafikun nĂ« drejtim tĂ« RP-R3.
MSDP punon mbi TCP; RP-të i dërgojnë njëri-tjetrit mesazhe keepalive për të kontrolluar disponueshmërinë. Timer-i është 60 sekonda.
Mbetet e paqartĂ« funksioni i ndarjes sĂ« peer-ve MSDP nĂ« domene tĂ« ndryshme, pasi nĂ« mesazhet Keepalive dhe SA nuk tregohet pĂ«rkatĂ«sia ndaj ndonjĂ« domeni. Gjithashtu, nĂ« kĂ«tĂ« topologji u testua edhe konfigurimi me specifikimin e domeneve tĂ« ndryshme â nuk pati asnjĂ« ndryshim nĂ« funksionim.
Nëse dikush mund të sjellë më shumë qartësi, do ta lexoj me kënaqësi në komente.
Burimi: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
Finnish
French
Hungarian
Latvian
Lithuanian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish