Multicast RPF Failure: Recovery Using IGP Routing

In the previous post in this series, I introduced the concept of IP multicast RPF. In this blog we’ll examine what happens when we experience RPF failure and how we can use routing protocol to recover from it. 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
!

R3:

R3#show ip pim interface

Address          Interface                Ver/   Nbr    Query  DR     DR
                                          Mode   Count  Intvl  Prior
192.168.0.3      Loopback0                v2/S   0      30     1      192.168.0.3
192.168.34.3     Serial1/0                v2/S   1      30     1      0.0.0.0
192.168.23.3     Serial1/1                v2/S   1      30     1      0.0.0.0

R3#show ip pim neighbor
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
      P - Proxy Capable, S - State Refresh Capable, G - GenID Capable
Neighbor          Interface                Uptime/Expires    Ver   DR
Address                                                            Prio/Mode
192.168.34.4      Serial1/0                01:17:08/00:01:15 v2    1 / S P G
192.168.23.2      Serial1/1                01:17:22/00:01:37 v2    1 / S P G

Next thing, let’s see what happens when we try to ping multicast group joined by R4 on Loopback0 (239.4.4.4) from R1.

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:
.

R1#mtrace 192.168.12.1 192.168.0.4 239.4.4.4
Type escape sequence to abort.
Mtrace from 192.168.12.1 to 192.168.0.4 via group 239.4.4.4
From source (?) to destination (?)
Querying full reverse path... * switching to hop-by-hop:
 0  192.168.0.4
-1  * 192.168.43.4 None No route

We can see that the ping is failing. After testing with mtrace command, we see that it reports “No route” at R4. This tells us that we are dealing with RPF failure. Let’s go to R4 and see what we can see there.

R4:

R4#show ip route 192.168.12.1
Routing entry for 192.168.12.0/24
  Known via "ospf 1", distance 110, metric 138, type intra area
  Last update from 192.168.43.3 on Ethernet0/0, 00:33:22 ago
  Routing Descriptor Blocks:
  * 192.168.43.3, from 192.168.0.2, 00:33:22 ago, via Ethernet0/0
      Route metric is 138, traffic share count is 1

R4#show ip rpf 192.168.12.1
 failed, no route exists

We can see that we have unicast route back to R1, but that “show ip rpf” is reporting no route. We already knew this, but let’s try to prove without dount this is what we’re dealing with. Time to debug.

R4:

R4#debug ip pim bsr
IP multicast packets debugging is on

After maximum 60 seconds, we’ll see a log message telling us something like this.

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

When we run the relevant command “show” commands on R4, we’ll indeed see that we don’t have BSR and RP information.

R4:

R4#show ip pim bsr
PIMv2 Bootstrap information

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

Since we’re using OSPF as our IGP and OSPF derives its metric directly from interface bandwidth, it’s perfectly normal that paths to all destinations are preferred on Ethernet0/0 over those sam routes on Serial1/0. The simplest possible fix for our RPF failure here is to change metrics to make R4 prefer Serial1/0 instead Ethernet0/0.

R4:

interface Ethernet0/0
 ip ospf cost 128
!

After few seconds, we should be getting new log message from our debug:

 PIM-BSR(0): 192.168.0.2 bootstrap forwarded on Loopback0
 PIM-BSR(0): bootstrap (192.168.0.2) on non-RPF path Loopback0 or from non-RPF neighbor 192.168.34.3 discarded

We can safely ignore the message about BSR message being discarded on Loopback. This message is in fact telling us that BSR message was accepted and is being forwarded by R4. Let’s make sure.

R4:

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

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:01:51, expires: 00:01:36

Furthermore, our RPF towards the source (R1′s Serial1/0) should no longer be failing.

R4:

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: unicast (ospf 1)
  Doing distance-preferred lookups across tables
  RPF topology: ipv4 multicast base, originated from ipv4 unicast base

Finally, let’s verify if our solution worked.

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

While this solution cannot be simpler, there are few caveats. First of all, this solution will affect the path of unicast traffic from R4 to the rest of the network. While in the CCIE lab this may not be such a big deal, barring restrictions, it’s definitely not something you should do in real life. In CCIE lab however, there is another reason why not to use this particular solution.

Hopefully by the time you are doing IP multicast tasks in the lab, your IGP is working perfectly, redistribution is in place and entire network is reachable. In other words, you have converged and stable network. Using ancient principle of networking “if it ain’t broken, don’t fix it”, modifying IGP configuration and changing things could be risky and is better avoided.

For these reasons, next time we’ll use a completely different solution.

Happy studies!

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

Multicast RPF Failure: Recovery Using IGP Routing, 4.2 out of 5 based on 5 ratings

Tags: CCIE Routing and Switching, CCIE Security, CCIE Service Provider, multicast, RPF, RPF Failure