In most scenarios, an MSDP peer is also a BGP peer. If an
autonomous system is a stub or nontransit autonomous system, and particularly
if the autonomous system is not multihomed, there is little or no reason to run
BGP to its transit autonomous system. A static default route at the stub
autonomous system, and a static route pointing to the stub prefixes at the
transit autonomous system, is generally sufficient. But if the stub autonomous
system is also a multicast domain and its RP must peer with an RP in the
neighboring domain, MSDP depends on the BGP next-hop database for its peer-RPF
checks. You can disable this dependency on BGP by defining a default peer from
which to accept all SA messages without performing the peer-RPF check. A
default MSDP peer must be a previously configured MSDP peer.
A stub autonomous
system also might want to have MSDP peerings with more than one RP for the sake
of redundancy. For example, SA messages cannot just be accepted from multiple
default peers, because there is no RPF check mechanism. Instead, SA messages
are accepted from only one peer. If that peer fails, SA messages are then
accepted from the other peer. The underlying assumption here, of course, is
that both default peers are sending the same SA messages.
illustrates a scenario where default MSDP peers might be used. In the figure, a
customer that owns Device B is connected to the Internet through two Internet
service providers (ISPs), one that owns Device A and the other that owns Device
C. They are not running BGP or MBGP between them. In order for the customer to
learn about sources in the ISP domain or in other domains, Device B identifies
Device A as its default MSDP peer. Device B advertises SA messages to both
Device A and Device C, but accepts SA messages either from Device A only or
Device C only. If Device A is the first default peer in the configuration, it
will be used if it is up and running. Only if Device A is not running will
Device B accept SA messages from Device C.
The ISP will also
likely use a prefix list to define which prefixes it will accept from the
customer device. The customer will define multiple default peers, each having
one or more prefixes associated with it.
The customer has two
ISPs to use. The customer defines both ISPs as default peers. As long as the
first default peer identified in the configuration is up and running, it will
be the default peer and the customer will accept all SA messages it receives
from that peer.
Figure 2. Default MSDP Peer
Device B advertises
SAs to Device A and Device C, but uses only Device A or Device C to accept SA
messages. If Device A is first in the configuration, it will be used if it is
up and running. Only when Device A is not running will Device B accept SAs from
Device C. This is the behavior without a prefix list.
If you specify a
prefix list, the peer will be a default peer only for the prefixes in the list.
You can have multiple active default peers when you have a prefix list
associated with each. When you do not have any prefix lists, you can configure
multiple default peers, but only the first one is the active default peer as
long as the device has connectivity to this peer and the peer is alive. If the
first configured peer goes down or the connectivity to this peer goes down, the
second configured peer becomes the active default, and so on.