MSDP

I was curious if non-BGP intra-AS MSDP requires the use of an Anycast RP address. Or, can you have different RPs for different areas of the network sharing sources? Thinking without MP-BGP this may cause problems. Thanks.

Comments

  • leminhleminh ✭✭
    edited June 2017

    Yes, you can as long as the unicast can pass the RPF check. MP-BGP is just another hack to deal with RPF check.

  • BugaziaBugazia ✭✭✭

    @snowbdr74
    yeah, it will work just fine, let's take a simple example with a flat area design, and two RPs : RP1(R4), and RP2(R5).

    !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 .

  • BugaziaBugazia ✭✭✭
    edited June 2017

    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)

    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 .

  • BugaziaBugazia ✭✭✭
    edited June 2017

    @snowbdr74 i hope that my Answer was informative to you, basically what i did is first gave you practical example, then explained the theory behind it, to make it less boring :)

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

Sign In or Register to comment.