MSDP and MBGP (multicast BGP) are independent of each other but required for 
inter-domain multicast, MSDP enables PIM-SM domain RP's to share source 
information via sa-cache messages (S,G) via a TCP connection to each other, the 
cases where you wouldn't use MBGP with MSDP would be an anycast implementation 
via some IGP domains

MSDP control-plane RPF checks are ignored if we have just two peers, if we have 
more then two peers then the originator-id is checked to ensure its own RP 
address is not originating the message in which case it would fail (if no 
originator-id is selected then preference is given to the loopbacks)

If you get a question where a restriction of not changing IGP AD/metric or 
static mroute is imposed and IF the topology permits it then create a MBGP peer 
to originate the source of the multicast feed and also the RP address, this way 
you can route around the RPF failure.

Order of preference for RPF checks are as follows:

Static mroutes
DVMRP routes
MBGP routes
Unicast routes

So as you can see MBGP routes are preferred for RPF over unicast, you still 
need to ensure PIM is enabled on the relevant data-planes for this to work!

--
BR

Tony

Sent from my iPad

> On 7 Jan 2014, at 20:08, "Ryanlk18 ." <[email protected]> wrote:
> 
> You can use MPBGP multicast address-family to carry source information
> across the network to the RP.  This can be useful in dealing with RPF
> issues where static mroutes won't work or you cannot manipulate the
> underlying routing protocol.
> 
> MSDP is used to connect RPs together across multicast domains.  This is
> needed when you have multiple multicast domains that need to be connected
> in order to share multicast feeds across the network.
> 
> It could be possible to peer MSDP through a GRE Tunnel, but I've always
> used MSDP and MPBGP together as they are both necessary to carry the source
> and RP information to bridge the domains.
> 
> V/r,
> 
> Ryan Krcelic
> 
> 
> 
>> On Tue, Jan 7, 2014 at 2:31 PM, Andrew LaPorte <[email protected]> wrote:
>> 
>> I'm going to try to help out here a bit.
>> 
>> BGP and MSDP are not directly related to one another.  You can have MSDP
>> without having BGP but it is typical to have BGP and Multicast as that is a
>> larger environment.
>> 
>> MSDP simply allows one RP to exchange multicast information with another
>> RP,
>> i.e. source A can register with RP A then another source B can register
>> with
>> RP B.  If RP A and RP B have MSDP between them then both with know about
>> source A and source B.
>> 
>> Now if you want a client to be able to get to both source A and source B
>> they must have a route that passes an RFP check. This is where BGP or OSPF
>> or EIGRP would come in typically.
>> 
>> Hope this helps.
>> 
>> AndyL
>> 
>> 
>> -----Original Message-----
>> From: [email protected]
>> [mailto:[email protected]] On Behalf Of Ryan Jensen
>> Sent: Tuesday, January 7, 2014 1:47 PM
>> To: [email protected]
>> Subject: [OSL | CCIE_RS] Multicast question
>> 
>> I all, this is probably an amateur question, but I'm having an issue
>> wrapping my head around how BGP for multicast relates to MSDP.
>> Here's how I Think they relate:
>> BGP for multicast shares routes to RPs for the purpose of RPF MSDP shares
>> 'routes' to multicast sources.
>> 
>> The sources that are shared via MSDP need to be reachable via the routes
>> learned from BGP yes?
>> 
>> Is this a correct understanding?
>> _______________________________________________
>> Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos ::
>> 
>> iPexpert on YouTube: www.youtube.com/ipexpertinc
>> 
>> _______________________________________________
>> Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos ::
>> 
>> iPexpert on YouTube: www.youtube.com/ipexpertinc
> _______________________________________________
> Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos ::
> 
> iPexpert on YouTube: www.youtube.com/ipexpertinc
_______________________________________________
Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos ::

iPexpert on YouTube: www.youtube.com/ipexpertinc

Reply via email to