PIM samskiptareglur eru sett af samskiptareglum til að senda fjölvarpssendingar í neti á milli beina. Hverfissambönd eru byggð á sama hátt og þegar um er að ræða kraftmikla leiðarsamskiptareglur. PIMv2 sendir Halló skilaboð á 30 sekúndna fresti á frátekið fjölvarpsnetfang 224.0.0.13 (All-PIM-Routers). Skilaboðin innihalda Hold Timer - venjulega jafnt og 3.5*Hello Timer, það er sjálfgefið 105 sekúndur.
PIM notar tvær aðalrekstrarstillingar - Þétt og dreifður háttur. Byrjum á Dense mode.
Upprunamiðuð dreifingartré.
Mælt er með því að nota þétta stillingu ef um er að ræða mikinn fjölda viðskiptavina í mismunandi fjölvarpshópum. Þegar beini tekur á móti fjölvarpsumferð er það fyrsta sem hún gerir að athuga það fyrir RPF regluna. RPF - þessi regla er notuð til að athuga uppruna fjölvarps með einvarpsleiðartöflu. Nauðsynlegt er að umferðin komi að viðmótinu sem þessi gestgjafi er falinn á bak við samkvæmt útgáfu unicast leiðartöflunnar. Þessi vélbúnaður leysir vandamálið með lykkju sem verður við fjölvarpssendingu.
R3 mun þekkja fjölvarpsgjafann (uppspretta IP) úr fjölvarpsskilaboðunum og athuga flæðið tvö frá R1 og R2 með því að nota einvarpstöfluna. Straumurinn frá viðmótinu sem taflan bendir á (R1 til R3) verður sendur áfram og straumurinn frá R2 verður sleppt, þar sem til að komast að fjölvarpsgjafanum þarftu að senda pakka í gegnum S0/1.
Spurningin er, hvað gerist ef þú ert með tvær jafngildar leiðir með sömu mæligildi? Í þessu tilviki mun leiðin velja næsta hopp úr þessum leiðum. Sá sem hefur hærri IP tölu vinnur. Ef þú þarft að breyta þessari hegðun geturðu notað ECMP. Nánari upplýsingar .
Eftir að hafa athugað RPF regluna sendir beininn fjölvarpspakka til allra PIM nágranna sinna, nema þess sem pakkinn var móttekinn frá. Aðrir PIM beinir endurtaka þetta ferli. Slóðin sem fjölvarpspakki hefur tekið frá upprunanum til lokaviðtakenda myndar tré sem kallast frumtengd dreifingartré, stystu leiðartré (SPT), upprunatré. Þrjú mismunandi nöfn, veldu hvaða sem er.
Hvernig á að leysa vandamálið að sumir beinir gáfust ekki upp á einhverju multicast straumi og það er enginn til að senda hann til, en upstream routerinn sendir hann til hans. Prune vélbúnaðurinn var fundinn upp fyrir þetta.
Prune skilaboð.
Til dæmis mun R2 halda áfram að senda fjölvarp til R3, þó að R3, samkvæmt RPF reglunni, sleppir því. Af hverju að hlaða rásinni? R3 sendir PIM Prune Skilaboð og R2, við móttöku þessara skilaboða, mun fjarlægja viðmót S0/1 af útgefandi viðmótalistanum fyrir þetta flæði, lista yfir viðmót sem þessi umferð ætti að senda frá.
Eftirfarandi er formlegri skilgreining á PIM Prune skilaboðum:
PIM Prune skilaboðin eru send af einum beini til annars beini til að valda því að annar beini fjarlægir hlekkinn sem prune er móttekin á frá tilteknu (S,G) SPT.
Eftir að hafa fengið prune skilaboðin stillir R2 prune tímamælirinn á 3 mínútur. Eftir þrjár mínútur mun það byrja að senda umferð aftur þar til það fær önnur Prune skilaboð. Þetta er í PIMv1.
Og í PIMv2 hefur State Refresh teljara verið bætt við (60 sekúndur sjálfgefið). Um leið og Prune skilaboð hafa verið send frá R3 er þessi teljari ræstur á R3. Þegar þessi tímamælir rennur út mun R3 senda State Refresh skilaboð, sem mun endurstilla 3-mínútna prune Timer á R2 fyrir þennan hóp.
Ástæður fyrir því að senda Prune skilaboð:
- Þegar multicast pakki mistekst RPF athugun.
- Þegar það eru engir staðbundnir viðskiptavinir sem hafa beðið um fjölvarpshóp (IGMP Join) og það eru engir PIM-nágrannar sem hægt er að senda fjölvarpsumferð til (Non-prune Interface).
Graft Skilaboð.
Ímyndum okkur að R3 hafi ekki viljað umferð frá R2, sent Prune og fengið multicast frá R1. En skyndilega féll rásin á milli R1-R3 og R3 varð eftir án fjölvarps. Þú getur beðið í 3 mínútur þar til prune Timer á R2 rennur út. 3 mínútur eru löng bið, til þess að bíða ekki þarftu að senda skilaboð sem koma þessu S0/1 viðmóti samstundis í R2 úr klipptu ástandi. Þessi skilaboð verða Graft skilaboð. Eftir að hafa fengið Graft skilaboðin mun R2 svara með Graft-ACK.
Hneka prune.
Við skulum skoða þessa skýringarmynd. R1 sendir út fjölvarp til hluta með tveimur beinum. R3 tekur á móti og sendir út umferð, R2 tekur á móti, en hefur engan til að senda út umferð til. Það sendir Prune skilaboð til R1 í þessum hluta. R1 ætti að fjarlægja Fa0/0 af listanum og hætta að senda út í þessum þætti, en hvað verður um R3? Og R3 er í sama flokki, fékk líka þessi skilaboð frá Prune og skildi hörmungar ástandsins. Áður en R1 hættir að senda út, stillir hann tímamæli á 3 sekúndur og hættir að senda út eftir 3 sekúndur. 3 sekúndur - þetta er nákvæmlega hversu mikinn tíma R3 hefur til að missa ekki fjölvarpið sitt. Því sendir R3 Pim Join skilaboð fyrir þennan hóp eins fljótt og auðið er og R1 dettur ekki lengur í hug að hætta útsendingum. Um Join skilaboð hér að neðan.
Fullyrða skilaboð.
Við skulum ímynda okkur þessa stöðu: tveir beinir senda út á eitt net í einu. Þeir fá sama strauminn frá upprunanum og senda hann báðir á sama netið á bak við tengi e0. Þess vegna þurfa þeir að ákveða hver verður eini útvarpsaðilinn fyrir þetta net. Fullyrðingarskilaboð eru notuð til þess. Þegar R2 og R3 greina tvítekningu á fjölvarpsumferð, það er að segja R2 og R3 fá fjölvarp sem þeir senda sjálfir út, skilja beinarnir að hér er eitthvað að. Í þessu tilviki senda beinir Assert skilaboð, sem innihalda stjórnunarfjarlægð og leiðarmælinguna sem fjölvarpsuppspretta er náð með - 10.1.1.10. Sigurvegarinn er ákveðinn sem hér segir:
- Sá með lægri AD.
- Ef AD eru jöfn, hver hefur þá lægri mæligildi.
- Ef það er jafnræði hér, þá er sá sem hefur hærri IP-tölu á netinu sem þeir senda þessa fjölvarpssendingu út á.
Sigurvegarinn í þessari atkvæðagreiðslu verður tilnefndur beini. Pim Hello er einnig notað til að velja DR. Í upphafi greinarinnar var PIM Hello skilaboðin sýnd, þar má sjá DR reitinn. Sá með hæstu IP töluna á þessum hlekk vinnur.
Gagnlegt merki:
MROUTE tafla.
Eftir fyrstu skoðun á því hvernig PIM samskiptareglur virka, þurfum við að skilja hvernig á að vinna með multicast leiðartöflu. mroute taflan geymir upplýsingar um hvaða strauma var beðið um frá viðskiptavinum og hvaða straumar streyma frá fjölvarpsþjónum.
Til dæmis, þegar IGMP aðildarskýrsla eða PIM Join er móttekin á einhverju viðmóti, er skrá af gerðinni ( *, G ) bætt við leiðartöfluna:
Þessi færsla þýðir að umferðarbeiðni barst með heimilisfanginu 238.38.38.38. DC fáninn þýðir að multicast mun starfa í Dense mode og C þýðir að viðtakandinn er beintengdur við beininn, það er að routerinn fékk IGMP aðildarskýrsluna og PIM Join.
Ef það er skrá af gerðinni (S,G) þýðir það að við höfum fjölvarpsstraum:
Í S reitnum - 192.168.1.11 höfum við skráð IP tölu fjölvarpsgjafans, það er þetta sem verður athugað af RPF reglunni. Ef það eru vandamál, það fyrsta sem þú þarft að gera er að athuga unicast töfluna fyrir leiðina að upprunanum. Í reitnum Innkomandi viðmót gefur til kynna viðmótið sem fjölvarpið er tekið á móti. Í unicast leiðartöflu verður leiðin að upprunanum að vísa til viðmótsins sem tilgreint er hér. Útsendingarviðmótið tilgreinir hvert fjölvarpinu verður vísað. Ef það er tómt, þá hefur beininn ekki fengið neinar beiðnir um þessa umferð. Nánari upplýsingar um alla fána má finna .
PIM Sparse-hamur.
Stefna Sparse-ham er andstæða Dense-ham. Þegar Sparse-mode tekur á móti multicast umferð mun það aðeins senda umferð í gegnum þau viðmót þar sem beiðnir voru um þetta flæði, til dæmis Pim Join eða IGMP Report skilaboð sem biðja um þessa umferð.
Svipaðir þættir fyrir SM og DM:
- Hverfasambönd eru byggð á sama hátt og í PIM DM.
- RPF reglan virkar.
- Úrval DR er svipað.
- Fyrirkomulagið á Prune Overrides og Assert skilaboðunum er svipað.
Til að stýra því hver, hvar og hvers konar fjölvarps umferð er þörf á netinu þarf sameiginlega upplýsingamiðstöð. Miðstöð okkar verður Rendezvous Point (RP). Sá sem vill einhvers konar multicast umferð eða einhver byrjaði að fá multicast umferð frá upprunanum, þá sendir hann hana til RP.
Þegar RP fær multicast umferð mun það senda það til þeirra beina sem áður bað um þessa umferð.
Ímyndum okkur staðfræði þar sem RP er R3. Um leið og R1 tekur á móti umferð frá S1, hylur hann þennan fjölvarpspakka inn í einútvarpað PIM Register skilaboð og sendir það til RP. Hvernig veit hann hver RP er? Í þessu tilviki er það stillt á kyrrstöðu og við munum tala um kraftmikla RP stillingu síðar.
ip pim rp-vistfang 3.3.3.3
RP mun skoða - voru upplýsingar frá einhverjum sem vildi fá þessa umferð? Gerum ráð fyrir að svo hafi ekki verið. Þá mun RP senda R1 PIM Register-Stop skilaboð, sem þýðir að enginn þarf þessa fjölvarpssendingu, skráningu er hafnað. R1 mun ekki senda fjölvarp. En fjölvarpsgjafinn mun senda það, þannig að R1, eftir að hafa fengið Register-Stop, mun ræsa Register-Suppression tímamæli sem jafngildir 60 sekúndum. 5 sekúndum áður en þessi tímamælir rennur út mun R1 senda tóm skráningarskilaboð með Null-Register bita (þ.e. án hjúpaðs fjölvarpspakka) í átt að RP. RP mun aftur á móti haga sér svona:
- Ef það voru engir viðtakendur, þá mun það svara með Register-Stop skilaboðum.
- Ef viðtakendur koma fram mun hann ekki bregðast við því á nokkurn hátt. R1, sem hefur ekki fengið synjun um skráningu innan 5 sekúndna, mun vera ánægður og senda Register skilaboð með hjúpuðu fjölvarpi til RP.
Við virðumst hafa fundið út hvernig multicast nær til RP, nú skulum við reyna að svara spurningunni um hvernig RP skilar umferð til viðtakenda. Hér er nauðsynlegt að kynna nýtt hugtak - root-path tree (RPT). RPT er tré með rætur í RP, vex í átt að viðtakendum, greinar á hverjum PIM-SM beini. RP býr það til með því að fá PIM Join skilaboð og bætir nýrri grein við tréð. Og svo gerir það hver einasti beini. Almenna reglan lítur svona út:
- Þegar PIM-SM beini fær PIM Join skilaboð á hvaða viðmóti sem er annað en viðmótið sem RP er falið, bætir það nýrri grein við tréð.
- Útibúi er einnig bætt við þegar PIM-SM beininn fær IGMP aðildarskýrslu frá beintengdum gestgjafa.
Ímyndum okkur að við séum með multicast biðlara á R5 beininum fyrir hóp 228.8.8.8. Um leið og R5 fær IGMP aðildarskýrsluna frá gestgjafanum, sendir R5 PIM Join í átt að RP, og bætir sjálfur viðmóti við tréð sem horfir á gestgjafann. Næst tekur R4 á móti PIM Join frá R5, bætir viðmóti Gi0/1 við tréð og sendir PIM Join í átt að RP. Að lokum fær RP ( R3 ) PIM Join og bætir Gi0/0 við tréð. Þannig er fjölvarpsmóttakandinn skráður. Við erum að byggja tré með rótinni R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0.
Eftir þetta verður PIM Join sendur til R1 og R1 mun byrja að senda fjölvarps umferð. Það er mikilvægt að hafa í huga að ef gestgjafinn óskaði eftir umferð áður en fjölvarpsútsendingin hófst, þá mun RP ekki senda PIM Join og mun alls ekki senda neitt til R1.
Ef skyndilega á meðan fjölvarp er sent hættir gestgjafinn að vilja taka á móti því, um leið og RP fær PIM Prune á Gi0/0 viðmótið, mun það strax senda PIM Register-Stop beint til R1, og síðan PIM Prune skilaboð í gegnum Gi0/1 viðmótið. PIM Register-stop er sent í gegnum unicast á heimilisfangið sem PIM Registerið kom frá.
Eins og við sögðum áðan, um leið og leið sendir PIM Join til annars, til dæmis R5 til R4, þá er skrá bætt við R4:
Og tímamælir er ræstur sem R5 verður stöðugt að endurstilla þennan tímamæli PIM Join skilaboð stöðugt, annars verður R4 útilokaður frá útsendingarlistanum. R5 mun senda hver 60 PIM Join skilaboð.
Stytta leið tré skipti.
Við munum bæta við tengi milli R1 og R5 og sjá hvernig umferð flæðir með þessari staðfræði.
Gerum ráð fyrir að umferð hafi verið send og móttekin samkvæmt gamla kerfinu R1-R2-R3-R4-R5, og hér tengdum við og stilltum viðmótið á milli R1 og R5.
Fyrst af öllu verðum við að endurbyggja unicast leiðartöfluna á R5 og nú er netið 192.168.1.0/24 náð í gegnum R5 Gi0/2 tengið. Nú skilur R5, sem tekur á móti fjölvarpi á viðmóti Gi0/1, að RPF reglan er ekki uppfyllt og það væri rökréttara að taka á móti fjölvarpi á Gi0/2. Það ætti að aftengjast RPT og byggja styttra tré sem kallast Shortest-Path Tree (SPT). Til að gera þetta sendir hann PIM Join til R0 í gegnum Gi2/1 og R1 byrjar að senda fjölvarp líka í gegnum Gi0/2. Nú þarf R5 að segja upp áskrift að RPT til að fá ekki tvö eintök. Til að gera þetta sendir hann Prune skilaboð sem gefur til kynna uppruna IP tölu og setur inn sérstakan bita - RPT-bita. Þetta þýðir að þú þarft ekki að senda mér umferð, ég er með betra tré hér. RP sendir einnig PIM Prune skilaboð til R1, en sendir ekki Register-Stop skilaboð. Annar eiginleiki: R5 mun nú stöðugt senda PIM Prune til RP, þar sem R1 heldur áfram að senda PIM Register til RP á hverri mínútu. Þangað til það er ekkert nýtt fólk sem vill þessa umferð mun RP neita henni. R5 tilkynnir RP að það haldi áfram að taka á móti fjölvarpi í gegnum SPT.
Dynamic RP leit.
Auto-RP.
Þessi tækni er í eigu Cisco og er ekki sérstaklega vinsæl, en er enn á lífi. Sjálfvirk RP aðgerð samanstendur af tveimur meginþrepum:
1) RP sendir RP-Announce skilaboð á frátekið netfang - 224.0.1.39, lýsir sig RP annað hvort fyrir alla eða fyrir tiltekna hópa. Þessi skilaboð eru send á hverri mínútu.
2) Krafist er RP kortlagningarfulltrúa sem mun senda RP-Discovery skilaboð sem gefa til kynna fyrir hvaða hópa ætti að hlusta á RP. Það er út frá þessum skilaboðum sem venjulegir PIM beinir munu ákvarða RP fyrir sig. Kortamiðillinn getur annað hvort verið RP beininn sjálfur eða aðskilinn PIM bein. RP-Discovery er sent á netfangið 224.0.1.40 með tímamæli upp á eina mínútu.
Við skulum skoða ferlið nánar:
Við skulum stilla R3 sem RP:
ip pim send-rp-announce loopback 0 scope 10
R2 sem kortlagningarmiðill:
ip pim send-rp-discovery loopback 0 scope 10
Og á öllum öðrum munum við búast við RP í gegnum Auto-RP:
ip pim autorp hlustandi
Þegar við stillum R3 mun það byrja að senda RP-Announce:
Og R2, eftir að hafa sett upp kortamiðilinn, mun byrja að bíða eftir RP-Announce skilaboðunum. Aðeins þegar það finnur að minnsta kosti eitt RP mun það byrja að senda RP-Discovery:
Þannig, um leið og venjulegir beinar (PIM RP Listener) fá þessi skilaboð, munu þeir vita hvar á að leita að RP.
Eitt helsta vandamálið við Auto-RP er að til að fá RP-Announce og RP-Discovery skilaboð þarf að senda PIM Join á netföngin 224.0.1.39-40 og til að senda þarf að vita hvert RP er staðsett. Klassískt kjúklinga- og eggvandamál. Til að leysa þetta vandamál var PIM Sparse-Dense-Mode fundinn upp. Ef leiðin þekkir ekki RP, þá starfar hann í þéttum ham; ef hann gerir það, þá í sparse-ham. Þegar PIM Sparse-mode og ip pim autorp listener skipunin eru stillt á viðmót venjulegra beina, mun beininn starfa í Dense-ham aðeins fyrir fjölvarp beint frá Auto-RP samskiptareglunum (224.0.1.39-40).
BootStrap leið (BSR).
Þessi aðgerð virkar svipað og Auto-RP. Hver RP sendir skilaboð til kortlagningaraðilans, sem safnar kortaupplýsingum og segir síðan öllum öðrum beinum frá. Við skulum lýsa ferlinu á svipaðan hátt og Auto-RP:
1) Þegar við stillum R3 sem frambjóðanda til að vera RP, með skipuninni:
ip pim rp-candidate loopback 0
Þá gerir R3 ekki neitt; til að geta byrjað að senda sérstök skilaboð þarf hann fyrst að finna kortagerðarmann. Þannig förum við yfir í annað skrefið.
2) Stilltu R2 sem kortlagningarmiðil:
ip pim bsr-kandidat loopback 0
R2 byrjar að senda PIM Bootstrap skilaboð, þar sem hann gefur til kynna sig sem kortlagningaraðila:
Þessi skilaboð eru send á netfangið 224.0.013, sem PIM samskiptareglan notar einnig fyrir önnur skilaboð. Það sendir þá í allar áttir og því er ekkert vandamál með hænu og egg eins og var í Auto-RP.
3) Um leið og RP fær skilaboð frá BSR beininum mun hann strax senda einvarpsskilaboð á BSR beini heimilisfangið:
Eftir það mun BSR, eftir að hafa fengið upplýsingar um RP, senda þær með fjölvarpi á netfangið 224.0.0.13, sem allir PIM beinir hlusta á. Því hliðstæða skipunarinnar ip pim autorp hlustandi fyrir venjulega beina sem ekki eru í BSR.
Anycast RP með Multicast Source Discovery Protocol (MSDP).
Auto-RP og BSR gera okkur kleift að dreifa álaginu á RP sem hér segir: Hver multicast hópur hefur aðeins einn virkan RP. Ekki verður hægt að dreifa álaginu fyrir einn fjölvarpshóp yfir nokkra RP. MSDP gerir þetta með því að gefa út RP beinum sömu IP tölu með grímunni 255.255.255.255. MSDP lærir upplýsingar með því að nota eina af aðferðunum: static, Auto-RP eða BSR.
Á myndinni erum við með Auto-RP stillingu með MSDP. Báðir RP eru stilltir með IP tölu 172.16.1.1/32 á Loopback 1 viðmóti og er notað fyrir alla hópa. Með RP-Announce tilkynna báðir beinir sig með því að vísa í þetta heimilisfang. Auto-RP kortlagningaraðili, eftir að hafa fengið upplýsingarnar, sendir RP-Discovery um RP með heimilisfanginu 172.16.1.1/32. Við segjum beinum frá netinu 172.16.1.1/32 með því að nota IGP og í samræmi við það. Þannig biðja PIM beinar um eða skrá flæði frá RP sem er tilgreint sem næsta hopp á leiðinni til netkerfisins 172.16.1.1/32. MSDP samskiptareglan sjálf er hönnuð fyrir RPs sjálfir til að skiptast á skilaboðum um fjölvarpsupplýsingar.
Íhugaðu þessa staðfræði:
Switch6 sendir út umferð á heimilisfangið 238.38.38.38 og enn sem komið er veit aðeins RP-R1 um það. Switch7 og Switch8 óskuðu eftir þessum hópi. Beinir R5 og R4 munu senda PIM Join til R1 og R3, í sömu röð. Hvers vegna? Leiðin til 13.13.13.13 fyrir R5 mun vísa til R1 með því að nota IGP mæligildið, alveg eins og fyrir R4.
RP-R1 veit um strauminn og mun byrja að senda hann í átt að R5, en R4 veit ekkert um það, þar sem R1 mun ekki einfaldlega senda það. Þess vegna er MSDP nauðsynlegt. Við stillum það á R1 og R5:
ip msdp peer 3.3.3.3 connect-source Loopback1 á R1
ip msdp peer 1.1.1.1 connect-source Loopback3 á R3
Þeir munu taka upp lotu sín á milli og þegar þeir fá flæði munu þeir tilkynna það til RP nágranna síns.
Um leið og RP-R1 fær straum frá Switch6 mun það strax senda unicast MSDP Source-Active skilaboð, sem munu innihalda upplýsingar eins og (S, G) - upplýsingar um uppruna og áfangastað fjölvarpsins. Nú þegar RP-R3 veit að uppspretta eins og Switch6, þegar hann fær beiðni frá R4 um þetta flæði, mun hann senda PIM Join í átt að Switch6, með leiðartöflunni að leiðarljósi. Þar af leiðandi mun R1, sem hefur fengið slíkan PIM Join, byrja að senda umferð í átt að RP-R3.
MSDP keyrir yfir TCP, RPs senda hvort öðru áframhaldandi skilaboð til að athuga lífleika. Tímamælirinn er 60 sekúndur.
Virkni þess að skipta MSDP jafningjum í mismunandi lén er enn óljós, þar sem Keepalive og SA skilaboð gefa ekki til kynna aðild að neinu léni. Einnig, í þessari staðfræði, prófuðum við uppsetningu sem gefur til kynna mismunandi lén - það var enginn munur á frammistöðu.
Ef einhver getur útskýrt þá væri ég fús til að lesa það í athugasemdum.
Heimild: www.habr.com