PIM-protokoll on protokollide kogum multisaadete edastamiseks võrgus ruuterite vahel. Naabrussuhted on üles ehitatud samamoodi nagu dünaamiliste marsruutimisprotokollide puhul. PIMv2 saadab Tere sõnumeid iga 30 sekundi järel reserveeritud multisaateaadressile 224.0.0.13 (All-PIM-Routers). Sõnum sisaldab Hold Timers - tavaliselt võrdne 3.5* Hello Timer, st vaikimisi 105 sekundit.
PIM kasutab kahte peamist töörežiimi – tihe ja hõre režiim. Alustame tiheda režiimiga.
Allikapõhised jaotuspuud.
Tiherežiimi režiimi on soovitatav kasutada suure hulga erinevate multisaaterühmade klientide puhul. Kui ruuter võtab vastu multiedastusliikluse, kontrollib see esimese asjana RPF-reeglit. RPF – seda reeglit kasutatakse multisaate allika kontrollimiseks unicast marsruutimistabeliga. On vaja, et liiklus jõuaks liidesesse, mille taha see host on peidetud vastavalt unicast marsruutimistabeli versioonile. See mehhanism lahendab multisaateedastuse ajal tekkiva ahela probleemi.
R3 tunneb multiedastuse allika (Source IP) ära multisaadete sõnumist ja kontrollib kahte voogu R1-st ja R2-st, kasutades oma unicast tabelit. Tabeli (R1 kuni R3) näidatud liidese voog edastatakse edasi ja voog R2-st loobutakse, kuna multisaateallikasse jõudmiseks peate paketid saatma S0/1 kaudu.
Küsimus on selles, mis juhtub, kui teil on kaks samaväärset marsruuti sama mõõdikuga? Sel juhul valib ruuter nende marsruutide hulgast järgmise hüppe. Võidab see, kellel on kõrgem IP-aadress. Kui teil on vaja seda käitumist muuta, võite kasutada ECMP-d. Rohkem detaile .
Pärast RPF-reegli kontrollimist saadab ruuter multisaatepaketi kõigile oma PIM-naabritele, välja arvatud sellele, kellelt pakett vastu võeti. Teised PIM-ruuterid kordavad seda protsessi. Tee, mille multiedastuspakett on allikast lõpp-saajateni võtnud, moodustab puu, mida nimetatakse allikapõhiseks jaotuspuuks, lühima tee puuks (SPT), lähtepuuks. Kolm erinevat nime, valige ükskõik milline.
Kuidas lahendada probleem, et osad ruuterid ei andnud alla mingi multicast striimi peale ja pole kellelegi saata, aga ülesvoolu ruuter saadab selle talle. Selleks leiutati Prune mehhanism.
Prune sõnum.
Näiteks R2 jätkab multisaate saatmist R3-le, kuigi R3 RPF reegli kohaselt loobub sellest. Miks kanalit laadida? R3 saadab PIM-i pügamissõnumi ja R2 eemaldab selle teate saamisel liidese S0/1 selle voo väljuvate liideste loendist, liideste loendist, kust see liiklus tuleks saata.
Järgmine on PIM Prune'i sõnumi ametlikum määratlus:
Üks ruuter saadab PIM Prune'i sõnumi teisele ruuterile, et panna teine ruuter eemaldama lingi, mille kaudu prune konkreetselt (S,G) SPT-lt vastu võetakse.
Pärast Prune sõnumi saamist seab R2 Prune taimeriks 3 minutit. Kolme minuti pärast hakkab see uuesti liiklust saatma, kuni saab uue Prune'i sõnumi. See on PIMv1-s.
Ja PIMv2-sse on lisatud State Refresh taimer (vaikimisi 60 sekundit). Niipea kui R3-lt on saadetud Prune-sõnum, käivitub see taimer R3-l. Taimeri aegumisel saadab R3 oleku värskendusteate, mis lähtestab selle grupi R3 2-minutilise prune-taimeri.
Prune'i sõnumi saatmise põhjused:
- Kui multisaadete pakett ebaõnnestub RPF-kontrollis.
- Kui pole lokaalselt ühendatud kliente, kes on taotlenud multisaadete gruppi (IGMP Join) ja pole PIM-naabreid, kellele saab multiedastusliiklust saata (mitte-prune Interface).
Siirda sõnum.
Kujutagem ette, et R3 ei tahtnud R2-lt liiklust, saatis Prune'i ja sai R1-lt multisaate. Kuid järsku langes kanal R1-R3 vahel ja R3 jäi ilma multisaateta. Võite oodata 3 minutit, kuni R2 ploomitaimer aegub. 3 minutit on pikk ootamine, et mitte oodata, peate saatma sõnumi, mis toob selle S0/1 liidese R2-le koheselt kärbitud olekust välja. Sellest sõnumist saab siirikusõnum. Pärast siirikusõnumi saamist vastab R2 siiriku-ACK-ga.
Prune Override.
Vaatame seda diagrammi. R1 edastab multiedastuse kahe ruuteriga segmendile. R3 võtab vastu ja edastab liiklust, R2 võtab vastu, kuid tal pole kedagi, kellele liiklust edastada. See saadab selles segmendis R1-le sõnumi Prune. R1 peaks Fa0/0 nimekirjast eemaldama ja selles segmendis leviedastuse lõpetama, aga mis saab R3-st? Ja R3 on samas segmendis, sai ka selle sõnumi Prune'ilt ja mõistis olukorra traagikat. Enne kui R1 edastamise lõpetab, seab see taimeri 3 sekundiks ja lõpetab edastamise 3 sekundi pärast. 3 sekundit – täpselt nii palju aega on R3-l, et mitte kaotada oma multisaadet. Seetõttu saadab R3 sellele grupile esimesel võimalusel Pim Join sõnumi ja R1 ei mõtle enam edastuse lõpetamisele. Teave liitumissõnumite kohta allpool.
Kinnita sõnum.
Kujutagem ette seda olukorda: kaks ruuterit edastavad korraga ühte võrku. Nad saavad allikast sama voogu ja mõlemad edastavad selle liidese e0 taga samasse võrku. Seetõttu peavad nad kindlaks määrama, kes on selle võrgu ainus ringhäälinguorganisatsioon. Selleks kasutatakse kinnitussõnumeid. Kui R2 ja R3 tuvastavad multisaadete liikluse dubleerimise, st R2 ja R3 võtavad vastu multisaate, mida nad ise edastavad, saavad ruuterid aru, et siin on midagi valesti. Sel juhul saadavad ruuterid Assert sõnumeid, mis sisaldavad administratiivset kaugust ja marsruudi mõõdikut, millega multisaateallikani jõutakse – 10.1.1.10. Võitja selgitatakse välja järgmiselt:
- See, kellel on madalam AD.
- Kui AD on võrdsed, siis kellel on madalam mõõdik.
- Kui siin on võrdsus, siis see, kellel on kõrgem IP võrgus, kuhu nad seda multisaadet edastavad.
Selle hääletuse võitjaks saab määratud ruuter. Pim Hello'i kasutatakse ka DR-ide valimiseks. Artikli alguses näidati PIM Hello teadet, seal on näha DR välja. Võidab see, kellel on sellel lingil kõrgeim IP-aadress.
Kasulik märk:
MROUTE tabel.
Pärast PIM-protokolli toimimise esmast ülevaadet peame mõistma, kuidas töötada multisaadete marsruutimistabeliga. Mroute tabel salvestab teavet selle kohta, milliseid vooge klientidelt küsiti ja millised vood multisaateserveritest voolavad.
Näiteks kui mõnes liideses võetakse vastu IGMP liikmelisuse aruanne või PIM-i liitumine, lisatakse marsruutimistabelisse kirje ( *, G ):
See kirje tähendab, et saadeti liikluspäring aadressiga 238.38.38.38. DC-lipp tähendab, et multisaade töötab tihedas režiimis ja C tähendab, et adressaat on ruuteriga otse ühendatud, see tähendab, et ruuter sai IGMP liikmelisuse aruande ja PIM-i liitumise.
Kui on olemas (S,G) tüüpi kirje, tähendab see, et meil on multisaadete voog:
Väljal S - 192.168.1.11 oleme registreerinud multiedastusallika IP-aadressi, seda kontrollib RPF-reegel. Probleemide korral peate esmalt kontrollima unicast-tabelist marsruuti allikani. Väljal Sissetulev liides tähistab liidest, millele multisaade vastu võetakse. Unicast marsruutimistabelis peab marsruut allikani viitama siin määratud liidesele. Väljuv liides määrab, kuhu multisaade ümber suunatakse. Kui see on tühi, pole ruuter selle liikluse kohta ühtegi päringut saanud. Lisateavet kõigi lippude kohta leiate .
PIM hõre režiim.
Sparse-režiimi strateegia on tiheda režiimi vastand. Kui hõre režiim võtab vastu multiedastusliikluse, saadab see liiklust ainult nende liideste kaudu, kus selle voo jaoks oli päringuid, näiteks Pim Join või IGMP Report sõnumid, mis seda liiklust taotlevad.
Sarnased elemendid SM ja DM jaoks:
- Naabrussuhted on üles ehitatud samamoodi nagu PIM DM-is.
- RPF-reegel töötab.
- DR-valik on sarnane.
- Prune Overrides ja Assert sõnumite mehhanism on sarnane.
Et kontrollida, kes, kus ja millist multisaateliiklust võrgus on vaja, on vaja ühist teabekeskust. Meie keskuseks saab Rendezvous Point (RP). Kes soovib mingit multisaateliiklust või keegi hakkas multisaate liiklust allikast vastu võtma, siis saadab selle RP-le.
Kui RP saab multiedastusliikluse, saadab see selle neile ruuteritele, kes seda liiklust varem taotlesid.
Kujutagem ette topoloogiat, kus RP on R3. Niipea, kui R1 saab S1-lt liiklust, kapseldab see selle multisaatepaketi PIM-registri unicast-sõnumisse ja saadab selle RP-le. Kuidas ta teab, kes on RP? Sel juhul konfigureeritakse see staatiliselt ja dünaamilise RP konfiguratsioonist räägime hiljem.
ip pim rp-aadress 3.3.3.3
RP vaatab - kas oli infot kelleltki, kes sooviks seda liiklust saada? Oletame, et ei olnud. Siis saadab RP R1-le PIM Register-Stop sõnumi, mis tähendab, et seda multisaadet pole kellelgi vaja, registreerimine on keelatud. R1 ei saada multisaadet. Kuid multisaateallika host saadab selle nii, et R1 käivitab pärast registri peatamise saamist registri sulgemise taimeri, mis on võrdne 60 sekundiga. 5 sekundit enne selle taimeri aegumist saadab R1 tühja registriteate nullregistri bitiga (st ilma kapseldatud multisaatepaketita) RP-le. RP omakorda käitub järgmiselt:
- Kui adressaate polnud, vastab see Registri-Stop sõnumiga.
- Kui adressaadid ilmuvad, ei reageeri ta sellele kuidagi. R1, kes ei saanud 5 sekundi jooksul registreerimisest keeldumist, on rahul ja saadab RP-le kapseldatud multisaadetega registreerimissõnumi.
Näib, et oleme aru saanud, kuidas multisaade RP-ni jõuab, proovime nüüd vastata küsimusele, kuidas RP edastab liiklust adressaatidele. Siin on vaja tutvustada uut mõistet - root-path tree (RPT). RPT on RP-s juurdunud puu, mis kasvab adressaatide poole ja hargneb igal PIM-SM ruuteril. RP loob selle PIM Join sõnumite vastuvõtmisega ja lisab puule uue haru. Ja nii teeb iga allavoolu ruuter. Üldreegel näeb välja selline:
- Kui PIM-SM-ruuter saab PIM-ühenduse teate mis tahes muul liidesel peale liidese, mille taha RP on peidetud, lisab see puusse uue haru.
- Filiaal lisatakse ka siis, kui PIM-SM-ruuter saab otse ühendatud hostilt IGMP liikmelisuse aruande.
Kujutagem ette, et meil on R5-ruuteris grupi 228.8.8.8 jaoks multisaateklient. Niipea kui R5 saab hostilt IGMP liikmelisuse aruande, saadab R5 PIM-i liitumise RP suunas ja lisab ise puusse liidese, mis vaatab hosti. Järgmisena võtab R4 vastu R5-lt PIM Join, lisab puule liidese Gi0/1 ja saadab PIM Join RP suunas. Lõpuks võtab RP ( R3 ) vastu PIM Join ja lisab puule Gi0/0. Seega registreeritakse multisaate adressaat. Ehitame puud juurega R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0.
Pärast seda saadetakse R1-le PIM-ühendus ja R1 hakkab saatma multiedastusliiklust. Oluline on märkida, et kui host taotles liiklust enne multisaateedastuse algust, siis RP ei saada PIM Join'i ega saada R1-le üldse midagi.
Kui äkitselt multisaate saatmise ajal ei soovi host seda vastu võtta, siis niipea, kui RP saab Gi0/0 liidesel PIM-i prune'i, saadab ta kohe PIM-i registri peatamise otse R1-le ja seejärel PIM-i prune'i. sõnum Gi0/1 liidese kaudu. PIM Register-stopp saadetakse unicast kaudu aadressile, kust PIM register tuli.
Nagu me varem ütlesime, lisatakse niipea, kui ruuter saadab teisele PIM-ühenduse, näiteks R5 kuni R4, kirje R4:
Ja käivitatakse taimer, et R5 peab selle taimeriga pidevalt lähtestama PIM Join sõnumeid pidevalt, muidu jäetakse R4 väljaminevate nimekirjast välja. R5 saadab iga 60 PIM Join sõnumi.
Lühima tee puu ümberlülitamine.
Lisame liidese R1 ja R5 vahele ja vaatame, kuidas liiklus selle topoloogiaga sujub.
Oletame, et liiklus saadeti ja võeti vastu vana skeemi R1-R2-R3-R4-R5 järgi ning siin ühendasime ja konfigureerisime R1 ja R5 vahelise liidese.
Kõigepealt peame R5-l uuesti üles ehitama unicast-marsruutimistabeli ja nüüd jõutakse võrguni 192.168.1.0/24 läbi R5 Gi0/2 liidese. Nüüd saab R5, kes võtab vastu multisaadet liidesel Gi0/1, aru, et RPF reegel ei ole täidetud ja loogilisem oleks multisaadet vastu võtta Gi0/2 kaudu. See peaks RPT-st lahti ühendama ja looma lühema puu nimega Shortest-Path Tree (SPT). Selleks saadab ta läbi Gi0/2 R1-le PIM Join ja R1 hakkab saatma multisaadet ka läbi Gi0/2. Nüüd peab R5 RPT tellimusest loobuma, et mitte saada kahte koopiat. Selleks saadab ta Prune'ile teate, mis näitab lähte IP-aadressi ja sisestab spetsiaalse biti - RPT-biti. See tähendab, et te ei pea mulle liiklust saatma, mul on siin parem puu. RP saadab ka PIM Prune'i sõnumeid R1-le, kuid ei saada Registri-Stop sõnumit. Veel üks funktsioon: R5 saadab nüüd pidevalt PIM Prune'i RP-le, kuna R1 jätkab PIM-registri saatmist RP-le iga minut. Kuni pole uusi inimesi, kes seda liiklust sooviksid, keeldub RP sellest. R5 teavitab RP-d, et jätkab multisaadete vastuvõtmist SPT kaudu.
Dünaamiline RP otsing.
Auto-RP.
See tehnoloogia on Cisco patenteeritud ja pole eriti populaarne, kuid on endiselt elus. Auto-RP töö koosneb kahest põhietapist:
1) RP saadab RP-Announce sõnumid reserveeritud aadressile - 224.0.1.39, kuulutades end RP-ks kas kõigile või kindlatele gruppidele. Seda sõnumit saadetakse iga minut.
2) Vaja on RP kaardistamisagenti, mis saadab RP-Discovery teateid, mis näitavad, milliste gruppide puhul millist RP-d tuleks kuulata. Selle sõnumi põhjal määravad tavalised PIM-ruuterid ise RP. Mapping Agent võib olla kas RP-ruuter ise või eraldi PIM-ruuter. RP-Discovery saadetakse üheminutilise taimeriga aadressile 224.0.1.40.
Vaatame protsessi üksikasjalikumalt:
Seadistame R3 RP-ks:
ip pim send-rp-announce loopback 0 ulatus 10
R2 kaardistusagendina:
ip pim send-rp-discovery loopback 0 ulatus 10
Ja kõigi teiste puhul ootame RP-d Auto-RP kaudu:
ip pim autorp kuulaja
Kui oleme R3 konfigureerinud, hakkab see saatma RP-Announce:
Ja R2 hakkab pärast vastendusagendi seadistamist ootama RP-Announce sõnumit. Alles siis, kui see leiab vähemalt ühe RP, hakkab see saatma RP-Discovery:
Nii teavad nad niipea, kui tavalised ruuterid (PIM RP Listener) selle teate saavad, kust RP-d otsida.
Üks peamisi probleeme Auto-RP puhul on see, et RP-Announce ja RP-Discovery sõnumite saamiseks tuleb saata PIM Join aadressidele 224.0.1.39-40 ning saatmiseks on vaja teada, kuhu RP asub. Klassikaline kana ja muna probleem. Selle probleemi lahendamiseks leiutati PIM Sparse-Dense-Mode. Kui ruuter RP-d ei tunne, töötab see tihedas režiimis, kui teab, siis hõreda režiimis. Kui tavaliste ruuterite liidestel on konfigureeritud PIM Sparse-mode ja ip pim autorp kuulaja käsk, töötab ruuter tihedas režiimis ainult multiedastuseks otse Auto-RP protokollist (224.0.1.39-40).
BootStrap ruuter (BSR).
See funktsioon töötab sarnaselt Auto-RP-ga. Iga RP saadab sõnumi kaardistamisagendile, mis kogub kaardistamise teavet ja teavitab sellest kõiki teisi ruuteriid. Kirjeldame protsessi sarnaselt Auto-RP-ga:
1) Kui oleme konfigureerinud R3 kandidaadiks RP-ks, käsuga:
ip pim rp-kandidaadi loopback 0
Siis ei tee R3 midagi, spetsiaalsete sõnumite saatmiseks peab ta esmalt leidma kaardistaja. Seega liigume edasi teise sammu juurde.
2) Konfigureerige R2 vastendusagendina:
ip pim bsr-candidate loopback 0
R2 hakkab saatma PIM Bootstrap sõnumeid, kus ta näitab end kaardistusagendina:
See teade saadetakse aadressile 224.0.013, mida PIM-protokoll kasutab ka oma teiste sõnumite jaoks. See saadab neid igale poole ja seetõttu pole kana ja muna probleemi nagu Auto-RP-s.
3) Niipea, kui RP saab BSR-ruuterilt teate, saadab see kohe BSR-ruuteri aadressile unicast sõnumi:
Pärast seda saadab BSR, olles saanud teabe RP-de kohta, need multisaate teel aadressile 224.0.0.13, mida kuulavad kõik PIM-ruuterid. Seega käsu analoog ip pim autorp kuulaja tavaliste ruuterite jaoks, mis ei asu Läänemere piirkonnas.
Anycast RP multicast Source Discovery Protocoliga (MSDP).
Auto-RP ja BSR võimaldavad meil RP koormust jaotada järgmiselt: Igal multisaaterühmal on ainult üks aktiivne RP. Ühe multisaaterühma koormust ei ole võimalik mitme RP vahel jaotada. MSDP teeb seda, väljastades RP-ruuteritele sama IP-aadressi maskiga 255.255.255.255. MSDP õpib teavet ühe meetodi abil: staatiline, Auto-RP või BSR.
Pildil on meil MSDP-ga Auto-RP konfiguratsioon. Mõlemad RP-d on Loopback 172.16.1.1 liideses konfigureeritud IP-aadressiga 32/1 ja neid kasutatakse kõigi rühmade jaoks. RP-Announce puhul annavad mõlemad ruuterid endast teada, viidates sellele aadressile. Auto-RP kaardistamisagent saadab teabe kätte saanud RP-Discovery RP kohta aadressiga 172.16.1.1/32. Räägime ruuteritest võrgust 172.16.1.1/32, kasutades IGP-d ja vastavalt. Seega taotlevad või registreerivad PIM-ruuterid vooge RP-st, mis on määratud järgmise hüppena marsruudil võrku 172.16.1.1/32. MSDP-protokoll ise on mõeldud RP-de endi jaoks, et vahetada sõnumeid multisaateteabe kohta.
Mõelge sellele topoloogiale:
Switch6 edastab liiklust aadressile 238.38.38.38 ja seni teab sellest ainult RP-R1. Switch7 ja Switch8 taotlesid seda rühma. Ruuterid R5 ja R4 saadavad PIM-ühenduse vastavalt R1-le ja R3-le. Miks? Marsruut punktile 13.13.13.13 R5 puhul viitab R1-le, kasutades IGP mõõdikut, täpselt nagu R4 puhul.
RP-R1 teab voost ja hakkab seda edastama R5 suunas, kuid R4 ei tea sellest midagi, kuna R1 seda lihtsalt ei saada. Seetõttu on MSDP vajalik. Seadistame selle R1 ja R5 jaoks:
ip msdp peer 3.3.3.3 connect-source Loopback1 R1-l
ip msdp peer 1.1.1.1 connect-source Loopback3 R3-l
Nad tõstavad omavahel seansi ja voo saamisel teatavad nad sellest oma RP-naabrile.
Niipea, kui RP-R1 saab Switch6-lt voo, saadab see kohe unicast MSDP Source-Active sõnumi, mis sisaldab sellist teavet nagu (S, G) - teave multisaate allika ja sihtkoha kohta. Nüüd, kui RP-R3 teab, et allikas, näiteks Switch6, saadab R4-lt selle voo kohta päringu saades PIM-ühenduse marsruutimistabelist juhindudes Switch6 poole. Järelikult hakkab sellise PIM-ühenduse saanud R1 liiklust saatma RP-R3 suunas.
MSDP töötab üle TCP, RP-d saadavad üksteisele elavuse kontrollimiseks sõnumeid. Taimer on 60 sekundit.
MSDP partnerite erinevateks domeenideks jagamise funktsioon jääb ebaselgeks, kuna Keepalive ja SA sõnumid ei viita ühegi domeeni liikmelisusele. Samuti testisime selles topoloogias erinevaid domeene tähistavat konfiguratsiooni – jõudluses polnud erinevust.
Kui keegi oskab täpsustada, siis hea meelega loen seda kommentaarides.
Allikas: www.habr.com