Die PIM-protokol is 'n stel protokolle vir die oordrag van multicast in 'n netwerk tussen routers. Buurtverhoudings word op dieselfde manier gebou as in die geval van dinamiese roeteringsprotokolle. PIMv2 stuur Hallo-boodskappe elke 30 sekondes na die gereserveerde multicast-adres 224.0.0.13 (All-PIM-Routers). Die boodskap bevat Hou Timers - gewoonlik gelyk aan 3.5*Hallo Timer, dit wil sê 105 sekondes by verstek.
PIM gebruik twee hoofbedryfsmodusse - dig en yl modus. Kom ons begin met Dense-modus.
Brongebaseerde verspreidingsbome.
Dit is raadsaam om digmodusmodus te gebruik in die geval van 'n groot aantal kliënte van verskillende multicast-groepe. Wanneer 'n router multicast-verkeer ontvang, is die eerste ding wat dit doen om dit te kontroleer vir die RPF-reël. RPF - hierdie reël word gebruik om die bron van 'n multicast met 'n unicast-roeteringtabel na te gaan. Dit is nodig dat die verkeer by die koppelvlak kom waaragter hierdie gasheer versteek is volgens die weergawe van die unicast-roeteringtabel. Hierdie meganisme los die probleem op van 'n lus wat tydens multicast-transmissie voorkom.
R3 sal die multicast-bron (Bron IP) van die multicast-boodskap herken en die twee vloeie van R1 en R2 nagaan met behulp van sy unicast-tabel. Die stroom vanaf die koppelvlak waarna die tabel wys (R1 tot R3) sal verder versend word, en die stroom vanaf R2 sal laat val word, aangesien om by die multicast-bron te kom, moet jy pakkies via S0/1 stuur.
Die vraag is, wat gebeur as jy twee ekwivalente roetes met dieselfde metrieke het? In hierdie geval sal die router die volgende hop van hierdie roetes kies. Wie ook al die hoër IP-adres het, wen. As jy hierdie gedrag moet verander, kan jy ECMP gebruik. Meer besonderhede .
Nadat die RPF-reël nagegaan is, stuur die router 'n multicast-pakkie na al sy PIM-bure, behalwe vir die een van wie die pakkie ontvang is. Ander PIM-routers herhaal hierdie proses. Die pad wat 'n multicast-pakkie van die bron na die finale ontvangers geneem het, vorm 'n boom genaamd brongebaseerde verspreidingsboom, kortste padboom (SPT), bronboom. Drie verskillende name, kies enige een.
Hoe om die probleem op te los dat sommige routers nie opgegee het op een of ander multicast-stroom nie en daar is niemand om dit na te stuur nie, maar die stroomop-router stuur dit vir hom. Die Prune-meganisme is hiervoor uitgevind.
Snoei Boodskap.
Byvoorbeeld, R2 sal voortgaan om 'n multicast na R3 te stuur, hoewel R3, volgens die RPF-reël, dit laat val. Hoekom laai die kanaal? R3 stuur 'n PIM-snoeiboodskap en R2, by ontvangs van hierdie boodskap, sal koppelvlak S0/1 van die uitgaande koppelvlaklys vir hierdie vloei verwyder, die lys koppelvlakke waarvandaan hierdie verkeer gestuur moet word.
Die volgende is 'n meer formele definisie van 'n PIM Prune-boodskap:
Die PIM Prune-boodskap word deur een roeteerder na 'n tweede roeteerder gestuur om te veroorsaak dat die tweede roeteerder die skakel waarop die Pruimedant van 'n spesifieke (S,G) SPT ontvang word, verwyder.
Nadat die Snoei-boodskap ontvang is, stel R2 die Snoei-timer op 3 minute. Na drie minute sal dit weer verkeer begin stuur totdat dit nog 'n Prune-boodskap ontvang. Dit is in PIMv1.
En in PIMv2 is 'n State Refresh timer bygevoeg (60 sekondes by verstek). Sodra 'n snoeiboodskap vanaf R3 gestuur is, word hierdie tydhouer op R3 begin. Na verstryking van hierdie tydteller, sal R3 'n State Refresh-boodskap stuur, wat die 3-minute snoei-afteller op R2 vir hierdie groep sal terugstel.
Redes vir die stuur van 'n Pruimedant-boodskap:
- Wanneer 'n multicast-pakkie die RPF-kontrole misluk.
- Wanneer daar geen plaaslik gekoppelde kliënte is wat 'n multicast-groep (IGMP Join) versoek het nie en daar geen PIM-bure is na wie multicast-verkeer gestuur kan word nie (Non-prune Interface).
Graft Boodskap.
Kom ons verbeel ons dat R3 nie verkeer van R2 wou hê nie, vir Prune gestuur het en 'n multicast vanaf R1 ontvang het. Maar skielik het die kanaal tussen R1-R3 geval en R3 is sonder multicast gelaat. Jy kan 3 minute wag totdat die Snoei Timer op R2 verval. 3 minute is 'n lang wag, om nie te wag nie, moet jy 'n boodskap stuur wat hierdie S0/1-koppelvlak onmiddellik na R2 uit die gesnoeide toestand sal bring. Hierdie boodskap sal 'n Graft-boodskap wees. Nadat die Graft-boodskap ontvang is, sal R2 reageer met 'n Graft-ACK.
Snoei oorheersing.
Kom ons kyk na hierdie diagram. R1 saai multicast uit na 'n segment met twee routers. R3 ontvang en saai verkeer uit, R2 ontvang, maar het niemand om verkeer na uit te saai nie. Dit stuur 'n Prune-boodskap na R1 in hierdie segment. R1 behoort Fa0/0 van die lys te verwyder en op te hou om in hierdie segment uit te saai, maar wat sal met R3 gebeur? En R3 is in dieselfde segment, het ook hierdie boodskap van Prune ontvang en die tragedie van die situasie verstaan. Voordat R1 ophou uitsaai, stel dit 'n tydteller van 3 sekondes en sal na 3 sekondes ophou uitsaai. 3 sekondes - dit is presies hoeveel tyd R3 het om nie sy multicast te verloor nie. Daarom stuur R3 so gou moontlik 'n Pim Sluit aan-boodskap vir hierdie groep, en R1 dink nie meer daaraan om op te hou uitsaai nie. Oor Sluit aan by boodskappe hieronder.
Bevestig Boodskap.
Kom ons stel ons hierdie situasie voor: twee routers saai gelyktydig na een netwerk uit. Hulle ontvang dieselfde stroom vanaf die bron, en albei saai dit uit na dieselfde netwerk agter koppelvlak e0. Daarom moet hulle bepaal wie die enigste uitsaaier vir hierdie netwerk sal wees. Beweringsboodskappe word hiervoor gebruik. Wanneer R2 en R3 duplisering van multicast-verkeer bespeur, dit wil sê 'n multicast arriveer by R2 en R3, wat hulle self uitsaai, verstaan die routers dat hier iets fout is. In hierdie geval stuur routers Assert-boodskappe, wat Administratiewe Afstand en die roetemetriek waarmee die multicast-bron bereik word, insluit - 10.1.1.10. Die wenner word soos volg bepaal:
- Die een met laer AD.
- As AD gelyk is, wie het dan die onderste metrieke.
- As daar gelykheid hier is, dan is die een wat die hoër IP het in die netwerk waarheen hulle hierdie multicast uitsaai.
Die wenner van hierdie stemming word die aangewese router. Pim Hello word ook gebruik om DR's te kies. Aan die begin van die artikel is die PIM Hallo-boodskap gewys, jy kan die DR-veld daar sien. Die een met die hoogste IP-adres op hierdie skakel wen.
Nuttige teken:
MROUTE Tabel.
Na 'n aanvanklike blik op hoe die PIM-protokol werk, moet ons verstaan hoe om met 'n multicast-roeteringtabel te werk. Die mroute-tabel stoor inligting oor watter strome van kliënte aangevra is en watter strome vanaf multicast-bedieners vloei.
Byvoorbeeld, wanneer 'n IGMP-lidmaatskapverslag of PIM-aansluiting op een of ander koppelvlak ontvang word, word 'n rekord van tipe (*, G) by die roetetabel gevoeg:
Hierdie inskrywing beteken dat 'n verkeersversoek ontvang is met die adres 238.38.38.38. Die DC-vlag beteken dat die multicast in Digte-modus sal werk en C beteken dat die ontvanger direk aan die router gekoppel is, dit wil sê die router het die IGMP-lidmaatskapverslag en PIM-aansluiting ontvang.
As daar 'n rekord van tipe (S,G) is, beteken dit dat ons 'n multicast-stroom het:
In die S-veld - 192.168.1.11, het ons die IP-adres van die multicast-bron geregistreer, dit is dit wat deur die RPF-reël nagegaan sal word. As daar probleme is, is die eerste ding wat jy moet doen om die unicast-tabel na te gaan vir die roete na die bron. In die Inkomende Interface-veld, dui die koppelvlak aan waarheen die multicast ontvang word. In 'n unicast-roeteringtabel moet die roete na die bron verwys na die koppelvlak wat hier gespesifiseer word. Die uitgaande koppelvlak spesifiseer waarheen die multicast herlei sal word. As dit leeg is, het die router geen versoeke vir hierdie verkeer ontvang nie. Meer inligting oor alle vlae kan gevind word .
PIM Sparse-modus.
Die strategie van Sparse-modus is die teenoorgestelde van Digte-modus. Wanneer Sparse-modus multicast-verkeer ontvang, sal dit slegs verkeer deur daardie koppelvlakke stuur waar daar versoeke vir hierdie vloei was, byvoorbeeld Pim Join of IGMP Report-boodskappe wat hierdie verkeer versoek.
Soortgelyke elemente vir SM en DM:
- Buurtverhoudings word op dieselfde manier gebou as in PIM DM.
- Die RPF-reël werk.
- Die DR-keuse is soortgelyk.
- Die meganisme van Prune Overrides en Assert-boodskappe is soortgelyk.
Om te beheer wie, waar en watter soort multicast-verkeer op die netwerk benodig word, is 'n gemeenskaplike inligtingsentrum nodig. Ons sentrum sal Rendezvous Point (RP) wees. Enigeen wat 'n soort multicast-verkeer wil hê of iemand het multicast-verkeer vanaf die bron begin ontvang, dan stuur hy dit na RP.
Wanneer die RP multicast-verkeer ontvang, sal dit dit stuur na daardie routers wat voorheen hierdie verkeer versoek het.
Kom ons stel ons 'n topologie voor waar RP R3 is. Sodra R1 verkeer van S1 ontvang, omhul dit hierdie multicast-pakkie in 'n unicast PIM Register-boodskap en stuur dit na RP. Hoe weet hy wie die RP is? In hierdie geval is dit staties gekonfigureer, en ons sal later oor dinamiese RP-konfigurasie praat.
ip pim rp-adres 3.3.3.3
RP sal kyk - was daar inligting van iemand wat graag hierdie verkeer wil ontvang? Kom ons neem aan dit was nie. Dan sal RP vir R1 'n PIM Register-Stop boodskap stuur, wat beteken dat niemand hierdie multicast nodig het nie, registrasie word geweier. R1 sal nie multicast stuur nie. Maar die multicast-brongasheer sal dit stuur, sodat R1, na ontvangs van Register-Stop, 'n Register-Onderdrukking timer gelyk aan 60 sekondes sal begin. 5 sekondes voor hierdie tydteller verstryk, sal R1 'n leë Register-boodskap met 'n Nul-Register-bis (dit wil sê sonder 'n ingekapselde multicast-pakkie) na RP stuur. RP sal op sy beurt so optree:
- As daar geen ontvangers was nie, sal dit met 'n Register-Stop-boodskap reageer.
- Indien ontvangers verskyn, sal hy op geen manier daarop reageer nie. R1, wat nie 'n weiering om te registreer binne 5 sekondes ontvang het nie, sal gelukkig wees en 'n Register-boodskap met 'n ingekapselde multicast na RP stuur.
Dit lyk asof ons uitgepluis het hoe multicast RP bereik, kom ons probeer nou om die vraag te beantwoord oor hoe RP verkeer aan ontvangers lewer. Hier is dit nodig om 'n nuwe konsep bekend te stel - wortelpadboom (RPT). RPT is 'n boom wat in RP gewortel is, wat na die ontvangers toe groei en op elke PIM-SM-roeteerder vertak. RP skep dit deur PIM Sluit aan-boodskappe te ontvang en voeg 'n nuwe tak by die boom. En so, elke stroomaf router doen. Die algemene reël lyk soos volg:
- Wanneer 'n PIM-SM-roeteerder 'n PIM Sluit-boodskap ontvang op enige ander koppelvlak as die koppelvlak waaragter die RP versteek is, voeg dit 'n nuwe tak by die boom.
- 'n Tak word ook bygevoeg wanneer die PIM-SM-roeteerder 'n IGMP-lidmaatskapverslag van 'n direk gekoppelde gasheer ontvang.
Kom ons stel ons voor dat ons 'n multicast-kliënt op die R5-roeteerder vir groep 228.8.8.8 het. Sodra R5 die IGMP-lidmaatskapverslag van die gasheer ontvang, stuur R5 'n PIM-aansluiting in die rigting van die RP, en voeg self 'n koppelvlak by die boom wat na die gasheer kyk. Vervolgens ontvang R4 PIM Join vanaf R5, voeg koppelvlak Gi0/1 by die boom en stuur PIM Join in die rigting van RP. Laastens ontvang RP ( R3 ) PIM Join en voeg Gi0/0 by die boom. Dus is die multicast-ontvanger geregistreer. Ons bou 'n boom met die wortel R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0.
Hierna sal 'n PIM-aansluiting na R1 gestuur word en R1 sal multicast-verkeer begin stuur. Dit is belangrik om daarop te let dat indien die gasheer verkeer versoek het voordat die multicast-uitsending begin het, RP nie PIM Join sal stuur nie en glad nie enigiets na R1 sal stuur nie.
As die gasheer skielik, terwyl 'n multicast gestuur word, ophou om dit te wil ontvang, sodra RP 'n PIM Prune op die Gi0/0 koppelvlak ontvang, sal dit onmiddellik 'n PIM Register-Stop direk na R1 stuur, en dan 'n PIM Prune boodskap via die Gi0/1-koppelvlak. PIM Register-stop word via unicast gestuur na die adres waarvandaan die PIM Register gekom het.
Soos ons vroeër gesê het, sodra 'n router 'n PIM-aansluiting na 'n ander stuur, byvoorbeeld R5 tot R4, word 'n rekord by R4 gevoeg:
En 'n timer word begin dat R5 voortdurend hierdie tydteller PIM Sluit aan by boodskappe voortdurend moet terugstel, anders sal R4 uitgesluit word van die uitgaande lys. R5 sal elke 60 PIM Sluit aan-boodskappe stuur.
Kortste-pad-boom-omskakeling.
Ons sal 'n koppelvlak tussen R1 en R5 byvoeg en kyk hoe verkeer met hierdie topologie vloei.
Kom ons neem aan dat verkeer gestuur en ontvang is volgens die ou skema R1-R2-R3-R4-R5, en hier het ons die koppelvlak tussen R1 en R5 gekoppel en gekonfigureer.
Eerstens moet ons die unicast-roeteringtabel op R5 herbou en nou word die netwerk 192.168.1.0/24 bereik deur die R5 Gi0/2-koppelvlak. Nou verstaan R5, ontvang multicast op koppelvlak Gi0/1, dat die RPF reël nie bevredig is nie en dit sal meer logies wees om multicast op Gi0/2 te ontvang. Dit moet van RPT ontkoppel en 'n korter boom genaamd Shortest-Path Tree (SPT) bou. Om dit te doen, stuur hy PIM Join na R0 deur Gi2/1 en R1 begin om 'n multicast ook deur Gi0/2 te stuur. Nou moet R5 by RPT uitteken om nie twee kopieë te ontvang nie. Om dit te doen, stuur hy 'n boodskap aan Prune wat die bron-IP-adres aandui en 'n spesiale bietjie - RPT-bis - invoeg. Dit beteken dat jy nie vir my verkeer hoef te stuur nie, ek het 'n beter boom hier. RP stuur ook PIM Prune-boodskappe na R1, maar stuur nie 'n Register-Stop-boodskap nie. Nog 'n kenmerk: R5 sal nou voortdurend PIM Prune na RP stuur, aangesien R1 aanhou om PIM Register elke minuut na RP te stuur. Totdat daar geen nuwe mense is wat hierdie verkeer wil hê nie, sal RP dit weier. R5 stel RP in kennis dat hy voortgaan om multicast via SPT te ontvang.
Dinamiese RP-soektog.
Outo-RP.
Hierdie tegnologie is eie van Cisco en is nie besonder gewild nie, maar leef steeds. Auto-RP werking bestaan uit twee hoofstadia:
1) RP stuur RP-Announce boodskappe na die gereserveerde adres - 224.0.1.39, en verklaar homself RP óf vir almal óf vir spesifieke groepe. Hierdie boodskap word elke minuut gestuur.
2) 'n RP-karteringagent word vereis, wat RP-Discovery-boodskappe sal stuur wat aandui vir watter groepe na RP geluister moet word. Dit is uit hierdie boodskap dat gereelde PIM-routers die RP vir hulself sal bepaal. Die karteringagent kan óf die RP-roeteerder self óf 'n aparte PIM-roeteerder wees. RP-Discovery word gestuur na adres 224.0.1.40 met 'n timer van een minuut.
Kom ons kyk na die proses in meer detail:
Kom ons konfigureer R3 as RP:
ip pim stuur-rp-aankondig terugloop 0 omvang 10
R2 as karteringsagent:
ip pim stuur-rp-ontdekking teruglus 0 omvang 10
En op alle ander sal ons RP via Auto-RP verwag:
ip pim autorp luisteraar
Sodra ons R3 gekonfigureer het, sal dit RP-Announce begin stuur:
En R2, nadat die karteringsagent opgestel is, sal begin wag vir die RP-Announce-boodskap. Eers wanneer dit ten minste een RP vind, sal dit RP-Discovery begin stuur:
Sodra gereelde routers (PIM RP Listener) hierdie boodskap ontvang, sal hulle weet waar om die RP te soek.
Een van die hoofprobleme met Auto-RP is dat jy PIM Join na adresse 224.0.1.39-40 moet stuur om RP-Announce en RP-Discovery boodskappe te ontvang, en om te kan stuur, moet jy weet waar die RP is geleë. Klassieke hoender en eier probleem. Om hierdie probleem op te los, is die PIM Sparse-Dense-Mode uitgevind. As die router nie RP ken nie, werk dit in Digte-modus; indien wel, dan in Sparse-modus. Wanneer PIM Sparse-modus en die ip pim autorp luisteraar-opdrag op die koppelvlakke van gewone roeteerders gekonfigureer is, sal die roeteerder slegs in Digte-modus werk vir multicasting direk vanaf die Auto-RP-protokol (224.0.1.39-40).
BootStrap-roeteerder (BSR).
Hierdie funksie werk soortgelyk aan Auto-RP. Elke RP stuur 'n boodskap aan die karteringagent, wat karteringinligting insamel en dan vir alle ander routers vertel. Kom ons beskryf die proses soortgelyk aan Auto-RP:
1) Sodra ons R3 as 'n kandidaat konfigureer om RP te wees, met die opdrag:
ip pim rp-kandidaat teruglus 0
Dan sal R3 niks doen nie; om spesiale boodskappe te begin stuur, moet hy eers 'n karteringsagent kry. Dus gaan ons aan na die tweede stap.
2) Konfigureer R2 as 'n karteringsagent:
ip pim bsr-kandidaat teruglus 0
R2 begin PIM Bootstrap-boodskappe stuur, waar dit homself as 'n karteringsagent aandui:
Hierdie boodskap word na die adres 224.0.013 gestuur, wat die PIM-protokol ook vir sy ander boodskappe gebruik. Dit stuur hulle in alle rigtings en daarom is daar geen hoender-en-eierprobleem soos daar in Auto-RP was nie.
3) Sodra die RP 'n boodskap van die BSR router ontvang, sal dit onmiddellik 'n unicast boodskap na die BSR router adres stuur:
Daarna sal die BSR, nadat hy inligting oor die RP's ontvang het, dit per multicast stuur na die adres 224.0.0.13, waarna alle PIM-routers geluister word. Daarom 'n analoog van die opdrag ip pim autorp luisteraar vir gewone routers nie in BSR nie.
Anycast RP met Multicast Source Discovery Protocol (MSDP).
Auto-RP en BSR laat ons toe om die las op RP soos volg te versprei: Elke multicast-groep het slegs een aktiewe RP. Dit sal nie moontlik wees om die las vir een multicast-groep oor verskeie RP's te versprei nie. MSDP doen dit deur RP-routers dieselfde IP-adres met 'n masker van 255.255.255.255 uit te reik. MSDP leer inligting deur een van die metodes te gebruik: staties, Auto-RP of BSR.
In die prentjie het ons 'n Auto-RP-konfigurasie met MSDP. Beide RP's is gekonfigureer met IP-adres 172.16.1.1/32 op Loopback 1-koppelvlak en word vir alle groepe gebruik. Met RP-Announce kondig beide routers hulself aan deur na hierdie adres te verwys. Die Auto-RP kartering agent, nadat die inligting ontvang is, stuur RP-Discovery oor die RP met die adres 172.16.1.1/32. Ons vertel routers oor die netwerk 172.16.1.1/32 met behulp van IGP en dienooreenkomstig. Dus, PIM-roeteerders versoek of registreer vloei vanaf die RP wat gespesifiseer is as die volgende-hop op die roete na die netwerk 172.16.1.1/32. Die MSDP-protokol self is ontwerp vir die RP's self om boodskappe oor multicast-inligting uit te ruil.
Oorweeg hierdie topologie:
Switch6 saai verkeer uit na die adres 238.38.38.38 en tot dusver weet net RP-R1 daarvan. Switch7 en Switch8 het hierdie groep versoek. Roeteerders R5 en R4 sal PIM Join onderskeidelik na R1 en R3 stuur. Hoekom? Die roete na 13.13.13.13 vir R5 sal verwys na R1 deur die IGP-metriek te gebruik, net soos vir R4.
RP-R1 weet van die stroom en sal dit na R5 begin uitsaai, maar R4 weet niks daarvan nie, aangesien R1 dit nie sommer sal stuur nie. Daarom is MSDP nodig. Ons konfigureer dit op R1 en R5:
ip msdp eweknie 3.3.3.3 verbind-bron Loopback1 op R1
ip msdp eweknie 1.1.1.1 verbind-bron Loopback3 op R3
Hulle sal 'n sessie tussen mekaar opstel en wanneer hulle enige vloei ontvang, sal hulle dit aan hul RP-buurman rapporteer.
Sodra RP-R1 'n stroom van Switch6 ontvang, sal dit onmiddellik 'n unicast MSDP Source-Active boodskap stuur, wat inligting sal bevat soos (S, G) - inligting oor die bron en bestemming van die multicast. Noudat RP-R3 weet dat 'n bron soos Switch6, wanneer hy 'n versoek van R4 vir hierdie vloei ontvang, PIM Join na Switch6 sal stuur, gelei deur die roeteringtabel. Gevolglik sal R1 wat so 'n PIM-aansluiting ontvang het, verkeer na RP-R3 begin stuur.
MSDP loop oor TCP, RP's stuur mekaar lewendige boodskappe om lewendigheid te kontroleer. Die timer is 60 sekondes.
Die funksie om MSDP-eweknieë in verskillende domeine te verdeel, bly onduidelik, aangesien Keepalive- en SA-boodskappe nie lidmaatskap in enige domein aandui nie. In hierdie topologie het ons ook 'n konfigurasie getoets wat verskillende domeine aandui - daar was geen verskil in werkverrigting nie.
As iemand dit kan verduidelik, lees ek dit graag in die kommentaar.
Bron: will.com