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.
In above, to disappear Gi0/2 from multicast routing table, it is mandatory to both not receive and not forward the traffic for 1 min 43 secs right?
Because you said âWhen we donât forward any packets for one minute and 43 seconds then this entry will be removed from the multicast routing table. As long as we keep receiving packets, this timer will be resetted to three minutes.â which means even if I donât forward when I receive a multicast packet then this timer will be resetted to 3 minutes.
First of all, the statement doesnât have to do specifically with the Gi0/2 interface, but with the whole (S,G) entry of (192.168.1.1, 239.1.1.1). The statement does seem to need some clarification. It should probably read like so:
âIf R1 does not receive any multicast packets from 192.168.1.1 for 1:43, the (S,G) entry will expire and be removed.â
Does that make sense? Iâll ask Rene to take a look and make any necessary clarifications.
