Multicast PIM Dense Mode

Lessons Discussion
61

Hello David

Let me try to add some detail to the process:

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 hope this has been helpful!

Laz

62

Hi,

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.

Thanks,

Sam

63

Hello Sam

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 hope this has been helpful!

Laz

64

Hi Laz,

Thanks for responding.

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.

Thanks.

Sam

65

Hello Samir

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?

I hope this has been helpful!

Laz

66

Hi Laz,

Thanks for getting back to me.

I have been reading this page:

https://notes.networklessons.com/multicast-routing-table-timers

And it is specifically this dense mode timer and the corresponding statement that I’m trying to understand:

GigabitEthernet0/2, Prune/Dense, 00:01:15/00:01:43

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.

Thanks.

Sam

67

Hello Sam

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.

I hope this has been helpful!

Laz

68

Hi,

image
image951×437 49.8 KB

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.

Thanks

69

Hello Görgen

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.

I hope this has been helpful!

Laz

1 Like
70

Hi, rene
I got a question for you in this multicast PIM dense mode part.
Firstly, I have to say that I’m new to multicast.

I followed your steps and topology.

When i issue the command: ip igmp join-group 239.1.1.1 under the H2 (a router)
And then i go to the multicast-R-02, and issue command: show ip mroute 239.1.1.1
i can get the output of (S,G) entry
But nothing happened on the Multicast-R-01 and 03.

However, when try to generate some multicast traffic on the H2
issue the command: ping 239.1.1.1 repeat 2147483647

I got the output of multicast group 239.1.1.1 (S,G) entry on the multicast routers R01 and R03.

Could you please briefly explain for me why does it happen?

image
image1389×801 56.5 KB

image
image1134×876 64.5 KB

71

Hello Galen

That’s an excellent observation. First of all, this is normal behavior, and I’ll explain why it works like this.

First of all, the ip gmp join-group command on H2 sends an IGMP membership report. This report gets sent to the local network segment, and is received by R2, which is the directly connected router in the topology.

When R2 receives that IGMP report, it creates a local group membership entry on that interface. R2 records the receiver on that interface and will accept multicast traffic for that group when it arrives. That’s why you see the (S,G) entry in R2. At this point, R1, and R3 see nothing because the IGMP membership report, by design, does not propagate beyond the local subnet. PIM Dense mode behavior is such that explicit PIM join messages are not sent upstream when a receiver joins. Only the first hop router obtains any knowledge of the joining of a host to a multicast group, and that’s R2. Dense mode builds state only when traffic arrives, not when receivers appear.

If you were running PIM-SM instead, R2 would actively send a PIM Join message upstream toward an RP when it received the IGMP report, proactively building the multicast tree before data arrives. This is a fundamental architectural difference between the two modes. If you haven’t yet looked at PIM Sparse Mode, you’ll see that when you do the lab.

Now, once you ping the multicast group, H2 becomes a multicast source because of the ping itself. Note that this has nothing to do with the IGMP join process you initiated before, which made H2 a member of the multicast group, that is, a receiver of multicast traffic from that group.

It’s a different mechanism altogether. When you ping the group, this triggers the flood and prune process of PIM-DM. When R1 and R3 receive the flooded multicast packets, they create (S,G) entries in their mroute tables. This is known as a data-plane driven state creation. The process on the data plane drives the creation of the entries in the mroute table.

So the key takeaways are:

  • The (S,G) state in PIM Dense Mode is DATA-PLANE driven. It is created when actual multicast data packets are received and processed by a router.
  • IGMP is purely a receiver signaling protocol between a host and its directly connected router. It tells R2 that H2 wants to receive group 239.1.1.1, but it does NOT cause routing state to propagate across the entire network.

I hope this has been helpful!

Laz