From: Edwards, Andrew M (andrew.m.edwards@boeing.com)
Date: Fri Jul 01 2005 - 14:47:37 GMT-3
Sheikh,
The basic idea of MSDP and MBGP interaction is passing the RPF check for
the unicast address of the RP advertised in the MSDP Source Active (SA)
message.
MSDP was meant to resolve inter-AS multicast issues (now better resolved
through SSM) and also happens to provide Anycast multicast capabilities
within an AS.
If you are within an AS, MSDP can pass the RPF by:
1. Having Only 1 MSDP peer. (or a default peer)
2. Using a mesh-group with MSDP
3. Having the MSDP peer address = iMBGP peer address
In the first intra-AS case, you only have one peer that you will learn
MSDP SA's from, so you should accept them without hesitation or RPF
verification.
In the second intra-AS case where you use a mesh-group, when an MSDP
peer within the mesh-group hears an SA from a mesh-group MSDP peer, it
will accept the first one it hears without RPF verification. This MSDP
peer will also continue to flood the SA towards NON mesh-group MSDP
peers. This make sense because the other mesh-group peers will already
have received the same SA (no reason to flood it again) and NON
mesh-group peers have yet to hear the SA, so flood it to them.
In the third case, this simply means that the route towards the RP is
through the correct next hop as seen through the iMBGP table. This must
be true because iMBGP requires a full mesh of MBGP peers; that's why
iMBGP advertisements are not re-advertised by iMBGP speakers. This is
weird with RR and Confederations, but I will not go into these cause it
just muddies the point.
Now, if you are using MSDP between AS (inter-AS) then MSDP can pass the
RPF by:
1. Having only 1 MSDP peer. (e.g. default peer)
2. Having the MSDP peer address = eMBGP peer address
3. Having the MSDP peer address = iMBGP peer address
We already discussed rule 1 and 3. So, if you look at rule 2 it
basically says, make sure that the route towards the source of the
multicast (e.g. the RP) is through the correct eMBGP neighbor (RPF via
MBGP table, not unicast table). I believe there is a secondary check
for rule 2 that say if the multicast source is through a given AS, make
sure that the eMBGP peer is reachable through that same AS.
And, if that wasn't fun enough, you can now use IGPs to pass the MSDP
RPF (new feature). And, if that wasn't just too much, you can now use
SSM and skip MSDP completely. 8)
By the way, my vote is for the later.
Now, hopefully that's as clear as mud, right?!
Andy
Get your CCIE Today!
Network Learning Inc
www.ccbootcamp.com (Cisco Training)
-----Original Message-----
From: Sheikh Rahman [mailto:Sheikh.Rahman@uk.didata.com]
Sent: Thursday, June 30, 2005 3:28 AM
To: Chris Lewis (chrlewis); Montiean; ccielab@groupstudy.com
Subject: RE: MSDP and MBGP question
Hi
Just following up on this topic. Do you think "ip msdp mesh-group"
command is required while configuring basic MSDP with out bgp. In my lab
it works with or without it, therefore not sure whether to keep this in
the config or not.
Thanks
Sheikh
-----Original Message-----
From: nobody@groupstudy.com on behalf of Chris Lewis (chrlewis)
Sent: Wed 29/06/2005 15:36
To: Montiean; ccielab@groupstudy.com
Cc:
Subject: RE: MSDP and MBGP question
MSDP will use BGP by default, the normal practice is to
configure ip
msdp default-peer A.B.C.D to identify the MSDP peeer and then
the route
to that peer can come from any routing method. AFAIK, this is
the only
thing to be concerned about with MSDP and BGP.
Chris
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
Behalf Of
Montiean
Sent: Wednesday, June 29, 2005 12:30 PM
To: ccielab@groupstudy.com
Subject: MSDP and MBGP question
Hi,
Per my understanding, when using multicast between diference
domain
like PIM-SM can consult RPF through unicast routing like BGP.
If the question asking to use MSDP. Do we need to enable MBGP
along
through domains?
I tested in my home lab. MSDP works without MBGP. Look like it
is
difference topic but I alway see it tied to each other when
there 's
topic in many books.
Appreciated your help to shine on this.
--Montiean
This archive was generated by hypermail 2.1.4 : Sun Sep 04 2005 - 17:00:29 GMT-3