Multicast PIM Register Message

Multicast PIM sparse mode uses a unidirectional shared tree, and multicast traffic can only flow down the tree. Multicast sources somehow have to get their traffic to this shared tree so that it can flow down the tree toward the receivers. PIM sparse mode will let the RP join the SPT to the source so that it can receive the multicast traffic and let it flow down the multicast shared tree.

The trick is that the RP has to know that a source exists. We use PIM register and PIM register-stop messages to accomplish this.

PIM register messages are sent by the DR (Designated Router) on the segment where the source is. It does two things for us:

  1. Notify the rendezvous point that the source is sending traffic toward a multicast group address.
  2. Deliver the first multicast packet from the source to the RP so it can be delivered to the shared tree. This first packet is encapsulated in a PIM register message.

Whenever a multicast source starts to transmit, the DR will catch the multicast packet and create an (S,G) entry in its multicast routing table. It will encapsulate multicast packets in IP packets and send them using unicast to the RP. When the RP receives this packet, it will de-encapsulate the PIM register message. There are now two possibilities:

  1. When the RP has listeners (receivers) for the multicast group, it will join the SPT for the source so that it can receive the multicast traffic itself and forward it down the shared tree.
  2. When the RP has no listeners, it will discard the multicast packets, and it won’t send a join toward the source.

Once the RP has built the SPT towards the source, it will send a PIM register-stop message to the DR when it has built the SPT to the source OR when it has no active listeners. As a result, the DR will stop the PIM registration process, and it will stop encapsulating multicast traffic in PIM register packets.

Anyway, enough talk…let’s take a look at an actual topology so I can demonstrate how PIM register works!

multicast pim register example

In the example above, we have four routers configured for multicast:

  • R1 is the source for our multicast traffic.
  • R2 will be the designated router, receiving multicast traffic from R1.
  • R3 is the rendezvous point.
  • R4 is the receiver for our multicast traffic.

OSPF has been configured to have full reachability between the four routers. First, we will enable multicast routing and PIM sparse mode on all routers:

R1(config)#ip multicast-routing
R1(config)#ip pim rp-address 3.3.3.3
R1(config)#interface fastEthernet 0/0
R1(config-if)#ip pim sparse-mode
R2(config)#ip multicast-routing 
R2(config)#ip pim rp-address 3.3.3.3
R2(config)#interface fastEthernet 0/0
R2(config-if)#ip pim sparse-mode 
R2(config-if)#interface fastEthernet 0/1
R2(config-if)#ip pim sparse-mode
R3(config)#ip multicast-routing
R3(config)#ip pim rp-address 3.3.3.3 
R3(config)#interface fastEthernet 0/0
R3(config-if)#ip pim sparse-mode 
R3(config-if)#interface fastEthernet 0/1
R3(config-if)#ip pim sparse-mode
R3(config-if)#interface loopback0
R3(config-if)#ip pim sparse-mode
R4(config)#ip multicast-routing 

All routers are configured to use PIM sparse mode and to use R3’s loopback0 interface as the RP. I don’t need to configure PIM on R4 since it’s only the receiver. Let’s configure R4 to join a multicast group address:

R4(config)#interface fastEthernet 0/0
R4(config-if)#ip igmp join-group 239.1.1.1
R3#show ip mroute 239.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.1.1.1), 00:00:22/00:02:37, RP 3.3.3.3, flags: SJC
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    FastEthernet0/1, Forward/Sparse, 00:00:22/00:02:37

You can see that R4 has joined the rendezvous point for the 239.1.1.1 multicast group address. Nobody is sending anything to this multicast group address; however, let’s enable a debug on the RP and launch some multicast packets:

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You’ve Ever Spent on Your Cisco Career!
  • Full Access to our 799 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

567 Sign Ups in the last 30 days

satisfaction-guaranteed
100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Tags:


Forum Replies

  1. Really a nice Blog.

  2. There is a mechanism REGISTER SUPPRESSION.
    when a DR receives a Register stop message it starts a 60-sec Register-suppression timer and when the timer expires, the router again sends multicast packets to the RP.

  3. If the DR has received a register stop from the RP because the RP the does not have any receivers.

    Then how does it restart back again?
    does the whole process wait for a receiver to send a pim join to the RP,
    then the RP sends a join back to the source ?

    During the registration process do the unicast encapsulated packets get sent to the receiver
    at the same time as the RP is establishing the SPT back to the source?
    so during that time you can get duplicate packets and dropped packets

  4. Hi Jeffrey,

    Once the DR receives the register stop, it will start a 60 second “register suppression” timer. During this time, it will not forward any PIM register messages to the RP. Five seconds before the timer expires, it will send a “null register” message to the RP. Now there are two options:

    Option 1) The RP still doesn’t have anyone that is interested in the multicast stream, if so it will send another register stop message and the DR will reset its suppression time.

    Option 2) If the RP does have receivers, it won’t send anything to the DR. The DR its ti

    ... Continue reading in our forum

11 more replies! Ask a question or join the discussion by visiting our Community Forum