Thanks @ReneMolenaar
In your example if the R4 is the DR (Designated Router) so it will create the PIM join message and forward it upstream just like you said, but I need to know to which one it will be forwarded to R2 or R3, that’s it ??? my questions is simple why I did not got clear answer till now !!!
Hi Hussein,
In my example, R4 was only a receiver so it didn’t participate in PIM, which makes R2 or R3 the designated router. When you enable PIM on R4 and it is a DR, it will have two equal unicast routes to 1.1.1.1 so it has to make a choice.
RPF does not use both routes but uses the PIM neighbor with the highest IP address to go upstream.
Let’s look at an example. I’ll turn R4 into a PIM router by enabling it on the FastEthernet0/0 interface. I’ll also create a loopback that will have IGMP join on it so that R4 is the DR for the loopback segment:
R4(config)#interface FastEthernet 0/1
R4(config-if)#no ip igmp join-group 239.1.1.1
R4(config-if)#ip pim sparse-mode
R4(config)#router ospf 1
R4(config-router)#network 4.4.4.4 0.0.0.0 area 0
R4(config)#interface loopback 0
R4(config-if)#ip address 4.4.4.4 255.255.255.255
R4(config-if)#ip pim sparse-mode
R4(config-if)#ip igmp join-group 239.1.1.1
Here’s how R4 reaches the RP:
R4#show ip route 1.1.1.1 | include via
Known via "ospf 1", distance 110, metric 3, type intra area
192.168.234.3, from 1.1.1.1, 00:04:57 ago, via FastEthernet0/0
* 192.168.234.2, from 1.1.1.1, 00:04:57 ago, via FastEthernet0/0
There are two routes but RPF only chooses one:
R4#show ip rpf 1.1.1.1
RPF information for ? (1.1.1.1)
RPF interface: FastEthernet0/0
RPF neighbor: ? (192.168.234.3)
RPF route/mask: 1.1.1.1/32
RPF type: unicast (ospf 1)
Doing distance-preferred lookups across tables
RPF topology: ipv4 multicast base, originated from ipv4 unicast base
It selects R3 since that’s the highest PIM neighbor IP address. If you want to influence this, you have a couple of options:
* Don’t enable PIM on R2’s connection to R3/R4
* Change the IP address on R2 so that it’s higher than R3’s IP address.
* Create a static mroute
The static mroute is a decent option but you’ll lose redundancy since you have to manually change it.
Hope this helps!
Rene
Its seems relatively straightforward when explained. However, may become less so when starting to apply in real world 
. One real world example - client is facing redundant pair of routers with HSRP. Will both routers still participate in DR election? How its going to work then if router with lower IP is the active router? Looks like the joins may not be sent as DR (being passive) will not receive client request and active router will receive it but will not send join to RP, since its not a DR. If thats the case does it mean in HSRP case (which is very often) we always need to manually increase priority on the active router to make it DR and ensure registration with RP?
Hello Vadim,
When you mix certain protocols, things can get interesting 
HSRP and PIM is a good example. The routers will still participate in the DR election since PIM doesn’t know about HSRP.
They thought of this though, take a look at HSRP aware PIM:
https://www.cisco.com/en/US/docs/ios-xml/ios/ipmulti_pim/configuration/15-2s/imc_hsrp_aware.html
So HSRP and PIM can work together nicely. Another good example is PVST and HSRP…those two you have to align yourself.
Rene
Ok, thanks. Giving it a little more thought I guess it can be looked at from the angle that strictly speaking HSRP is a unicast solution - it provides unicast IP that mac addresses of both routers share. So stand-by router does not receive unicast traffic. But it has nothing to do with specifically multicast traffic - for routers to know about multicast client a message is ‘multicast’ to particular vlan, where the clients are. So in essense the HSRP shared IP is not in play here at all, both routers (and clients) don’t use it in this case. Nor HSRP affects any functions of the either router except just providing one more IP (stand-by IP) for them to use (we still can connect to native IP of either router, as well). So whatever router is DR will send join (and any can be selected as forwarding router afterwards). Stand-by IP is not in play here. And clients sends their reports to native IPs of the routers, not stand-by IP.
Thanks
Hi Vadim,
Some protocols (including HSRP) use multicast as a destination to communicate with each other but this traffic only remains within the broadcast domain, it’s not routed between subnets so for this traffic, it doesn’t have anything to do with PIM.
HSRP and PIM work next to each other, they don’t work together in any way. They are independent. You can say that HSRP is a unicast traffic as it’s used to forward unicast traffic.
When HSRP is up and running, you get a virtual IP address that you can use but it’s not required. You can still use any of the real IP addresses of your HSRP routers and they will happily forward any traffic. Since you want redundancy, you’ll use the virtual IP address as the default gateway on your hosts. Your unicast traffic will be forwarded.
When you add PIM and multicast in the mix, it’s possible that your standby HSRP router gets elected as the DR which means that’s the router that forwards multicast traffic. HSRP and PIM run completely independent of each other but it’s best to make sure that the active HSRP router is also your DR, otherwise, you can get some duplicate traffic or issues with failover.
Rene
In our network there are two lines going to the exchange
Hello Azzam
When you had the failure, did it only affect the multicast traffic or all traffic on your network? If it was all traffic, then the issue will not be with the PIM DR priority, but with a more general issue of configuration. With the information that you are providing, my first instinct is that VRRP has been configured without the use of object tracking. So the Internet-facing interface of the secondary link went down, but that did not affect the VRRP configuration, so packets were still being sent to the switch with the failed link. However, if your routing configuration noticed the change in topology, it may have routed traffic to the other switch and out to the internet. How are your L3 switches connected to the ISP? Are you using BGP on the network edge? It all depends on the configuration and how you have it set up.
Take a look at the following lessons that may help you configure the network edge more appropriately.
If you let us know some more information about your topology, maybe we can help direct you in the troubleshooting procedures.
I hope this has been helpful!
Laz
Hi Laz,
Many thanks for the email. I can explain you little bit more about the topology. We have two cross connects going to exchange(Lease lines). One SW1 we created /30 subnet on SVI and made the external physical interface access port as its layer 2.
Same we did for switch 2.
according to VRRP SW1 is master and SW2 is back up
but we forgot to configure the PIM DR priority on SW1 so at the moment it is not DR and SW2 is DR.
we can joins going to sw2 rather than sw1. So when the secondary link went down on weekend, we stopped getting the multicast data from exchange becuase DR was SW2.
Exchange is saying make SW1 as PIM DR it will resolve the issue.
the topology is attached.
Hello Azzam
Thanks for sharing that information. I believe that if you do change the PIM DR to be SW1 that should solve the issue since that switch is the master for VRRP as well. Is that doable or is there another configuration that is conflicting with a change like that?
Laz
Hi Lag,
Many thanks for the reply. I made the priority of SW1 to 15 so when subscribing for the multicast it was going to through SW1 but when exchange disconnected the link between SW1-MASTER & ESW1 the failover did not occur.
I think we need to configure the tracking on the SW1-MASTER so that one primary link to ESW1 goes down the traffic automatically goes to SW2 AND PIM dr will automatically be SW2.
Hi Rene,
Since the PIM join message will be send by the DR. Why the PIM Assert still will be trigger?
Davis
Hello Davis
Remember that the DR is the router that will forward the PIM join message. The PIM Assert feature is used to determine which router will be the multicast traffic forwarder. These are two different things.
The first has to do with the messages that are exchanged between hosts and multicast routers. The second has to do with the path that the actual multicast traffic will take.
So both mechanisms are needed in order to avoid duplicate multicast streams. For more info on the PIM Assert mechanism, take a look at the following lesson:
I hope this has been helpful!
Laz
Thanks for the tutorial Rene, it was helpful.
One question, in that topology where R3 is the DR, if there are hosts connected to R2 and they want to publish or receive any traffic for a multicast group (for example, 239.5.5.5), then does PIM join or PIM register messages go from R2 -> R1 or R2 -> Switch -> R3 -> R1?
Hello Ram
Great to hear the lesson was helpful!
When a host sends a join message, the first multicast router that receives it will forward it to the DR. This forwarding will take place using unicast routing. So if there was a host on R2 that sent a join message, it would reach R2. R2 would then take a look and see where the DR is. The output of the show ip pim neighbor shows us that the DR’s IP address is 192.168.234.3.
Using the unicast routing table, the join message will be sent to this IP address. Just looking at the diagram you can see that this address belongs to a network that is directly connected to the Fe0/1 interface of R2. So in this particular case, the join message will be forwarded by R2 via the switch.
I hope this has been helpful!
Laz
Hello!
With a Hub & Spoke Topology should it seems logical that the Hub will be the PIM DR. Is that a correct assumption?
Thanks,
JB
Hello James
In a hub and spoke topology it would be best practice to have the HUB play the role of the DR. This would be the most efficient choice since it is at the centre of the topology, and can more easily relay the PIM join messages it receives. For this reason, it is a good idea to ensure that the priority set for the DR elections is done in such a way so that the hub is elected. Similarly, it should also be chosen as the Rendezvous Point as well.
Now these roles played by the hub seem kind of trivial in such a topology because the RP is used to relay all multicast traffic (and that should be configured to be the hub router), and the DR is used to relay traffic to the RP (but if the DR is the RP, the point seems to be moot).
These features come into play much more in topologies such as those in this lesson, where there are multiple paths that can be taken between multicast source and destination, as does the issue of PIM forwarder, which is a different issue that can be read about at this lesson.
I hope this has been helpful!
Laz
Thanks for your reply!
JB
Nice lesson Rene. This one line is confusing me a bit though.
"When R4 sends a PIM join message both R2 and R3 would receive it and forward it to R1."
Based on the config, R4 is only acting like a host. PIM-SM is not configured on Fa0/0, and R4 is not configured with the RP address, so R4 would only send an IGMP membership report.
Please can you confirm?
