{"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\/en\/blog\/administrirovanie\/printsipy-raboty-protokola-pim","title":{"rendered":"Principles of PIM Protocol Operation","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

The PIM protocol is a set of protocols for transmitting multicast in networks between routers. Neighbor relationships are established similarly to dynamic routing protocols. PIMv2 sends Hello messages every 30 seconds to the reserved multicast address 224.0.0.13 (All-PIM-Routers). The message contains Hold Timers, which are typically equal to 3.5 * Hello Timer, or 105 seconds by default.
\n\"Principles<\/a><\/noindex>
\n PIM uses two main operating modes \u2014 Dense and Sparse mode. Let's start with Dense mode. <\/a><\/noindex>
\nSource-Based Distribution Trees.<\/b>
\nDense mode is advisable to use when there are a large number of clients from various multicast groups. When a router receives multicast traffic, the first thing it does is check it against the RPF rule. RPF is a rule used to verify the source of the multicast against the unicast routing table. The traffic must arrive on the interface behind which the host is hidden according to the unicast routing table. This mechanism solves the problem of loops occurring during multicast transmission.
\n \"Principles<\/a><\/noindex>
\nR3 learns the source of the multicast (Source IP) from the multicast message and checks two streams from R1 and R2 against its unicast table. The stream from the interface indicated by the table (R1 to R3) will be forwarded, while the stream from R2 will be dropped, as packets need to be sent via S0\/1 to reach the multicast source.
\nWhat happens if you have two equivalent routes with the same metric? In this case, the router will choose based on the next-hop of these routes. The one with the higher IP address wins. If you need to change this behavior, you can use ECMP. Learn more. here<\/a><\/noindex>.
\nAfter checking the RPF rule, the router sends the multicast packet to all its PIM neighbors, except for the one from whom the packet was received. The other PIM routers repeat this process. The path that the multicast packet takes from the source to the final recipients forms a tree called a source-based distribution tree, shortest-path tree (SPT), or source tree. Three different names, choose any.
\nHow to deal with situations where some routers don't want a particular multicast stream and have no one to send it to, yet an upstream router sends it to them? The Prune mechanism was invented for this.
\nPrune Message.<\/b>
\nFor instance, R2 will continue sending multicast to R3, even though 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 the S0\/1 interface from the outgoing interface list for that stream, which is the list of interfaces from where 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, unless it receives another Prune message. This is in PIMv1.
\nIn PIMv2, a State Refresh timer is added (default 60 seconds). As soon as a Prune message is sent from R3, this timer starts on R3. Upon the timer expiring, R3 will send a State Refresh message, which will reset the 3-minute Prune Timer on R2 for that group.
\nReasons for sending a Prune message:<\/p>\n