This topic is to discuss the following lesson:
Hi Rene,
Very nice article. I was curious about the value of the timer on R1 once it receives prune message from the R2
Thanks
Nage
So R2 will keep receiving the multicast stream even though it does not have a receiver. I wonder if the switch(es) sitting in the middle of the Multiaccess segment can do something to avoid sending the multicast stream to R2 once it sends the PIM Prune msg.
Hello Muhmmad
That’s a good question. It would seem that something like IGMP snooping could be used in such a case to ensure unwanted multicast traffic doesn’t reach a router like that. Although Layer 2 switches are IGMP-aware and can deal with delivering multicast traffic only to hosts that want it, they are unable to act upon PIM messages such as PIM prune in the same way, to help in making such communication more efficient.
In such a case, a network designer should choose a better topology, such as ensuring that R2 and R3 are in different network segments.
I hope this has been helpful!
Laz
Hi,
Could you explain why R1 will “relay” the prune message by sending it again with itself as the source?When R2&R3 receive it, will they relay it again?If so this seems to cause a problem.If not,why?
Thanks
Hello Kai
This is a tricky one. The simple answer is that the Multicast Dense Mode process requires that the upstream router that receives a prune message on its interface that exists on a multi-access (shared) medium such as Ethernet must respond with a prune message.
The process that upstream multicast routers must follow is called the Upstream(S,G) State Machine. This is a fancy term for the steps and processes that define what such a router will do when certain events take place.
This state machine is described in its entirety in RFC 3973. In particular, the portion that is relevant to your question is described like so. The first section describes what an upstream router (like R1 in our case) “sees” a prune message on its interface. This is in the 4.4.1.1. Transitions from the Forwarding (F) State section that describes events that will cause a router to transition from the forwarding state:
See Prune(S,G) AND S NOT directly connected
This event is only relevant if RPF_interface(S) is a shared
medium. This router sees another router on RPF_interface(S) send
a Prune(S,G). As this router is in Forwarding state, it must
override the Prune after a short random interval. If OT(S,G) is
not running, the router MUST set OT(S,G) to t_override seconds.
The Upstream(S,G) state machine remains in Forwarding (F) state.
OT(S,G) Expires AND S NOT directly connected
The OverrideTimer (OT(S,G)) expires. The router MUST send a
Join(S,G) to RPF'(S) to override a previously detected prune.
The Upstream(S,G) state machine remains in the Forwarding (F)
state.
olist(S,G) -> NULL AND S NOT directly connected
The Upstream(S,G) state machine MUST transition to the Pruned (P)
state, send a Prune(S,G) to RPF'(S), and set PLT(S,G) to t_limit
seconds.
The process involves a timer as well as the outgoing interface list. Under certain circumstances, the Ustream(S,G) state machine (i.e. the process running in R1) MUST transition to the pruned state, and send a prune out of its interface facing downstream. This is the statement that shows that the upstream router must send out another prune.
Now there’s no explanation as to why engineers have designed this process in this way. It seems redundant since R2 already sent a prune on the network segment, and R3 received that prune message. By having R1 resend it, it is simply sending the same information. However, my feeling is that this is there to ensure robustness and redundancy. These state machines are designed based on countless tests which optimize the operation, so such redundancy seems to be necessary.
I’m sorry that I couldn’t be more insightful. However, this may also help you to further investigate and research the topic at your leisure.
I hope this has been helpful!
Laz