cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
582
Views
0
Helpful
1
Replies

PIM dense mode,prune message, state refresh message.

sarahr202
Level 5
Level 5

Hi everybody.

Please consider the following topology.

Host3 has joined the multicast group 224.7.7.7. All routers are running " PIM Dense mode".   The diagram shows the rpf int and pruned int for 224.7.7.7

zee.png

Questions:

1) By default (S,G) entry stays in the table on routers for three minutes. In our case we have ( 10.10.10.10,224.7.7.7) where 10.10.10.10 is the ip address of server, which is the source of multicast traffic.  This tree minutes timer gets reset each time our routers receive multicast packet for 224.7.7.7

My book says a pruned int stays in pruned state for 3 minutes. After 3 minutes, the the int is unpruned. In our example, R2 s0/0 is being pruned.

My question is it should not matter whether the int stays pruned or not pruned because  ( 10.10.10.10, 224.7.7.7) will last only 3 minutes in the table.

Let me elaborate on it.

Suppose R2 has ( 10.10.10.10, 224.7.7.7) and the timer read 180 seconds

The prune timer for s0/0 on R2 reads 60 seconds.

   Assuming R2 does not receive any multicast packet,after 60 seconds, entry ( 10.10.10.10, 224.7.7.7) goes away so does the prune timer for s0/0 even though it still has 60 more seconds to expire

Am I correct?

2) My book says each time a Router receives a prune message, the router starts the prune timer on that int. After 3 minutes, the router will unprune the int.

Here is my understanding.

R3 receives a multicast packet 224.7.7.7 from R1 and R2.  R3 sends the " prune" message to R2 because s0/1 on R3 fails RPF check.

R2 receives the prune message and starts the timer. For the next three minutes, R2 will not send out any multcast packet to 224.7.7.7

After 3 minutes prune timer expires. R2 receives a multicast traffic 224.7.7.7. R2 will sends out the packet to R3 because s0/0 on R2 is no longer pruned. As a result, R3 will receive multicast packet 224.7.7.7 from R1 and R2. R3 again performs the RPF check and sends out prune message to R2.  This cycles repeats every 3 minutes provided that routers continue to receive multicast traffic .

This is what I observed.

R3 sends  a prune message and forgets about it for three minutes. After 3 minutes If R3 receives multicast packet 224.7.7.7 from R1 and R2., it performs RPF check and sends another prune message to R2 then forgets about it for another 3 minutes.

Am I correct?

------------------------------------------------------------------------

State refresh message

This is what my book says:

R3 monitors the time since it sent the last Prune to R2. Just before the Prune timer expires, R3 decides to send a " State Refresh Message " to R2.

Let suppose R3 just sends a prune message to R2. Prune timer is about to expires but R3 does not receive any multicast 224.1.1.1 from R1.

What will R3 do next? will it still send " state refresh message" to R2? If yes what is the point ? Because after three minutes, entry ( 10.10.10.10, 244.7.7.7) goes away on all routers in our example so there is no point sending "refresh message to R2' because there is no entry ( 10.10.10.10,224.7.7.7) in R2's table which means no longer need for R2 to prune s0/0 any more.

Sending " refresh message" by R3 to R2 will be effective as long as R3 continue to receive multicast packets 224.7.7.7 from R1.

Is my understanding correct?

Thanks and have a great day.

1 Reply 1

sarahr202
Level 5
Level 5

Hi everybody

I found the answer. I am posting for someone who might have the same question.

R3 monitors the time since it sent the last Prune to R2. Just before the Prune timer expires, R3 decides to send a " State Refresh Message " to R2.

Let suppose R3 just sends a prune message to R2. Prune timer is about to expires but R3 does not receive any multicast 224.1.1.1 from R1.

What will R3 do next? will it still send " state refresh message" to R2? If yes what is the point ? Because after three minutes, entry ( 10.10.10.10, 244.7.7.7) goes away on all routers in our example so there is no point sending "refresh message to R2' because there is no entry ( 10.10.10.10,224.7.7.7) in R2's table which means no longer need for R2 to prune s0/0 any more.

Sending " refresh message" by R3 to R2 will be effective as long as R3 continue to receive multicast packets 224.7.7.7 from R1.

My lab corroborates the above.

R3 continue to send state refresh message to R2 as long as it is receiving multicast traffic 224.7.7.7 from R1.

Once R3 stops receiving multicast packet 224.7.7.7 from R1, ( 10.10.10.10,224.7.7.7) will age out and R3 will stop sending  state refresh message.

So R3.7 performs somewhat this logic.

If the entry ( 10.10.10.10, 224.7.7.7) is valid, then continue to send " refresh message" to R1 around every three minutes. If the entry (10.10.10.10,224.7.7.7) ages out, do not send any state refresh message to R1.

Thanks and have a great day.