MSDP stands for Multicast Source Discovery Protocol which is used to share the multicast information between the different AS. MSDP protocol is an application layer protocol that works on top of TCP using well-known port number 639.
Sample Topology: MSDP
Simple topology to understand the behavior of MSDP between two AS 100 and 200:
In this topology in AS 100 R2 is the RP & in AS 200 R3 is configured as the RP.
We are using the bootstrap RP method to configure the RP in both AS.
Below commands are configured in global prompt on R2 & R3 to give them role of RP:
Router R1 is configured to join the Multicast group 239.1.1.1 and R4 will be acting as the source for this multicast group.
When no MSDP protocol is configured we are unable to receive any replies to ping from R4 to multicast group IP 239.1.1.1 as below.
Sending 1, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:
Now let us enable MSDP on R2 and R3 as follows:
Make sure R2 and R3 are able to reach each other’s Lo0 address. We have used BGP to advertise them.
We can verify on either router that MSDP protocol peering is up now.
Connection status:
State: Up, Resets: 0, Connection source: Loopback0 (9.9.0.2)
Uptime(Downtime): 00:01:21, Messages sent/received: 2/2
Output messages discarded: 0
Connection and counters cleared 00:02:21 ago
SA Filtering:
Input (S,G) filter: none, route-map: none
Input RP filter: none, route-map: none
Output (S,G) filter: none, route-map: none
Output RP filter: none, route-map: none
SA-Requests:
Input filter: none
Peer ttl threshold: 0
SAs learned from this peer: 0
Number of connection transitions to Established state: 1
Input queue size: 0, Output queue size: 0
MD5 signature protection on MSDP TCP connection: not enabled
Message counters:
RPF Failure count: 0
SA Messages in/out: 0/0
SA Requests in: 0
SA Responses out: 0
Data Packets in/out: 0/0
Now let us again try to ping from R4 to R1’s group address 239.1.1.1.
Sending 1, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:
Reply to request 0 from 9.9.0.1, 288 ms
Here we see we are able to ping the R1’s multicast group from R1.
On R1 also we can see now it has a (S,G) entry with R4 as source.
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, E – Extranet,
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,
G – Received BGP C-Mroute, g – Sent BGP C-Mroute,
Q – Received BGP S-A Route, q – Sent BGP S-A Route,
V – RD & Vector, v – Vector
Outgoing interface flags: H – Hardware switched, A – Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.1.1.1), 00:47:20/stopped, RP 9.9.0.2, flags: SJCL
Incoming interface: FastEthernet0/0, RPF nbr 9.9.12.2
Outgoing interface list:
Loopback0, Forward/Sparse, 00:47:20/00:02:36
(9.9.0.4, 239.1.1.1), 00:00:47/00:02:12, flags: LJT
Incoming interface: FastEthernet0/0, RPF nbr 9.9.12.2
Outgoing interface list:
Loopback0, Forward/Sparse, 00:00:47/00:02:36
(9.9.34.4, 239.1.1.1), 00:00:47/00:02:12, flags: LJ
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Loopback0, Forward/Sparse, 00:00:47/00:02:36
(*, 224.0.1.40), 00:49:11/00:02:54, RP 0.0.0.0, flags: DPL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
But whenever we enable MSDP all the entries from the mroute table of one AS are flooded to the other AS.
In order to avoid this flooding of all the mroute entries between the AS we configure another command on R2 and R3 interface facing each other as below:
R3 relays the information about the active source 9.9.0.4 to R2 is a special message called the source active or SA message.
This message is received on R2 and which then uses a PIM message to convey the information of source R4 to receiver R1 in our case.
R1 then sends a PIM JOIN message to R2, R2 sends it to R3 and R3 sends it to R4 in turn.
When we send a ping from R4 for group IP 239.1.1.1 we see a SA message is learnt on R2 from MSDP peer R3 as below:
(9.9.0.4, 239.1.1.1), RP 9.9.0.3, BGP/AS 200, 00:00:18/00:05:49, Peer 9.9.0.3
(9.9.34.4, 239.1.1.1), RP 9.9.0.3, BGP/AS 200, 00:00:18/00:05:49, Peer 9.9.0.3
Connection status:
State: Up, Resets: 0, Connection source: Loopback0 (9.9.0.2)
Uptime(Downtime): 00:26:38, Messages sent/received: 36/29
Output messages discarded: 0
Connection and counters cleared 00:27:38 ago
SA Filtering:
Input (S,G) filter: none, route-map: none
Input RP filter: none, route-map: none
Output (S,G) filter: none, route-map: none
Output RP filter: none, route-map: none
SA-Requests:
Input filter: none
Peer ttl threshold: 0
SAs learned from this peer: 2
Number of connection transitions to Established state: 1
Input queue size: 0, Output queue size: 0
MD5 signature protection on MSDP TCP connection: not enabled
Message counters:
RPF Failure count: 0
SA Messages in/out: 3/10
SA Requests in: 0
SA Responses out: 0
Data Packets in/out: 2/8
ABOUT THE AUTHOR
I am here to share my knowledge and experience in the field of networking with the goal being – “The more you share, the more you learn.”
I am a biotechnologist by qualification and a Network Enthusiast by interest. I developed interest in networking being in the company of a passionate Network Professional, my husband.
I am a strong believer of the fact that “learning is a constant process of discovering yourself.”
– Rashmi Bhardwaj (Author/Editor)
