IPv4 BGP multicast

IPv4 BGP multicast announcements can be somewhat confusing.  It took a while to get my head around it, so now that I have, I will try to explain.

I have set up the topology below.

Everything has been configured in the above scenario EXCEPT the IPv4 BGP multicast session between RP and ASBR-RP.  I want to show how you can change the multicast path using IPV4 BGP multicast.

lets start by understanding BGP AS2

The receiver sends a join for group 224.1.1.1, Net-Edge2 receives the igmp join and forwards a PIM JOIN to ASBR-RP.  We can now see a (*,G) entry in the multicast routing table as below.

ASBR-RP#show ip mroute
(*, 224.1.1.1), 00:24:06/00:02:42, RP 4.4.4.4, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet2/0, Forward/Sparse, 00:24:06/00:02:42

Pretty straight forward so far.

Now lets look at BGP AS1 from an IPv4 routing perspective

AS1 runs ISIS as the IGP. IPv4 192.168.1.0/24 and 2.2.2.2/32 prefixes are advertised into ISIS. ASBR1 is the only device which runs BGP in AS1.  ASBR1 then advertises 192.168.1.0/24 and 2.2.2.2/32 to AS2 as IPv4 prefixes.  If we examine the IPv4 routing table on ASBR-RP we can see it has an entry for 192.168.1.0/24 and 2.2.2.2/32 as below.

ASBR-RP#sh ip route 192.168.1.0
Routing entry for 192.168.1.0/24
Known via "bgp 2", distance 20, metric 10
Tag 1, type external
Last update from 10.0.0.1 00:14:09 ago
Routing Descriptor Blocks:
* 10.0.0.1, from 10.0.0.1, 00:14:09 ago
Route metric is 10, traffic share count is 1
AS Hops 1
Route tag 1

ASBR-RP#sh ip route 2.2.2.2
Routing entry for 2.2.2.2/32
Known via "bgp 2", distance 20, metric 20
Tag 1, type external
Last update from 10.0.0.1 00:05:20 ago
Routing Descriptor Blocks:
* 10.0.0.1, from 10.0.0.1, 00:05:20 ago
Route metric is 20, traffic share count is 1
AS Hops 1
Route tag 1

nothing majorly complicated here.

We now setup an MSDP session using the basic config between RP and ASBR-RP using the commands below on RP and ASBR-RP respectivly.

RP

RP#sh run | in msdp
ip msdp peer 10.0.0.6 connect-source FastEthernet1/1 remote-as 2
ip msdp cache-sa-state

ASBR-RP

ip msdp peer 10.0.0.5 connect-source FastEthernet1/0 remote-as 1
ip msdp cache-sa-state

no rocket science here.

Now lets kick off some multicast traffic from the source destined to 224.1.1.1 from 192.168.1.1

We should see an entry in the multicast routing table of RP in AS1.

RP#show ip mroute 224.1.1.1
(*, 224.1.1.1), 00:00:06/stopped, RP 2.2.2.2, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null

(192.168.1.1, 224.1.1.1), 00:00:06/00:02:53, flags: PA
Incoming interface: FastEthernet1/0, RPF nbr 11.0.0.1
Outgoing interface list: Null

Everything good so far.

MSDP should now advertise this source to its peer ASBR-RP in AS 2.  Lets check to see if this has happened.

ASBR-RP#show ip msdp sa-cache
MSDP Source-Active Cache - 1 entries
(192.168.1.1, 224.1.1.1), RP 2.2.2.2, BGP/AS 0, 00:01:50/00:05:29, Peer 10.0.0.5

yep we can see it.

Now lets check to see whether we can see the entry in the mcast table on ASBR-RP.

ASBR-RP#sh ip mroute 224.1.1.1
(*, 224.1.1.1), 00:12:56/00:03:11, RP 4.4.4.4, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet2/0, Forward/Sparse, 00:12:07/00:03:11

(192.168.1.1, 224.1.1.1), 00:12:56/00:03:28, flags: T
Incoming interface: FastEthernet1/1, RPF nbr 10.0.0.1
Outgoing interface list:
FastEthernet2/0, Forward/Sparse, 00:12:07/00:03:11

Yep, we can see it, but notice that the incoming interface is being shown as fastethernet1/1 and the RPF neighbor is 10.0.0.1.  This is due to the fact that the PIM Join message was sent using the ipv4 routing table and as such was routed via the lower link in the diagram.  This is not what we were trying to acheive, we wanted the SPT tree to flow over the upper link, upon which we configured MSDP.  To fix this we simply setup a IPv4 BGP multicast session as follows on RP.

router bgp 1
no bgp default ipv4-unicast
bgp log-neighbor-changes
neighbor 10.0.0.6 remote-as 2
!
address-family ipv4 multicast
neighbor 10.0.0.6 activate
no auto-summary
network 192.168.1.0
exit-address-family

Check on ASBR-RP that the multicast IPv4 prefix is being learnt.

ASBR-RP#sh ip bgp ipv4 multicast
Network          Next Hop            Metric LocPrf Weight Path
*> 192.168.1.0      10.0.0.5                10             0 1 i
ASBR-RP#

Its also worth noting that this prefix does not enter the unicast routing table as you can see below.

ASBR-RP#sh ip route 192.168.1.0
Routing entry for 192.168.1.0/24
Known via "bgp 2", distance 20, metric 20
Tag 1, type external
Last update from 10.0.0.1 00:04:22 ago
Routing Descriptor Blocks:
* 10.0.0.1, from 10.0.0.1, 00:04:22 ago
Route metric is 20, traffic share count is 1
AS Hops 1
Route tag 1

Now if we check the multicast routing table on ASBR-RP we will see the following.

ASBR-RP#sh ip mroute 224.1.1.1
(*, 224.1.1.1), 00:25:48/00:03:06, RP 4.4.4.4, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet2/0, Forward/Sparse, 00:24:59/00:03:06

(192.168.1.1, 224.1.1.1), 00:25:48/00:03:27, flags: T
Incoming interface: FastEthernet1/0, RPF nbr 10.0.0.5, Mbgp
Outgoing interface list:
FastEthernet2/0, Forward/Sparse, 00:24:59/00:03:06

As you can see the incoming interface is now the upper link in the diagram and the RPF neighbor has changed to 10.0.0.5.

Therefore we can conclude the following, the IPv4 BGP multicast entries are used to send PIM Joins as well as conduct RPF checks on incoming multicast data traffic.  To further prove that the IPv4 BGP multicast entries are used to forward PIM Join messages we could remove the IPv4 prefixes which are being advertised over the lower link and see if we still have a SPT to ASBR-RP.

ASBR-RP#sh ip mroute 224.1.1.1
(*, 224.1.1.1), 00:01:19/00:03:26, RP 4.4.4.4, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet2/0, Forward/Sparse, 00:01:03/00:03:26

(192.168.1.1, 224.1.1.1), 00:01:19/00:03:22, flags: T
Incoming interface: FastEthernet1/0, RPF nbr 10.0.0.5, Mbgp
Outgoing interface list:
FastEthernet2/0, Forward/Sparse, 00:01:03/00:03:25

Yep, its still there.

However, now that we have withdrawn the IPv4 prefixes from AS2 Net-Edge2 will no longer we able to build an SPT to the source as it has no route to 192.168.1.1 but rather will have to use the shared tree as you can see below.

net-edge2#sh ip mroute 224.1.1.1
(*, 224.1.1.1), 02:42:16/00:02:58, RP 4.4.4.4, flags: SJCL
Incoming interface: FastEthernet1/0, RPF nbr 12.0.0.1
Outgoing interface list:
Loopback0, Forward/Sparse, 02:42:16/00:02:17

(192.168.1.1, 224.1.1.1), 00:02:51/00:00:08, flags: LJ
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Loopback0, Forward/Sparse, 00:02:51/00:02:17

If we reinject the IPv4 prefix 192.168.1.0/24 using BGP on ASBR1 and then reexamine the multicast entry for 224.1.1.1 on net-edge2 we see the following.

net-edge2#sh ip mroute 224.1.1.1
(*, 224.1.1.1), 00:00:09/stopped, RP 4.4.4.4, flags: SJCL
Incoming interface: FastEthernet1/0, RPF nbr 12.0.0.1
Outgoing interface list:
Loopback0, Forward/Sparse, 00:00:09/00:02:50

(192.168.1.1, 224.1.1.1), 00:00:00/00:02:59, flags: LJT
Incoming interface: FastEthernet1/0, RPF nbr 12.0.0.1
Outgoing interface list:
Loopback0, Forward/Sparse, 00:00:00/00:02:59

As you can see net-edge2 is now using the (S,G) tree.  MAGIC:-)

Anyway, I hope that makes sense.

Comments

Leave a comment

Name (required)

E-mail (required)

URI

Your Comment