Using MSDP to Interconnect Multiple PIM-SIM Domains
Available Languages
Table Of Contents
Using MSDP to Interconnect Multiple
PIM-SM DomainsPrerequisites for Using MSDP to Interconnect Multiple PIM-SM Domains
Information About Using MSDP to Interconnect Multiple PIM-SM Domains
Benefits of Using MSDP to Interconnect Multiple PIM-SM Domains
MSDP MD5 Password Authentication
Benefits of MSDP MD5 Password Authentication
How MSDP MD5 Password Authentication Works
Use of MSDP to Interconnect Multiple PIM-SM Domains
SA Message Origination, Receipt, and Processing
MSDP Keepalive and Hold-Time Intervals
MSDP Connection-Retry Interval
MSDP Compliance with IETF RFC 3618
Benefits of MSDP Compliance with RFC 3618
Use of Outgoing Filter Lists in MSDP
Use of Incoming Filter Lists in MSDP
How to Use MSDP to Interconnect Multiple PIM-SM Domains
Configuring MSDP MD5 Password Authentication Between MSDP Peers
Adjusting the MSDP Keepalive and Hold-Time Intervals
Adjusting the MSDP Connection-Retry Interval
Configuring MSDP Compliance with IETF RFC 3618
Configuring a Default MSDP Peer
Configuring an MSDP Mesh Group
Controlling SA Messages Originated by an RP for Local Sources
Controlling the Forwarding of SA Messages to MSDP Peers Using Outgoing Filter Lists
Controlling the Receipt of SA Messages from MSDP Peers Using Incoming Filter Lists
Using TTL Thresholds to Limit the Multicast Data Sent in SA Messages
Requesting Source Information from MSDP Peers
Controlling the Response to Outgoing SA Request Messages from MSDP Peers Using SA Request Filters
Including a Bordering PIM Dense Mode Region in MSDP
Configuring an Originating Address Other Than the RP Address
Clearing MSDP Connections, Statistics, and SA Cache Entries
Enabling SNMP Monitoring of MSDP
Configuration Examples for Using MSDP to Interconnect Multiple PIM-SM Domains
Example: Configuring an MSDP Peer
Example: Configuring MSDP MD5 Password Authentication
Example: Configuring MSDP Compliance with IETF RFC 3618
Example: Configuring a Default MSDP Peer
Example: Configuring MSDP Mesh Groups
Feature Information for Using MSDP to Interconnect Multiple PIM-SM Domains
Using MSDP to Interconnect Multiple
PIM-SM Domains
First Published: August 21, 2007Last Updated: February 14, 2011This module describes the tasks associated with using Multicast Source Discovery Protocol (MSDP) to interconnect multiple Protocol Independent Multicast Sparse-Mode (PIM-SM) domains. The tasks explain how to configure MSDP peers, mesh groups, and default peers, how to use filters to control and scope MSDP activity, and how to monitor and maintain MSDP. Using MSDP with PIM-SM greatly reduces the complexity of connecting multiple PIM-SM domains.
Finding Feature Information
Your software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the "Feature Information for Using MSDP to Interconnect Multiple PIM-SM Domains" section.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Contents
•
Prerequisites for Using MSDP to Interconnect Multiple PIM-SM Domains
•
•
•
•
Prerequisites for Using MSDP to Interconnect Multiple PIM-SM Domains
Before configuring MSDP, the addresses of all MSDP peers must be known in Border Gateway Protocol (BGP).
Information About Using MSDP to Interconnect Multiple PIM-SM Domains
•
•
•
•
•
•
•
•
•
Benefits of Using MSDP to Interconnect Multiple PIM-SM Domains
•
•
MSDP Peers
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.
MSDP MD5 Password Authentication
The MSDP MD5 password authentication feature is an enhancement to support Message Digest 5 (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.
Benefits of MSDP MD5 Password Authentication
•
•
How MSDP MD5 Password Authentication Works
Developed in accordance with RFC 2385, the MSDP MD5 password authentication feature is used to verify each segment sent on the TCP connection between MSDP peers. The ip msdp password peer command is used to enable 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. MD5 authentication must be configured with the same password on both MSDP peers; otherwise, the connection between them will not be made. Configuring MD5 authentication causes the Cisco IOS software to generate and verify the MD5 digest of every segment sent on the TCP connection.
Use of MSDP to Interconnect Multiple PIM-SM Domains
MSDP is a mechanism to connect multiple PIM-SM domains. The purpose of MSDP is to discover multicast sources in other PIM domains. 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 an common shared tree). When MSDP is configured in a network, RPs exchange source information with RPs in other domains. An RP can join the interdomain source tree for sources that are sending to groups for which it has receivers. The RP can do that because it is the root of the shared tree within its domain, which has branches to all points in the domain where there are active receivers. When a last-hop router 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
When MSDP is enabled, an RP in a PIM-SM domain maintains MSDP peering relationships with MSDP-enabled routers 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, using point-to-point TCP peering means that each peer must be explicitly configured. 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 is also used to announce sources sending to a group. These announcements must originate at the RP of the domain.
Note
Figure 1 illustrates MSDP operating between two MSDP peers. PIM uses MSDP as the standard mechanism to register a source with the RP of a domain.
Figure 1 MSDP Running Between RP Peers
When MSDP is implemented, the following sequence of events occurs:
1.
Note
2.
3.
Note
Note
4.
(*, 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.
Note
MSDP Message Types
There are four basic MSDP message types, each encoded in their own Tag, Length, and Value (TLV) data format.
•
•
•
•
SA Messages
SA messages are used to advertise active sources in a domain. In addition, these SA messages may contain the initial multicast data packet that was sent by the source.
SA messages contain the IP address of the originating RP as well as one or more (S, G) pairs being advertised. In addition, the SA message may contain an encapsulated data packet.
Note
SA Request Messages
SA request messages are used to request a list of active sources for a specific group. These messages are sent to an MSDP SA cache that is maintains a list of active (S, G) pairs in its SA cache. Join latency can be reduced by using SA request messages to request the list of active sources for a group instead of having to wait up to 60 seconds for all active sources in the group to be readvertised by originating RPs.
Note
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 as well as one or more (S, G) pairs of the active sources in the originating RP's domain that are stored in the cache.
Note
Keepalive Messages
Keepalive messages are sent every 60 seconds in order to keep the MSDP session active. If no keepalive messages or SA messages are received for 75 seconds, the MSDP session is reset.
Note
SA Message Limits
The ip msdp sa-limit command is used to limit the overall number of SA messages that a router can accept from specified MSDP peers. When the ip msdp sa-limit command is configured, the router 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 router from denial of service (DoS) attacks. We recommended that you configure SA message limits for all MSDP peerings on the router. 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.
SA Message Origination, Receipt, and Processing
The section describes SA message origination, receipt, and processing in detail.
SA Message Origination
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
When a source is in the local PIM-SM domain, it causes the creation of (S, G) state in the RP. 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 initial multicast packet sent by the source (either encapsulated in the register message or received from a directly connected source) is encapsulated in the initial SA message.
SA Message Receipt
SA messages are only accepted from the MSDP RPF peer that is in the best path back towards 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 (M)BGP routing data as the best approximation of the MSDP topology for the SA RPF check mechanism. An MSDP topology, therefore, must follow the same general topology as the BGP peer topology. Besides a few exceptions (such as default MSDP peers and MSDP peers in MSDP mesh groups), MSDP peers, in general should also be (M)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:
•
•
•
RPF checks are not performed in the following cases:
•
•
•
How the Cisco IOS Software Determines the Rule to Apply to RPF Checks
The Cisco IOS software uses the following logic to determine which RPF rule to apply to RPF checks:
•
–
–
–
Note
Rule 1 of RPF Checking of SA Messages in MSDP
Rule 1 of RPF checking in MSDP is applied when the sending MSDP peer is also an i(M)BGP peer. When Rule 1 is applied, the RPF check proceeds as follows:
1.
2.
Note
Note
3.
Implications of Rule 1 of RPF Checking on MSDP
The MSDP topology must mirror the (M)BGP topology. In general, wherever there is an i(M)BGP peer connection between two routers, an MSDP peer connection should be configured. More specifically, the IP address of the far end MSDP peer connection must be the same as the far end i(M)BGP peer connection. The addresses must be the same because the BGP topology between i(M)BGP peers inside an autonomous system is not described by the AS path. If it were always the case that i(M)BGP peers updated the next-hop address in the path when sending an update to another i(M)BGP peer, then the peer could rely on the next-hop address to describe the i(M)BGP topology (and hence the MSDP topology). However, because the default behavior for i(M)BGP peers is to not update the next-hop address, the peer cannot rely on the next-hop address to describe the (M)BGP topology (MSDP topology). Instead, the i(M)BGP peer uses the address of the i(M)BGP peer that sent the path to describe the i(M)BGP topology
(MSDP topology) inside the autonomous system.
Tip
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 e(M)BGP peer. When Rule 2 is applied, the RPF check proceeds as follows:
1.
2.
Implications of Rule 2 of RPF Checking on MSDP
The MSDP topology must mirror the (M)BGP topology. In general, wherever there is an e(M)BGP peer connection between two routers, an MSDP peer connection should be configured. As opposed to Rule 1, the IP address of the far end MSDP peer connection does not have to be the same as the far end e(M)BGP peer connection.The reason that the addresses do not have to be identical is that BGP topology between two e(M)BGP 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 an (M)BGP peer at all. When Rule 3 is applied, the RPF check proceeds as follows:
1.
2.
Note
3.
SA Message Processing
The following steps are taken by an MSDP peer whenever it processes an SA message:
1.
2.
3.
4.
–
–
Note
MSDP Keepalive and Hold-Time Intervals
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-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 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 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
The ip msdp timer command is used to 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. When the ip msdp timer command is configured, the configured connection-retry interval applies to all MSDP peering sessions on the router.
MSDP Compliance with IETF RFC 3618
When the MSDP Compliance with IETF RFC 3618 feature is configured, the peer-RPF forwarding rules defined in IETF RFC 3618 are applied to MSDP peers. IETF RFC 3618 provides peer-RPF forwarding rules that are used for forwarding SA messages throughout an MSDP-enabled internet. Unlike the RPF check used when forwarding data packets, which compares a packet's source address against the interface upon which the packet was received, the peer-RPF check compares the RP address carried in the SA message against the MSDP peer from which the message was received. Except when MSDP mesh groups are being used, SA messages from an RP address are accepted from only one MSDP peer to avoid looping SA messages.
Note
Benefits of MSDP Compliance with RFC 3618
•
•
Note
•
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, using the ip msdp default-peer command. 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.
Figure 2 illustrates a scenario where default MSDP peers might be used. In the figure, a customer that owns Router B is connected to the Internet through two Internet service providers (ISPs), one that owns Router A and the other that owns Router 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, Router B identifies
Router A as its default MSDP peer. Router B advertises SA messages to both Router A and Router C, but accepts SA messages either from Router A only or Router C only. If Router A is the first default peer in the configuration, it will be used if it is up and running. Only if Router A is not running will Router B accept SA messages from Router C.The ISP will also likely use a prefix list to define which prefixes it will accept from the customer router. 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
Router B advertises SAs to Router A and Router C, but uses only Router A or Router C to accept SA messages. If Router A is first in the configuration, it will be used if it is up and running. Only when Router A is not running will Router B accept SAs from Router 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 router 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.
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 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.
Benefits of MSDP Mesh Groups
•
•
•
Note
SA Origination Filters
Note
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 using the ip msdp redistribute command. By creating SA origination filters, you can control the sources advertised in SA messages as follows:
•
Note
•
•
Note
•
Note
Use of Outgoing Filter Lists in MSDP
By default, an MSDP-enabled router 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 using the ip msdp sa-filter out command.
Note
By creating an outgoing filter list, you can control the SA messages that a router forwards to a peer as follows:
•
•
•
•
Note
Caution
Use of Incoming Filter Lists in MSDP
By default, an MSDP-enabled router receives all SA messages sent to it from its MSDP peers. However, you can control the source information that a router receives from its MSDP peers by creating incoming filter lists using the ip msdp sa-filter in command.
By creating incoming filter lists, you can control the incoming SA messages that a router receives from its peers as follows:
•
•
•
•
•
Note
Caution
TTL Thresholds in MSDP
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-value argument from being encapsulated in SA messages sent to that peer.
SA Request Messages
The ip msdp sa-request command is used to enable a noncaching router to send SA request messages to a specified MSDP peer. You can enter this command multiple times to specify that the router send SA request messages to additional 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
SA Request Filters
By default, a router 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 router will honor from specified peers by enabling an SA request filter using the ip msdp filter-sa-request command. By creating an SA request filter, you can control the outgoing SA requests that the router will honor from MSDP peers as follows:
•
•
MSDP MIB
The MSDP MIB describes managed objects that can be used to remotely monitor MSDP speakers using SNMP. The MSDP MIB module contains four scalar objects and three tables. The tables are the Requests table, the Peer table, and the Source-Active (SA) Cache table. The Cisco implementation supports the Peer table and SA Cache table only. The Requests table contains information used to determine which peer to send SA requests to. However, the MSDP implementation used in Cisco IOS software does not associate sending SA requests to peers with group addresses (or group address masks).
Note
How to Use MSDP to Interconnect Multiple PIM-SM Domains
Perform the following tasks to use MSDP to interconnect multiple PIM-SM domains. The first task is required; all other tasks are optional.
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Configuring an MSDP Peer
Perform this required task to configure an MSDP peer.
Note
Prerequisites
•
•
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Step 1
enable
Example:Router> enable
Enables privileged EXEC mode.
•
Step 2
configure terminal
Example:Router# configure terminal
Enters global configuration mode.
Step 3
ip msdp peer {peer-name | peer-address} [connect-source type number] [remote-as as-number]
Example:Router(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
•
Step 4
ip msdp description {peer-name | peer-address} text
Example:Router(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:Router(config)# end
Exits global configuration mode and returns to privileged EXEC mode.
Shutting Down an MSDP Peer
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
Prerequisites
This task assumes that you are running MSDP and have configured MSDP peers. For more information about configuring MSDP peers, see the "Configuring an MSDP Peer" section.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Configuring MSDP MD5 Password Authentication Between MSDP Peers
Perform this optional task to configure MSDP MD5 password authentication between MSDP peers.
Prerequisites
This task assumes that you are running MSDP and have configured MSDP peers. For more information about configuring MSDP peers, see the "Configuring an MSDP Peer" section.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPSTroubleshooting Tips
If a router has a password configured for an MSDP peer, but the MSDP peer does not, a message such as the following will appear on the console while the routers attempt to establish an MSDP session between them:
%TCP-6-BADAUTH: No MD5 digest from [peer's IP address]:11003 to [local router'sIP address]:179Similarly, if the two routers have different passwords configured, a message such as the following will appear on the console:
%TCP-6-BADAUTH: Invalid MD5 digest from [peer's IP address]:11004 to [local router'sIP address]:179The 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.
Preventing DoS Attacks by Limiting the Number of SA Messages Allowed in the SA Cache from Specified MSDP Peers
Perform this optional (but highly recommended) task to limit the overall number of SA messages that the router can accept from specified MSDP peers. Performing this task protects an MSDP-enabled router from distributed denial-of-service (DoS) attacks.
Note
Prerequisites
This task assumes that you are running MSDP and have configured MSDP peers. For more information about configuring MSDP peers, see the "Configuring an MSDP Peer" section.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
DETAILED STEPSAdjusting 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 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 (by lowering the value for hold-time-interval argument from the default of 75 seconds) can expedite the reconvergence time of MSDP peers in the event that an MSDP peer fails.
Note
Prerequisites
This task assumes that you are running MSDP and have configured MSDP peers. For more information about configuring MSDP peers, see the "Configuring an MSDP Peer" section.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPSAdjusting the MSDP Connection-Retry Interval
Perform this optional task to adjust the interval at which MSDP peers will wait after peering sessions are reset before attempting to reestablish the peering sessions. In network environments where fast recovery of SA messages is required (such as in trading floor network environments), you may want to decrease the connection-retry interval to a time value less than the default value of 30 seconds.
Prerequisites
This task assumes that you are running MSDP and have configured MSDP peers. For more information about configuring MSDP peers, see the "Configuring an MSDP Peer" section.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
Configuring MSDP Compliance with IETF RFC 3618
Perform this optional task to configure MSDP peers to be compliant with Internet Engineering Task Force (IETF) RFC 3618 specifications for MSDP.
Prerequisites
This task assumes that you are running MSDP and have configured MSDP peers. For more information about configuring MSDP peers, see the "Configuring an MSDP Peer" task.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Configuring a Default MSDP Peer
Perform this optional task to specify a default MSDP peer.
Prerequisites
An MSDP default peer must be a previously configured MSDP peer. Before configuring a default MSDP peer, you must first configure an MSDP peer. For more information about configuring MSDP peers, see the "Configuring an MSDP Peer" section.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPSConfiguring an MSDP Mesh Group
Perform this optional task to configure an MSDP mesh group.
Prerequisites
This task assumes that you are running MSDP and have configured MSDP peers. For more information about configuring MSDP peers, see the "Configuring an MSDP Peer" section.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPSControlling 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
Prerequisites
•
•
For more information about configuring extended access lists, see the "Creating an IP access list and Applying It to an Interface" module.
For more information about configuring AS-path access lists, see the "Connecting to a Service Provider Using External BGP" module.
For more information about configuring route maps, see the "Configuring IP Routing Protocol-Independent Features" module.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
Controlling the Forwarding of SA Messages 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
Prerequisites
•
•
For more information about configuring extended access lists, see the "Creating an IP Access List and Applying It to an Interface" module.
For more information about configuring route maps, see the "Configuring IP Routing Protocol-Independent Features" module.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Controlling the Receipt of SA Messages from MSDP Peers Using Incoming Filter Lists
Perform this optional task to control the receipt of incoming SA messages from MSDP peers.
Note
Prerequisites
•
•
For more information about configuring extended access lists, see the "Creating an IP Access List and Applying It to an Interface" module.
For more information about configuring route maps, see the "Configuring IP Routing Protocol-Independent Features" module.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Using TTL Thresholds to Limit the Multicast Data Sent in SA Messages
Perform this optional task to establish a TTL threshold.
Prerequisites
This task assumes that you are running MSDP and have configured MSDP peers. For more information about configuring MSDP peers, see the "Configuring an MSDP Peer" section.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPSRequesting Source Information from MSDP Peers
Perform this optional task to enable a router to request source information from MSDP peers.
Note
Prerequisites
This task assumes that you are running MSDP and have configured MSDP peers. For more information about configuring MSDP peers, see the "Configuring an MSDP Peer" section.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Controlling the Response to Outgoing SA Request Messages from MSDP Peers Using SA Request Filters
Perform this optional task to control the outgoing SA request messages that the router will honor from MSDP peers.
Prerequisites
•
•
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPSIncluding a Bordering PIM Dense Mode Region in MSDP
Perform this optional task to configure a border router to send SA messages for sources active in the dense mode region.
You might have a router that borders a PIM-SM region and a PIM-DM region. By default, sources in the PIM-DM domain are not included in MSDP. You could configure this border router to send SA messages for sources active in the PIM-DM domain. If you do so, it is very important to also configure the ip msdp redistribute command to control what local sources from the PIM-DM domain are advertised. Not configuring this command can result in the (S, G) state remaining long after a source in the PIM-DM domain has stopped sending.
Note
Prerequisites
This task assumes that you are running MSDP and have configured MSDP peers. For more information about configuring MSDP peers, see the "Configuring an MSDP Peer" section.
SUMMARY STEPS1.
2.
3.
4.
DETAILED STEPS
Configuring 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.
The ip msdp originator-id command is used to change the default RP address used in MSDP messages. If you need to change the originator ID for any reason, use the ip msdp originator-id command. For example, you might change the originator ID in one of these cases:
•
•
Prerequisites
This task assumes that you are running MSDP and have configured MSDP peers. For more information about configuring MSDP peers, see the "Configuring an MSDP Peer" section.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
Monitoring MSDP
Perform this optional task to monitor MSDP SA messages, peers, state, and peer status.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
DETAILED STEPS
Step 1
Use this command to enable privileged EXEC mode. Enter your password if prompted.
Router# enableStep 2
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.
The following is sample output from the debug ip msdp command:
Router# debug ip msdpMSDP debugging is onRouter#MSDP: 224.150.44.254: Received 1388-byte message from peerMSDP: 224.150.44.254: SA TLV, len: 1388, ec: 115, RP: 172.31.3.92MSDP: 224.150.44.254: Peer RPF check passed for 172.31.3.92, used EMBGP peerMSDP: 224.150.44.250: Forward 1388-byte SA to peerMSDP: 224.150.44.254: Received 1028-byte message from peerMSDP: 224.150.44.254: SA TLV, len: 1028, ec: 85, RP: 172.31.3.92MSDP: 224.150.44.254: Peer RPF check passed for 172.31.3.92, used EMBGP peerMSDP: 224.150.44.250: Forward 1028-byte SA to peerMSDP: 224.150.44.254: Received 1388-byte message from peerMSDP: 224.150.44.254: SA TLV, len: 1388, ec: 115, RP: 172.31.3.111MSDP: 224.150.44.254: Peer RPF check passed for 172.31.3.111, used EMBGP peerMSDP: 224.150.44.250: Forward 1388-byte SA to peerMSDP: 224.150.44.250: Received 56-byte message from peerMSDP: 224.150.44.250: SA TLV, len: 56, ec: 4, RP: 192.168.76.241MSDP: 224.150.44.250: Peer RPF check passed for 192.168.76.241, used EMBGP peerMSDP: 224.150.44.254: Forward 56-byte SA to peerMSDP: 224.150.44.254: Received 116-byte message from peerMSDP: 224.150.44.254: SA TLV, len: 116, ec: 9, RP: 172.31.3.111MSDP: 224.150.44.254: Peer RPF check passed for 172.31.3.111, used EMBGP peerMSDP: 224.150.44.250: Forward 116-byte SA to peerMSDP: 224.150.44.254: Received 32-byte message from peerMSDP: 224.150.44.254: SA TLV, len: 32, ec: 2, RP: 172.31.3.78MSDP: 224.150.44.254: Peer RPF check passed for 172.31.3.78, used EMBGP peerMSDP: 224.150.44.250: Forward 32-byte SA to peerStep 3
Use this command to debug MSDP peer reset reasons.
Router# debug ip msdp resetsStep 4
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.
The following is sample output from the show ip msdp count command:
Router# show ip msdp countSA State per Peer Counters, <Peer>: <# SA learned>192.168.4.4: 8SA State per ASN Counters, <asn>: <# sources>/<# groups>Total entries: 8?: 8/8Step 5
Use this command to display detailed information about MSDP peers.
Use the optional peer-address or peer-name arguments to display information about a particular peer.
The following is sample output from the show ip msdp peer command:
Router# show ip msdp peer 192.168.4.4MSDP 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/18Output messages discarded: 0Connection and counters cleared 00:08:55 agoSA Filtering:Input (S,G) filter: none, route-map: noneInput RP filter: none, route-map: noneOutput (S,G) filter: none, route-map: noneOutput RP filter: none, route-map: noneSA-Requests:Input filter: nonePeer ttl threshold: 0SAs learned from this peer: 8Input queue size: 0, Output queue size: 0MD5 signature protection on MSDP TCP connection: not enabledStep 6
Use this command to display the (S, G) state learned from MSDP peers.
The following is sample output from the show ip msdp sa-cache command:
Router# show ip msdp sa-cacheMSDP 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.4Step 7
Use this command to display MSDP peer status.
The following is sample output from the show ip msdp summary command:
Router# show ip msdp summaryMSDP Peer Status SummaryPeer Address AS State Uptime/ Reset SA Peer NameDowntime Count Count192.168.4.4 4 Up 00:08:05 0 8 ?
Clearing MSDP Connections, Statistics, and SA Cache Entries
Perform this optional task to clear MSDP connections, statistics, or SA cache entries.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
Enabling SNMP Monitoring of MSDP
Perform this optional task to enable Simple Network Management Protocol (SNMP) monitoring of MSDP.
Note
Prerequisites
•
•
Restrictions
•
•
•
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPSTroubleshooting Tips
You can compare the results of MSDP MIB notifications to the output from the Cisco IOS software by using the show ip msdp summary and show ip msdp peer commands on the appropriate router. You can also compare the results of these commands to the results from SNMP Get operations. You can verify SA cache table entries using the show ip msdp sa-cache command. Additional troubleshooting information, such as the local address of the connection, the local port, and the remote port, can be obtained using the output from the debug ip msdp command.
Configuration Examples for Using MSDP to Interconnect Multiple PIM-SM Domains
This section provides the following MSDP configuration examples:
•
•
•
•
•
Example: Configuring an MSDP Peer
The following example shows how to establish MSDP peering connections between three MSDP peers:
Router A
!interface Loopback 0ip address 10.220.8.1 255.255.255.255!ip msdp peer 10.220.16.1 connect-source Loopback0ip msdp peer 10.220.32.1 connect-source Loopback0!Router B
!interface Loopback 0ip address 10.220.16.1 255.255.255.255!ip msdp peer 10.220.8.1 connect connect-source Loopback0ip msdp peer 10.220.32.1 connect connect-source Loopback0!Router C
!interface Loopback 0ip address 10.220.32.1 255.255.255.255!ip msdp peer 10.220.8.1 connect 10.220.8.1 connect-source Loopback0ip msdp peer 10.220.16.1 connect 10.220.16.1 connect-source Loopback0!Example: Configuring MSDP MD5 Password Authentication
The following example shows how to enable MD5 password authentication for TCP connections between two MSDP peers:
Router A
!ip msdp peer 10.3.32.154ip msdp password peer 10.3.32.154 0 test!Router B
!ip msdp peer 10.3.32.153ip msdp password peer 10.3.32.153 0 test!Example: Configuring MSDP Compliance with IETF RFC 3618
The following example shows how to configure the MSDP peers at 10.10.2.4 and 10.20.1.2 to be compliant with peer-RPF forwarding rules specified in IETF RFC 3618:
ip msdp peer 10.10.2.4ip msdp peer 10.20.1.2ip msdp rpf rfc3618Example: Configuring a Default MSDP Peer
Figure 3 illustrates a scenario where default MSDP peers might be used. In the figure, a customer that owns Router B is connected to the internet through two Internet service providers (ISPs), one that owns Router A and the other that owns Router 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, Router B identifies Router A as its default MSDP peer. Router B advertises SA messages to both Router A and Router C, but accepts SA messages either from Router A only or Router C only. If Router A is the first default peer in the configuration, it will be used if it is up and running. Only if Router A is not running will Router B accept SA messages from Router C.
The ISP will also likely use a prefix list to define which prefixes it will accept from the customer router. 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 3 Default MSDP Peer Scenario
Router B advertises SAs to Router A and Router C, but uses only Router A or Router C to accept SA messages. If Router A is first in the configuration file, it will be used if it is up and running. Only when Router A is not running will Router B accept SAs from Router 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 router 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.
The following example shows a partial configuration of Router A and Router C in Figure 3. Each of these ISPs may have more than one customer like the customer in Figure 3 that use default peering. 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.
Router A Configuration
ip msdp default-peer 10.1.1.1ip msdp default-peer 10.1.1.1 prefix-list site-b ge 32ip prefix-list site-b permit 10.0.0.0/8Router C Configuration
ip msdp default-peer 10.1.1.1 prefix-list site-b ge 32ip prefix-list site-b permit 10.0.0.0/8Example: Configuring MSDP Mesh Groups
The following example shows how to configure three routers to be fully meshed members of an MSDP mesh group:
Router A Configuration
ip msdp peer 10.2.2.2ip msdp peer 10.3.3.3ip msdp mesh-group test-mesh-group 10.2.2.2ip msdp mesh-group test-mesh-group 10.3.3.3Router B Configuration
ip msdp peer 10.1.1.1ip msdp peer 10.3.3.3ip msdp mesh-group test-mesh-group 10.1.1.1ip msdp mesh-group test-mesh-group 10.3.3.3Router C Configuration
ip msdp peer 10.1.1.1ip msdp peer 10.2.2.2ip msdp mesh-group test-mesh-group 10.1.1.1ip msdp mesh-group test-mesh-group 10.2.2.2Additional References
Related Documents
Multicast commands: complete command syntax, command mode, command history, defaults, usage guidelines, and examples
Standard
No new or modified standards are supported, and support for existing standards has not been modified.
—
MIBs
MSDP-MIB
To locate and download MIBs for selected platforms, Cisco software releases, and feature sets, use Cisco MIB Locator found at the following URL:
RFCs
Technical Assistance
Feature Information for Using MSDP to Interconnect Multiple PIM-SM Domains
Table 1 lists the features in this module and provides links to specific configuration information.
Use Cisco Feature Navigator to find information about platform support and software image support. Cisco Feature Navigator enables you to determine which software images support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Note
Table 1 Feature Information for Using MSDP to Interconnect Multiple PIM-SM Domains
MSDP Compliance with IETF RFC 3618
12.0(27)S
12.2(25)S
12.2(27)SBC
12.2(33)SRA
12.2(33)SXH
12.3(4)T
15.0(1)S
Cisco IOS XE 3.1.0SGThe MSDP Compliance with IETF RFC 3618 feature enables you to configure MSDP to comply with the peer-RPF forwarding rules defined in the IETF RFC 3618 specifications. Enabling the MSDP Compliance with IETF RFC 3618 feature prevents SA message loops. Additionally, enabling the MSDP Compliance with IETF RFC 3618 feature eliminates the requirement that BGP RRs run MSDP, enables the use of an IGP for the RPF check, and allows MSDP peerings between routers in nondirectly connected autonomous systems.
The following sections provide information about this feature:
•
•
The following commands were introduced or modified by this feature: ip msdp rpf rfc3618, show ip msdp rpf-peer.
MSDP MD5 Password Authentication
12.2(33)SXH
12.2(33)SRE
12.4(2)T
15.0(1)SThe MSDP MD5 password authentication feature is an enhancement to support 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.
The following sections provide information about this feature:
•
•
The following commands were introduced or modified by this feature: ip msdp password peer, show ip msdp peer.
MSDP MIB
12.1(5)T
12.2(15)T
12.2(27)SBB
12.2(50)SYThe MSDP MIB feature adds support in Cisco IOS software for the MSDP MIB. The MSDP MIB describes objects used for managing MSDP operations using SNMP.
The following section provides information about this feature:
•
The following commands were introduced or modified by this feature: snmp-server enable traps, snmp-server host.
Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1005R)
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.
© 2007-2011 Cisco Systems, Inc. All rights reserved.Related Commands
snmp-server enable traps
To enable all Simple Network Management Protocol (SNMP) notification types that are available on your system, use the snmp-server enable traps command in global configuration mode. To disable all available SNMP notifications, use the no form of this command.
snmp-server enable traps [notification-type] [vrrp]
no snmp-server enable traps [notification-type] [vrrp]
Syntax Description
notification-type
(Optional) Type of notification (trap or inform) to enable or disable. If no type is specified, all notifications available on your device are enabled or disabled (if the no form is used). See the "Notification-Type Keywords" section in the "Usage Guidelines" section for more information about the keywords available.
vrrp
(Optional) Specifies the Virtual Router Redundancy Protocol (VRRP).
Command Default
No notifications controlled by this command are sent.
Command Modes
Global configuration (config)
Command History
Usage Guidelines
For additional notification types, see the Related Commands table for this command.
SNMP notifications can be sent as traps or inform requests. This command enables both traps and inform requests for the specified notification types. To specify whether the notifications should be sent as traps or informs, use the snmp-server host [traps | informs] command.
To configure the router to send these SNMP notifications, you must enter at least one snmp-server enable traps command. If you enter the command with no keywords, all notification types are enabled. If you enter the command with a keyword, only the notification type related to that keyword is enabled. To enable multiple types of notifications, you must issue a separate snmp-server enable traps command for each notification type and notification option.
Most notification types are disabled by default but some cannot be controlled with the snmp-server enable traps command.
The snmp-server enable traps command is used in conjunction with the snmp-server host command. Use the snmp-server host command to specify which host or hosts receive SNMP notifications. To send notifications, you must configure at least one snmp-server host command.
Catalyst 6500 Series Switches
The following MIBs were enhanced or supported in Cisco IOS Release 12.2(33)SXI and later releases on the Catalyst 6500 series switch:
•
•
•
•
•
Notification-Type Keywords
The notification type can be one or more of the following keywords:
Note
•
The severity argument is an integer or string value that identifies the severity of an alarm. Integer values are from 1 to 4. String values are critical, major, minor, and informational. The default is 4 (informational). Severity levels are defined as follows:
–
–
–
–
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
–
–
–
–
•
•
•
•
•
•
•
•
•
–
–
–
–
•
•
•
•
•
•
•
•
•
•
–
–
–
–
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Note
Examples
The following example shows how to enable the router to send all traps to the host specified by the name myhost.cisco.com, using the community string defined as public:
Router(config)# snmp-server enable trapsRouter(config)# snmp-server host myhost.cisco.com publicThe following example shows how to configure an alarm severity threshold of 3:
Router# snmp-server enable traps alarms 3The following example shows how to enable the generation of a DSP operational state notification from from the command-line interface (CLI):
Router(config)# snmp-server enable traps dsp oper-stateThe following example shows how to enable the generation of a DSP operational state notification from a network management device:
setany -v2c 1.4.198.75 test cdspEnableOperStateNotification.0 -i 1cdspEnableOperStateNotification.0=true(1)The following example shows how to send no traps to any host. The Border Gateway Protocol (BGP) traps are enabled for all hosts, but the only traps enabled to be sent to a host are ISDN traps (which are not enabled in this example).
Router(config)# snmp-server enable traps bgpRouter(config)# snmp-server host user1 public isdnThe following example shows how to enable the router to send all inform requests to the host at the address myhost.cisco.com, using the community string defined as public:
Router(config)# snmp-server enable trapsRouter(config)# snmp-server host myhost.cisco.com informs version 2c publicThe following example shows how to send HSRP MIB traps to the host myhost.cisco.com using the community string public:
Router(config)# snmp-server enable traps hsrpRouter(config)# snmp-server host myhost.cisco.com traps version 2c public hsrpThe following example shows that VRRP will be used as the protocol to enable the traps:
Router(config)# snmp-server enable traps vrrpRouter(config)# snmp-server host myhost.cisco.com traps version 2c vrrpThe following example shows how to send IEEE 802.1X MIB traps to the host "myhost.example.com" using the community string defined as public:
Router(config)# snmp-server enable traps dot1xRouter(config)# snmp-server host myhost.example.com traps publicRelated Commands
snmp-server host
To specify the recipient of a Simple Network Management Protocol (SNMP) notification operation, use the snmp-server host command in global configuration mode. To remove the specified host from the configuration, use the no form of this command.
snmp-server host {hostname | ip-address} [vrf vrf-name] [informs | traps] [version {1 | 2c | 3 [auth | noauth | priv]}] community-string [udp-port port] [notification-type]
no snmp-server host {hostname | ip-address} [vrf vrf-name] [informs | traps] [version {1 | 2c | 3 [auth | noauth | priv]}] community-string [udp-port port] [notification-type]
Command Syntax on Cisco ME 3400, ME 3400E, and Catalyst 3750 Metro Switches
snmp-server host ip-address {community-string | {informs | traps} {community-string |
version {1 | 2c | 3 {auth | noauth}} community-string | version {1 | 2c | 3 {auth | noauth}} community-string | vrf vrf-name {informs | traps} {community-string | version {1 | 2c | 3 {auth | noauth}} community-string}} [notification-type]no snmp-server host ip-address {community-string | {informs | traps} {community-string |
version {1 | 2c | 3 {auth | noauth}} community-string | version {1 | 2c | 3 {auth | noauth}} community-string | vrf vrf-name {informs | traps} {community-string | version {1 | 2c | 3 {auth | noauth}} community-string}} [notification-type]Command Syntax on Cisco 7600 Series Router
snmp-server host ip-address {community-string | {informs | traps} {community-string |
version {1 | 2c | 3 {auth | noauth | priv}} community-string | version {1 | 2c | 3 {auth | noauth | priv}} community-string | vrf vrf-name {informs | traps} {community-string | version {1 | 2c | 3 {auth | noauth | priv}} community-string}} [notification-type]no snmp-server host ip-address {community-string | {informs | traps} {community-string |
version {1 | 2c | 3 {auth | noauth | priv}} community-string | version {1 | 2c | 3 {auth | noauth | priv}} community-string | vrf vrf-name {informs | traps} {community-string | version {1 | 2c | 3 {auth | noauth | priv}} community-string}} [notification-type]Syntax Description
hostname
Name of the host. The SNMP notification host is typically a network management station (NMS) or SNMP manager. This host is the recipient of the SNMP traps or informs.
ip-address
IP address or IPv6 address of the SNMP notification host.
vrf
(Optional) Specifies that a Virtual Private Network (VPN) routing and forwarding (VRF) instance should be used to send SNMP notifications.
vrf-name
(Optional) VPN VRF instance used to send SNMP notifications.
•
informs
(Optional) Specifies that notifications should be sent as informs.
•
traps
(Optional) Specifies that notifications should be sent as traps. This is the default.
•
version
(Optional) Specifies the version of the SNMP that is used to send the traps or informs. The default is 1.
If you use the version keyword, one of the following keywords must be specified:
•
•
•
One of the following three optional security level keywords can follow the 3 keyword:
–
–
–
community-string
Password-like community string sent with the notification operation.
Note
Note
udp-port
(Optional) Specifies that SNMP traps or informs are to be sent to an NMS host.
•
port
(Optional) User Datagram Protocol (UDP) port number of the NMS host. The default is 162.
•
notification-type
(Optional) Type of notification to be sent to the host. If no type is specified, all available notifications are sent. See the "Notification-Type Keywords" section in the "Usage Guidelines" section for more information about the keywords available.
Command Default
This command is disabled by default. A recipient is not specified to receive notifications.
Command Modes
Global configuration (config)
Command History
10.0
This command was introduced.
12.0(3)T
•
•
•
12.1(3)T
The calltracker notification-type keyword was added for the Cisco AS5300 and AS5800 platforms.
12.2(2)T
•
•
•
12.2(4)T
•
•
12.2(8)T
•
•
12.2(13)T
•
•
12.3(2)T
•
•
12.3(4)T
•
•
•
12.3(8)T
The iplocalpool notification-type keyword was added for the Cisco 7200 and 7301 series routers.
12.3(11)T
The vrrp keyword was added.
12.3(14)T
•
•
12.4(20)T
The license notification-type keyword was added.
15.0(1)M
•
•
12.0(17)ST
The mpls-traffic-eng notification-type keyword was added.
12.0(21)ST
The mpls-ldp notification-type keyword was added.
12.0(22)S
•
•
12.0(23)S
The l2tun-session notification-type keyword was added.
12.0(26)S
The memory notification-type keyword was added.
12.0(27)S
•
•
12.0(31)S
The l2tun-pseudowire-status notification-type keyword was added.
12.2(18)S
This command was integrated into Cisco IOS Release 12.2(18)S.
12.2(25)S
•
•
12.2(28)SB
This command was integrated into Cisco IOS Release 12.2(28)SB.
12.2(33)SRA
This command was integrated into Cisco IOS Release 12.2(33)SRA.
12.2(31)SB2
The cef notification-type keyword was added.
12.2(33)SXH
This command was integrated into Cisco IOS Release 12.2(33)SXH.
12.2(33)SB
This command was integrated into Cisco IOS Release 12.2(33)SB.
12.2(33)SXI5
•
•
12.2(54)SE
This command was modified. See the "Command Syntax on Cisco ME 3400, ME 3400E, and Catalyst 3750 Metro Switches" section for the command syntax for these switches.
12.2(50)SY
This command integrated into Cisco IOS Release 12.2(50)SY.
15.0(1)S
This command was modified. The flowmon notification-type keyword was added.
Cisco IOS XE Release 2.1
This command was integrated into Cisco IOS XE Release 2.1.
Usage Guidelines
If you enter this command with no optional keywords, the default is to send all notification-type traps to the host. No informs will be sent to the host.
The no snmp-server host command with no keywords disables traps, but not informs, to the host. To disable informs, use the no snmp-server host informs command.
Note
SNMP notifications can be sent as traps or inform requests. Traps are unreliable because the receiver does not send acknowledgments when it receives traps. The sender cannot determine if the traps were received. However, an SNMP entity that receives an inform request acknowledges the message with an SNMP response protocol data unit (PDU). If the sender never receives the response, the inform request can be sent again. Thus, informs are more likely than traps to reach their intended destination.
Compared to traps, informs consume more resources in the agent and in the network. Unlike a trap, which is discarded as soon as it is sent, an inform request must be held in memory until a response is received or the request times out. Also, traps are sent only once; an inform may be tried several times. The retries increase traffic and contribute to a higher overhead on the network.
If you do not enter an snmp-server host command, no notifications are sent. To configure the router to send SNMP notifications, you must enter at least one snmp-server host command. If you enter the command with no optional keywords, all trap types are enabled for the host.
To enable multiple hosts, you must issue a separate snmp-server host command for each host. You can specify multiple notification types in the command for each host.
When multiple snmp-server host commands are given for the same host and kind of notification (trap or inform), each succeeding command overwrites the previous command. Only the last snmp-server host command will be in effect. For example, if you enter an snmp-server host inform command for a host and then enter another snmp-server host inform command for the same host, the second command will replace the first.
The snmp-server host command is used in conjunction with the snmp-server enable command. Use the snmp-server enable command to specify which SNMP notifications are sent globally. For a host to receive most notifications, at least one snmp-server enable command and the snmp-server host command for that host must be enabled.
Some notification types cannot be controlled with the snmp-server enable command. Some notification types are always enabled, and others are enabled by a different command. For example, the linkUpDown notifications are controlled by the snmp trap link-status command. These notification types do not require an snmp-server enable command.
The availability of a notification-type options depends on the router type and the Cisco IOS software features supported on the router. For example, the envmon notification type is available only if the environmental monitor is part of the system. To see what notification types are available on your system, use the command help ? at the end of the snmp-server host command.
The vrf keyword allows you to specify the notifications being sent to a specified IP address over a specific virtual routing and forwarding (VRF) VPN. The VRF defines a VPN membership of a user so that data is stored using the VPN.
In the case of the NMS sending the query having a correct SNMP community but that does not have a read or a write view, the SNMP agent returns the following error values:
•
•
Notification-Type Keywords
The notification type can be one or more of the following keywords:
Note
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Note
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
SNMP-Related Notification-Type Keywords
The notification-type keywords used in the snmp-server host command do not always match the keywords used in the corresponding snmp-server enable traps command. For example, the notification keyword applicable to Multiprotocol Label Switching Protocol (MPLS) traffic engineering tunnels is specified as mpls-traffic-eng (containing two hyphens and no embedded spaces). The corresponding parameter in the snmp-server enable traps command is specified as mpls traffic-eng (containing an embedded space and a hyphen).
This syntax difference is necessary to ensure that the CLI interprets the notification-type keyword of the snmp-server host command as a unified, single-word construct, which preserves the capability of the snmp-server host command to accept multiple notification-type keywords in the command line. The snmp-server enable traps commands, however, often use two-word constructs to provide hierarchical configuration options and to maintain consistency with the command syntax of related commands. Table 2 maps some examples of snmp-server enable traps commands to the keywords used in the snmp-server host command.
Table 2 SNMP-server enable traps Commands and Corresponding Notification Keywords
snmp-server enable traps l2tun session
l2tun-session
snmp-server enable traps mpls ldp
mpls-ldp
snmp-server enable traps mpls traffic-eng1
mpls-traffic-eng
snmp-server enable traps mpls vpn
mpls-vpn
1 See the Cisco IOS Multiprotocol Label Switching Command Reference for documentation of this command.
Examples
If you want to configure a unique SNMP community string for traps but prevent SNMP polling access with this string, the configuration should include an access list. The following example shows how to name a community string comaccess and number an access list 10:
Router(config)# snmp-server community comaccess ro 10Router(config)# snmp-server host 192.20.2.160 comaccessRouter(config)# access-list 10 deny any
Note
The following example shows how to send RFC 1157 SNMP traps to a specified host named myhost.cisco.com. Other traps are enabled, but only SNMP traps are sent because only snmp is specified in the snmp-server host command. The community string is defined as comaccess.
Router(config)# snmp-server enable trapsRouter(config)# snmp-server host myhost.cisco.com comaccess snmpThe following example shows how to send the SNMP and Cisco environmental monitor enterprise-specific traps to address 192.30.2.160 using the community string public:
Router(config)# snmp-server enable traps snmpRouter(config)# snmp-server enable traps envmonRouter(config)# snmp-server host 192.30.2.160 public snmp envmonThe following example shows how to enable the router to send all traps to the host myhost.cisco.com using the community string public:
Router(config)# snmp-server enable trapsRouter(config)# snmp-server host myhost.cisco.com publicThe following example will not send traps to any host. The BGP traps are enabled for all hosts, but only the ISDN traps are enabled to be sent to a host. The community string is defined as public.
Router(config)# snmp-server enable traps bgpRouter(config)# snmp-server host myhost.cisco.com public isdnThe following example shows how to enable the router to send all inform requests to the host myhost.cisco.com using the community string public:
Router(config)# snmp-server enable trapsRouter(config)# snmp-server host myhost.cisco.com informs version 2c publicThe following example shows how to send HSRP MIB informs to the host specified by the name myhost.cisco.com. The community string is defined as public.
Router(config)# snmp-server enable traps hsrpRouter(config)# snmp-server host myhost.cisco.com informs version 2c public hsrpThe following example shows how to send all SNMP notifications to example.com over the VRF named trap-vrf using the community string public:
Router(config)# snmp-server host example.com vrf trap-vrf publicThe following example shows how to configure an IPv6 SNMP notification server with the IPv6 address 2001:0DB8:0000:ABCD:1 using the community string public:
Router(config)# snmp-server host 2001:0DB8:0000:ABCD:1 version 2c public udp-port 2012The following example shows how to specify VRRP as the protocol using the community string public:
Router(config)# snmp-server enable traps vrrpRouter(config)# snmp-server host myhost.cisco.com traps version 2c public vrrpThe following example shows how to send all Cisco Express Forwarding informs to the notification receiver with the IP address 192.40.3.130 using the community string public:
Router(config)# snmp-server enable traps cefRouter(config)# snmp-server host 192.40.3.130 informs version 2c public cefThe following example shows how to enable all NHRP traps, and how to send all NHRP traps to the notification receiver with the IP address 192.40.3.130 using the community string public:
Router(config)# snmp-server enable traps nhrpRouter(config)# snmp-server host 192.40.3.130 traps version 2c public nhrpRelated Commands
FeedbackContact Cisco
- Open a Support Case
- (Requires a Cisco Service Contract)
This Document Applies to These Products
- Collaboration Endpoints - Retired Products
- Conferencing - Retired Products
- Contact Center - Retired Products
- Optical Networking - Retired Products
- Routers - Retired Products
- Security - Retired Products
- Servers - Unified Computing (UCS) Retired Products
- Storage Networking Retired Products
- Switches - Retired Products
- Video - Retired Products
- Wireless - Retired Products