PIM-protokolli tööpõhimõtted

PIM-protokoll on protokollide kogum, mis edastab multikaasti võrgus maršrutite vahel. Naabrussuhted luuakse samamoodi nagu dünaamiliste marsruutimisprotokollide puhul. PIMv2 saadab iga 30 sekundi järel Hello sõnumeid reserveeritud multikaadiga aadressile 224.0.0.13 (All-PIM-Routers). Sõnum sisaldab Hold Timers'i — tavaliselt 3.5 * Hello Timer, st vaikimisi 105 sekundit.

PIM kasutab kahte peamist töörežiimi — Dense ja Sparse mode. Alustame Dense mode'ist.
Allika-põhised jaotust koostised.
Dense-mode'i režiimi on mõistlik kasutada juhul, kui on palju kliente erinevates multikaasti gruppides. Kui maršutitor saab multikaasti liiklust, kontrollib ta kõigepealt RPF reeglit. RPF — see reegel kontrollib multikaasti allikat unikaadis marsruutimiste tabeli kaudu. Liiklus peab tulema sellele liidesele, mille taga on antud host, vastavalt unikaadile marsruutimiste tabelile. See mehhanism lahendab probleemid, mis võivad tekkida multikaasti edastamisel.

R3 saab multikaasti sõnumist teada allika (Source IP) ja kontrollib R1 ja R2 kahte voogu oma unikaadise marsruutimiste tabelis. Voog, mille liides on tabelis (R1 R3-le), edastatakse edasi, samas kui voog R2 hakatakse tagasi lükkama, kuna multikaasti allikani jõudmiseks tuleb pakette saata S0/1-elt.
Küsimus on, mis juhtub, kui teil on kaks ekvivalentset marsruuti ühe ja sama metrikaga? Sellisel juhul valib maršutitor järgmise sammu nende marsruutide vahel. Sellel, kellel on kõrgem IP-aadress, see ka võidab. Kui soovite seda käitumist muuta, saate kasutada ECMP-d. Täiendavad andmed siit.
Pärast RPF reegli kontrollimist saadab maršutitor multikaastpaketi kõigile oma PIM naabritele, välja arvatud sellele, kellelt see pakett saadi. Ülejäänud PIM maršutid kordavad seda protsessi. Tee, mille mööda multikaastpakett läks allikast lõppsaajateni, moodustab puu, mida nimetatakse — allika-põhiseks jaotuspuuks, lühim tee puu (SPT), allika puu. Kolm erinevat nime, valige ükskõik milline.
Kuidas lahendada probleem, kui mõned maršutid ei soovi mingit multikaasti voogu ja sellele ei ole kedagi edastada, kuid kõrgem maršutitor saadab seda? Selleks on välja mõeldud Prune mehhanism.
Prune Message.
Näiteks R2 jätkab R3-le multikaasti saatmist, kuigi R3 eemaldab selle RPF reegli tõttu. Miks koormata kanalit? R3 saadab PIM Prune sõnumi ja R2 eemaldab, saades selle sõnumi, S0/1 liidese (outgoing interface list) selle voogude jaoks, mille kaudu seda trafikut saata.

Järgmine on PIM Prune sõnumi formaalne määratlus:
PIM Prune sõnum saadetakse ühe ruuteri poolt teisele ruuterile, et sundida teist ruuterit eemaldama Prune'i saamise linki konkreetse (S,G) SPT-l.

Pärast Prune sõnumi vastuvõtmist seab R2 Prune taimeri 3 minutiks. Kolme minuti pärast hakkab see taas trafikut saatma, kuni ta ei saa uut Prune sõnumit. See toimub PIMv1-s.
PIMv2-s on lisatud State Refresh taimer (vaikimisi 60 sekundit). Niipea kui R3-lt on saadetud Prune sõnum, käivitatakse selle taimer R3-l. Taimeri möödumisel saadab R3 State Refresh sõnumi, mis nullib R2-l 3-minutilise Prune taimeri selle grupi jaoks.
Põhjused Prune sõnumi saatmiseks:

• Kui multikaasti pakett ei läbinud RPF kontrolli.
• Kui pole kohapeal ühendatud kliente, kes on palunud multikaasti gruppi (IGMP Join) ja pole PIM naabreid, kellele võiks multikaasti trafikut saata (Non-prune Interface).

Graft sõnum.
Kujutame ette, et R3 ei soovinud R2-lt trafikut, saatis Prune'i ja sai multikaasti R1-lt. Kuid järsku kukkus R1-R3 vaheline kanal ja R3 jäi multikaastita. Saame oodata 3 minutit, kuni R2-l Prune taimer lõpeb. 3 minutit on kaua oodata, et mitte oodata, on vajalik saata sõnum, mis kohe eemaldab liidese S0/1 R2-l pruned olekust. Selline sõnum on Graft sõnum. Pärast Graft sõnumi vastuvõtmist saadab R2 vastuseks Graft-ACK.
Prune Override.

Vaadake seda skeemi. R1 edastab multicast'i kahe ruuteri segmendisse. R3 vastuvaidab ja edastab liiklust, R2 saab liiklust, kuid tal ei ole kedagi, kes edastaks. Ta saadab Prune sõnumi R1-le antud segmendis. R1 peab eemaldama Fa0/0 nimekirjast ja lõpetama edastamise antud segmendis, kuid mis saab R3-st? R3 asub samas segmendis, sai samuti selle Prune sõnumi ja mõistis olukorra tõsidust. Enne kui R1 lõpetab edastamise, seadistab ta taimeri 3 sekundiks ja lõpetab edastamise kolme sekundi pärast. 3 sekundit — just nii palju aega on R3-l, et mitte kaotada oma multicast'i. Seetõttu saadab R3 võimalikult kiiresti Pim Join sõnumi selle rühma jaoks ja R1 ei mõtle enam edastamise lõpetamisele. Join sõnumite kohta allpool.
Assert sõnum.

Kujutage ette olukorda: ühte võrku edastavad korraga kaks ruuterit. Nad saavad sama voolu allikast ja mõlemad edastavad seda ühte võrku e0 liidese kaudu. Seetõttu peavad nad kindlaks tegema, kes on selle võrgu ainus edastaja. Selleks kasutatakse Assert sõnumeid. Kui R2 ja R3 tuvastavad multicast-traffiku dubleerimise, st R2-le ja R3-le jõuab multicast, mida nad ise edastavad, mõistavad ruuterid, et midagi on valesti. Ruuterid saadavad sellisel juhul Assert sõnumeid, milles on kasutatud Administrative Distance ja marsruutimise meetrika, mille abil jõutakse multicast'i allikani — 10.1.1.10. Võitja määratakse järgmiselt:

1. See, kellel on madalam AD.
2. Kui AD-d on võrdsed, siis see, kellel on madalam meetrika.
3. Kui ka siin on võrdsus, siis see, kellel on kõrgem IP võrku, kuhu nad seda multicast'i edastavad.

Selles hääletuses võitnud ruuterist saab Designated Router. DR valimiseks kasutatakse samuti Pim Hello. Artikli alguses näidatud PIM Hello sõnumis on DR väli. Võidab see, kelle IP-aadress on sellel lingil kõrgem.
Kasulik tabel:

MROUTE tabel.
Pärast PIM protokolli töö esialgset kaalumist peame aru saama, kuidas töötada multicast marsruutimise tabeliga. mroute tabelis hoitakse teavet selle kohta, milliseid vooge on kliendid taotlenud ja millised vood tulevad multicast serveritest.
Näiteks, kui mõnel liidesel saadakse IGMP Membership Report või PIM Join, lisatakse marsruutimistabelisse kirje tüüpi ( *, G ):

See märge tähendab, et on saabunud päring liiklusele aadressilt 238.38.38.38. Lipp DC tähendab, et multicasting töötab tihedas režiimis (Dense mode) ja C tähendab, et saaja on otseselt ühendatud ruuteriga, st ruuter sai IGMP liikmesuse raporti ning PIM Joini.
Kui on olemas (S,G) tüüpi märge, tähendab see, et meil on multicasting voog:

Väljal S — 192.168.1.11, on meil määratud multicasting allika IP-aadress, mida kontrollitakse RPF reegliga. Probleemide korral tuleks kõigepealt kontrollida unikaalset tabelit allika marsruudi osas. Väljal Incoming Interface on näidatud liides, kuhu multicasting saabub. Unikaalses marsruutimistabelis peab marsruut allikale viitama siin näidatud liidesele. Väljal Outgoing Interface on näidatud, kuhu multicasting suunatakse. Kui see on tühi, tähendab, et ruuterile ei ole selle liikluse osas saadetud päringuid. Üksikasjalikku teavet kõikide lippude kohta saab leida. siin.
PIM Sparse-mode.
Sparse-mode strateegia on vastupidine Dense-mode'ile. Kui Sparse-mode saab multicasting liiklust, saadab ta liiklust ainult nendele liidesele, kus on olnud päringud selle voogudega, näiteks Pim Join või IGMP Report sõnumid, mis esitavad selle liikluse päringu.
SM ja DM sarnased elemendid:

• Naabrite suhted moodustatakse samuti nagu PIM DM-is.
• Kehtib RPF reegel.
• DR valik on sarnane.
• Prune Overrides mehhanism ja Assert sõnumid on sarnased.

Selleks, et kontrollida, kellele, kus ja millist multicasting liiklust on võrgu tarvis, on vajalik ühine infokeskus. Selliseks keskuseks on Rendezvous Point (RP). Kõik, kes soovivad mingit multicasting liiklust või kes hakkavad saama multicasting liiklust allikast, saadavad selle RP-le.
Kui RP saab multicasting liiklust, saadab ta selle ruuteritele, kes on enne seda liiklust küsinud.

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

ip pim rp-address 3.3.3.3

RP vaatab — kas oli teavet kelleltki, kes soovis seda liiklust saada? Oletame, et ei olnud. Siis saadab RP R1-le teate PIM Register-Stop, mis tähendab — keegi ei vaja seda multicast'i, registreerimine on tagasi lükatud. R1 ei saadeta multicast'i. Kuid multicast'i allikas saadab selle siiski, nii et R1, pärast Register-Stop'i saamist, käivitab Register-Suppression timer, mille pikkus on 60 sekundit. 5 sekundit enne selle taimeri aegumist, saadab R1 tühja Register teate Null-Register bit'iga (st ilma kapseldatud multicast paketi) RP suunas. RP käitub järgmiselt:

• Kui saajaid ei olnud, siis ta vastab Register-Stop teatega.
• Kui saajad ilmuvad, siis ta ei vasta sellele. R1, saamata oma registreerimisele 5 sekundi jooksul tagasi lükkamist, rõõmustab ja saadab Register teate kapseldatud multicast'iga RP suunas.

Kuidas multicast jõuab RP-ni, paistab olevat selge, nüüd proovime vastata küsimusele, kuidas RP toimetab liikluse saajateni. Siin on vaja tutvustada uut mõistet — root-path tree (RPT). RPT on puud, mille juur on RP, kasvab saajate suunas, hargnedes igal PIM-SM ruuteril. RP loob selle, saades PIM Join teateid ja lisab puusse uue oksa. Ja nii teeb iga alamruuter. Üldine reegel näeb välja järgmiselt:

• Kui PIM-SM ruuter saab PIM Join teate mõnel liidesel, välja arvatud liides, mille taha RP varjunud on, siis ta lisab puusse uue oksa.
• Oks lisatakse ka siis, kui PIM-SM ruuter saab IGMP Membership Report'it otse ühendatud hostilt.

Kujutame ette, et meil on multicast klient ruuteri R5 juures grupis 228.8.8.8. Kui R5 saab IGMP Membership Report'i hostilt, saadab R5 PIM Join'i RP suunas ja lisab puusse liidese, mis vaatab hosti poole. Edasi, R4 saab R5-lt PIM Join'i, lisab puusse liidese Gi0/1 ja saadab PIM Join'i RP suunas. Lõpuks saab RP (R3) PIM Join'i ja lisab Gi0/0 puusse. Nii toimub multicast saaja registreerimine. Meil tekib puu juurega R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0.
Pärast seda saadetakse R1-le PIM Join ja R1 hakkab saatma multikaust liiklust. Oluline on märkida, et kui host küsib liiklust enne kui multikaust hakkab edastama, siis RP ei saada PIM Join'i ega edasta midagi R1 suunas.
Kui äkki multikaustatoimetamise ajal ei soovi host seda enam vastu võtta, siis niipea kui RP saab PIM Prune sõnumi liideselt Gi0/0, saadab ta kohe PIM Register-Stop'i R1-le ja seejärel PIM Prune sõnumi liideselt Gi0/1. PIM Register-Stop saadetakse unicastiga sellele aadressile, kust tuli PIM Register.
Nagu me varem rääkisime, niipea kui ruuter saadab PIM Join teisele, näiteks R5-le R4-l, lisatakse R4-le kirje:

Ja käivitub taimer, mille jooksul R5 peab pidevalt saatma PIM Join sõnumeid, vastasel korral R4 eemaldab selle väljuvate nimekirjast. R5 saadab iga 60 sekundi tagant PIM Join sõnumeid.
Lühima tee puu vahetus.
Lisame liidese R1 ja R5 vahele ning vaatame, kuidas liiklus sellises topoloogias voolab.

Oletame, et liiklus liikus ja saadi vana skeemi R1-R2-R3-R4-R5 kaudu ja nüüd oleme lisanud ja seadistanud liidese R1 ja R5 vahel.
Esimene samm on see, et unicast marsruudi tabel R5-s rekonstrueeritakse ja nüüd on võrk 192.168.1.0/24 saavutatav R5 liidese Gi0/2 kaudu. Nüüd, kui R5 saab multikaust liiklust liideselt Gi0/1, mõistab ta, et RPF reegel ei rahuldata ja multikaust oleks mõistlikum saada Gi0/2 kaudu. Ta peab RPT-st lahti ütlema ja ehitama lühema puu, mida nimetatakse lühima tee puuks (SPT). Selleks saadab ta Gi0/2 kaudu PIM Join R1-le ja R1 hakkab saatma multikaust ka Gi0/2 kaudu. Nüüd peab R5 RPT-st lahti ütlema, et mitte saada kahte koopiat. Selleks saadab ta Prune sõnumi, märkides allika IP-aadressi ja lisades spetsiaalse biti — RPT-bit. See tähendab, et ärge saatke mulle liiklust, mul on parem puu. RP saadab samuti R1 suunas PIM Prune sõnumeid, kuid ei saada Register-Stop sõnumit. Veel üks omadus: R5 hakkab pidevalt saatma PIM Prune RP-le, kuna R1 jätkab PIM Register'i saatmist RP-le iga minuti tagant. RP vastab tema taotlustele keeldumisega, kuni uusi huvilisi ei ole. R5 teavitab RP-d, et ta jätkab multikaust liikluse saamist läbi SPT.
Dünaamiline RP otsing.
Auto-RP.
See tehnoloogia on Cisco'i poolt omandatud 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õnum saadetakse iga minuti tagant.
2) On vajalik RP mapping agent, mis saadab RP-Discovery sõnumeid, märkides, milliste gruppide jaoks milline RP kuulata tuleb. Just sellest sõnumist määrab tavapärased PIM ruuteriid endale RP. Mapping Agent võib olla kas RP ruuter ise või mõni eraldi PIM ruuter. RP-Discovery saadetakse aadressile 224.0.1.40 ühes minutis.
Vaadakem 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 Auto-RP kaudu:

ip pim autorp listener

Niipea kui me R3 seadistame, hakkab ta saatma RP-Announce:

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

Nii saavad tavalised ruuterid (PIM RP Listener) teada, kust RP-d otsida, kui nad saavad selle sõnumi.
Üks peamisi Auto-RP probleeme on see, et RP-Announce ja RP-Discovery sõnumite saamiseks tuleb saata PIM Join aadressidele 224.0.1.39-40, aga selleks, et saata, peab teadma, kus RP asub. Klassikaline kana ja muna probleem. Selle probleemi lahendamiseks töötati välja PIM Sparse-Dense-Mode režiim. Kui ruuter ei tea RP-d, töötab ta Dense-mode režiimis, ja kui teab, siis Sparse-mode režiimis. Kui tavaruuterite liidetes on seadistatud PIM Sparse-mode ja käsk ip pim autorp listener, hakkab ruuter Dense-mode tööle ainult Auto-RP protokolli multicast jaoks (224.0.1.39-40).
BootStrap Router (BSR).
See funktsioon töötab sarnaselt Auto-RP-le. Iga RP saadab sõnumi mapping agent-le, kes kogub mappimise teavet ja räägib edasi kõikidele teistele ruuteritele. Kirjeldame protsessi sarnaselt Auto-RP-le:
1) Kui oleme seadistanud R3 RP kandidaadina, käsuga:

ip pim rp-candidate loopback 0

Siis ei tee R3 midagi, et alustada spetsiaalsete sõnumite saatmist, peab ta kõigepealt leidma mapping agent-i. Nii et liigume teise sammu juurde.
2) Seadistame R2 mapping agent-iks:

ip pim bsr-candidate loopback 0

R2 hakkab saatma PIM Bootstrap sõnumeid, kus määratleb end kaardistamisagendina:

See sõnum saadetakse aadressile 224.0.0.13, mida PIM protokoll kasutab ka teiste oma sõnumite jaoks. See saadab neid igas suunas ja seega ei ole kana ja muna probleemi, nagu Auto-RP puhul.
3) Niipea kui RP saab sõnumi BSR ruuterilt, saadab ta kohe unikaalse sõnumi BSR ruuteri aadressile:

Pärast seda, kui BSR on saanud teavet RP kohta, saadab ta selle mängehngua multicastina aadressile 224.0.0.13, mida kuulavad kõik PIM ruuterid. Seega, BSR-is pole korraldust ip pim autorp listener tavalisetele ruuteritele.
Anycast RP koos Multicast Source Discovery Protocol (MSDP) abil.
Auto-RP ja BSR võimaldavad meil jaotada koormust RP-dele järgmiselt: Igal multicast grupil on ainult üks aktiivne RP. Ühe multicast grupi jaoks ei saa koormust jaotada mitme RP vahel. MSDP teeb seda, andes RP ruuteritele sama ip-aadressi maskiga 255.255.255.255. MSDP saab teavet ühtede meetodite kaudu: 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 liidesele ja seda kasutatakse kõigi gruppide jaoks. RP-Announce käigus räägivad mõlemad ruuterid endast, viidates sellele aadressile. Auto-RP kaardistamisagent, saades teavet, levitab RP-Discovery RP-st aadressiga 172.16.1.1/32. Ruuteritele räägime 172.16.1.1/32 võrgu kohta IGP kaudu. Seega, PIM ruuterid küsivad või registreerivad vooge, mille RP on määratud kui järgmine samm 172.16.1.1/32 võrgu Marsruudil. MSDP protokoll on mõeldud RP-dele, et jagada teavet multicastide kohta.
Vaatame sellist topoloogiat:

Switch6 levitab liiklust aadressil 238.38.38.38 ja selle kohta teab seni vaid RP-R1. Nüüd Switch7 ja Switch8 on selle grupi kohta taotluse esitanud. Ruuterid R5 ja R4 saadavad PIM Join R1 ja R3, vastavalt. Miks? Marsruut aadressini 13.13.13.13 R5-l viitab R1-le IGP meetriga, nagu ka R4-l.
RP-R1 teab voogust ja hakkab seda R5 suunas levitama, kuid R4 ei tea sellest midagi, kuna R1 ei saada seda lihtsalt. Seega on MSDP vajalik. Seame selle üles R1-l ja R5-l:

ip msdp peer 3.3.3.3 connect-source Loopback1 R1-l

ip msdp peer 1.1.1.1 connect-source Loopback3 R3-l

Need loovad omavahel seansi ja sõnumi saamisel edastavad nad teavet oma RP naabrile.
RP-R1, kui see saab voolu Switch6-lt, saadab kohe unicastiga MSDP Source-Active sõnumi, kus on teave tüüp (S, G) — teave allika ja multicast sihtkoha kohta. Nüüd, kui RP-R3 teab, et selline allikas nagu Switch6 eksisteerib, saadab ta, saades päringu R4-lt selle voolu kohta, Switch6 suunas PIM Join, tuginedes marsruutimistabelile. Seetõttu, kui R1 saab sellise PIM Join sõnumi, hakkab see suunama liiklust RP-R3 poole.
MSDP töötab TCP põhjal, RP saadavad üksteisele keepalive sõnumeid elujõulisuse kontrollimiseks. Ajastustsükkel on 60 sekundit.
MSDP peeride jagamise funktsioon erinevatesse domeenidesse jääb ebaselgeks, kuna Keepalive ja SA sõnumites ei näidata kuulumist ühtegi domeeni. Samuti testiti antud topoloogias konfigureerimist erinevate domeenide määramisega — tööprotsessis ei olnud erinevusi.
Kui keegi suudab selgust tuua, loen hea meelega kommentaarides.

Allikas: habr.com