Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/​go/​cfn. An account on Cisco.com is not required.

Enable MPLS OAM using the mpls oam command on all devices in the MPLS network.

Label Switched Multicast (LSM) can be summarized as Multiprotocol Label Switching (MPLS) technology extensions to support new point-to-multipoint and multipoint-to-multipoint connectivity requirements in a MPLS-enabled network infrastructure. In short, LSM provides scalable and reliable multicast tree building services in an MPLS network, which includes signaling and setup of label-switched multicast distribution trees (MDTs). A focus of LSM is the mapping of ingress multicast traffic onto MDTs and tree optimization mechanisms to minimize LSM traffic loss and reroute capabilities around network failures.

To manage an MPLS network, you must have the ability to monitor label-switched paths (LSPs) and quickly isolate MPLS forwarding problems. You need ways to reliably detect when an LSP fails to deliver user traffic. You can use MPLS LSP ping to verify the LSP that is used to transport packets.

An MPLS echo request is sent through an LSP to validate it. A Time to Live (TTL) expiration or LSP breakage causes the transit device to process the echo request before it gets to the intended destination. The device returns an MPLS echo reply that contains an explanatory reply code to the originator of the echo request.

The successful echo request is processed at the egress of the LSP. The echo reply is sent through an IP path, an MPLS path, or a combination of both back to the originator of the echo request.

The MPLS Embedded Management—LSP Ping Support for MLDP feature extends this diagnostic and troubleshooting ability to the MPLS network and aids in the identification of inconsistencies between the IP and MPLS forwarding tables, inconsistencies in the MPLS control and data plane, and problems with the reply path.

For Multicast Label Distribution Protocol (MLDP), a forwarding equivalence class (FEC) is defined by a root node address, a tree type, and an opaque type or value. The root node is a single point of failure for a Multiprotocol Label Switching (MPLS) label-switched path (LSP), whether the MPLS LSP is point-to-multipoint or multipoint-to-multipoint. The definition of an opaque type or value allows MLDP to remain separate from the applications that define the FECs, hence allowing the MLDP FEC protocol element to be reused to build point-to-multipoint and multipoint-to-multipoint trees for many applications. The application type is identified by the opaque type field.

In order to use MLDP, it is recommended to provide some Operation, Administration, and Maintenance (OAM) functionality. The ping mpls mldp command is one of the basic OAM functions for MLDP to detect failures and isolate a failure point.

MLDP supports injecting LSP ping packets starting from MLDP point-to-multipoint and multipoint-to-multipoint root, midpoint, bud, or leaf nodes. The midpoint device where the sub-LSP signaling is processed and this can be a branch point also. The bud node is a midpoint and tail-end device at the same time. A label switch router (LSR) that is an egress LSR, has one or more directly connected downstream LSRs. In a scenario where the ping is sent from a bud node, the sending device will not receive a copy of the echo request and act as a responder. When an LSP ping is sent from a midpoint in a multipoint-to-multipoint case, there is no existing forwarding entry that replicates to all MPLS neighbors. MLDP builds a forwarding state for a multipoint-to-multipoint tree containing number of neighbors (n) as n point-to-multipoint forwarding entries each with n-1 neighbors. Since there is no equivalent forward entry to reach all leaves, LSP needs to craft and send an MPLS echo request packet to any active upstream neighbors and all downstream neighbors.

The point-to-multipoint ping feature is used to check the connectivity between an ingress label switch router (LSR) and egress LSR along a point-to-multipoint label-switched path (LSP). The ingress LSR sends the point-to-multipoint echo request message along the specified point-to-multipoint LSP. All egress LSRs that receive the point-to-multipoint echo request message from the ingress LSR must send a point-to-multipoint echo reply message to the ingress LSR, according to the reply mode specified in the point-to-multipoint echo request message.

The point-to-multipoint Label Distribution Protocol (LDP) uses LDP to establish multicast LSPs. These LSPs distribute data from a single source (ingress) to one or more destinations (egress) across the network according to the next hops indicated by the routing protocols. Each LSP is identified by a Multiprotocol Label Switching (MPLS) multicast forwarding equivalence class (FEC).

An MPLS echo request packet is sent to a target device through the use of an appropriate label stack associated with the LSP to be validated. Use of the label stack causes the packet to be forwarded over the LSP itself.

An MPLS echo reply is sent in response to an MPLS echo request. The reply is sent as an IP packet and it is forwarded using IP, MPLS, or a combination of both types of switching. The source address of the MPLS echo reply packet is an address obtained from the device generating an echo reply. The destination address is the source address of the device that originated the MPLS echo request packet. The MPLS echo reply destination port is set to the echo request source port.

A multipoint-to-multipoint label-switched path (LSP) allows traffic from multiple leaf (ingress) nodes to be delivered to multiple egress nodes. Only a single copy of the packet will be sent on any link traversed by the multipoint LSP.

A multipoint-to-multipoint LSP is much like a point-to-multipoint LSP in that it consists of a single root node, zero or more transit nodes, and one or more leaf label switch routers (LSRs) acting equally as an ingress or egress LSR. A leaf node participates in the setup of a multipoint-to-multipoint LSP by establishing both a downstream LSP, which is like a point-to-multipoint LSP from the root, and an upstream LSP, which is used to send traffic towards the root and other leaf nodes. Transit nodes support the setup by propagating the upstream and downstream LSP setup towards the root node and installing the necessary Multiprotocol Label Switching (MPLS) forwarding state. The transmission of packets from the root node of a multipoint-to-multipoint LSP to the receivers is identical to that for a point-to-multipoint LSP. Traffic from a leaf node follows the upstream LSP towards the root node and branches downward along the downstream LSP as required to reach other leaf nodes. Mapping traffic to the multipoint-to-multipoint LSP happens at any leaf node.

Jitter is used to reduce the load on the label switch router (LSR) where the ping is performed. By adding a jitter, the replying devices will space their reply time based on a random number between one and the jitter value. Jitter value must be smaller than jitter type, length, value (TLV) received in an echo request or locally configured jitter value.

The jitter field specifies an upper limit for the jitter period that must be applied by a responding node to determine how long to wait before sending an echo reply. You can configure the jitter value to allow the echo replies to be spread out uniformly over the jitter duration. An echo request originator is needed to extend the timeout by the jitter value to account for jittered replies. The responder needs to either limit the maximum number of outstanding jitter waits that can be present or set an upper limit on the maximum jitter time. The jitter value is specified in milliseconds. The range is from 1 to 2147483647, and the default is 200.

The configured jitter value is also used by the responder node. If the configured jitter value is smaller than the received jitter TLV, then a reply is generated after a random time between a configured jitter value. If the configured jitter value is larger than the received jitter TLV, then the reply is generated after a random time between one and the received jitter TLV.

Note	An echo jitter TLV is only applicable on an echo request message. If it is present on an echo reply message, it is ignored.

1.    enable


2.    configure terminal


3.    mpls oam


4.    echo jitter jitter-value


5.    end

Device> enable

Device# configure terminal

Device(config)# mpls oam

Device(config-mpls)# echo jitter 100

Device(config-mpls)# end