Multicast PIM Dense Mode

What ios you are using for H1 ,H2 and routers ?

Hi Sims,

I believe I used Cisco VIRL for this with the latest IOSv image:

R1#show version 
Cisco IOS Software, IOSv Software (VIOS-ADVENTERPRISEK9-M), Version 15.6(2)T, RELEASE SOFTWARE (fc2)


Just to let you know, if your image is a layer 3 device, then for the config to work as Rene has put it, with default-gateway, you need to “no ip routing”.
Otherwise, just do a default route.

Usually the method used in the lab is for Layer 2 devices.

That’s right, it’s either this:

R1(config)#ip route

Or this:

R1(config)#no ip routing
R1(config)#ip default-gateway

The ip default-gateway command doesn’t do anything until routing is disabled.

“We’ll discuss sparse-dense mode in another lesson”

Did you create a lesson yet for this?

Hi Chris,

I see I never added it, will try to do so soon.

Hi Rene, Thanks for briefing us on dense mode, graft message, etc.

I dont see graft v2 msg while doing the same lab while connect H3 to igmp group

Is it because any specific reason?

PIM debugging is on
*Jul 28 05:39:47.672: PIM(0): Building Graft message for, Eth                                                               ernet0/0: no entries
*Jul 28 05:39:47.672: PIM(0): Building Graft message for, Eth                                                               ernet0/3: no entries
*Jul 28 05:39:47.672: PIM(0): Building Graft message for, Eth                                                               ernet0/2: no entries
*Jul 28 05:40:41.660: PIM(0): Received v2 Assert on Ethernet0/2 from 19                                                     
*Jul 28 05:40:41.660: PIM(0): Assert metric to source is [1                                                               10/20]
*Jul 28 05:40:41.660: PIM(0): We win, our metric [110/20]
*Jul 28 05:40:41.660: PIM(0): Schedule to prune Ethernet0/2
*Jul 28 05:40:41.660: PIM(0): (, oif Ethernet0                                                               /2 in Forward state
*Jul 28 05:40:41.660: PIM(0): Send v2 Assert on Ethernet0/2 for 239.1.1                                                               .1, source, metric [110/20]
*Jul 28 05:40:41.661: PIM(0): Assert metric to source is [1                                                               10/20]
*Jul 28 05:40:41.661: PIM(0): We win, our metric [110/20]
*Jul 28 05:40:41.661: PIM(0): (, oif Ethernet0                                                               /2 in Forward state
*Jul 28 05:40:41.661: PIM(0): Received v2 Join/Prune on Ethernet0/2 fro                                                               m, to us
*Jul 28 05:40:41.661: PIM(0): Prune-list: (,
*Jul 28 05:40:41.661: PIM(0): Prune Ethernet0/2/ from (192.168                                                               .1.1/32,

Hi Vinod,

In your output I see it is building the graft message but it doesn’t show anything about sending/receiving it.

Couple of things to check:

  • R1 and R3 are PIM neighbors?
  • Is the interface between R1-R3 currently pruned?
  • Does R1 show anything in its debugs?
  • Try a packet capture between R1-R3 to check if you see any graft messages.


Hi Rane,
I could see PIM neibhorship is up but not showing port in Outgoing interface list. What could be reason and how to troubleshoot it.

R1#sh ip pim interface

Address          Interface                Ver/   Nbr    Query  DR     DR
                                          Mode   Count  Intvl  Prior    Ethernet0/0              v2/S   0      30     1     Ethernet0/1              v2/S   1      30     1     Ethernet0/3              v2/S   1      30     1
R1#sh ip mro
R1#sh ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group,
       V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(*,, 00:40:15/00:02:53, RP, flags: DCL
  Incoming interface: Null, RPF nbr
  Outgoing interface list:
    Ethernet0/0, Forward/Sparse, 00:40:13/00:02:53



I would like to clear my doubt .

When multicast traffic hits on R1 and R2 these routers create (,g) entry in their multicast routing table along with s,g entry .Could you tell me why (,g) is required for this communication ?

I am not able to understand why these routers created this entry .

Hello Ratheesh

In the lesson shown, there is a (*, entry that appears in the multicast routing table. This appears only after H2 has had the ip igmp join-group command applied. This means that an entry has been created in the multicast routing table because of the join request coming from H2. No traffic has yet been sent for this group, so there is no information about the source, and this is why we have a (*,g) entry.

Once traffic begins to traverse the network, we have information about the source which in the case of the lesson is S1. This is why we have a second entry of (, which is an (S,G) entry which routes the actual traffic from specific source to specific destination.

I hope this has been helpful!


Dear Laz,

But even without the ip igmp join command there are (*,G) + (S,G) entry in the routing table when we just send the feed. Why is that?

Dear Rene/Laz,

Please help me to understand these timers.

Hello Roshan

Yes, this is the case because PIM sparse mode uses an RP and the Auto RP discovery protocol to automatically find the RP in the network. This will use the multicast group address This is why you will see (*, in the output of the lesson even before the command is initiated.

However, it is once the ip igmp join-group command is implemented that you will see the specific route for that group as shown in the lesson.

As for the timers you see in the show ip mroute output, these are the “Uptime/Expires” timers. The first indicates how long the entry has been in the IP multicast routing table while the second states how long until the entry will be removed from the table if no additional traffic is seen.

I hope this has been helpful!


Dear Laz,

thanks for the reply.
About the timers here in the 2nd underlined row, 00:01:11 seems ending at 3 min and set to zero again and 00:01:48 seems to be starting from 3 min and counting down to zero and resets to 3 min back. What is the meaning of that?

Hello Roshan

I was hasty to respond and forgot to add the information for the second set of timers. The explanation I gave before had to do with the first set of timers you indicated.

The second set of timers which correspond to a particular interface appear in what is known as the Outgoing Interface List or OIL. This is a list of interfaces that correspond to each of the entries in the mroute table. In the example you gave, there is only one interface, and that is Ethernet 0/1. Each interface in the OIL has a set of timers that correspond to it that indicate something different than the Uptime/Expiry timers when using Dense Mode.

There are two states of an interface that is in the OIL. Forward or Prune. When in the Forward state, the expiry timer does not get decremented. In some IOS versions, it simply says “stopped” and in some others it has a value of zero. You can see an example of this in the output of your example where there are a couple of routes for which the interface is in Forward/Dense state, and the expiry timer says “stopped”.

The second state is the pruned state in which the interface where you have indicated the underlines exists. When there are no receivers for a particular route, the router will send a prune message upstream. Once the router determines that it must prune an interface from the OIL, it starts a 3 minute timer after which the prune state times out.

I hope this has been helpful!


Hi Rene and staff,
sorry if my question is basic, i am new in multicast and try to undestand how dense mode can avoid loops
Here is the pic

R3 receive the multicast packet from R2 via s0/0: due to RPF the packet is discarded
R3 receive the same multicast packet from R1 via s0/1: due to split horizon it is not forwarded via this interface
But, with these two rules, you cannot have the end of the story.
Why R3 do not forward the packet from s0/1 to s0/0 ?


Hello Dominique

You are correct! Assuming that H1 and H2 are in the same multicast group, R3 will also flood traffic towards R2. However, just like R3 has pruned the traffic coming from R2 due to the RPF check, in the same way R2 will prune flooded multicast traffic coming from R3. The result will be that the S0/1 interface of R2 will be pruned, as will the S0/0 interface of R3. So initially, you will have one multicast packet flooded between R2 and R3, but they will be immediately pruned due to RPF.

This very situation is described in the lesson, under the PIM Graft Message section. You will notice that after H3 has been placed in the same multicast group as H2, the topology is exactly the same as that in your diagram. If you look closely at the output of the show ip mroute command in all three routers, you will see that the Gi0/2 interfaces of both R2 and R3 are pruned.

I hope this has been helpful!


thanks Laz , very well accepted solution
may i ask another question ?
because when you enter in multicast, you have some basic questions before you dive deeper in multicast
For exemple, when a lesson introduce dense mode versus sparse mode, you learn that a router designed in dense mode forward the multicast packets on all its interfaces (although this behavior is restricted by split horizon and RPF)
So, in this case, the first question that is triggering is: why do we need a multicast routing protocol in dense mode ? is it just for prune messages ? is it because in the real world , dense mode cannot exist without sparse mode ?

Hello Dominique

PIM dense mode is a simpler implementation of multicast because it doesn’t require any hierarchical organization of routers. All routes forward multicast traffic, except for traffic pruned by the mechanisms described. The configuration is the same in all routers, and it is generally a flat configuration implementation.

This is a good solution for small networks that require multicast. How small? Well it depends on the volume of traffic, and the number of sources and receivers. The larger the network, the more sources and receivers, the more multicast traffic you will have, and the more strain you will put on network resources. There comes a threshold where dense mode is too inefficient to scale to larger sized networks, and this is where sparse mode comes in.

In sparse mode, we have a hirearchical structure with the use of Rendezvous Points (RPs) which is a point on the network to which all multicast traffic is forwarded, and from which multicast traffic is requested. This makes multicast more scalable, but also makes its configuration more complex.

So to answer your question, dense mode is a perfectly good solution for smaller networks, but it is not as scalable due to the fact that traffic is flooded and pruned. Sparse mode is a more scalable solution for larger networks, because it sends multicast traffic only to those that request it.

I hope this has been helpful!