PIM-protokollen er et sett med protokoller for overfÞring av multicast i nettverk mellom rutere. Nabo-relasjoner bygges pÄ en lignende mÄte som i tilfellet med dynamiske rutingsprotokoller. PIMv2 sender hver 30. sekund Hello-meldinger til den reserverte multicast-adressen 224.0.0.13 (All-PIM-Routers). Meldingen inneholder Hold Timers - vanligvis lik 3,5 ganger Hello Timer, det vil si 105 sekunder som standard.
PIM bruker to hoveddriftsmoduser - Dense og Sparse mode. La oss begynne med Dense mode.
Source-Based Distribution Trees.
Dense-mode-modusen er hensiktsmessig Ä bruke i tilfelle et stort antall kunder fra forskjellige multicast-grupper. NÄr ruteren mottar multicast-trafikk, sjekker den fÞrst denne mot RPF-regelen. RPF - denne regelen brukes for Ä sjekke kilden til multicast mot unicast-ruting-tabellen. Trafikken mÄ komme inn pÄ det grensesnittet hvor verten er skjult i henhold til unicast-ruting-tabellen. Denne mekanismen lÞser problemet med loop-dannelse ved overfÞring av multicast.
R3 fra multicast-meldingen finner ut kilden til multicast (Source IP) og sjekker to strÞmmer fra R1 og R2 i sin unicast-ruting-tabell. StrÞmmen fra det grensesnittet som tabellen peker til (R1 til R3) vil bli sendt videre, mens strÞmmen fra R2 vil bli droppet, siden for Ä nÄ multicast-kilden mÄ pakker sendes via S0/1.
Hva skjer hvis du har to ekvivalente ruter med samme metrik? I sÄ fall vil ruteren velge basert pÄ next-hop for disse rutene. Den med hÞyest IP-adresse vinner. Hvis det er nÞdvendig Ä endre denne oppfÞrselen, kan ECMP brukes. Mer informasjon. .
Etter Ă„ ha sjekket RPF-regelen sender ruteren multicast-pakken til alle sine PIM-naboer, unntatt den som pakken ble mottatt fra. De andre PIM-ruteren gjentar denne prosessen. Stien som multicast-pakken fĂžlger fra kilde til sluttmottakere danner et tre som kalles - source-based distribution tree, shortest-path tree (SPT), source tree. Tre forskjellige navn, velg ett.
Hvordan lĂžse problemet med at noen rutere ikke fikk en viss multicast-strĂžm og ingen sender til den, men en overordnet ruter sender den. For dette ble Prune-mekanismen oppfunnet.
Prune Message.
For example, R2 will continue to send multicast to R3, although R3 drops it according to the RPF rule. Why overload the channel? R3 sends a PIM Prune Message, and upon receiving this message, R2 will remove interface S0/1 from the outgoing interface list for this stream, which is the list of interfaces from which this traffic should be sent.
The following is a more formal definition of a PIM Prune message:
The PIM Prune message is sent by one router to a second router to cause the second router to remove the link on which the Prune is received from a particular (S,G) SPT.
After receiving the Prune message, R2 sets the Prune timer to 3 minutes. After three minutes, it will start sending traffic again until it receives another Prune message. This is in PIMv1.
In PIMv2, a State Refresh timer has been added (default 60 seconds). Once a Prune message is sent from R3, this timer starts on R3. After the timer expires, R3 will send a State Refresh message, which will reset the 3-minute Prune Timer on R2 for this group.
Reasons for sending a Prune message:
- When a multicast packet fails the RPF check.
- When there are no locally connected clients that have requested the multicast group (IGMP Join) and there are no PIM neighbors to which multicast traffic can be sent (Non-prune Interface).
Graft Message.
Imagine that R3 didn't want traffic from R2, sent a Prune, and was receiving multicast from R1. But suddenly, the link between R1 and R3 went down, and R3 was left without multicast. You can wait 3 minutes for R2's Prune Timer to expire. Waiting 3 minutes is too long; to avoid that, you need to send a message that will immediately take interface S0/1 on R2 out of the pruned state. This message is the Graft message. After receiving the Graft message, R2 will send back a Graft-ACK.
Prune Override.
La oss se pĂ„ denne ordningen. R1 sender multicast til segmentet med to rutere. R3 mottar og sender trafikk videre, mens R2 mottar, men har ingen Ă„ sende trafikk til. Han sender en Prune-melding til R1 i dette segmentet. R1 mĂ„ fjerne Fa0/0 fra listen og slutte Ă„ sende til dette segmentet, men hva skjer med R3? R3 er i det samme segmentet, har ogsĂ„ mottatt denne Prune-meldingen og forstĂ„r alvoret i situasjonen. FĂžr R1 slutter Ă„ sende, setter han en timer pĂ„ 3 sekunder og vil slutte Ă„ sende etter 3 sekunder. 3 sekunder â det er tiden R3 har for Ă„ unngĂ„ Ă„ miste sitt multicast. SĂ„ R3 sender sĂ„ raskt som mulig en Pim Join-melding for denne gruppen, og R1 tenker ikke lenger pĂ„ Ă„ slutte Ă„ sende. Om Join-meldinger nedenfor.
Assert-melding.
La oss forestille oss en situasjon: to rutere sender til samme nettverk. De mottar samme strĂžm fra kilden, og begge sender den til ett nettverk via grensesnittet e0. Derfor mĂ„ de avgjĂžre hvem som skal vĂŠre den eneste senderen for dette nettverket. Dette gjĂžres ved hjelp av Assert-meldinger. NĂ„r R2 og R3 oppdager duplisering av multicast-trafikk, det vil si nĂ„r R2 og R3 mottar multicast som de selv sender, forstĂ„r rutere at noe er galt. I dette tilfellet sender rutere Assert-meldinger som inkluderer Administrative Distance og metrikken til ruten som brukes for Ă„ nĂ„ multicast-kilden â 10.1.1.10. Vinneren bestemmes slik:
- Den med lavere AD.
- Hvis AD er like, sÄ den med lavere metrik.
- Hvis det ogsÄ er likhet, sÄ den med hÞyere IP i nettverket de sender denne multicasten til.
Den som vinner denne avstemningen, blir Designated Router. For Ä velge DR brukes ogsÄ Pim Hello. I begynnelsen av artikkelen ble PIM Hello-meldingen vist, hvor DR-feltet kan observeres. Den med hÞyere IP-adresse pÄ denne linken vinner.
Nyttig tabell:
MROUTE-tabellen.
Etter Ä ha sett pÄ hvordan PIM-protokollen fungerer, mÄ vi forstÄ hvordan man arbeider med multicast-ruteforholdet. I mroute-tabellen lagres informasjon om hvilke strÞmmer som har blitt forespurt fra klientene og hvilke strÞmmer som strÞmmer fra multicast-serverne.
For eksempel, nÄr IGMP Membership Report eller PIM Join mottas pÄ et grensesnitt, legges en oppfÞring av typen (*, G) til rutetabellen:
Denne oppfĂžrselen betyr at det har blitt mottatt en forespĂžrsel om trafikk fra adressen 238.38.38.38. Flagget DC indikerer at multicast vil fungere i Dense mode, og C betyr at mottakeren er direkte tilkoblet ruteren, det vil si at ruteren har mottatt IGMP Membership Report, og PIM Join.
Hvis det finnes en oppfĂžring av typen (S,G) betyr det at vi har en multicast-strĂžm:
I feltet S â 192.168.1.11, har vi oppgitt IP-adressen til multicast-kilden, og det er denne som vil bli verifisert av RPF-regelen. Ved problemer mĂ„ vi fĂžrst sjekke unicast-tabellen for ruten til kilden. I feltet Incoming Interface angir man grensesnittet som multicast mottas pĂ„. I unicast-rutingtabellen mĂ„ ruten til kilden peke til grensesnittet som er spesifisert her. I Outgoing Interface angir man hvor multicast vil bli viderefĂžrt. Hvis det er tomt, betyr det at ingen forespĂžrsel om denne trafikken har kommet til ruteren. Mer detaljert informasjon om alle flagg kan finnes .
PIM Sparse-mode.
Strategy Sparse-mode er motsatt av Dense-mode. NĂ„r Sparse-mode mottar multicast-trafikk, vil det sende trafikken kun gjennom de grensesnittene hvor det har vĂŠrt forespĂžrsel om denne strĂžmmen, som Pim Join eller IGMP Report-meldinger med forespĂžrsel om denne trafikken.
Lignende elementer i SM og DM:
- Nabolagsforhold opprettes pÄ samme mÄte som i PIM DM.
- RPF-regelen fungerer.
- Valget av DR er likt.
- Mechanismen Prune Overrides og Assert-meldinger er sammenlignbare.
For Ă„ kontrollere hvem, hvor og hvilken multicast-trafikk som er nĂždvendig i nettverket, er det nĂždvendig med et felles informasjonsknutepunkt. Dette knutepunktet vil vĂŠre Rendezvous Point (RP). Alle som Ăžnsker multicast-trafikk eller som begynner Ă„ motta multicast-trafikk fra kilden, sender det til RP.
NĂ„r RP mottar multicast-trafikk, vil det sende det til de ruterne som tidligere har forespurt denne trafikken.
La oss anta en topologi der RP er R3. SĂ„ snart R1 mottar trafikk fra S1, vil det kapsle inn denne multicast-pakken i en unicast PIM Register-melding og sende den til RP. Hvordan vet den hvem RP er? I dette tilfellet er den konfigurert statisk, og vi skal snakke om dynamisk konfigurasjon av RP senere.
ip pim rp-address 3.3.3.3
RP vil se â om det var informasjon fra noen som ville ha fĂ„tt denne trafikken? La oss anta at det ikke var det. Da vil RP sende R1 en melding om PIM Register-Stop, som betyr â ingen trenger denne multicast, registreringen er avvist. R1 vil ikke sende multicast. Men kilden for multicast vil sende det, sĂ„ R1, etter Ă„ ha mottatt Register-Stop, vil starte en Register-Suppression timer som er 60 sekunder. Fem sekunder fĂžr denne timeren utlĂžper, vil R1 sende en tom Register-melding med Null-Register bit (det vil si uten innkapslet multicast-pakke) mot RP. RP vil pĂ„ sin side handle slik:
- Hvis mottakere ikke har vĂŠrt til stede, vil den svare med ett Register-Stop-melding.
- Hvis mottakere dukker opp, vil den ikke svare pÄ den. R1, som ikke mottar avslag pÄ registreringen sin innen 5 sekunder, vil vÊre glad og sende en Register-melding med innkapslet multicast til RP.
Vi har forstĂ„tt hvordan multicast nĂ„r RP, nĂ„ skal vi prĂžve Ă„ svare pĂ„ spĂžrsmĂ„let om hvordan RP leverer trafikken til mottakerne. Her er det nĂždvendig Ă„ introdusere et nytt begrep â root-path tree (RPT). RPT er et tre med roten i RP, vokser mot mottakerne og forgrener seg ved hver PIM-SM-ruteren. RP oppretter det ved Ă„ motta PIM Join-meldinger og legger til en ny gren i treet. Og slik gjĂžr hver nedre ruter.
- NÄr en PIM-SM-ruter mottar en PIM Join-melding pÄ hvilken som helst grensesnitt, unntatt grensesnittet der RP skjuler seg, legger han til en ny gren i treet.
- En gren legges ogsÄ til nÄr en PIM-SM-ruter mottar en IGMP Membership Report fra en direkte tilkoblet vert.
La oss anta at vi har fĂ„tt en multicast-klient pĂ„ ruteren R5 for gruppen 228.8.8.8. SĂ„ snart R5 mottar en IGMP Membership Report fra verten, sender R5 PIM Join mot RP, og legger selv til grenen som peker mot verten i treet. Deretter mottar R4 PIM Join fra R5, legger til grenen Gi0/1 i treet og sender PIM Join mot RP. Til slutt mottar RP (R3) PIM Join og legger Gi0/0 til treet. Dermed oppnĂ„r vi registrering av multicast-mottakeren. Vi fĂ„r et tre med roten R3-Gi0/0 â R4-Gi0/1 â R5-Gi0/0.
Etter dette vil PIM Join bli sendt til R1, og R1 vil begynne Ă„ sende multicast-trafikk. Det er viktig Ă„ merke seg at hvis verten har bedt om trafikk fĂžr multicast-sendingen begynte, vil RP ikke sende PIM Join og vil generelt ikke sende noe til R1.
Hvis verten plutselig slutter Ä ville motta multicast mens det sendes, sÄ snart RP mottar PIM Prune pÄ grensesnitt Gi0/0, vil den umiddelbart sende PIM Register-Stop direkte til R1, og deretter PIM Prune-meldingen via grensesnitt Gi0/1. PIM Register-Stop sendes unicast til den adressen som mottok PIM Register.
Som vi nevnte tidligere, sÄ snart ruteren sender PIM Join til en annen, for eksempel R5 pÄ R4, legges det til en post pÄ R4:
Og en timer settes i gang, slik at R5 kontinuerlig mÄ sende PIM Join-meldinger for Ä unngÄ at R4 ekskluderer fra utgÄende liste. R5 vil sende PIM Join-meldinger hvert 60. sekund.
Shortest-Path Tree Switchover.
Vi vil legge til et grensesnitt mellom R1 og R5, og se hvordan trafikken vil flyte i en slik topologi.
Anta at trafikken ble sendt og mottatt etter det gamle mÞnsteret R1-R2-R3-R4-R5, og sÄ koblet vi til og konfigurerte et grensesnitt mellom R1 og R5.
FĂžrst vil unicast-rutingstabellen pĂ„ R5 bli ombygd, og nĂ„ nĂ„s nettverket 192.168.1.0/24 via grensesnitt R5 Gi0/2. NĂ„, nĂ„r R5 mottar multicast pĂ„ grensesnitt Gi0/1, forstĂ„r den at RPF-regelen ikke er oppfylt og det ville vĂŠrt mer logisk Ă„ motta multicast pĂ„ Gi0/2. Den mĂ„ koble seg fra RPT og bygge et kortere tre, som kalles Shortest-Path Tree (SPT). For dette sender den PIM Join til R1 via Gi0/2, og R1 begynner Ă„ sende multicast ogsĂ„ gjennom Gi0/2. NĂ„ mĂ„ R5 melde seg ut fra RPT for ikke Ă„ motta to kopier. For dette sender den en Prune-melding som angir kilde-ip-adressen og setter inn et spesialbit â RPT-bit. Det betyr at jeg ikke vil ha trafikk sendt til meg, jeg har et bedre tre her. RP vil ogsĂ„ sende PIM Prune-meldinger mot R1, men ikke sende Register-Stop-meldingen. En annen funksjon: R5 vil nĂ„ kontinuerlig sende PIM Prune til RP, siden R1 fortsetter Ă„ sende PIM Register til RP hvert minutt. RP vil, inntil det er nye interesserte i denne trafikken, svare ham med avslag. R5 informerer RP om at det fortsatt mottar multicast gjennom SPT.
Dynamisk RP-sĂžk.
Auto-RP.
Denne teknologien er proprietĂŠr fra Cisco og er ikke sĂŠrlig populĂŠr, men den lever fortsatt. Auto-RP opererer i to hovedfaser:
1) RP sender RP-Announce-meldinger til den reserverte adressen 224.0.1.39, og annonserer seg selv som RP enten for alle eller for bestemte grupper. Denne meldingen sendes hvert minutt.
2) En RP-mapping-agent er nÞdvendig, som sender RP-Discovery-meldinger med angivelse av hvilke grupper som skal lytte til hvilken RP. Det er fra denne meldingen at vanlige PIM-rutere vil bestemme sin RP. Mapping-agenten kan vÊre enten RP-ruteren selv eller en annen PIM-ruter. RP-Discovery sendes til adressen 224.0.1.40 med et intervall pÄ ett minutt.
La oss se nÊrmere pÄ prosessen:
Sett opp R3 som RP:
ip pim send-rp-announce loopback 0 scope 10
R2 som mapping-agent:
ip pim send-rp-discovery loopback 0 scope 10
Og pÄ alle de andre vil vi vente pÄ RP via Auto-RP:
ip pim autorp listener
SĂ„ snart vi konfigurerer R3, vil den begynne Ă„ sende RP-Announce:
Og R2, etter Ä ha blitt satt opp som mapping-agent, vil begynne Ä vente pÄ RP-Announce-meldinger. Bare nÄr den finner minst én RP, vil den begynne Ä sende RP-Discovery:
Dermed, sÄ snart vanlige rutere (PIM RP Listener) mottar denne meldingen, vil de vite hvor de skal lete etter RP.
Et av de viktigste problemene med Auto-RP er at for Ä motta RP-Announce og RP-Discovery-meldinger, mÄ man sende PIM Join til adressene 224.0.1.39-40, og for Ä sende, mÄ man vite hvor RP befinner seg. Det klassiske dilemmaet med hÞna og egget. For Ä lÞse dette problemet ble PIM Sparse-Dense-Mode utviklet. Hvis ruteren ikke kjenner RP, opererer den i Dense-mode, hvis den vet det, sÄ i Sparse-mode. NÄr PIM Sparse-mode og kommandoen ip pim autorp listener er konfigurert pÄ grensesnittene til vanlige rutere, vil ruteren fungere i Dense-mode kun for multicast av Auto-RP-protokollen (224.0.1.39-40).
BootStrap Router (BSR).
Denne funksjonen fungerer pÄ lignende mÄte som Auto-RP. Hver RP sender meldinger til mapping-agenten, som samler mappinginformasjon og deretter forteller alt annet om rutere. La oss beskrive prosessen pÄ samme mÄte som med Auto-RP:
1) SĂ„ snart vi konfigurerer R3 som kandidat for Ă„ bli RP, med kommandoen:
ip pim rp-candidate loopback 0
Vil ikke R3 gjÞre noe; for Ä begynne Ä sende spesielle meldinger, mÄ den fÞrst finne mapping-agenten. PÄ denne mÄten gÄr vi videre til trinn to.
2) Konfigurer R2 som mapping-agent:
ip pim bsr-kandidat loopback 0
R2 begynner Ă„ sende PIM Bootstrap-meldinger, der den angir seg selv som mapping-agent:
Denne meldingen sendes til adressen 224.0.0.13, som PIM-protokollen ogsÄ bruker for andre meldinger. Den sender dem i alle retninger, sÄ det oppstÄr ikke noe problem med hÞna og egget, som det gjorde med Auto-RP.
3) SĂ„ snart RP mottar en melding fra BSR-ruteren, sender den umiddelbart en unicast-melding til adressen til BSR-ruteren:
Deretter, etter Ă„ ha mottatt informasjon om RP, sprer BSR dem med multicast til adressen 224.0.0.13, som alle PIM-rutere lytter til. Derfor finnes det ingen analog til kommandoen ip pim autorp listener for vanlige rutere i BSR.
Anycast RP med Multicast Source Discovery Protocol (MSDP).
Auto-RP og BSR lar oss fordele lasten pÄ RP pÄ fÞlgende mÄte: Hver multicast-gruppe har bare én aktiv RP. Det er ikke mulig Ä fordele lasten pÄ flere RP for én multicast-gruppe. MSDP gjÞr dette ved Ä tildele RP-rutere den samme IP-adressen med masken 255.255.255.255. MSDP fÄr informasjon via en av metodene: statisk, Auto-RP eller BSR.
Bilde viser oss Auto-RP-konfigurasjon med MSDP. Begge RP-er er konfigurert med IP-adressen 172.16.1.1/32 pÄ Loopback 1-grensesnittet og brukes for alle grupper. Ved RP-Announce informerer begge rutere om seg selv og refererer til denne adressen. Auto-RP mapping-agenten sender deretter ut RP-Discovery om RP med adressen 172.16.1.1/32. Om nettverket 172.16.1.1/32 informerer vi rutere ved hjelp av IGP og tilsvarende. Dermed ber eller registrerer PIM-rutere strÞmmer fra den RP-en som er angitt som next-hop for ruten til nettverket 172.16.1.1/32. MSDP-protokollen er ment for RP-er selv, for Ä utveksle meldinger om informasjon om multicast.
La oss se pÄ en slik topologi:
Switch6 sender trafikk til adressen 238.38.38.38, og dette er bare kjent for RP-R1. Her ber Switch7 og Switch8 om denne gruppen. Rutere R5 og R4 vil sende PIM Join til R1 og R3, henholdsvis. Hvorfor? Ruten til 13.13.13.13 for R5 vil referere til R1 med IGP-metoden, likt for R4.
RP-R1 vet om strÞmmen og begynner Ä sende den mot R5, mens R4 ikke vet om den, siden R1 ikke vil sende den uten videre. Derfor er MSDP nÞdvendig. Vi konfigurerer den pÄ R1 og R5:
ip msdp peer 3.3.3.3 connect-source Loopback1 pÄ R1
ip msdp peer 1.1.1.1 connect-source Loopback3 pÄ R3
De vil etablere en sesjon mellom hverandre, og nÄr de mottar en strÞm, vil de informere sin nabo RP.
RP-R1 vil straks sende en MSDP Source-Active melding som unicasten til Switch6 nĂ„r den mottar strĂžmmen derfra, hvor informasjonen om (S, G) â informasjon om kilde og destinasjon av multicast vil bli inkludert. NĂ„ som RP-R3 vil vite om en kilde som Switch6, vil den sende PIM Join mot Switch6 nĂ„r den mottar en forespĂžrsel fra R4 om denne strĂžmmen, basert pĂ„ rutingtabellen. FĂžlgelig, nĂ„r R1 mottar en slik PIM Join, vil den begynne Ă„ sende trafikk mot RP-R3.
MSDP opererer over TCP, RP sender hverandre keepalive-meldinger for Ă„ sjekke livsvilje. Timeren er satt til 60 sekunder.
Funksjonen til Ă„ dele MSDP-peers i forskjellige domener er fortsatt uklar, ettersom det i Keepalive- og SA-meldingene ikke angis tilhĂžrighet til noe domene. I denne topologien ble det ogsĂ„ testet med konfigurasjon som spesifiserer ulike domener â det var ingen forskjell i ytelsen.
Hvis noen kan gi klarhet, ville jeg med glede lese det i kommentarene.
Kilde: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish