Thanks Rene, appreciate it
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?!
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!
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?
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.
Why do I need to use a mroute static route rather than a unicast static route. Doesn’t RPF check the unicast table?
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!
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?
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!
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?
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.
is this correct? i think its a mistake, its should as in the output of the command 192.168.32.2 not 192.168.23.2…
(192.168.12.1, 22.214.171.124), 00:04:42/00:02:59, flags: LT Incoming interface: Serial0/0, RPF nbr **192.168.32.2**, Mroute Outgoing interface list: Loopback0, Forward/Dense, 00:04:42/00:00:00
See the RPF neighbor above? It now says 192.168.23.2 which is the IP address on the serial link of R2. As a result, our multicast traffic is now being accepted:
You are correct. The text should read:
See the RPF neighbor above? It now says 192.168.32.2 which is the IP address on the serial link of R2. As a result, our multicast traffic is now being accepted:
I will let @ReneMolenaar know.
Thanks for reporting this Samer, I just fixed it.
Thanks for this RPF failure lesson, it was useful. if possible can you explain what do you mean by DataPlane and control place RPF failures . Sorry i could not differentiate both the scenarios that you have posted in the topic
The whole concept revolves around the fact that multicast packets received on an interface will be dropped if the source of those multicast packets cannot be reached via that interface (based on the routing table. In other words, if the routing table indicates another exit interface to reach the source, then the packets will be dropped.
Now this is a principle that is valid both for the data plane and the control plane.
In the first example, we have multicast packets arriving on the serial interface of R3, but the routing table says that R1 can be reached via the Ethernet interface, thus the traffic is dropped. Notice that R3 has successfully joined the 126.96.36.199 multicast group. Now this failure occurs on the data plane. In other words, it is actual user traffic that is being blocked by the RPF situation.
In the second example, we see a situation where R2 tries to join the RP for the specific multicast group, but due to the RPF failure, it cannot join the group. So here the failure is in the actual joining of the group which is accomplished using the control plane, that is, packets and communication that takes place between the routers to negotiate multicast groups and parameters. The major difference here is that the failure is due to the fact that R2 failed to join the group, contrary to what happened in the first case, where the router successfully joined the group. So the RPF failure here affected the control plane.
I hope this has been helpful!
A thing that I noticed is that in the data plane failure we are using Dense mode. You can’t reach the source via the rpf interface. The difference in the control plane failure is we are using sparse mode and we can’t contact the RP via the rpf interface.
Yes, you’ve noticed this difference and that’s great. You can see here that RPF is actually something that is useful for both dense and sparse mode, albeit in particular circumstances. Both modes are susceptible to RPF failures, even though dense-mode is more susceptible because, by default, it sends multicast traffic everywhere (until it is requested to stop). But sparse-mode topologies can also experience an RPF failure if enough devices request multicast traffic to be forwarded to them.
I hope this has been helpful!