RPF check for Register and Join messages

Hi Gents,


I've found several threads and blog posts about it,
but I still need to clarify one thing. Let's say we have a router that
is running PIM-SM over a tunnel link. We are not running IGP over the
tunnel so the routing for the RP's address points to a physical link.
The tunnel is the only PIM interface.I understand we need static mroute
for the IP of RP pointing to the tunnel, but I don't understand why we
don't have to correct unicast routing as well ? Let's say this router is
a DR for the LAN segment and it receives IGMP Membership report for a
group. Then the router should send (*,G) Join to the RP which is
unicas packett, but the unicast routing table points to an interace which
doesn't run PIM. So how does it work then ? Does it send it based on the
RPF information and not based on the routing table ? The same thing for
the Register messages if the router receives multicast traffic on the
LAN.

Comments

  • Hi!

    Yes the register messages are checked againgst RPF. So when a source tries to register where the RP doesnt have a route to then it does not work.

    With static mroutes you can kind of modify that check. Usually the check is done against the unicast routing table...

    Step.1: Do I have a route to that destination? YES

    Step.2: Do I have a route to that destination via the interface the register came in? YES.

    And if step 1 fails you can override it with a static mroute. A static mroute does not modify the unicast routing...it only modifies the RPF check sequence!

    Here I blogged something with GRE tunnels. Its not about register but the same principle.

     

    http://chasingmyccie.wordpress.com/2012/03/08/ip-multicast-pim-sparse-mode-over-gre-tunnels/

     

    HTH!

    Regards!

    Markus

  • Thanks for the input, it cleared some things for me, but my question was about the outgoing Join/Register messages not about the incoming ones... I'll use the topology from your blog post - when R4 (the source) sends the Join message towards the RP it will send it through the tunnel interface not through the f1/0 even if the unicast routing table shows that the outgoing interface for 2.2.2.2 is f1/0... So does it mean that the static mroute will actually affect the unicast routing but only for the outgoing PIM Join/Register messages - so it's not used only for RPF checks but also for routing of the outgoing Join/Register messages ?

  • when R4 (the source) sends the Join message towards the RP it will send it through the tunnel interface not through the f1/0 even if the unicast routing table shows that the outgoing interface for 2.2.2.2 is f1/0

    Yes! Thats because PIM is not activated on the other interfaces. You can use GRE tunnels to run multicast when there is a service provider in the middle that isn capable of running multicast.

     

    So does it mean that the static mroute will actually affect the unicast routing but only for the outgoing PIM Join/Register messages - so it's not used only for RPF checks but also for routing of the outgoing Join/Register messages ?

    The router that JOINs will do a RPF lookup for the RP/source when trying to join.

    The RP will do a RPF lookup to sources that register at the RP. You cannot register a multicast group in the RP when the RP doenst have the source-ip in its routing table.

    Its not used for the routing of the outgoing join messages :)...

    Let me try to explain..

     

     

    Here is what happens:

    - PIM join messages are sent hop by hop as PIM is a p2p protocol.

    - the only possibility in my scenario where R4 can send a join is via Tun0

    - When R4 tries to join the RP (the join is sent via Tun0) it does an RPF check of the RP-address/source-address of the MC-source.

    - That check fails because R4 ssys...hmm....my PIM neighbor (sh ip pim neigh) is via tun0 but the RP address can be reached through fa1/0....fa1/0 is not the same so the check fails.

    - When you now create a mroute you kind of play a trick on the router...you fool him. Technically there is no reason why multicast packets should not traverse the GRE tunnel. So we need to modify the logic. In my blog I wrote this:

     

    As we can see here, the RPF check has failed with the reason that the lookup has failed towards the RP or source. this means that the RP and/or the source cannot be reached via the same interface the multicast packets come in.
    The multicast packets come in on interface “tunnel0″ and the unicast routing table for the source and the RP says that those addresses can be reached via “Fa0/1″ -> RPF check fails. 

     

    - When we create this mroute...we pretend to the router that there is a unicast route to the RP via tun0 although in reality its not. Its just to fool the rpf check.

     

    Maybe that helps a little more. IF not keep asking.

    I am not the joker in explaining via text :).

     

    Regards!

    Markus

     

  • Yep, it helps. Thanks ! [Y]

  • Hi guys,

    To clarify a little bit,

    1. I think RPF check is done only for the recieved multicast packet. 
    2. PIM join/prune messages are multicast traffic destined for 224.0.0.13. It will be forwarded up stream through all PIM enabled interfaces only . Since join/prune message is only significant in local segment, RPF check will not be necesary and is not performed.
    3. Interestingly,RPF is not performed for the unicast Regester packet. It is performed for the encapsulated multicast body inside. This means RP will de-encapsulte it first, and then perform RPF.
    4. IP mroute command is only used for defining the RPF neighbour for a specified multicast source. It will always have precedance over the RIB entry.
Sign In or Register to comment.