MPLS EM: MPLS LSP Multipath Tree Trace
Available Languages
Table Of Contents
MPLS EM—MPLS LSP Multipath Tree Trace
Prerequisites for MPLS EM—MPLS LSP Multipath Tree Trace
Restrictions for MPLS EM—MPLS LSP Multipath Tree Trace
Information About MPLS EM—MPLS LSP Multipath Tree Trace
Overview of MPLS LSP Multipath Tree Trace
Discovery of IPv4 Load Balancing Paths by MPLS LSP Multipath Tree Trace
Echo Reply Return Codes Sent by the Router Processing Multipath LSP Tree Trace
How to Configure MPLS EM—MPLS LSP Multipath Tree Trace
Customizing the Default Behavior of MPLS Echo Packets
MPLS Embedded Management Configuration
Configuring MPLS LSP Multipath Tree Trace
Discovering IPv4 Load Balancing Paths Using MPLS LSP Multipath Tree Trace
MPLS Multipath LSP Traceroute Path Discovery
Monitoring LSP Paths Discovered by MPLS LSP Multipath Tree Trace Using MPLS LSP Traceroute
Using DSCP to Request a Specific Class of Service in an Echo Reply
Controlling How a Responding Router Replies to an MPLS Echo Request
Reply Modes for an MPLS LSP Multipath Tree Trace Echo Request Response
Specifying the Output Interface for Echo Packets Leaving a Router for MPLS LSP Multipath Tree Trace
Echo Request Output Interface Control
Setting the Pace of MPLS Echo Request Packet Transmission for MPLS LSP Multipath Tree Trace
Explicit Null Label Shimming Tests LSP Ability to Carry MPLS Traffic
Requesting that a Transit Router Validate the Target FEC Stack for MPLS LSP Multipath Tree Trace
Setting the Number of Timeout Attempts for MPLS LSP Multipath Tree Trace
Configuration Examples for MPLS EM—MPLS LSP Multipath Tree Trace
Customizing the Default Behavior of MPLS Echo Packets: Example
Configuring MPLS LSP Multipath Tree Trace: Example
Discovering IPv4 Load Balancing Paths Using MPLS LSP Multipath Tree Trace: Example
Using DSCP to Request a Specific Class of Service in an Echo Reply: Example
Controlling How a Responding Router Replies to an MPLS Echo Request: Example
Setting the Pace of MPLS Echo Request Packet Transmission for MPLS LSP Multipath Tree Trace: Example
Setting the Number of Timeout Attempts for MPLS LSP Multipath Tree Trace: Example
Feature Information for MPLS EM—MPLS LSP Multipath Tree Trace
MPLS EM—MPLS LSP Multipath Tree Trace
First Published: December 4, 2006Last Updated: February 19, 2007The MPLS EM—MPLS LSP Multipath Tree Trace feature provides the means to discover all possible equal-cost multipath (ECMP) routing paths of a label switched path (LSP) between an egress and ingress router. Once discovered, these paths can be retested on a periodic basis using Multiprotocol Label Switching (MPLS) LSP ping or traceroute. This feature is an extension to the MPLS LSP traceroute functionality for the tracing of IPv4 LSPs.
You can use the MPLS Embedded Management (MPLS EM)—MPLS LSP Multipath Tree Trace feature to discover all paths for an IPv4 LSP.
This implementation of the MPLS EM—MPLS LSP Multipath Tree Trace feature is based on RFC 4379, Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures.
For information on the use of MPLS LSP ping and traceroute, see the MPLS Embedded Management—LSP Ping for LDP feature module.
Cisco IOS MPLS Embedded Management (EM) is a set of standards and value-added services that facilitate the deployment, operation, administration, and management of MPLS-based networks in line with the fault, configuration, accounting, performance, and security (FCAPS) model.
Finding Feature Information in This Module
Your Cisco IOS software release may not support all of the features documented in this module. To reach links to specific feature documentation in this module and to see a list of the releases in which each feature is supported, use the "Feature Information for MPLS EM—MPLS LSP Multipath Tree Trace" section.
Finding Support Information for Platforms and Cisco IOS 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 EM—MPLS LSP Multipath Tree Trace
•
•
•
•
•
Prerequisites for MPLS EM—MPLS LSP Multipath Tree Trace
The following are prerequisites for using the MPLS EM—MPLS LSP Multipath Tree Trace feature:
•
•
•
–
–
–
•
Restrictions for MPLS EM—MPLS LSP Multipath Tree Trace
•
•
•
Information About MPLS EM—MPLS LSP Multipath Tree Trace
Before using the MPLS EM—MPLS LSP Multipath Tree Trace feature, you need an understanding of the following concepts:
•
•
•
Overview of MPLS LSP Multipath Tree Trace
As the number of MPLS deployments increases, the number of traffic types the MPLS networks carry could increase. In addition, load balancing on label switch routers (LSRs) in the MPLS network provides alternate paths for carrying MPLS traffic to a target router. The ability of service providers to monitor LSPs and quickly isolate MPLS forwarding problems is critical to their ability to offer services.
Prior to the release of the MPLS EM—MPLS LSP Multipath Tree Trace feature no automated way existed to discover all paths between provider edge (PE) routers. Troubleshooting forwarding problems between PEs was cumbersome.
The release of the MPLS EM—MPLS LSP Multipath Tree Trace feature provides an automated way to discover all paths from the ingress PE router to the egress PE router in multivendor networks that use IPv4 load balancing at the transit routers. Once the PE-to-PE paths are discovered, use MPLS LSP ping and MPLS LSP traceroute to periodically test them.
The MPLS EM—MPLS LSP Multipath Tree Trace feature requires the Cisco RFC-compliant implementation which is based on RFC 4379. If you do not have a Cisco IOS release that supports RFC 4379, MPLS LSP multipath tree trace does not operate to discover all PE-to-PE paths.
Discovery of IPv4 Load Balancing Paths by MPLS LSP Multipath Tree Trace
IPv4 load balancing at a transit router is based on the incoming label stack and the source and destination addresses in the IP header. The outgoing label stack and IP header source address remain constant for each branch being traced.
When you execute MPLS LSP multipath tree trace on the source LSR, the router needs to find the set of IP header destination addresses to use all possible output paths. The source LSR starts path discovery by sending a transit router a bitmap in an MPLS echo request. The transit router returns information in an MPLS echo request that contains subsets of the bitmap in a downstream map (DS Map) in an echo reply. The source router can then use the information in the echo reply to interrogate the next router. The source router interrogates each successive router until it finds one bitmap setting that is common to all routers along the path. The router uses TTL expiry to interrogate the routers to find the common bits.
For example, you could start path discovery by entering the following command at the source router:
Source_LSR# trace mpls multipath ipv4 10.131.101.129/32 hashkey ipv4 bitmap 16This command sets the IP address of the target router as 10/131.101.192 255.255.255.255 and configures:
•
•
If you entered the trace mpls multipath ipv4 10.131.101.129/32 command, MPLS LSP multipath tree trace uses the default hash type of 8 or IPv4 and a default bitmap size of 32. Your choice of a bitmap size depends on the number of routes in your network. If you have a large number of routes, you might need to use a larger bitmap size.
Echo Reply Return Codes Sent by the Router Processing Multipath LSP Tree Trace
Table 1 describes the characters that the router processing a multipath LSP tree trace packet returns to the sender about the failure or success of the request.
How to Configure MPLS EM—MPLS LSP Multipath Tree Trace
This section contains the following tasks:
•
•
•
•
•
•
•
•
•
•
Customizing the Default Behavior of MPLS Echo Packets
Perform the following task to customize the default behavior of MPLS echo packets. You might need to customize the default echo packet encoding and decoding behavior to allow later implementations of the Detecting MPLS Data Plane Failures (RFC 4379) to be deployed in networks running earlier versions of the draft.
MPLS Embedded Management Configuration
Before using the ping mpls, trace mpls, or trace mpls multipath command, you should consider ensuring that the router is configured to encode and decode MPLS echo packets in a format that all receiving routers in the network can understand.
LSP ping drafts after Version 3 (draft-ietf-mpls-ping-03) have undergone numerous TLV format changes, but the implementations based on different drafts might not interoperate properly.
To allow later Cisco implementations to interoperate with draft Version 3 Cisco and non-Cisco implementations, a global configuration mode (MPLS OAM configuration) allows you to encode and decode echo packets in formats specified by draft Version 3 implementations.
Unless configured otherwise, a Cisco implementation encodes and decodes echo requests assuming the version on which the Internet Engineering Task Force (IETF) implementation is based.
To allow for seamless interoperability with earlier Revision 1 and 3 images, you can use MPLS Operation, Administration, and Maintenance (OAM) configuration mode parameters to force the default behavior of the Revision 4 images to be compliant or compatible in networks with Revision 1 or Revision 3 images.
To prevent failures reported by the replying router due to TLV version issues, you should configure all routers in the core. Encode and decode MPLS echo packets in the same draft version. For example, if the network is running RFC 4379 (Cisco Revision 4) implementations but one router is capable of only Version 3 (Cisco Revision 3), configure all routers in the network to operate in Revision 3 mode.
Cisco Revision 4 is the default version. The default version is the latest LSP Ping version supported by the image on the router.
Prerequisites
MPLS LSP Multipath Tree Trace requires RFC 4379 (Revision 4).
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
DETAILED STEPS
Configuring MPLS LSP Multipath Tree Trace
Perform the following task to configure MPLS multipath LSP traceroute. This task helps discover all LSPs from an egress router to an ingress router.
Prerequisites
Cisco LSP ping or traceroute implementations based on draft-ietf-mpls-lsp-ping-11 are capable in some cases of detecting the formatting of the sender of an MPLS echo request. However, certain cases exist in which an echo request or echo reply might not contain the Cisco extension TLV. To avoid complications due to certain cases where the echo packets are decoded assuming the wrong TLV formats, configure all routers in the network to operate in the same mode.
For an MPLS LSP multipath tree trace to be successful, the implementation in your routers must support RFC 4379 on all core routers.
If all routers in the network support FRC-4379 and another vendor's implementation exists that is not capable of properly handling Cisco's vendor TLV, the routers supporting the RFC-compliant or later configuration must include commands to disable the Cisco vendor TLV extensions.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
DETAILED STEPS
Discovering IPv4 Load Balancing Paths Using MPLS LSP Multipath Tree Trace
Perform the following task to discover IPv4 load balancing paths using MPLS LSP multipath tree trace.
MPLS Multipath LSP Traceroute Path Discovery
A Cisco router load balances MPLS packets based on the incoming label stack and the source and destination addresses in the IP header. The outgoing label stack and IP header source address remain constant for each path being traced. The router needs to find the set of IP header destination addresses to use all possible output paths. This might require exhaustive searching of the 127.x.y.z/8 address space. Once you discover all paths from the source LSR to the target or destination LSR with MPLS LSP multipath tree trace, you can use MPLS LSP traceroute to monitor these paths.
Figure 1 shows how MPLS LSP multipath tree trace discovers LSP paths in a sample network. In Figure 1, the bitmap size is 16 and the numbers 0 to 15 represent the bitmapped addresses that MPLS LSP multipath tree trace uses to discover all the paths from the source LSR R-101 to the target LSR R-150. Figure 1 illustrates how the trace mpls multipath command discovers all LSP paths in the sample network.
Figure 1 MPLS LSP Multipath Tree Trace Path Discovery in a Sample Network
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
DETAILED STEPS
Monitoring LSP Paths Discovered by MPLS LSP Multipath Tree Trace Using MPLS LSP Traceroute
Perform the following task to monitor LSP paths discovered by MPLS LSP multipath tree trace using MPLS LSP traceroute. You can take output directly from the trace mpls multipath command and add it to a trace mpls command periodically to verify that the path is still operating.
Figure 2 shows the mapping of the output of a trace mpls multipath command to a trace mpls command.
Figure 2 Mapping of trace mpls multipath Command Output to a trace mpls Command
Each path you discover with MPLS LSP Multipath Tree Trace can be tested in this manner periodically to monitor the LSP paths in your network.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
Step 1
Use this command to enable privileged EXEC mode. Enter your password if prompted. For example:
Router> enableRouter#Step 2
Use this command to discover all MPLS LSPs from an egress router to an ingress router. For example:
Router# trace mpls multipath ipv4 10.1.1.150/32 hashkey ipv4 bitmap 16Starting LSP Multipath Traceroute for 10.1.1.150/32Codes: '!' - success, 'Q' - request not sent, '.' - timeout,'L' - labeled output interface, 'B' - unlabeled output interface,'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,'P' - no rx intf label prot, 'p' - premature termination of LSP,'R' - transit router, 'I' - unknown upstream index,'X' - unknown return code, 'x' - return code 0Type escape sequence to abort.LLLL!Path 0 found,output interface Et0/0 source 10.1.111.101 destination 127.0.0.0LLL!Path 1 found,output interface Et0/0 source 10.1.111.101 destination 127.0.0.1L!Path 2 found,output interface Et0/0 source 10.1.111.101 destination 127.0.0.5LL!Path 3 found,output interface Et0/0 source 10.1.111.101 destination 127.0.0.7Paths (found/broken/unexplored) (4/0/0)Echo Request (sent/fail) (14/0)Echo Reply (received/timeout) (14/0)Total Time Elapsed 468 msThe output of the trace mpls multipath command in the example shows the result of path discovery with MPLS LSP multipath tree trace. In this example, the command sets the bitmap size to 16. Path discovery starts by MPLS LSP multipath tree trace using 16 bitmapped addresses as it locates LSP paths from the source router to the target router with prefix and mask 10.1.1.150/32. MPLS LSP multipath tree trace starts using the 127.x.y.z/8 address space with 127.0.0.1.
Step 3
Use this command to verify that the paths discovered when you entered a trace mpls multipath command are still operating. For example, the output for Path 0 in the previous trace mpls multipath command in Step 2 is:
output interface Et0/0 source 10.1.111.101 destination 127.0.0.0If you put the output for path 0 in the trace mpls command, you see the following results:
Router# trace mpls ipv4 10.1.1.150/32 output interface Et0/0 source 10.1.111.101 destination 127.0.0.0Tracing MPLS Label Switched Path to 10.1.1.150/32, timeout is 2 secondsCodes: '!' - success, 'Q' - request not sent, '.' - timeout,'L' - labeled output interface, 'B' - unlabeled output interface,'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,'P' - no rx intf label prot, 'p' - premature termination of LSP,'R' - transit router, 'I' - unknown upstream index,'X' - unknown return code, 'x' - return code 0Type escape sequence to abort.0 10.1.111.101 MRU 1500 [Labels: 33 Exp: 0]L 1 10.1.111.111 MRU 1500 [Labels: 34 Exp: 0] 40 msL 2 10.2.121.121 MRU 1500 [Labels: 34 Exp: 0] 32 msL 3 10.3.132.132 MRU 1500 [Labels: 32 Exp: 0] 16 msL 4 10.4.140.240 MRU 1504 [Labels: implicit-null Exp: 0] 20 ms! 5 10.5.150.50 20 msYou can take output directly from the trace mpls multipath command and add it to a trace mpls command periodically to verify that the path is still operating (see Figure 2).
Step 4
Use this command to exit to user EXEC mode. for example:
Router# exitRouter>
Using DSCP to Request a Specific Class of Service in an Echo Reply
For Cisco IOS Release 12.2(27)SXE, Cisco added a reply differentiated services code point (DSCP) option that lets you request a specific class of service (CoS) in an echo reply.
The reply DSCP option is supported in the experimental mode for IETF draft-ietf-mpls-lsp-ping-03.txt. Cisco implemented a vendor-specific extension for the reply DSCP option rather than using a Reply TOS TLV. A Reply TOS TLV serves the same purpose as the reply dscp command in IETF draft-ietf-mpls-lsp-ping-11.txt. This draft provides a standardized method of controlling the reply DSCP.
Note
To use DSCP to request a specific CoS in an echo reply, perform the following steps.
SUMMARY STEPS
1.
2.
3.
DETAILED STEPS
Controlling How a Responding Router Replies to an MPLS Echo Request
This section contains information about and instructions for controlling how a responding router replies to an MPLS echo request. You should understand the following information before you configure a reply mode for the echo request response:
•
Reply Modes for an MPLS LSP Multipath Tree Trace Echo Request Response
The reply mode controls how a responding router replies to an MPLS echo request sent by a trace mpls multipath command. There are two reply modes for an echo request packet:
•
•
Note
IPv4 UDP Reply Mode
The IPv4 UDP reply mode is the most common reply mode used with a trace mpls multipath command when you want to periodically poll the integrity of an LSP. With this option, you do not have explicit control over whether the packet traverses IP or MPLS hops to reach the originator of the MPLS echo request. If the originating (headend) router fails to receive a reply to an MPLS echo request when you use the reply mode ipv4 keywords, use the reply mode router-alert keywords.
Router-alert Reply Mode
The router-alert reply mode adds the router alert option to the IP header. When an IP packet that contains an IP router alert option in its IP header or an MPLS packet with a router alert label as its outermost label arrives at a router, the router punts (redirects) the packet to the Route Processor (RP) process level for handling. This forces the RP of each intermediate router to specifically handle the packet at each intermediate hop as it moves back to the destination. Hardware and line-card forwarding inconsistencies are thus bypassed. Router-alert reply mode is slower than IPv4 mode because the reply requires process-level RP handling at each hop.
Table 2 describes how an incoming IP packet with an IP router alert is handled by the router switching path processes when the outgoing packet is an IP packet or an MPLS packet. It also describes how an MPLS packet with a router alert option is handled by the router switching path processes when the outgoing packet is an IP packet or an MPLS packet.
SUMMARY STEPS
1.
2.
3.
DETAILED STEPS
Specifying the Output Interface for Echo Packets Leaving a Router for MPLS LSP Multipath Tree Trace
Perform the following task to specify the output interface for echo packets leaving a router for the MPLS LSP Multipath Tree Trace feature. You can use this task to test the LSPs reachable through a given interface.
Echo Request Output Interface Control
You can control the interface through which packets leave a router. Path output information is used as input to LSP ping and traceroute.
The echo request output interface control feature allows you to force echo packets through the paths that perform detailed debugging or characterizing of the LSP. This feature is useful if a PE router connects to an MPLS cloud and there are broken links. You can direct traffic through a certain link. The feature also is helpful for troubleshooting network problems.
SUMMARY STEPS
1.
2.
3.
DETAILED STEPS
Setting the Pace of MPLS Echo Request Packet Transmission for MPLS LSP Multipath Tree Trace
Perform the following task to set the pace of MPLS echo request packet transmission for the MPLS LSP Multipath Tree Trace feature. Echo request traffic pacing allows you to set the pace of the transmission of packets so that the receiving router does not drop packets. If you have a large amount of traffic on your network you might increase the size of the interval to help ensure that the receiving router does not drop packets.
SUMMARY STEPS
1.
2.
3.
DETAILED STEPS
Enabling MPLS LSP Multipath Tree Trace to Detect LSP Breakages Caused by an Interface that Lacks an MPLS Configuration
Perform the following task to enable MPLS LSP multipath tree trace to detect LSP breakages caused by an interface that lacks an MPLS configuration. If an interface is not configured for MPLS, then it cannot forward MPLS packets.
Explicit Null Label Shimming Tests LSP Ability to Carry MPLS Traffic
For an MPLS LSP multipath tree trace of LSPs carrying IPv4 FECs, you can force an explicit null label to be added to the MPLS label stack even though the label was unsolicited. This allows MPLS LSP multipath tree trace to detect LSP breakages caused by an interface that is not configured for MPLS. MPLS LSP multipath tree trace does not report that an LSP is functioning when it is unable to send MPLS traffic.
An explicit null label is added to an MPLS label stack if MPLS echo request packets are forwarded from an interface not configured for MPLS that is directly connected to the destination of the MPLS LSP multipath tree trace or if the IP TTL value for the MPLS echo request packets is set to 1.
When you enter a trace mpls multipath command, you are looking for all MPLS LSP paths from an egress router to an ingress router. Failure at output interfaces that are not configured for MPLS at the penultimate hop are not detected. Explicit-null shimming allows you to test an LSP's ability to carry MPLS traffic.
SUMMARY STEPS
1.
2.
3.
DETAILED STEP
Requesting that a Transit Router Validate the Target FEC Stack for MPLS LSP Multipath Tree Trace
Perform the following task to request that a transit router validate the target FEC stack for the MPLS LSP Multipath Tree Trace feature.
An MPLS echo request tests a particular LSP. The LSP to be tested is identified by the FEC stack.
During an MPLS LSP multipath tree trace, the echo packet validation rules do not require that a transit router validate the target FEC stack TLV. A downstream map TLV containing the correct received labels must be present in the echo request for target FEC stack checking to be performed.
To request that a transit router validate the target FEC stack, set the V flag from the source router by entering the flags fec keywords in the trace mpls multipath command. The default is that echo request packets are sent with the V flag set to 0.
SUMMARY STEPS
1.
2.
3.
DETAILED STEPS
Setting the Number of Timeout Attempts for MPLS LSP Multipath Tree Trace
Perform the following task to set the number of timeout attempts for the MPLS LSP Multipath Tree Trace feature.
A retry is attempted if an outstanding echo request times out waiting for the corresponding echo reply.
SUMMARY STEPS
1.
2.
3.
DETAILED STEPS
Configuration Examples for MPLS EM—MPLS LSP Multipath Tree Trace
This section includes the following configuration examples for the MPLS EM—MPLS LSP Multipath Tree Trace feature:
•
•
•
•
•
•
Customizing the Default Behavior of MPLS Echo Packets: Example
The following example shows how to customize the behavior of MPLS echo packets so that the MPLS LSP Multipath Tree Trace feature interoperates with a vendor implementation that does not interpret RFC 4379 as Cisco does:
configure terminal!mpls oamecho revision 4no echo vendor-extensionendThe echo revision command is included in this example for completeness. The default echo revision number is 4, which corresponds to RFC 4379.
Configuring MPLS LSP Multipath Tree Trace: Example
The following example shows how to configure the MPLS LSP Multipath Tree Trace feature to interoperate with a vendor implementation that does not interpret RFC 4379 as Cisco does:
configure terminal!mpls oamecho revision 4no echo vendor-extensionend!trace mpls multipath ipv4 10.131.161.151/32The echo revision command is included in this example for completeness. The default echo revision number is 4, which corresponds to the RFC 4379.
Discovering IPv4 Load Balancing Paths Using MPLS LSP Multipath Tree Trace: Example
The following example shows how to use the MPLS LSP Multipath Tree Trace feature to discover IPv4 load balancing paths. The example is based on the sample network shown in Figure 3. In this example, the bitmap size is set to 16. Therefore, path discovery starts by the MPLS LSP Multipath Tree Trace feature using 16 bitmapped addresses as it locates LSP paths from the source router R-101 to the target router R-150 with prefix and mask 10.1.1.150/32. The MPLS LSP Multipath Tree Trace feature starts using the 127.x.y.z/8 address space with 127.0.0.0.
Router# trace mpls multipath ipv4 10.1.1.150/32 hashkey ipv4 bitmap 16Starting LSP Multipath Traceroute for 10.1.1.150/32Codes: '!' - success, 'Q' - request not sent, '.' - timeout,'L' - labeled output interface, 'B' - unlabeled output interface,'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,'P' - no rx intf label prot, 'p' - premature termination of LSP,'R' - transit router, 'I' - unknown upstream index,'X' - unknown return code, 'x' - return code 0Type escape sequence to abort.LLLL!Path 0 found,output interface Et0/0 source 10.1.111.101 destination 127.0.0.0LLL!Path 1 found,output interface Et0/0 source 10.1.111.101 destination 127.0.0.1L!Path 2 found,output interface Et0/0 source 10.1.111.101 destination 127.0.0.5LL!Path 3 found,output interface Et0/0 source 10.1.111.101 destination 127.0.0.7Paths (found/broken/unexplored) (4/0/0)Echo Request (sent/fail) (14/0)Echo Reply (received/timeout) (14/0)Total Time Elapsed 468 msThe output of the trace mpls multipath command in the example shows the result of path discovery with the MPLS LSP Multipath Tree Trace feature as shown in Figure 3.
Figure 3 MPLS LSP Multipath Tree Trace Path Discovery in a Sample Network
Using DSCP to Request a Specific Class of Service in an Echo Reply: Example
The following example shows how to use DSCP to request a specific CoS in an echo reply:
Router# trace mpls multipath ipv4 10.1.1.150/32 reply dscp 50Starting LSP Multipath Traceroute for 10.1.1.150/32Codes: '!' - success, 'Q' - request not sent, '.' - timeout,'L' - labeled output interface, 'B' - unlabeled output interface,'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,'P' - no rx intf label prot, 'p' - premature termination of LSP,'R' - transit router, 'I' - unknown upstream index,'X' - unknown return code, 'x' - return code 0Type escape sequence to abort.LLLL!Path 0 found,output interface Et0/0 source 10.1.111.101 destination 127.0.0.0LLL!Path 1 found,output interface Et0/0 source 10.1.111.101 destination 127.0.0.1L!Path 2 found,output interface Et0/0 source 10.1.111.101 destination 127.0.0.5LL!Path 3 found,output interface Et0/0 source 10.1.111.101 destination 127.0.0.7Paths (found/broken/unexplored) (4/0/0)Echo Request (sent/fail) (14/0)Echo Reply (received/timeout) (14/0)Total Time Elapsed 448 msControlling How a Responding Router Replies to an MPLS Echo Request: Example
The following example shows how to control how a responding router replies to an MPLS echo request:
Router# trace mpls multipath ipv4 10.1.1.150/32 reply mode router-alertStarting LSP Multipath Traceroute for 10.1.1.150/32Codes: '!' - success, 'Q' - request not sent, '.' - timeout,'L' - labeled output interface, 'B' - unlabeled output interface,'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,'P' - no rx intf label prot, 'p' - premature termination of LSP,'R' - transit router, 'I' - unknown upstream index,'X' - unknown return code, 'x' - return code 0Type escape sequence to abort.LLLL!Path 0 found,output interface Et0/0 source 10.1.111.101 destination 127.0.0.0LLL!Path 1 found,output interface Et0/0 source 10.1.111.101 destination 127.0.0.1L!Path 2 found,output interface Et0/0 source 10.1.111.101 destination 127.0.0.5LL!Path 3 found,output interface Et0/0 source 10.1.111.101 destination 127.0.0.7Paths (found/broken/unexplored) (4/0/0)Echo Request (sent/fail) (14/0)Echo Reply (received/timeout) (14/0Total Time Elapsed 708 msSpecifying the Output Interface for Echo Packets Leaving a Router for MPLS LSP Multipath Tree Trace: Example
The following example shows how to specify the output interface for echo packets leaving a router for the MPLS LSP Multipath Tree Trace feature:
Router# trace mpls multipath ipv4 10.1.1.150/32 output interface ethernet0/0Tracing MPLS Label Switched Path to 10.1.1.150/32, timeout is 2 secondsCodes: '!' - success, 'Q' - request not sent, '.' - timeout,'L' - labeled output interface, 'B' - unlabeled output interface,'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,'P' - no rx intf label prot, 'p' - premature termination of LSP,'R' - transit router, 'I' - unknown upstream index,'X' - unknown return code, 'x' - return code 0Type escape sequence to abort.0 10.1.111.101 MRU 1500 [Labels: 33 Exp: 0]L1 10.1.111.111 MRU 1500 [Labels: 33 Exp: 0] 40 msL2 10.2.120.120 MRU 1500 [Labels: 33 Exp: 0] 20 msL3 10.3.131.131 MRU 1500 [Labels: 34 Exp: 0] 20 msL4 10.4.141.141 MRU 1504 [Labels: implicit-null Exp: 0] 20 ms !5 10.5.150.150 16 msSetting the Pace of MPLS Echo Request Packet Transmission for MPLS LSP Multipath Tree Trace: Example
The following examples show how set the pace of MPLS echo request packet transmission for the MPLS LSP Multipath Tree Trace feature. The time between successive MPLS echo requests is set to 300 milliseconds in the first example and 400 milliseconds in the second example:
Router# trace mpls multipath ipv4 10.131.159.252/32 interval 300Starting LSP Multipath Traceroute for 10.131.159.252/32Codes: '!' - success, 'Q' - request not sent, '.' - timeout,'L' - labeled output interface, 'B' - unlabeled output interface,'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,'P' - no rx intf label prot, 'p' - premature termination of LSP,'R' - transit router, 'I' - unknown upstream index,'X' - unknown return code, 'x' - return code 0Type escape sequence to abort.LL!Path 0 found,output interface Et1/0 source 10.2.3.2 destination 127.0.0.0Paths (found/broken/unexplored) (1/0/0)Echo Request (sent/fail) (3/0)Echo Reply (received/timeout) (3/0)Total Time Elapsed 1604 msRouter# trace mpls multipath ipv4 10.131.159.252/32 interval 400Starting LSP Multipath Traceroute for 10.131.159.252/32Codes: '!' - success, 'Q' - request not sent, '.' - timeout,'L' - labeled output interface, 'B' - unlabeled output interface,'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,'P' - no rx intf label prot, 'p' - premature termination of LSP,'R' - transit router, 'I' - unknown upstream index,'X' - unknown return code, 'x' - return code 0Type escape sequence to abort.LL!Path 0 found,output interface Et1/0 source 10.2.3.2 destination 127.0.0.0Paths (found/broken/unexplored) (1/0/0)Echo Request (sent/fail) (3/0)Echo Reply (received/timeout) (3/0)Total Time Elapsed 1856 msNotice that the elapsed time increases as you increase the interval size.
Enabling MPLS LSP Multipath Tree Trace to Detect LSP Breakages Caused by an Interface that Lacks an MPLS Configuration: Example
The following examples shows how to enable the MPLS LSP Multipath Tree Trace feature to detect LSP breakages caused by an interface that lacks an MPLS configuration:
Router# trace mpls multipath ipv4 10.1.1.150/32 force-explicit-nullStarting LSP Multipath Traceroute for 10.1.1.150/32Codes: '!' - success, 'Q' - request not sent, '.' - timeout,'L' - labeled output interface, 'B' - unlabeled output interface,'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,'P' - no rx intf label prot, 'p' - premature termination of LSP,'R' - transit router, 'I' - unknown upstream index,'X' - unknown return code, 'x' - return code 0Type escape sequence to abort.LLLL!Path 0 found,output interface Et0/0 source 10.1.111.101 destination 127.0.0.0LLL!Path 1 found,output interface Et0/0 source 10.1.111.101 destination 127.0.0.1L!Path 2 found,output interface Et0/0 source 10.1.111.101 destination 127.0.0.5LL!Path 3 found,output interface Et0/0 source 10.1.111.101 destination 127.0.0.7Paths (found/broken/unexplored) (4/0/0)Echo Request (sent/fail) (14/0)Echo Reply (received/timeout) (14/0)Total Time Elapsed 460 msThis example shows the additional information provided when you add the verbose keyword to the command:
Router# trace mpls multipath ipv4 10.1.1.150/32 force-explicit-null verboseStarting LSP Multipath Traceroute for 10.1.1.150/32Codes: '!' - success, 'Q' - request not sent, '.' - timeout,'L' - labeled output interface, 'B' - unlabeled output interface,'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,'P' - no rx intf label prot, 'p' - premature termination of LSP,'R' - transit router, 'I' - unknown upstream index,'X' - unknown return code, 'x' - return code 0Type escape sequence to abort.LLLL!Path 0 found,output interface Et0/0 source 10.1.111.101 destination 127.0.0.00 10.1.111.101 10.1.111.111 MRU 1500 [Labels: 33/explicit-null Exp: 0/0] multipaths 0L1 10.1.111.111 10.2.121.121 MRU 1500 [Labels: 34/explicit-null Exp: 0/0] ret code 8 multipaths 2L2 10.2.121.121 10.3.132.132 MRU 1500 [Labels: 34/explicit-null Exp: 0/0] ret code 8 multipaths 1L3 10.3.132.132 10.4.140.240 MRU 1500 [Labels: 32/explicit-null Exp: 0/0] ret code 8 multipaths 1L4 10.4.140.240 10.5.150.50 MRU 1504 [Labels: explicit-null Exp: 0] ret code 8 multipaths 1 !5 10.5.150.50, ret code 3 multipaths 0LLL!Path 1 found,output interface Et0/0 source 10.1.111.101 destination 127.0.0.10 10.1.111.101 10.1.111.111 MRU 1500 [Labels: 33/explicit-null Exp: 0/0] multipaths 0L1 10.1.111.111 10.2.120.120 MRU 1500 [Labels: 33/explicit-null Exp: 0/0] ret code 8 multipaths 2L2 10.2.120.120 10.3.131.131 MRU 1500 [Labels: 33/explicit-null Exp: 0/0] ret code 8 multipaths 2L3 10.3.131.131 10.4.141.141 MRU 1500 [Labels: 34/explicit-null Exp: 0/0] ret code 8 multipaths 2L4 10.4.141.141 10.5.150.150 MRU 1504 [Labels: explicit-null Exp: 0] ret code 8 multipaths 1!5 10.5.150.150, ret code 3 multipaths 0L!Path 2 found,output interface Et0/0 source 10.1.111.101 destination 127.0.0.50 10.1.111.101 10.1.111.111 MRU 1500 [Labels: 33/explicit-null Exp: 0/0] multipaths 0L1 10.1.111.111 10.2.120.120 MRU 1500 [Labels: 33/explicit-null Exp: 0/0] ret code 8 multipaths 2L2 10.2.120.120 10.3.131.131 MRU 1500 [Labels: 33/explicit-null Exp: 0/0] ret code 8 multipaths 2L3 10.3.131.131 10.4.140.140 MRU 1500 [Labels: 32/explicit-null Exp: 0/0] ret code 8 multipaths 2L4 10.4.140.140 10.5.150.50 MRU 1504 [Labels: explicit-null Exp: 0] ret code 8 multipaths 1 ! 5 10.5.150.50, ret code 3 multipaths 0LL!Path 3 found,output interface Et0/0 source 10.1.111.101 destination 127.0.0.70 10.1.111.101 10.1.111.111 MRU 1500 [Labels: 33/explicit-null Exp: 0/0] multipaths 0L1 10.1.111.111 10.2.120.120 MRU 1500 [Labels: 33/explicit-null Exp: 0/0] ret code 8 multipaths 2L2 10.2.120.120 10.3.130.130 MRU 1500 [Labels: 34/explicit-null Exp: 0/0] ret code 8 multipaths 2L3 10.3.130.130 10.4.140.40 MRU 1500 [Labels: 32/explicit-null Exp: 0/0] ret code 8 multipaths 1L4 10.4.140.40 10.5.150.50 MRU 1504 [Labels: explicit-null Exp: 0] ret code 8 multipaths 1!5 10.5.150.50, ret code 3 multipaths 0Paths (found/broken/unexplored) (4/0/0)Echo Request (sent/fail) (14/0)Echo Reply (received/timeout) (14/0)Total Time Elapsed 492 msRequesting that a Transit Router Validate the Target FEC Stack for MPLS LSP Multipath Tree Trace: Example
The following example shows how to request that a transit router validate the target FEC stack for the MPLS LSP Multipath Tree Trace feature:
Router# trace mpls multipath ipv4 10.1.1.150/32 flags fec ttl 5Starting LSP Multipath Traceroute for 10.1.1.150/32Codes: '!' - success, 'Q' - request not sent, '.' - timeout,'L' - labeled output interface, 'B' - unlabeled output interface,'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,'P' - no rx intf label prot, 'p' - premature termination of LSP,'R' - transit router, 'I' - unknown upstream index,'X' - unknown return code, 'x' - return code 0Type escape sequence to abort.LLLL!Path 0 found,output interface Et0/0 source 10.1.111.101 destination 127.0.0.0LLL!Path 1 found,output interface Et0/0 source 10.1.111.101 destination 127.0.0.1L!Path 2 found,output interface Et0/0 source 10.1.111.101 destination 127.0.0.5LL!Path 3 found,output interface Et0/0 source 10.1.111.101 destination 127.0.0.7Paths (found/broken/unexplored) (4/0/0)Echo Request (sent/fail) (14/0)Echo Reply (received/timeout) (14/0)Total Time Elapsed 464 msTarget FEC stack validation is always done at the egress router when the flags fec keywords are specified in the trace mpls multipath command.
Setting the Number of Timeout Attempts for MPLS LSP Multipath Tree Trace: Example
The following example sets the number of timeout attempts for the MPLS LSP Multipath Tree Trace feature to four:
Router# trace mpls multipath ipv4 10.1.1.150/32 retry-count 4Starting LSP Multipath Traceroute for 10.1.1.150/32Codes: '!' - success, 'Q' - request not sent, '.' - timeout,'L' - labeled output interface, 'B' - unlabeled output interface,'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,'P' - no rx intf label prot, 'p' - premature termination of LSP,'R' - transit router, 'I' - unknown upstream index,'X' - unknown return code, 'x' - return code 0Type escape sequence to abort.LLLL!Path 0 found,output interface Et0/0 source 10.1.111.101 destination 127.0.0.0LLL!Path 1 found,output interface Et0/0 source 10.1.111.101 destination 127.0.0.1L!Path 2 found,output interface Et0/0 source 10.1.111.101 destination 127.0.0.5LL!Path 3 found,output interface Et0/0 source 10.1.111.101 destination 127.0.0.7Paths (found/broken/unexplored) (4/0/0)Echo Request (sent/fail) (14/0)Echo Reply (received/timeout) (14/0)Total Time Elapsed 460 msThe following output shows a trace mpls multipath command that found one unexplored path, one successful path, and one broken path:
Router# trace mpls multipath ipv4 10.1.1.150/32 retry-count 4Starting LSP Multipath Traceroute for 10.1.1.150/32Codes: '!' - success, 'Q' - request not sent, '.' - timeout,'L' - labeled output interface, 'B' - unlabeled output interface,'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,'P' - no rx intf label prot, 'p' - premature termination of LSP,'R' - transit router, 'I' - unknown upstream index,'X' - unknown return code, 'x' - return code 0Type escape sequence to abort.LLL....Path 0 Unexplorable,output interface Et0/0 source 10.1.111.101 destination 127.0.0.0LLL!Path 1 found,output interface Et0/0 source 10.1.111.101 destination 127.0.0.1 BPath 2 Broken,output interface Et0/0 source 10.1.111.101 destination 127.0.0.7Paths (found/broken/unexplored) (1/1/1)Echo Request (sent/fail) (12/0)Echo Reply (received/timeout) (8/4)Total Time Elapsed 7868 msAdditional References
The following sections provide references related to the MPLS EM—MPLS LSP Multipath Tree Trace feature.
Related Documents
Concepts and configuration tasks for MPLS LSP ping or traceroute
MPLS Embedded Management—LSP Ping for LDP, Cisco IOS 12.4(6)T feature module
Concepts and configuration for MPLS and other MPLS applications
Cisco IOS Multiprotocol Label Switching Configuration Guide, Release 12.4
MPLS commands
Cisco IOS Multiprotocol Label Switching Command Reference, Release 12.4
Troubleshooting procedures for MPLS
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 new and modified commands only.
•
debug mpls lspv
To display information related to the MPLS LSP Ping/Traceroute feature, use the debug mpls lspv command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug mpls lspv [tlv] [error] [event] [ipc] [packet [data | error]] [path-discovery] [multipath] [all]
no debug mpls lspv
Syntax Description
tlv
(Optional) Displays Multiprotocol Label Switching (MPLS) echo packet type, length, values (TLVs) information as it is being coded and decoded.
error
(Optional) Displays error conditions encountered during MPLS echo request and echo reply encoding and decoding. See Table 3.
event
(Optional) Displays MPLS echo request and reply send and receive event information.
ipc
(Optional) Interprocess communication. Displays debug information regarding communication between the Route Processor and line cards.
packet data
(Optional) Displays detailed debug information for the MPLS echo packets sent and received. This output is seen only on the originating router and the router generating the reply.
packet error
(Optional) Displays packet errors for MPLS echo request and reply. No output is expected for this command.
path-discovery
(Optional) Provides information regarding LSP traceroute path discovery operations.
multipath
(Optional) Displays multipath information.
all
(Optional) Enables all the command keywords.
Command Default
MPLS LSP debugging is disabled.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Use this command to monitor activity associated with the ping mpls and the trace mpls commands.
Table 3 lists the messages displayed by the debug mpls lspv error command and the reason for each error message.
Examples
The following is sample output from the ping mpls command when LSPV event debugging is enabled:
Router# debug mpls lspv eventLSPV event debugging is onRouter# ping mpls ipv4 10.131.159.252/32 repeat 1Sending 1, 100-byte MPLS Echos to 10.131.159.252/32,timeout is 2 seconds, send interval is 0 msec:Codes: '!' - success, 'Q' - request not transmitted,'.' - timeout, 'U' - unreachable,'R' - downstream router but not targetType escape sequence to abort.!Success rate is 100 percent (1/1), round-trip min/avg/max = 48/48/48 msRouter#*Dec 31 19:31:15.366: LSPV:waiting for 2 seconds*Dec 31 19:31:15.366: LSPV: sender_handle: 2000002D, Event Echo Requests Start, [Idle->Waiting for Echo Reply]*Dec 31 19:31:15.414: LSPV: sender_handle: 2000002D, Event Echo Reply Received, [Waiting for Echo Reply->Waiting for Interval]*Dec 31 19:31:15.466: LSPV: sender_handle: 2000002D, Event Echo Requests Cancel, [Waiting for Interval->Idle]Router# undebug allAll possible debugging has been turned offThe following is sample output from the ping mpls command when LSPV TLV debugging is enabled:
Router# debug mpls lspv tlvLSPV tlv debugging is onRouter# ping mpls ipv4 10.131.159.252/32 repeat 1Sending 1, 100-byte MPLS Echos to 10.131.159.252/32,timeout is 2 seconds, send interval is 0 msec:Codes: '!' - success, 'Q' - request not transmitted,'.' - timeout, 'U' - unreachable,'R' - downstream router but not targetType escape sequence to abort.!Success rate is 100 percent (1/1), round-trip min/avg/max = 40/40/40 msRouter#*Dec 31 19:32:32.566: LSPV: Echo Hdr encode: version 1, msg type 1, reply mode 2 , return_code 0, return_subcode 0, sender handle 9400002E, sequence number 1, timestamp sent 14:32:32 EST Wed Dec 31 2003, timestamp rcvd 19:00:00 EST Thu Dec 31 1899*Dec 31 19:32:32.566: LSPV: IPV4 FEC encode: destaddr 10.131.159.252/32*Dec 31 19:32:32.566: LSPV: Pad TLV encode: type 1, size 18, pattern 0xABCD*Dec 31 19:32:32.606: LSPV: Echo Hdr decode: version 1, msg type 2, reply mode 2, return_code 3, return_subcode 0, sender handle 9400002E, sequence number 1, timestamp sent 14:32:32 EST Wed Dec 31 2003, timestamp rcvd 14:32:32 EST Wed Dec 31 2003Router# undebug allAll possible debugging has been turned offThe following is sample output from the trace mpls multipath command when LSPV multipath debugging is on:
Router# debug mpls lspv multipathmultipath information debugging is onRouter# trace mpls multipath ipv4 10.5.5.5/32Starting LSP Multipath Traceroute for 10.5.5.5/32Codes: '!' - success, 'Q' - request not sent, '.' - timeout,'L' - labeled output interface, 'B' - unlabeled output interface,'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,'P' - no rx intf label prot, 'p' - premature termination of LSP,'R' - transit router, 'I' - unknown upstream index,'X' - unknown return code, 'x' - return code 0Type escape sequence to abort.LL*Aug 30 20:39:03.719: LSPV: configuring bitmask multipath, base 0x7F000000, bitmapsize 32, start 0x7F000000, numbits 32*Aug 30 20:39:03.719: LSPV: multipath info: info_length 4, bitmapsize 32, multipath_length 8, start 127.0.0.0, base 127.0.0.0, numbits 32*Aug 30 20:39:03.719: LSPV: multipath info: info_length 4, bitmapsize 32, multipath_length 8, start 127.0.0.0, base 127.0.0.0, numbits 32*Aug 30 20:39:03.719: LSPV: getnext bit_cursor 0, index 0, mask 0x80000000*Aug 30 20:39:03.719: LSPV: next addr 127.0.0.0*Aug 30 20:39:03.719: LSPV: multipath info: datagramsize 8*Aug 30 20:39:03.719: 7F 00 00 00 FF FF FF FF*Aug 30 20:39:04.007: LSPV: multipath info: !Path 0 found,output interface Et1/0 source 10.2.3.2 destination 127.0.0.0Paths (found/broken/unexplored) (1/0/0)Echo Request (sent/fail) (3/0)Echo Reply (received/timeout) (3/0)Total Time Elapsed 924 msRouter#*Aug 30 20:39:04.007: 7F 00 00 00 FF FF FF FF*Aug 30 20:39:04.007: LSPV: ds map convert: rtr_id A030404, mtu 1500 intf_addr 10.3.4.4 hashkey 8, multipath length 8, info 2130706432*Aug 30 20:39:04.007: LSPV: multipath info: hashkey type 8, base 0x7F000000, bitmapsize 32, info0 0xFFFFFFFF*Aug 30 20:39:04.007: LSPV: multipath info: info_length 4, bitmapsize 32, multipath_length 8, start 127.0.0.0, base 127.0.0.0, numbits 32*Aug 30 20:39:04.007: LSPV: getnext bit_cursor 0, index 0, mask 0x80000000*Aug 30 20:39:04.007: LSPV: next addr 127.0.0.0*Aug 30 20:39:04.007: LSPV: multipath info: datagramsize 8*Aug 30 20:39:04.007: 7F 00 00 00 FF FF FF FF*Aug 30 20:39:04.299: LSPV: multipath info: datagramsize 8*Aug 30 20:39:04.299: 7F 00 00 00 FF FF FF FF*Aug 30 20:39:04.299: LSPV: ds map convert: rtr_id A040505, mtu 1504 intf_addr 10.4.5.5 hashkey 8, multipath length 8, info 2130706432*Aug 30 20:39:04.299: LSPV: multipath info: hashkey type 8, base 0x7F000000, bitmapsize 32, info0 0xFFFFFFFF*Aug 30 20:39:04.299: LSPV: multipath info: info_length 4, bitmapsize 32, multipath_length 8, start 127.0.0.0, base 127.0.0.0, numbits 32*Aug 30 20:39:04.299: LSPV: getnext bit_cursor 0, index 0, mask 0x80000000*Aug 30 20:39:04.299: LSPV: next addr 127.0.0.0*Aug 30 20:39:04.299: LSPV: multipath info: datagramsize 8*Aug 30 20:39:04.299: 7F 00 00 00 FF FF FF FFRouter# undebug allmultipath information debugging is offRelated Commands
ping mpls
Checks MPLS LSP connectivity.
trace mpls
Discovers MPLS LSP routes that packets will actually take when traveling to their destinations.
echo
To customize the default behavior of echo packets, use the echo command in MPLS OAM configuration mode. To set the echo packet's behavior to its default value, use the no form of this command.
echo {revision {3 | 4} | vendor-extension}
no echo {revision {3 | 4} | vendor-extension}
Syntax Description
Command Default
Cisco-specific extension TLVs are sent with the echo packet. Revision 4 is the router's default.
Command Modes
MPLS OAM configuration
Command History
Usage Guidelines
Before you can enter the echo command, you must first enter the mpls oam command to enter MPLS OAM configuration mode.
Specify the revision keyword only if one of the following conditions exists:
•
•
To prevent failures reported by the replying router due to TLV version issues, you can use the echo revision command to configure all routers in the core for the same version of the Internet Engineering Task Force (IEFT) label switched paths (LSP) ping draft. For example, if the network is running draft RFC 4379 implementations, but one router is capable of only Version 3 (Cisco Revision 3), configure all routers in the network to operate in Revision 3 mode. Revision 3 mode applies only to Multiprotocol Label Switching (MPLS) LSP ping or traceroute. Revision 3 mode does not support MPLS multipath LSP traceroute.
The vendor-extension keyword is enabled by default in the router. If your network includes routers that are not Cisco routers, you may want to disable Cisco extended TLVs. To disable Cisco extended TLVs, specify the no echo vendor-extension command in MPLS OAM configuration mode. To enable Cisco extended TLVs again, respecify the echo command with the vendor-extension keyword.
Examples
The following example uses Revision 3 of the echo packets and sends the vendor's extension TLV with the echo packet:
mpls oamecho revision 3echo vendor-extensionexit
Related Commands
mpls oam
Enters MPLS OAM configuration mode for customizing the default behavior of echo packets.
mpls oam
To enter MPLS OAM configuration mode for customizing the default behavior of echo packets, use the mpls oam command in global configuration mode. To disable MPLS OAM functionality, use the no format of this command.
mpls oam
no mpls oam
Syntax Description
This command has no arguments or keywords.
Command Default
Customizing the default behavior of echo packets is disabled.
Command Modes
Global configuration
Command History
Usage Guidelines
After you enter the mpls oam command, you can enter the echo command in MPLS OAM configuration mode to specify the revision number of the echo packet's default values or to send the vendor's extension type, length, values (TLVs) with the echo packet.
Examples
The following example enters MPLS OAM configuration mode for customizing the default behavior of echo packets:
mpls oamRelated Commands
trace mpls
To discover Multiprotocol Label Switching (MPLS) label switched path (LSP) routes that packets actually take when traveling to their destinations, use the trace mpls command in privileged EXEC mode.
trace mpls
{ipv4 destination-address/destination-mask | traffic-eng Tunnel tunnel-number}
[timeout seconds]
[destination address-start [address-end | address-increment]]
[revision {1 | 2 | 3 | 4}]
[source source-address]
[exp exp-bits]
[ttl maximum-time-to-live]
[reply {dscp dscp-bits | mode reply-mode {ipv4 | no-reply | router-alert} | pad-tlv}]
[force-explicit-null]
[output interface tx-interface [nexthop ip-address]]
[flags fec]
[revision tlv-revision-number]Syntax Description
ipv4
Specifies the destination type as a Label Distribution Protocol (LDP) IPv4 address.
destination-address
Address prefix of the target to be tested.
/destination-mask
Number of bits in the network mask of the target address. The slash is required.
traffic-eng Tunnel tunnel-number
Specifies the destination type as an MPLS traffic engineering (TE) tunnel.
timeout seconds
(Optional) Specifies the timeout interval in seconds. The range is from 0 to 3600. The default is 2 seconds.
destination
(Optional) Specifies a network 127 address.
address-start
(Optional) The beginning network 127 address.
address-end
(Optional) The ending network 127 address.
address-increment
(Optional) Number by which to increment the network 127 address.
revision {1 | 2 | 3 | 4}
(Optional) Selects the type, length, values (TLVs) version of the implementation. Use the revision 4 default unless attempting to interoperate with devices running Cisco IOS Release 12.0(27)S1 or 12.0(27)S2. If you do not select a revision keyword, the software uses the latest version.
See Table 4 in the"Revision Keyword Usage" section of the "Usage Guidelines" section for information on when to select the 1, 2, 3, and 4 keywords.
source source-address
(Optional) Specifies the source address or name. The default address is loopback0. This address is used as the destination address in the MPLS echo response.
exp exp-bits
(Optional) Specifies the MPLS experimental field value in the MPLS header for an MPLS echo reply. Valid values are from 0 to 7. Default is 0.
ttl maximum-time-to-live
(Optional) Specifies a maximum hop count.
reply dscp dscp-bits
(Optional) Provides the capability to request a specific class of service (CoS) in an echo reply by providing a differentiated services code point (DSCP) value.
The echo reply is returned with the IP header ToS byte set to the value specified in the reply dscp keyword.
reply mode reply-mode
(Optional) Specifies the reply mode for the echo request packet.
The reply-mode is one of the following:
•
•
•
reply pad-tlv
(Optional) Tests the ability of the sender of an echo reply to support the copy pad TLV to echo reply.
force-explicit-null
(Optional) Forces an explicit null label to be added to the MPLS label stack even though the label was unsolicited.
output interface tx-interface
(Optional) Specifies the output interface for echo requests.
nexthop ip-address
(Optional) Causes packets to go through the specified next-hop address.
flags fec
(Optional) Requests that target Forwarding Equivalence Class (FEC) stack validation be done at the egress router. A downstream map TLV containing the correct received labels must be present in the echo request for target FEC stack checking to be performed.
Note
revision tlv-revision-number
(Optional) Cisco TLV revision number.
Defaults
revision = 4
timeout = 2 seconds
reply mode = ipv4 via UDP (2)
Maximum time-to-live = 30 hops
Experimental bits in MPLS header = 0Command Modes
Privileged EXEC
Command History
Usage Guidelines
Use the trace mpls command to validate, test, or troubleshoot IPv4 LDP LSPs and IPv4 Resource Reservation Protocol (RSVP) TE tunnels.
UDP Destination Address Usage
The destination address is a valid 127/8 address. You can specify a single address or a range of numbers from 0.0.0 to x.y.z, where x, y, and z are numbers from 0 to 255 and correspond to the 127.x.y.z destination address.
The MPLS echo request destination address in the UDP packet is not used to forward the MPLS packet to the destination router. The label stack that is used to forward the echo request routes the MPLS packet to the destination router. The 127/8 address guarantees that the packets are routed to the localhost (the default loopback address of the router processing the address) if the UDP packet destination address is used for forwarding.
In addition, the destination address is used to adjust load balancing when the destination address of the IP payload is used for load balancing.
Time-to-Live Keyword Usage
The time-to-live value indicates the maximum number of hops a packet should take to reach its destination. The value in the TTL field in a packet is decremented by 1 each time the packet travels through a router.
For MPLS LSP ping, the TTL is a value after which the packet is discarded and an MPLS echo reply is sent back to the originating router.
For MPLS Multipath LSP Traceroute, the TTL is a maximum time-to-live value and is used to discover the number of downstream hops to the destination router. MPLS LSP Traceroute incrementally increases the TTL value in its MPLS echo requests (TTL = 1, 2, 3, 4, ...) to accomplish this.
Revision Keyword Usage
The revision keyword allows you to issue a trace mpls ipv4 or trace mpls traffic-eng command based on the format of the TLV. Table 4 lists the revision option and usage guidelines for each option.
Table 4 Revision Options and Option Usage Guidelines
11
Not supported in Cisco IOS Release 12.4(11)T or later releases.
Version 1 (draft-ietf-mpls-ping-03)
For a device running Cisco IOS Release 12.0(27)S3 or a later release, you must use the revision 1 keyword when you send LSP ping or LSP traceroute commands to devices running Cisco IOS Release 12.0(27)S1 or 12.0(27)S2.
2
Version 2 functionality was replaced by Version 3 functionality before any images were shipped.
3
Version 3 (draft-ietf-mpls-ping-03).
•
•
4
•
•
This is the recommended version.
1 If you do not specify the revision keyword, the software uses the latest version.
Examples
The following example shows how to trace packets through an MPLS LDP LSP:
Router# trace mpls ipv4 10.131.191.252/32Alternatively, you can use the interactive mode:
Protocol [ip]: mplsTarget IPv4, pseudowire or traffic-eng [ipv4]: <ipv4 |pseudowire |tunnel> ipv4Target IPv4 address: 10.131.191.252Target mask: /32Repeat [1]:Packet size [100]:Timeout in seconds [2]:Extended commands? [no]: yesDestination start address:Destination end address:Source address:EXP bits in mpls header [0]:TimeToLive [255]:Reply mode (2-ipv4 via udp, 3-ipv4 via udp with router alert) [2]:Reply ip header DSCP bits [0]:Tracing MPLS Label Switched Path to 10.131.191.252/32, timeout is 2 secondsCodes:'!' - success, 'Q' - request not sent, '.' - timeout,'L' - labeled output interface, 'B' - unlabeled output interface,'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label,'P' - no rx intf label prot, 'p' - premature termination of LSP,'R' - transit router, 'X' - unknown return code, 'x' - return code 0Type escape sequence to abort.0 10.131.159.245 mtu 1500 []! 1 10.131.191.252 100 msThe following example shows how to trace packets through an MPLS TE tunnel:
Router# trace mpls traffic-eng Tunnel 0Tracing MPLS TE Label Switched Path on Tunnel0, timeout is 2 secondsCodes:'!' - success, 'Q' - request not sent, '.' - timeout,'L' - labeled output interface, 'B' - unlabeled output interface,'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label,'P' - no rx intf label prot, 'p' - premature termination of LSP,'R' - transit router, 'X' - unknown return code, 'x' - return code 0Type escape sequence to abort.0 10.131.159.230 mtu 1500 [Labels: 22 Exp: 0]R 1 10.131.159.225 mtu 1500 [Labels: 22 Exp: 6] 72 msR 2 10.131.191.229 mtu 1504 [implicit-null] 72 ms! 3 10.131.191.252 92 msAlternatively, you can use the interactive mode:
Router# tracerouteProtocol [ip]: mplsTarget IPv4 or tunnel [ipv4]: traffic-engTunnel number [0]:Repeat [1]:Timeout in seconds [2]:Extended commands? [no]:Tracing MPLS TE Label Switched Path on Tunnel0, timeout is 2 secondsCodes:'!' - success, 'Q' - request not sent, '.' - timeout,'L' - labeled output interface, 'B' - unlabeled output interface,'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label,'P' - no rx intf label prot, 'p' - premature termination of LSP,'R' - transit router, 'X' - unknown return code, 'x' - return code 0Type escape sequence to abort.0 10.131.159.230 mtu 1500 [Labels: 22 Exp: 0]R 1 10.131.159.225 mtu 1500 [Labels: 22 Exp: 6] 72 msR 2 10.131.191.229 mtu 1504 [implicit-null] 72 ms! 3 10.131.191.252 92 msUse the show running-config command to verify the configuration of Tunnel 0 (shown in bold):
Router# show running-config interface tunnel 0Building configuration...Current configuration : 210 bytes!interface Tunnel0ip unnumbered Loopback0no ip directed-broadcasttunnel destination 10.131.191.252 <---- Tunnel destination IP address.tunnel mode mpls traffic-engtunnel mpls traffic-eng path-option 5 explicit name as1pe-long-pathendRouter# show mpls traffic-eng tunnels tunnel 0 briefSignalling Summary:LSP Tunnels Process: runningRSVP Process: runningForwarding: enabledPeriodic reoptimization: every 3600 seconds, next in 1369 secondsPeriodic FRR Promotion: Not RunningPeriodic auto-bw collection: disabledTUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROTPE_t0 10.131.191.252 - Et0/0 up/upRouter# show ip cef 10.131.191.25210.131.191.252/32, version 37, epoch 0, cached adjacency 10.131.159.2460 packets, 0 bytestag information set, all rewrites ownedlocal tag: 21via 10.131.159.246, Ethernet1/0, 0 dependenciesnext hop 10.131.159.246, Ethernet1/0valid cached adjacencytag rewrite with Et1/0, 10.131.159.246, tags imposed {}The tunnel destination has the same IP address as the one in the earlier trace IPv4 example, but the trace takes a different path, even though tunnel 0 is not configured to forward traffic by means of autoroute or static routing. The trace mpls traffic-eng command is powerful; it enables you to test the tunnels to verify that they work before you map traffic onto them.
Related Commands
trace mpls multipath
To discover all Multiprotocol Label Switching (MPLS) label switched paths (LSPs) from an egress router to an ingress router, use the trace mpls multipath command in privileged EXEC mode.
trace mpls multipath ipv4 destination-address/destination-mask-length
[timeout seconds]
[interval milliseconds]
[destination address-start address-end]
[source source-address]
[exp exp-bits]
[ttl maximum-time-to-live]
[reply mode {ipv4 | router-alert}]
[reply dscp dscp-value]
[retry-count retry-count-value]
[force-explicit-null]
[output interface tx-interface [nexthop ip-address]]
[hashkey ipv4 bitmap bitmap-size]
[flags fec]
[verbose]Syntax Description
Command Default
timeout = 2 seconds
interval = 0 milliseconds
reply mode = IPv4 via UDP (2)
Maximum time-to-live = 30 hops
Experimental bits in MPLS header = 0Command Modes
Privileged EXEC
Command History
12.2(31)SB2
This command was introduced.
12.2(33)SRB
This command was integrated into Cisco IOS Release 12.2(33)SRB.
Usage Guidelines
Use the trace mpls multipath command to discover all possible paths between an egress and ingress router in multivendor networks that use IPv4 load balancing at the transit routers.
Use the destination address-start address-end keyword and arguments to specify a valid 127/8 address. You have the option to specify a single x.y.z-address or a range of numbers from 0.0.0 to x.y.z, where x, y, and z are numbers from 0 to 255 and correspond to the 127.x.y.z destination address. The MPLS echo request destination address in the UDP packet is not used to forward the MPLS packet to the destination router. The label stack that is used to forward the echo request routes the MPLS packet to the destination router. The 127/8 address guarantees that the packets are routed to the localhost (the default loopback address of the router processing the address) if the UDP packet destination address is used for forwarding. In addition, the destination address is used to adjust load balancing when the destination address of the IP payload is used for load balancing.
Examples
The following example shows how to discover all IPv4 LSPs to a router whose IP address is 10.1.1.150:
Router# trace mpls multipath ipv4 10.1.1.150/32Starting LSP Multipath Traceroute for 10.1.1.150/32Codes: '!' - success, 'Q' - request not sent, '.' - timeout,'L' - labeled output interface, 'B' - unlabeled output interface,'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,'P' - no rx intf label prot, 'p' - premature termination of LSP,'R' - transit router, 'I' - unknown upstream index,'X' - unknown return code, 'x' - return code 0Type escape sequence to abort.LLLL!Path 0 found,output interface Et0/0 source 10.1.111.101 destination 127.0.0.0 LLL!Path 1 found,output interface Et0/0 source 10.1.111.101 destination 127.0.0.1 L!Path 2 found,output interface Et0/0 source 10.1.111.101 destination 127.0.0.5 LL!Path 3 found,output interface Et0/0 source 10.1.111.101 destination 127.0.0.7Paths (found/broken/unexplored) (4/0/0)Echo Request (sent/fail) (14/0)Echo Reply (received/timeout) (14/0)Total Time Elapsed 472 msThe following example shows how to set the number of timeout retry attempts to 4 during a multipath LSP trace:
Router# trace mpls multipath ipv4 10.1.1.150/32 retry-count 4Starting LSP Multipath Traceroute for 10.1.1.150/32Codes: '!' - success, 'Q' - request not sent, '.' - timeout,'L' - labeled output interface, 'B' - unlabeled output interface,'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,'P' - no rx intf label prot, 'p' - premature termination of LSP,'R' - transit router, 'I' - unknown upstream index,'X' - unknown return code, 'x' - return code 0Type escape sequence to abort.LLLL!Path 0 found,output interface Et0/0 source 10.1.111.101 destination 127.0.0.0 LLL!Path 1 found,output interface Et0/0 source 10.1.111.101 destination 127.0.0.1 L!Path 2 found,output interface Et0/0 source 10.1.111.101 destination 127.0.0.5 LL!Path 3 found,output interface Et0/0 source 10.1.111.101 destination 127.0.0.7Paths (found/broken/unexplored) (4/0/0)Echo Request (sent/fail) (14/0)Echo Reply (received/timeout) (14/0)Total Time Elapsed 460 msThe following example shows that outgoing MPLS Operation, Administration, and Management (OAM) echo request packets will go through the interface e0/0 and will be restricted to the path with the next hop address of 10.0.0.3:
Router# trace multipath ipv4 10.4.4.4/32 output interface e0/0 nexthop 10.0.0.3Starting LSP Multipath Traceroute for 10.4.4.4/32Codes: '!' - success, 'Q' - request not sent, '.' - timeout,'L' - labeled output interface, 'B' - unlabeled output interface,'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,'P' - no rx intf label prot, 'p' - premature termination of LSP,'R' - transit router, 'I' - unknown upstream index,'X' - unknown return code, 'x' - return code 0Type escape sequence to abort.L!Path 0 found,output interface Et0/0 nexthop 10.0.0.3source 10.0.0.1 destination 127.0.0.0Paths (found/broken/unexplored) (1/0/0)Echo Request (sent/fail) (2/0)Echo Reply (received/timeout) (2/0)Total Time Elapsed 728 msRelated Commands
Feature Information for MPLS EM—MPLS LSP Multipath Tree Trace
Table 5 lists the release history for this feature.
Not all commands may be available in your Cisco IOS software release. For release information about a specific command, see the command reference documentation.
Cisco IOS software images are specific to a Cisco IOS software release, a feature set, and a platform. Use Cisco Feature Navigator to find information about platform support and Cisco IOS software image support. Access Cisco Feature Navigator at http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Note
Table 5 Feature Information for MPLS EM—MPLS LSP Multipath Tree Trace
MPLS EM—MPLS LSP Multipath Tree Trace
12.2(31)SB2
12.2(33)SRBThe MPLS EM—MPLS LSP Multipath Tree Trace feature provides the means to discover all the possible paths of a label switched path (LSP) between an egress and ingress router. Once discovered, these paths can be retested on a periodic basis using Multiprotocol Label Switching (MPLS) LSP ping or traceroute. This feature is an extension to the MPLS LSP traceroute functionality for the tracing of IPv4 LSPs.
Cisco IOS MPLS Embedded Management (EM) is a set of standards and value-added services that facilitate the deployment, operation, administration, and management of MPLS-based networks in line with the fault, configuration, accounting, performance, and security (FCAPS) model.
In Cisco IOS Release 12.2(31)SB2, this feature was introduced.
In Cisco IOS Release 12.2(33)SRB, support was added for a Cisco IOS 12.2SR release.
The following sections provide information about this feature:
•
•
•
•
•
•
•
•
•
•
•
The following commands were modified by this feature: debug mpls lspv, echo, mpls oam, trace mpls, and trace mpls multipath.
Glossary
ECMP—equal-cost multipath. Multiple routing paths of equal cost that may be used for packet forwarding.
FEC—Forwarding Equivalence Class. A set of packets that can be handled equivalently for forwarding purposes and are thus suitable for binding to a single label. Examples include the set of packets destined for one address prefix and the packets in any flow.
flow—A set of packets traveling between a pair of hosts, or between a pair of transport protocol ports on a pair of hosts. For example, packets with the same source address, source port, destination address, and destination port might be considered a flow.
A flow is also a stream of data traveling between two endpoints across a network (for example, from one LAN station to another). Multiple flows can be transmitted on a single circuit.
localhost—A name that represents the host router (device). The localhost uses the reserved loopback IP address 127.0.0.1.
LSP—label switched path. A connection between two routers in which MPLS forwards the packets.
LSPV—Label Switched Path Verification. An LSP ping subprocess. It encodes and decodes MPLS echo requests and replies, and it interfaces with IP, MPLS, and AToM switching for sending and receiving MPLS echo requests and replies. At the MPLS echo request originator router, LSPV maintains a database of outstanding echo requests for which echo responses have not been received.
MPLS router alert label—An MPLS label of 1. An MPLS packet with a router alert label is redirected by the router to the Route Processor (PR) processing level for handling. This allows these packets to bypass any forwarding failures in hardware routing tables.
OAM—Operation, Administration, and Management.
punt—Redirect packets with a router alert from the line card or interface to Route Processor (RP) level processing for handling.
RP—Route Processor. The processor module in a Cisco 7000 series router that contains the CPU, system software, and most of the memory components that are used in the router. It is sometimes called a supervisory processor.
TTL—time-to-live. A parameter you can set that indicates the maximum number of hops a packet should take to reach its destination.
TLV—type, length, values. A block of information included in a Cisco Discovery Protocol address.
UDP—User Datagram Protocol. Connectionless transport layer protocol in the TCP/IP protocol stack. UDP is a simple protocol that exchanges datagrams without acknowledgments or guaranteed delivery, so error processing and retransmission must be handled by other protocols. UDP is defined in RFC 768.
XDR—eXternal Data Representation. Standard for machine-independent data structures developed by Sun Microsystems. Used to transport messages between the Route Processor (RP) and the line card.
Note
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.
© 2006-2007 Cisco Systems, Inc. All rights reserved.
FeedbackContact Cisco
- Open a Support Case
- (Requires a Cisco Service Contract)