Understanding MSDP (Multicast Source Discovery Protocol)
MSDP stands for Multicast Source Discovery Protocol which is used to share the multicast information between the different AS. MSDP is an application layer protocol which works on top of TCP using well-known port number 639.We will use a simple topology below to understand the behavior of MSDP between two AS 100 and 200.
MSDP stands for Multicast Source Discovery Protocol which is used to share the multicast information between the different AS. MSDP is an application layer protocol which works on top of TCP using well-known port number 639.We will use a simple topology below 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 the role of RP:
it PIM bsr-candidate Loopback0 0
it PIM rp-candidate Loopback0
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 is configured we are unable to receive any replies to ping from R4 to the multicast group IP 239.1.1.1 as below.
R4#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:
.
Now let us enable MSDP on R2 and R3 as follows:
R2(config)#ip msdp peer 9.9.0.3 connect-source lo0 remote-as 200
R3(config)#ip msdp peer 9.9.0.2 connect-source lo0 remote-as 100
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 peering is up now.
R2#sh ip msdp peer
MSDP Peer 9.9.0.3 (?), AS 200 (configured AS)
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.
R4#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 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 an (S,G) entry with R4 as the source.
R1#sh ip mroute
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, 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(config-if)#ip pim bsr-border
R2(config-if)#ip pim bsr-border
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 learned on R2 from MSDP peer R3 as below:
R2#sh ip msdp sa-cache
MSDP Source-Active Cache – 2 entries
(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
R2#sh ip msdp peer
MSDP Peer 9.9.0.3 (?), AS 200 (configured AS)
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
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 the role of RP:
it PIM bsr-candidate Loopback0 0
it PIM rp-candidate Loopback0
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 is configured we are unable to receive any replies to ping from R4 to the multicast group IP 239.1.1.1 as below.
R4#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:
.
Now let us enable MSDP on R2 and R3 as follows:
R2(config)#ip msdp peer 9.9.0.3 connect-source lo0 remote-as 200
R3(config)#ip msdp peer 9.9.0.2 connect-source lo0 remote-as 100
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 peering is up now.
R2#sh ip msdp peer
MSDP Peer 9.9.0.3 (?), AS 200 (configured AS)
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.
R4#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 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 an (S,G) entry with R4 as the source.
R1#sh ip mroute
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, 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(config-if)#ip pim bsr-border
R2(config-if)#ip pim bsr-border
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 learned on R2 from MSDP peer R3 as below:
R2#sh ip msdp sa-cache
MSDP Source-Active Cache – 2 entries
(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
R2#sh ip msdp peer
MSDP Peer 9.9.0.3 (?), AS 200 (configured AS)
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