MPLS_LSPM/2/hwMplsTunnelPrimaryDown_active

Message

MPLS_LSPM/2/hwMplsTunnelPrimaryDown_active: The primary 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

The primary LSP of the tunnel changes to 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	Indicates the reason why a tunnel goes Down.
hwMplsTunnelDownLSRId	Indicates the LSR ID of the error node on a tunnel.
hwMplsTunnelDownIfAddrType	Indicates the IP address type of the error interface on a tunnel.
hwMplsTunnelDownIfAddr	Indicates the IP address of the error interface on a tunnel.
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. Run the display mpls te tunnel-interface tunnel-name command on the ingress (that is, the node that generates the trap) to check the configurations of the tunnel. View the Tunnel State Desc field to check whether the tunnel is in the Down state Then, run the display mpls te tunnel-interface last-error command to view the prompt.
- In the case of the following error prompts, do as required:
- If the error prompt is "Cspf failed to calculate a path for Tunnel." (indicating that the ingress is enabled with CSPF, but the CSPF path calculation fails), go to Step 2.
- If the error prompt is "Trigger Rsvp failed", go to Step 2.
- If the error prompt is "One LSP is deleted at smooth period", go to Step 6.
- If the error prompt is "One LSP is deleted at Tunnel aging period", go to Step 6.
- For other types of errors, go to Step 6.
- If there is no error prompt, go to Step 2.
2. Run the ping command on the ingress to check whether the destination IP address of the tunnel can be pinged.
- If the ping fails, rectify the route fault to ensure that the destination IP address of the tunnel can be pinged, and then check whether the alarm MPLS_LSPM_1.3.6.1.4.1.2011.5.25.121.2.1.46 hwMplsTunnelPrimaryUp is generated.
- If so, go to Step 7.
- If not, go to Step 3.
- If the ping is successful, go to Step 3.
3. Run the display this command in the MPLS view of the ingress to check whether the mpls te cspf command is configured, that is, to check whether the CSPF is enabled.
- If so, go to Step 4.
- If not, go to Step 5.
4. Run the display mpls te cspf destination command on the ingress to check whether a path that meets the constraints is available. If so, the path of the TE tunnel is displayed, indicating that CSPF calculation is successful. If not, null is displayed, indicating that CSPF calculation fails.
- If the path is successfully calculated, run the display current-configuration interface interface-type interface-number command on the ingress to check the tunnel configurations, including the primary tunnel, protection tunnel, and the protection interface. Check whether the mpls te auto-frr command is configured in the MPLS view. If so, it indicates that Auto FRR is enabled. In this case, you can check the primary tunnel. If not, check whether the mpls te fast-reroute, mpls te record-route, and mpls te bypass-tunnel are configured to identify the primary and backup tunnels.
After the primary and backup tunnels are checked, you can check the explicit-path command to verify whether the explicit path is configured; check the mpls te affinity property command to verify whether the affinity property is configured; check the mpls te bandwidth command to verify whether the bandwidth is configured.

Run the display mpls te cspf destination command and configure the parameters of constraints one by one, including the priority (priority setup-priority), bandwidth (bandwidth), explicit path (explicit-path path-name), affinity property (affinity properties), and hop limit (hop-limit hop-limit-number), and you can check whether the path that meets the constraints is available. If so, the path of the TE tunnel is displayed, indicating that CSPF calculation is successful. If not, null is displayed, indicating that CSPF calculation fails.
- a. If the explicit path fails to be calculated, check whether the interfaces along the explicit path are in the Up state and are enabled with MPLS and MPLS TE. If the explicit path is successfully calculated, check whether path calculation according to the affinity property and bandwidth is consistent with the explicit path by running the display mpls te cspf destination ip-address bandwidth ct0 ct0-bandwidth explicit-path path-name command.
- b. If CSPF path calculation fails after affinity property is configured, run the mpls te affinity property command in the tunnel view to modify the affinity property of the tunnel, or run the mpls te link administrative group on the interfaces along the tunnel to modify the administrative group property of the link.
- c. If CSPF path calculation fails after bandwidth is configured, run the display mpls te link-administration bandwidth-allocation interface interface-type interface-number command to check whether the bandwidth of each outbound interface along the tunnel is enough. If the bandwidth is enough, it is possible that the tunnel with a higher priority preempts the bandwidth of the current tunnel. Then run the mpls te bandwidth max-reservable-bandwidth and mpls te bandwidth commands in the interface view to increase the bandwidth.
- d. If CSPF path calculation fails because of other constraints, go to Step 6.
- Then, check whether the alarm MPLS_LSPM_1.3.6.1.4.1.2011.5.25.121.2.1.46 hwMplsTunnelPrimaryUp is generated.
- If so, go to Stpe 7.
- If not, go to Step 5.
- If CSPF path calculation fails, go to Step 5.
5. Run the display explicit-path command to check the interfaces along the tunnel. Then, run the display this command in the interface view of each interface of the tunnel to check whether the interface is enabled with MPLS, MPLS TE, and RSVP-TE.
- If MPLS, MPLS TE, or RSVP-TE is not enabled, run the mpls, mpls te or mpls rsvp-te commands in the view of the interface.
- If any interface along the tunnel is not in Up state, restart the interface. That is, run the shutdown and then undo shutdown commands in the interface view, or run the restartcommand in the interface view .
Then, check whether the alarm MPLS_LSPM_1.3.6.1.4.1.2011.5.25.121.2.1.46 hwMplsTunnelPrimaryUp is generated.
- If so, go to Step 7.
- If not, go to Step 6.
6. Collect alarm information and configuration information, and then contact technical support personnel.

7. 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.