{"id":33142,"date":"2019-10-31T21:50:58","date_gmt":"2019-10-31T18:50:58","guid":{"rendered":"https:\/\/prohoster.info\/blog\/printsipy-raboty-protokola-pim\/"},"modified":"2019-10-31T21:50:58","modified_gmt":"2019-10-31T18:50:58","slug":"printsipy-raboty-protokola-pim","status":"publish","type":"post","link":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/printsipy-raboty-protokola-pim","title":{"rendered":"Prinsippene for PIM-protokollen","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

PIM-protokollen er et sett med protokoller for overf\u00f8ring av multicast i nettverk mellom rutere. Nabo-relasjoner bygges p\u00e5 en lignende m\u00e5te 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.
\n\"Prinsippene<\/a><\/noindex>
\n PIM bruker to hoveddriftsmoduser - Dense og Sparse mode. La oss begynne med Dense mode. <\/a><\/noindex>
\nSource-Based Distribution Trees.<\/b>
\nDense-mode-modusen er hensiktsmessig \u00e5 bruke i tilfelle et stort antall kunder fra forskjellige multicast-grupper. N\u00e5r ruteren mottar multicast-trafikk, sjekker den f\u00f8rst denne mot RPF-regelen. RPF - denne regelen brukes for \u00e5 sjekke kilden til multicast mot unicast-ruting-tabellen. Trafikken m\u00e5 komme inn p\u00e5 det grensesnittet hvor verten er skjult i henhold til unicast-ruting-tabellen. Denne mekanismen l\u00f8ser problemet med loop-dannelse ved overf\u00f8ring av multicast.
\n \"Prinsippene<\/a><\/noindex>
\nR3 fra multicast-meldingen finner ut kilden til multicast (Source IP) og sjekker to str\u00f8mmer fra R1 og R2 i sin unicast-ruting-tabell. Str\u00f8mmen fra det grensesnittet som tabellen peker til (R1 til R3) vil bli sendt videre, mens str\u00f8mmen fra R2 vil bli droppet, siden for \u00e5 n\u00e5 multicast-kilden m\u00e5 pakker sendes via S0\/1.
\nHva skjer hvis du har to ekvivalente ruter med samme metrik? I s\u00e5 fall vil ruteren velge basert p\u00e5 next-hop for disse rutene. Den med h\u00f8yest IP-adresse vinner. Hvis det er n\u00f8dvendig \u00e5 endre denne oppf\u00f8rselen, kan ECMP brukes. Mer informasjon. here<\/a><\/noindex>.
\nEtter \u00e5 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\u00f8lger fra kilde til sluttmottakere danner et tre som kalles - source-based distribution tree, shortest-path tree (SPT), source tree. Tre forskjellige navn, velg ett.
\nHvordan l\u00f8se problemet med at noen rutere ikke fikk en viss multicast-str\u00f8m og ingen sender til den, men en overordnet ruter sender den. For dette ble Prune-mekanismen oppfunnet.
\nPrune Message.<\/b>
\nFor 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. <\/p>\n

The following is a more formal definition of a PIM Prune message:
\nThe 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.<\/p><\/blockquote>\n

\nAfter 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.
\nIn 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.
\nReasons for sending a Prune message:<\/p>\n