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
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
following illustration and example uses routers in the configuration, any
device (router or switch) can be used.
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.