OSPF/4/OSPF_NSSA_TRANS_STATE_CHG

Message

OSPF/4/OSPF_NSSA_TRANS_STATE_CHG: The status of the NSSA translator changes. (RouterId=[RouterId], AreaId=[AreaId], NSSATranslatorState=[NSSATranslatorState], ProcessId=[ProcessId])

Description

The NSSA translator state of a device changed between Enabled, Elected, and Disabled.

Parameters

Parameter Name	Parameter Meaning
RouterId	Router ID of the local device.
AreaId	ID of an NSSA.
NSSATranslatorState	Current NSSA translator state: 1: ENABLED 2: ELECTED 3: DISABLED
ProcessId	Process ID of the local device.

Possible Causes

Cause 1: The translator-always parameter of the nssa command was configured or canceled on an ABR in the NSSA.
Cause 2: A new router ID has been configured for an ABR in the NSSA, and the configuration has taken effect.
Cause 3: A new device was added to the NSSA, or a device was removed from the NSSA.
Cause 4: In the backbone area or NSSA, the OSPF protocol was restarted or an active/standby switchover was performed on a device, causing topology flapping.
Cause 5: Manual command configuration or parameter modification caused a topology change in the backbone area or NSSA.

For example, the no-summary and no-import-route parameters of the nssa command were configured or canceled. As a result, neighbor relationships between the local device and neighbors in the backbone area and NSSA need to be re-established.

Cause 6: The local device changed to be an ABR or changed from an ABR to another role.
Cause 7: The topology of the backbone area or NSSA changed. As a result, the local device could not route traffic from the backbone area or NSSA to an ABR with a larger router ID or with the translator-always parameter configured.

Procedure

1. If the nssa translator-always command has been configured or canceled on the local device, run the display ospf brief command to check whether the NSSA translator state of the local device is correct.

If yes, go to Step 11.
If no, go to Step 2.

2. If the nssa translator-always command has been configured for an ABR in the NSSA, run the display ospf lsdb router command to check whether the Nt bit in the Router-LSA of an ABR changes or check whether the nssa translator-always command has been configured for another ABR.

If the Nt bit changes, check whether the NSSA translator state of the local device is correct.
If yes, go to Step 11.
If no, go to Step 3.
If the Nt bit does not change, go to Step 3.

3. If a new router ID is configured on the local device and takes effect, check whether the NSSA translator state of the local device is correct after the topology in the NSSA is stable.

If yes, go to Step 11.
If no, go to Step 4.

4. If a new router ID has been configured for an ABR other than the translator in the NSSA, check the configuration of this ABR.

4. If the router ID of an ABR changes, check whether the NSSA translator state of the local device is correct after the topology in the NSSA is stable.

If yes, go to Step 11.
If no, go to Step 5.

5. If a new device is added to the NSSA or a device is removed from the NSSA:

If no ABR is added to or removed from the NSSA, check whether the NSSA translator state of the local device is restored after the topology in the NSSA is stable.
If yes, go to Step 11.
If no, go to Step 6.
If an ABR is added to or removed from the NSSA, check whether the NSSA translator state of the local device is correct after the topology in the NSSA is stable.
If yes, go to Step 11.
If no, go to Step 6.

6. If manual command configuration or parameter modification causes topology flapping in the backbone area or NSSA, check whether the local device has been restored to the original NSSA translator state after the topology in the NSSA becomes stable.

If yes, go to Step 11.
If no, go to Step 7.

7. Run the display ospf brief command to check whether the ABR role of the local device changes.

If the change of the ABR role is caused by manual configuration, check whether the NSSA translator state of the local device is correct.
If yes, go to Step 11.
If no, go to Step 8.
If the role of the ABR changes without manual intervention, check whether the OSPF_1.3.6.1.2.1.14.16.2.2 ospfNbrStateChange alarm is generated on the local device and its neighbor.
If yes, locate the fault according to the procedure for processing the OSPF_1.3.6.1.2.1.14.16.2.2 ospfNbrStateChange alarm.
If no, go to Step 8.

8. If the translator state of the local device changes from DISABLED to ELECTED, but an ABR with a larger router ID or with the translator-always parameter configured exists in the NSSA, run the display ospf routing router-id [router-id] command to check whether there are backbone-area and NSSA routes to the original forwarder.

If yes, go to Step 11.
If not, the topology of the backbone area or NSSA changes. In this case, go to Step 10.

9. Check whether the OSPF_1.3.6.1.2.1.14.16.2.2 ospfNbrStateChange alarm is generated on the local and neighboring devices.

If any of the preceding alarms is generated, clear the alarm according to the related alarm handling procedure. After the topology in the NSSA is stable, check whether the local device has been restored to the original NSSA translator state.
If yes, go to Step 11.
If not, go to Step 10.
If none of the preceding alarms is generated, go to Step 11.

10. Collect log and configuration information, and contact Huawei technical support personnel.

11. End.