MPLS Label Distribution Protocol MIB

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.

The MPLS LDP MIB has been implemented to enable standard, SNMP-based network management of the label switching features in Cisco 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 embodies a layered structure that is compatible with Cisco 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 software.

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 software require some minor translations between the MPLS LDP MIB objects and the internal data structures of Cisco software. 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 MPLS LDP MIB can generate and send event notification messages to signal changes in the status of LDP sessions.
• You can enable and disable event notification messages by using SNMP CLI commands.
• You can specify the name or the IP address of an NMS workstation where event notification messages are sent to serve network administrative and management purposes.
• You can store the configuration pertaining to an event notification message in nonvolatile memory (NVRAM) of the NMS.

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

Because the MPLS LDP MIB was not given an Internet Assigned Numbers Authority (IANA) Experimental OID at the time of its implementation, Cisco chose to implement the MIB under the Cisco Experimental OID number: 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.

The MPLS LDP MIB provides the following benefits:

• Establishing LDP sessions between peer devices in an MPLS network
• Retrieving MIB parameters relating to the operation of LDP entities, such as:
  • Well-known LDP discovery port
  • Maximum transmission unit (MTU)
  • Proposed KeepAlive timer interval
  • Loop detection
  • Session establishment thresholds
  • Range of VPI/VCI pairs to be used in forming labels
• Gathering statistics related to LDP operations, such as:
  • Count of the total established sessions for an LDP entity
  • Count of the total attempted sessions for an LDP entity
• Monitoring the time remaining for Hello adjacencies
• Monitoring the characteristics and status of LDP peers, such as:
  • Type of internetwork layer address of LDP peers
  • Actual internetwork layer address of LDP peers
  • Default MTU of the LDP peer
  • Number of seconds the LDP peer proposes as the value of the KeepAlive interval
  • Establishment of VPI/VCI label ranges to be made known to LDP peers
• Monitoring the characteristics and status of LDP sessions, such as:
  • Determining the LDP version being used by the LDP session
  • Determining the KeepAlive hold time remaining for an LDP session
  • Determining the state of an LDP session (whether the session is active or not)
  • Determining the range of VPI/VCI pairs to be used by an LDP session
  • Determining the last active interface of an LDP session

The MPLS LDP MIB includes the following elements:

• LDP entity--Relates to an instance of LDP for purposes of exchanging label spaces.
• LDP peer--Refers to a remote LDP entity (that is, a nonlocal LSR).
• LDP session--Refers to an active LDP process between a local LSR and a remote LDP peer.
• Hello adjacency--Refers to the result of an LDP discovery process which affirms the state of two LSRs in an MPLS network as being adjacent to each other (that is, as being LDP peers).

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:

• Retrieving MPLS LDP MIB parameters pertaining to LDP operations
• Monitoring the characteristics and the status of LDP peers
• Monitoring the status of LDP sessions between LDP peers
• Monitoring Hello adjacencies in the network
• Gathering statistics regarding LDP sessions

• LDP Entities
  
• LDP Peers
  
• LDP Sessions
  
• LDP Hello Adjacencies
  

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:

• MPLS LDP Textual Conventions
• MPLS LDP Objects
• MPLS Label Distribution Protocol Entity Objects
• LDP Entity Objects for Generic Labels
• LDP Entity Objects for ATM
• MPLS LDP Entity Configured ATM Label Range Table
• MPLS Entity Objects for Frame Relay
• Frame Relay Label Range Components
• MPLS LDP Entity Statistics Table
• MPLS LDP Entity Peer Table
• MPLS LDP Hello Adjacency Table
• MPLS LDP Sessions Table
• MPLS LDP ATM Session Information
• MPLS LDP Frame Relay Session Information
• MPLS LDP Session Statistics Table
• Address Message/Address Withdraw Message Information
• MPLS LDP LIB Table
• MPLS LDP FEC Table
• Notifications
• Module Conformance Statement

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

The MPLS LDP MIB objects that announce LDP status transitions and event notifications include the following:

• mplsLdpSessionUp--This message is generated when an LDP entity (a local LSR) establishes an LDP session with another LDP entity (an adjacent LDP peer in the network).
• mplsLdpSessionDown--This message is generated when an LDP session between a local LSR and its adjacent LDP peer is terminated.

The up and down notifications indicate the last active interface in the LDP session.

• mplsLdpPathVectorLimitMismatch--This message is generated when a local LSR establishes an LDP session with its adjacent peer LSR, but the two LSRs have dissimilar 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.

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.

• mplsLdpFailedInitSessionThresholdExceeded--This message is generated when a local LSR and an adjacent 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 software and cannot be changed by either the CLI or an SNMP agent.

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:

• • Nonoverlapping ATM VPI/VCI ranges (as noted above) or nonoverlapping Frame-Relay DLCI ranges between LSRs attempting to set up an LDP session
  • Unsupported label distribution method
  • Dissimilar protocol data unit (PDU) sizes
  • Dissimilar LDP feature support

1.   enable

2.   show running-config

3.   configure terminal

4.   snmp-server community string [view view-name] [ro | rw] [acl-number]

5.   do copy running-config startup-config

6.   exit

7.   show running-config [interface | map-class]

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	Although you can set the community-string argument using the snmp-server host command by itself, we recommend that you define this string using the snmp-server community command prior to using the snmp-server host command.

1.    enable

2.    configure terminal

3.    snmp-server host host-addr [traps | informs] [version {1 | 2c | 3 [auth | noauth | priv]}] community-string [udp-port port] [notification-type] [vrf vrf-name]

4.    snmp-server enable traps mpls ldp [session-down] [session-up] [pv-limit] [threshold]

5.    exit

1.    enable

2.    show running-config

3.    exit

Router> enable
Router#

Router# show running-config
.
.
.
snmp-server community public RO
snmp-server community private RO

Router# exit
Router>