Multicast Tunnel RPF Failure

This topic is to discuss the following lesson:

Will this issue not arise in tunnel intended to pass both Unicast and Multicast?

Hello Deep

First of all, one major difference between unicast and multicast routing is that for unicast routing, we only care about the destination and how to get there. For multicast routing, we care about the source as well. PIM uses the unicast routing table to check what interface will be used to reach the source. More on this can be found at this lesson.

Now to your question. If a GRE tunnel is used only for multicast traffic, then there will be no unicast routing
information concerning routes over the GRE tunnel. Therefore you will run into the RPF problem. If you do use unicast over the GRE tunnel, unicast routes will be available and you will not have the RPF problem.

I hope this has been helpful!


1 Like

PIM sparse solution:
In R2 conf you have:

ip mroute
ip mroute
ip route

If you wouldn’t have “ip mroute” your unicast would go by the traditional path instead of the tunnel. Isn’t it? And in that way it wouldn’t work, am I right?

Then in R1 you don’t have any ip mroute. Should we also route the unicast traffic by the tunnel?

If we have a bidir multicast implementation with a GRE tunnel, would it work? But in that case my question about mroute in R1 would make sence, isn’t it?

Hello Miguel

First of all, remember that the mroute commands refer only to multicast traffic, so whether you implement the ip mroute command or not will not affect the unicast traffic.

This command is implemented in order to verify that the RPF check is passed. The RPF check essentially checks to see if the source IP address of the multicast traffic is reachable via a routing entry in the routing table that matches the interface via which the packet entered the router. If this check is not passed, the packet is dropped. In order for this check to be passed, the ip mroute command is implemented, thus satisfying the requirements of the check.

Once again, the mroute commands do not apply to unicast traffic. However, in order for unicast traffic to successfully traverse the tunnel, the appropriate routes must be installed in the routing table.

Remember that the above command was implemented not to enable bidirectional multicast traffic, but to satisfy the RPF check. If the RPF check is satisfied, then multicast will function correctly over a GRE tunnel.

I hope this has been helpful!


Thanks for your explanation.
I understand better the use of ip mroute.

But I still have 2 questions:

  1. In the case you have R1-R2-R3*(RP)-R4-R5, with senders and receivers in all R%, would you have to configure ip mroute in R1,R2,R4 and R5?

In the case you have many senders and receivers in both sides R1 and R2, and a tunnel between them, would you recommend to implement pim sparse-dense mode or bidir multicat implementation?

I have in the lab 2 L3 in this config:
I have R1 and R2 with pim sparse-dense-mode + ip routing
I used:

ip routing
ip multicast-routing distributed

router eigrp 100

I didn’t use ip mroute. And even having senders and receivers in both sides they were communicating well in multicast.
why didn’t I need ip mroute?

Hello Miguel

The mroute command to take care of the RPF failure should be configured only on routers that terminate a GRE tunnel, and that have multicast receivers connected to them. Remember the configuration is done only to solve the RPF failure that occurs at the end of a GRE tunnel.

In your scenario, the most likely case is that the RPF condition is met, and so you don’t need to add any additional mroute commands. To verify this in your setup, check to see if the RPF condition is met in your routers. Remember that the RPF check ensures that a route to the source IP of a packet exists using the interface from which the packet entered the router. More about the RPF check can be found at the Multicast RPF lesson.

I hope this has been helpful!


Just one more questions regarding this discussion Multiscat tunnel rpf failure:

From S1 and H1 you must ping: Tunnel source, destination and both tunnel IPs.
Is it true? Or not necessarily an obligation.

Hello Miguel

With this configuration, S1 can only ping R1 and the ISP router while H1 can only ping R2 and the ISP router. Because the ISP router doesn’t include a route to full connectivity is not available. Also, S1 and H1 can only ping the tunnel IP on the router they are connected to.

But this connectivity is not necessary to make this topology work. The important thing here is to ensure that multicast routing can occur via the tunnel interface.

I hope this has been helpful!