• Allows a rendezvous point (RP) to dynamically discover active sources outside of its domain.

• Introduces a more manageable approach for building multicast distribution trees between multiple domains.

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

The section describes SA message origination, receipt, and processing in detail.

Like BGP, MSDP establishes neighbor relationships with other MSDP peers. MSDP peers connect using TCP port 639. The lower IP address peer takes the active role of opening the TCP connection. The higher IP address peer waits in LISTEN state for the other to make the connection. MSDP peers send keepalive messages every 60 seconds. The arrival of data performs the same function as the keepalive message and keeps the session from timing out. If no keepalive messages or data is received for 75 seconds, the TCP connection is reset.

The ip msdp sa-limit command is used to limit the overall number of SA messages that a device can accept from specified MSDP peers. When the ip msdp sa-limit command is configured, the device maintains a per-peer count of SA messages stored in the SA cache and will ignore new messages from a peer if the configured SA message limit for that peer has been reached.

The ip msdp sa-limit command was introduced as a means to protect an MSDP-enabled device from denial of service (DoS) attacks. We recommended that you configure SA message limits for all MSDP peerings on the device. An appropriately low SA limit should be configured on peerings with a stub MSDP region (for example, a peer that may have some further downstream peers but that will not act as a transit for SA messages across the rest of the Internet). A high SA limit should be configured for all MSDP peerings that act as transits for SA messages across the Internet.

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 of the connection sends a keepalive message and sets a keepalive 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-intervalargument 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-intervalargument when the peer comes up. The keepalive timer is reset to the value of the keepalive-interval argument whenever an MSDP keepalive message is sent to the peer and reset when the timer expires. The keepalive timer is deleted when an MSDP peering session is closed. By default, the keepalive timer is set to 60 seconds.

Note	The value specified for the keepalive-interval argument must be less than the value specified for the holdtime-intervalargument and must be at least one second.

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-intervalargument 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.

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.

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.

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

An MSDP mesh group is a group of MSDP speakers that have fully meshed MSDP connectivity between one another. In other words, each of the MSDP peers in the group must have an MSDP peering relationship (MSDP connection) to every other MSDP peer in the group. When an MSDP mesh group is configured between a group of MSDP peers, SA message flooding is reduced. Because when an MSDP peer in the group receives an SA message from another MSDP peer in the group, it assumes that this SA message was sent to all the other MSDP 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.

By default, an RP that is configured to run MSDP will originate SA messages for all local sources for which it is the RP. Local sources that register with an RP, therefore, will be advertised in SA messages, which in some cases is not desirable. For example, if sources inside a PIM-SM domain are using private addresses (for example, network 10.0.0.0/8), you should configure an SA origination filter to restrict those addresses from being advertised to other MSDP peers across the Internet.

To control what sources are advertised in SA messages, you can configure SA origination filters on an RP. By creating SA origination filters, you can control the sources advertised in SA messages as follows:

• You can configure an RP to prevent the device from advertising local sources in SA messages. The device will still forward SA messages from other MSDP peers in the normal fashion; it will just not originate any SA messages for local sources.

• You can configure the device to only originate SA messages for local sources sending to specific groups that match (S, G) pairs defined in the extended access list. All other local sources will not be advertised in SA messages.

• You can configure the device to only originate SA messages for local sources sending to specific groups that the match AS paths defined in an AS-path access list. All other local sources will not be advertised in SA messages.

• You can configure the device to only originate SA messages for local sources that match the criteria defined in the route map. All other local sources will not be advertised in SA messages.

• You configure an SA origination filter that includes an extended access list, an AS-path access list, and route map, or a combination thereof. In this case, all conditions must be true before any local sources are advertised in SA messages.

By default, an MSDP-enabled device forwards all SA messages it receives to all of its MSDP peers. However, you can prevent SA messages from being forwarded to MSDP peers by creating outgoing filter lists. Outgoing filter lists apply to all SA messages, whether locally originated or received from another MSDP peer, whereas SA origination filters apply only to locally originated SA messages. For more information about enabling a filter for MSDP SA messages originated by the local device, see the Controlling SA Messages Originated by an RP for Local Sources section.

By creating an outgoing filter list, you can control the SA messages that a device forwards to a peer as follows:

• You can filter all outgoing SA messages forwarded to a specified MSDP peer by configuring the device to stop forwarding its SA messages to the MSDP peer.

• You can filter a subset of outgoing SA messages forwarded to a specified MSDP peer based on (S, G) pairs defined in an extended access list by configuring the device to only forward SA messages to the MSDP peer that match the (S, G) pairs permitted in an extended access list. The forwarding of all other SA messages to the MSDP peer will be stopped.

• You can filter a subset of outgoing SA messages forwarded to a specified MSDP peer based on match criteria defined in a route map by configuring the device to only forward SA messages that match the criteria defined in the route map. The forwarding of all other SA messages to the MSDP peer will be stopped.

• You can filter a subset of outgoing SA messages from a specified peer based on the announcing RP address contained in the SA message by configuring the device to filter outgoing SA messages based on their origin, even after an SA message has been transmitted across one or more MSDP peers. The forwarding of all other SA messages to the MSDP peer will be stopped.

• You can configure an outgoing filter list that includes an extended access list, a route map, and either an RP access list or an RP route map. In this case, all conditions must be true for the MSDP peer to forward the outgoing SA message.

Caution

Arbitrary filtering of SA messages can result in downstream MSDP peers being starved of SA messages for legitimate active sources. Care, therefore, should be taken when using these sorts of filters. Normally, outgoing filter lists are used only to reject undesirable sources, such as sources using private addresses.

By default, an MSDP-enabled device receives all SA messages sent to it from its MSDP peers. However, you can control the source information that a device receives from its MSDP peers by creating incoming filter lists.

By creating incoming filter lists, you can control the incoming SA messages that a device receives from its peers as follows:

• You can filter all incoming SA messages from a specified MSDP peer by configuring the device to ignore all SA messages sent to it from the specified MSDP peer.

• You can filter a subset of incoming SA messages from a specified peer based on (S, G) pairs defined in an extended access list by configuring the device to only receive SA messages from the MSDP peer that match the (S, G) pairs defined in the extended access list. All other incoming SA messages from the MSDP peer will be ignored.

• You can filter a subset of incoming SA request messages from a specified peer based on match criteria defined in a route map by configuring the device to only receive SA messages that match the criteria defined in the route map. All other incoming SA messages from the MSDP peer will be ignored.

• You can filter a subset of incoming SA messages from a specified peer based on both (S, G) pairs defined in an extended access list and on match criteria defined in a route map by configuring the device to only receive incoming SA messages that both match the (S, G) pairs defined in the extended access list and match the criteria defined in the route map. All other incoming SA messages from the MSDP peer will be ignored.

• You can filter a subset of incoming SA messages from a specified peer based on the announcing RP address contained in the SA message by configuring the device to filter incoming SA messages based on their origin, even after the SA message may have already been transmitted across one or more MSDP peers.

• You can configure an incoming filter list that includes an extended access list, a route map, and either an RP access list or an RP route map. In this case, all conditions must be true for the MSDP peer to receive the incoming SA message.

Caution

Arbitrary filtering of SA messages can result in downstream MSDP peers being starved of SA messages for legitimate active sources. Care, therefore, should be taken when using these sorts of filters. Normally, incoming filter lists are used only to reject undesirable sources, such as sources using private addresses.

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. Because the multicast packet is encapsulated inside of the unicast SA message (whose TTL is 255), its TTL is not decremented as the SA message travels to the MSDP peer. Furthermore, the total number of hops that the SA message traverses can be drastically different than a normal multicast packet because multicast and unicast traffic may follow completely different paths to the MSDP peer and hence 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-valueargument from being encapsulated in SA messages sent to that peer.

You can configure a noncaching device to send SA request messages to one or more specified MSDP peers.

If an noncaching RP has an MSDP peer that is caching SAs, you can reduce the join latency for a noncaching peer by enabling the noncaching peer to send SA request messages. 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 back to the requestor.

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

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 as follows:

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

• You can 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.

Note	By enabling an MSDP peer, you implicitly enable MSDP.

1.    enable


2.    configure terminal


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


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


5.    end

Device> enable

Device# configure terminal

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

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

Device(config)# end

Perform this optional task to 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 might 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).

1.    enable


2.    configure terminal


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


4.    Repeat Step 3 to shut down additional MSDP peers.

5.    end

> enable

# configure terminal

(config)# ip msdp shutdown 192.168.1.3

(config)# end

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.

1.    enable


2.    configure terminal


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


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

5.    exit


6.    show ip msdp count [as-number]


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


8.    show ip msdp summary

Device> enable

Device# configure terminal

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

Device(config)# exit

Device# show ip msdp count

Device# show ip msdp peer

Device# show ip msdp summary

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 as long as 75 seconds for an MSDP peer to detect that a peering session with another MSDP peer has gone down. In network environments with redundant MSDP peers, decreasing the hold-time interval can expedite the reconvergence time of MSDP peers in the event that 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.

1.    enable


2.    configure terminal


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


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

5.    exit

Device> enable

Device# configure terminal

Device(config)# ip msdp keepalive 10.1.1.3 40 55

Device(config)# exit

1.    enable


2.    configure terminal


3.    ip msdp timer connection-retry-interval


4.    exit

Device> enable

Device# configure terminal

Device# ip msdp timer 45

Device(config)# exit

1.    enable


2.    configure terminal


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


4.    exit

Device> enable

Device# configure terminal

Device(config)# ip msdp default-peer 192.168.1.3

Device(config)# exit

Perform this optional task to configure an MSDP mesh group.

Note	You can configure multiple mesh groups per device.

1.    enable


2.    configure terminal


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


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

5.    exit

> enable

# configure terminal

(config)# ip msdp mesh-group peermesh

(config)# exit

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.

1.    enable


2.    configure terminal


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


4.    exit

Device> enable

Device# configure terminal

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

Device(config)# exit

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.

1.    enable


2.    configure terminal


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]


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

5.    exit

Device> enable

Device# configure terminal

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

Device(config)# exit

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.

1.    enable


2.    configure terminal


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]


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

5.    exit

Device> enable

Device# configure terminal

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

Device(config)# exit

1.    enable


2.    configure terminal


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


4.    exit

Device> enable

Device# configure terminal

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

Device(config)# exit

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.

1.    enable


2.    configure terminal


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


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

5.    exit

Device> enable

Device# configure terminal

Device(config)# ip msdp sa-request 192.168.10.1

Device(config)# exit

1.    enable


2.    configure terminal


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


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

5.    exit

Device> enable

Device# configure terminal

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

Device(config)# exit

1.    enable


2.    configure terminal


3.    ip msdp border sa-address type number


4.    exit

Device> enable

Device# configure terminal

Device(config)# ip msdp border sa-address gigabitethernet0/0/0

Device(config)# exit

1.    enable


2.    configure terminal


3.    ip msdp originator-id type number


4.    exit

Device> enable

Device# configure terminal

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

Device(config)# exit

1.    enable


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


3.    debug ip msdp resets


4.    show ip msdp count [as-number]


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


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


7.    show ip msdp summary

Device# enable

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

Device# debug ip msdp resets

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

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

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

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     ?

1.    enable


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


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


4.    clear ip msdp sa-cache [group-address]

Device> enable

Device# clear ip msdp peer 

Device# clear ip msdp statistics

Device# clear ip msdp sa-cache

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 msdpEstablished notification is not supported in Cisco’s implementation of the MSDP MIB.

1.    enable


2.    snmp-server enable traps msdp


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


4.    exit

Device> enable

Device# snmp-server enable traps msdp

Device# snmp-server host examplehost msdp

Device(config)# exit