This topic is to discuss the following lesson:
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
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
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 188.8.131.52 source 192.168.12.1”
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: 184.108.40.206 Repeat count : 5 Datagram size : Timeout in seconds : Extended commands : yes Interface [All]: GigabitEthernet0/1 Time to live : Source address: Loopback0 Type of service : 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 220.127.116.11, timeout is 2 seconds: Packet sent with a source address of 18.104.22.168
Yes, you are right. I need to specify the interface to ping.
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 22.214.171.124... PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for 126.96.36.199.. PIM(0): Building Triggered (*,G) Join / (S,G,RP-bit) Prune message for 188.8.131.52 PIM(0): Building Triggered (*,G) Join / (S,G,RP-bit) Prune message for 184.108.40.206. 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, 220.127.116.11), 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, 18.104.22.168), 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 22.214.171.124 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 126.96.36.199 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 ms
Also, the PING stopped at the end
R1#ping 188.8.131.52 repeat 100000 Type escape sequence to abort. Sending 100000, 100-byte ICMP Echos to 184.108.40.206, timeout is 2 seconds: ... PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for 220.127.116.11.. R1#
Any reasoning behind it?
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).
“First we will enable multicast routing and PIM dense mode on all routers:”
- looks like a misprint. Should be sparse mode, right?
Yes you are correct, thanks for catching that. I will let @ReneMolenaar know so that he can fix it…