PIM protokolli tööpõhimõtted

PIM-protokoll on protokollide kogum, mis edastab multikaastivõrgus rikutud marsruuterite vahel. Naabrussuhted luuakse sarnaselt dünaamiliste marsruutimisprotokollidega. PIMv2 saatab iga 30 sekundi järel Hello sõnumid reserveeritud multikaast aadressile 224.0.0.13 (All-PIM-Routers). Sõnum sisaldab Hold Timereid — tavaliselt 3,5 korda Hello Timer, mis tähendab vaikimisi 105 sekundit.

PIM kasutab kahte põhirežiimi — Dense ja Sparse mode. Alustame Dense mode'ist.
Allika-põhised jaotustead.
Dense-mode režiimi on mõistlik kasutada palju kliente erinevatest multikaasgruppidest. Kui marsruuter saab multikaasiliiklust, kontrollib ta kõigepealt selle RPF-reegli järgi. RPF — see reegel kontrollib multikaasi allikat unikaastia marsruuditabeliga. Liiklus peab tulema sellele liidesele, mille taga on see host unikaastia marsruuditabeli kohaselt. See mehhanism lahendab multikaasi edastamise käigus tekkida võivate silmade probleemi.

R3 multicast sõnumist tuvastab multicasti allika (Source IP) ja kontrollib R1 ja R2 kahte voogu oma unikaalses tabelis. Voog, mis tulevast liidese kaudu edasi saadetakse (R1-st R3-ni), edastatakse edasi, samas kui R2 voog lükatakse tagasi, kuna multicasti allikasse jõudmiseks tuleb pakette edastada S0/1 kaudu.
Küsimus, mis juhtub siis, kui teil on kaks ekvivalentset marsruuti sama meetriga? Sellisel juhul valib marsruuter need marsruudid next-hop'i põhjal. Kõrgema IP-aadressiga marsruut on võitnud. Kui on vaja seda käitumist muuta, võib kasutada ECMP-d. Lisainfot. siin.
Pärast RPF reegli kontrollimist saadab marsruuter multicast-paketti kõigile oma PIM-naabritele, välja arvatud see, kellelt pakett saadi. Ülejäänud PIM-marsruuterid kordavad seda protsessi. Tee, mida multicast-pakett läbib allikast kuni lõppsaajateni, moodustab puu, mida nimetatakse — allikaspõhiseks jaotuspuiduks, lühima tee puuks (SPT), allikapuu. Kolm erinevat nime, valige üks.
Kuidas lahendada küsimust, et mõned ruuterid ei saanud mõnedest multimeedia voogudest ja ei suuna neid kellelegi, samas kui kõrgem ruuter saadab. Selleks on välja mõeldud Prune mehhanism.
Prune sõnum.
Näiteks R2 jätkab R3-le multimeedia saatmist, kuigi R3 viskab selle RPF reegli tõttu kõrvale. Miks koormata kanalit? R3 saadab PIM Prune sõnumi ja R2, pärast selle sõnumi vastuvõttu, eemaldab S0/1 liidese (väljuvate liideste loendist) antud voogude jaoks, loenditest, millest seda liiklust tuleb saata.

Allpool on PIM Prune sõnumi formaalne definitsioon:
PIM Prune sõnum saadetakse ühelt ruuterilt teisele, et sundida teist ruuteri eemaldama Prune'i vastuvõtmise linki konkreetsest (S,G) SPT-st.

Pärast Prune sõnumi vastuvõtmist seab R2 Prune taimeri kolme minuti peale. Kolme minuti möödudes alustab ta taas liikluse saatmist, kuni saab järgmise Prune sõnumi. See kehtib PIMv1 puhul.
PIMv2-s on lisatud oleku uuendamise taimer (vaikimisi 60 sekundit). Kui R3-lt saadetakse Prune sõnum, käivitub see taimer R3-l. Pärast taimeri aegumist saadab R3 oleku uuendamise sõnumi, mis lähtestab R2-l 3-minutilise Prune Taimeri antud grupi jaoks.
Prune sõnumi saatmise põhjused:

• Kui multicast-paketti ei läbitud RPF-i kontrolli.
• Kui ei ole kohapealseid ühendatud kliente, kes on taotlenud multicast-gruppi (IGMP Join), ning pole PIM naabreid, kellele multicast-trafikut edastada (Non-prune Interface).

Grafti sõnum.
Kujutame ette, et R3 ei soovinud R2-lt trafikuit, saatis Prune ja sai multicastit R1-elt. Kuid äkki katkeb kanal R1-R3 vahel ja R3 jääb ilma multicastita. Tuleb oodata 3 minutit, kuni R2-l aegub Prune Timer. 3 minutit on liiga kaua oodata, et seda mitte teha, tuleb saata sõnum, mis kohe viib antud liini S0/1 R2-lt pruned-olekust välja. Selliseks sõnumiks on Grafti sõnum. Pärast Grafti sõnumi vastuvõtmist saadab R2 vastuseks Graft-ACK.
Prune Override.

Vaadakem sellele skeemile. R1 edastab multikaast segmendis, kus on kaks ruuteri. R3 saab ja edastab liiklust, R2 saab, kuid edastamiseks pole kedagi. Ta saadab R1-ile Prune sõnumi antud segmendis. R1 peab Fa0/0 loendist eemaldama ja lõpetama edastamise antud segmendis, aga mis juhtub R3-ga? R3 on samas segmendis, sai samuti selle Prune sõnumi ja mõistis kogu olukorra tragöödia. Enne kui R1 lõpetab edastamise, seadistab ta taimeri 3 sekundiks ja lõpetab edastamise 3 sekundi pärast. 3 sekundit — just nii palju aega on R3-l, et oma multikaast mitte kaotada. Seetõttu saadab R3 niipea kui võimalik Pim Join sõnumi antud rühmale ja R1 ei mõtle enam lõpetamisele. Join sõnumitest allpool.
Assert Message.

Kujutage ette olukorda, kus kahe ruuteri kaudu edastatakse sama voog ühes võrgus. Mõlemad saavad selle sama voolu allikast ning edastavad selle e0 liidese kaudu ühte võrku. Seetõttu peavad nad määrama, kes on selle võrgu jaoks ainus edastaja. Selleks kasutatakse Teavitusi. Kui R2 ja R3 tuvastavad dubleeritud mitme saatja liiklust, st et R2 ja R3 saavad mitme saatja voogu, mida nad ise edastavad, mõistavad ruuterid, et siin on midagi valesti. Sellisel juhul saadavad ruuterid Teavituse, mis sisaldab haldusvahemaad ja marsruudi mõõdikut, mille kaudu saavutatakse mitme saatja allikas — 10.1.1.10. Võitja määratakse järgmiselt:

1. See, kelle haldusvahemik on madalam.
2. Kui haldusvahemikud on võrdsed, siis see, kellel on madalam mõõdik.
3. Kui ka siin on võrdne, siis see, kellel on kõrgem IP aadress võrgus, kuhu nad seda mitme saatjat edastavad.

Selles hääletuses võitnud ruuter muutub määratud ruuteriks (Designated Router). DR valimiseks kasutatakse samuti PIM Hello-sid. Artikli alguses näidati PIM Hello sõnumit, kus võib märgata DR välja. Võitja on see, kelle IP aadress on sellel lingil kõrgem.
Kasulik tabel:

MROUTE tabel.
PIM-protokolli algsete ülevaatuste järel peame selgeks saama, kuidas töötada multikaastabeliga. Mroute tabelis hoitakse teavet selle kohta, milliseid voogusid on kliendid taotlenud ja millised voogud tulevad multikaasserveritest.
Näiteks, kui mõnel liideseal saabub IGMP Membership Report või PIM Join, lisatakse marsruutimistabelisse kirje tüüpi (*, G):

See kirje näitab, et on saabunud päring voogudele aadressilt 238.38.38.38. DC lipp tähendab, et multikaas töötab tihedas režiimis (Dense mode) ja C tähendab, et saaja on ühendatud otse marsruuteriga, st marsruuter on saanud IGMP Membership Report'i ja PIM Join'i.
Kui kirje on tüüpi (S, G), siis tähendab see, et meil on multikaasivoog:

S-väljal on 192.168.1.11, meil on määratud multikaallika IP-aadress, just tema kontrollitakse RPF-reegliga. Probleemide korral tuleb kõigepealt kontrollida unicast-tabelit, et leida marsruut allika juurde. Incoming Interface väljal näidatakse liidest, mille kaudu multikaallikad tulevad. Unicast marsruuditabelis peab allikani viiv marsruut viitama siin näidatud liidesele. Outgoing Interface väljal näidatakse, kuhu multikaal suunatakse. Kui see on tühi, tähendab see, et ruuterile ei ole selle liikluse jaoks päringuid saabunud. Täiendavat teavet kõigi lippude kohta leiate siit.
PIM Sparse-mode.
Sparse-mode strateegia on vastupidine Dense-mode'le. Kui Sparse-mode saab multikaaliliiklust, suunab ta liikluse ainult nendele liidesele, kus on olnud päringud selle voogu, näiteks Pim Join või IGMP Report sõnumid, mis pärivad seda liiklust.
SM ja DM sarnased elemendid:

• Naaberühendused luuakse nagu PIM DM-is.
• RPF-reegel töötab.
• DR valik on sarnane.
• Prune Overrides mehhanism ja Assert sõnumid on sarnased.

Ettevõtte võrgus, et hallata, kellele, kus ja millist multicastingi liiklust vaja on, on vajalik ühine teabe keskus. Selleks keskuseks on meil Rendezvous Point (RP). Kõik, kes soovivad mingisugust multicastingi liiklust või on hakanud saama multicastingi liiklust allikast, saadavad selle RP-le.
Kui RP saab multicastingi liiklust, siis saadab see selle marsruuteritele, kes on varem seda liiklust küsinud.

Kujutame ette sellist topoloogiat, kus RP on R3. Niipea kui R1 saab liiklust S1-lt, kapseldab ta selle multicastingi paketi unicast PIM Register sõnumiks ja saadab selle RP-le. Kuidas ta teab, kes on RP? Antud juhul on see seadistatud staatiliselt, kuid dünaamilise RP seadistamise teemal räägime hiljem.

ip pim rp-address 3.3.3.3

RP vaatab, kas on olnud teavet kellegi käest, kes sooviks selle liikluse saada? Oletame, et ei ole. Siis saadab RP R1-le PIM Register-Stop sõnumi, mis tähendab — et keegi ei vaja seda multicast'i, registreerimine on keelatud. R1 ei saada multicast'i. Kuid host-allika multicast saadab selle, nii et R1, pärast Register-Stopi saamist, käivitab Register-Suppression timer'i, mis kestab 60 sekundit. 5 sekundit enne selle taimeri lõppemist saadab R1 tühja Register sõnumi koos Null-Register bit'iga (st ilma kapseldatud multicast paketi). RP käitub järgmiselt:

• Kui saajaid ei olnud, ei ole neid ka nüüd, siis vastab ta Register-Stop sõnumiga.
• Kui saajad on ilmunud, siis ei vasta ta sellele kuidagi. R1, kui ta ei saa 5 sekundi jooksul registreerimisele keeldumist, rõõmustab ja saadab Register sõnumi kapseldatud multicast'iga RP-le.

Kuidas multicast jõuab RP-ni, oleme enam-vähem aru saanud, nüüd proovime vastata küsimusele, kuidas RP edastab liiklust saajateni. Siin on vaja tutvustada uut mõistet — root-path tree (RPT). RPT on puu, mille juured on RP-s, ulatudes saajateni ja hargnedes igas PIM-SM ruuteris. RP loob selle, saades PIM Join sõnumeid ja lisab puusse uue meie. Ja nii teeb iga madalam ruuter. Üldine reegel on järgmine:

• Kui PIM-SM ruuter saab PIM Join sõnumi mõnel liidesel, välja arvatud liides, mille taga on RP, lisab ta puusse uue haru.
• Haru lisatakse ka siis, kui PIM-SM ruuter saab IGMP Membership Reporti vahetult ühendatud hostilt.

Kujutame ette, et meil on klient, kes kasutab multicasti ruuteris R5 aadressi 228.8.8.8. Kui R5 saab IGMP liitumisraporti hostilt, saadab R5 PIM Join'i RP suunas ning lisab liidese puusse, mis vaatab hosti poole. Seejärel R4 saab PIM Join'i R5-lt, lisab liidese Gi0/1 puusse ja saadab PIM Join'i RP suunas. Lõpuks RP (R3) saab PIM Join'i ja lisab Gi0/0 puusse. Nii toimub multicasti saaja registreerimine. Meil tekib puu, mille juured on R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0.
Pärast seda saadetakse PIM Join R1-le ja R1 hakkab saatma multicasti liiklust. On oluline märkida, et kui host taotles liiklust enne, kui multicasti edastus algas, siis RP ei saadet PIM Join'i ja ei saadet midagi R1 suunas.
Kui juhuslikult, kui multicasti saadetakse, lõpetab host selle saamise soovi, siis kui RP saab PIM Prune'i liidese Gi0/0 pealt, saadab ta koheselt PIM Register-Stop'i R1-le ning seejärel PIM Prune'i sõnumi liidese Gi0/1 kaudu. PIM Register-Stop saadetakse unicastina aadressile, millest PIM Register tuli.
Nagu varem rääkisime, kui ruuter saadab PIM Join teisele, näiteks R5-le R4-l, siis R4 lisab sissekande:

Ja käivitatakse taimer, mille määramist R5 peab pidevalt PIM Join sõnumeid saatma, vastasel juhul R4 jätab selle väljamineku loendist välja. R5 saadab iga 60 PIM Join sõnumit.
Lühimaa puu vahetus.
Lisame R1 ja R5 vahele liidese ning vaatame, kuidas liiklus sellise topoloogia korral voolab.

Oletame, et liiklus saadeti ja saadi vana skeemi järgi R1-R2-R3-R4-R5 ning siis ühendame ja seadistame liidese R1 ja R5 vahel.
Esite, meil on uuendatud unicast-routed tabel R5-s ning nüüd saavutatakse võrk 192.168.1.0/24 R5 Gi0/2 kaudu. Nüüd, kui R5 saab multikaid Gi0/1 liidese kaudu, mõistab ta, et RPF reegel ei ole täidetud, seega oleks mõistlikum saada multikaid Gi0/2 kaudu. Ta peab RPT-st lahti ütlema ja looma lühema puu, mida nimetatakse lühimaks tee puuks (SPT). Selleks saadab ta Gi0/2 kaudu PIM Join sõnumi R1-le ja R1 hakkab saatma multikaid ka Gi0/2 kaudu. Nüüd peab R5 RPT-st lahti ütlema, et mitte saada kahte koopiat. Selleks saadab ta Prune sõnumi, näidates allika IP-aadressi ja lisades spetsiaalseBit - RPT-bit. See tähendab, et ei ole vaja mulle liiklust saata, mul on siin paremad puud. RP saadab samuti R1 suunas PIM Prune sõnumeid, kuid ei saada Register-Stop sõnumit. Veel üks eripära: R5 hakkab pidevalt saatma PIM Prune RP-le, kuna R1 saadab iga minuti tagant PIM Register RP-le. RP, kuni ei tule uusi huvilisi, nagu see liiklus, vastab talle keeldumisega. R5 teavitab RP-d, et ta jätkab multika saamist läbi SPT.
Dünaamiline RP otsing.
Auto-RP.
See tehnoloogia on Cisco omand ja ei ole eriti populaarne, kuid siiski on elujõuline. Auto-RP töö koosneb kahest põhietapist:
1) RP saadab RP-Announce sõnumeid reserveeritud aadressile 224.0.1.39, kuulutades end RP-ks kas kõigi või teatud gruppide jaoks. Sõnumit saadetakse iga minuti järel.
2) On vajalik RP mapping agent, mis saadab RP-Discovery sõnumeid, märkides, milliste gruppide jaoks peab konkreetne RP olema kuulatav. Just sellest sõnumist saavad tavalised PIM ruuterid oma RP-d määrata. Mapping Agent võib olla nii RP ruuter kui ka mõni eraldi PIM ruuter. RP-Discovery saadetakse aadressile 224.0.1.40 ühe minuti intervalliga.
Vaatame protsessi lähemalt:
Seadistame R3 RP-ks:

ip pim send-rp-announce loopback 0 scope 10

R2 kui mapping agent:

ip pim send-rp-discovery loopback 0 scope 10

Ja kõikidel teistel ootame RP-d läbi Auto-RP:

ip pim autorp listener

Niipea kui oleme R3 seadistanud, hakkab ta saatma RP-Announce:

Ja R2, pärast mapping agendiks seadmist, hakkab ootama RP-Announce sõnumeid. Alles siis, kui ta leiab vähemalt ühe RP, hakkab ta saatma RP-Discovery:

Seega, kui tavalised marsruutorid (PIM RP Listener) saavad selle teate, teavad nad, kust RP-d otsida.
Üks peamisi Auto-RP probleeme on see, et RP-Announce ja RP-Discovery sõnumite saamiseks peab saatma PIM Join aadressidele 224.0.1.39-40, kuid selleks, et saata, tuleb teada, kus RP paikneb. Klassikaline muna ja kana probleem. Selle probleemi lahendamiseks loodi PIM Sparse-Dense-Mode režiim. Kui marsruutor ei tea RP-d, töötab see tiheda režiimi (Dense-mode) režiimis, kui teab, siis hõredas režiimis (Sparse-mode). Kui tavaliste marsruutorite liidetes on seadistatud PIM Sparse-mode ja käsk ip pim autorp listener, siis töötab marsruutor tiheda režiimi ainult Auto-RP protokolli multikastiks (224.0.1.39-40).
BootStrap Router (BSR).
See funktsioon töötab sarnaselt Auto-RP-le. Iga RP saadab sõnumi mappimise agendile, kes kogub mappimise teavet ja edastab selle seejärel kõigile teistele marsruutoritele. Kirjeldame protsessi samamoodi nagu Auto-RP puhul:
1) Niipea kui seadistame R3 RP kandidaatideks, käsuga:

ip pim rp-candidate loopback 0

R3 ei tee midagi, et alustada spetsiifiliste sõnumite saatmist; selleks peab ta esmalt leidma mapping agent'i. Niisiis, liigume teise sammu juurde.
2) Seadistame R2 mapping agent'ina:

ip pim bsr-kandidaat loopback 0

R2 hakkab saatma PIM Bootstrap sõnumeid, kus ta määratleb end mapping agent'ina:

Sõnum saadetakse aadressile 224.0.0.13, mida PIM protokoll kasutab ka oma teiste sõnumite jaoks. Ta saadab neid igas suunas ja seetõttu ei esine kana ja muna probleemi, nagu see oli Auto-RP-s.
3) Kui RP saab sõnumi BSR ruuterilt, saadab ta kohe unicast sõnumi aadressile BSR ruuter:

Pärast seda saadab BSR, saades teavet RP kohta, need multikastina aadressile 224.0.0.13, mida kuulavad kõik PIM ruuterid. Seetõttu ei ole BSR-is analoogset käsku ip pim autorp listener tavalistele ruutereile.
Anycast RP koos Multicast Source Discovery Protocol'i (MSDP) abil.
Auto-RP ja BSR võimaldavad meil jagada koormust RP-le järgmiselt: igal multika grupil on ainult üks aktiivne RP. Ühe multika rühma jaoks ei saa koormust jagada mitme RP vahel. MSDP teostab selle, andes RP marsruuteritele sama IP-aadressi maskiga 255.255.255.255. MSDP kogub teavet ühe meetodi abil: staatika, Auto-RP või BSR.

Pildil on meil Auto-RP konfiguratsioon koos MSDP-ga. Mõlemad RP-d on seadistatud IP-aadressiga 172.16.1.1/32 Loopback 1 liidesel ja seda kasutatakse kõigi rühmade jaoks. RP-Announce'i ajal räägivad mõlemad marsruuterid endist, viidates sellele aadressile. Auto-RP mapping agent, saades teavet, levitab RP-Discovery teavet RP kohta aadressiga 172.16.1.1/32. Aadressi 172.16.1.1/32 kohta räägime marsruuteritele IGP kaudu. Seega küsivad või registreerivad PIM marsruuterid voogusid vastavalt sellele RP-le, mis on märgitud next-hop-ina marsruudile aadressile 172.16.1.1/32. MSDP protokoll on loodud RP-de jaoks, et vahetada teavet multika kohta.
Vaatleme järgmist topoloogiat:

Switch6 suunab liiklust aadressile 238.38.38.38 ja sellest teab praegu ainult RP-R1. Just sellepärast on Switch7 ja Switch8 selle grupi kohta pärinud. Ruuterid R5 ja R4 saadavad PIM Join R1 ja R3, vastavalt. Miks? R5 marsruut 13.13.13.13 suunab R1, kasutades IGP mõõdet, nagu R4 samuti.
RP-R1 teab voogust ja hakkab seda suunama R5 suunas, kuid R4 ei tea sellest midagi, kuna R1 ei kavatse seda lihtsalt nii saata. Seetõttu on vajalik MSDP. Seadistame selle R1 ja R5 peal:

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 loovad teineteise vahel seansi ja kui saavad mõne voolu, teavitavad nad sellest oma RP naabrile.
RP-R1 saadab kohe voolu saades Switch6-lt unicastiga MSDP Source-Active sõnumi, mis sisaldab teavet tüüpi ( S, G) — teavet allika ja multika sihtkoha kohta. Nüüd, kui RP-R3 teab, et selline allikas nagu Switch6 eksisteerib, saadab ta R4 taotluse korral sellele voole suunamise Switch6 suunas PIM Join, tuginedes marsruutimistabelile. Seega, kui R1 saab sellise PIM Join-i, hakkab ta liiklust saatma RP-R3 suunas.
MSDP töötab TCP protokollil, RP-de vahel saadetakse keepalive sõnumeid elujõulisuse kontrollimiseks. Taimer on 60 sekundit.
MSDP peeride jagamise funktsiooni erinevatesse domeenidesse jääb ebaselgeks, kuna keepalive ja SA sõnumites ei näidata kuulumist ühtegi domeeni. Samuti testiti selles topoloogias konfiguratsiooni erinevate domeenide määramisega - töödes ei olnud mingeid erinevusi.
Kui keegi suudab selgust tuua, oleksin rõõmus, kui loeksin kommentaarides.

Allikas: habr.com