Hour 385: Multicast RPF Check and Failure

Multicast RPF failure is one of the things I have struggled the most to understand in my CCIE studies. The concept of RPF failure is actually very simple once you understand how multicast routing works in itself. Hopefully, at this point you have read my other posts on PIM Dense-mode vs Sparse-mode Part 1 and Part 2, my Auto-RP vs BSR post or even my Multicast PIM DR vs PIM Assert post. If you haven’t and don’t have a good foundation of multicast concepts, I would strongly advise you read them.

So what exactly is Reverse Path Forwarding (RPF)? Well, in multicast, a switch will forward packets away from the source to make progress along the distribution tree towards the subscriber. For each hop it crosses, an RPF interface entry will be created in the multicast routing table. In order to avoid loops, every multicast packet received must pass an RPF check before it is eligible to be forwarded on any interface. The RPF check verifies that there is no loop in the network by comparing the incoming multicast packet to the outgoing interface of the unicast route to the source of the packet.  If you have to remember one thing from this post is that the RPF Check will pass when IP multicast traffic will flow from its source to the subscriber on the same path but in the opposite direction that unicast traffic from the subscriber will take to the source.

The number one cause of RPF failure is PIM not being enabled on every interfaces that the unicast traffic is traversing. Let’s take for example this topology:

RPF1

We have PIM enabled between R1 – R2 between R2 – R4. We have OSPF running everywhere. Between R1 – R3 and R3 – R4, PIM is not enabled. The RP is R1 and the Source of the multicast is R1’s Loopback (1.1.1.1). The subscriber of this multicast feed is R4 Loopback (4.4.4.4) on group 239.1.1.1. Multicast is not working in this network. Why? Well let’s find out what is the multicast traffic flow right now.:

RPF2

From it’s source on R1 1.1.1.1 towards the subscriber the outgoing interface is F0/0 (so towards R2).

RPF3

From R2 to the subscriber its outgoing interface is S1/0 (towards R4).

RPF4

And the subscriber on R4 is the loopback so outgoing interface is towards its loopback.

So the multicast path taken from source to subscriber is R1 to R2, R2 to R4 and R4 to R4’s loopback.

Let’s check the unicast path taken from the subscriber to the source.

RPF5

It looks like the unicast path taken from the subscriber to the source is R4’s Loopback to R4, R4 to R3 and R3 to R1.

Does IP multicast traffic flow from its source to the subscriber on the same path but in the opposite direction that unicast traffic from the subscriber will take to the source?

Multicast traffic flow from source to subscriber = R1 to R2, R2 to R4 and R4 to R4’s loopback

Unicast traffic flow from subscriber to source = R4’s Loopback to R4, R4 to R3 and R3 to R1 for unicast

These two do not flow on the same path but in opposite direction and this is why RPF check is failing.

Now there are several different ways that we can fix this. The easiest one is to enable PIM on the unicast traffic flow from subscriber to the source. If this is not an option there are 3 more available ways that I will show you.

  1. Change the unicast routing to reflect multicast traffic flow
  2. Add an exception to the RPF check with static RPF
  3. Change the multicast routing with MBGP

1. Change the unicast routing to reflect multicast traffic flow

This is by far the easiest. I’m running OSPF here so I’ll just increase the cost of the f0/0 link towards the source in order to prefer the R4-R2-R1 path.

RPF6

2. Add an exception to the RPF check with static RPF

For this we will use the “ip mroute” command. You want to add the mroute to be configured towards the source. Since this is multicast, it only has to be configured in one direction not like a static route that needs to be configured in both direction for TCP to work. So the template will be ip mroute <multicast source> <netmask of source> <next hop towards the source>. In this case, I will have to add an mroute on R4 and R2 towards R1.

RPF7

3. Change the multicast routing with MBGP

For this one I will peer eBGP on the routers I want to apply the bypass on and use the multicast address-family to pass traffic. We can redistribute OSPF from the source, generate a default route or use the network command to originate the route. In this example I use the network command to originate the 1.1.1.1 multicast route.

R1:

RPF8

R2:

RPF9

R4:

R10

And now we can see BGP come up and the 1.1.1.1 multicast route being injected up to R4

R8-1

R9-1

R10-1

And of course the multicast test:

RPF11

Note:*We could of used iBGP here too and the reason I chose to do this with eBGP was to simplify things because there is no need to re-advertise the network and change the next-hop information.

In conclusion, in this post I showed you what multicast RPF was, how the RPF check was done and how to fix it with 3 different methods that do not use PIM. I hope this was informative.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s