PIM Register messages - multicasted?

[Peter Paluch]

Dear friends,

I have been having a closer look at the PIM registration process when a multicast source starts sending a multicast traffic and its PIM Designated Router (DR) performs the registration process. Both the respective RFCs and official Cisco documentation consistently maintain that the DR encapsulates the multicast traffic into PIM Register messages which are unicasted to the preconfigured RP - essentially, the multicast traffic is tunneled as unicast to the RP. That is how I understood it as well.

Now, I have captured and analyzed the PIM Register messages on 1841 (IOS 12.4(25)c ADVIPSERVICESK9) and 2691 (IOS 12.4(15)T12 ADVIPSERVICESK9), and I was surprised to see every time that the PIM Register messages are actually transmitted as multicast, addressed to the same multicast group as the original encapsulated multicast traffic. That goes against all the documentation I have been able to find so far.

It has a logic to it - essentially, if you deliver all PIM Register  messages towards the appropriate RP then you do not need to address them as  unicast at all (with the notable exception of a multicast-incapable  network somewhere between the DR and the RP which is a marginal case). I  would like to know if this is something open and documented or a  proprietary enhancement of Cisco.

So my question is - can anybody enlighten me on this, perhaps point me to an Internet Draft or RFC that describes this new, different behavior? Do you have the same experiences?

One never ceases to learn... Thank you for any guidance!

Best regards,

Peter

[Mohamed Sobair · Accepted solution]

Hi Peter,

Your understanding is correct indeed, and in fact I havent tried to captured it, but for sure the pim register messages has to be sent as unicast from the Designated router which has the lowest cost towards the RP, this process is done for a period of time interval before the RP sends back register-stop messages towards the source.

This symptom requires the multicast traffic to be unicasted to the known RP or else the registration will fail , the RP should be known to all Multicast recievers and the Source. The recievers needs to send (or the IGMP querier routers) needs to know the RP to forward all pim Join messages to it. The source doesnt know about the RP at the first place, in fact, the source forwards the traffic as multicast, however, the PIM DR who knows about the RP and would therfore sends a pim register message to its known RP as unicast.

I didnt test it in a lab , but this is what I knew.and this is how it should work!!

HTH

Mohamed

[Peter Paluch]

Hello Mohamed,

Thank you for replying. Yes, you have described the common scenario with PIM-SM registration process with the PIM Register messages being unicast. That is what I also expected and knew - until today

But the funny thing is - I see a nice logic in the current behavior, too! If all routers make an agreement that

1. all PIM Register messages will be sent to the multicast group of the original multicast flow, and
   
2. all received PIM Register messages will be forwarded towards the RP (using the RPF interface towards the RP)

then the Register messages will be delivered to the RP just as if they were unicast. After all, this seems to be exactly what is happening in my test topologies.

I just wonder whether there is any description of the rationale behind this, and why did Cisco decide to implement it this way.

Best regards,

Peter

[Mohamed Sobair]

Hello Peter,

Its illogical to send it as multicast to the RP after all however, UNLESS the RP is the ONLY candidate that recieves the pim register messages. Or the logic will revert to Dense Mode Multicast rather than being Sparse Mode.

The Concept behing Sparse Mode is to Optimize the multicast traffic by reducing unnecessary wasted bandwidth, and its designed for medium to large Network size.

Regards,

Mohamed

[Peter Paluch]

Hello Mohamed,

Its illogical to send it as multicast to the RP after all however, UNLESS the RP is the ONLY
 candidate that recieves the pim register messages. Or the logic will 
revert to Dense Mode Multicast rather than being Sparse Mode.

Not entirely true. The PIM-DM propagates the received multicast flow through all multicast-enabled interfaces that are not in the Pruned state, and implicitly, all such interfaces are in the Forward state. The logic I have described causes the multicast, though encapsulated in Register messages addressed to the multicast group of the original flow, to be propagated only towards the RP, not through all interfaces.

Best regards,

Peter

[Peter Paluch]

Dear friends,

OH MY...! I am such an idiot. This entire thread is a great misunderstanding on my side. I apologize so much to anybody whom I have confused or misled.

When I was looking on the captured PIM Register packets in the Wireshark, I've just looked on the packet list where the source/destination IP were displayed. However, these IP addresses are the internal IP addresses, not the addressing information in the outer header. The outer header addresses are visible only in the frame contents breakdown (the Packet Details window part). Everything is OK - the outer header is unicast just as it should be. Just the IP addresses in the packet list do not correspond to the outer but rather to the inner IP header! I was looking at incorrect IP addressing information! The Register messages are in fact addressed exactly as they should.

I'd rather not comment how I feel about myself right now. Let me just thank anybody who tried to understand this issue together with me, and apologize sincerely once more for this gross mystification.

Best regards,

Peter