This topic is to discuss the following lesson:
https://networklessons.com/multicast/multicast-pim-register-message/
Really a nice Blog.
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.
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
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 time will expire and it will send another PIM register message with an encapsulated packet.
About your second question, I believe the packet will be forwarded to the receiver but I’m not entirely sure how this process works…I’d have to lab and debug that to take a closer look 
Rene
thank you
Hi Rene,
Just check with you, why the multicast source ping one time to receiver, and will get multiple reply? Only have one join group which R4 only.
I thought is because using the multiple source interface ping to the receiver, but i try to specify the source IP address to ping still the same, will get multiple reply. “ping 239.1.1.1 source 192.168.12.1”
Davis
Hi Davis,
I believe the router will generate a packet for each multicast enabled interface that you have, using the same source address. With an extended ping where you specify the egress interface you should be able to prevent this:
R1#ping
Protocol (ip):
Target IP address: 239.1.1.1
Repeat count [1]: 5
Datagram size [100]:
Timeout in seconds [2]:
Extended commands : yes
Interface [All]: GigabitEthernet0/1
Time to live [255]:
Source address: Loopback0
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes :
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
Rene
Hi Rene,
Yes, you are right. I need to specify the interface to ping.
Thanks!
Davis
Hi Rene,
In your example, you haven’t enabled PIM on lo0 of R2, any particular reason. Also, I tried following your example, but, if I don’t place “ip pim sparse-mode” on R4’s interface towards R3, I am unable to PING from the source (R1)
PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for 224.0.1.40...
PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for 239.1.1.1..
PIM(0): Building Triggered (*,G) Join / (S,G,RP-bit) Prune message for 224.0.1.40
PIM(0): Building Triggered (*,G) Join / (S,G,RP-bit) Prune message for 239.1.1.1.
PIM(0): Received v2 Join/Prune on GigabitEthernet1.12 from 192.168.12.2, to us
PIM(0): Join-list: (192.168.12.1/32, 239.1.1.1), S-bit set
%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up................
PIM(0): Received v2 Join/Prune on GigabitEthernet1.12 from 192.168.12.2, to us
PIM(0): Join-list: (192.168.12.1/32, 239.1.1.1), S-bit set......
Reply to request 36 from 192.168.34.4, 2 ms
Reply to request 37 from 192.168.34.4, 2 ms
PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for 224.0.1.40
Reply to request 38 from 192.168.34.4, 2 ms
Reply to request 39 from 192.168.34.4, 3 ms
Reply to request 40 from 192.168.34.4, 2 ms
PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for 239.1.1.1
Reply to request 41 from 192.168.34.4, 2 ms
Reply to request 42 from 192.168.34.4, 1 ms
Reply to request 43 from 192.168.34.4, 2 ms
Reply to request 44 from 192.168.34.4, 1 ms
Reply to request 45 from 192.168.34.4, 2 msAlso, the PING stopped at the end
R1#ping 239.1.1.1 repeat 100000
Type escape sequence to abort.
Sending 100000, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:
...
PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for 224.0.1.40..
R1#
Any reasoning behind it?
Hi Nagender,
In my example, I don’t have a loopback interface on R2. Only R3 has one since it’s the RP of this network.
R1 and R4 are the source and receiver, I’m using routers but these are only used as host devices. That’s why you don’t need PIM on their interfaces, you could also replace them with windows/linux computers. Make sure you have PIM enabled on the routers that are facing your hosts (R2 and R3).
Rene
“First we will enable multicast routing and PIM dense mode on all routers:”
- looks like a misprint. Should be sparse mode, right?
Hello Ryan
Yes you are correct, thanks for catching that. I will let @ReneMolenaar know so that he can fix it…
Thanks again!
Laz
1 Like
Is it correct that source router will only send registration request for particular group to RP it knows is responsible for that group? Similar to receivers knowing which RP is responsible for the desired group? Or registration will be sent to all known RPs and its RPs that filter our register requests based on ACLs on them?
Hello Vadim
When a source router sends a registration request, it sends it to the RP that corresponds to the specific group. When there are multiple RPs, each multicast router maintains a group-to-RP mapping where the groups correspond to the appropriate RPs. Using the show ip pim rp mapping command, you can see these mappings. How are they created? It depends upon the setup.
You can use mechanisms such as Auto-RP or BSR to automatically choose an RP. These mechanisms also maintain this mapping that is used in the event that there are multiple RPs.
Multiple RPs can be statically configured as well. As seen from the Wireshark capture in the PIM_Register section of the Multicast Sparse Mode lesson, the registration request is sent specifically to the RP with an address of 2.2.2.2, and that RP is chosen from the group to RP mappings. Now in this case there is only one RP, but if there were more, the choice is made from the mappings.
I hope this has been helpful!
Laz
Thank you for clarifying that.
1 Like