Multicast BGP

Hello,

 

In this post I will cover what is known as “Multicast BGP” , why it’s used for and how to configure it.

 

This is one of the topics that if by any chance you encounter it in the CCIE lab you are going to get mad as you might not seeing it in the past or at least provide it the attention needed to such an easy topic but let’s start with the basics: It’s usage.

 

Multicast BGP exist to fix the RPF failures on the network. As simple as that! You can build a BGP relationship between two routers in order to build a Multicast topology that will satisfy the network requirements that the IGP protocols did not satisfy and of course the CCIE did not allow you to create any Mroute.

 

So now that we know why to use it let’s show you our scenario today.

Multicast BGP

 

  • All of the routers are running OSPF as the IGP protocol.
  • There is full reachability across the entire  network.
  • PIM Sparse-Mode will be used.
  • R5 will be the RP Multicast Router (Using loopback 5.5.5.5).
  • R5-R4 have 2 links connecting each other (one is  a FastEthernet link and the other a Ethernet port).
  • The multicast group is 239.1.1.1
  • R5 and R4 are not running PIM on the 100 Mbps link.

 

So where does Multicast BGP fits here????

 

Well check the connections between R5 and R4.

  1. There are two links running OSPF but only one is running PIM.
  2. OSPF uses bandwidth as the metric for path calculation (higher bandwidth = Better metric) .

 

What route do you think R4 will choose to get to either the RP  address or R1 (source of traffic)?

 

Let’s check the routing table of R4 to determine that:

R4#sh ip route 5.5.5.5
Routing entry for 5.5.5.5/32
Known via “ospf 1″, distance 110, metric 2, type intra area
Last update from 192.168.30.1 on FastEthernet0, 00:01:33 ago
Routing Descriptor Blocks:
* 192.168.30.1, from 192.168.40.1, 00:01:33 ago, via FastEthernet0
Route metric is 2, traffic share count is 1

R4#sh ip route 192.168.10.0
Routing entry for 192.168.10.0/24
Known via “ospf 1″, distance 110, metric 21, type intra area
Last update from 192.168.30.1 on FastEthernet0, 00:01:38 ago
Routing Descriptor Blocks:
* 192.168.30.1, from 192.168.20.1, 00:01:38 ago, via FastEthernet0
Route metric is 21, traffic share count is 1

Of course the one with the higher Bandwidth. The problem lies on the fact that PIM is not enabled on that link so any multicast packet received over the link ethernet 0 will be dropped.

R4#sh ip rpf 192.168.10.1
RPF information for ? (192.168.10.1) failed, no route exists
R4#sh ip rpf 5.5.5.5
RPF information for ? (5.5.5.5) failed, no route exists
R4#

 

How to Fix it?

 

Well that’s the whole idea of this post, using Multicast BGP as the routing protocol that will be the source of the Multicast Topology information for R4-R5.

 

Configuration Tasks:

  1. Enable a BGP process and the right neighborhood (BGP Session must be enabled using the interfaces where PIM is enabled)
  2. Establish a BGP session over the multicast address-family.
  3. Make sure you announce the required networks over the BGP session (Make sure you can reach the RP and the Multicast Source).

 

Step 1 and 2 BGP session between the routers where the RPF Failure happens using the Multicast address family.

R5

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

 

R4

router bgp 100

no bgp default ipv4-unicast
bgp log-neighbor-changes
neighbor 192.168.40.1 remote-as 100

!
address-family ipv4 multicast
neighbor 192.168.40.1 activate
no auto-summary
no synchronization
exit-address-family

 

We have disabled the bgp ipv4-unicast process so no sessions are established using the unicast routing table of the devices. We are already running IGP to populate the unicast routing table so no need for this.

 

We must only focus on the Multicast routes.

 

Let’s check if the session was build

R4#sh ip bgp (This command only shows sessions established via the IPv4 unicast database so it’s expected to see no entries)

R4#sh ip bgp all summary (Will show you sessions from all of the address families used in your router)

For address family: IPv4 Multicast
BGP router identifier 7.7.7.7, local AS number 100
BGP table version is 3, main routing table version 3
2 network entries using 234 bytes of memory
2 path entries using 96 bytes of memory

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

192.168.40.1 4 100 10 8 3 0 0 00:05:15 2

 

Now that the session got successfully established it’s time to fix the RPF issue.

 

!Remember that the problem in this lab is that R4 is learning via IGP the IP address of the RP and the source of the multicast traffic but all of this via the link with the highest bandwith (100 Mbps). Problem is that PIM is not enabled on that link and we are not allow to do it.

 

R5  will announce the routes that are failing the RPF check via multicast BGP  and as soon as R4 receives them, they will be considered válid.

 

router bgp 100

address-family ipv4 multicast

neighbor 192.168.40.2 activate
no auto-summary
no synchronization
network 5.5.5.5 mask 255.255.255.255
network 192.168.10.0
exit-address-family

 

After those announcements R4 RPF issues will fade away

On R4

 

R4# sh ip rpf 5.5.5.5
RPF information for ? (5.5.5.5)
RPF interface: Ethernet0
RPF neighbor: ? (192.168.40.1)
RPF route/mask: 5.5.5.5/32
RPF type: mbgp
RPF recursion count: 0
Doing distance-preferred lookups across tables
R4#sh ip rpf 192.168.10.1
RPF information for ? (192.168.10.1)
RPF interface: FastEthernet0
RPF neighbor: ? (192.168.50.1)
RPF route/mask: 192.168.10.0/24
RPF type: mbgp
RPF recursion count: 0
Doing distance-preferred lookups across tables
R4#

 

Time to test the Multicast Network:

R1#ping 239.1.1.1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:

Reply to request 0 from 192.168.40.2, 308 ms

 

That’s it! We have successfully re converged our network without modifying the IGP metrics, setting a static Mroute or enabling PIM on all links.

 

Additional Stuff:

While doing the lab I tried to build the BGP multicast session using as source and remote IP the loopbacks of each R5 and R4. The results were the following:

  • The BGP session was established for the Multicast family as needed.
  • The BGP prefixes were announced.
  • RPF Failure fade away as well (I was able to do a show ip rpf 5.5.5.5 and get a succesful result) but pointing via the 100 Mbps.
  • PIM is still not enabled on that link so Multicast traffic will not flow so this will not work.
  • We must use an IP address that forces both peers to send traffic via the PIM Sparse link.

 

Regards,

iNetworks