Downloads |
Table Of Contents
MPLS Label Distribution Protocol MIB
Information About MPLS LDP MIB
Benefits of Using MPLS LDP MIB
Description of MPLS LDP MIB Elements
MPLS LDP MIB Object Categories
Events Generating MPLS LDP MIB Notifications
Configuring the Router to Send SNMP Traps
Verifying the Status of the SNMP Agent
Configuration Examples for MPLS LDP MIB
snmp-server enable traps mpls ldp
MPLS Label Distribution Protocol MIB
First Published: November 13, 2000Last Updated: June 29, 2007This document describes the Simple Network Management Protocol (SNMP) agent support provided in Cisco IOS software for the MPLS Label Distribution Protocol Management Information Base (MPLS LDP MIB) on applicable Cisco IOS hardware platforms.
History for MPLS LDP MIB 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
•
Restrictions for MPLS LDP MIB
•
•
•
Restrictions for MPLS LDP MIB
The MPLS LDP MIB is limited to read-only (RO) permission for MIB objects, except for MIB object mplsLdpSessionUpDownTrapEnable, which is writable by the SNMP agent.
Setting this object to a value of true enables both the mplsLdpSessionUp and mplsLdpSessionDown notifications on the Label Switched Router (LSR); conversely, setting this object to a value of false disables both of these notifications. The value of the mplsLdpSessionUpDownTrapEnable object is stored in NVRAM on the MPLS LDP MIB host.
For a description of notification events, see the "Events Generating MPLS LDP MIB Notifications" 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.
Information About MPLS LDP MIB
Before enabling the MPLS LDP MIB, you should understand the following concepts:
•
•
•
•
MPLS LDP Overview
Multiprotocol Label Switching (MPLS) is a packet forwarding technology that uses a short, fixed-length value called a label in packets to determine the next hop for packet transport through an MPLS network by means of label switching 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 Label Distribution Protocol (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 negotiates basic operating procedures between them. 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. An LDP function then creates an active LDP session between the two LSRs to effect the exchange of label binding information. The result of this process, when carried to completion with respect to all the LSRs in an MPLS network, 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.
MPLS LDP MIB Overview
The MPLS LDP MIB has been implemented to enable standard, SNMP-based network management of the label switching features in Cisco IOS. 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 embodies a layered structure that is compatible with Cisco IOS 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.
By means of an SNMP agent, you can access MPLS LDP MIB objects using standard SNMP get operations to accomplish a variety of network management tasks. All the objects in the MPLS LDP MIB follow the conventions defined in the Internet Engineering Task Force (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 continually evolving toward the status of a standard. Accordingly, the MPLS LDP MIB will be implemented in a manner that tracks the evolution of this IETF document.
Slight differences that exist between the IETF draft MIB and the implementation of equivalent functions in Cisco IOS require some minor translations between the MPLS LDP MIB objects and the internal data structures of Cisco IOS. Such translations are accomplished by the SNMP agent, which runs in the background on the NMS workstation as a low priority process.
The MPLS LDP MIB provides the following functions:
•
•
•
•
The structure of the MPLS LDP MIB conforms to Abstract Syntax Notation One (ASN.1), thereby forming 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 operations. Similarly, you can traverse and display information in the MIB by means of SNMP GETNEXT operations.
Note
ciscoExperiment 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 deprecate all objects in the MIB under the Cisco Experimental OID and reposition the objects under the IANA Experimental OID.
Benefits of Using MPLS LDP MIB
The MPLS LDP MIB provides the following benefits:
•
•
–
–
–
–
–
–
•
–
–
•
•
–
–
–
–
–
•
–
–
–
–
–
Description of MPLS LDP MIB Elements
The MPLS LDP MIB includes the following elements:
•
•
•
•
A Hello adjacency constitutes the working context between two LSRs in an MPLS network. The adjacency is used for the exchange of label binding information.
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 within, reflecting the current state of MPLS LDP operations in the network. This network management information database is accessible 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 having the object name mplsLdpEntityLdpId. This object consists of the router ID (four octets) and an interface number (two octets). The router ID encodes an IP address assigned to the LSR. The interface number identifies a specific label space available within the LSR.
An LDP entity represents a label space that is targeted for distribution to an LDP peer. In the case of an interface-specific LDP entity, the label space is distributed to a single LDP peer by means of a single LDP session.
Conversely, a platform-wide LDP entity can be associated with multiple LDP peers. In this case, the label space is distributed to multiple LDP peers by means of a separate LDP session pertaining to each peer.
LDP Peers
If an LSR has a label space to advertise to another LSR, or to multiple LSRs, there would be one LDP session for each LSR receiving the label space information. The receiver of the label space information is referred to as an LDP peer.
Per-interface label spaces are advertised to a single LDP peer by means of a single LDP session. Per-platform label spaces are advertised to multiple LDP peers by means of multiple LDP sessions.
The possible existence of multiple per-platform LDP peers dictates not only that an LDP entity be identified by its unique LDP tag, but also by its LDP index. In this case, the label space is the same, but the LDP Index differentiates the LDP session over which the label space is distributed to multiple LDP peers.
LDP Sessions
LDP sessions between local entities and remote peers distribute label spaces. There is always a one-to-one correspondence between an LDP peer and an LDP session. A single LDP session is a label distribution protocol instance that communicates across one or more network links with a single LDP peer. In the case of a platform-wide local LDP entity, there may be multiple LDP sessions and a corresponding number of remote LDP peers.
LDP Hello Adjacencies
An LDP session is an LDP instance that communicates across one or more network links to a peer protocol instance. An LDP Hello adjacency exists for each link on which LDP runs. Multiple link adjacencies exist whenever there are multiple links to the same LDP peer. In the case of a platform-wide label space, for example, there is a separate LDP peer/LDP session relationship for each LSR to which a label space may be advertised.
MPLS LDP MIB Object Categories
The MPLS LDP MIB contains numerous definitions of managed objects for the MPLS Label Distribution Protocol, as defined in the IETF draft document entitled draft-ietf-mpls-ldp-08.txt.
The managed objects in the MPLS LDP MIB are structured according to the following categories:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Events Generating MPLS LDP MIB Notifications
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 that announce LDP status transitions and event notifications include the following:
•
•
The up and down notifications indicate the last active interface in the LDP session.
•
The value of the path vector limit can range from 0 to 255; a value of 0 indicates that loop detection is off; any value other than 0 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 a dissimilar path vector limits.
•
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.
In general, 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.
Operationally, the LSRs whose label ranges do not overlap continue their attempt to create an LDP session between themselves after the eight retry limit is exceeded. In such cases, the LDP threshold exceeded notification alerts the network administrator to the existence of a condition in the network that may 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:
–
–
–
–
How to Configure MPLS LDP MIB
This section describes the tasks for configuring the MPLS LDP MIB:
•
•
•
Enabling the SNMP Agent
By default, the SNMP agent for the MPLS LDP MIB is disabled. To enable the SNMP agent on the host NMS workstation, perform the following procedure.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
DETAILED STEPS
Configuring the Router to Send SNMP Traps
Perform this task to configure the router to send traps to a host.
The snmp-server host command specifies which hosts receive traps. The snmp-server enable traps command globally enables the trap production mechanism for the specified traps.
For a host to receive a trap, an snmp-server host command must be configured for that host, and, generally, the trap must be enabled globally through the snmp-server enable traps command.
Note
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Verifying the Status of the SNMP Agent
To verify that the SNMP agent has been enabled on the host NMS workstation, perform the following steps.
SUMMARY STEPS
1.
2.
DETAILED STEPS
Step 1
Use this command to enable SNMP on the host NMS. For example:
Router# enableStep 2
Use this command to display the running configuration on the host NMS and examine the output for SNMP information. For example:
Router# show running-config...snmp-server community public ROsnmp-server community private ROThe presence of any snmp-server statement in the output that takes the form shown above verifies that the SNMP agent has been enabled on the host NMS workstation.
Configuration Examples for MPLS LDP MIB
The following example shows how to enable an SNMP agent on the host NMS:
Router# config terminalRouter(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 with 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 the session up and session down LDP notifications:
Router(config)# snmp-server enable traps mpls ldp session-upRouter(config)# snmp-server enable traps mpls ldp session-downAdditional References
The following sections provide references related to the MPLS LDP MIB.
Related Documents
MPLS LDP configuration tasks
•
MPLS LDP commands: complete command syntax, command mode, command history, defaults, usage guidelines, and examples
•
•
•
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.
•
snmp-server enable traps mpls ldp
To enable the sending of Multiprotocol Label Switching (MPLS) Label Distribution Protocol (LDP) SNMP notifications, use the snmp-server enable traps mpls ldp command in global configuration mode. To disable the sending of MPLS LDP notifications, use the no form of this command.
snmp-server enable traps mpls ldp [session-down | session-up | pv-limit | threshold]
no snmp-server enable traps mpls ldp [session-down | session-up | pv-limit | threshold]
Syntax Description
Command Default
The sending of SNMP notifications is disabled. If you do not specify an optional keyword, all four types of LDP notifications are enabled on the label switching router (LSR).
Command Modes
Global configuration (config)
Command History
Usage Guidelines
The MPLS LDP pv-limit (mplsLdpPathVectorLimitMismatch) notification provides a warning message that can be sent to the network management station (NMS) when two routers engaged in LDP operations have a dissimilar path vector limits. We recommend that all LDP-enabled routers in the network be configured with the same path vector limits.
The value of the path vector limit can range from 0 to 255; a value of 0 indicates that loop detection is off; any value other than 0 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.
The MPLS LDP threshold (mplsLdpFailedInitSessionThresholdExceeded) notification object provides a warning message that can be sent to a NMS when a local Label Switching Router (LSP) and an adjacent Label Distribution Protocol (LDP) peer attempt to set up an LDP session between them, but fail to do so after a specified number of attempts. The default number of attempts is 8. This default value is implemented in Cisco IOS and cannot be changed using either the CLI or an SNMP agent.
In general, 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 will try eight times to create an LDP session between themselves before the mplsLdpFailedInitSessionThresholdExceeded notification is generated.
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 to the existence of a condition in the network that may 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 these incompatibilities, for example, are the following:
•
•
•
•
The snmp-server enable traps mpls ldp command is used with the snmp-server host command. Use the snmp-server host command to specify which host or hosts receive SNMP notifications. To send SNMP notifications, you must configure at least one snmp-server host command.
If the session-down keyword is used, a session-down message is generated when an LDP session between the router and its adjacent LDP peer is terminated.
If the session-up keyword is used, a message is generated when the router establishes an LDP session with another LDP entity (an adjacent LDP peer in the network).
If the pv-limit keyword is used, a message is generated when the router establishes an LDP session with its adjacent peer LSR, but the two LSRs have dissimilar path vector limits.
If the threshold keyword is used, a message is generated after eight failed attempts to establish an LDP session between the router and an LDP peer. The failures can be caused by any type of incompatibility between the devices.
Examples
In the following example, LDP-specific informs are enabled and will be sent to the host myhost.cisco.com through use of community string defined as public:
Router(config)# snmp-server enable traps mpls ldpRouter(config)# snmp-server host myhost.cisco.com informs version 2c public mpls-ldpRelated Commands
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-2002, 2004-2007 Cisco Systems, Inc. All rights reserved.
