Fixing multicast RPF failure with BGP
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 (18.104.22.168/32). R4 also has a loopback 0 with the 22.214.171.124/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.
Everything is working fine and we can verify that we have reachability through the network using icmp echo between R1 and R4:
R1#ping 126.96.36.199 so loo0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 188.8.131.52, timeout is 2 seconds: Packet sent with a source address of 184.108.40.206 !!!!! 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
R4(config-if)# ip igmp join-group 220.127.116.11
What we end up with is a PIM topology as in 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 (18.104.22.168) 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:
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 22.214.171.124 mask 255.255.255.255 neighbor 10.2.3.3 activate no auto-summary exit-address-family
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 126.96.36.199/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 *>i188.8.131.52/32 10.1.2.1 156160 100 0 i
and using “show ip rpf 184.108.40.206”:
R3#sh ip rpf 220.127.116.11 RPF information for ? (18.104.22.168) RPF interface: FastEthernet2/0 RPF neighbor: ? (10.2.3.2) RPF route/mask: 22.214.171.124/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 126.96.36.199/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) 188.8.131.52/4 RP 184.108.40.206 (?), v2 Info source: 220.127.116.11 (?), 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) 18.104.22.168/4 RP 22.214.171.124 (?), v2 Info source: 126.96.36.199 (?), 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.