PIM-DM routers exchange periodic Hello messages, by default, every 30 seconds, to maintain neighbor adjacencies. If a neighbor fails (detected via Hello timeout), the router removes the neighbor from its PIM neighbor table. When a neighbor goes down, the router removes the associated interface from the OIL for multicast groups. Upstream routers will prune the affected branch if no other valid OIL interfaces exist, suppressing traffic until the next flood cycle.
By default, PIM-DM re-floods multicast traffic every 3 minutes. This occurs when prune states expire, resulting in the rebuilding of the distribution tree. With State Refresh enabled, periodic refresh messages, by default: every 60 seconds, extend prune timers, reducing unnecessary flooding.
Now, after a failed link recovers, a downstream router sends GRAFT messages upstream to rejoin the multicast tree, bypassing the flood cycle. Upstream routers reinstate the interface in the OIL upon receiving GRAFTs, resuming traffic immediately.
So the router does not globally prune out all groups for every neighbor when one neighbor goes down. It just discontinues sending traffic to that specific neighbor. Graft messages are the ārecoveryā trigger, telling the upstream router, āI realize I got pruned or was offline; now I need the multicast traffic again on this interface.ā If a Graft message is not sent, and the prune timers expire, the traffic begins to be sent once again. Does that make sense?
Iām a little unclear about how the tree is rebuilt after timers expire.
If a router is receiving traffic from a source and the 3 min timer expires for an interface on its OIL (because it hasnāt received a prune in that time), then it starts forwarding traffic. Makes sense, so far.
But what if that downstream routerās OIL timer has not expired? Does it immediately send a prune or will it continue to receive traffic until its own 3 min timer expires then starts sending traffic?
Iām trying to understand how the tree can be built from end-to-end with out timers preventing it form happening.
The only thing I can thing is that the prune has to originate from the LHR and travel up the RPF tree.
Letās break down your question into key points to clarify how PIM-DM handles timer expirations and tree rebuilding:
PIM-DM initially floods multicast traffic to all downstream interfaces. Routers with no interested receivers upstream prune themselves from the distribution tree. However, prunes are temporary. A pruned interface is re-added to the OIL after the Prune Timer (default 3 minutes) expires, unless refreshed by another prune.
Now if an upstream routerās OIL timer expires, it resumes forwarding multicast traffic downstream. This is the flooding phase (traffic is sent even if downstream had pruned earlier).
If a downstream routerās OIL timer has not expired, and it receives traffic but still has no receivers, it immediately sends a prune upstream. Thereās no need to wait for its own timer to expire. This prune resets the upstream routerās OIL timer to 3 minutes and traffic stops again. This prevents waiting for timers and is thus more efficient.
So the multicast tree is periodically rebuilt via the flood-prune cycle every 3 minutes.
Downstream routers re-express their interest (or lack of interest) via immediate prunes. If a receiver appears, the LHR sends a PIM Graft upstream to bypass the timer and resume traffic immediately.
So to summarize, if the upstream routerās OIL timer expires and traffic resumes, the downstream router will immediately send a prune if it still has no receivers. There is no waiting for timers. This ensures the tree remains pruned, and traffic flows only along necessary paths. The periodic flood-prune cycle with the 3 min timer and graft mechanism handle dynamic network changes efficiently. Does that make sense?
I understand the part where if a router receives multicast traffic and it doesnāt have a listener then itāll send a prune to the upstream router, but what if it has a downstream router but the timer on its OIL hasnāt expired yet? How does it handle the traffic then? Thatās the part Iām trying to clarify.
I know that graft messages are sent to un-prune a link to an upstream router, so my question might be a little pointless, but I just want to make sure I understand how it all works.
Your question is a good one, and touches on an important aspect of how multicast pruning and forwarding states behave.
So the scenario is, you have a router that is receiving multicast traffic. It has a downstream router that had requested the multicast traffic (was in the OIL). But now, no listener is present on the downstream segment, yet the OIL timer hasnāt expired yet. Youāre asking: What happens during this window? Will the router still forward the traffic?
As long as the OIL entry of the downstream router has not expired, the router will continue forwarding multicast traffic to that downstream interface ā even if there are no current listeners.
Only when the prune timer expires (and no new IGMP joins or PIM grafts are received to refresh the interest), the router removes that interface from the OIL and sends a PIM Prune upstream if needed. Does that make sense?
00:01:43: This timer is specific to PIM Dense mode. It is the prune timer for the GigabitEthernet0/2 interface. The interface is pruned and is thus not forwarding multicast traffic. This timer indicates how much longer the interface will remain in the pruned state before it will again be eligible to receive multicast traffic. If no prune message is received within this period, the interface will transition to the forwarding state and will resume receiving multicast traffic.
Firstly, shouldnāt it say:
This timer indicates how much longer the interface will remain in the pruned state before it will again be eligible to SEND multicast traffic. If no prune message is received within this period, the interface will transition to the forwarding state and will resume SENDING multicast traffic.
Assuming I am correct, for the 00:01:43: part of the timer, what if it has already expired on an upstream router and starts forwarding traffic? Thatās the part I am trying to understand.
Yes, youāre right, the text there should say āsendā or āforward,ā not āreceiveā. I have made the correction.
When the prune timer expires on the upstream router, letās call it R0 for now, it assumes that the downstream router, R1 in the output of our note, may now want traffic again. Therefore, R0 resumes forwarding multicast traffic to R1.
R1 receives multicast packets again on GigabitEthernet0/2.
Upon receiving traffic, R1ās own prune expiration timer is reset OR R1 re-evaluates whether to forward or send another prune based on whether it has interested downstream receivers, and whether it has received multicast traffic recently from that interface.
If the upstream routerās (R0) prune timer expires before R1ās, multicast traffic will resume arriving at R1. If R1 still has no interested receivers, it will drop the packets locally, and optionally send another prune message upstream to reassert its prune.
So to summarize, if the prune timer on an upstream router (not shown in the output) expires before R1ās timer, that upstream router will resume forwarding multicast traffic to R1. R1 will then either accept and forward it (if it has receivers) or send a new prune message to stop the flood again.