7200a#show mpls traffic-eng tunnels tunnel1
Name: Primary tunnel 7200a->12008a->12... (Tunnel1) Destination: 18.104.22.168
Admin: up Oper: down Path: not valid Signalling: Down path option 6, type dynamic
Bandwidth: 0 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF
Metric Type: TE (default)
AutoRoute: enabled LockDown: disabled Loadshare: 0 bw-based auto-bw: disabled
Shortest Unconstrained Path Info: Path Weight: UNKNOWN Explicit Route: UNKNOWN History: Tunnel:
Time since created: 1 hours, 14 minutes Time since path change: 4 minutes, 3 seconds Prior LSP:
Removal Trigger: path verification failed Path Option 6:
Last Error: PCALC:: No path to destination, 22.214.171.124
Example 11-22 provides little information as to what might be wrong. The Shortest Unconstrained Path Info:
shows the explicit route as UNKNOWN, and the last error says No path to destination, 126.96.36.199. This output shows only one active path option, and it is dynamic.
With an explicitly specified path, it is easy to check for MPLS TE information at each hop, because you specify the hops that should be used. If something goes wrong, it would have to be somewhere along this path.
However, with the dynamic path option, if there are multiple ways to get to the tail from the head, there is no obvious path where you can start looking for errors. To troubleshoot this type of problem, you must know the topology of your network very well!
For example, you need to know the IGP path between the headend and the tail. As soon as you know that, you should remove the constraints that are placed on the tunnel and see if the tunnel comes up. If you remove all constraints, the headend should follow the IGP best path to get to the tail. If the tunnel does not come up, you can start looking for information in the TE-DB, check the information distribution, and check the configuration of each node along that path, just as you'd do with the explicit path option.
Was this article helpful?