MPLS_LSPM/2/mplsTunnelDown_active

Message

MPLS_LSPM/2/mplsTunnelDown_active: Tunnel status changes to Down. (TunnelId=[TunnelId], LocalLspId=[LocalLspId], IngressLsrId=[IngressLsrId], EgressLsrId=[EgressLsrId], OutIfIndex=[OutIfIndex], TunnelAdminStatus=[TunnelAdminStatus], TunnelOperStatus=[TunnelOperStatus], TunnelName=[TunnelName], OutIfName=[OutIfName], SubReason=[SubReason], Reason=[DownReason], SignalledTunnelName=[SignalledTunnelName])

Description

A trap was generated when the current tunnel became faulty and went Down.

Parameters

Parameter Name	Parameter Meaning
TunnelId	Indicates the ID of the tunnel.
LocalLspId	Indicates the LSP ID of a session.
IngressLsrId	Indicates the LSR ID of the ingress on the tunnel.
EgressLsrId	Indicates the LSR ID of the egress on the tunnel.
OutIfIndex	Indicates the outgoing interface index of the ingress of the LSP that goes Down.
TunnelAdminStatus	Indicates the management status of the tunnel.
TunnelOperStatus	Indicates the operating status of the tunnel.
TunnelName	Indicates the name of the tunnel.
OutIfName	Indicates the name of the outgoing interface on the ingress of the LSP that goes Down.
SubReason	Indicates the sub-cause for identifying the alarm clearance type. The default value is 0 when an alarm is generated. The meaning of a different sub-cause value is as follows: 1: The alarm is cleared because related faults are rectified. 2: The alarm is cleared due to timeout. 3: The alarm is deleted.
DownReason	Indicates the reason of Tunnel down.
SignalledTunnelName	Tunnel alias.

Possible Causes

Cause 1: Others
Cause 2: A static LSP went Down.
Cause 3: A static CR-LSP went Down.
Cause 4: The outbound interface of an RSVP-TE LSP's ingress went Down.
Cause 5: RSVP-TE LSP resources were preempted.
Cause 6: Transmission of an RSVP message timed out.
Cause 7: RSVP Hello mechanism detected a downstream node failure.
Cause 8: The bypass tunnel in use was Down or unbound from the primary tunnel.
Cause 9: CSPF failed to calculate a path.
Cause 10: The tunnel was manually shut down.

Procedure

Cause 1: Others
1. Check whether the configurations for the current tunnel interface, RSVP, an IGP, link connectivity, and bandwidth for links along the tunnel are correct.
- If a configuration is incorrect, correct the configuration and commit the new configuration. Then check whether the tunnel is Up. If the tunnel goes Up, the alarm is cleared. If the tunnel is still Down, go to Step 4.
- If the alarm persists, go to Step 2.
2. Run the display mpls te tunnel-interface last-error command to check error information.
- Check possible causes for error information before proceeding to the next step:
- "Cspf failed to calculate a path for Tunnel": CSPF is enabled on the ingress but CSPF fails to calculate a path for the tunnel. Check whether configurations for explicit paths are correct, whether IS-IS TE or OSPF TE has been enabled, and whether routing configurations are correct.
- If the configuration is corrected, the alarm is cleared.
- If the alarm persists, go to Step 3.
- "Routing Problem:Bad EXPLICIT_ROUTE object." or "Routing Problem:Bad initial subobject.": The ingress is not enabled with CSPF and is configured with an incorrect explicit path. Configure a correct explicit path for the tunnel.
- If the configuration is corrected, the alarm is cleared.
- If the alarm persists, go to Step 3.
- "Routing Problem:No route available toward destination.": CSPF is not enabled on either the ingress or any transit node, or an incorrect explicit path or an unreachable route to the destination address is configured. Correctly reconfigure the explicit path or an IGP.
- If the configuration is corrected, the alarm is cleared.
- If the alarm persists, go to Step 3.
- "Service preempted": Tunnel resources are preempted. Reconfigure the setup and holding priorities on the tunnel interface.
- If the configuration is corrected, the alarm is cleared.
- If the alarm persists, go to Step 3.
- "Admission Control failure": The ingress is enabled with CSPF but its downstream nodes is not. Along an explicit path, CSPF counts the bandwidth: the bandwidth of the ingress is sufficient; but the link bandwidth of downstream nodes is insufficient. Check the explicit path and bandwidth configurations.
- If the configuration is corrected, the alarm is cleared.
- If the alarm persists, go to Step 3.
- If other errors occurs, go to Step 4.
- If no error information is displayed, go to Step 3.
3. Run the display mpls lsp statistics command to check whether the number of LSPs exceeds the upper limit. If the number of LSPs exceeds the upper limit, delete unwanted LSPs and check whether the alarm is cleared. If the alarm persists, go to Step 4.

4. Collect alarm information and configuration information, and then contact technical support personnel.

5. End.
Cause 2: A static LSP went Down.
The same as Cause 1.
Cause 3: A static CR-LSP went Down.
The same as Cause 1.
Cause 4: The outbound interface of an RSVP-TE LSP's ingress went Down.
The same as Cause 1.
Cause 5: RSVP-TE LSP resources were preempted.
The same as Cause 1.
Cause 6: Transmission of an RSVP message timed out.
The same as Cause 1.
Cause 7: RSVP Hello mechanism detected a downstream node failure.
The same as Cause 1.
Cause 8: The bypass tunnel in use was Down or unbound from the primary tunnel.
The same as Cause 1.
Cause 9: CSPF failed to calculate a path.
The same as Cause 1.
Cause 10: The tunnel was manually shut down.
The same as Cause 1.