When you say flood out all interfaces, dose this include directly connected interfaces that have subnets? What happens if a router has a subnet that dose not have any members wishing for a multicast? Dose the router know to not forward it or dose it get flooded out anyways?
Hello Patrick
The example shown in the lesson refers to a hypothetical situation. Rene uses this to help us understand how PIM dense mode works. The diagram is the following:
Initially, PIM dense mode floods multicast traffic out of all router interfaces. All interfaces, without exception. This hypothetical situation however is not acceptable because it results in loops. Therefore PIM dense mode also has a pruning mechanism that deals with these potential loops. If there is a router that is not interested in the multicast traffic, it will send a prune message to its upstream router. This flood and prune behavior will result in something like this:
Now, what about router interfaces connected to LANs with multiple hosts? If a router has such an interface and it receives no join messages from the LAN, then it will know that no one is interested in this traffic and will send a prune message upstream, stopping multicast traffic from being sent.
For example, router R3 in the above diagram has a network connected to it, but no host on that network is requesting any multicast traffic. R3 will send a prune message to R2, thus blocking any flooding that may take place. Once a host on that subnet sends a join message, R3 will update R2 that it is now interested in the traffic, and thus R2 will begin flooding out of the appropriate port.
Does that make sense?
I hope this has been helpful!
Laz
For example if we have an interface in the OIL that is in prune/dense , and its timers is uptime 30 min (i guess that means that entry was added 30 min ago, thatâs right ?) and the expire timer is 2 min 30 secs and indeed after that time it expires because no prune msg was received⌠that interface will change it states to forwarding/dense ?
Hello Juan
Yes that is correct.
Yes that is correct.
As stated in the lesson, PIM version 1 uses a âflood and pruneâ mechanism where after the expire timer expires, it begins to forward again. Once the downstream router receives this, if it doesnât need this traffic, it will send a prune message back stopping the flow once again. This process continues⌠However, PIM version 2 uses a âstate refreshâ system where prune messages are sent periodically. Each time we receive a prune message, the timer is reset to three minutes. With state refresh, prune messages are received before the timer expires, so no flooding occurs.
I hope this has been helpful!
Laz
Hello, I have just one doubt that I would like to clarify to see if I got it right.
This is my topology, R7 is the source, R1 is a client and his gw is GW3.
I am using Dense mode.
There is equal cost path , but the chosen is R7-R5-R4-R3
the flooding is : 5â6, 5----4, 5----2 , then 2 â3 , 6â3 , 4----3 . As far as I understood R3 only chooses one path and validates RPF with that path. So when it receives the notification from 2 and 6 it gonna reject them and send back a prune.
After that R3 should continue flooding to R6 and R2 since their ports should be in forwarding but they will not pass RPF and received a prune back.
The thing is that I am not seeing the last part since I see an assert ( where R7 lost ) that makes R3 change to prune. ( And I understood that assert was only used in domains with more than one router using PIM ). so I am confused here, is R3 changing the ports facing R2 and R6 in prune mode cuz received a prune for RPF or because of the asserted challenge?
( I also captured traffic but only see one prune message on the interface which confused me more )
R3 debug
*Mar 29 00:05:11.853: PIM(0): Send v2 Assert on GigabitEthernet0/2 for 229.7.7.7, source 172.16.57.7, metric [110/5]
*Mar 29 00:05:11.853: PIM(0): Assert metric to source 172.16.57.7 is [110/5]
*Mar 29 00:05:11.853: PIM(0): We win, our metric [110/5]
*Mar 29 00:05:11.853: PIM(0): Schedule to prune GigabitEthernet0/2
^ first we won
*Mar 29 00:05:11.853: PIM(0): (172.16.57.7/32, 229.7.7.7) oif GigabitEthernet0/2 in Forward state
*Mar 29 00:05:11.856: PIM(0): Received v2 Assert on GigabitEthernet0/2 from 172.16.23.2
*Mar 29 00:05:11.856: PIM(0): Assert metric to source 172.16.57.7 is [110/2]
*Mar 29 00:05:11.856: PIM(0): We lose, our metric [110/5]
*Mar 29 00:05:11.856: PIM(0): Prune GigabitEthernet0/2/229.7.7.7 from (172.16.57.7/32, 229.7.7.7)
^ then we lost
`*Mar 29 00:05:11.856: PIM(0): Insert (172.16.57.7,229.7.7.7) prune in nbr 172.16.23.2's queue`
^ I understand that its the timer before putting in the prune ( our interface locally R3 )
*Mar 29 00:05:11.856: PIM(0): Send (172.16.57.7, 229.7.7.7) PIM-DM prune to oif GigabitEthernet0/2 in Prune state
*Mar 29 00:05:11.856: PIM(0): (172.16.57.7/32, 229.7.7.7) oif GigabitEthernet0/2 in Prune state
^ then we prune it. ( our interface locally R3 )
*Mar 29 00:05:11.856: PIM(0): Building Join/Prune packet for nbr 172.16.23.2
*Mar 29 00:05:11.856: PIM(0): Adding v2 (172.16.57.7/32, 229.7.7.7) Prune
*Mar 29 00:05:11.857: PIM(0): Send v2 join/prune to 172.16.23.2 (GigabitEthernet0/2)
^ we sent it to R2 for RPF I guess ??
*Mar 29 00:05:11.872: PIM(0): Send v2 Assert on GigabitEthernet0/6 for 229.7.7.7, source 172.16.57.7, metric [110/5]
*Mar 29 00:05:11.873: PIM(0): Assert metric to source 172.16.57.7 is [110/5]
*Mar 29 00:05:11.873: PIM(0): We win, our metric [110/5]
*Mar 29 00:05:11.873: PIM(0): Schedule to prune GigabitEthernet0/6
*Mar 29 00:05:11.873: PIM(0): (172.16.57.7/32, 229.7.7.7) oif GigabitEthernet0/6 in Forward state
*Mar 29 00:05:11.874: PIM(0): Received v2 Assert on GigabitEthernet0/6 from 172.16.36.6
*Mar 29 00:05:11.874: PIM(0): Assert metric to source 172.16.57.7 is [110/2]
*Mar 29 00:05:11.875: PIM(0): We lose, our metric [110/5]
*Mar 29 00:05:11.875: PIM(0): Prune GigabitEthernet0/6/229.7.7.7 from (172.16.57.7/32, 229.7.7.7)
*Mar 29 00:05:11.875: PIM(0): Insert (172.16.57.7,229.7.7.7) prune in nbr 172.16.36.6's queue
*Mar 29 00:05:11.875: PIM(0): Send (172.16.57.7, 229.7.7.7) PIM-DM prune to oif GigabitEthernet0/6 in Prune state
*Mar 29 00:05:11.875: PIM(0): (172.16.57.7/32, 229.7.7.7) oif GigabitEthernet0/6 in Prune state
*Mar 29 00:05:11.875: PIM(0): Building Join/Prune packet for nbr 172.16.36.6
*Mar 29 00:05:11.875: PIM(0): Adding v2 (172.16.57.7/32, 229.7.7.7) Prune
*Mar 29 00:05:11.875: PIM(0): Send v2 join/prune to 172.16.36.6 (GigabitEthernet0/6)
The same process is now for R6.
Sorry if itâs too long, just wanna know if my understanding is correct or if there is something that I am getting wrong.
Thanks in advance for the help, sorry again for the long post.
( i tried to attach the packet capture but just one file was allowed, the only can see is just one prune message from R2 to R3 and the assert).
Hello Juan
Thanks for the detailed explanation and your well-planned topology. Here are a couple of comments I have that may help you in your thought process:
When R3 receives initial multicast traffic from R2 and R6, it will send an RFP prune because the source (R7) is not reached via those interfaces. However, R3 will not try flooding the multicast traffic out of Gi0/2 and Gi0/8. This is because these interfaces are not considered valid outgoing interfaces for the particular traffic.
Why? Because the router will only forward the multicast traffic received on the interface that passes the RPF check, which in this case is Gi0/4. It will then forward the multicast packet out of all other interfaces that are part of the multicast distribution tree, except for the incoming interface (Gi0/4) and any interfaces that have been pruned or have failed the RPF check (like Gi0/2 and Gi0/8).
In your topology, because there are only point to point connections between routers, PIM assert does not play a role in the behavior of multicast. Assert messages are exchanged, but they do not affect the behavior. It is only the RPF and pruning mechanisms that play a role.
I hope this has been helpful!
Laz
1 Like
Hello Laz, thanks so much for your Answer.
I will not bother too much about dense mode since is nearly deprecated. But Just to try to close my doubt ( I am a curious person sorry in advance hehe ).
so the assert doesnât take relevance in this case and the messages about prune, ( that match with the time are for something else ? there is a way to see when is pruned by RPF in the debug to donât confuse the message as I did ? )
to validate that I got it right :
I received a multicast:
if pass the RPF :
â> Add to the IIL .
not pass the RPF :
â> sent a prune message to the neighbor.
â> Add to the OIL
â> set them as stopped/pruned
so each MRoute entry should be able to see all interfaces that speak PIM.
ok, that was the way I was thinkings.
I am gonna exclude R6 since is the same case as R2.
R3 - Received the multicast traffic from R7 by R4 (s,g) (172.16.57.7,229.7.7.7). He checked The RPF pass without any issue since g0/4 is the interface that he saw in the rib for 172.16.57.7. He considers as downstream to R2, R4, R6, and R1.
R2 - received from R5 the same multicast traffic at the begging from R5 (172.16.57.7, 229.7.7.7) as he received from R5 pass the RPF check. So he considers as downstream to R4 and R3.
In that scenario, R2 sends the multicast to R3. R3 received the traffic and did not pass the RPF, so send a prune message saying, EY I donât want this! ( so R2 put G0/3 in the stop due to the prune).
R3 should send the traffic forward to R2 as well since from his point of view he is downstream or at least is not upstream. So he sent the multicast, to R2, it will not pass the RPF and R2 gonna sent a prune message to R3. R3 put the interface G0/2 to stop/prune.
That is what I understood at the beginning but when I use Wireshark and capture traffic on the interfaces I was only able to see 1 prune packet instead of 2. Thatâs when I start to think about the assert ( That according to what I know is only used in DR election for Sparse-mode to send packets to the RP ).
Thanks very much for the help 
its quiet interesting topic multicast.
Hello Juan
Thanks for the detailed response. It helps me to understand how you are thinking about the whole process. Indeed, multicast is interesting!
Typically in syslogs you would see something like this:
%PIM-5-ASSERT_WON: Assert won on interface GigabitEthernet0/0 for group 239.1.1.1 from 192.168.1.1, our metric [30/0] is better than 192.168.2.1's metric [40/0]
or
%PIM-5-RPF_FAIL: RPF check failed for source 192.168.1.1, group 239.1.1.1 on interface GigabitEthernet0/0
These syslogs identify specifically what process is actually taking place that is affecting the behavior of the device, including the label ASSERT or RPF in the ID of the syslog. In your syslogs this is not the case, and Iâm not sure why. For this reason itâs more difficult to differentiate from what source the pruning took place. However, the timing of the messages does seem to indicate that it is due to the assert mechanism.
In any case, PIM assert will indeed cause pruning even in a point-to-point scenario with only two multicast routers on that particular segment, because of the exchanges of assert messages. However, any resulting pruning will not affect multicast traffic.
In the case where PIM assert messages are exchanged in a point-to-point network and one of the routers loses the election, the router would not prune the interface since there is only one other router connected to it. The multicast traffic would simply flow over the direct path between the routers without creating any duplicate packets.
Pruning however will take place due to the RPF check, and this is what ultimately creates a single multicast path for the traffic in your scenario, and your description of this seems to be correct.
Iâm not sure if the rest of your post constitutes a question or if youâre just sharing your thoughts. If you have a more specific question, feel free to continue the conversation.
I hope this has been helpful!
Laz
Thanks so much for your replies Lazaros it helps me and also makes me more curious to continue reading about this.
And yes I was just sharing my thoughts 
like speaking loudly to see if something new comes to my mind hehe, Itâs my first approach to Multicast in order to go for the ccnp exam. After probably I am gonna return to it deeper :).
Thanks again, And probably see you in another topic around
1 Like
Hi,
I was trying out the PIM dense mode in a LAB and had a question on the outgoing interface list for [*,G] entries in the mroute table.
Q. When a host joins a group using IGMPv2 membership report router is generating a [*,G] entry with outgoing interfaces as all PIM enabled interfaces + the interface on which the interested host was connected to. On the other hand when a host sends multicast traffic into the network, router
generates a [*,G] entry with outgoing interfaces as the only PIM enables interfaces and not the one on which it received traffic.
Can you please explain how outgoing interfaces are decided for [*,G] when router sees multicast traffic vs IGMP join
Thanks in advance!!
Hello Shashidhar
There are two different things taking place here. One has to do with IGMP, and the other has to do with multicast traffic. Letâs take a look at each scenario:
In your first scenario, a router receives an IGMP membership report from a host. The router will indeed generate a [*,G] entry and the outgoing interfaces will be all PIM-enabled interfaces plus the interface on which the report was received.
In your second scenario, you mention that âa host sends multicast traffic into the network.â The important thing to mention here is that, at this point, this host has become a multicast source. In this case, the router receives multicast traffic from this source, and the outgoing interface list is different from the previous one. It only includes PIM-enabled interfaces, without the one on which the router received the multicast traffic. And this makes sense because the router only needs to forward multicast traffic from the source to other interested hosts. Since the source is already on the incoming interface, there is no need to include that interface in the outgoing interface list.
So the outgoing interface list in the [*,G] entry is decided based on whether the router receives an IGMP Membership Report or actual multicast traffic. The former includes all PIM-enabled interfaces and the interested hostâs interface, while the latter only includes the PIM-enabled interfaces.
I hope this has been helpful!
Laz
Hello Laz and Rene
Iâve done a Mcast topology using PIM Dense mode but also iâve used a L2 Switch between a Router running PIM Dense mode and the end-user device (basically a Router Cisco ios , disabling routing) . In the other end of the topology iâve also used a Router disabling its routing features to forward mcast traficc to 239.1.1.1 using icmp like on this lesson.
But if 239.1.1.1 is mapped to 01:00:5E:00:00:01 l2 mcast mac add, at the other end in the L2 Switch before the end device receiving this mcast traffic i should see that mcast mac add in the CAM tbl ? iâve issued the show mac address-table dynamic but iâve seen any mcast mac add such as 01:00:5E:00:00:01 despite the ping to 239.1.1.1 from 192.168.1.100 succeed (end device replied OK) how can i see that mac add in the L2 Switch ?
EDIT : Iâve also tried the show mac address-table multicast but is empty
EDIT 2 : I think iâve missed a key concept. Iâll never see a mcast mac add int the cam tbl because mcast is destination, and the cam tbl is filled only with src mac add.. is this right ? So, whatâs the purpose of show mac address-table multicast and in which scenario we could see a mcast mac add used as src mac add ?
Hello @castrojuanj ,
Switches learn MAC addresses based on the source MAC address.
The key concept to learn here is IGMP snooping:
This is how switches learn what interfaces should receive multicast traffic, and the matching MAC addresses. I explain this in the lesson but hereâs a quick example:
H1(config)#interface GigabitEthernet 0/1
H1(config-if)#ip igmp join-group 239.1.1.1With debug ip igmp snooping 239.1.1.1 youâll see this on your switch:
SW1#
IGMPSN: Received IGMPv2 Report for group 239.1.1.1 received on Vlan 1, port Gi0/2
IGMPSN: group: Received IGMPv2 report for group 239.1.1.1 from Client 192.168.1.1 received on Vlan 1, port Gi0/2
L2MM: Add member: gda:0100.5e01.0101, adding Gi0/1
IGMPSN: mgt: added port Gi0/1 on gce 0100.5e01.0101, Vlan 1
IGMPSN: group: Created group 239.1.1.1
IGMPSN: Add v2 group 239.1.1.1 member port Gi0/2, on Vlan 1
L2MM: Add member: gda:0100.5e01.0101, adding Gi0/2
IGMPSN: mgt: added port Gi0/2 on gce 0100.5e01.0101, Vlan 1
IGMPSN: group: Added port Gi0/2 to group 239.1.1.1
IGMPSN: group: Forwarding 239.1.1.1 report to router portsYou can see it here as well:
SW1#show ip igmp snooping groups
Vlan Group Version Port List
---------------------------------------------------------
1 224.0.1.40 v2 Gi0/1
1 239.1.1.1 v2 Gi0/1, Gi0/2About the show mac address-table multicast commandâŚthatâs a good one. I think this is an older command or platform specific. For example, hereâs a 9200L. This works:
SW1#show ip igmp snooping groups
Vlan Group Type Version Port List
-----------------------------------------------------------------------
20 224.0.1.187 igmp v2 Gi1/0/46
20 239.192.152.143 igmp v2 Te1/1/3
20 230.86.6.15 igmp v2 Gi1/0/46
20 239.255.255.250 igmp v2 Gi1/0/46, Te1/1/3, Te2/1/4
20 239.255.255.253 igmp v2 Te1/1/3
120 224.0.1.187 igmp v2 Gi1/0/37, Gi2/0/2, Te2/1/4
120 239.255.90.90 igmp v2 Gi1/0/6, Gi1/0/7, Gi1/0/19,
Gi1/0/20, Gi1/0/41
120 239.255.255.250 igmp v2 Gi1/0/5, Gi1/0/19, Gi1/0/20,
Gi1/0/48, Gi2/0/2, Gi2/0/24
120 239.255.255.251 igmp v2 Gi1/0/19, Gi1/0/20And this doesnât return anything:
SW1#show mac address-table multicast igmp-snooping
Vlan Mac Address Type Ports
---- ----------- ---- -----I hope this helps!
Rene
1 Like
Hello Lazarus,
Im a bit confused on your statements that Gi0/3 has stopped forwarding multicast traffic for this group. It shows its in the forwarding state, and i thought that in dense mode, an interface in the OIL that is in forwarding mode will always show âstoppedâ in the expiry timer since it doesnât get decremented. But I was under the impression that the âstoppedâ meant what I just mentioned and not that an interface has stopped forwarding multicast traffic for that specific source tree in the mroute table. I thought that in dense mode an interface only stopped forwarding multicast traffic if it showed it was in a prune state.
So shouldnât GI0/3 be forwarding multicast traffic since itâs in forwarding mode?
And shouldnât GI0/2 be the interface that is not forwarding multicast traffic since itâs in the prune state?
Hello Paul
You are indeed correct. The interface in the Forwarding state is indeed forwarding multicast traffic for this particular multicast group, while the interface in the Prune state is not. I have since modified my response in the post above to reflect these changes. Thanks for pointing this out!
I hope this has been helpful!
Laz
Hello Ahmad
If R3 is configured for multicast routing, and the interface on the router connected to H3 is configured with ip pim dense-mode, then the ip igmp join-group command should install a multicast route in the mroute table of R3. I suggest you check to ensure that ip multicast-routing is enabled on R3, and that dense mode is indeed configured on the interface connected to H3. Otherwise, check to see that your connectivity between H3 and R3 is functional. Check these things and let us know how you get along.
I hope this has been helpful!
Laz
Hello, everyone.
In the MC routing table, what exactly do these 2 values represent?
The first one is how long has this router been forwarding multicast traffic out of the relevant interface but what does stopped mean?
It should be the expiry timer, right? But then what is this timer above?
David
Hello David
Take a look at this NetworkLessons note on the timers associated with the mroute table. If you have further questions, let us know!
I hope this has been helpful!
Laz
Hello, everyone.
Could I ask for some more clarification for the Link Recovery section? If a neighbor goes down, does the local router just prune everything out until it receives a GRAFT from someone, or how should I understand this?
Thank you.
David