Multicast RPF Failure: Recovery Using Static RPF

In the first post in this series, I introduced the concept of IP multicast RPF. In the previous one, I explained the solution to the RPF failure using IGP routing. Since that solution affects not only multicast, but unicast routing, it may not be suitable. Today, I will explore the solution to the RPF failure using static RPF verification – also (wrongly) called “static multicast routing”.To examine RPF failure, I will use the same network diagram and the configuration introduced in the original “Multicast Reverse Path Forwarding (RPF) article.

Please, consult that article for startup configurations of routers. I will post the diagram below as a brief reminder.

Before we can recover from RPF failure, we first need to create one. We will disable PIM on the Ethernet segment between R3 and R4 for that purpose.

R3 and R4:

interface Ethernet0/0
 no ip pim sparse-mode
!

In the previous article, Multicast RPF Failure: Recovery Using IGP Routing I covered troubleshooting of RPF failure to some extent. I urge you to read or revisit that article, because I won’t focus on that part here. Instead, I will just briefly provide the solution to the problem using different method.

The goal is to provide the ability of R1 to ping IP multicast group 239.4.4.4 joined by R4 on Loopback0. At this moment, this is failing.

R1:

R1#ping 239.4.4.4

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.4.4.4, timeout is 2 seconds:
.

The reason is RPF failure on R4.

R4:

R4#show ip rpf 192.168.12.1
 failed, no route exists

We want to solve this problem, without affecting unicast routing. Obvious solution is to provide R4 with static information that it is OK to receive multicast packets on a non-RPF interface, in our case Serial1/0 coming from the source. Solution is therefore very simple.

R4:

ip mroute 192.168.12.0 255.255.255.0 Serial1/0

R4#show ip rpf 192.168.12.1
RPF information for ? (192.168.12.1)
  RPF interface: Serial1/0
  RPF neighbor: ? (192.168.34.3)
  RPF route/mask: 192.168.12.0/24
  RPF type: multicast (static)
  Doing distance-preferred lookups across tables
  RPF topology: ipv4 multicast base

We can see that RPF is now successful and that information used is not coming from unicast routing, but from statically configured information. Does our ping work now?

R1:

R1#ping 239.4.4.4

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.4.4.4, timeout is 2 seconds:
.

Still nothing! Why is that? Let’s take a look at R4 a bit more. Does it have information about RP for example?

R4:

R4#show ip pim rp mapping
PIM Group-to-RP Mappings

R4#show ip pim bsr
PIMv2 Bootstrap information

R4#debug ip pim bsr
PIM-BSR debugging is on

Nothing – no information! I enabled debugging and let’s see what happens. Within a minute, we should see an error message.

PIM-BSR(0): bootstrap (192.168.0.2) on non-RPF path Serial1/0 or from non-RPF neighbor 0.0.0.0 discarded

That explains it! We did fi the problem for the source of the traffic we’re interested in, but remember that BSR (and Auto-RP for that matter) messages are also subjected to RPF verification. So, we need to fix that, as well. After we add another static RPF, we’ll wait a minute or so and see the log message telling us that information has been forwarded by R4. We should have both BSR and RP information after that.

R4:

ip mroute 192.168.0.2 255.255.255.255 Serial1/0

R4#show ip pim bsr
PIMv2 Bootstrap information
  BSR address: 192.168.0.2 (?)
  Uptime:      00:00:38, BSR Priority: 0, Hash mask length: 0
  Expires:     00:01:31

R4#show ip pim rp mapping
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
  RP 192.168.0.2 (?), v2
    Info source: 192.168.0.2 (?), via bootstrap, priority 0, holdtime 150
         Uptime: 00:00:42, expires: 00:01:47

R1 should also be able to ping the group at this point.

R1:

R1#ping 239.4.4.4

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.4.4.4, timeout is 2 seconds:

Reply to request 0 from 192.168.0.4, 40 ms
Reply to request 0 from 192.168.0.4, 44 ms

Caveats

The problem with using static RPF is similar to the one with using static routing. It doesn’t really scale well. We’ll need either a static RPF for each source and BSR, or use default static RPF (ip mroute 0.0.0.0 0.0.0.0 …). This may or may not be suitable in your environment. How about in the CCIE lab?

Using “static multicast routes” is one of those things we can say are a little bit of a gray area. While they are technically not routes, using static RPF configuration may be frowned upon and disallowed. I my strong advice is to verify with your Proctor before using them in the exam.

Next time, in the last blog in this series, I will talk about the ultimate solution for RPF failure recovery. The one that does not affect unicast routing and is not static in nature.

Happy studies!

–
Marko Milivojevic – CCIE #18427
Senior Technical Instructor – IPexpert
Join our Online Study List

Multicast RPF Failure: Recovery Using Static RPF, 3.7 out of 5 based on 3 ratings

Tags: CCIE, multicast, multicast rpf, RPF, RPF Failure