Use the output of the commands in this section to discover LSP breaks.
An LDP target session is established between routers PE1 and P2, as shown in the output of the following
show mpls ldp discovery command:
PE1# show mpls ldp discovery
Local LDP Identifier:
10.131.191.252:0
Discovery Sources:
Interfaces:
FastEthernet0/0/0 (ldp): xmit/recv
LDP Id: 10.131.191.251:0
Tunnel1 (ldp): Targeted -> 10.131.159.251
Targeted Hellos:
10.131.191.252 -> 10.131.159.252 (ldp): active/passive, xmit/recv
LDP Id: 10.131.159.252:0
10.131.191.252 -> 10.131.159.251 (ldp): active, xmit/recv
LDP Id: 10.131.159.251:0
Enter the following command on the P2 router in global configuration mode:
P2(config)# no mpls ldp discovery targeted-hello accept
The LDP configuration change causes the targeted LDP session between the headend and tailend of the TE tunnel to go down.
Labels for IPv4 prefixes learned by P2 are not advertised to PE1. Thus, all IP prefixes reachable by P2 are reachable by PE1
only through IP (not MPLS). In other words, packets destined for those prefixes through Tunnel 1 at PE1 will be IP switched
at P2 (which is undesirable).
The following
show mpls ldp discovery command shows that the LDP targeted session is down:
PE1# show mpls ldp discovery
Local LDP Identifier:
10.131.191.252:0
Discovery Sources:
Interfaces:
FastEthernet0/0/0 (ldp): xmit/recv
LDP Id: 10.131.191.251:0
Tunnel1 (ldp): Targeted -> 10.131.159.251
Targeted Hellos:
10.131.191.252 -> 10.131.159.252 (ldp): active/passive, xmit/recv
LDP Id: 10.131.159.252:0
10.131.191.252 -> 10.131.159.251 (ldp): active, xmit
Enter the
show mpls forwarding-table command at the PE1 router. The display shows that the outgoing packets are untagged as a result of the LDP configuration
changes.
PE1# show mpls forwarding-table 10.131.159.252
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
22 Untagged[T] 10.131.159.252/32 0 Tu1 point2point
[T] Forwarding through a TSP tunnel.
View additional tagging info with the 'detail' option
A
ping mpls command entered at the PE1 router displays the following:
PE1# ping mpls ipv4 10.131.159.252/32 repeat 1
Sending 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 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 0
Type escape sequence to abort.
R
Success rate is 0 percent (0/1)
The
ping mpls command fails. The R indicates that the sender of the MPLS echo reply had a routing entry but no MPLS FEC. Entering the
verbose keyword with theping mpls command displays the MPLS LSP echo reply sender address and the return code. You should be able to determine where the breakage
occurred by telnetting to the replying router and inspecting its forwarding and label tables. You might need to look at the
neighboring upstream router as well, because the breakage might be on the upstream router.
PE1# ping mpls ipv4 10.131.159.252/32 repeat 1 verbose
Sending 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 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 0
Type escape sequence to abort.
R 10.131.159.225, return code 6
Success rate is 0 percent (0/1)
Alternatively, use the LSP
traceroute command to figure out which router caused the breakage. In the following example, for subsequent values of TTL greater than
2, the same router keeps responding (10.131.159.225). This suggests that the MPLS echo request keeps getting processed by
the router regardless of the TTL. Inspection of the label stack shows that P1 pops the last label and forwards the packet
to P2 as an IP packet. This explains why the packet keeps getting processed by P2. MPLS echo request packets cannot be forwarded
by use of the destination address in the IP header because the address is set to a 127/8 address.
PE1# trace mpls ipv4 10.131.159.252/32 ttl 5
Tracing MPLS Label Switched Path to 10.131.159.252/32, timeout is 2 seconds
Codes:
'!' - 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 0
Type 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 ms
R 2 10.131.159.229 MRU 1504 [implicit-null] 28 ms
! 3 10.131.159.230 40 ms
pe1#
Feedback