Table Of Contents
MPLS Embedded Management—LSP Ping/Traceroute and AToM VCCV
Prerequisites for MPLS Embedded Management—LSP Ping/Traceroute and AToM VCCV
Restrictions for MPLS Embedded Management—LSP Ping/Traceroute and AToM VCCV
Information About MPLS Embedded Management—LSP Ping/Traceroute and AToM VCCV
Any Transport over MPLS Virtual Circuit Connection Verification
Selection of AToM VCCV Switching Types
MPLS LSP Ping/Traceroute Command Options
Selection of FECs for Validation
Reply Mode Options for MPLS LSP Ping/Traceroute
Other MPLS LSP Ping/Traceroute Command Options
MPLS LSP Ping/Traceroute Option Interactions and Loops
MPLS Echo Request Packets Not Forwarded by IP
Information Provided by the Router Processing LSP Ping or LSP Traceroute
Troubleshooting with LSP Ping/Traceroute
MPLS LSP Ping/Traceroute Discovers LSP Breakage
MPLS LSP Traceroute Tracks Untagged Cases
MPLS LSP Ping/Traceroute Returns a Q
Load Balancing for IPv4 LDP LSPs
MPLS Embedded Management—LSP Ping/Traceroute and AToM VCCV
As Multiprotocol Label Switching (MPLS) deployments increase and the traffic types they carry increase, the ability of service providers to monitor label switched paths (LSPs) and quickly isolate MPLS forwarding problems is critical to their ability to offer services. The MPLS Embedded Management—LSP Ping/Traceroute and Any Transport over MPLS Virtual Circuit Connection Verification (AToM VCCV) feature helps them do this.
MPLS Embedded Management—LSP Ping/Traceroute and AToM VCCV can detect when an LSP fails to deliver user traffic.
•
You can use MPLS LSP Ping to test LSP connectivity for IPv4 Label Distribution Protocol (LDP) prefixes, traffic engineering (TE) Forwarding Equivalence Classes (FECs), and AToM FECs.
•
•
Internet Control Message Protocol (ICMP) ping and trace are often used to help diagnose the root cause when a forwarding failure occurs. The MPLS Embedded Management—LSP Ping/Traceroute and AToM VCCV 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.
MPLS Embedded Management—LSP Ping/Traceroute and AToM VCCV use MPLS echo request and reply packets to test LSPs. The Cisco implementation of MPLS echo request and echo reply are based on the Internet Engineering Task Force (IETF) Internet-Draft Detecting MPLS Data Plane Failures (draft-ietf-mpls-lsp-ping-03.txt).
Feature History for MPLS Embedded Management—LSP Ping/Traceroute and AToM VCCV
12.0(27)S
This feature was introduced.
12.2(18)SXE
This feature was integrated into Cisco IOS Release 12.2(18)SXE.
Note
Finding Support Information for Platforms and Cisco IOS Software Images
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/fn. You must have an account on Cisco.com. If you do not have an account or have forgotten your username or password, click Cancel at the login dialog box and follow the instructions that appear.
Contents
•
•
•
Prerequisites for MPLS Embedded Management—LSP Ping/Traceroute and AToM VCCV
Before you use the MPLS Embedded Management—LSP Ping/Traceroute and AToM VCCV feature, you should:
•
–
–
–
•
–
–
–
•
Restrictions for MPLS Embedded Management—LSP Ping/Traceroute and AToM VCCV
The following restrictions apply to the MPLS Embedded Management—LSP Ping/Traceroute and AToM VCCV feature:
•
•
•
Information About MPLS Embedded Management—LSP Ping/Traceroute and AToM VCCV
Before using the MPLS Embedded Management—LSP Ping/Traceroute and AToM VCCV feature, you need an understanding of the following concepts:
•
•
•
•
•
•
•
MPLS LSP Ping Operation
MPLS LSP Ping uses MPLS echo request and reply packets to validate an LSP. Both an MPLS echo request and an MPLS echo reply are User Datagram Protocol (UDP) packets with source and destination ports set to 3503.
The MPLS echo request packet is sent to a target router through the use of the appropriate label stack associated with the LSP to be validated. Use of the label stack causes the packet to be switched inband of the LSP (that is, forwarded over the LSP itself). The destination IP address of the MPLS echo request packet is different from the address used to select the label stack. The destination address of the UDP packet is defined as a 127.x.y.z/8 address. This prevents the IP packet from being IP switched to its destination if the LSP is broken.
An MPLS echo reply is sent in response to an MPLS echo request. It is sent as an IP packet and forwarded using IP, MPLS, or a combination of both types of switching. The source address of the MPLS echo reply packet is an address from the router generating the echo reply. The destination address is the source address of the router in the MPLS echo request packet.
Figure 1 shows MPLS LSP Ping echo request and echo reply paths.
Figure 1 MPLS LSP Ping Echo Request and Echo Reply Paths
If you initiate an MPLS LSP Ping request at LSR1 to an FEC at LSR6, you get the results shown in Table 1.
Table 1 MPLS LSP Ping Example from Figure 1
1.
LSR1
Initiates an MPLS LSP Ping request for an FEC at the target router LSR6 and sends an MPLS echo request to LSR2.
2.
LSR2
Receives and forwards the MPLS echo request packet through transit routers LSR3 and LSR4 to the penultimate router LSR5.
3.
LSR5
Receives the MPLS echo request, pops the MPLS label, and forwards the packet to LSR6 as an IP packet.
4.
LSR6
Receives the IP packet, processes the MPLS echo request, and sends an MPLS echo reply to LSR1 through an alternate route.
5.
LSR7 to LSR10
Receive and forward the MPLS echo reply back toward LSR1, the originating router.
6.
LSR1
Receives the MPLS echo reply in response to the MPLS echo request.
You can use MPLS LSP Ping to validate IPv4 LDP, AToM, and IPv4 Resource Reservation Protocol (RSVP) FECs by using appropriate keywords and arguments with the ping mpls command:
ping mpls {ipv4 destination-address destination-mask | pseudowire ipv4-address vc-id vc-id | traffic-eng tunnel-interface tunnel-number}MPLS LSP Traceroute Operation
MPLS LSP Traceroute also uses MPLS echo request and reply packets to validate an LSP. The echo request and echo reply are UDP packets with source and destination ports set to 3503.
The MPLS LSP Traceroute feature uses time-to-live (TTL) settings to force expiration of the TTL along an LSP. MPLS LSP Traceroute incrementally increases the TTL value in its MPLS echo requests (TTL = 1, 2, 3, 4,...) to discover the downstream mapping of each successive hop. The success of the LSP traceroute depends on the transit router processing the MPLS echo request when it receives a labeled packet with a TTL = 1. On Cisco routers, when the TTL expires, the packet is sent to the Route Processor (RP) for processing. The transit router returns an MPLS echo reply containing information about the transit hop in response to the TTL-expired MPLS packet.
Figure 2 shows an MPLS LSP Traceroute example with an LSP from LSR1 to LSR4.
Figure 2 MPLS LSP Traceroute Example
If you enter an LSP traceroute to a FEC at LSR4 from LSR1, you get the results shown in Table 2.
Table 2 MPLS LSP Traceroute Example Based on Figure 2
1.
LSR1
MPLS echo request—With a target FEC pointing to LSR4 and to a downstream mapping
•
•
2.
LSR2
MPLS echo reply
Receives packet with TTL = 1
•
•
3.
LSR1
MPLS echo request—With the same target FEC and the downstream mapping received in the echo reply from LSR2
•
•
4.
LSR2
MPLS echo request
Receives packet with TTL = 2
•
•
5.
LSR3
MPLS reply packet
Receives packet with TTL = 1
•
•
6.
LSR1
MPLS echo request—With the same target FEC and the downstream mapping received in the echo reply from LSR3
•
•
7.
LSR2
MPLS echo request
Receives packet with TTL = 3
•
•
8.
LSR3
MPLS echo request
Receives packet with TTL = 2
•
•
9.
LSR4
MPLS echo reply
Receives packet with TTL = 1
•
•
•
You can use MPLS LSP Traceroute to validate IPv4 LDP and IPv4 RSVP FECs by using appropriate keywords and arguments with the trace mpls command:
trace mpls {ipv4 destination-address destination-mask | traffic-eng tunnel-interface tunnel-number}By default, the TTL is set to 30. Therefore, the traceroute output always contains 30 lines, even if an LSP problem exists. This might mean duplicate entries in the output, should an LSP problem occur. The router address of the last point that the trace reaches is repeated until the ouput is 30 lines. You can ignore the duplicate entries. The following example shows that the trace encountered an LSP problem at the router that has an IP address of 10.6.1.6:
Router# traceroute mpls ipv4 10.6.7.4/32Tracing MPLS Label Switched Path to 10.6.7.4/32, timeout is 2 secondsCodes: '!' - success, 'Q' - request not transmitted,'.' - timeout, 'U' - unreachable,'R' - downstream router but not targetType escape sequence to abort.0 10.6.1.14 MRU 4470 [Labels: 22 Exp: 0]R 1 10.6.1.5 MRU 4470 [Labels: 21 Exp: 0] 2 msR 2 10.6.1.6 4 ms <------ Router address repeated for 2nd to 30th TTL.R 3 10.6.1.6 1 msR 4 10.6.1.6 1 msR 5 10.6.1.6 3 msR 6 10.6.1.6 4 msR 7 10.6.1.6 1 msR 8 10.6.1.6 2 msR 9 10.6.1.6 3 msR 10 10.6.1.6 4 msR 11 10.6.1.6 1 msR 12 10.6.1.6 2 msR 13 10.6.1.6 4 msR 14 10.6.1.6 5 msR 15 10.6.1.6 2 msR 16 10.6.1.6 3 msR 17 10.6.1.6 4 msR 18 10.6.1.6 2 msR 19 10.6.1.6 3 msR 20 10.6.1.6 4 msR 21 10.6.1.6 1 msR 22 10.6.1.6 2 msR 23 10.6.1.6 3 msR 24 10.6.1.6 4 msR 25 10.6.1.6 1 msR 26 10.6.1.6 3 msR 27 10.6.1.6 4 msR 28 10.6.1.6 1 msR 29 10.6.1.6 2 msR 30 10.6.1.6 3 ms <------ TTL 30.If you know the maximum number of hops in your network, you can set the TTL to a smaller value with the trace mpls ttl maximum-time-to-live command. The following example shows the same traceroute command as the previous example, except that this time the TTL is set to 5.
Router# traceroute mpls ipv4 10.6.7.4/32 ttl 5Tracing MPLS Label Switched Path to 10.6.7.4/32, timeout is 2 secondsCodes: '!' - success, 'Q' - request not transmitted,'.' - timeout, 'U' - unreachable,'R' - downstream router but not targetType escape sequence to abort.0 10.6.1.14 MRU 4470 [Labels: 22 Exp: 0]R 1 10.6.1.5 MRU 4474 [No Label] 3 msR 2 10.6.1.6 4 ms <------ Router address repeated for 2nd to 5th TTL.R 3 10.6.1.6 1 msR 4 10.6.1.6 3 msR 5 10.6.1.6 4 msAny Transport over MPLS Virtual Circuit Connection Verification
AToM Virtual Circuit Connection Verification (AToM VCCV) allows the sending of control packets inband of an AToM PW from the originating provider edge (PE) router. The transmission is intercepted at the destination PE router, instead of being forwarded to the customer edge (CE) router. This capability allows you to use MPLS LSP Ping to test the PW section of AToM virtual circuits (VCs).
AToM VCCV consists of the following:
•
•
AToM VCCV Signaling
One of the steps involved in AToM VC setup is the signaling of VC labels and AToM VCCV capabilities between AToM VC endpoints. The router uses an optional parameter, defined in the Internet Draft draft-ieft-pwe3-vccv-01.txt, to communicate the AToM VCCV disposition capabilities of each endpoint.
The AToM VCCV disposition capabilities are categorized as follows:
•
•
Table 3 describes AToM VCCV Type 1 and Type 2 switching modes.
Selection of AToM VCCV Switching Types
Cisco routers always use Type 1 switching, if available, when they send MPLS LSP Ping packets over an AToM VC control channel. Type 2 switching accommodates those VC types and implementations that do not support or interpret the AToM control word.
Table 4 shows the AToM VCCV switching mode advertised and the switching mode selected by the AToM VC.
An AToM VC advertises its AToM VCCV disposition capabilities in both directions: that is, from the originating router (PE1) to the destination router (PE2), and from PE2 to PE1.
In some instances, AToM VCs might use different switching types if the two endpoints have different AToM VCCV capabilities. If PE1 supports Type 1 and Type 2 AToM VCCV switching and PE2 supports only Type 2 AToM VCCV switching, there are two consequences:
•
•
You can determine the AToM VCCV capabilities advertised to and received from the peer by entering the show mpls l2transport binding command at the PE router. For example:
PE1# show mpls l2transport bindingDestination Address: 10.131.191.252, VC ID: 333Local Label: 16Cbit: 1, VC Type: Ethernet, GroupID: 0MTU: 1500, Interface Desc: n/aVCCV Capabilities: Type 1, Type 2Remote Label: 19Cbit: 1, VC Type: Ethernet, GroupID: 0MTU: 1500, Interface Desc: n/aVCCV Capabilities: Type 1MPLS LSP Ping/Traceroute Command Options
MPLS LSP Ping/Traceroute command options are specified as keywords and arguments on the ping mpls and trace mpls commands.
The ping mpls command provides the following options:
ping mpls {ipv4 destination-address destination-mask [destination address-start address-end increment] [ttl time-to-live] | pseudowire ipv4-address vc-id vc-id [destination address-start address-end increment] | traffic-eng tunnel-interface tunnel-number [ttl time-to-live]} [source source-address] [repeat count] [timeout seconds][{size packet-size} | {sweep minimum maximum size-increment}] [pad pattern] [reply mode reply-mode] [interval msec] [exp exp-bits] [verbose]The trace mpls command provides the following options:
trace mpls {ipv4 destination-address destination-mask [destination address-start address-end address-increment] | traffic-eng tunnel-interface tunnel-number} [source source-address] [timeout seconds] [reply mode reply-mode] [ttl maximum-time-to-live] [exp exp-bits]The following sections describe some command options of the MPLS LSP Ping/Traceroute features:
•
•
•
•
Selection of FECs for Validation
An LSP is formed by labels. Routers learn labels through LDP, TE, AToM, or other MPLS applications. You can use MPLS LSP Ping/Traceroute to validate an LSP used for forwarding traffic for a given FEC. Table 5 lists the keywords and arguments for the ping mpls and traceroute mpls commands that allow the selection of an LSP for validation.
Table 5 Selection of LSPs for Validation
LDP IPv4 prefix
ipv4 destination-address destination-mask
ipv4 destination-address destination-mask
MPLS TE tunnel
traffic-eng tunnel-interface tunnel-number
traffic-eng tunnel-interface tunnel-number
AToM VC
pseudowire ipv4-address vc-id vc-id
—1
1 MPLS LSP Traceroute does not support the AToM tunnel LSP type for this release.
Reply Mode Options for MPLS LSP Ping/Traceroute
The reply mode is used to control how the responding router replies to an MPLS echo request sent by an MPLS LSP Ping or MPLS LSP Traceroute command. Table 6 describes the reply mode options.
On Cisco routers, the reply with an IPv4 UDP packet implies that the router should send an IPv4 UDP packet in reply to an MPLS echo request. If you select the ipv4 reply mode, you do not have explicit control over whether the packet uses IP or MPLS hops to reach the originator of the MPLS echo request. This is the mode that you would normally use to test and verify LSPs.
On Cisco routers, the reply with an IPv4 UDP packet that contains a router alert forces the packet to go back to the destination and be processed by the Route Processor (RP) process switching at each intermediate hop. This bypasses hardware/line card forwarding table inconsistencies. You should select this option when the originating (headend) routers fail to receive a reply to the MPLS echo request.
You can instruct the replying router to send an echo reply with the IP router alert option by using one of the following commands:
ping mpls {ipv4 destination-address destination-mask | pseudowire ipv4-address vc-id vc-id | traffic-eng tunnel-interface tunnel-number} reply mode router-alertor
trace mpls {ipv4 destination-address destination-mask | traffic-eng tunnel-interface tunnel-number} reply mode router-alertHowever, the reply with a router alert adds overhead to the process of getting a reply back to the originating router. This method is more expensive to process than a reply without a router alert and should be used only if there are reply failures. That is, the reply with a router alert label should only be used for MPLS LSP Ping or MPLS LSP Traceroute when the originating (headend) router fails to receive a reply to an MPLS echo request.
Packet Handling Along Return Path with an IP/MPLS Router Alert
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 RP process level for handling. This allows these packets to bypass the forwarding failures in hardware routing tables. Table 7 describes how IP and MPLS packets with an IP router alert option are handled by the router switching path processes.
Other MPLS LSP Ping/Traceroute Command Options
Table 8 describes other MPLS LSP Ping/Traceroute command options that can be specified as keywords or arguments with the ping mpls command, or with both the ping mpls and trace mpls commands. Options available for you to use only on the ping mpls command are indicated as such.
MPLS LSP Ping options described in Table 8 can be implemented by the use of the following syntax:
ping mpls {ipv4 destination-address destination-mask [destination address-start address-end increment] [ttl time-to-live] | pseudowire ipv4-address vc-id vc-id [destination address-start address-end increment] | traffic-eng tunnel-interface tunnel-number [ttl time-to-live]} [source source-address] [repeat count] [{size packet-size} | {sweep minimum maximum size-increment}] [pad pattern] [timeout seconds] [interval msec] [exp exp-bits] [verbose]MPLS LSP Traceroute options described in Table 8 can be implemented by the use of the following syntax:
trace mpls {ipv4 destination-address destination-mask [destination address-start address-end address-increment] | traffic-eng tunnel-interface tunnel-number} [source source-address] [timeout seconds] [ttl maximum-time-to-live] [exp exp-bits]MPLS LSP Ping/Traceroute Option Interactions and Loops
Usage examples for the MPLS Embedded Management—LSP Ping/Traceroute and AToM VCCV feature in this and subsequent sections are based on the sample topology shown in Figure 3.
Figure 3 Sample Topology for Configuration Examples
The interaction of some MPLS Embedded Management—LSP Ping/Traceroute and AToM VCCV options can cause loops. See the following topic for a description of the loops you might encounter with the ping mpls and trace mpls commands:
•
•
Possible Loops with MPLS LSP Ping
With the MPLS LSP Ping feature, loops can occur if you use the repeat count option, the sweep size range option, or the UDP destination address range option.
ping mpls {ipv4 destination-address destination-mask [destination address-start address-end increment] | pseudowire ipv4-address vc-id vc-id [destination address-start address-end increment] | traffic-eng tunnel-interface tunnel-number} [repeat count] [sweep minimum maximum size-increment]Following is an example of how a loop operates if you use the following keywords and arguments on the ping mpls command:
Router# ping mpls ipv4 10.131.159.251/32 destination 127.0.0.1 127.0.0.2 0.0.0.1 repeat 2
sweep 1450 1475 25Sending 2, [1450..1500]-byte MPLS Echos to 10.131.159.251/32,
timeout is 2 seconds, send interval is 0 msec:
Codes: '!' - success, 'Q' - request not transmitted,
'.' - timeout, 'U' - unreachable,
'R' - downstream router but not target
Type escape sequence to abort.
Destination address 127.0.0.1
!
!
Destination address 127.0.0.2
!
!
Destination address 127.0.0.1
!
!
Destination address 127.0.0.2
!
!
An mpls ping command is sent for each packet size range for each destination address until the end-address is reached. For this example, the loop continues in the same manner until the destination address, 127.0.0.5, is reached. The sequence continues until the number is reached that you specified with the repeat count keyword and argument. For this example, the repeat count is 2. The MPLS LSP Ping loop sequence is as follows:
repeat = 1destination address 1 (address-start)for (size from sweep minimum to maximum, counting by size-increment)send an lsp pingdestination address 2 (address-start + address-increment)for (size from sweep minimum to maximum, counting by size-increment)send an lsp pingdestination address 3 (address-start + address-increment + address-increment)for (size from sweep minimum to maximum, counting by size-increment)send an lsp ping. . .until destination address = address-end. . .until repeat = countPossible Loop with MPLS LSP Traceroute
With the MPLS LSP Traceroute feature, loops can occur if you use the UDP destination address range option and the time-to-live option.
trace mpls {ipv4 destination-address destination-mask [destination address-start address-end address-increment] | traffic-eng tunnel-interface tunnel-number [ttl maximum-time-to-live]Here is an example of how a loop operates if you use the following keywords and arguments on the trace mpls command:
Router# trace mpls ipv4 10.131.159.251/32 destination 127.0.0.1 127.0.0.3 1 ttl 5Tracing MPLS Label Switched Path to 10.131.159.251/32, timeout is 2 secondsCodes: '!' - success, 'Q' - request not transmitted,'.' - timeout, 'U' - unreachable,'R' - downstream router but not targetType escape sequence to abort.Destination address 127.0.0.10 10.131.191.230 MRU 1500 [Labels: 19 Exp: 0]R 1 10.131.159.226 MRU 1504 [implicit-null] 40 ms! 2 10.131.159.225 40 msDestination address 127.0.0.20 10.131.191.230 MRU 1500 [Labels: 19 Exp: 0]R 1 10.131.159.226 MRU 1504 [implicit-null] 40 ms! 2 10.131.159.225 40 msDestination address 127.0.0.30 10.131.191.230 MRU 1500 [Labels: 19 Exp: 0]R 1 10.131.159.226 MRU 1504 [implicit-null] 40 ms! 2 10.131.159.225 48 msAn mpls trace command is sent for each TTL from 1 to the maximum TTL (ttl maximum-time-to-live keyword and argument) for each destination address until the address specified with the destination end-address argument is reached. For this example, the maximum TTL is 5 and the end destination address is 127.0.0.3. The MPLS LSP Traceroute loop sequence is as follows:
destination address 1 (address-start)for (ttl from 1 to maximum-time-to-live)send an lsp tracedestination address 2 (address-start + address-increment)for (ttl from 1 to maximum-time-to-live)send an lsp tracedestination address 3 (address-start + address-increment + address-increment)for (ttl from 1 to maximum-time-to-live)send an lsp trace. . .until destination address = address-endMPLS Echo Request Packets Not Forwarded by IP
MPLS echo request packets sent during an LSP ping are never forwarded by IP. The IP header destination address field in an MPLS echo request packet is a 127.x.y.z/8 address. Routers should not forward packets using a 127.x.y.z/8 address. The 127.x.y.z/8 address corresponds to an address for the local host.
The use of a 127.x.y.z address as a destination address of the UDP packet is significant in that the MPLS echo request packet fails to make it to the target router if a transit router does not label switch the LSP. This allows for the detection of LSP breakages.
•
•
Figure 4 shows the path of the MPLS echo request and reply when a transit router fails to label switch a packet in an LSP.
Figure 4 Path When Transit Router Fails to Label Switch a Packet
Note
Information Provided by the Router Processing LSP Ping or LSP Traceroute
Table 9 describes the characters that the router processing an LSP ping or LSP traceroute packet returns to the sender about the failure or success of the request.
You can also view the return code for an MPLS LSP Ping operation if you enter the verbose keyword on the ping mpls command.
MTU Discovery in an LSP
During an MLPS LSP Ping, MPLS echo request packets are sent with the IP packet attribute set to do not fragment. That is, the DF bit is set in the IP header of the packet. This allows you to use the MPLS echo request to test for the MTU that can be supported for the packet through the LSP without fragmentation.
Figure 5 shows a sample network with a single LSP from PE1 to PE2 formed with labels advertised by means of LDP.
Figure 5 Sample Network with LSP—Labels Advertised by LDP
You can determine the maximum receive unit (MRU) at each hop by tracing the LSP using the MPLS Traceroute feature. The MRU is the maximum size of a labeled packet that can be forwarded through an LSP. The following example shows the results of a trace mpls command when the LSP is formed with labels created by LDP:
PE1# trace mpls ipv4 10.131.159.252/32Tracing MPLS Label Switched Path to 10.131.159.252/32, timeout is 2 secondsCodes: '!' - success, 'Q' - request not transmitted,'.' - timeout, 'U' - unreachable,'R' - downstream router but not targetType escape sequence to abort.0 10.131.191.230 MRU 1496 [Labels: 22/19 Exp: 0/0]R 1 10.131.159.226 MRU 1500 [Labels: 19 Exp: 0] 40 msR 2 10.131.159.229 MRU 1504 [implicit-null] 28 ms! 3 10.131.159.230 40 msYou can determine the MRU for the LSP at each hop through the use of the show forwarding detail command:
PE1# show mpls forwarding 10.131.159.252 detailLocal Outgoing Prefix Bytes tag Outgoing Next Hoptag tag or VC or Tunnel Id switched interface22 19 10.131.159.252/32 0 Tu1 point2pointMAC/Encaps=14/22, MRU=1496, Tag Stack{22 19}, via Et0/0AABBCC009700AABBCC0098008847 0001600000013000No output feature configuredTo determine the maximum sized echo request that will fit on the LSP, you can find the IP MTU by using the show interface interface-name command.
PE1# show interface e0/0Ethernet0/0 is up, line protocol is upHardware is Lance, address is aabb.cc00.9800 (bia aabb.cc00.9800)Internet address is 10.131.191.230/30MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 1/255Encapsulation ARPA, loopback not setKeepalive set (10 sec)ARP type: ARPA, ARP Timeout 04:00:00Last input 00:00:01, output 00:00:01, output hang neverLast clearing of "show interface" counters neverInput queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0Queueing strategy: fifoOutput queue: 0/40 (size/max)5 minute input rate 0 bits/sec, 0 packets/sec5 minute output rate 0 bits/sec, 0 packets/sec377795 packets input, 33969220 bytes, 0 no bufferReceived 231137 broadcasts, 0 runts, 0 giants, 0 throttles0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored0 input packets with dribble condition detected441772 packets output, 40401350 bytes, 0 underruns0 output errors, 0 collisions, 10 interface resets0 babbles, 0 late collision, 0 deferred0 lost carrier, 0 no carrier0 output buffer failures, 0 output buffers swapped outThe IP MTU in the show interface interface-name example is 1500 bytes. Subtract the number of bytes corresponding to the label stack from the MTU number. From the output of the show mpls forwarding command, the Tag stack consists of one label (21). Therefore, the largest MPLS echo request packet that can be sent in the LSP, shown in Figure 5, is 1500 - (2 x 4) = 1492.
You can validate this by using the following mpls ping command:
PE1# ping mpls ipv4 10.131.159.252/32 sweep 1492 1500 1 repeat 1Sending 1, [1492..1500]-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.!QQQQQQQQSuccess rate is 11 percent (1/9), round-trip min/avg/max = 40/40/40 msIn this command, only packets of 1492 bytes are sent successfully, as indicated by the exclamation point (!). Packets of byte sizes 1493 to 1500 are source-quenched, as indicated by the Q.
You can pad an MPLS echo request so that a payload of a given size can be tested. The pad TLV is useful when you use the MPLS echo request to discover the MTU supportable by an LSP. MTU discovery is extremely important for applications like AToM that contain non-IP payloads that cannot be fragmented.
Managing an LSP Network
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 characterize the liveliness of an LSP and reliably detect when a label switched path fails to deliver user traffic.
You can use MPLS LSP Ping to verify the LSP that is used to transport packets destined for IPv4 LDP prefixes, TE tunnels, and AToM PW FECs. You can use MPLS LSP Traceroute to trace LSPs that are used to carry packets destined for IPv4 LDP prefixes and TE tunnel FECs.
An MPLS echo request is sent through an LSP to validate it. A TTL expiration or LSP breakage causes the transit router to process the echo request before it gets to the intended destination and 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 via an IP path, an MPLS path, or a combination of both back to the originator of the echo request.
Troubleshooting with LSP Ping/Traceroute
ICMP ping and trace commands are often used to help diagnose the root cause of a failure. When an LSP is broken, the packet might make its way to the target router by way of IP forwarding, thus making ICMP ping and traceroute unreliable for detecting MPLS forwarding problems. The MPLS Embedded Management—LSP Ping/Traceroute and AToM VCCV feature extends this diagnostic and troubleshooting ability to the MPLS network and handles inconsistencies between the IP and MPLS forwarding tables, inconsistencies in the MPLS control and data plane, and problems with the reply path.
Figure 6 shows a sample topology with an LDP LSP and TE tunnel LSP.
Figure 6 Sample Topology with LDP and TE Tunnel LSPs
This section contains the following topics:
•
•
•
MPLS LSP Ping/Traceroute Discovers LSP Breakage
This section contains the following topics:
•
•
Configuration for Sample Topology
These are sample topology configurations for the troubleshooting examples in the following sections (see Figure 6). There are the six sample router configurations.
Router CE1 Configuration
Following is the configuration for the CE1 router:
version 12.0!hostname ce1!enable password lab!interface Loopback0ip address 10.131.191.253 255.255.255.255no ip directed-broadcast!interface Ethernet2/0ip address 10.0.0.1 255.255.255.0no ip directed-broadcastno keepaliveno cdp enable!endRouter PE1 Configuration
Following is the configuration for the PE1 router:
version 12.0!hostname pe1!ip cefmpls label protocol ldpmpls traffic-eng tunnelsno mpls traffic-eng auto-bw timers frequency 0mpls ldp discovery targeted-hello accept!interface Loopback0ip address 10.131.191.252 255.255.255.255no ip directed-broadcast!interface Tunnel1ip unnumbered Loopback0no ip directed-broadcastmpls label protocol ldpmpls iptunnel destination 10.131.159.251tunnel mode mpls traffic-engtunnel mpls traffic-eng autoroute announcetunnel mpls traffic-eng priority 2 2tunnel mpls traffic-eng bandwidth 512tunnel mpls traffic-eng path-option 1 dynamic!interface Tunnel2ip unnumbered Loopback0no ip directed-broadcastshutdownmpls label protocol ldpmpls iptunnel destination 10.131.159.252tunnel mode mpls traffic-engtunnel mpls traffic-eng autoroute announcetunnel mpls traffic-eng priority 1 1tunnel mpls traffic-eng bandwidth 100tunnel mpls traffic-eng path-option 1 dynamic!interface Ethernet0/0ip address 10.131.191.230 255.255.255.252no ip directed-broadcastmpls traffic-eng tunnelsmpls ipip rsvp bandwidth 1500 1500ip rsvp signalling dscp 0!interface Ethernet1/0ip address 10.131.159.246 255.255.255.252no ip directed-broadcastno shutdownmpls ipip rsvp bandwidth 1500 1500ip rsvp signalling dscp 0!interface Ethernet2/0no ip addressno ip directed-broadcastno cdp enablexconnect 10.131.159.252 333 encapsulation mpls!interface Ethernet3/0no ip addressno ip directed-broadcastshutdown!router ospf 1log-adjacency-changespassive-interface Loopback0network 10.131.159.244 0.0.0.3 area 0network 10.131.191.228 0.0.0.3 area 0network 10.131.191.232 0.0.0.3 area 0
Guest
