Multicast RPF Failure: Recovery Using BGP

In the first post in this series, I introduced the concept of IP multicast RPF. In the previous two, I explained the solution to the RPF failure using IGP routing and static RPF. Both of those solutions have serious caveats, amongst others that they may be disallowed in the CCIE lab. Today, I will examine the solution using BGP, or more specifically IPv4 multicast BGP address family.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.

Similar to previous cases, the goal is to have R1 be able to ping 239.4.4.4 multicast group joined by R4 on Loopback0. Since we created RPF failure, this is again 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:
.

R4:

R4#show ip pim bsr
PIMv2 Bootstrap information

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

R4#show ip rpf 192.168.12.1
 failed, no route exists

R4#show ip rpf 192.168.0.2
 failed, no route exists

We need to recover from this situation without affecting unicast traffic, so tweaking OSPF is out of the question. We also can’t use static RPF, so “ip mroute” is also not available. What remains is BGP. The fix is surprisingly easy.

All we have to do is to create BGP session between R3 and R4, enable IPv4 address-family and make sure R4 receives all relevant routes. We need at least route for BSR and the original source. We can either redistribute OSPF, or we can simply originate route using network command, or simply generate the default route. Remember, since this is not unicast routing, default may be perfectly acceptable.

R3:

router bgp 34
 no bgp default ipv4-unicast
 neighbor 192.168.0.4 remote-as 34
 neighbor 192.168.0.4 update-source Loopback0
 address-family ipv4 multicast
  neighbor 192.168.0.4 activate
  neighbor 192.168.0.4 default-originate
!

R4:

router bgp 34
 no bgp default ipv4-unicast
 neighbor 192.168.0.3 remote-as 34
 neighbor 192.168.0.3 update-source Loopback0
 address-family ipv4 multicast
  neighbor 192.168.0.3 activate
!

Let’s see what happens on R4 now.

R4:

R4#show ip bgp ipv4 multicast
BGP table version is 2, local router ID is 192.168.0.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*>i0.0.0.0          192.168.0.3              0    100      0 i

R4#show ip rpf 192.168.0.2
 failed, no route exists

We still seem to have the problem. It’s easily explained why. Take a look at the next-hop for the default route. It’s the Loopback0 of R3. How are we reaching it?

R4:

R4#show ip route 192.168.0.3
Routing entry for 192.168.0.3/32
  Known via "ospf 1", distance 110, metric 11, type intra area
  Last update from 192.168.43.3 on Ethernet0/0, 00:16:54 ago
  Routing Descriptor Blocks:
  * 192.168.43.3, from 192.168.0.3, 00:16:54 ago, via Ethernet0/0
      Route metric is 11, traffic share count is 1

We are reaching 192.168.0.3 via Ethernet0/0, which means that due to recursive lookup, our RPF is still going to fail. This is BGP however, the fix is easy. Watch the magic!

R4:

route-map Fix-Next-Hop permit 10
 set ip next-hop 192.168.34.3
!
router bgp 34
 address-family ipv4 multicast
  neighbor 192.168.0.3 route-map Fix-Next-Hop in
!

R4#show ip bgp ipv4 multicast
BGP table version is 2, local router ID is 192.168.0.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*>i0.0.0.0          192.168.34.3             0    100      0 i

Now the next-hop information for the default route is Serial0/0 on R3. This is much better. Let’s check RPF, BSR and RP.

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: 0.0.0.0/0
  RPF type: multicast (bgp 34)
  Doing distance-preferred lookups across tables
  RPF topology: ipv4 multicast base

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

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

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:43, expires: 00:01:44

This seems to work like a charm. Let’s try pinging 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:

Reply to request 0 from 192.168.0.4, 32 ms
Reply to request 0 from 192.168.0.4, 52 ms

This also worked. Finally, let’s make sure that our unicast routing is unaffected on R4.

R4:

R4#show ip route ospf | begin ^Gateway
Gateway of last resort is not set

      192.168.0.0/32 is subnetted, 4 subnets
O        192.168.0.1 [110/139] via 192.168.43.3, 00:05:46, Ethernet0/0
O        192.168.0.2 [110/75] via 192.168.43.3, 00:05:46, Ethernet0/0
O        192.168.0.3 [110/11] via 192.168.43.3, 00:05:56, Ethernet0/0
O     192.168.12.0/24 [110/138] via 192.168.43.3, 00:05:46, Ethernet0/0
O     192.168.23.0/24 [110/74] via 192.168.43.3, 00:05:56, Ethernet0/0

That’s it for this series on multicast RPF failure and methods to recover from it.

Happy studies!

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

Multicast RPF Failure: Recovery Using BGP, 5.0 out of 5 based on 3 ratings

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