This topic is to discuss the following lesson:
1 Like
Lovely… Nice and neat
R2#show ip route ospf
3.0.0.0/32 is subnetted, 1 subnets
O 3.3.3.3 [110/11] via 192.168.32.3, 00:00:02, FastEthernet0/1
How it will reach via Fa0/1, it was connected s0/0 and also there no Fa0/1 in R2. Please check this and update the same…
In the picture was an incorrect interface number, I just fixed it.
Good one.
Hello Rene,
Could you please explain the ip dense mode and igmp ? kind of confused on this one. Thanks
Hi Ammar,
I will add some posts on the basics of multicast soon, this will include PIM sparse, sparse-dense and dense mode. I’ll also explain what IGMP is about.
Rene
Thanks Rene, appreciate it
Hi Rene,
My question is in the example of dense mode RPF. Why is R2 using the serial interface to send the pim packet? With what mechanism it chooses the serial interface rather than FastEthernet? If R2 chooses the Fa interface from the beginning, there will be no problem at all. That causes my confusing, if you can explain this then it helps me to understand better about RPF check failure. Thank you!
dense-mode is enabled for both of the interfaces. I am thinking in the lab could it be a requirement that don’t use ip mroute to fix the problem. I am thinking to disable the ip pim dense-mode under serial interface. But are there any options to manipulate this?
R2(config)#interface fastEthernet 0/0
R2(config-if)#ip pim dense-mode
R2(config-if)#exit
R2(config)#interface serial 0/0
R2(config-if)#ip pim dense-mode
Aha, I saw it, you did not enable ip pim under fa interface of R3. That is why the problem occurs. But still assume you have enable pim for both interface, by what method will R2 to choose one interface over the other?
Hmm, after a second thought, if you have enable both interfaces for r3 and r2, there should not be any problem, since RPF check failure, R3 will drop the “wrong” interface, in another word FA interfaces will be the winner of forwarding pim packets. So I should say if you have enable ip pim for all interfaces, there should not be any problem for multicast?!
Hi Jie,
In this example, we used a FastEthernet and Serial interface, both advertised in OSPF. R2 will prefer the FastEthernet interface to forward all traffic.
To “simulate” an RPF failure, I only enabled PIM for the serial interface. R3 will receive multicast traffic on its serial link, does an RPF check and concludes that it wants to use the FastEthernet interface to get to the source. As a result, the multicast packet is dropped.
When you enable PIM on all interfaces then this problem doesn’t occur since multicast traffic will be received on the FastEthernet interface which passes the RPF check.
Hope this helps!
Rene
2 Likes
Hi Rene,
What if the cost of both (FastEthernet and Serial links) are the same. In this scenario, there will be ECMP towards the source. Here, there will be both the entries in the unicast routing table. Now, even if the multicast traffic comes on the serial link, RPF check will still pass, is that right?
Thanks.
Hi Parth,
RPF will pass but not for both links. By default, the RPF check will be done for the neighbor with the highest IP address. This means that by default, ECMP multicast load balancing is disabled.
For example, let’s say there are two routers…R1 and R2. Between R1 and R2 we use two interfaces. These interfaces have the same metric in whatever IGP we are using. Let’s say R1 has IP address 192.168.12.1 and 192.168.21.1 on these interfaces.
R2 will then send the PIM join to the highest IP address PIM neighbor, 192.168.21.1. That’s the interface that will be used to receive multicast traffic.
Rene
1 Like
Hi Rene,
Why do I need to use a mroute static route rather than a unicast static route. Doesn’t RPF check the unicast table?
1 Like
Hello Rohini
It is possible to fix this problem by changing the unicast routing table by adding a static unicast route. However, this is not advisable in the specific topology because we want all unicast traffic to go over the FastEthernet link and not the serial link. We would like to make the RFP neighbour 192.168.32.2 (the serial link) rather than 192.168.23.2 (FastEthernet link) and maintain unicast routing via the FastEthernet link.
By adding the static route in the multicast table, unicast routing remains on the FastEthernet link and the RFP neighbour changes to 192.168.32.2 (serial link) thus achieving the desired result.
I hope this has been helpful!
Laz
2 Likes
Hello Rene,
in case we have 2 wan links with the same ISP, running eBGP and using ISP for Multicast web service, how will PIM choose the active interface for traffic forwarding to the other location considering symmetric traffic as multicast is UDP?
Hello Prashant,
If you have two links and your routing protocol uses ECMP (Equal-Cost Multipath Routing) then this doesn’t mean that PIM will use both paths automatically.
By default, PIM will forward traffic on the interface where you have the highest IP address PIM neighbor. For example, if you have R1-R2 with two links and R2 has 192.168.12.2 on link 1 and 192.168.21.2 on link 2 then the second link will be used to forward multicast traffic.
Also, keep in mind that multicast isn’t really a thing on the Internet. Out of the box, BGP also doesn’t use multiple paths but that’s something you can configure:
Hope this helps!
Rene
2 Likes
Rene,
In this lesson, I don’t understand the first part (Data plane failure). We receive Unicast/Multicast on the same fastEthernet link. Could you explain me more plz?
Thanks,
Ulrich
Hello Ulrich,
On the Fa0/1 interface of R2 we don’t have PIM so we don’t send any multicast traffic on this interface and there is no PIM neighbor adjacency through this link. However, OSPF uses this link to forward traffic which is why we get the RPF failure.
Rene
1 Like