No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

Alarm Handling

AR100, AR120, AR160, AR1200, AR2200, AR3200, and AR3600 V300R003

This document provides the trap description, attributes, parameters, impact on the system, possible causes, procedures, and references. This document provides a complete set of traps, through which intended readers are kept of the running status of the device so as to locate faults.
Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.28 hwMstpProRootLost

MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.28 hwMstpProRootLost

Description

MSTP/4/PROROOTLOST: OID [OID] The bridge loses the position of root bridge.(ProcessID=[ProcessID], InstanceID=[InstanceID])

The device in an MSTP process lost its root bridge role.

Attribute

Alarm ID Alarm Severity Alarm Type
1.3.6.1.4.1.2011.5.25.42.4.2.28 Warning equipmentAlarm(5)

Parameters

Name Meaning

OID

Indicates the MIB object ID of the alarm.

ProcessID

Process ID.

InstanceID

Instance ID.

Impact on the System

The network topology will be changed, and traffic will be forwarded through a new path.

Possible Causes

After a root bridge was specified using the stp [ instance instance-id ] root primary command in the MSTP process or system view, a device whose priority changed to 0 became the new root bridge.

NOTE:
This alarm is not triggered in an instance with a non-zero ID of a process with a non-zero ID.

Procedure

  1. View physical devices on the network and check whether a new STP-enabled physical link is added to the topology.

    • If such a link is added, go to Step 2.

    • If no such link is added, go to Step 5.

  2. Check whether the added physical link is the required one.

    • If the link is required, go to Step 3.

    • If the link is not required, go to Step 9.

  3. Run the display stp [ process process-id ] [ instance instance-id ] [ interface interface-type interface-number | vsi vsi-name pw pw-name | slot slot-id ] [ brief ] command to check whether the added device is the root bridge.

    • If the device is the root bridge, go to Step 4.

    • If the device is not the root bridge, go to Step 5.

  4. Check whether the priority of the added device is proper.

    • If the priority is proper, go to Step 8.

    • If the priority is improper, go to Step 9.

  5. Run the display stp [ process process-id ] [ instance instance-id ] [ interface interface-type interface-number | vsi vsi-name pw pw-name | slot slot-id ] [ brief ] command to check whether a device's priority is changed in the network topology.

    • If a device's priority is changed, go to Step 6.

    • If no device's priority is changed, go to Step 10.

  6. Check whether the priority modification is proper.

    • If the modification is proper, go to Step 8.

    • If the modification is improper, go to Step 7.

  7. Run the stp [ instance instance-id ] priority priority command in the system view or MSTP process view of the device whose priority has been changed to re-set its priority as needed. Alternatively, run the undo stp [ instance instance-id ] priority or undo stp [ instance instance-id ] root command to restore the default priority. Check whether the alarm is cleared.

    • If the alarm is cleared, go to Step 11.

    • If the alarm persists, go to Step 9.

  8. Run the undo stp [ instance instance-id ] root command in the system view or MSTP process view of the device that has lost the root bridge role. Then check whether the alarm is cleared.

    • If the alarm is cleared, go to Step 11.

    • If the alarm persists, go to Step 10.

  9. Correct the network topology and check whether the alarm is cleared.

    • If the alarm is cleared, go to Step 11.

    • If the alarm persists, go to Step 10.

  10. Collect alarm information and configuration information, and then contact technical support personnel.
  11. End.

Related Information

None

Translation
Download
Updated: 2019-03-06

Document ID: EDOC1100041475

Views: 70323

Downloads: 45

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next