MSDP and Inter-domain multicast


So far we have seen that PIM (Protocol Independent Multicast) can perfectly satisfy the need for multicast forwarding inside a single domain or autonomous system, which is not the case with multicast applications intended to provide services outside the boundary of a single autonomous system, here comes the role of protocols such MSDP (Multicast Source Discovery Protocol).

With PIM-SM a typical multicast framework inside a single domain is composed of one or more Rendez-Vous points, multicast sources and multicast receivers. Now let’s imagine a company specialized in Video-On Demand content with receivers across Internet, with a typical multicast framework inside each AS to be as close as possible to receivers and let’s suppose that multicast sources in one AS is no more available, and we know that RP is responsible for registering sources and linking them to receivers, so what if an RP in one AS can communicate with the RP in another AS and be able to register with its sources?

Well that’s exactly what MSDP is intended for: make multicast sources available for other AS receivers by communicating this information between RP in different autonomous systems.

In this lab two simplified autonomous systems are considered AS27011 and AS27022 with an RP and multicast source, serving the same group, in each(Figure1).

Figure1: Topology

The scenario is as follow:

  • First, R22 the multicast source is sending multicast traffic 224.1.1.1 to R2 with RP2 as the rendez-vous point inside AS27022.
  • Second, R22 stop sending the multicast traffic and R1 in AS27011 start sending the same multicast group 224.1.1.1

To successfully deploy MSDP (or any other technology or protocol) it is crucial to split the work into several steps and make sure that each step is working perfectly, this will dramatically reduce the time that would be spent troubleshooting issues accumulated with each layer.

  • Basic connectivity & reachability
  • Routing protocol: BGP configuration
  • multicast configuration
  • MSDP configuration
  1. Basic connectivity & reachability

Let’s start by configuring IGP (EIGRP) to insure connectivity between devices:

R1:

router eigrp 10
network 192.168.111.0

no auto-summary

RP1:

router eigrp 10

passive-interface Ethernet0/1

network 1.1.1.3 0.0.0.0

network 172.16.0.1 0.0.0.0

network 192.168.111.0

network 192.168.221.0

no auto-summary

RP2:

router eigrp 10

passive-interface Ethernet0/1

network 1.1.1.2 0.0.0.0

network 172.16.0.2 0.0.0.0

network 192.168.221.0

network 192.168.222.0

network 192.168.223.0

no auto-summary

IGP routing information should not leak between ASs, hence the need to set interfaces between ASs as passive so only networks carried by BGP will be reachable between AS27022 and AS27011.

R22:

router eigrp 10
network 22.0.0.0

network 192.168.223.0

no auto-summary

R2:

router eigrp 10
network 192.168.222.0

no auto-summary

  1. Routing protocol: BGP configuration

     

Do not forget to advertise multicast end-point subnets through BGP (10.10.10.0/24, 22.0.0.0/24 and 192.168.40.0/24) so they can be reachable between the two autonomous systems.

R1:

router bgp 27011
no synchronization

bgp log-neighbor-changes

network 10.10.10.0 mask 255.255.255.0

neighbor 192.168.111.11 remote-as 27011

no auto-summary

RP1:

router bgp 27011
no synchronization

bgp log-neighbor-changes

neighbor 1.1.1.2 remote-as 27022

neighbor 1.1.1.2 ebgp-multihop 2

neighbor 1.1.1.2 update-source Loopback0

neighbor 192.168.111.1 remote-as 27011

no auto-summary

ip route 1.1.1.2 255.255.255.255 192.168.221.22

RP2:

router bgp 27022
no synchronization

bgp log-neighbor-changes

neighbor 1.1.1.3 remote-as 27011

neighbor 1.1.1.3 ebgp-multihop 2

neighbor 1.1.1.3 update-source Loopback0

neighbor 192.168.222.2 remote-as 27022

neighbor 192.168.222.2 route-reflector-client

neighbor 192.168.223.33 remote-as 27022

neighbor 192.168.223.33 route-reflector-client

no auto-summary

ip route 1.1.1.3 255.255.255.255 192.168.221.11

eBGP is configured between loopback interfaces to match MSDP peer relationship, therefore static routes are added in both sides to reach those loopback interfaces.

R22:

router bgp 27022
no synchronization

network 22.0.0.0 mask 255.255.255.0

neighbor 192.168.223.22 remote-as 27022

no auto-summary

R2:

router bgp 27022
no synchronization

network 192.168.40.0

neighbor 192.168.222.22 remote-as 27022

no auto-summary

There is three methods to configure iBGP in AS 27022:

– enable BGP only on the border router RP2 and redistribute needed subnets into BGP (not straightforward).

– configure full mesh iBGP (not consistent with the phyisical topology which is linear).

– configure RP1 as Route reflector.

let’s retain the last option the most optimal in the current situation, whenever this option is possible you better start by considering it to allow more flexibility for future growth of your network, otherwise when things become more complicated you will have to reconfigure BGP from the scratch to use Route Reflector.

Monitoring:

R2:

R2#sh ip bgp
BGP table version is 10, local router ID is 1.1.1.4

Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,

r RIB-failure, S Stale

Origin codes: i – IGP, e – EGP, ? – incomplete

Network Next Hop Metric LocPrf Weight Path

*>i10.10.10.0/24 192.168.221.11 0 100 0 27011 i

*>i22.0.0.0/24 192.168.223.33 0 100 0 i

*> 192.168.40.0 0.0.0.0 0 32768 i

R2#

R22:

R22(config-router)#do sh ip bgp
BGP table version is 8, local router ID is 22.0.0.1

Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,

r RIB-failure, S Stale

Origin codes: i – IGP, e – EGP, ? – incomplete

Network Next Hop Metric LocPrf Weight Path

*>i10.10.10.0/24 192.168.221.11 0 100 0 27011 i

*> 22.0.0.0/24 0.0.0.0 0 32768 i

*>i192.168.40.0 192.168.222.2 0 100 0 i

R22(config-router)#

R1:

R1#sh ip bgp
BGP table version is 10, local router ID is 192.168.111.1

Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,

r RIB-failure, S Stale

Origin codes: i – IGP, e – EGP, ? – incomplete

Network Next Hop Metric LocPrf Weight Path

*> 10.10.10.0/24 0.0.0.0 0 32768 i

*>i22.0.0.0/24 192.168.221.22 0 100 0 27022 i

*>i192.168.40.0 192.168.221.22 0 100 0 27022 i

R1#

  1. multicast configuration

R1:

ip multicast-routing
interface Ethernet0/0

ip pim sparse-dense-mode

interface Serial1/0

ip pim sparse-dense-mode

RP1:

ip multicast-routing
interface Loopback1

ip pim sparse-dense-mode

interface Ethernet0/1

ip pim sparse-dense-mode

ip pim send-rp-announce Loopback1 scope 64

ip pim send-rp-discovery scope 64

RP1 router is configured as the RP and mapping agent for the AS27011

RP2:

interface Loopback0
ip pim sparse-dense-mode

interface Ethernet0/1

ip pim sparse-dense-mode

interface Ethernet0/2

ip pim sparse-dense-mode

ip pim send-rp-announce Loopback1 scope 64

ip pim send-rp-discovery scope 64

RP2 router is configured as the RP and mapping agent for the AS27022

R2:

interface Ethernet0/0
ip pim sparse-dense-mode


ip igmp join-group 224.1.1.1

interface Serial1/0

ip pim sparse-dense-mode

Auto-RP is chosen to advertise RP information throughout all interfaces where PIM sparse-dense mode is enabled… including through the link between autonomous systems, this mean that group-to-RP mapping information will be advertised to other ASs PIM routers which can lead to confusion and the result is that a PIM router in one AS will receive information from its local RP telling that it is the RP responsible for a number of groups as well information from external RP announcing their information:

R2#
*Mar 1 02:58:01.315: Auto-RP(0): Received RP-discovery, from 192.168.221.11, RP_cnt 1, ht 181

*Mar 1 02:58:01.319: Auto-RP(0): Update (224.0.0.0/4, RP:172.16.0.1), PIMv2 v1

R2#

RP2(config-if)#

*Mar 1 02:44:05.615: %PIM-6-INVALID_RP_JOIN: Received (*, 224.1.1.1) Join from 0.0.0.0 for invalid RP 172.16.0.1

RP2(config-if)#

And this is not the kind of cooperation intended by MSDP, MSDP allow RPs on one AS to contact multicast sources in other AS, but still responsible for multicast forwarding inside its AS.

The solution is to block service groups 224.0.1.39 and 224.0.1.40 between the two ASs using multicast boundary filtering:

RP1:

access-list 10 deny
224.0.1.39
access-list 10 deny
224.0.1.40

access-list 10 permit any

interface Ethernet0/1


ip multicast boundary 10

RP2:

access-list 10 deny
224.0.1.39
access-list 10 deny
224.0.1.40

access-list 10 permit any

interface Ethernet0/1


ip multicast boundary 10

Multicast monitoring inside AS:

RP2(config)#
*Mar 1 03:26:17.731: Auto-RP(0): Build RP-Announce for
172.16.0.2, PIMv2/v1, ttl 64, ht 181

*Mar 1 03:26:17.735: Auto-RP(0): Build announce entry for (224.0.0.0/4)

*Mar 1 03:26:17.739: Auto-RP(0): Send RP-Announce packet on Ethernet0/2

*Mar 1 03:26:17.743: Auto-RP(0): Send RP-Announce packet on
Serial1/0

*Mar 1 03:26:17.747: Auto-RP: Send RP-Announce packet on Loopback1

*Mar 1 03:26:17.747: Auto-RP(0): Received RP-announce, from 172.16.0.2, RP_cnt 1, ht 181

*Mar 1 03:26:17.751: Auto-RP(0): Added with (224.0.0.0/4, RP:172.16.0.2), PIMv2 v1

*Mar 1 03:26:17.783: Auto-RP(0): Build RP-Discovery packet

RP2(config)#

RP2(config)#

*Mar 1 03:26:17.783: Auto-RP: Build mapping (224.0.0.0/4, RP:172.16.0.2), PIMv2 v1,

*Mar 1 03:26:17.791: Auto-RP(0): Send RP-discovery packet on Ethernet0/2 (1 RP entries)

*Mar 1 03:26:17.799: Auto-RP(0): Send RP-discovery packet on Serial1/0 (1 RP entries)

RP2(config)#

RP2 the RP forAS27022 is properly announcing itself to the mapping agent (the same router) which in turn properly announcing RP to local PIM routers R22 and R2:

R22:
R22#

*Mar 1 03:26:24.339: Auto-RP(0): Received RP-discovery, from 192.168.223.22, RP_cnt 1, ht 181

*Mar 1 03:26:24.347: Auto-RP(0): Added with (224.0.0.0/4, RP:172.16.0.2), PIMv2 v1

R22#

R22#sh ip pim rp mapp

PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4


RP 172.16.0.2 (?), v2v1

Info source: 192.168.223.22 (?), elected via Auto-RP

Uptime: 00:04:16, expires: 00:02:41

R22#

R2:
R2#

*Mar 1 03:27:14.175: Auto-RP(0): Received RP-discovery, from 192.168.222.22, RP_cnt 1, ht 181

*Mar 1 03:27:14.179: Auto-RP(0): Update (224.0.0.0/4, RP:172.16.0.2), PIMv2 v1

R2#

R2#sh ip pim rp mapp

PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4


RP 172.16.0.2 (?), v2v1

Info source: 192.168.222.22 (?), elected via Auto-RP

Uptime: 00:09:22, expires: 00:02:37

R2#

  1. MSDP configuration

RP1:

ip msdp peer 1.1.1.2 connect-source Loopback0

RP2:

ip msdp peer 1.1.1.3 connect-source Loopback0

interface loo0 doesn’t need PIM to be enabled on it.

The MSDP peer ID have to match eBGP peer ID

RP1:

RP1#sh ip msdp summ
MSDP Peer Status Summary

Peer Address AS State Uptime/ Reset SA Peer Name

Downtime Count Count

1.1.1.2
27022 Up 01:14:58 0 0 ?

RP1#

RP1(config)#do sh ip bgp summ

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

1.1.1.2 4 27022 79 79 4 0 0 01:15:46 2

192.168.111.1 4 27011 80 80 4 0 0 01:16:03 1

RP1#

RP2:

RP2#sh ip msdp sum
MSDP Peer Status Summary

Peer Address AS State Uptime/ Reset SA Peer Name

Downtime Count Count

1.1.1.3
27011 Up 01:15:48 0 2 ?

RP2#

RP2(config)#

RP2(config)#do sh ip bgp sum

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

1.1.1.3 4 27011 80 80 4 0 0 01:16:33 1

192.168.222.2 4 27022 81 82 4 0 0 01:16:43 1

192.168.223.33 4 27022 81 82 4 0 0 01:16:44 1

RP2#

R22#ping
Protocol [ip]:

Target IP address: 224.1.1.1

Repeat count [1]: 1000000

Datagram size [100]:

Timeout in seconds [2]:

Extended commands [n]: y

Interface [All]: Ethernet0/0

Time to live [255]:

Source address: Loopback2

Type of service [0]:

Set DF bit in IP header? [no]:

Validate reply data? [no]:

Data pattern [0xABCD]:

Loose, Strict, Record, Timestamp, Verbose[none]:

Sweep range of sizes [n]:

Type escape sequence to abort.

Sending 1000000, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:

Packet sent with a source address of 22.0.0.1

Reply to request 0 from 192.168.222.2, 216 ms

Reply to request 1 from 192.168.222.2, 200 ms

Reply to request 2 from 192.168.222.2, 152 ms

Reply to request 3 from 192.168.222.2, 136 ms

Reply to request 4 from 192.168.222.2, 200 ms

Reply to request 5 from 192.168.222.2, 216 ms

After generating a multicast routing from R22 loo2 interface to the group 224.1.1.1 you can note from the result of the previous extended ping that R2 is responding to it.

RP2#sh ip mroute 224.1.1.1
IP Multicast Routing Table

Flags: D – Dense, S – Sparse, B – Bidir Group, s – SSM Group, C – Connected,

L – Local, P – Pruned, R – RP-bit set, F – Register flag,

T – SPT-bit set, J – Join SPT, M – MSDP created entry,

X – Proxy Join Timer Running, A – Candidate for MSDP Advertisement,

U – URD, I – Received Source Specific Host Report,

Z – Multicast Tunnel, z – MDT-data group sender,

Y – Joined MDT-data group, y – Sending to MDT-data group

Outgoing interface flags: H – Hardware switched, A – Assert winner

Timers: Uptime/Expires

Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.1.1.1), 00:17:35/00:02:38, RP 172.16.0.2, flags: S

Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list:


Serial1/0, Forward/Sparse-Dense, 00:17:35/00:02:38

(22.0.0.1, 224.1.1.1), 00:05:57/00:03:28, flags: T


Incoming interface: Ethernet0/2, RPF nbr 192.168.223.33

Outgoing interface list:


Serial1/0, Forward/Sparse-Dense, 00:05:57/00:03:28

RP2#

RP on AS27022 has already built the shared tree with the receiver (*, 224.1.1.1) and registered for the source tree with PIM-DR sending router (22.0.0.1, 224.1.1.1).

Note that the RPF interface that is used to reach the source 22.0.0.1 is e0/2

Now let’s suppose that for some reasons the source R22 stopped sending the multicast group to 224.1.1.1 and in the neighbor AS 27022 a source begin to send multicast traffic to the same group.

RP2#*Mar 1 01:32:42.051: MSDP(0): Received 32-byte TCP segment from 1.1.1.3

*Mar 1 01:32:42.055: MSDP(0): Append 32 bytes to 0-byte msg 102
from 1.1.1.3, qs 1

RP2#

RP2 msdp has received SA message from the MSDP peer at RP1 to inform it about its local source, the group and RP as show in the following output:

RP2#sh ip msdp saMSDP Source-Active Cache – 2 entries

(10.10.10.3, 224.1.1.1), RP 172.16.0.1, BGP/AS 0, 00:26:31/00:05:46, Peer 1.1.1.3

(192.168.111.1, 224.1.1.1), RP 172.16.0.1, BGP/AS 0, 00:26:31/00:05:46, Peer 1.1.1.3

RP2#

RP2#sh ip mroute 224.1.1.1
IP Multicast Routing Table

Flags: D – Dense, S – Sparse, B – Bidir Group, s – SSM Group, C – Connected,

L – Local, P – Pruned, R – RP-bit set, F – Register flag,

T – SPT-bit set, J – Join SPT, M – MSDP created entry,

X – Proxy Join Timer Running, A – Candidate for MSDP Advertisement,

U – URD, I – Received Source Specific Host Report,

Z – Multicast Tunnel, z – MDT-data group sender,

Y – Joined MDT-data group, y – Sending to MDT-data group

Outgoing interface flags: H – Hardware switched, A – Assert winner

Timers: Uptime/Expires

Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.1.1.1), 01:34:23/00:03:25, RP 172.16.0.2, flags: S

Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list:

Serial1/0, Forward/Sparse-Dense, 01:34:23/00:03:25

(10.10.10.3, 224.1.1.1), 00:30:13/00:03:21, flags: MT


Incoming interface: Ethernet0/1, RPF nbr 192.168.221.11

Outgoing interface list:


Serial1/0, Forward/Sparse-Dense, 00:30:13/00:03:25

(192.168.111.1, 224.1.1.1), 00:30:13/00:03:21, flags:

Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list:

Serial1/0, Forward/Sparse-Dense, 00:30:13/00:03:24

RP2#

Note the new entry for the group 224.1.1.1 which is (10.10.10.3, 224.1.1.1) flagged as “M” for MSDP created entry and “T” telling that packets has been received on this SPT.

The incoming interface connect the RPF neighbor RP2 towards the source 10.10.10.3 and the outgoing interface send traffic to R2.

RP1#sh ip mroute 224.1.1.1
IP Multicast Routing Table

Flags: D – Dense, S – Sparse, B – Bidir Group, s – SSM Group, C – Connected,

L – Local, P – Pruned, R – RP-bit set, F – Register flag,

T – SPT-bit set, J – Join SPT, M – MSDP created entry,

X – Proxy Join Timer Running, A – Candidate for MSDP Advertisement,

U – URD, I – Received Source Specific Host Report,

Z – Multicast Tunnel, z – MDT-data group sender,

Y – Joined MDT-data group, y – Sending to MDT-data group

Outgoing interface flags: H – Hardware switched, A – Assert winner

Timers: Uptime/Expires

Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.1.1.1), 00:34:29/stopped, RP 172.16.0.1, flags: SP

Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list: Null

(10.10.10.3, 224.1.1.1), 00:31:27/00:02:25, flags: TA


Incoming interface: Serial1/0, RPF nbr 192.168.111.1

Outgoing interface list:


Ethernet0/1, Forward/Sparse-Dense, 00:30:31/00:02:50

(192.168.111.1, 224.1.1.1), 00:34:29/00:02:55, flags: PTA

Incoming interface: Serial1/0, RPF nbr 0.0.0.0

Outgoing interface list: Null

RP1#

RP1#

the entry (10.10.10.3, 224.1.1.1) has serial1/0 as incoming interface connected to the RPF neighbor which is the source R1 and forward the traffic to AS27022 to RP2.

“T” for packets has been received on this entry and the RP (MSDP) consider this SPT to be a candidate for MSDP advertisement to other AS.

Advertisements

About ajnouri
Se vi deziras sekure komuniki eksterbloge, jen mia publika (GPG) ŝlosilo: My public key for secure communication: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x41CCDE1511DF0EB8

13 Responses to MSDP and Inter-domain multicast

  1. Pingback: Bookmarks about Routers

  2. LAX says:

    Perfect!

  3. Saad says:

    Excellent

  4. eduardo1n says:

    This one was a really good entry. It took me time to replicate this test in my gns3 lab. but was really useful to understand MSDP. Thanks.

  5. multicast-q says:

    Hi there,

    The MSDP peer config for RP1:
    ip msdp peer 1.1.1.3 connect-source Loopback0

    Doesn’t that need to have a peer IP add of 1.1.1.2 ?

    Thanks!

  6. ccie7 says:

    Some small mistakes likes mixed-up interface IDs, but hey, excellent overview of how MSDP-MC works 😉

  7. excellent post. thank you.

  8. Pingback: 3.2.c Implement and troubleshoot multicast source discovery protocol | ccie or die

  9. Bin.Y says:

    learned a lot from this post.Thx

  10. NA says:

    Very Very useful , Thanks ! but why you used sparse-dense mode and not only PIM
    sparse-mode ?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: