RP - Shared Tree RPF

Dear all,

a quick question, maybe I pick your mind with this, but at the moment I cant recall how come the initial traffic sent from the RP to a Receiving Router (Shared Tree) is not dropped by RPF If the RP is not along the Shared Tree Path.

Many thanks for your help,



  • I thought to share my understanding. With Sparse-mode, all traffic goes to RP (Randeuvz Point) first. RP is in the path shared-tree between Receiving Router and Source. Source will send traffic or its request to Randeuvz point (RP) First. Receivers will send their request to join specific multicast group to RP also at the begining.

    Then when RP has received both Source traffic and Receiving Router traffic, RP will introduce Source Router and Receiving Router together. Then RP (Randeuvz Point) will be eliminated from Shared-Tree. Then Source and Destination will start talking together directly without RP being involved. at the begining RP is on the shared Path-tree. Then after source and Receiving Router each has sent its traffic to RP and they are known to eachother, RP will be eliminated and they will start talking together directly.

    to my understanding, Reverse-Path forwarding works fine in all situations even when RP is involved. The reason is because when RP is involved, RP is still ont the shared-Tree path and Reverse-Path forwarding is able to distinguish RP. When RP is eliminated, Reverse_path forwarding works between source and receiving Router directly

    Thanks for your question and making us reviewing this subject.


  • Thank you Ellie,


    so yuo would say that RPF is not triggered on traffic coming from RP because it's still considered part of the (*,G) path? (that is, regardless of the fact that the Source of the incoming Mcast traffic could be coming in from a non RPF interface?).

    At what point would then the Receiving Router activate the RPF detection, and what would trigger this change on the receiving Router (and all other Routers on the Shared Tree)?




  • I think I found the answer to the above:


    "...Last hop routers directly conected to receivers may, at their discretion, join thmselves to the source tree and prune themselves from the shared tree."


    That could imply that the Receiving Router would individually jion the Source Tree and at that point, enforce RPF for the incoming (S,G) traffic.




  • Hi Francesco,


    You are right about above, When RP is involved on sending the traffic between source and Receiving Router, It is called Shared-Tree. When RP gets eliminated from the path after source and destination are known together, That is called Shorted-Path tree since that is more efficient path for the source to send traffic directly to Receiving router as opposed to RP being involved along the path and every body has to send traffic to RP even though if it is not a shorted path.


    Per my understanding, RPF (Reverse-Path Forwarding) Happens in both situations with RP and without RP. RPF checked depends on the situation. with Shared-Tree, RPF (Reverse-Path Forwarding) happens towards RP (Randeuvz Point). With Shorted-Path Tree which RP (Randeuvz Point) is not involved, Reverse-Path forwarding (RPF) Happens towards source since Shortest-path forwarding is between source and Receiving Router. In Sparse-mode, when we have both (*,G) or Shared-Tree and Shortest-path tree (S,G), always (S,G) Will take over (*,G) which is shared-tree. Due to this matter, when we have both of them, RPF (Reverse-Path Forwarding) will happen towards Source since (S,G) Entry will take over and has precedence over (*,G).

    In Sparse Mode, there is threshold=0 with RP by default. Once the first packet is sent from Source to RP, Threshold will go beyond zero. that makes Sparse-mode to switch from Shared-Tree to Shortest-Path Tree which RP will be eliminated and source and Recieving router will start talking directly.

    Also, although we are talking about Multicast routing in Sparse-mode, RPF happens in Unicast-Routing table towards source or RP depending on the situations as described above.


    I thought to share my thoughts on this


    Thank you

  • Thank you Ellie,


    all very clear above; the point where I struggle is this:

    Does RPF perform its check on the Source IP of the MCast Traffic? If this is the case, and provided that the RP is not on along the path between Source and Destionation, When RP initially forwards the multicast traffic to the destination router (Shred Tree) the Source Address of the  stream would be the IP Address of the Source Device.

    To my understanding, this should be discarded by RPF becase, as said above, the packet would arrive to the Receiving Router with an IP source that doesnt belong to this interface - UNLESS -  the Receiving Router, knowing that it is a Shared Tree, disregards of this fact and will accept the packet, learn about the Multicast Source and then switch to the Source Path Tree (S,G).

    If this is correct, that implies that RPF would be disabled for the Shared Tree (*,G) and enabled only for Source Path Tree (S,G).

    I am curious to know your thoughts,


    Many thanks,



  • Hi Francesco,

    RPF check happens on both Shared-tree and Shortest-path tree. RPF Check depends on tree type. if Traffic is flowing down the shared-tree, RPF check mechanism will use IP address of RP to perform RPF Check.

    If traffic is flowing down SPT (Shortest_Path_Tree), RPF CHeck mechanism will use the IP address of the source to perform RPF Check. when traffic is going via Shared-Tree, RPF Check happens towards RP. RPF Check will happen on both modes.

    PIM Sparse_Mode uses Explicit Join model where Receivers send PIM Join messages to RP. RP Is the root of shared-tree down which all multicast traffic flows. Last Hop routers may be configured with SPT_Threshold wich once exceeded, it will cause the last hop router to join SPT (Shortest_Path_Tree). This will result in the multicast traffic from the source to flow down the SPT from the source to the last hop router and by passing RP. If there is no SPT_Threshold configured, default SPT_Threshold =0 which when is exceeded, Shared-Tree will convert to SPT (Shortest_Path_tree).

    That is my understanding from the process.

    Thank you



  • OK so this is what I was after:

    "...when traffic is going via Shared-Tree, RPF Check happens towards RP."

    Many thanks for your replies; we cleared it at the end,



  • Q. How does RPF work for Shared trees?

    A. The RPF check is conducted differently for data flowing via the shared tree, which is routed at the RP, not the Source. In this instance, the RPF is successful when data arrives at the interface that it would use to reach the RP.


    All preceding sources of RPF data are searched for a match on the source IP address. When you use Shared Trees, the RP address is used instead of the source address.


Sign In or Register to comment.