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 239.1.1.1 command in all three routers, you will see that the Gi0/2 interfaces of both R2 and R3 are pruned.
Hi,
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 ?
Thanks
Regards
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.
In PIM version 1 an interface would be pruned for three minutes. After these three minutes, the traffic would be forwarded again until we send another prune message. This âflood and pruneâ behavior is pretty inefficient so in PIM version 2 use something called âstate refreshâ. Prune messages are sent periodically. Each time we receive a prune message, the prune timer is resetted to three minutes which prevents the âflood and pruneâ behavior.
what u said above in my case its not working
I am using Pim v2 on both routers but "state refresh " not happening after 3 min port went to forwarding state after receiving prune message from downstream router the port goes to prune state.
PIMv2 does indeed support the state refresh feature. By default, Cisco IOS routers are configured to automatically process and forward any state refresh control messages they receive. However, the origination of state refresh control messages is disabled by default. According to this Cisco documentation, in order to enable the sending of state refresh messages, you must issue the following command on the interfaces of a router that are facing the source of the multicast traffic:
Router(config-if)# ip pim state-refresh origination-interval [interval]
where [interval] is the interval in seconds between each control message. By default, this value is 60, but can be anything between 4 and 100. Of course, it makes sense that this value is less than 180, which is the three-minute prune timer.
In the case of the topology of this lesson, this command should be implemented on the Gi0/1 interface of the R3 router, so that the connected Gi0/2 interface of R1 gets these control messages and remains pruned.
Hi,
I did a lab just like yours. R10 is the source. R6 & R4 are the receivers. However, when I do âshow ip mrouteâ, the output is different than yours.
R3#show ip mroute 239.1.1.2
(*, 239.1.1.2), 03:33:40/stopped, RP 0.0.0.0, flags: DC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/0, Forward/Dense, 02:47:26/stopped
Ethernet0/2, Forward/Dense, 03:33:40/stopped
Ethernet0/1, Forward/Dense, 03:33:40/stopped
(10.1.101.10, 239.1.1.2), 00:00:11/00:02:48, flags: T
Incoming interface: Ethernet0/1, RPF nbr 10.1.13.1
Outgoing interface list:
Ethernet0/2, Forward/Dense, 00:00:11/stopped ### 1. what does this stopped mean?
Ethernet0/0, Prune/Dense, 00:00:11/00:02:48, A
From the output, except (10.1.101.10, 239.1.1.2) entry, thereâs also (, 239.1.1.2). Whatâs the purpose of (, 239.1.1.2)?
One more question is why would assert election happens between R2 eth0/1 - R3 eth0/0 but not the other links?
The timers that appear in the Outgoing Interface List show two things: Uptime/Expires. Uptime indicates how long the entry has been in the IP multicast routing table. The Expires indicates how long until the entry will be removed from the IP multicast routing table.
However, for dense mode, the timers act a little differently. The expire timer does not decrement. Dense mode assumes all interfaces are in the forwarding state, so they donât expire. Therefore, in such cases, in some IOS versions, it says âstoppedâ and in others, it simply says 00:00:00.
However, when in a pruned state, the expiry timer does have meaning, and that is why you see it on the pruned interface. It is set to 3 minutes and starts counding down.
This is an excellent question. Actually, when using dense mode, you should simply ignore those entries. Theyâre only used in PIM sparse mode because they represent a shared tree. Theyâre there in dense mode simply to maintain consistency in the mrout output. If you want to get a little more technical about how IOS works, these entries are actually used as templates, and the subsequent (S,G) entries are actually cloned off of these templates.
A PIM Assert election will take place when two routers see each otherâs multicast traffic. In your scenario, This will take place only on the link between R3 and R2. Remember the flow of multicast traffic comes from R10, through R1, and goes to both R2 and R3. Multicast traffic does not flow back to R1, so the pairs of routers on the R1-R2 and R1-R3 links will never âsee each otherâs multicast trafficâ like R2 and R3 will. Remember, when two routers see each otherâs multicast traffic on the same segment, this will trigger the PIM assert mechanism.
You can find out more about it at the following lesson:
R1 is forwarding traffic on its Gi0/1 interface that is connected to R2. It has been doing this for one minute and 16 seconds and there is no expiry. It will keep doing this until it gets pruned.
R1 has stopped forwarding traffic on its Gi0/2 interface since it is pruned.
To:
R1 is forwarding traffic on its Gi0/2 interface that is connected to R2. It has been doing this for one minute and 16 seconds and there is no expiry. It will keep doing this until it gets pruned.
R1 has stopped forwarding traffic on its Gi0/1 interface since it is pruned.
Notice here that on R1, it is indeed Gi0/1 that is forwarding traffic. Notice the Forward indication in the OIL. Also note, that it is Gi0/1 that is connected to R2 as mentioned in Reneâs statement. Also notice the time of 1:16 which is the duration of forwarding, and the stopped statement indicating there is no expiry.
Secondly, R1 has indeed stopped forwarding traffic on its Gi0/2 interface, since it says Prune in the OIL for Gi0/2.
Hello, I noticed this section reads âAbove you can see that this is a unicast packet from R1 to R3.â However should it read âAbove you can see that this is a unicast packet from R3 to R1.â? It appears this packet is originating from R3.
==========
Hereâs what these packets look like in wireshark. First the graft message:
Multicast Pim Dense Graft Packet
Above you can see that this is a unicast packet from R1 to R3. In the graft message we find the group address and source that we want to receive. Below you can see the graft acknowledgment:
For the benefit of our readers I will restate your question in English:
Multicast is a feature that is configured on routers so that when they route multicast traffic, they can take a single stream of packets, and duplicate them whenever necessary so that they reach all intended multicast receivers. This feature of multicast is only configured on a router because only routers perform this function.
Hosts that want to participate in multicast need only send an IGMP join message to let the multicast routers know that they want to receive multicast traffic. No other multicast configuration is necessary on a host. Hosts donât route multicast traffic, they simply announce themselves as receivers of multicast traffic.
In red line meaning, âwhen we donât forward any packets for 1 minute and 49 seconds then this entry will be removed from the multicast routing tableâ. is that correct? what is the expiry time for this red line?
In blue line, what is expiry time for prune state? is it three minutes or 210 seconds?
Yes, the timer with the red underline shows how long before the entry will be removed if no further multicast traffic to that group is received. If multicast traffic to that group is received before the timer expires, the timer will be reset.
The timer with the blue underline is the âprune timer.â This is a timer that is reset whenever it receives a prune message from upstream, and it is specific to the interface indicated. Once a prune message is received, that interface is pruned and stops forwarding traffic for this particular multicast group, and for the time period indicated. Youâll notice that Gi0/2 shows âPruneâ in its state, which means that the interface is no longer sending out multicast traffic to this group. But Gi0/3 is (Forward state), and will continue to do so until it too is pruned. Typically, the prune timer is initially set to a value of 180 seconds or 3 minutes, but this can be adjusted.
Yes, the expiry timer is indeed 180 seconds by default. The only way that timer may be longer is if it was configured longer. But you say that the value of the timer was not changed, so it should still be the default.
Take a look at this command reference to see how the value of the timer can be changed:
I suggest you do some troubleshooting to see what value has been set. Look at the config of the device to determine that. If the default is still at 180 seconds and yet the expiry timer on the interface is larger, it may mean that there is an issue. I see that the interface is a port-channel interface as well, which may also contribute to the issue.
More troubleshooting is needed to determine where the problem is. Take a look at the above mentioned issues and see if they give an explanation. If not, let us know more about your setup so that we further help you to troubleshoot.
