< Home

OSPFV3_1.3.6.1.4.1.2011.5.25.147.0.12 hwOspfv3NssaTranslatorStatusChange

Description

OSPFV3/3/NSSATRNSLTRSTSCHNG:OID [oid] The status of the NSSA translator has changed. (AreaId=[integer], RouterId=[gauge], State=[integer])

The translator role in the NSSA changed. A possible cause is that the status of the translator changed among Enabled, Elected, and Disabled.

Attribute

Alarm ID Alarm Severity Alarm Type
1.3.6.1.4.1.2011.5.25.147.0.12 Minor processingErrorAlarm(4)

Parameters

Name Meaning

oid

Indicates the MIB object ID of the alarm.

AreaId

Indicates the OSPFv3 area ID, which is a decimal integer.

RouterId

Indicates the router ID of the local device, which is a decimal integer.

State

Indicates the new status of the translator in the NSSA:
  • 1: enabled
  • 2: elected
  • 3: disabled

Impact on the System

ASE routes may flap for a short period in the following situations. The translator role of the NSSA ABR changes; Type 5 LSAs translated from Type 7 LSAs need to be flushed; or a new translator is translating Type 7 LSAs to Type 5 LSAs. In addition, the translator role changes without manual configuration mostly because the topology in the backbone area or the NSSA changes.

Possible Causes

1. The parameter translator-always in the nssa command was manually configured or canceled on an ABR in the NSSA.

2. A new router ID was configured on an ABR in the NSSA and took effect.

3. A new switch joined the NSSA or a switch exited from the NSSA.

4. The OSPFv3 protocol was restarted or the master/slave switchover was performed on a switch in the backbone area or the NSSA. This resulted in topology instability in the NSSA.

5. The nssa command was manually configured or the parameters in the nssa command were manually modified, which caused the topology of the backbone area or the NSSA changes. For example, configuring or canceling the parameter no-summary or no-import-route in the nssa command will lead to the reestablishment of neighbor relationships between the local switch and a switch in the backbone area, and between the local switch and a switch in the NSSA.

6. The role of the local switch changed to an ABR or changed from an ABR to another role.

7. The topology of the backbone area or the NSSA changed. As a result, the local switch cannot reach another ABR with a greater router ID or with the parameter translator-always from the backbone area or the NSSA.

Procedure

  1. If the nssa translator-always command is configured or canceled manually on the local switch, run the display ospfv3 area command to check whether the translator role of the local switch in the NSSA is correct.

    • If the nssa translator-always command is configured, run the display ospfv3 area command to check whether the status of the NSSA translator is always. If so, go to Step 8. If not, go to Step 7.

    • If the configuration of the nssa translator-always command is canceled, run the display ospfv3 area command to check the status of the NSSA translator. If the status is disabled, go to Step 2. If the status is elected, go to Step 8.

  2. A possible cause is that the nssa translator-always command is configured on an ABR in the NSSA. You can run the display ospfv3 lsdb routercommand to check whether the Router-LSA of a specific ABR in the NSSA carries the N bit. Alternatively, you can check whether the nssa translator-always is configured on other ABRs.

    • If the Router-LSA of a specific ABR carries the N bit or other ABRs are configured with the nssa translator-always command, go to Step 8.

    • If the Router-LSA of a specific ABR does not carry the N bit or other ABRs are not configured with the nssa translator-always command, go to Step 3.

  3. If a new router ID is configured on the local switch and already takes effect, after the topology in the area becomes stable, check whether the translator role of the local switch in the NSSA is correct.

    • If so, go to Step 8.

    • If not, go to Step 4.

  4. A possible cause is that a new router ID is configured on another ABR in the NSSA. In this case, check the configurations of other ABRs.

    • If the router ID of a specific ABR is changed, after the topology of the NSSA becomes stable, check whether the newly configured router ID is greater than the local router ID.
      • If so, go to Step 8.

      • If not, go to Step 5.

    • If the router ID of a specific ABR remains unchanged, go to Step 5.

  5. If a new switch joins the NSSA, do as follows as required:

    • If an ABR joins the NSSA, after the topology in the NSSA becomes stable, check whether the router ID of the ABR is greater than the local router ID.
      • If so, go to Step 8.

      • If not, go to Step 6.

    • If a non-ABR joins the NSSA, go to Step 6.

  6. Check whether the local switch and the neighboring switch have traps 1.3.6.1.2.1.14.16.2.1, 1.3.6.1.2.1.14.16.2.2, 1.3.6.1.2.1.14.16.2.3, and 1.3.6.1.2.1.14.16.2.16.

    • If the preceding traps are generated, refer to the related fault location procedure.
    • If the preceding traps are not generated, go to Step 7.

  7. Collect alarm information and configuration information, and then contact technical support personnel.
  8. End.

Related Information

None

Copyright © Huawei Technologies Co., Ltd.
Copyright © Huawei Technologies Co., Ltd.
< Previous topic Next topic >