Fixing multicast RPF failure with BGP

• June 12, 2013
• CCIE  
• IOS  
• BGP  
• Multicast  
• RPF failure  

In this post i would like to explain how you can fix a multicast RPF failure using BGP.

If you take a look at the topology in figure 1, we have a network running EIGRP as the IGP

and where R1 advertises its loopback 0 (1.1.1.1/32). R4 also has a loopback 0 with the 4.4.4.4/32 address.

EIGRP adjacencies are running between R1 and R2, R1 and R3, R2 and R3 and finally R3 and R4.

Basically on all links in the topology.

Figure 1

Everything is working fine and we can verify that we have reachability through the network using icmp echo between R1 and R4:

R1#ping 4.4.4.4 so loo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/59/96 ms

To create the multicast network, we enable multicast routing on all the routers and enable

pim sparse-mode on all links except the R1 to R3 link! (remember to include the loopbacks).

Rx(config-if)#ip pim sparse-mode

To simulate traffic, R1 will be the source and R4’s loopback will be the receiver, so on R4, lets join

239.1.1.1:

R4(config-if)# ip igmp join-group 239.1.1.1

What we end up with is a PIM topology as in figure 2.

Figure 2

Now what we want to do is make R1 our RP using BSR. What will happen is that R3 will receive a BSR

message on its f2/0 interface and determine that its not the RPF interface it should be getting this message on.

That would instead be f1/0 as per the IGP.

Using “debug ip pim bsr” a message will appear on the console:

*Jun 12 11:07:20.063: PIM-BSR(0): bootstrap (1.1.1.1) on non-RPF path FastEthernet2/0 or from non-RPF neighbor 0.0.0.0 discarded

This basically renders our multicast network incomplete as R3 and R4 wont have any RP.

So lets fix it!

On R2 and R3 we enable BGP with the multicast address family:

R2:

router bgp 100
no bgp default ipv4-unicast
bgp log-neighbor-changes
neighbor 10.2.3.3 remote-as 100
!
address-family ipv4
no synchronization
no auto-summary
exit-address-family
!
address-family ipv4 multicast
network 1.1.1.1 mask 255.255.255.255
neighbor 10.2.3.3 activate
no auto-summary
exit-address-family

R3:

router bgp 100
no bgp default ipv4-unicast
bgp log-neighbor-changes
neighbor 10.2.3.2 remote-as 100
!
address-family ipv4
no synchronization
no auto-summary
exit-address-family
!
address-family ipv4 multicast
neighbor 10.2.3.2 activate
distance bgp 20 70 1
no auto-summary
exit-address-family

So what did we do here. Well for one thing, we are creating an iBGP peering between R2 and R3.

On this peering we are enable the multiprotocol extension for multicast.

Then on R2, we are advertising the 1.1.1.1/32 network as learned through EIGRP.

A similar configuration is used on R3 except we are not advertising anything and importantly we are using the

distance command to set the administrative distance for iBGP routes to 70. This last step would not be nessecary

if we had an eBGP peering instead, since the AD would then already be lower than the IGP learned route.

On R3, we should now see the following:

R3#sh bgp ipv4 mu
BGP table version is 2, local router ID is 10.3.4.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-external
Origin codes: i - IGP, e - EGP, ? - incomplete
Network          Next Hop            Metric LocPrf Weight Path
*>i1.1.1.1/32       10.1.2.1            156160    100      0 i

and using “show ip rpf 1.1.1.1”:

R3#sh ip rpf 1.1.1.1
RPF information for ? (1.1.1.1)
RPF interface: FastEthernet2/0
RPF neighbor: ? (10.2.3.2)
RPF route/mask: 1.1.1.1/32
RPF type: multicast (bgp 100)
Doing distance-preferred lookups across tables
RPF topology: ipv4 multicast base, originated from ipv4 unicast base

As can be seen, R3 now use the BGP learned route through f2/0 to get “back” to 1.1.1.1/32.

And finally, the RP should be installed on both R3 and R4:

R3#sh ip pim rp map
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
RP 1.1.1.1 (?), v2
Info source: 1.1.1.1 (?), via bootstrap, priority 0, holdtime 150
Uptime: 00:52:22, expires: 00:01:51
R4#sh ip pim rp map
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
RP 1.1.1.1 (?), v2
Info source: 1.1.1.1 (?), via bootstrap, priority 0, holdtime 150
Uptime: 00:52:36, expires: 00:01:36

So thats how we would fix a multicast RPF failure using BGP.