MSDP

Feature history for MSDP

This table provides release and platform support information for the features explained in this module.

These features are available in all the releases subsequent to the one they were introduced in, unless noted otherwise.

Release

Feature name and description

Supported platform

Cisco IOS XE 17.18.1

MSDP: MSDP is a mechanism for connecting multiple PIM-SM domains and discovers multicast sources in other PIM domains.

Cisco C9350 Series Smart Switches

Cisco C9610 Series Smart Switches

Understand MSDP

MSDP is a mechanism for connecting multiple PIM-SM domains and discovers multicast sources in other PIM domains.

This section provides information about using MSDP to interconnect multiple PIM-SM domains.

Benefits and use of MSDP

The main advantage of MSDP is that it reduces the complexity of interconnecting multiple PIM-SM domains by allowing PIM-SM domains to use an interdomain source tree (rather than a common shared tree). When MSDP is configured in a network, RPs exchange source information with RPs in other domains. MSDP uses a more manageable approach to build multicast distribution trees between multiple domains.

An RP can join the interdomain source tree for sources that are sending to groups for which it has receivers. The RP is the root of the shared tree with branches to all active receivers in its domain. When a last-hop device learns of a new source outside the PIM-SM domain (through the arrival of a multicast packet from the source down the shared tree), it then can send a join toward the source and join the interdomain source tree.


Note

If the RP either has no shared tree for a particular group or a shared tree whose outgoing interface list is null, it does not send a join to the source in another domain.

When MSDP is enabled, an RP in a PIM-SM domain maintains MSDP peering relationships with MSDP-enabled devices in other domains. This peering relationship occurs over a TCP connection, where primarily a list of sources sending to multicast groups is exchanged. MSDP uses TCP (port 639) for its peering connections. As with BGP, you must explicitly configure each peer for point-to-point TCP peering. The TCP connections between RPs, moreover, are achieved by the underlying routing system. The receiving RP uses the source lists to establish a source path. If the multicast sources are of interest to a domain that has receivers, multicast data is delivered over the normal, source-tree building mechanism provided by PIM-SM. MSDP announces sources that send data to a multicast group. These announcements must originate at the RP of the domain.


Note

MSDP depends on BGP or multiprotocol BGP (MBGP) for interdomain operation. We recommend that you run MSDP on RPs sending to global multicast groups.

The figure illustrates MSDP operating between two MSDP peers. PIM uses MSDP as the standard mechanism to register a source with the RP of a domain.


Note

Although this illustration and example uses routers in the configuration, any device (router or switch) can be used.
Figure 1. MSDP running between RP peers

When MSDP is implemented, this sequence of events occurs:

  1. When a PIM designated device (DR) registers a source with its RP, the RP sends a Source-Active (SA) message to all MSDP peers.


    Note

    The DR sends the encapsulated data to the RP only once per source (when the source goes active). If the source times out, this process happens again when it goes active again. This situation is different from the periodic SA message that contains all sources that are registered to the originating RP. Those SA messages are MSDP control packets, and, thus, do not contain encapsulated data from active sources.

  2. The SA message identifies the source address, the group that the source is sending to, and the address or the originator ID of the RP, if configured.

  3. Each MSDP peer that receives the SA message floods the SA message to all of its peers downstream from the originator. In some cases (such as the case with the RPs in PIM-SM domains B and C in the figure), an RP may receive a copy of an SA message from more than one MSDP peer. To prevent looping, the RP consults the BGP next-hop database to determine the next hop toward the originator of the SA message. If both MBGP and unicast BGP are configured, MBGP is checked first, and then unicast BGP. That next-hop neighbor is the RPF-peer for the originator. SA messages that are received from the originator on any interface other than the interface to the RPF peer are dropped. The SA message flooding process, therefore, is referred to as peer-RPF flooding. Because of the peer-RPF flooding mechanism, BGP or MBGP must be running in conjunction with MSDP.


    Note

    • MBGP is not required in MSDP mesh group scenarios. For more information about MSDP mesh groups, see the Configure an MSDP mesh group section.

    • MBGP is not required in default MSDP peer scenarios or in scenarios where only one MSDP peer is configured. For more information, see the Configure a default MSDP peer section.

  4. When an RP receives an SA message, it checks to see whether there are any members of the advertised groups in its domain by checking to see whether there are interfaces on the group’s (*, G) outgoing interface list. If there are no group members, the RP does nothing. If there are group members, the RP sends an (S, G) join toward the source. As a result, a branch of the interdomain source tree is constructed across autonomous system boundaries to the RP. As multicast packets arrive at the RP, they are then forwarded down its own shared tree to the group members in the RP’s domain. The members’ DRs then have the option of joining the rendezvous point tree (RPT) to the source using standard PIM-SM procedures.

  5. The originating RP continues to send periodic SA messages for the (S, G) state every 60 seconds for as long as the source is sending packets to the group. When an RP receives an SA message, it caches the SA message. Suppose, for example, that an RP receives an SA message for (172.16.5.4, 228.1.2.3) from originating RP 10.5.4.3. The RP consults its mroute table and finds that there are no active members for group 228.1.2.3, so it passes the SA message to its peers downstream of 10.5.4.3. If a host in the domain then sends a join to the RP for group 228.1.2.3, the RP adds the interface toward the host to the outgoing interface list of its (*, 224.1.2.3) entry. Because the RP caches SA messages, the device will have an entry for (172.16.5.4, 228.1.2.3) and can join the source tree as soon as a host requests a join.


Note

In all current and supported software releases, the caching of MSDP SA messages is mandatory and cannot be manually enabled or disabled. By default, when an MSDP peer is configured, theip multicast cache-sa-state command will automatically be added to the running configuration.

MSDP message types

There are four basic MSDP message types, each encoded in a Type, Length, and Value (TLV) data format.

SA messages

SA messages are used to advertise active sources in a domain. These SA messages may contain the initial multicast data packet sent by the source.

SA messages contain the IP address of the originating RP and one or more (S, G) pairs being advertised. In addition, the SA message may contain an encapsulated data packet.


Note

For more information about SA messages, see the SA messaging section.

SA request messages

SA request messages request a list of active sources for a specific group. These messages are sent to an MSDP SA cache that maintains a list of active (S, G) pairs in its SA cache. SA request messages reduce join latency by providing a list of active sources for a group, avoiding a wait time of up to 60 seconds for originating RPs to readvertise all active sources.


Note

For more information about SA request messages, see the Request source information from MSDP peers section.

SA response messages

SA response messages are sent by the MSDP peer in response to an SA request message. SA response messages contain the IP address of the originating RP and one or more (S, G) pairs of the active sources in the originating RP’s domain that are stored in the cache.


Note

For more information about SA response messages, see the Control the response to outgoing SA request messages from MSDP peers section.

Keepalive messages

Keepalive messages are sent every 60 seconds to maintain the MSDP session's activity. If no keepalive messages or SA messages are received for 75 seconds, the MSDP session is reset.


Note

For more information about keepalive messages, see the Adjust the MSDP keepalive and hold-time intervals section.

SA messaging

This section describes SA messaging in detail.

SA message origin

SA messages are triggered by an RP (assuming MSDP is configured) when any new source goes active within a local PIM-SM domain. A local source is a source that is directly connected to the RP or is the first-hop DR that has registered with it. An RP originates SA messages only for local sources in its PIM-SM domain; that is, for local sources that register with it.


Note

A local source is denoted by the A flag being set in the (S, G) mroute entry on the RP (which can be viewed in the output of the show ip mroute command). This flag indicates that the source is a candidate for advertisement by the RP to other MSDP peers.

When a source is in the local PIM-SM domain, it triggers the RP to create (S, G) state. New sources are detected by the RP either by the receipt of a register message or the arrival of the first (S, G) packet from a directly connected source. The source's initial multicast packet, encapsulated in the register message or directly received, is included in the initial SA message.

SA message receipt

SA messages are accepted only from the MSDP RPF peer that provides the best path back to the originator. The same SA message arriving from other MSDP peers must be ignored or SA loops can occur. Deterministically selecting the MSDP RPF peer for an arriving SA message requires knowledge of the MSDP topology. However, MSDP does not distribute topology information in the form of routing updates. MSDP infers this information by using MBGP routing data as the best approximation of the MSDP topology for the SA RPF check mechanism. Therefore, an MSDP topology must follow the same general structure as the BGP peer topology. With a few exceptions, such as default MSDP peers and MSDP peers in unique configurations, most MSDP peers should also be BGP peers.

How RPF check rules are applied to SA messages

The rules that apply to RPF checks for SA messages are dependent on the BGP peerings between the MSDP peers:

  • Rule 1: Applied when the sending MSDP peer is also an interior MBGP peer.

  • Rule 2: Applied when the sending MSDP peer is also an exterior MBGP peer.

  • Rule 3: Applied when the sending MSDP peer is not an MBGP peer.

RPF checks are not performed in these cases:

  • If the sending MSDP peer is the only MSDP peer, which would be the case if only a single MSDP peer or a default MSDP peer is configured.

  • If the sending MSDP peer is a member of a mesh group.

  • If the sending MSDP peer address is the RP address contained in the SA message.

How the software determines the rule to apply to RPF checks

The software determines which RPF rule to apply to RPF checks using this logic. Find the MBGP neighbor that has the same IP address as the sending MSDP peer.

  • If the matching MBGP neighbor is an internal BGP (iBGP) peer, apply Rule 1.

  • If the matching MBGP neighbor is an external BGP (eBGP) peer, apply Rule 2.

  • If no match is found, apply Rule 3.

The IP address used to configure an MSDP peer must match the one used for configuring the MBGP peer on the same device.

Rule 1 of RPF checking of SA messages in MSDP

Rule 1 of RPF checking in MSDP applies when the sending MSDP peer is also an iMBGP peer. When Rule 1 is applied, the RPF check proceeds as follows:

Summary

  1. The peer searches the BGP Multicast Routing Information Base (MRIB) for the best path to the RP that originated the SA message. If a path is not found in the MRIB, the peer then searches the Unicast Routing Information Base (URIB). If a path is still not found, the RPF check fails.

  2. If the previous search succeeds (the best path is found), the peer finds the address of the BGP neighbor for this path. It will be the address of the BGP neighbor that sent the peer the path in BGP update messages.


    Note

    • The BGP neighbor address is not the same as the next-hop address in the path. Since iMBGP peers do not modify the next-hop attribute, this address typically differs from the BGP peer's address that provided the path.

    • The BGP neighbor address is not necessarily the same as the BGP ID of the peer that sent the peer the path.

  3. If the IP address of the sending MSDP peer is the same as the BGP neighbor address (that is, the address of the BGP peer that sent the peer the path), then the RPF check succeeds; otherwise it fails.

Implications of Rule 1 of RPF Checking on MSDP

The MSDP topology must mirror the MBGP topology. In general, wherever there is an iMBGP peer connection between two devices, an MSDP peer connection should be configured. More specifically, the IP address of the far-end MSDP peer connection must match the far-end iMBGP peer connection. The addresses must be the same because the BGP topology between iMBGP peers inside an autonomous system is not described by the AS path.

Instead, if iMBGP peers updated the next-hop address when sending an update, the peer could rely on it to describe the iMBGP topology (and hence the MSDP topology). However, because the default behavior for iMBGP peers is to not update the next-hop address, the peer cannot rely on the next-hop address to describe the MBGP topology (MSDP topology). Instead, the iMBGP peer uses the address of the iMBGP peer that sent the path to describe the iMBGP topology (MSDP topology) inside the autonomous system.


Tip

Ensure that you use the same address for both iMBGP and MSDP peer addresses.
Rule 2 of RPF checking of SA messages in MSDP

Rule 2 of RPF checking in MSDP is applied when the sending MSDP peer is also an eMBGP peer. When Rule 2 is applied, the RPF check proceeds as follows:

Summary

  1. The peer searches the BGP MRIB for the best path to the RP that originated the SA message. If a path is not found in the MRIB, the peer then searches the URIB. If the search does not find a path, the RPF check fails.

  2. If the previous search succeeds (that is, the best path is found), the peer then examines the path. If the first autonomous system in the best path to the RP is the same as the autonomous system of the eMBGP peer (which is also the sending MSDP peer), then the RPF check succeeds; otherwise it fails.

Implications of Rule 2 of RPF Checking on MSDP

The MSDP topology must mirror the MBGP topology. Configure an MSDP peer connection wherever there is an eMBGP peer connection between two devices. Unlike Rule 1, the IP address of the far-end MSDP peer connection does not have to match the far-end eMBGP peer connection.The reason that the addresses do not have to be identical is that BGP topology between two eMBGP peers is not described by the AS path.

Rule 3 of RPF checking of SA messages in MSDP

Rule 3 of RPF checking is applied when the sending MSDP peer is not a MBGP peer at all. When Rule 3 is applied, the RPF check proceeds as follows:

Summary

  1. The peer searches the BGP MRIB for the best path to the RP that originated the SA message. Without a path in the MRIB, the peer searches the URIB. If a path is still not found, the RPF check fails.

  2. If the previous search succeeds (that is, the best path to the RP that originated the SA message is found), the peer then searches the BGP MRIB for the best path to the MSDP peer that sent the SA message. If a path is not found in the MRIB, the peer then searches the URIB. If a path is still not found, the RPF check fails.


    Note

    The autonomous system of the MSDP peer that sent the SA is the origin autonomous system, which is the last autonomous system in the AS path to the MSDP peer.

  3. If the first autonomous system in the best path to the RP is the same as the autonomous system of the sending MSDP peer, then the RPF check succeeds; otherwise it fails.

SA request messages

You can configure a noncaching device to send SA request messages to one or more specified MSDP peers. To reduce join latency for a noncaching RP, enable it to send SA request messages to its MSDP peer that is caching SAs. When a host requests a join to a particular group, the noncaching RP sends an SA request message to its caching peers. If a peer has cached source information for the group in question, it sends the information to the requesting RP with an SA response message. The requesting RP uses the information in the SA response but does not forward the message to any other peers. If a noncaching RP receives an SA request, it sends an error message to the requestor.


Note

Caching of MSDP SA messages is mandatory in all current and supported software releases; it cannot be manually enabled or disabled. By default, when an MSDP peer is configured, the configured commands are automatically added to the running configuration.

SA request filters

By default, a device honors all outgoing SA request messages from its MSDP peers; that is, it sends cached source information to requesting MSDP peers in SA response messages. You can control the outgoing SA request messages that a device will honor from specified peers by creating an SA request filter. An SA request filter controls the outgoing SA requests that the device will honor from MSDP peers.

  • Filter all SA request messages from a specified peer by configuring the device to ignore all SA requests from the specified MSDP peer.

  • Filter a subset of SA request messages from a specified peer based on groups defined in a standard access list by configuring the device to honor only SA request messages from the MSDP peer that match the groups defined in a standard access list. SA request messages from the specified peer for other groups will be ignored.

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 static routes pointing to stub prefixes at the transit autonomous system are 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. To disable the dependency on BGP, define a default peer to accept all SA messages without performing the peer-RPF check. A default MSDP peer must be a previously configured MSDP peer.

If your switch does not support BGP and MBGP, you cannot configure an MSDP peer on the local switch by using the ip msdp peer global configuration command. Instead, you define a default MSDP peer (by using the ip msdp default-peer global configuration command) which can accept all SA messages for the switch. The default MSDP peer must be a previously configured MSDP peer. When your switch does not peer with an MSDP peer, configure a default MSDP peer. If only one MSDP peer is configured, your switch accepts all SA messages from it.

A stub autonomous system may use MSDP peerings with multiple RPs for 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 likely uses a prefix list to accept prefixes from the customer device. The customer defines multiple default peers with associated prefixes. 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.


Note

Although the illustration uses routers in the configuration, you can use any device, such as a router or switch.
Figure 2. Default MSDP peer scenario

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. Without prefix lists, configure multiple default peers. Only the first is active, assuming it is connected and alive. If the first configured peer or its connectivity goes down, the second configured peer becomes the active default.

MSDP mesh groups

An MSDP mesh group is a group of MSDP speakers that have fully meshed MSDP connectivity between one another. In other words, each MSDP peer in the group must establish an MSDP peering relationship (MSDP connection) with every other peer in the group. When an MSDP mesh group is configured between a group of MSDP peers, SA message flooding is reduced. When an MSDP peer in the group receives an SA message from another peer, it assumes the message has been sent to all other peers in the group. As a result, it is not necessary for the receiving MSDP peer to flood the SA message to the other MSDP peers in the group.

Benefits of MSDP mesh groups

  • Optimizes SA flooding by allowing two or more peers to efficiently share information within the group.

  • SA messages are not flooded to other mesh group peers reducing the amount of SA traffic across the Internet.

  • SA messages are always accepted from mesh group peers by eliminating RPF checks on arriving SA messages.

MSDP MD5 password authentication

The MSDP Message Digest 5 (MD5) password authentication feature enhances security by supporting MD5 signature protection on a TCP connection between two MSDP peers. This feature provides added security by protecting MSDP against the threat of spoofed TCP segments being introduced into the TCP connection stream.

How MSDP MD5 password authentication works

Developed in accordance with RFC 2385, the MSDP MD5 password authentication feature verifies each segment sent on the TCP connection between MSDP peers. The ip msdp password peer command enables MD5 authentication for TCP connections between two MSDP peers. When MD5 authentication is enabled between two MSDP peers, each segment sent on the TCP connection between the peers is verified. For the connection to be established, MD5 authentication must be configured with the same password on both MSDP peers. Configuring MD5 authentication causes the Cisco IOS software to generate and verify the MD5 digest of every segment sent on the TCP connection.

Benefits of MSDP MD5 password authentication

  • MSDP is protected against the threat of spoofed TCP segments introduced into the TCP connection stream.

  • The industry-standard MD5 algorithm is used for improved reliability and security.

MSDP intervals

You can configure MSDP intervals for message and peer communication.

MSDP keepalive interval

The ip msdp keepalive command is used to adjust the interval at which an MSDP peer will send keepalive messages and the interval at which the MSDP peer will wait for keepalive messages from other peers before declaring them down.

Once an MSDP peering session is established, each side sends a keepalive message and sets a timer. If the keepalive timer expires, the local MSDP peer sends a keepalive message and restarts its keepalive timer; this interval is referred to as the keepalive interval. The keepalive-interval argument is used to adjust the interval for which keepalive messages will be sent. The keepalive timer is set to the value specified for the keepalive-interval argument when the peer comes up. The keepalive timer is reset to the value of the keepalive-interval argument both when an MSDP keepalive message is sent to the peer and when the timer expires. The keepalive timer is deleted when an MSDP peering session is closed. The hold-time interval is set to a default of 75 seconds.


Note

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.

MSDP hold-time interval

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 how long the MSDP peer waits for keepalive messages before declaring peers down.

MSDP connection-retry interval

You can adjust the interval that all MSDP peers wait after peering sessions are reset, before attempting to reestablish the sessions. This interval is called the connection-retry interval. By default, MSDP peers wait 30 seconds after a 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.

MSDP TTL thresholds

The time-to-live (TTL) value provides a means to limit the number of hops a packet can take before being dropped. The ip multicast ttl-threshold command is used to specify a TTL for data-encapsulated SA messages sent to specified MSDP peers. By default, multicast data packets in SA messages are sent to an MSDP peer, provided the TTL value of the packet is greater than 0, which is standard TTL behavior.

In general, a TTL-threshold problem can be introduced by the encapsulation of a source’s initial multicast packet in an SA message. When a multicast packet is encapsulated inside a unicast SA message with a TTL of 255, its TTL does not decrease during the travel to the MSDP peer. The total number of hops traversed by the SA message can differ significantly from a normal multicast packet because multicast and unicast traffic might take paths that are entirely different to the MSDP peer and the remote PIM-SM domain. As a result, encapsulated packets can end up violating TTL thresholds. The solution to this problem is to configure a TTL threshold that is associated with any multicast packet that is encapsulated in an SA message sent to a particular MSDP peer using the ip multicast ttl-threshold command. The ip msdp ttl-threshold command prevents any multicast packet whose TTL in the IP header is less than the TTL value specified for the ttl-value argument from being encapsulated in SA messages sent to that peer.

Configure MSDP

Before you configure MSDP, the addresses of all MSDP peers must be known in Border Gateway Protocol (BGP).

MSDP peer configuration

Configuring an MSDP peer is required; all other tasks are optional.

Configure an MSDP peer


Note

By enabling an MSDP peer, you implicitly enable MSDP.

Before you begin

  • IP multicast routing must be enabled and PIM-SM must be configured.

  • With the exception of a single MSDP peer, default MSDP peer, and MSDP mesh group scenarios, all MSDP peers must be configured to run BGP prior to being configured for MSDP.

Procedure
  Command or Action Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

  • Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ip msdp peer {peer-name | peer-address } [connect-source type number ] [remote-as as-number ]

Example:

Device(config)# ip msdp peer 192.168.1.2 connect-source loopback0

Enables MSDP and configures an MSDP peer as specified by the DNS name or IP address.

Note

 

The device that is selected to be configured as an MSDP peer is also usually a BGP neighbor. If it is not, see the Configuring a Default MSDP Peer section or the Configuring an MSDP Mesh Group section.

  • If you specify the connect-source keyword, the primary address of the specified local interface type and number values are used as the source IP address for the TCP connection. The connect-source keyword is recommended, especially for MSDP peers on a border that peer with a device inside of a remote domain.

Step 4

ip msdp description {peer-name | peer-address } text

Example:

Device(config)# ip msdp description 192.168.1.2 router at customer a

(Optional) Configures a description for a specified peer to make it easier to identify in a configuration or in show command output.

Step 5

end

Example:

Device(config)# end

Exits global configuration mode and returns to privileged EXEC mode.

Shut Down an MSDP Peer

If you are configuring several MSDP peers and you do not want any of the peers to go active until you have finished configuring all of them, you can shut down each peer, configure each peer, and later bring each peer up. You may also want to shut down an MSDP session without losing the configuration for that MSDP peer.


Note

When an MSDP peer is shut down, the TCP connection is terminated and not restarted until the peer is brought back up using the no ip msdp shutdown command (for the specified peer).

Before you begin

MSDP is running and the MSDP peers must be configured.

Procedure
  Command or Action Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

  • Enter your password if prompted.

Step 2

configure terminal

Example:
Device# configure terminal

Enters global configuration mode.

Step 3

ip msdp shutdown {peer-name | peer-address }

Example:
Device(config)# ip msdp shutdown 192.168.1.3

Administratively shuts down the specified MSDP peer.

Step 4

Repeat Step 3 to shut down additional MSDP peers.

--

Step 5

end

Example:
Device(config)# end

Exits global configuration mode and returns to privileged EXEC mode.

Configure a default MSDP peer

Perform this optional task to configure a default MSDP peer.

Before you begin

You must first configure an MSDP peer before designating it as a default MSDP peer.

Procedure
  Command or Action Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

  • Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ip msdp default-peer {peer-address | peer-name } [prefix-list list ]

Example:

Device(config)# ip msdp default-peer 192.168.1.3

Configures a default peer from which to accept all MSDP SA messages

Step 4

exit

Example:

Device(config)# exit

Exits global configuration mode and returns to privileged EXEC mode.

Configure an MSDP mesh group

You can configure multiple mesh groups per device.

Procedure
  Command or Action Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

  • Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ip msdp mesh-group mesh-name {peer-address | peer-name }

Example:

Device(config)# ip msdp mesh-group peermesh

Configures an MSDP mesh group and indicates that an MSDP peer belongs to that mesh group.

Note

 

All MSDP peers on a device that participate in a mesh group must be fully meshed with all other MSDP peers in the group. Each MSDP peer on each device must be configured as a peer using the ip msdp peer command and also as a member of the mesh group using the ip msdp mesh-group command.

Step 4

Repeat Step 3 to add MSDP peers as members of the mesh group.

--

Step 5

exit

Example:

Device(config)# exit

Exits global configuration mode and returns to privileged EXEC mode.

Configure MSDP MD5 password authentication between MSDP peers

Perform this optional task to configure MSDP MD5 password authentication between MSDP peers.

Procedure
  Command or Action Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

  • Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ip msdp password peer {peer-name | peer-address } [encryption-type ] string

Example:

Device(config)# ip msdp password peer 10.32.43.144 0 test

Enables MD5 password encryption for a TCP connection between two MSDP peers.

Note

 

MD5 authentication must be configured with the same password on both MSDP peers; otherwise, the connection between them will not be made.

  • If you configure or change the password or key, which is used for MD5 authentication between two MSDP peers, the local device does not disconnect the existing session after you configure the password. You must manually disconnect the session to activate the new or changed password.

Step 4

exit

Example:

Device(config)# exit

Exits global configuration mode and returns to privileged EXEC mode.

Step 5

show ip msdp peer [peer-address | peer-name]

Example:

Device# show ip msdp peer

(Optional) Displays detailed information about MSDP peers.

Note

 

Use this command to verify whether MD5 password authentication is enabled on an MSDP peer.

What to do next

If a device has a password configured for an MSDP peer but the MSDP peer does not, a message such as this will appear on the console while the devices attempt to establish an MSDP session between them: 


%TCP-6-BADAUTH: No MD5 digest from [peer's IP address]:11003 to [local router's 
IP address]:179

Similarly, if the two devices have different passwords configured, a message such as this will appear on the console: 


%TCP-6-BADAUTH: Invalid MD5 digest from [peer's IP address]:11004 to [local router's 
IP address]:179

The debug ip tcp transactions command is used to display information on significant TCP transactions such as state changes, retransmissions, and duplicate packets. In the context of monitoring or troubleshooting MSDP MD5 password authentication, use the debug ip tcp transactions command to verify that the MD5 password is enabled and that the keepalive message is received by the MSDP peer.

Request source information from MSDP peers

Perform this optional task to enable a device to request source information from MSDP peers.


Note

Because SA caching is enabled by default and cannot be explicitly enabled or disabled in earlier Cisco software releases, performing this task is seldom needed.

Procedure
  Command or Action Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

  • Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ip msdp sa-request {peer-address | peer-name }

Example:

Device(config)# ip msdp sa-request 192.168.10.1

Specifies that the device send SA request messages to the specified MSDP peer.

Step 4

Repeat Step 3 to specify that the device send SA request messages to additional MSDP caching peers.

--

Step 5

exit

Example:

Device(config)# exit

Exits global configuration mode and returns to privileged EXEC mode.

MSDP timer adjustments

Perform the tasks in this section to configure MSDP timers.

Adjust the MSDP keepalive and hold-time intervals

Perform this optional task to adjust the interval at which an MSDP peer will send keepalive messages and the interval at which the MSDP peer will wait for keepalive messages from other peers before declaring them down. By default, it may take up to 75 seconds for an MSDP peer to detect that a peering session with another MSDP peer has terminated. In network environments with redundant MSDP peers, decreasing the hold-time interval can expedite reconvergence of MSDP peers if an MSDP peer fails.


Note

We recommend that you do not change the command defaults for the ip msdp keepalive command, because the command defaults are in accordance with RFC 3618, Multicast Source Discovery Protocol. If your network environment requires that you modify the defaults, you must configure the same time values for the keepalive-interval and hold-time-interval arguments on both ends of the MSDP peering session.

Procedure
  Command or Action Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

  • Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ip msdp keepalive {peer-address | peer-name } keepalive-interval hold-time-interval

Example:

Device(config)# ip msdp keepalive 10.1.1.3 40 55

Configures the interval at which an MSDP peer will send keepalive messages and the interval at which the MSDP peer will wait for keepalive messages from other peers before declaring them down.

Step 4

Repeat Step 3 to adjust the keepalive message interval for additional MSDP peers.

--

Step 5

exit

Example:

Device(config)# exit

Exits global configuration mode and returns to privileged EXEC mode.

Adjust the MSDP connection-retry interval

Perform this optional task to adjust the interval MSDP peers wait to reestablish peering sessions after they are reset. In environments where fast recovery of SA messages is required, such as trading floors, consider decreasing the connection-retry interval from the default 30 seconds.

Procedure
  Command or Action Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

  • Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ip msdp timer connection-retry-interval

Example:

Device# ip msdp timer 45

Configures the interval at which MSDP peers will wait after peering sessions are reset before attempting to reestablish the peering sessions.

Step 4

exit

Example:

Device(config)# exit

Exits global configuration mode and returns to privileged EXEC mode.

SA messaging

Perform the tasks in this section for SA messaging.

Control SA messages originated by an RP for local sources

Perform this task to control SA messages originated by an RP by enabling a filter to restrict which registered sources are advertised in SA messages.


Note

For best practice information related to configuring MSDP SA message filters, see the Multicast Source Discovery Protocol SA Filter Recommendations tech note.

Procedure
  Command or Action Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

  • Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ip msdp redistribute [list access-list ] [asn as-access-list ] [route-map map-name ]

Example:

Device(config)# ip msdp redistribute route-map customer-sources

Enables a filter for MSDP SA messages originated by the local device.

Note

 

The ip msdp redistribute command can also be used to advertise sources that are known to the RP but not registered. However, it is strongly recommended that you not originate advertisements for sources that have not registered with the RP.

Step 4

exit

Example:

Device(config)# exit

Exits global configuration mode and returns to privileged EXEC mode.

Control SA messages forwarding to MSDP peers using outgoing filter lists

Perform this optional task to control the forwarding of SA messages to MSDP peers by configuring outgoing filter lists.


Note

For best practice information related to configuring MSDP SA message filters, see the Multicast Source Discovery Protocol SA Filter Recommendations tech note.

Procedure
  Command or Action Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

  • Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ip msdp sa-filter out {peer-address | peer-name } [list access-list ] [route-map map-name ] [rp-list access-list | rp-route-map map-name ]

Example:

Device(config)# ip msdp sa-filter out 192.168.1.5 peerone

Enables a filter for outgoing MSDP messages.

Step 4

Repeat Step 3 to configure outgoing filter lists for additional MSDP peers.

--

Step 5

exit

Example:

Device(config)# exit

Exits global configuration mode and returns to privileged EXEC mode.

Control SA messages receipt from MSDP peers using incoming filter lists

Perform this optional task to control the receipt of incoming SA messages from MSDP peers.


Note

For best practice information related to configuring MSDP SA message filters, see the Multicast Source Discovery Protocol SA Filter Recommendations tech note.

Procedure
  Command or Action Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

  • Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ip msdp sa-filter in {peer-address | peer-name } [list access-list ] [route-map map-name ] [rp-list access-list | rp-route-map map-name ]

Example:

Device(config)# ip msdp sa-filter in 192.168.1.3

Enables a filter for incoming MSDP SA messages.

Step 4

Repeat Step 3 to configure incoming filter lists for additional MSDP peers.

--

Step 5

exit

Example:

Device(config)# exit

Exits global configuration mode and returns to privileged EXEC mode.

Limit the multicast data sent in SA messages using TTL thresholds

Perform this optional task to establish a time to live (TTL) threshold to limit the multicast data sent in SA messages.

Procedure
  Command or Action Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

  • Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ip msdp ttl-threshold {peer-address | peer-name } ttl-value

Example:

Device(config)# ip msdp ttl-threshold 192.168.1.5 8

Sets a TTL value for MSDP messages originated by the local device.

  • By default, multicast data packets in SA messages are sent to an MSDP peer, provided the TTL value of the packet is greater than 0, which is standard TTL behavior.

Step 4

exit

Example:

Device(config)# exit

Exits global configuration mode and returns to privileged EXEC mode.

Control the response to outgoing SA request messages from MSDP peers

Perform this optional task to control the outgoing SA request messages that the device will honor from MSDP peers.

Procedure
  Command or Action Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

  • Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ip msdp filter-sa-request {peer-address | peer-name } [list access-list ]

Example:

Device(config)# ip msdp filter sa-request 172.31.2.2 list 1

Enables a filter for outgoing SA request messages.

Note

 

Only one SA request filter can be configured per MSDP peer.

Step 4

Repeat Step 3 to configure SA request filters for additional MSDP peers.

--

Step 5

exit

Example:

Device(config)# exit

Exits global configuration mode and returns to privileged EXEC mode.

Configure an originating address other than the RP address

Perform this optional task to allow an MSDP speaker that originates an SA message to use the IP address of its interface as the RP address in the SA message.

You can also change the originator ID for any one of these reasons:

  • If you configure multiple devices in an MSDP mesh group for Anycast RP.

  • If you have a device that borders a PIM-SM domain and a PIM-DM domain. If a device borders a PIM-SM domain and a PIM-DM domain and you want to advertise active sources within the PIM-DM domain, configure the RP address in SA messages to be the address of the originating device’s interface.

Before you begin

MSDP is enabled and the MSDP peers are configured. For more information about configuring MSDP peers, see the Configure an MSDP peer section.

Procedure
  Command or Action Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

  • Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ip msdp originator-id type number

Example:

Device(config)# ip msdp originator-id ethernet 1

Configures the RP address in SA messages to be the address of the originating device’s interface.

Step 4

exit

Example:

Device(config)# exit

Exits global configuration mode and returns to privileged EXEC mode.

Prevent DoS attacks by limiting the number of SA messages

Perform this optional (but highly recommended) task to limit the overall number of SA messages that the device can accept from specified MSDP peers. Performing this task protects an MSDP-enabled device from distributed denial-of-service (DoS) attacks.


Note

We recommend that you perform this task for all MSDP peerings on the device.

Procedure
  Command or Action Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

  • Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ip msdp sa-limit {peer-address | peer-name } sa-limit

Example:

Device(config)# ip msdp sa-limit 192.168.10.1 100

Limits the number of SA messages allowed in the SA cache from the specified MSDP.

Step 4

Repeat Step 3 to configure SA limits for additional MSDP peers.

--

Step 5

exit

Example:

Device(config)# exit

Exits global configuration mode and returns to privileged EXEC mode.

Step 6

show ip msdp count [as-number ]

Example:

Device# show ip msdp count

(Optional) Displays the number of sources and groups originated in MSDP SA messages and the number of SA messages from an MSDP peer in the SA cache.

Step 7

show ip msdp peer [peer-address | peer-name ]

Example:

Device# show ip msdp peer

(Optional) Displays detailed information about MSDP peers.

Note

 

The output of this command displays the number of SA messages received from MSDP peers that are stored in the cache.

Step 8

show ip msdp summary

Example:

Device# show ip msdp summary

(Optional) Displays MSDP peer status.

Note

 

The output of this command displays a per-peer “SA Count” field that displays the number of SAs stored in the cache.

Monitor and maintain MSDP

Use the commands in these topics to monitor and maintain MSDP statistics.

Monitor MSDP

Perform this optional task to monitor MSDP SA messages, peers, state, and peer status.

Procedure

Step 1

enable

Example:


Device# enable

Enables privileged EXEC mode.

  • Enter your password if prompted.

Step 2

debug ip msdp [peer-address | peer-name ] [detail ] [routes ]

Use this command to debug MSDP activity.

Use the optional peer-address or peer-name argument to specify for which peer debug events are logged.

This is a sample output from the debug ip msdp command:

Example:

Device# debug ip msdp

MSDP debugging is on
Device#
MSDP: 224.150.44.254: Received 1388-byte message from peer
MSDP: 224.150.44.254: SA TLV, len: 1388, ec: 115, RP: 172.31.3.92 
MSDP: 224.150.44.254: Peer RPF check passed for 172.31.3.92, used EMBGP peer
MSDP: 224.150.44.250: Forward 1388-byte SA to peer
MSDP: 224.150.44.254: Received 1028-byte message from peer
MSDP: 224.150.44.254: SA TLV, len: 1028, ec: 85, RP: 172.31.3.92 
MSDP: 224.150.44.254: Peer RPF check passed for 172.31.3.92, used EMBGP peer
MSDP: 224.150.44.250: Forward 1028-byte SA to peer
MSDP: 224.150.44.254: Received 1388-byte message from peer
MSDP: 224.150.44.254: SA TLV, len: 1388, ec: 115, RP: 172.31.3.111 
MSDP: 224.150.44.254: Peer RPF check passed for 172.31.3.111, used EMBGP peer
MSDP: 224.150.44.250: Forward 1388-byte SA to peer
MSDP: 224.150.44.250: Received 56-byte message from peer
MSDP: 224.150.44.250: SA TLV, len: 56, ec: 4, RP: 192.168.76.241 
MSDP: 224.150.44.250: Peer RPF check passed for 192.168.76.241, used EMBGP peer
MSDP: 224.150.44.254: Forward 56-byte SA to peer
MSDP: 224.150.44.254: Received 116-byte message from peer
MSDP: 224.150.44.254: SA TLV, len: 116, ec: 9, RP: 172.31.3.111 
MSDP: 224.150.44.254: Peer RPF check passed for 172.31.3.111, used EMBGP peer
MSDP: 224.150.44.250: Forward 116-byte SA to peer
MSDP: 224.150.44.254: Received 32-byte message from peer
MSDP: 224.150.44.254: SA TLV, len: 32, ec: 2, RP: 172.31.3.78 
MSDP: 224.150.44.254: Peer RPF check passed for 172.31.3.78, used EMBGP peer
MSDP: 224.150.44.250: Forward 32-byte SA to peer

Step 3

debug ip msdp resets

Use this command to debug MSDP peer reset reasons.

Example:

Device# debug ip msdp resets

Step 4

show ip msdp count [as-number ]

Use this command to display the number of sources and groups originated in MSDP SA messages and the number of SA messages from an MSDP peer in the SA cache. The ip msdp cache-sa-state command must be configured for this command to produce any output.

This is a sample output from the show ip msdp count command:

Example:

Device# show ip msdp count

SA State per Peer Counters, <Peer>: <# SA learned>
    192.168.4.4: 8
SA State per ASN Counters, <asn>: <# sources>/<# groups>
    Total entries: 8
    ?: 8/8

Step 5

show ip msdp peer [peer-address | peer-name ]

Use this command to display detailed information about MSDP peers.

Use the optional peer-address or peer-name argument to display information about a particular peer.

This is a sample output from the show ip msdp peer command:

Example:

Device# show ip msdp peer 192.168.4.4

MSDP Peer 192.168.4.4 (?), AS 64512 (configured AS)
  Connection status:
    State: Up, Resets: 0, Connection source: Loopback0 (2.2.2.2)
    Uptime(Downtime): 00:07:55, Messages sent/received: 8/18
    Output messages discarded: 0
    Connection and counters cleared 00:08:55 ago
  SA Filtering:
    Input (S,G) filter: none, route-map: none
    Input RP filter: none, route-map: none
    Output (S,G) filter: none, route-map: none
    Output RP filter: none, route-map: none
  SA-Requests: 
    Input filter: none
  Peer ttl threshold: 0
  SAs learned from this peer: 8
  Input queue size: 0, Output queue size: 0
  MD5 signature protection on MSDP TCP connection: not enabled

Step 6

show ip msdp sa-cache [group-address | source-address | group-name | source-name ] [as-number ]

Use this command to display the (S, G) state learned from MSDP peers.

This is a sample output from the show ip msdp sa-cache command:

Example:

Device# show ip msdp sa-cache

MSDP Source-Active Cache - 8 entries
(10.44.44.5, 239.232.1.0), RP 192.168.4.4, BGP/AS 64512, 00:01:20/00:05:32, Peer 192.168.4.4
(10.44.44.5, 239.232.1.1), RP 192.168.4.4, BGP/AS 64512, 00:01:20/00:05:32, Peer 192.168.4.4
(10.44.44.5, 239.232.1.2), RP 192.168.4.4, BGP/AS 64512, 00:01:19/00:05:32, Peer 192.168.4.4
(10.44.44.5, 239.232.1.3), RP 192.168.4.4, BGP/AS 64512, 00:01:19/00:05:32, Peer 192.168.4.4
(10.44.44.5, 239.232.1.4), RP 192.168.4.4, BGP/AS 64512, 00:01:19/00:05:32, Peer 192.168.4.4
(10.44.44.5, 239.232.1.5), RP 192.168.4.4, BGP/AS 64512, 00:01:19/00:05:32, Peer 192.168.4.4
(10.44.44.5, 239.232.1.6), RP 192.168.4.4, BGP/AS 64512, 00:01:19/00:05:32, Peer 192.168.4.4
(10.44.44.5, 239.232.1.7), RP 192.168.4.4, BGP/AS 64512, 00:01:19/00:05:32, Peer 192.168.4.4

Step 7

show ip msdp summary

Use this command to display MSDP peer status.

This is sample output from the show ip msdp summary command:

Example:

Device# show ip msdp summary

MSDP Peer Status Summary
Peer Address     AS    State    Uptime/  Reset SA    Peer Name
                                Downtime Count Count
192.168.4.4      4     Up       00:08:05 0     8     ?

Clear MSDP connections statistics and SA cache entrie

Perform this optional task to clear MSDP connections, statistics, and SA cache entries.

Procedure

  Command or Action Purpose

Step 1

enable

Example:


Device> enable

Enables privileged EXEC mode.

  • Enter your password if prompted.

Step 2

clear ip msdp peer [peer-address | peer-name ]

Example:


Device# clear ip msdp peer

Clears the TCP connection to the specified MSDP peer and resets all MSDP message counters.

Step 3

clear ip msdp statistics [peer-address | peer-name]

Example:


Device# clear ip msdp statistics

Clears the statistics counters for the specified MSDP peer and resets all MSDP message counters.

Step 4

clear ip msdp sa-cache [group-address ]

Example:


Device# clear ip msdp sa-cache

Clears SA cache entries.

  • If the clear ip msdp sa-cache is specified with the optional group-address argument or source-address argument, all SA cache entries are cleared.

  • Use the optional group-address argument to clear all SA cache entries associated with a specific group.

Enable SNMP monitoring of MSDP

Perform this optional task to enable SNMP monitoring of MSDP.

Before you begin

  • SNMP and MSDP is configured on your devices.

  • In each PIM-SM domain there should be a device that is configured as the MSDP speaker. This device must have SNMP and the MSDP MIB enabled.


Note

  • All MSDP-MIB objects are implemented as read-only.

  • The Requests table is not supported in Cisco’s implementation of the MSDP MIB.

  • The MSDP Established notification is not supported in Cisco’s implementation of the MSDP MIB.

Procedure

  Command or Action Purpose

Step 1

enable

Example:


Device> enable

Enables privileged EXEC mode.

  • Enter your password if prompted.

Step 2

snmp-server enable traps msdp

Example:


Device# snmp-server enable traps msdp

Enables the sending of MSDP notifications for use with SNMP.

Note

 

The snmp-server enable traps msdp command enables both traps and informs.

Step 3

snmp-server host host [traps | informs ] [version {1 | 2c | 3 [auth | priv | noauth ]}] community-string [udp-port port-number ] msdp

Example:


Device# snmp-server host examplehost msdp

Specifies the recipient (host) for MSDP traps or informs.

Step 4

exit

Example:


Device(config)# exit

Exits global configuration mode and returns to privileged EXEC mode.

Configuration examples

This section provides configuration examples of using MSDP to interconnect multiple PIM-SM domains.

Example: Configure an MSDP peer

This example shows how to establish MSDP peering connections between three MSDP peers:

Device A

!
interface Loopback 0
 ip address 10.220.8.1 255.255.255.255
!
ip msdp peer 10.220.16.1 connect-source Loopback0
ip msdp peer 10.220.32.1 connect-source Loopback0
!

Device B

!
interface Loopback 0
 ip address 10.220.16.1 255.255.255.255
!
ip msdp peer 10.220.8.1 connect connect-source Loopback0 
ip msdp peer 10.220.32.1 connect connect-source Loopback0
!

Device C

!
interface Loopback 0
 ip address 10.220.32.1 255.255.255.255
!
ip msdp peer 10.220.8.1 connect 10.220.8.1 connect-source Loopback0
ip msdp peer 10.220.16.1 connect 10.220.16.1 connect-source Loopback0
!

Example: Configure a default MSDP peer

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 ISPs, one that owns Device A and the other that owns Device C. They are not running 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.


Note

Although this illustration and example uses routers in the configuration, any device (router or switch) can be used.
Figure 3. Default MSDP peer scenario

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 file, 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.

This example shows a partial configuration of Device A and Device C in the figure. Each of these ISPs may have more than one customer using default peering, like the customer in the figure. In that case, they may have similar configurations. That is, they will only accept SAs from a default peer if the SA is permitted by the corresponding prefix list.

Device A configuration

ip msdp default-peer 10.1.1.1
ip msdp default-peer 10.1.1.1 prefix-list site-b ge 32
ip prefix-list site-b permit 10.0.0.0/8

Device C configuration

ip msdp default-peer 10.1.1.1 prefix-list site-b ge 32
ip prefix-list site-b permit 10.0.0.0/8

Example: Configure MSDP mesh groups

This example shows how to configure three devices to be fully meshed members of an MSDP mesh group:

Device A configuration

ip msdp peer 10.2.2.2
ip msdp peer 10.3.3.3
ip msdp mesh-group test-mesh-group 10.2.2.2
ip msdp mesh-group test-mesh-group 10.3.3.3

Device B configuration

ip msdp peer 10.1.1.1
ip msdp peer 10.3.3.3
ip msdp mesh-group test-mesh-group 10.1.1.1
ip msdp mesh-group test-mesh-group 10.3.3.3

Device C configuration

ip msdp peer 10.1.1.1
ip msdp peer 10.2.2.2
ip msdp mesh-group test-mesh-group 10.1.1.1
ip msdp mesh-group test-mesh-group 10.2.2.2

Example: Configure MSDP MD5 password authentication

This example shows how to enable MD5 password authentication for TCP connections between two MSDP peers:

Device A

!
ip msdp peer 10.3.32.154
ip msdp password peer 10.3.32.154 0 test
!

Device B

!
ip msdp peer 10.3.32.153
ip msdp password peer 10.3.32.153 0 test
!