MSDP Explained (Part 1)

Note(s):
- this's a 1 of 2 parts Series i Made on MSDP, the next write up will have MSDP with Anycast
RPs, Stay Tuned..
- it's strongly recommended to have a good understanding of Multicast Technologies (PIM
sparse-mode, and PIM dense-mode) before proceeding in this Discussion.

  • Due to the Character Limit on each discussion, i have split Part 1 into two sections: Section 1 and Section 2 (Section 2 is Right Under Section 1)

Section 1: a Practical Explanation of MSDP:

Multicast Source Discovery Protocol, or MSDP. as the name Implies, is a Protocol for exchanging the Source of the Multicast Senders (hence, the (S,G) pair entry) between RPs (Rendezvous Points ).

  • Why Use MSDP ?
    (I'm gonna Leave the Answer at the End of this Discussion )


Fig.1

following the Topology in Fig.1 let's configure the Routers in the Network :
!PC1:

ip multicast-routing
!
router ospf 1
network 0.0.0.0 255.255.255.255 area 0
!


!R1:

ip multicast-routing
interface FastEthernet0/0
ip pim sparse-mode

!
interface Serial5/4
ip pim sparse-mode
!
router ospf 1
network 0.0.0.0 255.255.255.255 area 0
!


!R4:

ip multicast-routing
interface Serial5/1
ip pim sparse-mode
!
interface Serial5/3
ip pim sparse-mode
!
interface Loopback0
ip pim sparse-mode
!
router ospf 1
network 0.0.0.0 255.255.255.255 area 0


!R3:
ip multicast-routing
interface Serial5/4
ip pim sparse-mode
!
interface Serial5/5
ip pim sparse-mode
router ospf 1
network 0.0.0.0 255.255.255.255 area 0


!R5:

ip multicast-routing
interface Serial5/2
ip pim sparse-mode
!
interface Serial5/3
ip pim sparse-mode
!
interface Loopback0
ip pim sparse-mode
!
router ospf 1
network 0.0.0.0 255.255.255.255 area 0


!R2:

ip multicast-routing
interface FastEthernet0/0
ip pim sparse-mode

!
interface Serial5/5
ip pim sparse-mode
!
router ospf 1
network 0.0.0.0 255.255.255.255 area 0


!PC1:

ip multicast-routing
!
router ospf 1
network 0.0.0.0 255.255.255.255 area 0
!
______________________________________________________________________________________________ ______________________________________________________________________________________________

let's set R5 as the RP for 2 and R3:

!R2-3,R5:
enable
conf t
ip pim rp-address 5.5.5.5
end
!
and let's verify the RP mapping :smile:
show ip pim rp mapping
PIM Group-to-RP Mappings

Group(s): 224.0.0.0/4, Static
RP:5.5.5.5(?)

let's set R4 as the RP for R1:

!R1,R4:
enable
conf t
ip pim rp-address 4.4.4.4
end
!
and let's verify the RP mapping :
show ip pim rp mapping
PIM Group-to-RP Mappings

Group(s): 224.0.0.0/4, Static
RP: 4.4.4.4 (?)


!now that the RP's are set to go, let's try to send packets (ping) to 224.1.2.3 from the Source PC2, to the Receiver PC1 :

on PC2:

ping 224.1.2.3 repeat 1000
.........................
no receivers yet, so we'are not getting any replies, but let's check the Mroute table:

!R2:

R2#show ip mroute 224.1.2.3 | begin Interface
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.1.2.3), 00:02:23/stopped, RP 5.5.5.5, flags: SPF
Incoming interface: Serial5/5, RPF nbr 10.1.25.5
Outgoing interface list: Null

(10.1.2.200, 224.1.2.3), 00:02:23/00:02:36, flags: PFT
Incoming interface: FastEthernet0/0, RPF nbr 0.0.0.0
Outgoing interface list: Null

!R5:
R5#show ip mroute 224.1.2.3 | begin Interface
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.1.2.3), 00:02:22/stopped, RP 5.5.5.5, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null

(10.1.2.200, 224.1.2.3), 00:02:22/00:02:35, flags: P
Incoming interface: Serial5/2, RPF nbr 10.1.25.2
Outgoing interface list: Null

!R1,R3,R4:

RX#show ip mroute 224.1.2.3
Group 224.1.2.3 not found

as we can see, R2 sees the source because it's the DR(the DR is responsible for sending the register messages to the RP). and R5 is the RP, has received a register message from R2, and sent back a register STOP, and a prune message, because it has no receivers yet, and R3 is NOT in the way between R2(DR) and R5(RP2).

! Now let's make PC1 join the (*,224.1.2.3) group as a Receiver.
!PC1:
enable
conf t
int fa0/0
ip igmp join-group 224.1.2.3
end

let's check the Mroute table for this group on R1 and R4 (RP1):

!R1:
R1#show ip mroute 224.1.2.3 | begin Interface
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.1.2.3), 00:02:00/00:02:48, RP 4.4.4.4, flags: SJC
Incoming interface: Serial5/4, RPF nbr 10.1.14.4
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 00:02:00/00:02:48

!R4:
R4#show ip mroute 224.1.2.3 | begin Interface
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.1.2.3), 00:02:00/00:03:27, RP 4.4.4.4, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Serial5/1, Forward/Sparse, 00:02:00/00:03:27

let's take a look at PC2 again :
PC2:

PC2#ping 224.1.2.3 repeat 1000
Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 224.1.2.3, timeout is 2 seconds:
......................................................................
......................................................................

as we can see, R1 has joined the (,G) for group 224.1.2.3 to R4(RP1), after receiver an IGMP join message (IGMP membership Report , as Cisco likes to call it). but PC2 does NOT Receive any replies yet! why? because there's a distinct between between the RP for the source (RP2) and the RP of the receiver (RP1)
So, we ended up with RP2(R5) knowing the (S,G) entry (the path to the source) and RP1 (R4) knowing the the (
,G) entry to a receiver, but non of them knows both!

how can we solve this problem ? simple, we use MSDP (Multicast Source Discovery Protocol) between R4 and R5:

!R4:
enable
conf
ip msdp peer 5.5.5.5 connect-source loopback 0

!R5:
enable
conf
ip msdp peer 4.4.4.4 connect-source loopback 0
*Jun 17 10:12:15.491: %MSDP-5-PEER_UPDOWN: Session to peer 4.4.4.4 going up

Now let's Check PC2 again:

PC2#ping 224.1.2.3 repeat 1000
Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 224.1.2.3, timeout is 2 seconds:
......................................................................
...........................................................
Reply to request 129 from 10.1.1.100, 264 ms
Reply to request 130 from 10.1.1.100, 84 ms
Reply to request 131 from 10.1.1.100, 128 ms
Reply to request 132 from 10.1.1.100, 132 ms
Reply to request 133 from 10.1.1.100, 136 ms
Reply to request 134 from 10.1.1.100, 92 ms
Reply to request 135 from 10.1.1.100, 68 ms
Reply to request 136 from 10.1.1.100, 104 ms
Reply to request 137 from 10.1.1.100, 64 ms
Reply to request 138 from 10.1.1.100, 72 ms
Reply to request 139 from 10.1.1.100, 88 ms

If you need me, @Bugazia Me, and i'll be there .

Comments

  • BugaziaBugazia ✭✭✭

    basically, what happened is the following:
    RP2(R5) knew the path to the (S,G) entry, RP1(R4) knew the path to the (*,G) entry ,when they became MSDP neighbors, R5 sent an MSDP SA (Source Active Message) to inform it's MSDP Neighbor (R4) of the (S,G) entries it possesses. so as soon as R4 received that SA message, it joined the source (by sending a Pim join towards R2) and started forwarding packets for the group 224.1.2.3 towards PC1.

    let's take a look at R4's SA Cache:

    R4#show ip msdp sa-cache
    MSDP Source-Active Cache - 1 entries
    (10.1.2.200, 224.1.2.3), RP 5.5.5.5, AS ?,00:00:18/00:05:41, Peer 5.5.5.5

    let's now check the (S,G) Mroute entry for 224.1.2.3 on all routers (i have excluded the (*,G) because it's irrelevant here since it's no longer used for the SPT:

    !R2:
    R2#show ip mroute 224.1.2.3 | begin (10.1.2.200, 224.1.2.3)
    (10.1.2.200, 224.1.2.3), 00:05:48/00:01:41, flags: FT
    Incoming interface: FastEthernet0/0, RPF nbr 0.0.0.0
    Outgoing interface list:
    Serial5/5, Forward/Sparse, 00:05:48/00:03:29

    !R5:
    R5#show ip mroute 224.1.2.3 | begin (10.1.2.200, 224.1.2.3)
    (10.1.2.200, 224.1.2.3), 00:05:53/00:01:40, flags: TA
    Incoming interface: Serial5/2, RPF nbr 10.1.25.2
    Outgoing interface list:

    !R3:

    R3#show ip mroute 224.1.2.3 | begin (10.1.2.200, 224.1.2.3)
    (10.1.2.200, 224.1.2.3), 00:05:50/00:01:28, flags: T
    Incoming interface: Serial5/5, RPF nbr 10.1.35.5
    Outgoing interface list:
    Serial5/4, Forward/Sparse, 00:05:50/00:02:37

    !R4:

    R4#show ip mroute 224.1.2.3 | begin (10.1.2.200, 224.1.2.3)
    (10.1.2.200, 224.1.2.3), 00:05:51/00:01:34, flags: MT
    Incoming interface: Serial5/3, RPF nbr 10.1.34.3
    Outgoing interface list:
    Serial5/1, Forward/Sparse, 00:05:51/00:02:36

    !R1:

    R1#show ip mroute 224.1.2.3 | begin (10.1.2.200, 224.1.2.3)
    (10.1.2.200, 224.1.2.3), 00:05:49/00:01:01, flags: JT
    Incoming interface: Serial5/4, RPF nbr 10.1.14.4
    Outgoing interface list:
    FastEthernet0/0, Forward/Sparse, 00:05:49/00:02:35

    So Why Use MDSP ?

    by now, you probably have a good idea why to use MSDP, but as i promised:
    MSDP solves the problem of having two (or more) RPs. FOR EXAMPLE RP1 and RP2, if RP1 has a Joined receiver, and RP2 has a sender(Source) connected to it, then we will never be able to send the Multicast Messages from the Source to the Receiver, because the Routers on the Multicast Network Do't agree on the RP for a specific Group.
    MSDP solved that problem by having Multiple RPs share their (S,G) entries with each other(using a message called SA message), that way each RP receiving an SA for a (s,g) entry, can join to that Source Directly (having the Original RP that initiated the SA entry in the Control Plane only and not necessarily in the Data plane)

    If you need me, @Bugazia Me, and i'll be there .

  • BugaziaBugazia ✭✭✭

    Section 2) Summary :

    1) PC2 (the source) sent Multicast(Ping) Packets to 224.1.2.3, towards R2.
    2) R2, being the PIM DR for this Segment,sent a PIM Register for (10.1.2.200,224.1.2.3) to it's RP (R5)
    3) R5 received the Register Message for (10.1.2.200,224.1.2.3) and sent back a register Stop as soon as it received the first Multicast(ping) Packet
    4) R5 sends an MSDP SA(source Active) Message to it's MSDP Peer, R4. informing it about the (10.1.2.200,224.1.2.3) Entry.
    4.5) R4 receives the SA message from R5, and stores it in it's SA-cache table(along with RP that send the SA message). but it will NOT have this (S,G) Entry in it's table Yet(because it has no receivers for it)
    5) PC1 sends an Igmp Join for the group 224.1.2.3 towards R1.
    6) R1, being the IGMP Querier for this Segment,sends a PIM Join for (*,224.1.2.3) to it's RP (R4).
    7) as soon as R4 receives the PIM join, for the group, it imports the SA-Cache entry from R5 to it's Mroute Table, and then sends a PIM Join to the source of the group, to (10.1.2.200,224.1.2.3)

    Now PC1 can receive the Packets from PC2 without any problems.

    If you need me, @Bugazia Me, and i'll be there .

Sign In or Register to comment.