The source IP address of the PIM join will be the interface that is closest to the RP, its destination will be 22.214.171.124.
It all makes sense now…Multicast isnt that hard once you put it into small pieces. Thanks Rene!!!
In the same topology, if we consider R4 as a PIM router, which is also a DR for the LAN segment connecting R2 and R3 and if there is PIM or IGMP join coming from downstream connected to R4:
Does R4 send PIM joins upstream because it is a DR? what if R4 is non-DR in the LAN segment?
If, R4 is the DR, and it sends PIM join upstream, how will R2 and R3 process the joins, since none of them are DRs?
Thanks in advance
It is no problem if R4 is the DR on the 192.168.234.0/24 segment. It will be responsible for creating the PIM join, which will be forwarded upstream. R2 or R3 will forward it further upstream.
I have two questions :-
1- you said in your answer to Vishal that “R2 or R3 will forward it further upstream”, my question is which one exactly will forward it and depending on what this router is chosen instead of the other one ??
2- Making the priority of the DR 0 mean this router never elected as DR just like in ospf DR election or it mean something else ??
Which router will be chosen depends on what is called the PIM Assert mechanism. You can find detailed information about this at the following lesson:
When you set the priority of a router to 0, this means that it will never become a DR.
I hope this has been helpful!
Thanks @lagapides for your answer,
I know how PIM assert working and it’s to elect one PIM forwarder downstream to the receiver but my question was about PIM join messages, which R4 will forward it upstream to R1 (RP), in this case the process reversed !! is PIM assert working in both cases or there is something else are making the decision ??
It’s the job of the DR (Designated Router) to forward the PIM join upstream.
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 !!!
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 126.96.36.199 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 188.8.131.52 R4(config-if)#ip pim sparse-mode R4(config)#router ospf 1 R4(config-router)#network 184.108.40.206 0.0.0.0 area 0 R4(config)#interface loopback 0 R4(config-if)#ip address 220.127.116.11 255.255.255.255 R4(config-if)#ip pim sparse-mode R4(config-if)#ip igmp join-group 18.104.22.168
Here’s how R4 reaches the RP:
R4#show ip route 22.214.171.124 | include via Known via "ospf 1", distance 110, metric 3, type intra area 192.168.234.3, from 126.96.36.199, 00:04:57 ago, via FastEthernet0/0 * 192.168.234.2, from 188.8.131.52, 00:04:57 ago, via FastEthernet0/0
There are two routes but RPF only chooses one:
R4#show ip rpf 184.108.40.206 RPF information for ? (220.127.116.11) RPF interface: FastEthernet0/0 RPF neighbor: ? (192.168.234.3) RPF route/mask: 18.104.22.168/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!
That was very helpful.
Thank you @ReneMolenaar now everything is clear indeed.
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?
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:
So HSRP and PIM can work together nicely. Another good example is PVST and HSRP…those two you have to align yourself.
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.
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.
In our network there are two lines going to the exchange
we have configured VRRP on SW1 and SW2. We did not set the PIM DR priority so at the moment SW1 is master but but SW2 is DR because of highest IP.
on weekend the secondary line to exchange goes down so fail-over did not occur. Is it simply because the outside interface went down and SW2 was still DR ? and we should set the PIM DR priority on SW1 to make it DR as well as MASTER ?
Failover did not occur because of above mentioned issue ? or i have to configure something like tracking object in VRRP ?
or something VRRP redundancy dr ? but problem is that it is arista device.
please kindly help
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!
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.
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?
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.