MPLS_LSPM/3/hwMplsTunnelBesteffortDown_active

Message

MPLS_LSPM/3/hwMplsTunnelBesteffortDown_active: The best-effort LSP of the tunnel changes to Down. (SessionTunnelId=[SessionTunnelId], TunnelInstIndex=[TunnelInstIndex], IngressLsrId=[IngressLsrId], EgressLsrId=[EgressLsrId], mplsTunnelIfName=[mplsTunnelIfName], hwMplsTunnelDownReason=[hwMplsTunnelDownReason], hwMplsTunnelDownLSRId=[hwMplsTunnelDownLSRId], hwMplsTunnelDownIfAddrType=[hwMplsTunnelDownIfAddrType], hwMplsTunnelDownIfAddr=[hwMplsTunnelDownIfAddr], SignalledTunnelName=[SignalledTunnelName])

Description

A best-effort path went Down.

Parameters

Parameter Name	Parameter Meaning
SessionTunnelId	Indicates the ID of the tunnel.
TunnelInstIndex	Indicates the InstIndex of the tunnel.
IngressLsrId	Indicates the LSR ID of the ingress on the tunnel.
EgressLsrId	Indicates the LSR ID of the egress on the tunnel.
mplsTunnelIfName	Indicates the name of a tunnel.
hwMplsTunnelDownReason	The reason of Tunnel change to down.
hwMplsTunnelDownLSRId	The value of this object identifies the LSR ID of the error node on a tunnel.
hwMplsTunnelDownIfAddrType	The IP address type of the error interface on a tunnel.
hwMplsTunnelDownIfAddr	The IP address of the error interface on a tunnel
SignalledTunnelName	Indicates the alias of the tunnel.

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
Collect the alarm and configuration information, and contact technical support personnel.
Cause 2: A static LSP went Down.
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 alarm is cleared. If the alarm is cleared, go to Step 5. If not go to Step 4.
- If all configurations are correct and the alarm persists, go to Step 2.
2. Run the display mpls te tunnel-interface last-error command to check error information. And deal with the problem according to the error information. Then check whether the alarm is cleared.
- If so, go to Step 5.
- If not, 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 is cleared, go to Step 5. If the alarm persists, go to Step 4.
- If not, go to Step 4.
4.Collect alarm information and configuration information, and then contact technical support personnel.

5.End.
Cause 3: A static CR-LSP went Down.
The same as Cause 2.
Cause 4: The outbound interface of an RSVP-TE LSP's ingress went Down.
1. Check the configuration and status of the current tunnel interface. If the outbound interface is incorrectly configured, reconfigure it correctly. Then check whether the alarm is cleared.
- If so, go to Step 3.
- If not, go to Step 2.
2. Collect alarm information and configuration information, and then contact technical support personnel.

3.End.
Cause 5: RSVP-TE LSP resources were preempted.
1. Change the setup and holding priorities on the tunnel interface.Then check whether the alarm is cleared.
- If so, go to Step 3.
- If not, go to Step 2.
2. Collect alarm information and configuration information, and then contact technical support personnel.

3.End.
Cause 6: Transmission of an RSVP message timed out.
Collect alarm information and configuration information, and then contact technical support personnel.
Cause 7: RSVP Hello mechanism detected a downstream node failure.
1. Check configurations and statues of all downstream nodes of the ingress. Correct the configuration if there is an error. Then check whether the alarm is cleared.
- If so, go to Step 3.
- If not, go to Step 2.
2. Collect alarm information and configuration information, and then contact technical support personnel.

3.End.
Cause 8: The bypass tunnel in use was Down or unbound from the primary tunnel.
1. Run the display mpls te tunnel-interface command to check the status of the bypass tunnel. If a problem occurs, solve it and Then check whether the alarm is cleared.
- If so, go to Step 4.
- If not, go to Step 2.
2. Run the display mpls te tunnel verbose command to check the binding between the primary and bypass tunnel. If a problem occurs, solve it. Then check whether the alarm is cleared.
- If so, go to Step 4.
- If not, go to Step 3.
3. Collect alarm information and configuration information, and then contact technical support personnel.

4.End.
Cause 9: CSPF failed to calculate a path.
1. 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 a configuration is incorrect, correct the configuration and commit the new configuration. Then check whether the alarm is cleared. If the alarm is cleared, go to Step 3. If not go to Step 2.
- If all configurations are correct and the alarm persists, go to Step 2.
2. Collect alarm information and configuration information, and then contact technical support personnel.

3.End.
Cause 10: The tunnel was manually shut down.
1. Run the undo shutdown command in the tunnel interface view.Then check whether the alarm is cleared.
- If so, go to Step 3.
- If not, go to Step 2.
2. Collect alarm information and configuration information, and then contact technical support personnel.

3.End.