 Feedback
|
Table Of Contents
MPLS Label Distribution Protocol MIB Version 8 Upgrade
Prerequisites for MPLS LDP MIB Version 8 Upgrade
Restrictions for MPLS LDP MIB Version 8 Upgrade
Information About MPLS LDP MIB Version 8 Upgrade
Feature Design of MPLS LDP MIB Version 8 Upgrade
Enhancements in Version 8 of the MPLS LDP MIB
Benefits of MPLS LDP MIB Version 8 Upgrade
Description of MPLS LDP MIB Elements for MPLS LDP MIB Version 8 Upgrade
Events Generating MPLS LDP MIB Notifications in MPLS LDP MIB Version 8 Upgrade
MIB Tables in MPLS LDP MIB Version 8 Upgrade
VPN Contexts in MPLS LDP MIB Version 8 Upgrade
VPN Aware LDP MIB Notifications
How to Configure MPLS LDP MIB Version 8 Upgrade
Enabling Cisco Express Forwarding
Configuring a VPN Aware LDP MIB
Configuring SNMP Support for a VPN
Configuring an SNMP Context for a VPN
Associating an SNMP VPN Context with SNMPv1 or SNMPv2
Verifying MPLS LDP MIB Version 8 Upgrade
Configuration Examples for MPLS LDP MIB Version 8 Upgrade
MPLS LDP MIB Version 8 Upgrade Examples
Configuring a VPN Aware SNMP Context for SNMPv1 or SNMPv2: Example
snmp-server enable traps (MPLS)
snmp-server trap authentication vrf
MPLS Label Distribution Protocol MIB Version 8 Upgrade
First Published: November 13, 2000Last Updated: June 29, 2007The MPLS Label Distribution Protocol (LDP) MIB Version 8 Upgrade feature enhances the LDP MIB to support the Internet Engineering Task Force (IETF) draft Version 8.
History for MLPS Label Distribution Protocol MIB Version 8 Update Feature
Finding Support Information for Platforms and Cisco IOS and Catalyst OS Software Images
Use Cisco Feature Navigator to find information about platform support and Cisco IOS and Catalyst OS 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 MPLS LDP MIB Version 8 Upgrade
•
•
•
•
•
•
•
•
Prerequisites for MPLS LDP MIB Version 8 Upgrade
•
•
•
Restrictions for MPLS LDP MIB Version 8 Upgrade
This implementation of the MPLS LDP MIB is limited to read-only (RO) permission for MIB objects, except for MIB object mplsLdpSessionUpDownTrapEnable, which has been extended to be writable by the SNMP agent.
Setting this object to a value of true enables both the mplsLdpSessionUp and mplsLdpSessionDown notifications on the LSR; conversely, setting this object to a value of false disables both of these notifications.
For a description of notification events, see the "Events Generating MPLS LDP MIB Notifications in MPLS LDP MIB Version 8 Upgrade" section.
Most MPLS LDP MIB objects are set up automatically during the LDP peer discovery (hello) process and the subsequent negotiation of parameters and establishment of LDP sessions between the LDP peers.
The following tables are not implemented in this feature:
•
•
•
•
•
•
•
Information About MPLS LDP MIB Version 8 Upgrade
To configure MPLS LDP MIB Version 8 Upgrade, you need to understand the following concepts:
•
•
•
Feature Design of MPLS LDP MIB Version 8 Upgrade
MPLS is a packet forwarding technology that uses a short, fixed-length value called a label in packets to specify the next hop for packet transport through an MPLS network by means of label switch routers (LSRs).
A fundamental MPLS principle is that LSRs in an MPLS network must agree on the definition of the labels being used for packet forwarding operations. Label agreement is achieved in an MPLS network by means of procedures defined in the LDP.
LDP operations begin with a discovery (hello) process, during which an LDP entity (a local LSR) finds a cooperating LDP peer in the network, and the two negotiate basic operating procedures. The recognition and identification of a peer by means of this discovery process results in a hello adjacency, which represents the context within which label binding information is exchanged between the local LSR and its LDP peer. LDP then creates an active LDP session between the two LSRs to effect the exchange of label binding information. When this process is carried to completion with respect to all of the LSRs in an MPLS network, the result is a label-switched path (LSP), which constitutes an end-to-end packet transmission pathway between the communicating network devices.
By means of LDP, LSRs can collect, distribute, and release label binding information to other LSRs in an MPLS network, thereby enabling the hop-by-hop forwarding of packets in the network along normally routed paths.
The MPLS LDP MIB has been implemented to enable standard, SNMP-based network management of the label switching features in Cisco IOS software. Providing this capability requires SNMP agent code to execute on a designated network management station (NMS) in the network. The NMS serves as the medium for user interaction with the network management objects in the MPLS LDP MIB.
The SNMP agent code has a layered structure that is compatible with Cisco IOS software and presents a network administrative and management interface to the objects in the MPLS LDP MIB and, thence, to the rich set of label switching capabilities supported by Cisco IOS software.
By means of an SNMP agent, you can access MPLS LDP MIB objects using standard SNMP GET operations, and you can use those objects to accomplish a variety of network management tasks. All the objects in the MPLS LDP MIB follow the conventions defined in the IETF draft MIB entitled draft-ietf-mpls-ldp-mib-08.txt, which defines network management objects in a structured and standardized manner. This draft MIB is evolving and is soon expected to be a standard. Accordingly, the MPLS LDP MIB will be implemented in such a way that it tracks the evolution of this IETF document.
However, slight differences exist between the IETF draft MIB and the implementation of equivalent Cisco IOS functions. As a result, some minor translations between the MPLS LDP MIB objects and the internal Cisco IOS data structures are needed. Such translations are accomplished by the SNMP agent, which runs in the background on the NMS workstation as a low-priority process.
The extensive Cisco IOS label switching capabilities provide an integrated approach to managing the large volumes of traffic carried by WANs. These capabilities are integrated into the Layer 3 network services, thus optimizing the routing of high-volume traffic through Internet service provider backbones while, at the same time, ensuring the resistance of the network to link or node failures.
Cisco IOS Release 12.0(11)ST and later releases support the following MPLS LDP MIB-related functions:
•
•
•
•
•
The structure of the MPLS LDP MIB conforms to Abstract Syntax Notation One (ASN.1), so the MIB forms a highly structured and idealized database of network management objects.
Using any standard SNMP application, you can retrieve and display information from the MPLS LDP MIB by means of standard SNMP GET and GETNEXT operations.
Note
ciscoExperimental
1.3.6.1.4.1.9.10
mplsLdpMIB
1.3.6.1.4.1.9.10.65
If the MPLS LDP MIB is assigned an IANA Experimental OID number, Cisco will replace all objects in the MIB under the ciscoExperimental OID and reposition the objects under the IANA Experimental OID.
Enhancements in Version 8 of the MPLS LDP MIB
Version 8 of the MPLS LDP MIB contains the following enhancements:
•
•
•
•
Benefits of MPLS LDP MIB Version 8 Upgrade
•
•
•
–
–
–
–
–
–
•
•
•
–
–
–
–
•
–
–
–
–
–
–
Description of MPLS LDP MIB Elements for MPLS LDP MIB Version 8 Upgrade
LDP operations related to an MPLS LDP MIB involve the following functional elements:
•
•
•
•
These MPLS LDP MIB elements are briefly described under separate headings below.
In effect, the MPLS LDP MIB provides a network management database that supports real-time access to the various MIB objects in the database. This database reflects the current state of MPLS LDP operations in the network. You can access this network management information database by means of standard SNMP commands issued from an NMS in the MPLS LDP operating environment.
The MPLS LDP MIB supports the following network management and administrative activities:
•
•
•
•
•
LDP Entities
An LDP entity is uniquely identified by an LDP identifier that consists of the mplsLdpEntityLdpId and the mplsLdpEntityIndex (see Figure 1).
•
•
The mplsldpEntityProtocolVersion is a sample object from the mplsLdpEntityTable.
Figure 1 shows the following indexing:
•
•
•
The mplsLdpEntityLdpId or the LDP ID consists of the LSR ID and the label space ID.
•
Figure 1 Sample Indexing for an LDP Entity
An LDP entity represents a label space that has the potential for a session with an LDP peer. An LDP entity is set up when a hello adjacency receives a hello message from an LDP peer.
In Figure 2, Router A has potential sessions with two remote peers, Routers B and C. The mplsLdpEntityLdpId is 10.10.10.10.0.0, and the IP address of the peer active hello adjacency (mplsLdpEntityIndex) is 3232235777, which is the 32-bit representation of the IP address 192.168.1.1 for Router B.
Figure 2
LDP Entity
LDP Sessions and Peers
LDP sessions exist between local entities and remote peers for the purpose of distributing label spaces. There is always a one-to-one correspondence between an LDP peer and an LDP session. A single LDP session is an LDP instance that communicates across one or more network links with a single LDP peer.
LDP supports the following types of sessions:
•
•
When a session is established between two peers, entries are created in the mplsLdpPeerTable and the mplsLdpSessionTable because they have the same indexing.
In Figure 3, Router A has two remote peers, Routers B and C. Router A has a single platform-wide session that consists of two serial interfaces with Router B and another platform-wide session with Router C. Router A also has two interface-specific sessions with Router B.
Figure 3
LDP Sessions
Figure 4 shows entries that correspond to the mplsLdpPeerTable and the mplsLdpSessionTable in Figure 3.
In Figure 4, mplsLdpSesState is a sample object from the mplsLdpSessionTable on Router A. There are four mplsLdpSesState sample objects shown (top to bottom). The first object represents a platform-wide session associated with two serial interfaces. The next two objects represent interface-specific sessions for the LC-ATM interfaces on Routers A and B. These interface-specific sessions have nonzero peer label space IDs. The last object represents a platform-wide session for the next peer, Router C.
The indexing is based on the entries in the mplsLdpEntityTable. It begins with the indexes of the mplsLdpEntityTable and adds the following:
•
The peer LDP ID consists of the peer LSR ID (four octets) and the peer label space ID (two octets).
•
•
The peer label space ID identifies a specific peer label space available within the LSR.
Figure 4
Sample Indexing for an LDP Session
LDP Hello Adjacencies
An LDP hello adjacency is a network link between a router and its peers. An LDP hello adjacency enables two adjacent peers to exchange label binding information.
An LDP hello adjacency exists for each link on which LDP runs. Multiple LDP hello adjacencies exist whenever there is more than one link in a session between a router and its peer, such as in a platform-wide session.
A hello adjacency is considered active if it is currently engaged in a session, or nonactive if it is not currently engaged in a session.
A targeted hello adjacency is not directly connected to its peer and has an unlimited number of hops between itself and its peer. A linked hello adjacency is directly connected between two routers.
In Figure 5, Router A has two remote peers, Routers B and C. Router A has a platform-wide session with Router B that consists of three serial interfaces, one of which is active and another platform-wide (targeted) session with Router C.
Figure 5
Hello Adjacency
Figure 6 shows entries in the mplsLdpHelloAdjacencyTable. There are four
mplsLdpHelloAdjHoldTime sample objects (top to bottom). They represent the two platform-wide sessions and the four serial links shown in Figure 5.The indexing is based on the mplsLdpSessionTable. When the mplsLdpHelloAdjIndex enumerates the different links within a single session, the active link is mplsLdpHelloAdjIndex = 1.
Figure 6
Sample Indexing for an LDP Hello Adjacency
Events Generating MPLS LDP MIB Notifications in MPLS LDP MIB Version 8 Upgrade
When you enable MPLS LDP MIB notification functionality by issuing the snmp-server enable traps mpls ldp command, notification messages are generated and sent to a designated NMS in the network to signal the occurrence of specific events within Cisco IOS.
The MPLS LDP MIB objects involved in LDP status transitions and event notifications include the following:
•
•
•
The value of the path vector limit can range from 0 through 255; a value of 0 indicates that loop detection is off; any value other than zero up to 255 indicates that loop detection is on and, in addition, specifies the maximum number of hops through which an LDP message can pass before a loop condition in the network is sensed.
We recommend that all LDP-enabled routers in the network be configured with the same path vector limit. Accordingly, the mplsLdpPathVectorLimitMismatch object exists in the MPLS LDP MIB to provide a warning message to the NMS when two routers engaged in LDP operations have different path vector limits.
Note
•
Eight failed attempts to establish an LDP session between a local LSR and an LDP peer, due to any type of incompatibility between the devices, causes this notification message to be generated. Cisco routers support the same features across multiple platforms.
Therefore, the most likely incompatibility to occur between Cisco LSRs is a mismatch of their respective ATM VPI/VCI label ranges.
For example, if you specify a range of valid labels for an LSR that does not overlap the range of its adjacent LDP peer, the routers try eight times to create an LDP session between themselves before the mplsLdpFailedInitSessionThresholdExceeded notification is generated and sent to the NMS as an informational message.
The LSRs whose label ranges do not overlap continue their attempt to create an LDP session between themselves after the eight-retry threshold is exceeded.
In such cases, the LDP threshold exceeded notification alerts the network administrator about a condition in the network that might warrant attention.
RFC 3036, LDP Specification, details the incompatibilities that can exist between Cisco routers and/or other vendor LSRs in an MPLS network.
Among such incompatibilities, for example, are the following:
–
–
–
–
MIB Tables in MPLS LDP MIB Version 8 Upgrade
Version 8 of the MPLS LDP MIB consists of the following tables:
•
The advantage of showing the active hello adjacency instead of sessions in this table is that the active hello adjacency can exist even if an LDP session is not active (cannot be established). Previous implementations of the IETF MPLS-LDP MIB used sessions as the entries in this table. This approach was inadequate because as sessions went down, the entries in the entity table would disappear completely because the agent code could no longer access them. This resulted in the MIB failing to provide information about failed LDP sessions.
Directed adjacencies are also shown in this table. These entries, however, are always up administratively (adminStatus) and operationally (operStatus), because the adjacencies disappear if the directed session fails. Nondirected adjacencies might disappear from the MIB on some occasions, because adjacencies are deleted if the underlying interface becomes operationally down, for example.
•
•
•
•
•
•
•
•
•
mplsLdpEntityTable
Table 1 lists the mplsLdpEntityTable objects and their descriptions.
mplsLdpEntityConfGenLRTable
Table 2 lists the mplsLdpEntityConfGenLRTable objects and their descriptions.
mplsLdpEntityAtmParmsTable
Table 3 lists the mplsLdpEntityAtmParmsTable objects and their descriptions.
mplsLdpEntityConfAtmLRTable
Table 4 lists the mplsLdpEntityConfAtmLRTable objects and their descriptions.
mplsLdpEntityStatsTable
Table 5 lists the mplsLdpEntityStatsTable objects and their descriptions.
mplsLdpPeerTable
Table 6 lists the mplsLdpPeerTable objects and their descriptions.
mplsLdpHelloAdjacencyTable
Table 7 lists the mplsLdpHelloAdjacencyTable objects and their descriptions.
mplsLdpSessionTable
Table 8 lists the mplsLdpSessionTable objects and their descriptions.
mplsLdpAtmSesTable
Table 9 lists the mplsLdpAtmSesTable objects and their descriptions.
mplsLdpSesStatsTable
Table 10 lists the mplsLdpSesStatsTable objects and their descriptions.
VPN Contexts in MPLS LDP MIB Version 8 Upgrade
Within an MPLS Border Gateway Protocol (BGP) 4 Virtual Private Network (VPN) environment, separate LDP processes can be created for each VPN. These processes and their associated data are called LDP contexts. Each context is independent from all others and contains data specific only to that context.
Cisco IOS Release 12.0(11)ST and later releases include the VPN Aware LDP MIB feature that allows the LDP MIB to get VPN context information. The feature adds support for different contexts for different MPLS VPNs. Users of the MIB can view MPLS LDP processes for a given MPLS VPN. The VPN Aware LDP MIB feature does not change the syntax of the IETF MPLS-LDP MIB. It changes the number and types of entries within the tables.
The IETF MPLS-LDP MIB can show information about only one context at a time. You can specify a context, either a global context or an MPLS VPN context, using an SMNP security name.
The following sections describe topics related to the VPN Aware LDP MIB feature:
•
SNMP Contexts
SNMP contexts provide VPN users with a secure way of accessing MIB data. When a VPN is associated with a context, that VPN's specific MIB data exists in that context. Associating a VPN with a context enables service providers to manage networks with multiple VPNs. Creating and associating a context with a VPN enables a provider to prevent the users of one VPN from accessing information about users of other VPNs on the same networking device.
VPN-aware SNMP requires that SNMP manager and agent entities operating in a VPN environment agree on mapping between the SNMP security name and the VPN name. This mapping is created by using different contexts for the SNMP data of different VPNs, which is accomplished through the configuration of the SNMP View-based Access Control Model MIB (SNMP-VACM-MIB). The SNMP-VACM-MIB is configured with views so that a user on a VPN with a security name is allowed access to the restricted object space within the context of only that VPN.
SNMP request messages undergo three phases of security and access control before a response message is sent back with the object values within a VPN context:
•
•
•
IP access lists can be configured and associated with SNMP community strings. This feature enables you to configure an association between VRF instances and SNMP community strings. When a VRF instance is associated with an SNMP community string, SNMP processes requests coming in for a particular community string only if they are received from the configured VRF. If the community string contained in the incoming packet does not have a VRF associated with it, it is processed only if it came in through a non-VRF interface.
You can also enable or disable authentication traps for SNMP packets dropped due to VRF mismatches. By default, if SNMP authentication traps are enabled, VRF authentication traps are also enabled.
VPN Aware LDP MIB Sessions
Prior to Cisco IOS Release 12.0(11)ST, an SNMP query to the MPLS LDP MIB returned information about global sessions only. A query did not return information about LDP sessions in a VPN context. The IETF MPLS LDP MIB retrieved information from global routing tables, but did not retrieve information from VPN routing and forwarding instances (VRFs) that store per-VPN routing data. The MPLS LDP MIB looked only at LDP processes in the global context and ignored all other sessions. A query on a VRF returned no information. You can view LDP processes in a VPN context.
Figure 7 shows a sample MPLS VPN network with the MPLS LDP sessions prior to the implementation of the VPN Aware LDP MIB feature.
Figure 7 MPLS LDP Sessions Setup Before VPN Aware LDP MIB Feature
A MIB walk prior to this Cisco IOS release displayed only global session information.
With the VPN Aware LDP MIB enhancement in this Cisco IOS release, an SNMP query to the IETF MPLS-LDP-MIB supports both global and VPN contexts. This feature allows you to enter LDP queries on any VRF and on the core (global context). A query can differentiate between LDP sessions from different VPNs. LDP session information for a VPN stays in the context of that VPN. Therefore, the information from one VPN is not available to a user of a different VPN. The VPN Aware update to the LDP MIB also allows you to view LDP processes operating in a Carrier Supporting Carrier (CSC) network.
In an MPLS VPN, a service provider edge router (PE) might contain VRFs for several VPNs as well as a global routing table. To set up separate LDP processes for different VPNs on the same device, you need to configure each VPN with a unique securityName, contextName, and View-based Access Control Model (VACM) view. The VPN securityName must be configured for the IETF MPLS LDP MIB.
Figure 8 shows LDP sessions for a sample MPLS VPN network with the VPN Aware LDP MIB feature.
Figure 8 MPLS LDP Sessions with the VPN Aware LDP MIB Feature
With the VPN Aware LDP MIB feature, you can do MIB queries or MIB walks for an MPLS VPN LDP session or a global LDP session.
Note
VPN Aware LDP MIB Notifications
Prior to Cisco IOS Release 12.0(11)ST, all notification messages for MPLS LDP sessions were sent to the same designated network management station (NMS) in the network. The notifications were enabled with the snmp-server enable traps mpls ldp command.
Figure 9 shows LDP notifications that were sent before the implementation of the VPN Aware LDP MIB feature.
Figure 9 LDP Notifications Sent Before the VPN Aware LDP MIB Feature
The VPN Aware LDP MIB feature supports LDP notifications for multiple LDP contexts for VPNs. LDP notifications can be generated for the core (global context) and for different VPNs. You can cause notifications be sent to different NMS hosts for different LDP contexts. LDP notifications associated with a specific VRF are sent to the NMS designated for that VRF. LDP global notifications are sent to the NMS configured to receive global traps.
To enable LDP context notifications for the VPN Aware LDP MIB feature, use either the SNMP object mplsLdpSessionsUpDownEnable (in the global LDP context only) or the following extended global configuration commands.
To enable LDP notifications for the global context, use the following commands:
PE-Router(config)# snmp-server host host-address traps community mpls-ldpPE-Router(config)# snmp-server enable traps mpls ldpTo enable LDP notifications for a VPN context, use the following commands:
PE-Router(config)# snmp-server host host-address vrf vrf-name version {v1|v2c|v3} community community-string udp-port upd-port mpls-ldpPE-Router(config)# snmp-server enable traps mpls ldpFigure 10 shows LDP notifications with the VPN Aware LDP MIB feature.
Figure 10 LDP Notifications With the VPN Aware LDP MIB Feature
How to Configure MPLS LDP MIB Version 8 Upgrade
This section contains the following procedures:
•
•
•
•
•
•
•
•
Enabling the SNMP Agent
Perform this task to enable the SNMP agent.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
DETAILED STEPS
Enabling Cisco Express Forwarding
Perform this task to enable Cisco Express Forwarding or distributed Cisco Express Forwarding.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
Enabling MPLS Globally
Perform this task to enable MPLS globally.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
Enabling LDP Globally
Perform this task to enable LDP globally.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
Enabling MPLS on an Interface
Perform this task to enable MPLS on an interface.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Enabling LDP on an Interface
Perform this task to enable LDP on an interface.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Configuring a VPN Aware LDP MIB
To configure a VPN Aware LDP MIB, perform the following tasks:
•
•
•
Configuring SNMP Support for a VPN
Perform this task to configure SNMP support for a Virtual Private Network (VPN) or a remote VPN.
SUMMARY STEPS
1.
2.
3.
community-string [udp-port port] [notification-type] [vrf vrf-name]4.
engineid-string5.
DETAILED STEPS
What to Do Next
Proceed to the "Configuring an SNMP Context for a VPN" section.
Configuring an SNMP Context for a VPN
Perform this task to configure an SNMP context for a VPN. This sets up a unique SNMP context for a VPN, which allows you to access the VPN's LDP session information.
SNMP Context
SNMP contexts provide VPN users with a secure way of accessing MIB data. When a VPN is associated with a context, that VPN's specific MIB data exists in that context. Associating a VPN with a context enables service providers to manage networks with multiple VPNs. Creating and associating a context with a VPN enables a provider to prevent the users of one VPN from accessing information about users of other VPNs on the same networking device.
VPN Route Distinguishers
A route distinguisher (RD) creates routing and forwarding tables for a VPN. Cisco IOS adds the RD to the beginning of the customer's IPv4 prefixes to change them into globally unique VPN-IPv4 prefixes.
Either the RD is an autonomous system number (ASN)-relative RD, in which case it is composed of an autonomous system number and an arbitrary number, or it is an IP-address-relative RD, in which case it is composed of an IP address and an arbitrary number. You can enter an RD in either of these formats:
•
•
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
DETAILED STEPS
What to Do Next
Proceed to the "Associating an SNMP VPN Context with SNMPv1 or SNMPv2" section.
Associating an SNMP VPN Context with SNMPv1 or SNMPv2
Perform this task to associate an SNMP VPN context with SNMPv1 or SNMPv2. This allows you to access LDP session information for a VPN using SNMPv1 or SNMPv2.
SNMPv1 or SNMPv2 Security
SNMPv1 and SNMPv2 are not as secure as SNMPv3. SNMP Versions 1 and 2 use plain text communities and do not perform the authentication or security checks that SNMP Version 3 performs.
To configure the VPN Aware LDP MIB feature when using SNMP Version 1 or SNMP Version 2, you need to associate a community name with a VPN. This association causes SNMP to process requests coming in for a particular community string only if they come in from the configured VRF. If the community string contained in the incoming packet does not have an associated VRF, the packet is processed only if it came in through a non-VRF interface. This process prevents users outside the VPN from using a clear text community string to query the VPN data. However, this is not as secure as using SNMPv3.
SUMMARY STEPS
1.
2.
3.
[auth {md5 | sha} auth-password]} [access access-list]4.
[read readview] [write writeview] [notify notifyview] [access access-list]5.
6.
7.
community-string [udp-port port] [notification-type] [vrf vrf-name]8.
[security-name security-name] target-list vpn-list-name9.
10.
11.
DETAILED STEPS
Verifying MPLS LDP MIB Version 8 Upgrade
Perform a MIB walk using your SNMP management tool to verify that the MPLS LDP MIB Version 8 Upgrade feature is functioning.
Configuration Examples for MPLS LDP MIB Version 8 Upgrade
This section provides the following configuration examples:
•
•
MPLS LDP MIB Version 8 Upgrade Examples
The following example shows how to enable an SNMP agent on the host NMS:
Router# configure terminalEnter configuration commands, one per line. End with CNTL/Z.Router(config)# snmp-server communityThe following example shows how to enable SNMPv1 and SNMPv2C on the host NMS. The configuration permits any SNMP agent to access all MPLS LDP MIB objects that have read-only permission using the community string public.
Router(config)# snmp-server community publicThe following example shows how to allow read-only access to all MPLS LDP MIB objects relating to members of access list 4 that specify the comaccess community string. No other SNMP agents will have access to any of the MPLS LDP MIB objects.
Router(config)# snmp-server community comaccess ro 4The following example shows how to enable LDP globally and then on an interface:
Router# configure terminalEnter configuration commands, one per line. End with CNTL/Z.Router(config)# mpls label protocol ldpRouter(config)# interface Ethernet1Router(config-if)# mpls label protocol ldpRouter(config-if)# endConfiguring a VPN Aware SNMP Context for SNMPv1 or SNMPv2: Example
The following configuration example shows how to configure a VPN Aware SNMP context for the MPLS LDP MIB Version 8 with SNMPv1 or SNMPv2:
snmp-server context Asnmp-server context Bip vrf CustomerArd 100:110context Aroute-target export 100:1000route-target import 100:1000!ip vrf CustomerBrd 100:120context Broute-target export 100:2000route-target import 100:2000!interface Ethernet3/1description Belongs to VPN Aip vrf forwarding CustomerAip address 10.0.0.0 255.255.0.0interface Ethernet3/2description Belongs to VPN Bip vrf forwarding CustomerBip address 10.0.0.1 255.255.0.0snmp-server user commA grp1A v1snmp-server user commA grp2A v2csnmp-server user commB grp1B v1snmp-server user commB grp2B v2csnmp-server group grp1A v1 context A read viewA write viewA notify viewAsnmp-server group grp1B v1 context B read viewB write viewB notify viewBsnmp-server view viewA ipForward includedsnmp-server view viewA ciscoPingMIB includedsnmp-server view viewB ipForward includedsnmp-server view viewB ciscoPingMIB includedsnmp-server enable trapssnmp-server host 10.0.0.3 vrf CustomerA commA udp-port 7002snmp-server host 10.0.0.4 vrf CustomerB commB udp-port 7002snmp mib community-map commA context A target-list commAvpn! Configures source address validationsnmp mib community-map commB context B target-list commBvpn! Configures source address validationsnmp mib target list commAvpn vrf CustomerA! Configures a list of VRFs or from which community commA is validsnmp mib target list commBvpn vrf CustomerB! Configures a list of VRFs or from which community commB is validAdditional References
The following sections provide references related to the MPLS LDP MIB Version 8 Upgrade feature.
Related Documents
MPLS LDP configuration tasks
A description of SNMP agent support in Cisco IOS software for the MPLS Label Switching Router MIB (MPLS-LSR-MIB)
A description of SNMP agent support in Cisco IOS software for the MPLS Traffic Engineering MIB (MPLS TE MIB)
Configuration tasks for MPLS ATM network enhancements
MPLS automatic bandwidth adjustment configuration tasks
MPLS Traffic Engineering (TE)—Automatic Bandwidth Adjustment for TE Tunnels
A description of MPLS differentiated types of service across an MPLS network
SNMP commands
Cisco IOS Network Management Command Reference, Release 12.4T
SNMP configuration
"Configuring SNMP Support" chapter in the Cisco IOS Network Management Configuration Guide, Release 12.4
SNMP support for VPNs
SNMP context support for VPNs configuration tasks
Standards
No new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature.
—
MIBs
RFCs
Technical Assistance
Command Reference
This section documents only commands that are new or modified.
•
•
context
To associate a Simple Network Management Protocol (SNMP) context with a particular virtual private network (VPN) routing and forwarding instance (VRF), use the context command in VRF configuration mode. To disassociate an SNMP context from a VPN, use the no form of this command.
context context-name
no context context-name
Syntax Description
Command Default
No SNMP contexts are associated with VPNs.
Command Modes
VRF configuration (config-vrf)
Command History
Usage Guidelines
Before you use this command to associate an SNMP context with a VPN, you must do the following:
•
•
•
SNMP contexts provide VPN users with a secure way of accessing MIB data. When a VPN is associated with a context, MIB data for that VPN exists in that context. Associating a VPN with a context helps enable service providers to manage networks with multiple VPNs. Creating and associating a context with a VPN enables a provider to prevent the users of one VPN from accessing information about users of other VPNs on the same networking device.
A route distinguisher (RD) is required when you configure an SNMP context. An RD creates routing and forwarding tables and specifies the default route distinguisher for a VPN. The RD is added to the beginning of a IPv4 prefix to make it globally unique. An RD is either ASN relative, which means it is composed of an autonomous system number and an arbitrary number, or it is IP address relative and composed of an IP address and an arbitrary number.
Examples
The following example shows how to create an SNMP context named context1 and associate the context with the VRF named vrf1:
Router(config)# snmp-server context1Router(config)# ip vrf vrf1Router(config-vrf)# rd 100:120Router(config-vrf)# context context1Related Commands
show mpls ldp neighbor
To display the status of Label Distribution Protocol (LDP) sessions, use the show mpls ldp neighbor command in user EXEC or privileged EXEC mode.
show mpls ldp neighbor [vrf vrf-name | all] [address | interface] [detail] [graceful-restart]
Syntax Description
Command Default
This command displays information about LDP neighbors for the default routing domain if you do not specify the optional vrf keyword.
Command Modes
User EXEC (>)
Privileged EXEC (#)Command History
Usage Guidelines
The show mpls ldp neighbor command can provide information about all LDP neighbors, or the information can be limited to the following:
•
•
Note
Examples
For explanations of the significant fields shown in the displays, see Table 11.
The following is sample output from the show mpls ldp neighbor command:
Router# show mpls ldp neighborPeer LDP Ident: 10.0.7.7:2; Local LDP Ident 10.1.1.1:1TCP connection: 10.0.7.7:11032 - 10.1.1.1:646State: Oper; Msgs sent/rcvd: 5855/6371; Downstream on demandUp time: 13:15:09LDP discovery sources:ATM3/0.1Peer LDP Ident: 10.1.1.1:0; Local LDP Ident 10.1.1.1:0TCP connection: 10.1.1.1:646 - 10.1.1.1:11006State: Oper; Msgs sent/rcvd: 4/411; DownstreamUp time: 00:00:52LDP discovery sources:Ethernet1/0/0Addresses bound to peer LDP Ident:10.0.0.29 10.1.1.1 10.0.0.199 10.10.1.110.205.0.9The following is sample output from the show mpls ldp neighbor command, in which duplicate addresses are detected. They indicate an error because a given address should be bound to only one peer.
Router# show mpls ldp neighborPeer LDP Ident: 10.0.7.7:2; Local LDP Ident 10.1.1.1:1TCP connection: 10.0.7.7:11032 - 10.1.1.1:646State: Oper; Msgs sent/rcvd: 5855/6371; Downstream on demandUp time: 13:15:09LDP discovery sources:ATM3/0.1Peer LDP Ident: 10.1.1.1:0; Local LDP Ident 10.1.1.1:0TCP connection: 10.1.1.1:646 - 10.1.1.1:11006State: Oper; Msgs sent/rcvd: 4/411; DownstreamUp time: 00:00:52LDP discovery sources:Ethernet1/0/0Addresses bound to peer LDP Ident:10.0.0.29, 10.1.1.1, 10.0.0.199, 10.10.1.110.205.0.9Duplicate Addresses advertised by peer:10.10.8.111The following is sample output from the show mpls ldp neighbor vrf vpn10 command, which displays the LDP neighbor information for the specified VPN routing and forwarding instance named vpn10:
Router# show mpls ldp neighbor vrf vpn10Peer LDP Ident:10.14.14.14:0; Local LDP Ident 10.29.0.2:0TCP connection:10.14.14.14:646 - 10.29.0.2:11384State:Oper; Msgs sent/rcvd:1423/800; DownstreamUp time:02:38:11LDP discovery sources:ATM3/0/0.10Addresses bound to peer LDP Ident:10.3.36.9 10.7.0.1 10.14.14.14 10.13.0.110.15.0.1 10.17.0.1 10.19.0.1 10.21.0.110.23.0.1 10.25.0.1 10.27.0.1 10.29.0.110.31.0.1 10.33.0.1 10.35.0.1 10.37.0.110.39.0.1 10.41.0.1 10.43.0.1 10.45.0.110.47.0.1 10.49.0.1 10.51.0.1 10.53.0.110.55.0.1 10.57.0.1 10.59.0.1 10.61.0.110.63.0.1 10.65.0.1 10.67.0.1 10.69.0.110.71.0.1 10.73.0.1 10.75.0.1 10.77.0.110.79.0.1 10.81.0.1 10.83.0.1 10.85.0.110.87.0.1 10.89.0.1 10.91.0.1 10.93.0.110.95.0.1 10.97.0.1 10.99.0.1 10.101.0.110.103.0.1 10.105.0.1 10.107.0.1 10.109.0.110.4.0.2 10.3.0.2The following shows sample output from the show mpls ldp neighbor detail command, which displays information about inbound filtering:
Router# show mpls ldp neighbor vrf vpn1 detailPeer LDP Ident: 10.13.13.13:0; Local LDP Ident 10.33.0.2:0TCP connection: 10.13.13.13:646 - 10.33.0.2:31581State: Oper; Msgs sent/rcvd: 11/10; Downstream; Last TIB rev sent 13Up time: 00:02:25; UID: 26; Peer Id 0;LDP discovery sources:Ethernet1/0/2; Src IP addr: 10.33.0.1holdtime: 15000 ms, hello interval: 5000 msAddresses bound to peer LDP Ident:10.3.105.1 10.13.13.13 10.33.0.1Peer holdtime: 180000 ms; KA interval: 60000 ms; Peer state: estabLDP inbound filtering accept acl:1Peer LDP Ident: 10.14.14.14:0; Local LDP Ident 10.33.0.2:0TCP connection: 10.14.14.14:646 - 10.33.0.2:31601State: Oper; Msgs sent/rcvd: 10/9; Downstream; Last TIB rev sent 13Up time: 00:01:17; UID: 29; Peer Id 3;LDP discovery sources:Ethernet1/0/3; Src IP addr: 10.33.0.1holdtime: 15000 ms, hello interval: 5000 msAddresses bound to peer LDP Ident:10.3.104.1 10.14.14.14 10.32.0.1Peer holdtime: 180000 ms; KA interval: 60000 ms; Peer state: estabLDP inbound filtering accept acl:1The following is sample output from the show mpls ldp neighbor all command, which displays the LDP neighbor information for all VPN routing and forwarding instances, including those in the default routing domain. In this example, note that the same neighbor LDP ID (10.14.14.14) appears in all the listed VRF interfaces, highlighting the fact that the same IP address can coexist in different VPN routing and forwarding instances.
Router# show mpls ldp neighbor allPeer TDP Ident:10.11.11.11:0; Local TDP Ident 10.12.12.12:0TCP connection:10.11.11.11:711 - 10.12.12.12:11003State:Oper; PIEs sent/rcvd:185/187; DownstreamUp time:02:40:02TDP discovery sources:ATM1/1/0.1Addresses bound to peer TDP Ident:10.3.38.3 10.1.0.2 10.11.11.11VRF vpn1:Peer LDP Ident:10.14.14.14:0; Local LDP Ident 10.7.0.2:0TCP connection:10.14.14.14:646 - 10.7.0.2:11359State:Oper; Msgs sent/rcvd:952/801; DownstreamUp time:02:38:49LDP discovery sources:ATM3/0/0.1Addresses bound to peer LDP Ident:10.3.36.9 10.7.0.1 10.14.14.14 10.13.0.110.15.0.1 10.17.0.1 10.19.0.1 10.21.0.110.23.0.1 10.25.0.1 10.27.0.1 10.29.0.110.31.0.1 10.33.0.1 10.35.0.1 10.37.0.110.39.0.1 10.41.0.1 10.43.0.1 10.45.0.110.47.0.1 10.49.0.1 10.51.0.1 10.53.0.110.55.0.1 10.57.0.1 10.59.0.1 10.61.0.110.63.0.1 10.65.0.1 10.67.0.1 10.69.0.110.71.0.1 10.73.0.1 10.75.0.1 10.77.0.110.79.0.1 10.81.0.1 10.83.0.1 10.85.0.110.87.0.1 10.89.0.1 10.91.0.1 10.93.0.110.95.0.1 10.97.0.1 10.99.0.1 10.101.0.110.103.0.1 10.105.0.1 10.107.0.1 10.109.0.110.4.0.2 10.3.0.2VRF vpn2:Peer LDP Ident:10.14.14.14:0; Local LDP Ident 10.13.0.2:0TCP connection:10.14.14.14:646 - 10.13.0.2:11361State:Oper; Msgs sent/rcvd:964/803; DownstreamUp time:02:38:50LDP discovery sources:ATM3/0/0.2Addresses bound to peer LDP Ident:10.3.36.9 10.7.0.1 10.14.14.14 10.13.0.110.15.0.1 10.17.0.1 10.19.0.1 10.21.0.110.23.0.1 10.25.0.1 10.27.0.1 10.29.0.110.31.0.1 10.33.0.1 10.35.0.1 10.37.0.110.39.0.1 10.41.0.1 10.43.0.1 10.45.0.110.47.0.1 10.49.0.1 10.51.0.1 10.53.0.110.55.0.1 10.57.0.1 10.59.0.1 10.61.0.110.63.0.1 10.65.0.1 10.67.0.1 10.69.0.110.71.0.1 10.73.0.1 10.75.0.1 10.77.0.110.79.0.1 10.81.0.1 10.83.0.1 10.85.0.110.87.0.1 10.89.0.1 10.91.0.1 10.93.0.110.95.0.1 10.97.0.1 10.99.0.1 10.101.0.110.103.0.1 10.105.0.1 10.107.0.1 10.109.0.110.4.0.2 10.3.0.2VRF vpn3:Peer LDP Ident:10.14.14.14:0; Local LDP Ident 10.15.0.2:0TCP connection:10.14.14.14:646 - 10.15.0.2:11364State:Oper; Msgs sent/rcvd:1069/800; DownstreamUp time:02:38:52LDP discovery sources:ATM3/0/0.3Addresses bound to peer LDP Ident:10.3.36.9 10.17.0.1 10.14.14.14 10.13.0.110.15.0.1 10.17.0.1 10.19.0.1 10.21.0.110.23.0.1 10.25.0.1 10.27.0.1 10.29.0.110.31.0.1 10.33.0.1 10.35.0.1 10.37.0.110.39.0.1 10.41.0.1 10.43.0.1 10.45.0.110.47.0.1 10.49.0.1 10.51.0.1 10.53.0.110.55.0.1 10.57.0.1 10.59.0.1 10.61.0.110.63.0.1 10.65.0.1 10.67.0.1 10.69.0.110.71.0.1 10.73.0.1 10.75.0.1 10.77.0.110.79.0.1 10.81.0.1 10.83.0.1 10.85.0.110.87.0.1 10.89.0.1 10.91.0.1 10.93.0.110.95.0.1 10.97.0.1 10.99.0.1 10.101.0.110.103.0.1 10.105.0.1 10.107.0.1 10.109.0.110.4.0.2 10.3.0.2VRF vpn4:Peer LDP Ident:10.14.14.14:0; Local LDP Ident 10.17.0.2:0TCP connection:10.14.14.14:646 - 10.17.0.2:11366State:Oper; Msgs sent/rcvd:1199/802; DownstreamThe following example shows the Graceful Restart status of the LDP neighbors:
Router# show mpls ldp neighbor graceful-restartPeer LDP Ident: 10.20.20.20:0; Local LDP Ident 10.17.17.17:0TCP connection: 10.20.20.20:16510 - 10.17.17.17:646State: Oper; Msgs sent/rcvd: 8/18; DownstreamUp time: 00:04:39Graceful Restart enabled; Peer reconnect time (msecs): 120000Peer LDP Ident: 10.19.19.19:0; Local LDP Ident 10.17.17.17:0TCP connection: 10.19.19.19:11007 - 10.17.17.17:646State: Oper; Msgs sent/rcvd: 8/38; DownstreamUp time: 00:04:30Graceful Restart enabled; Peer reconnect time (msecs): 120000The following sample output from the show mpls ldp neighbor detail command displays information about the MD5 password configuration:
Router# show mpls ldp neighbor detailPeer LDP Ident: 10.3.3:0; Local LDP Ident 10.1.1.1:0TCP connection: 10.3.3.3:11018 - 10.1.1.1:646Password: required, neighbor, in useState: Oper; Msgs sent/rcvd: 167/167; Downstream; Last TIB rev sent 9Up time: 02:24:02; UID: 5; Peer Id 3;LDP discovery sources:Targeted Hello 10.1.1.1 -> 10.3.3.3, passive;holdtime: 90000 ms, hello interval: 10000 msAddresses bound to peer LDP Ident:10.3.3.3 10.0.30.3Peer holdtime: 180000 ms; KA interval: 60000 ms; Peer state: estabPeer LDP Ident: 10.4.4.4:0; Local LDP Ident 10.1.1.1:0TCP connection: 10.4.4.4:11017 - 10.1.1.1:646Password: not required, none, staleState: Oper; Msgs sent/rcvd: 9/9; Downstream; Last TIB rev sent 9Up time: 00:05:35; UID: 6; Peer Id 1;LDP discovery sources:Ethernet1/0; Src IP addr: 10.0.20.4holdtime: 15000 ms, hello interval: 5000 msAddresses bound to peer LDP Ident:10.0.40.4 10.4.4.4 10.0.20.4Peer holdtime: 180000 ms; KA interval: 60000 ms; Peer state: estabTable 11 describes the significant fields shown in the displays.
Related Commands
snmp mib community-map
To associate a Simple Network Management Protocol (SNMP) community with an SNMP context, engine ID, or security name, use the snmp mib community-map command in global configuration mode. To change an SNMP community mapping to its default mapping, use the no form of this command.
snmp mib community-map community-name [context context-name] [engineid engine-id] [security-name security-name] [target-list vpn-list-name]
no snmp mib community-map community-name [context context-name] [engineid engine-id] [security-name security-name] [target-list vpn-list-name]
Syntax Description
Command Default
No SNMP communities and contexts are associated.
Command Modes
Global configuration (config)
Command History
Usage Guidelines
Use this command to create a mapping between an SNMP community and an SNMP context, engine ID, or security name that is different from the default settings.
Use the snmp-server community command to configure an SNMP community. When an SNMP community is associated with an SNMP context and a request is made from this community, the request is applied to the context. You also can use the snmp mib community-map command to specify the source address validation for an SNMP community by associating a list of target VRFs. The target VRF list specifies the valid host or hosts for this SNMP community.
Examples
The following example shows how to create an SNMP community named community1 and associate it with an SNMP context named context1:
Router(config)# snmp-server community community1Router(config)# snmp mib community-map community1 context context1The following example shows a mapping of community A (commA) to VPN list commAvpn and community B (commB) to VPN list commBvpn:
Router(config)# snmp mib community-map commA context A target-list commAvpnRouter(config)# snmp mib community-map commB context B target-list commBvpnRouter(config)# snmp mib target list commAvpn vrf CustomerARouter(config)# snmp mib target list commBvpn vrf CustomerBRelated Commands
context
Associates an SNMP context with a particular VPN.
snmp-server community
Sets up the community access string to permit access to the SNMP.
snmp mib target list
To create a list of target virtual private network (VPN) routing and forwarding (VRF) instance and hosts to associate with a Simple Network Management Protocol (SNMP) community, use the snmp mib target list command in global configuration mode. To delete the list of VRF instances and hosts or to delete a particular VRF or host from the list, use the no form of this command.
snmp mib target list vpn-list-name {vrf vrf-name | host ip-address}
no snmp mib target list vpn-list-name {vrf vrf-name | host ip-address}
Syntax Description
Command Default
No target list is created.
Command Modes
Global configuration (config)
Command History
Usage Guidelines
Use this command when using SNMPv1 or SNMPv2 in a VPN environment to configure a list of VRFs or hosts for source address validation. Configuring the target list ensures that the community is valid only if the incoming packet is received from a VRF or host on the target list.
•
–
–
–
–
–
•
Note
Examples
The following example shows how to add a target list named target1 and add a VRF named vrf1 to the newly created target list:
Router(config)# snmp mib target list target1 vrf vrf1Related Commands
snmp mib community-map
Associates an SNMP community with an SNMP context, engine ID, or security name.
snmp-server community
To set up the community access string to permit access to the Simple Network Management Protocol (SNMP), use the snmp-server community command in global configuration mode. To remove the specified community string, use the no form of this command.
snmp-server community string [view view-name] [ro | rw] [ipv6 nacl] [access-list-number]
no snmp-server community string
Syntax Description
Command Default
An SNMP community string permits read-only access to all objects.
Note
Command Modes
Global configuration (config)
Command History
Usage Guidelines
The no snmp-server command disables all versions of SNMP (SNMPv1, SNMPv2C, SNMPv3).
The first snmp-server command that you enter enables all versions of SNMP.
To configure SNMP community strings for the MPLS LDP MIB, use the snmp-server community command on the host network management station (NMS).
The snmp-server community command can be used to specify only an IPv6 named access list, only an IPv4 access list, or both. For you to configure both IPv4 and IPv6 access lists, the IPv6 access list must appear first in the command statement.
Note
Examples
The following example shows how to set the read/write community string to newstring:
Router(config)# snmp-server community newstring rwThe following example shows how to allow read-only access for all objects to members of the standard named access list lmnop that specify the comaccess community string. No other SNMP managers have access to any objects.
Router(config)# snmp-server community comaccess ro lmnopThe following example shows how to assign the string comaccess to SNMP, allow read-only access, and specify that IP access list 4 can use the community string:
Router(config)# snmp-server community comaccess ro 4The following example shows how to assign the string manager to SNMP and allow read-write access to the objects in the restricted view:
Router(config)# snmp-server community manager view restricted rwThe following example shows how to remove the community comaccess:
Router(config)# no snmp-server community comaccessThe following example shows how to disable all versions of SNMP:
Router(config)# no snmp-serverThe following example shows how to configure an IPv6 access list named list1 and links an SNMP community string with this access list:
Router(config)# ipv6 access-list list1Router(config-ipv6-acl)# permit ipv6 any anyRouter(config-ipv6-acl)# exitRouter(config)# snmp-server community comaccess rw ipv6 list1Related Commands
snmp-server context
To create a Simple Network Management Protocol (SNMP) context, use the snmp-server context command in global configuration mode. To delete an SNMP context, use the no form of this command.
snmp-server context context-name
no snmp-server context context-name
Syntax Description
Command Default
No SNMP contexts are configured.
Command Modes
Global configuration (config)
Command History
Usage Guidelines
When you use the no snmp-server context command, all SNMP instances in that context are deleted.
A route distinguisher (RD) is required when you configure an SNMP context. An RD creates routing and forwarding tables and specifies the default route distinguisher for a VPN. The RD is added to the beginning of a IPv4 prefix to make it globally unique. An RD is either ASN relative, which means it is composed of an autonomous system number and an arbitrary number, or it is IP address relative and composed of an IP address and an arbitrary number.
Examples
The following example shows how to create an SNMP context named contextA and associate it with a virtual private network (VPN) routing and forwarding (VRF) instance named CustomerA:
Router(config)# snmp-server context contextARouter(config)# ip vrf CustomerARouter(config-vrf)# rd 100:120Router(config-vrf)# context contextARelated Commands
snmp-server enable traps (MPLS)
To enable a label switch router (LSR) to send Simple Network Management Protocol (SNMP) notifications or informs to an SNMP host, use the snmp-server enable traps command in global configuration mode. To disable notifications or informs, use the no form of this command.
snmp-server enable traps [notification-type] [notification-option]
no snmp-server enable traps [notification-type] [notification-option]
Syntax Description
Command Default
If you issue this command on an LSR without specifying any notification-type keywords, the default behavior of the LSR is to enable all notification types controlled by the command (some notification types cannot be controlled by means of this command).
Command Modes
Global configuration (config)
Command History
Usage Guidelines
To configure an LSR to send SNMP LDP notifications, you must issue at least one snmp-server enable traps command on the router.
To configure an LSR to send either notifications (traps) or informs to a designated network management station (NMS), you must issue the snmp-server host command on that device, using the keyword (traps or informs) that suits your purposes.
If you issue the snmp-server enable traps command without keywords, all SNMP notification types are enabled on the LSR. If you issue this command with specific keywords, only the notification types associated with those particular keywords are enabled on the LSR.
The snmp-server enable traps command is used in conjunction with the snmp-server host command. You use the latter command to specify the NMS host (or hosts) targeted as the recipient(s) of the SNMP notifications generated by SNMP-enabled LSRs in the network. To enable an LSR to send such notifications, you must issue at least one snmp-server host command on the LSR.
Examples
In the following example, the router is enabled to send all notifications to the host specified as myhost.cisco.com. The community string is defined as public.
Router(config)# snmp-server enable trapsRouter(config)# snmp-server host myhost.cisco.com publicIn the following example, the router is enabled to send Frame Relay and environmental monitor notifications to the host specified as myhost.cisco.com. The community string is defined as public:
Router(config)# snmp-server enable traps frame-relayRouter(config)# snmp-server enable traps envmon temperatureRouter(config)# snmp-server host myhost.cisco.com publicIn the following example, notifications are not sent to any host. BGP notifications are enabled for all hosts, but the only notifications enabled to be sent to a host are ISDN notifications (which are not enabled in this example).
Router(config)# snmp-server enable traps bgpRouter(config)# snmp-server host host1 public isdnIn the following example, the router is enabled to send all inform requests to the host specified as myhost.cisco.com. The community string is defined as public.
Router(config)# snmp-server enable trapsRouter(config)# snmp-server host myhost.cisco.com informs version 2c publicIn the following example, HSRP MIB notifications are sent to the host specified as myhost.cisco.com. The community string is defined as public.
Router(config)# snmp-server enable hsrpRouter(config)# snmp-server host myhost.cisco.com traps version 2c public hsrpRelated Commands
snmp-server host
Specifies the intended recipient of an SNMP notification (that is, the designated NMS workstation in the network).
snmp-server group
To configure a new Simple Network Management Protocol (SNMP) group, use the snmp-server group command in global configuration mode. To remove a specified SNMP group, use the no form of this command.
snmp-server group group-name {v1 | v2c | v3 {auth | noauth | priv}} [context context-name] [read read-view] [write write-view] [notify notify-view] [access [ipv6 named-access-list] [acl-number | acl-name]]
no snmp-server group group-name {v1 | v2c | v3 {auth | noauth | priv}} [context context-name]
Syntax Description
Command Default
No SNMP server groups are configured.
Command Modes
Global configuration (config)
Command History
Usage Guidelines
When a community string is configured internally, two groups with the name public are autogenerated, one for the v1 security model and the other for the v2c security model. Similarly, deleting a community string will delete a v1 group with the name public and a v2c group with the name public.
No default values exist for authentication or privacy algorithms when you configure the snmp-server group command. Also, no default passwords exist. For information about specifying a Message Digest 5 (MD5) password, see the documentation of the snmp-server user command.
Configuring Notify Views
The notify-view option is available for two reasons:
•
•
Specifying a notify view when configuring an SNMP group is not recommended, for the following reasons:
•
•
Instead of specifying the notify view for a group as part of the snmp-server group command, use the following commands in the order specified:
1.
2.
3.
SNMP Contexts
SNMP contexts provide VPN users with a secure way of accessing MIB data. When a VPN is associated with a context, that VPN's specific MIB data exists in that context. Associating a VPN with a context enables service providers to manage networks with multiple VPNs. Creating and associating a context with a VPN enables a provider to prevent the users of one VPN from accessing information about users of other VPNs on the same networking device.
Use this command with the context context-name keyword and argument to associate a read, write, or notify SNMP view with an SNMP context.
Examples
Create an SNMP Group
The following example shows how to create the SNMP server group "public," allowing read-only access for all objects to members of the standard named access list "lmnop":
Router(config)# snmp-server group public v2c access lmnopRemove an SNMP Server Group
The following example shows how to remove the SNMP server group "public" from the configuration:
Router(config)# no snmp-server group public v2cAssociate an SNMP Server Group with Specified Views
The following example shows SNMP context "A" associated with the views in SNMPv2c group "GROUP1":
Router(config)# snmp-server context ARouter(config)# snmp mib community commARouter(config)# snmp mib community-map commA context A target-list commAVpnRouter(config)# snmp-server group GROUP1 v2c context A read viewA write viewA notify viewBRelated 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] [traps | informs] [version {1 | 2c | 3 [auth | noauth | priv]}] community-string [udp-port port] [notification-type]
no snmp-server host {hostname | ip-address} [vrf vrf-name] [traps | informs] [version {1 | 2c | 3 [auth | noauth | priv]}] community-string [udp-port port] [notification-type]
Syntax Description
Command Default
This command is disabled by default. No notifications are sent.
Command Modes
Global configuration (config)
Command History
Usage Guidelines
If you enter this command with no keywords, the default is to send all trap types 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, a SNMP entity that receives an inform request acknowledges the message with a 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 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 retried several times. The retries increase traffic and contribute to a higher overhead on the network.
If you do not enter a 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 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. For example, 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.
A notification-type option's availability depends on the router type and 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 VRF. The VRF defines a VPN membership of a customer so data is stored using the VPN.
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 intervening spaces). The corresponding parameter in the snmp-server enable traps command is specified as mpls-traffic-eng (containing an intervening space and a hyphen).
This syntax difference is necessary to ensure that the command-line interface (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 12 maps some examples of snmp-server enable traps commands to the keywords used in the snmp-server host command.
Table 12 Notification Keywords and Corresponding SNMP Enable Traps Commands
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 172.20.2.160 comaccessRouter(config)# access-list 10 deny any
Note
The following example shows how to send RFC 1157 SNMP traps to a host specified 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 172.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 172.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 company.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 10.56.125.47 using the community string public:
Router(config)# snmp-server enable traps cefRouter(config)# snmp-server host 10.56.125.47 informs version 2c public cefRelated Commands
snmp-server trap authentication vrf
To enable Virtual Private Network (VPN) routing and forwarding (VRF) instance context authentication notifications for Simple Network Management Protocol (SNMP), use the snmp-server trap authentication vrf command in global configuration mode. To suppress authentication notifications for SNMP packets dropped due specifically to VRF context mismatches while keeping all other SNMP authentication notifications enabled, use the no form of this command.
snmp-server trap authentication vrf
no snmp-server trap authentication vrf
Syntax Description
This command has no arguments or keywords.
Command Default
No VRF-specific authentication notifications are enabled when SNMP authentication notifications are not enabled.
Command Modes
Global configuration (config)
Command History
Usage Guidelines
The snmp-server enable traps snmp authentication command controls SNMP authentication traps and the no form of this command disables all SNMP authentication failure notifications. The snmp-server trap authentication vrf command provides more granular control of these notifications.
With context-based MIB access, SNMP requests on each VRF are tied to a specific context. This context is used for access control. If SNMP contexts are configured for VPNs, any SNMP request not matching the configured context will generate an SNMP authentication failure notification.The no snmp-server trap authentication vrf command allows you to suppress the authentication failure notifications that are specific to these VRF contexts, while keeping all other SNMP authentication failure notifications enabled.
The no snmp-server trap authentication vrf command has no effect if the snmp-server enable traps snmp authentication command has not been configured.
Examples
The following example shows how to enable a router to send SNMP authentication traps to host myhost.cisco.com using the community string public while disabling all VRF authentication traps:
Router(config)# snmp-server enable traps snmp authenticationRouter(config)# no snmp-server trap authentication vrfRouter(config)# snmp-server host myhost.cisco.com publicRelated Commands
snmp-server enable traps snmp
Enables the sending of RFC 1157 SNMP notifications.
snmp-server host
Specifies the recipient of an SNMP notification operation.
Glossary
ATM—Asynchronous Transfer Mode. The international standard for cell relay in which multiple service types (such as voice, video, or data) are conveyed in fixed-length (53-byte) cells. Fixed-length cells allow cell processing to occur in hardware, thereby reducing transit delays. ATM is designed to take advantage of high-speed transmission media, such as E3, SONET, and T3.
downstream-on-demand distribution—A label distribution method in which a downstream label switch router (LSR) sends a binding upstream only if the upstream LSR requests it.
downstream unsolicited distribution—A label distribution method in which labels are dispersed if a downstream label switch router (LSR) needs to establish a new binding with its neighboring upstream LSR. For example, an edge LSR might enable a new interface with another subnet. The LSR then announces to the upstream router a binding to reach this network.
informs—A type of notification message that is more reliable than a conventional trap notification message, because the informs message notification requires acknowledgment, but a trap notification does not.
label—A short, fixed-length data identifier that tells switching nodes how to forward data (packets or cells).
label distribution—The techniques and processes that are used by label switch routers (LSRs) to exchange label binding information for supporting hop-by-hop forwarding along normally routed paths.
LDP—Label Distribution Protocol. The protocol that supports MPLS hop-by-hop forwarding and the distribution of bindings between labels and network prefixes. The Cisco proprietary version of this protocol is the Tag Distribution Protocol (TDP).
LSP—label-switched path. A configured connection between two label switch routers (LSRs) in which label-switching techniques are used for packet forwarding; also a specific path through an MPLS network.
LSR—label switch router. A Multiprotocol Label Switching (MPLS) node that can forward native Layer 3 packets. The LSR forwards a packet based on the value of a label attached to the packet.
MIB—Management Information Base. A database of network management information that is used and maintained by a network management protocol such as Simple Network Management Protocol (SNMP). The value of a MIB object can be changed or retrieved by the use of SNMP commands, usually through a network management system. MIB objects are organized in a tree structure that includes public (standard) and private (proprietary) branches.
MPLS—Multiprotocol Label Switching. A switching method for the forwarding of IP traffic through the use of a label. This label instructs the routers and the switches in the network where to forward the packets based on preestablished IP routing information.
MPLS label distribution—A constraint-based routing algorithm for routing label-switched path (LSP) tunnels.
NMS—network management station. A powerful, well-equipped computer (typically an engineering workstation) that is used by a network administrator to communicate with other devices in the network. An NMS is typically used to manage network resources, gather statistics, and perform a variety of network administration and configuration tasks. In the context of SNMP, an NMS is a device that performs SNMP queries to the SNMP agent of a managed device to retrieve or modify information.
notification—A message sent by a Simple Network Management Protocol (SNMP) agent to a network management station, console, or terminal to indicate that a significant network event has occurred. See also trap.
RSVP—Resource Reservation Protocol. A protocol that supports the reservation of resources across an IP network. Applications running on IP end systems can use RSVP to indicate to other nodes the nature of the packet streams they want to receive by specifying such items as bandwidth, jitter, and maximum burst.
RTR—Response Time Reporter. A tool that allows you to monitor network performance, network resources, and applications by measuring response times and availability.
SNMP—Simple Network Management Protocol. A network management protocol used almost exclusively in TCP/IP networks. SNMP enables a user to monitor and control network devices, manage configurations, collect statistics, monitor performance, and ensure network security.
SNMP communities—Authentication scheme that enables an intelligent network device to validate SNMP requests.
SNMPv2c—Version 2c of the Simple Network Management Protocol. SNMPv2c supports centralized as well as distributed network management strategies and includes improvements in the Structure of Management Information (SMI), protocol operations, management architecture, and security.
SNMPv3—Version 3 of the Simple Network Management Protocol. Interoperable standards-based protocol for network management. SNMPv3 provides secure access to devices by a combination of authenticating and encrypting packets over the network.
TDP—Tag Distribution Protocol. A standard protocol used by MPLS-enabled routers to negotiate the tags (addresses) used for forwarding packets. See also LDP.
TLV—Type-Length-Value. A mechanism used by several routing protocols to carry a variety of attributes. Cisco Discovery Protocol (CDP), Label Discovery Protocol (LDP), and Border Gateway Protocol (BGP) are examples of protocols that use TLVs. BGP uses TLVs to carry attributes such as Network Layer Reachability Information (NLRI), Multiple Exit Discriminator (MED), and local preference.
trap—A message sent by an SNMP agent to a network management station, console, or terminal to indicate that a significant network event has occurred. Traps (notifications) are less reliable than inform requests, because the receiver of the trap does not send an acknowledgment of receipt; furthermore, the sender of the trap cannot determine if the trap was received. See also notification.
VCC—virtual channel connection. A logical circuit, made up of virtual channel links (VCLs), that carries data between two endpoints in an ATM network. Sometimes called a virtual circuit connection.
VCI—virtual channel identifier. A 16-bit field in the header of an ATM cell. The VCI, together with the virtual path identifier (VPI), is used to identify the next network virtual channel link (VCL) as the cell passes through a series of ATM switches on its way to its final destination.
VCL—virtual channel link. The logical connection that exists between two adjacent switches in an ATM network.
VPI—virtual path identifier. An 8-bit field in the header of an ATM cell. The VPI, together with the virtual channel identifier (VCI), is used to identify the next network virtual channel link (VCL) as the cell passes through a series of ATM switches on its way to its final destination.
VPN—Virtual Private Network. A network that enables IP traffic to use tunneling to travel securely over a public TCP/IP network.
VRF—VPN routing and forwarding instance. A VRF consists of an IP routing table, a derived forwarding table, a set of interfaces that use the forwarding table, and a set of rules and routing protocols that determine what goes into the forwarding table. In general, a VRF includes the routing information that defines a customer VPN site that is attached to a PE router.
CCVP, the Cisco logo, and the Cisco Square Bridge logo are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn is a service mark of Cisco Systems, Inc.; and Access Registrar, Aironet, BPX, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Enterprise/Solver, EtherChannel, EtherFast, EtherSwitch, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, iQuick Study, LightStream, Linksys, MeetingPlace, MGX, Networking Academy, Network Registrar, Packet, PIX, ProConnect, ScriptShare, SMARTnet, StackWise, The Fastest Way to Increase Your Internet Quotient, and TransPath are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or Website 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. (0705R)
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.
© 2000-2004, 2006-2007 Cisco Systems, Inc. All rights reserved.
