The value specified for the
keepalive-interval
argument must be less than the value specified for the
holdtime-interval
argument and must be at least one second.
Note
The hold-time timer is initialized to the value of the
hold-time-interval
argument whenever an MSDP peering
connection is established, and is reset to the value of the
hold-time-interval
argument whenever an MSDP
keepalive message is received. The hold-time timer is deleted whenever an MSDP peering connection is
closed. By default, the hold-time interval is set to 75 seconds.
Use the
hold-time-interval
argument to adjust the interval at which the MSDP peer will wait for keepalive
messages from other peers before declaring them down.
MSDP Connection-Retry Interval
You can adjust the interval at which all MSDP peers will wait after peering sessions are reset before attempting
to reestablish the peering sessions. This interval is referred to as the connection-retry interval. By default,
MSDP peers will wait 30 seconds after the session is reset before attempting to reestablish sessions with other
peers. The modified configured connection-retry interval applies to all MSDP peering sessions on the device.
Default MSDP Peers
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.
The figure 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.
IP Multicast Routing Configuration Guide, Cisco IOS XE Release 3SE (Catalyst 3650 Switches)
OL-29890-01
179
Configuring MSDP
MSDP Connection-Retry Interval
