Contents

Introduction
Use Unicast Routing Table to Resolve Reverse Path
Static Multicast Route (mroute)
MBGP

Introduction

BGP supports Multiprotocol Extension. In this article, Multicast BGP (MBGP), one of extensions of BGP, is discussed. Multicast Routing depends on Reverse Path Forwarding (RPF) to prevent looping. We will discuss how MBGP involve in RPF checking. You should know RPF, AD and the basic configuration of BGP before you read further. You may find tutorials of PIM, AD and BGP in this website.

Use Unicast Routing Table to Resolve Reverse Path

In normal cases, Router use Unicast Routing Table to resolve RPF. However, when there are many paths in the network, it may fail. Please see the following example.

multicast-bgp

The setting of routers at the very beginning are shown below:

hostname R1
!
ip multicast-routing 
!
interface Ethernet1/0
 ip address 192.168.12.1 255.255.255.0
 ip pim dense-mode
!
interface Ethernet1/1
 ip address 192.168.13.1 255.255.255.0
!
interface Ethernet1/2
 ip address 192.168.14.1 255.255.255.0
 ip pim dense-mode
!
router ospf 1
 network 0.0.0.0 255.255.255.255 area 0
hostname R2
!
ip multicast-routing 
!
interface Ethernet1/0
 ip address 192.168.12.2 255.255.255.0
 ip pim dense-mode
!
interface Ethernet1/1
 ip address 192.168.23.2 255.255.255.0
 ip pim dense-mode
!
router ospf 1
 network 0.0.0.0 255.255.255.255 area 0
hostname R3
!
ip multicast-routing
!
interface Loopback0
 ip address 3.3.3.3 255.255.255.255
 ip pim dense-mode
 ip igmp join-group 224.1.1.1
!
interface Ethernet1/0
 ip address 192.168.13.3 255.255.255.0
!
interface Ethernet1/1
 ip address 192.168.23.3 255.255.255.0
 ip pim dense-mode
!
router ospf 1
 network 0.0.0.0 255.255.255.255 area 0
hostname R4
!
ip multicast-routing 
!
interface Ethernet1/0
 ip address 192.168.14.4 255.255.255.0
 ip pim dense-mode
!
router ospf 1
 network 0.0.0.0 255.255.255.255 area 0

As shown, all network are advertised by OSPF. R3's Loopback0 join 224.1.1.1 group. However, PIM is only run on the R4>R1>R2>R3 path, but not on R4>R1>R3. What will happen?

R4#ping 224.1.1.1 repeat 5 
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:
.....

Multicast can not be ping successfully since R3 use Unicast Routing Table to do the RPF checking. R3 use E1/0 to arrive source address 192.168.14.4 because it is the best path told by OSPF. It is not match with the multicast incoming interface E1/1. So, multicast traffic is dropped.

R3#show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       + - replicated route, % - next hop override

Gateway of last resort is not set

      3.0.0.0/32 is subnetted, 1 subnets
C        3.3.3.3 is directly connected, Loopback0
O     192.168.12.0/24 [110/20] via 192.168.23.2, 00:34:57, Ethernet1/1
                      [110/20] via 192.168.13.1, 01:12:46, Ethernet1/0
      192.168.13.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.13.0/24 is directly connected, Ethernet1/0
L        192.168.13.3/32 is directly connected, Ethernet1/0
O     192.168.14.0/24 [110/20] via 192.168.13.1, 00:20:40, Ethernet1/0
      192.168.23.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.23.0/24 is directly connected, Ethernet1/1
L        192.168.23.3/32 is directly connected, Ethernet1/1
O     192.168.34.0/24 [110/30] via 192.168.13.1, 00:20:30, Ethernet1/0
R3#
R3#show ip rpf 192.168.14.4
 failed, no route exists

To solve the issue, we can increase the OSPF cost of E1/0 on R3 so that R3 use E1/1 to arrive 192.168.14.4. It makes RPF checking success.

R3(config)#int ethernet 1/0
R3(config-if)#ip ospf cost 9999
R3(config-if)#end
R3#
R3#show ip route 192.168.14.4
Routing entry for 192.168.14.0/24
  Known via "ospf 1", distance 110, metric 30, type intra area
  Last update from 192.168.23.2 on Ethernet1/1, 00:00:39 ago
  Routing Descriptor Blocks:
  * 192.168.23.2, from 4.4.4.4, 00:00:39 ago, via Ethernet1/1
      Route metric is 30, traffic share count is 1

From the result of show ip rpf, RPF Type is sourced from OSPF Process 1.

R3#show ip rpf 192.168.14.4
RPF information for ? (192.168.14.4)
  RPF interface: Ethernet1/1
  RPF neighbor: ? (192.168.23.2)
  RPF route/mask: 192.168.14.0/24
  RPF type: unicast (ospf 1)
  Doing distance-preferred lookups across tables
  RPF topology: ipv4 multicast base, originated from ipv4 unicast base

Instead, we can use a Static Route pointing 192.168.14.0/24 to E1/1.

R3(config)#ip route 192.168.14.0 255.255.255.0 192.168.23.2

Since the AD of Static Route is 1 which is better than 110 of OSPF. Now, RPF Type is sourced from Static Route.

R3#show ip rpf 192.168.14.4
RPF information for ? (192.168.14.4)
  RPF interface: Ethernet1/1
  RPF neighbor: ? (192.168.23.2)
  RPF route/mask: 192.168.14.0/24
  RPF type: unicast (static)
  Doing distance-preferred lookups across tables
  RPF topology: ipv4 multicast base, originated from ipv4 unicast base

Both of the above methods can make PRF checking successful and multicast ping receives response.

R4#ping 224.1.1.1 repeat 5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:

Reply to request 0 from 3.3.3.3, 120 ms
Reply to request 1 from 3.3.3.3, 36 ms
Reply to request 2 from 3.3.3.3, 36 ms
Reply to request 3 from 3.3.3.3, 24 ms
Reply to request 4 from 3.3.3.3, 28 ms

But both of them change the best path of unicast routing and the normal unicast packet traffic flow paths are influenced.

Static Multicast Route (mroute)

A better solution is Static Multicast Route (or mroute). Mroute only change RPF Type but do not have any influence to Unicast Route Table.

R3(config)#ip mroute 192.168.14.0 255.255.255.0 192.168.23.2

Since the AD of mroute is 1 (which is equal to unicast static route) is better that 110 of OSPF, it becomes the source of RPF Type. RPF checking success.

R3#show ip rpf 192.168.14.4
RPF information for ? (192.168.14.4)
  RPF interface: Ethernet1/1
  RPF neighbor: ? (192.168.23.2)
  RPF route/mask: 192.168.14.0/24
  RPF type: multicast (static)
  Doing distance-preferred lookups across tables
  RPF topology: ipv4 multicast base

MBGP

Finally, try to use MBGP to solve the problem. Establish the BGP peers between R2 and R3 first.

R2(config)#router bgp 65002
R2(config-router)#neighbor 192.168.23.3 remote-as 65003
R3(config)#router bgp 65003
R3(config-router)#neighbor 192.168.23.2 remote-as 65002

Configure multicast address-family and advertise 192.168.14.0/24 network.

R2(config-router)#address-family ipv4 multicast 
R2(config-router-af)#neighbor 192.168.23.3 activate 
R2(config-router-af)#network 192.168.14.0 mask 255.255.255.0
R3(config-router)#address-family ipv4 multicast 
R3(config-router-af)#neighbor 192.168.23.2 activate

The BGP AS number is defference between R2 and R3 make it becomes eBGP and have AD 20 that is better than 110 of OSPF. It becomes RPF Type source and RPF checking success.

R3#show ip rpf 192.168.14.4
RPF information for ? (192.168.14.4)
  RPF interface: Ethernet1/1
  RPF neighbor: ? (192.168.23.2)
  RPF route/mask: 192.168.14.0/24
  RPF type: multicast (bgp 65003)
  Doing distance-preferred lookups across tables
  RPF topology: ipv4 multicast base

If iBGP is used, AD of iBGP is 200 which is worse than 110 of OSPF. It will not be RPF Type source. In the following example, AS number of R2 is changed to 65003 to make the BGP be an iBGP.

R2(config)#router bgp 65003
R2(config-router)#neighbor 192.168.23.3 remote-as 65003
R2(config-router)#address-family ipv4 multicast 
R2(config-router-af)#neighbor 192.168.23.3 activate 
R2(config-router-af)#network 192.168.14.0 mask 255.255.255.0
R3(config)#router bgp 65003
R3(config-router)#neighbor 192.168.23.2 remote-as 65003
R3(config-router)#address-family ipv4 multicast 
R3(config-router-af)#neighbor 192.168.23.2 activate

RPF checking fails.

R3#show ip rpf 192.168.14.4
 failed, no route exists

Since PRF checking works similar to unicast routing, it compares longest match before AD. In this scenario, we can increase the length of the advertised network prefix. For example, advertise the host route 192.168.14.4/32. Of course, we need to add the host route in our routing table as well as in order to fulfill the BGP advertising algorithm.

R2(config-router)#address-family ipv4 multicast 
R2(config-router-af)#no network 192.168.14.0 mask 255.255.255.0
R2(config-router-af)#network 192.168.14.4 mask 255.255.255.255
R2(config-router-af)#exit    
R2(config-router)#exit
R2(config)#ip route 192.168.14.4 255.255.255.255 192.168.12.1