MSTP
- MSTP_1.3.6.1.2.1.17.0.1 newRoot
- MSTP_1.3.6.1.2.1.17.0.2 topologyChange
- MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.1 hwMstpiPortStateForwarding
- MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.2 hwMstpiPortStateDiscarding
- MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.3 hwMstpiBridgeLostRootPrimary
- MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.4 hwMstpiPortRootGuarded
- MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.5 hwMstpiPortBpduGuarded
- MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.6 hwMstpiPortLoopGuarded
- MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.7 hwMstpiEdgePortChanged
- MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.15 hwMstpiTcGuarded
- MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.16 hwMstpProTcGuarded
- MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.17 hwMstpProRootChanged
- MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.18 hwMstpProNewPortStateForwarding
- MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.19 hwMstpProNewPortStateDiscarding
- MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.20 hwMstpProNewBridgeLostRootPrimary
- MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.21 hwMstpProNewPortRootGuarded
- MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.22 hwMstpProNewPortBpduGuarded
- MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.23 hwMstpProNewPortLoopGuarded
- MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.24 hwMstpProNewEdgePortChanged
- MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.25 hwMstpProLoopbackDetected
- MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.26 hwMstpPortCountExceedThreshold
- MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.27 hwMstpPortCountExceedThresholdResume
- 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.29 hwMstpProRootResume
MSTP_1.3.6.1.2.1.17.0.1 newRoot
Description
MSTP/1/NEWRT:OID [oid] This bridge has changed to be the root bridge.
After the network converges, the local bridge is elected as the new root bridge in the topology.
Possible Causes
1. The local bridge is added into a new network topology.
2. The priority of the local bridge is increased.
3. The root bridge in the original topology is faulty.
4. The priority of the root bridge in the original topology is reduced.
Procedure
- Check whether the local bridge is added as a new node into
a Layer 2 network topology.
If so, go to Step 2.
If not, go to Step 5.
- Run the display stp [ process process-id ] [ instance instance-id ] [ interface interface-type interface-number | slot slot-id ] [ brief ] command to check whether the priority
of the local bridge is the lowest in the network. The lower the priority
of the local bridge is, the more possibly the bridge becomes the root
bridge.
If so, go to Step 3.
If not, go to Step 5.
- Check whether the local bridge is specified as the root
bridge in the Layer 2 network topology.
If so, go to Step 10.
If not, go to Step 4.
- Run the stp priority command to re-set the priority of the local bridge as required.
Alternatively, run the undo stp
priority command to restore the default priority of the
local bridge. Then, check whether the alarm is cleared.
If the alarm is cleared, go to Step 10.
If the alarm is not cleared, go to Step 5.
- Check whether a fault occurs in the original network topology.
If so, go to Step 6.
If not, go to Step 7.
- Rectify the fault in the original network topology. Then,
check whether the alarm is cleared.
If the alarm is cleared, go to Step 10.
If the alarm is not cleared, go to Step 7.
- Check whether the priority of the root bridge in the original
topology is lowered.
If so, go to Step 8.
If not, go to Step 9.
- Run the stp priority command or the stp root primary command on the original root bridge to re-specify the original root
bridge as the root bridge. Then, check whether the alarm is cleared.
If the alarm is cleared, go to Step 10.
If the alarm is not cleared, go to Step 9.
- Collect alarm information and configuration information, and then contact technical support personnel.
- End.
MSTP_1.3.6.1.2.1.17.0.2 topologyChange
Description
MSTP/1/TOPOC:OID [OID] Bridge topology change.
The topology calculated by the STP changes.
A topologyChange alarm is triggered if the status of an STP interface other than an edge interface changes from Blocking to Forwarding.
Possible Causes
1. The network topology changes because a new link is added into the network topology.
2. The network topology changes because interfaces go Up or Down.
3. The network topology changes because a device changed the priority.
4. The network topology changes because a device changed the priority, or an interface changed its priority or cost, which caused a change in the blocked interface.
Procedure
- View physical devices on the network to check whether new
physical connections enabled with STP are added.
If so, go to Step 2.
If not, go to Step 4.
- Check whether the added physical link is the required one.
If so, go to Step 3.
If not, go to Step 8.
- Run the display stp [ process process-id ] [ instance instance-id ] [ interface { interface-type interface-number [ to interface-number ] }&<1-10> ] [ brief ] command to check whether
the interfaces are consistent with the STP calculation results.
If so, go to Step 10.
If not, go to Step 4.
- Check whether the interfaces enabled with the STP protocol
go Up or Down in the network topology.
If so, go to Step 5.
If not, go to Step 6.
- Run the undo shutdown command in the interface view to check whether the alarm is cleared.
If so, go to Step 10.
If not, go to Step 6.
- Check whether a fault occurs in the original network topology.
If so, go to Step 7.
If not, go to Step 9.
- Rectify the fault in the original network topology. Then,
check whether the alarm is cleared.
If the alarm is cleared, go to Step 10.
If the alarm is not cleared, go to Step 9.
- Correctly deploy the network topology, and then check whether
the alarm is cleared.
If the alarm is cleared, go to Step 10.
If the alarm is not cleared, go to Step 3.
- Collect alarm information and configuration information, and then contact technical support personnel.
- End.
MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.1 hwMstpiPortStateForwarding
Description
MSTP/4/PFWD:OID [oid] The port has been set to forwarding state. (InstanceID=[INTEGER], PortInstanceID=[INTEGER], PortID=[INTEGER], IfIndex=[INTEGER], PortName=[STRING])
A new link is added and the port enters the forwarding state.
Attribute
Alarm ID | Alarm Severity | Alarm Type |
---|---|---|
1.3.6.1.4.1.2011.5.25.42.4.2.1 |
Warning |
communicationsAlarm(2) |
Parameters
Name | Meaning |
---|---|
oid |
Indicates the MIB object ID of the alarm. |
InstanceID |
Indicates the instance ID. |
PortInstanceID |
Indicates the ID of the instance to which the interface belongs. |
PortID |
Indicates the interface ID. |
IfIndex |
Indicates the interface index. |
PortName |
Indicates the interface name. |
Possible Causes
1.
A new link was added to the network topology, and the network topology changed.
2.
The network topology has changed, because a port may be up or down.
Procedure
- View physical devices on the network to check whether new physical connections enabled with STP are added.
If so, go to Step 2.
If not, go to Step 3.
- Check whether the added physical link is necessary.
If so, go to Step 3.
If not, go to Step 4.
- Run the display stp [ process process-id ] [ instance instance-id ] [ interface interface-type interface-number | slot slot-id ] [ brief ] command to check whether the interfaces are consistent with the STP calculation results.
If so, go to Step 6.
If not, go to Step 5.
- Correctly deploy the network topology, and then check whether the alarm is cleared.
If the alarm is cleared, go to Step 6.
If the alarm is not cleared, go to Step 3.
- Collect alarm information and configuration information, and then contact technical support personnel.
- End.
MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.2 hwMstpiPortStateDiscarding
Description
MSTP/4/PDISC:OID [oid] The port has been set to discarding state. (InstanceID=[INTEGER], PortInstanceID=[INTEGER], PortID=[INTEGER], IfIndex=[INTEGER], PortName=[STRING])
The link status changed, and the port enters the Discarding state.
Attribute
Alarm ID | Alarm Severity | Alarm Type |
---|---|---|
1.3.6.1.4.1.2011.5.25.42.4.2.2 |
Warning |
communicationsAlarm(2) |
Parameters
Name | Meaning |
---|---|
oid |
Indicates the MIB object ID of the alarm. |
InstanceID |
Indicates the instance ID. |
PortInstanceID |
Indicates the ID of the instance to which the interface belongs. |
PortID |
Indicates the port ID. |
IfIndex |
Indicates the interface index. |
PortName |
Indicates the interface name. |
Possible Causes
1.
The network topology changes that the port changes from the Forwarding state into the Discarding state.
2.
A new link is added. After the topology calculation, the port enters the Discarding state.
Procedure
- View physical devices on the network to check whether new physical connections enabled with STP are added.
If so, go to Step 2.
If not, go to Step 3.
- Check whether the added physical link is necessary.
If so, go to Step 3.
If not, go to Step 4.
- Run the display stp [ process process-id ] [ instance instance-id ] [ interface interface-type interface-number | slot slot-id ] [ brief ] command to check whether the interfaces are consistent with the STP calculation results.
If so, go to Step 6.
If not, go to Step 5.
- Correctly deploy the network topology, and then check whether the alarm is cleared.
If the alarm is cleared, go to Step 6.
If the alarm is not cleared, go to Step 3.
- Collect alarm information and configuration information, and then contact technical support personnel.
- End.
MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.3 hwMstpiBridgeLostRootPrimary
Description
MSTP/2/ROOT:OID [OID]: This bridge is no longer the root bridge of the instance [instance-id].
l switch lost its status as a root bridge. Another switch with a higher priority in the network replaced it and became the root bridge.
Attribute
Alarm ID | Alarm Severity | Alarm Type |
---|---|---|
1.3.6.1.4.1.2011.5.25.42.4.2.3 |
Major |
communicationsAlarm(2) |
Parameters
Name | Meaning |
---|---|
oid |
Indicates the MIB object ID of the alarm. |
instance-id |
Indicates the instance ID. |
Possible Causes
1.
A new link was added to the network topology, and the network topology changed. In addition, the newly-added device became the root bridge through the stp root primary command, with the MAC address smaller than that of the previous root bridge.
2.
The priorities of some switches changed in the network.
Procedure
- View physical devices on the network to check whether new physical connections enabled with STP are added.
If so, go to Step 2.
If not, go to Step 4.
- Check whether the added physical link is necessary.
If so, go to Step 3.
If not, go to Step 7.
- Run the display stp [ process process-id ] [ instance instance-id ] [ interface interface-type interface-number | slot slot-id ] [ brief ] command to check whether the interfaces are consistent with the STP calculation results.
If so, go to Step 9.
If not, go to Step 4.
- Run the display stp [ process process-id ] [ instance instance-id ] [ interface interface-type interface-number | slot slot-id ] [ brief ] command to check whether the priority of a bridge is changed in the network topology.
If so, go to Step 5.
If not, go to Step 8.
- Check whether the operation of changing the priority is correct.
If so, go to Step 9.
If not, go to Step 6.
- Run the stp priority command to re-set the priority of the local bridge as required. Alternatively, run the undo stp priority command to restore the default value of the priority of the local bridge. Then, check whether the alarm is cleared.
If the alarm is cleared, go to Step 9.
If the alarm is not cleared, go to Step 8.
- Correctly deploy the network topology, and then check whether the alarm is cleared.
If the alarm is cleared, go to Step 9.
If the alarm is not cleared, go to Step 3.
- Collect alarm information and configuration information, and then contact technical support personnel.
- End.
MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.4 hwMstpiPortRootGuarded
Description
MSTP/2/RGSUP:OID [oid] The ROOT-Protection port received superior message. (InstanceID=[INTEGER], PortInstanceID=[INTEGER], PortID=[INTEGER], IfIndex=[INTEGER], PortName=[STRING])
A switch with a higher priority outside the protection range of the root bridge attempted to become the root bridge.
Attribute
Alarm ID | Alarm Severity | Alarm Type |
---|---|---|
1.3.6.1.4.1.2011.5.25.42.4.2.4 |
Major |
communicationsAlarm(2) |
Parameters
Name | Meaning |
---|---|
OID |
Indicates the MIB object ID of the alarm. |
InstanceID |
Indicates the instance ID. |
PortInstanceID |
Indicates the instance ID of the port. |
PortID |
Indicates the port ID. |
IfIndex |
Indicates the interface index. |
PortName |
Indicates the port name. |
Possible Causes
Cause 1:
The port enabled with the root protection function received BPDUs of a higher priority than that of the bridge.
2:
The priority of some switch changed in the network.
Procedure
- View physical devices on the network to check whether new physical connections enabled with STP are added.
If so, go to Step 2.
If not, go to Step 4.
- Check whether the added physical link is necessary.
If so, go to Step 3.
If not, go to Step 7.
- Run the display stp [ process process-id ] [ instance instance-id ] [ interface interface-type interface-number | slot slot-id ] [ brief ] command to check whether the interfaces are consistent with the STP calculation results.
If so, go to Step 11.
If not, go to Step 4.
- Run the display stp [ process process-id ] [ instance instance-id ] [ interface interface-type interface-number | slot slot-id ] [ brief ] command to check whether the priority of a bridge is change in the network topology.
If so, go to Step 5.
If not, go to Step 8.
- Check whether the operation of changing the priority is correct.
If so, go to Step 8.
If not, go to Step 6.
- Run the stp priority command to re-set the priority of the local bridge as required. Alternatively, run the undo stp priority command or the undo stp priority command to restore the default value of the priority of the local bridge. Then, check whether the alarm is cleared.
If the alarm is cleared, go to Step 11.
If the alarm is not cleared, go to Step 8.
- Correctly deploy the network topology, and then check whether the alarm is cleared.
If the alarm is cleared, go to Step 11.
If the alarm is not cleared, go to Step 8.
- Run the display stp [ process process-id ] [ instance instance-id ] [ interface interface-type interface-number | slot slot-id ] [ brief ] command to check whether an interface under the protection of the root bridge.
If so, go to Step 9.
If not, go to Step 10.
- Run the undo stp root-protection command in the interface view to delete the configuration of the protection under the root bridge. Then, check whether the alarm is cleared.
If the alarm is cleared, go to Step 11.
If the alarm is not cleared, go to Step 10.
- Collect alarm information and configuration information, and then contact technical support personnel.
- End.
MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.5 hwMstpiPortBpduGuarded
Description
MSTP/2/IVBPDU:OID [oid] The edged-port that enabled BPDU-Protection will be shutdown, because it received BPDU packet. (InstanceID=[INTEGER], PortID=[INTEGER], IfIndex=[INTEGER], PortName=[STRING])
The port enabled with BPDU protection and connected to the user received BPDUs. These BPDUs are likely to be attack packets from the user.
Attribute
Alarm ID | Alarm Severity | Alarm Type |
---|---|---|
1.3.6.1.4.1.2011.5.25.42.4.2.5 | Major | communicationsAlarm(2) |
Parameters
Name | Meaning |
---|---|
oid |
Indicates the MIB object ID of the alarm. |
InstanceID |
Indicates the instance ID. |
PortID |
Indicates the port ID. |
IfIndex |
Indicates the interface index. |
PortName |
Indicates the port name. |
Procedure
- Check whether the interface should be specified as an edge
port.
If so, go to Step 2.
If not, go to Step 3.
- Locate the source of the BPDUs on the interface and check
whether the malicious attack exists.
If so, go to Step 4.
If not, go to Step 3.
- Run the undo stp edged-port command and then the undo shutdown command in the interface view to delete the configuration
of the edge port and restart the interface. Then, check whether the
alarm is cleared.
If the alarm is cleared, go to Step 5.
If the alarm is not cleared, go to Step 4.
- Collect alarm information and configuration information, and then contact technical support personnel.
- End.
MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.6 hwMstpiPortLoopGuarded
Description
MSTP/2/LGEXP:OID [OID] The LOOP-Protection port did not receive BPDU packets in prescriptive time. (InstanceID=[INTEGER], PortInstanceID=[INTEGER], PortID=[INTEGER], IfIndex=[INTEGER], PortName=[STRING])
A port enabled with loop protection failed to receive BPDUs within a specified period, and was set to be in the Discarding state.
Attribute
Alarm ID | Alarm Severity | Alarm Type |
---|---|---|
1.3.6.1.4.1.2011.5.25.42.4.2.6 |
Major |
communicationsAlarm(2) |
Parameters
Name | Meaning |
---|---|
oid |
Indicates the MIB object ID of the alarm. |
InstanceID |
Indicates the instance ID. |
PortInstanceID |
Indicates the instance ID of the port. |
PortID |
Indicates the port ID. |
IfIndex |
Indicates the interface index. |
PortName |
Indicates the port name. |
Possible Causes
1.
The peer switch did not send the BPDUs to the local switch within the specified period. The possible cause was that the spanning tree function was disabled on the peer switch.
2.
The links connected to the peer were congested. Check whether the traffic was normal.
Procedure
- Run the display stp [ process process-id ] [ instance instance-id ] [ interface interface-type interface-number | slot slot-id ] [ brief ] command to check whether STP is disabled on the interfaces that are directly connected.
If so, go to Step 3.
If not, go to Step 2.
- Run the display this interface command in the interface view to check the percentage of the rate at which the interface receives packets to the total bandwidth and then determine whether congestion occurs.
If so, go to Step 4.
If not, go to Step 5.
- Run the stp enable command in the interface view to enable STP. Then, check whether the alarm is cleared.
If the alarm is cleared, go to Step 6.
If the alarm is not cleared, go to Step 2.
- Repair the physical link and then check whether the alarm is cleared.
If the alarm is cleared, go to Step 6.
If the alarm is not cleared, go to Step 5.
- Collect alarm information and configuration information, and then contact technical support personnel.
- End.
MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.7 hwMstpiEdgePortChanged
Description
MSTP/4/EDGEPORT_DISABLE:OID [oid] When the port receives a BPDU packet, the edged-port attribute will be disabled. (InstanceID=[INTEGER], PortID=[INTEGER], IfIndex=[INTEGER], EdgePortEnableState=[INTEGER], PortName=[STRING])
The edge port lost the attributes of an edge port after receiving BPDUs.
Attribute
Alarm ID | Alarm Severity | Alarm Type |
---|---|---|
1.3.6.1.4.1.2011.5.25.42.4.2.7 | Warning | communicationsAlarm(2) |
Parameters
Name | Meaning |
---|---|
oid |
Indicates the MIB object ID of the alarm. |
InstanceID |
Indicates the instance ID. |
PortID |
Indicates the port ID. |
IfIndex |
Indicates the interface index. |
EdgePortEnableState |
Indicates whether BPDU-guard is enabled on the edge port. |
PortName |
Indicates the port name. |
Procedure
- Check whether the interface should be specified as an edge
port.
If so, go to Step 2.
If not, go to Step 3.
- Locate the source of the BPDUs on the interface and check
whether the malicious attack exists.
If so, go to Step 4.
If not, go to Step 3.
- Run the undo stp edged-port and undo shutdown commands in the interface view to delete the configuration
of the edge port and restart the interface. Then, check whether the
alarm is cleared.
If the alarm is cleared, go to Step 5.
If the alarm is not cleared, go to Step 4.
- Collect alarm information and configuration information, and then contact technical support personnel.
- End.
MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.15 hwMstpiTcGuarded
Description
MSTP/4/TCGUARD:OID [OID] The instance received TC message exceeded the threshold will be deferred to deal with at the end of TC protection time. (InstanceID=[INTEGER])
After the TC protection was enabled on the device that was enabled with MSTP, the TC packets, which were received after the number of TC packets received in a specified period had exceeded the threshold, were processed after the TC protection time expired.
Attribute
Alarm ID | Alarm Severity | Alarm Type |
---|---|---|
1.3.6.1.4.1.2011.5.25.42.4.2.15 | Warning | communicationsAlarm(2) |
Parameters
Name | Meaning |
---|---|
oid |
Indicates the MIB object ID of the alarm. |
InstanceID |
Indicates the instance ID. |
Impact on the System
If the number of TC packets exceeds the threshold, MAC entries and ARP entries will not be deleted immediately, and network topology will not be changed immediately, either.
Possible Causes
The TC packets, which were received after the number of TC packets received in a specified period had exceeded the threshold, were processed after the TC protection time expired.
Procedure
- Check whether the network topology flaps.
If so, go to Step 3.
If not, go to Step 2.
- Run the display stp [ process process-id ] [ instance instance-id ] [ interface interface-type interface-number | slot slot-id ] [ brief ] command to check whether the number of
TC BPDUs exceeds the set threshold on the interface.
If the alarm is cleared, go to Step 4.
If the alarm is not cleared, go to Step 7.
- Locate the cause of the network topology flapping and rectify
the fault. Then, check whether the alarm is cleared.
If the alarm is cleared, go to Step 8.
If the alarm is not cleared, go to Step 2.
- Run the stp tc-protection
threshold threshold command in the interface
view to re-set the maximum number of TC BPDUs that the device can
process. Then, check whether the alarm is cleared.
If the alarm is cleared, go to Step 8.
If the alarm is not cleared, go to Step 5.
- Check whether malicious attacks exist.
If so, go to Step 6.
If not, go to Step 7.
- Locate the attack source and remove the attack. Then, check
whether the alarm is cleared.
If the alarm is cleared, go to Step 8.
If the alarm is not cleared, go to Step 7.
- Collect alarm information and configuration information, and then contact technical support personnel.
- End.
MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.16 hwMstpProTcGuarded
Description
MSTP/1/PROTCGUARD:OID [OID] MSTP process's instance received TC message exceeded the threshold will be deferred to deal with at the end of TC protection time. (ProcessID=[INTEGER], InstanceID=[INTEGER])
After the TC protection of the MSTP process was enabled, the TC packets, which were received after the number of TC packets received by an instance had exceeded the threshold, were processed after the TC protection time expired.
Attribute
Alarm ID | Alarm Severity | Alarm Type |
---|---|---|
1.3.6.1.4.1.2011.5.25.42.4.2.16 | Critical | communicationsAlarm(2) |
Parameters
Name | Meaning |
---|---|
oid |
Indicates the MIB object ID of the alarm. |
ProcessID |
Indicates the ID of an MSTP process. |
InstanceID |
Indicates the ID of an MSTP instance. |
Impact on the System
If the number of TC BPDUs exceeds the threshold, MAC address entries and ARP entries will not be deleted immediately, and the traffic forwarding path will not be changed immediately, either.
Possible Causes
The TC packets, which were received after the number of TC messages received by an MSTP process in a specified period had exceeded the threshold, were processed after the TC protection time expired.
Procedure
- Check whether the network topology flaps.
If so, go to Step 3.
If not, go to Step 2.
- Run the display stp [ process process-id ] [ instance instance-id ] [ interface interface-type interface-number | slot slot-id ] [ brief ] command to check whether the number of
TC BPDUs exceeds the set threshold on the interface.
If so, go to Step 4.
If not, go to Step 7.
- Locate the cause of the network topology flapping and rectify
the fault. Then, check whether the alarm is cleared.
If the alarm is cleared, go to Step 8.
If the alarm is not cleared, go to Step 2.
- Run the stp tc-protection
threshold threshold command in the MSTP
process view to re-set the maximum number of TC BPDUs that the MSTP
process can process. Then, check whether the alarm is cleared.
If the alarm is cleared, go to Step 8.
If the alarm is not cleared, go to Step 5.
- Check whether the malicious attacks exist.
If so, go to Step 6.
If not, go to Step 7.
- Locate the attack source and remove the attack. Then, check
whether the alarm is cleared.
If the alarm is cleared, go to Step 8.
If the alarm is not cleared, go to Step 7.
- Collect alarm information and configuration information, and then contact technical support personnel.
- End.
MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.17 hwMstpProRootChanged
Description
MSTP/4/PRORTCHANGED:OID [oid] The root bridge of MSTP process has changed. (ProcessID=[INTEGER], InstanceID=[INTEGER], PortID=[INTEGER], PreviousRootBridgeID=[STRING], NewRootBridgeID=[STRING])
The root bridge changed. That is, a device became the root bridge or was not the root bridge any more.
Attribute
Alarm ID | Alarm Severity | Alarm Type |
---|---|---|
1.3.6.1.4.1.2011.5.25.42.4.2.17 | Warning | communicationsAlarm(2) |
Parameters
Name | Meaning |
---|---|
oid |
Indicates the MIB object ID of the alarm. |
ProcessID |
Indicates the ID of an MSTP process. |
InstanceID |
Indicates the instance ID. |
PortID |
Indicates the port ID. |
PreviousRootBridgeID |
Indicates the ID of the previous root bridge. |
NewRootBridgeID |
Indicates the ID of the new root bridge. |
Impact on the System
If the root bridge is not a core node, it will affect the performance of the entire network.
Possible Causes
1.
A new device was added, which had the optimal bridge ID.
2.
The priorities of the devices in the current network were modified.
3.
The domain configuration was modified.
Procedure
- View physical devices on the network to check whether new
physical links enabled with STP are added.
If so, go to Step 2.
If not, go to Step 3.
- Check whether the added physical link is required.
If so, go to Step 4.
If not, go to Step 5.
- Run the display stp [ process process-id ] [ instance instance-id ] [ interface interface-type interface-number | slot slot-id ] [ brief ] command to check whether the priority
vector of the instance is changed or the domain configuration is modified.
If so, go to Step 5.
If not, go to Step 4.
- Run the display stp [ process process-id ] [ instance instance-id ] [ interface interface-type interface-number | slot slot-id ] [ brief ] command to check whether the bridge ID
is optimal on the entire network.
If so, go to Step 6.
If not, go to Step 7.
- Correctly configure the device according to the topology,
and then check whether the alarm is cleared.
If the alarm is cleared, go to Step 8.
If the alarm is not cleared, go to Step 7.
- Check whether the bridge ID of the added device is the
optimal one on the entire network.
If so, go to Step 8.
If not, go to Step 5.
- Collect alarm information and configuration information, and then contact technical support personnel.
- End.
MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.18 hwMstpProNewPortStateForwarding
Description
MSTP/4/PROPFWD:OID [oid] The MSTP Process's Port has been set to forwarding state. (ProcessID=[INTEGER], InstanceID=[INTEGER], PortID1=[INTEGER], PortID2=[INTEGER], PortID3=[INTEGER], PortID4=[INTEGER], PortIDFlag=[INTEGER], IfIndex=[INTEGER], PortState=[INTEGER], PortName=[STRING])
The link status of MSTP process changed, and the port enters the forwarding state.
Attribute
Alarm ID | Alarm Severity | Alarm Type |
---|---|---|
1.3.6.1.4.1.2011.5.25.42.4.2.18 | Warning | communicationsAlarm(2) |
Parameters
Name | Meaning |
---|---|
oid |
Indicates the MIB object ID of the alarm. |
ProcessID |
Indicates the MSTP process ID |
InstanceID |
Indicates the instance ID. |
PortID1 |
Indicates ID 1 of the port in the MSTP process. |
PortID2 |
Indicates ID 2 of the port in the MSTP process. |
PortID3 |
Indicates ID 3 of the port in the MSTP process. |
PortID4 |
Indicates ID 4 of the port in the MSTP process. |
PortIDFlag |
Indicates the port flag. |
IfIndex |
Indicates the port index. |
PortState |
Indicates the port state. |
PortName |
Indicates the port name. |
Possible Causes
1.
A new link was added to the network topology, and the link status of MSTP process changed.
2.
The network topology changes that the port changes from the Blocked state into the Forwarding state.
Procedure
- View physical devices on the network to check whether new
physical connections enabled with STP are added.
If so, go to Step 2.
If not, go to Step 3.
- Check whether the added physical link is necessary.
If so, go to Step 3.
If not, go to Step 4.
- Run the display stp [ process process-id ] [ instance instance-id ] [ interface interface-type interface-number | slot slot-id ] [ brief ] command to check whether the interfaces
are consistent with the STP calculation results.
If so, go to Step 6.
If not, go to Step 5.
- Correctly deploy the network topology, and then check whether
the alarm is cleared.
If the alarm is cleared, go to Step 6.
If the alarm is not cleared, go to Step 3.
- Collect alarm information and configuration information, and then contact technical support personnel.
- End.
MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.19 hwMstpProNewPortStateDiscarding
Description
MSTP/4/PROPDISC:OID [oid] The MSTP Process's Port has been set to discarding state. (ProcessID=[INTEGER], InstanceID=[INTEGER], PortID1=[INTEGER], PortID2=[INTEGER], PortID3=[INTEGER], PortID4=[INTEGER], PortIDFlag=[INTEGER], IfIndex=[INTEGER], PortState=[INTEGER], PortName=[STRING])
The link status of MSTP process changed, and the port enters the Discarding state.
Attribute
Alarm ID | Alarm Severity | Alarm Type |
---|---|---|
1.3.6.1.4.1.2011.5.25.42.4.2.19 | Warning | communicationsAlarm(2) |
Parameters
Name | Meaning |
---|---|
oid |
Indicates the MIB object ID of the alarm. |
ProcessID |
Indicates the MSTP process ID |
InstanceID |
Indicates the instance ID. |
PortID1 |
Indicates ID 1 of the port in the MSTP process. |
PortID2 |
Indicates ID 2 of the port in the MSTP process. |
PortID3 |
Indicates ID 3 of the port in the MSTP process. |
PortID4 |
Indicates ID 4 of the port in the MSTP process. |
PortIDFlag |
Indicates the port flag. |
IfIndex |
Indicates the port index. |
PortState |
Indicates the port state. |
PortName |
Indicates the port name. |
Possible Causes
1.
The network topology changes that the port changes from the Forwarding state into the Discarding state.
2.
A new link is added. After the topology calculation, the port enters the Discarding state.
Procedure
- View physical devices on the network to check whether new
physical connections enabled with STP are added.
If so, go to Step 2.
If not, go to Step 3.
- Check whether the added physical link is necessary.
If so, go to Step 3.
If not, go to Step 4.
- Run the display stp [ process process-id ] [ instance instance-id ] [ interface interface-type interface-number | slot slot-id ] [ brief ] command to check whether the interfaces
are consistent with the STP calculation results.
If so, go to Step 6.
If not, go to Step 5.
- Correctly deploy the network topology, and then check whether
the alarm is cleared.
If the alarm is cleared, go to Step 6.
If the alarm is not cleared, go to Step 3.
- Collect alarm information and configuration information, and then contact technical support personnel.
- End.
MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.20 hwMstpProNewBridgeLostRootPrimary
Description
MSTP/1/PROROOT:OID [oid] MSTP process [process-id] is no longer the root bridge of the instance [instance-id].
The original MSTP process lost its status as a root bridge. Another MSTP process with a higher priority in the network replaced it and became the root bridge.
Attribute
Alarm ID | Alarm Severity | Alarm Type |
---|---|---|
1.3.6.1.4.1.2011.5.25.42.4.2.20 | Critical | communicationsAlarm(2) |
Parameters
Name | Meaning |
---|---|
oid |
Indicates the MIB object ID of the alarm. |
process-id |
Indicates the MSTP process ID. |
instance-id |
Indicates the instance ID. |
Possible Causes
1.
A new link was added to the network topology, and the network topology changed. In addition, the newly-added device became the root bridge through the stp root primary command, with the MAC address smaller than that of the previous root bridge.
2.
The priority of some switch changed in the network.
Procedure
- View physical devices on the network to check whether new
physical connections enabled with STP are added.
If so, go to Step 2.
If not, go to Step 4.
- Check whether the added physical link is necessary.
If so, go to Step 3.
If not, go to Step 7.
- Run the display stp [ process process-id ] [ instance instance-id ] [ interface interface-type interface-number | slot slot-id ] [ brief ] command to check whether the interfaces
are consistent with the STP calculation results.
If so, go to Step 9.
If not, go to Step 4.
- Run the display stp [ process process-id ] [ instance instance-id ] [ interface interface-type interface-number | slot slot-id ] [ brief ] command to check whether the priority
of a bridge is changed in the network topology.
If so, go to Step 5.
If not, go to Step 8.
- Check whether the operation of changing the priority is
correct.
If so, go to Step 9.
If not, go to Step 6.
- Run the stp priority command to re-set the priority of the local bridge as required.
Alternatively, run the stp root
primary command to restore the default priority of the local
bridge. Then, check whether the alarm is cleared.
If the alarm is cleared, go to Step 9.
If the alarm is not cleared, go to Step 8.
- Correctly deploy the network topology, and then check whether
the alarm is cleared.
If the alarm is cleared, go to Step 9.
If the alarm is not cleared, go to Step 3.
- Collect alarm information and configuration information, and then contact technical support personnel.
- End.
MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.21 hwMstpProNewPortRootGuarded
Description
MSTP/4/PRORGSUP:OID [oid] The MSTP process's instance's ROOT-Protection port received superior message. (ProcessID=[INTEGER], InstanceID=[INTEGER], PortID1=[INTEGER], PortID2=[INTEGER], PortID3=[INTEGER], PortID4=[INTEGER], PortIDFlag=[INTEGER], IfIndex=[INTEGER], PortState=[INTEGER], PortName=[STRING])
An MSTP process with a higher priority outside the protection range of the root bridge attempted to become the root bridge.
Attribute
Alarm ID | Alarm Severity | Alarm Type |
---|---|---|
1.3.6.1.4.1.2011.5.25.42.4.2.21 | Warning | communicationsAlarm(2) |
Parameters
Name | Meaning |
---|---|
oid |
Indicates the MIB object ID of the alarm. |
ProcessID |
Indicates the MSTP process ID |
InstanceID |
Indicates the instance ID. |
PortID1 |
Indicates ID 1 of the port in the MSTP process. |
PortID2 |
Indicates ID 2 of the port in the MSTP process. |
PortID3 |
Indicates ID 3 of the port in the MSTP process. |
PortID4 |
Indicates ID 4 of the port in the MSTP process. |
PortIDFlag |
Indicates the port flag. |
IfIndex |
Indicates the port index. |
PortState |
Indicates the port state. |
PortName |
Indicates the port name. |
Possible Causes
1.
In the MSTP process, the port configured with the root protection function received BPDUs of a higher priority than that of the bridge.
2.
The priorities of some MSTP processes changed in the network.
Procedure
- View physical devices on the network to check whether new
physical connections enabled with STP are added.
If so, go to Step 2.
If not, go to Step 4.
- Check whether the added physical link is necessary.
If so, go to Step 3.
If not, go to Step 7.
- Run the display stp [ process process-id ] [ instance instance-id ] [ interface interface-type interface-number | slot slot-id ] [ brief ] command to check whether the interfaces
are consistent with the STP calculation results.
If so, go to Step 11.
If not, go to Step 4.
- Run the display stp [ process process-id ] [ instance instance-id ] [ interface interface-type interface-number | slot slot-id ] [ brief ] command to check whether the priority
of a bridge is changed in the network topology.
If so, go to Step 5.
If not, go to Step 8.
- Check whether the operation of changing the priority is
correct.
If so, go to Step 8.
If not, go to Step 6.
- Run the stp priority command to re-set the priority of the local bridge as required.
Alternatively, run the undo stp
priority command or the undo stp root command to restore the default value of the
priority of the local bridge. Then, check whether the alarm is cleared.
If so, go to Step 11.
If not, go to Step 8.
- Correctly deploy the network topology, and then check whether
the alarm is cleared.
If so, go to Step 11.
If not, go to Step 8.
- Run the display stp [ process process-id ] [ instance instance-id ] [ interface interface-type interface-number | slot slot-id ] [ brief ] command to check whether an interface
is under the protection of the root bridge.
If so, go to Step 9.
If not, go to Step 10.
- Run the undo stp root-protection command in the interface view to disable the protection under the
root bridge. Then, check whether the alarm is cleared.
If so, go to Step 11.
If not, go to Step 10.
- Collect alarm information and configuration information, and then contact technical support personnel.
- End.
MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.22 hwMstpProNewPortBpduGuarded
Description
MSTP/4/PROIVBPDU:OID [oid] The MSTP process's edged-port that enabled BPDU-Protection will be shutdown, because it received BPDU packet. (ProcessID=[INTEGER], InstanceID=[INTEGER], PortID1=[INTEGER], PortID2=[INTEGER], PortID3=[INTEGER], PortID4=[INTEGER], PortIDFlag=[INTEGER], IfIndex=[INTEGER], PortState=[INTEGER], PortName=[STRING])
The port of MSTP process enabled with BPDU protection and connected to the user received BPDUs. These BPDUs are likely to be attack packets from the user.
Attribute
Alarm ID | Alarm Severity | Alarm Type |
---|---|---|
1.3.6.1.4.1.2011.5.25.42.4.2.22 | Warning | communicationsAlarm(2) |
Parameters
Name | Meaning |
---|---|
oid |
Indicates the MIB object ID of the alarm. |
ProcessID |
Indicates the MSTP process ID |
InstanceID |
Indicates the instance ID. |
PortID1 |
Indicates ID 1 of the port in the MSTP process. |
PortID2 |
Indicates ID 2 of the port in the MSTP process. |
PortID3 |
Indicates ID 3 of the port in the MSTP process. |
PortID4 |
Indicates ID 4 of the port in the MSTP process. |
PortIDFlag |
Indicates the port flag. |
IfIndex |
Indicates the port index. |
PortState |
Indicates the port state. |
PortName |
Indicates the port name. |
Possible Causes
In the MSTP process, the edge port received BPDUs, and BPDU protection was enabled globally.
Procedure
- Check whether the interface should be specified as an edge
port.
If so, go to Step 2.
If not, go to Step 3.
- Locate the source of the BPDUs on the interface and check
whether the malicious attack exists.
If so, go to Step 4.
If not, go to Step 3.
- Run the undo stp root-protection and undo shutdown commands in the interface view to delete the configuration
of the edge port and restart the interface. Then, check whether the
alarm is cleared.
If the alarm is cleared, go to Step 5.
If the alarm is not cleared, go to Step 4.
- Collect alarm information and configuration information, and then contact technical support personnel.
- End.
MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.23 hwMstpProNewPortLoopGuarded
Description
MSTP/4/PROLGEXP:OID [oid] The MSTP process's instance's LOOP-Protection port did not receive BPDU packets in prescriptive time. (ProcessID=[INTEGER], InstanceID=[INTEGER], PortID1=[INTEGER], PortID2=[INTEGER], PortID3=[INTEGER], PortID4=[INTEGER], PortIDFlag=[INTEGER], IfIndex=[INTEGER], PortState=[INTEGER], PortName=[STRING])
A port of MSTP process enabled with loop protection failed to receive BPDUs within a specified period, and was set to be in the Discarding state.
Attribute
Alarm ID | Alarm Severity | Alarm Type |
---|---|---|
1.3.6.1.4.1.2011.5.25.42.4.2.23 | Warning | communicationsAlarm(2) |
Parameters
Name | Meaning |
---|---|
oid |
Indicates the MIB object ID of the alarm. |
ProcessID |
Indicates the MSTP process ID |
InstanceID |
Indicates the instance ID. |
PortID1 |
Indicates ID 1 of the port in the MSTP process. |
PortID2 |
Indicates ID 2 of the port in the MSTP process. |
PortID3 |
Indicates ID 3 of the port in the MSTP process. |
PortID4 |
Indicates ID 4 of the port in the MSTP process. |
PortIDFlag |
Indicates the port flag. |
IfIndex |
Indicates the port index. |
PortState |
Indicates the port state. |
PortName |
Indicates the port name. |
Possible Causes
1.
The peer switch did not send the BPDUs to the local switch within the specified period. The possible cause was that the spanning tree function was disabled on the peer switch.
2.
The links connected to the peer were congested. Check whether the traffic was normal.
Procedure
- Run the display stp [ process process-id ] [ instance instance-id ] [ interface interface-type interface-number | slot slot-id ] [ brief ] command to check whether STP is disabled
on the interfaces that are directly connected.
If so, go to Step 3.
If the alarm is not cleared, go to Step 2.
- Run the display this
interface command in the interface view to check the percentage
of the rate at which the interface receives packets to the total bandwidth
and then determine whether congestion occurs.
If so, go to Step 4.
If not, go to Step 5.
- Run the stp enable command in the interface view to enable STP. Then, check whether
the alarm is cleared.
If the alarm is cleared, go to Step 6.
If the alarm is not cleared, go to Step 2.
- Repair the physical link and then check whether the alarm
is cleared.
If the alarm is cleared, go to Step 6.
If not, go to Step 5.
- Collect alarm information and configuration information, and then contact technical support personnel.
- End.
MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.24 hwMstpProNewEdgePortChanged
Description
MSTP/4/PROEDGEDISABLE:OID [oid] When the port receives a BPDU packet, the edged-port attribute will be disabled. (ProcessID=[INTEGER], InstanceID=[INTEGER], PortID1=[INTEGER], PortID2=[INTEGER], PortID3=[INTEGER], PortID4=[INTEGER], PortIDFlag=[INTEGER], IfIndex=[INTEGER], PortState=[INTEGER], PortName=[STRING])
The edge port of MSTP process lost the attributes of an edge port after receiving BPDUs.
Attribute
Alarm ID | Alarm Severity | Alarm Type |
---|---|---|
1.3.6.1.4.1.2011.5.25.42.4.2.24 | Warning | communicationsAlarm(2) |
Parameters
Name | Meaning |
---|---|
oid |
Indicates the MIB object ID of the alarm. |
ProcessID |
Indicates the MSTP process ID |
InstanceID |
Indicates the instance ID. |
PortID1 |
Indicates ID 1 of the port in the MSTP process. |
PortID2 |
Indicates ID 2 of the port in the MSTP process. |
PortID3 |
Indicates ID 3 of the port in the MSTP process. |
PortID4 |
Indicates ID 4 of the port in the MSTP process. |
PortIDFlag |
Indicates the port flag. |
IfIndex |
Indicates the port index. |
PortState |
Indicates the port state. |
PortName |
Indicates the port name. |
Procedure
- Check whether the interface should be specified as an edge
port.
If so, go to Step 2.
If not, go to Step 3.
- Locate the source of the BPDUs on the interface and check
whether the malicious attack exists.
If so, go to Step 4.
If not, go to Step 3.
- Run the undo stp edged-port command
and then the undo shutdown command in the interface
view to delete the configuration of the edge port and restart the
interface. Then, check whether the alarm is cleared.
If the alarm is cleared, go to Step 5.
If the alarm is not cleared, go to Step 4.
- Collect alarm information and configuration information, and then contact technical support personnel.
- End.
MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.25 hwMstpProLoopbackDetected
Description
MSTP/4/PROLBDETECTGED:OID [OID] The MSTP Process's Port has been set to discarding state because of detecting loopback. (ProcessID=[INTEGER], InstanceID=[INTEGER], PortID1=[INTEGER], PortID2=[INTEGER], PortID3=[INTEGER], PortID4=[INTEGER], PortIDFlag=[INTEGER], IfIndex=[INTEGER], PortState=[INTEGER], PortName=[STRING])
When port detected loopback, block the port and arise trap.
Attribute
Alarm ID | Alarm Severity | Alarm Type |
---|---|---|
1.3.6.1.4.1.2011.5.25.42.4.2.25 | Warning | communicationsAlarm(2) |
Parameters
Name | Meaning |
---|---|
OID |
Indicates the MIB object ID of the alarm. |
ProcessID |
Indicates the MSTP process ID |
InstanceID |
Indicates the instance ID. |
PortID1 |
Indicates ID 1 of the port in the MSTP process. |
PortID2 |
Indicates ID 2 of the port in the MSTP process. |
PortID3 |
Indicates ID 3 of the port in the MSTP process. |
PortID4 |
Indicates ID 4 of the port in the MSTP process. |
PortIDFlag |
Indicates the port flag. |
IfIndex |
Indicates the port index. |
PortState |
Indicates the port state. |
PortName |
Indicates the port name. |
Impact on the System
After detecting a port blocked by local loopback, the system considers that a network storm occurs and blocks the local port to prevent the network storm from affecting services of the entire network. Services on the block port will be interrupted.
Possible Causes
When the STP port of the equipment receiving BPDU with the same designated bridge ID and designated port ID as this equipment and port, STP blocks this port and arises this trap for loopback detection will lead loop.
Procedure
- Check whether the port where the alarm is generated is
configured with local loopback.
If so, go to Step 4.
If not, go to Step 2.
- Check whether there is a loop formed by a hub and devices,
one of which is connected to the port.
If so, go to Step 5.
If not, go to Step 3.
- Collect alarm information and configuration information, and then contact technical support personnel.
- Delete the local loopback configuration to solve the problem.
- Remove the self-loop network cable from the hub to solve the problem.
- End.
MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.26 hwMstpPortCountExceedThreshold
Description
MSTP/4/PORT_COUNT_EXCEED_THRESHOLD: OID [OID] The number of Up STP-capable interfaces exceeded the upper threshold, which may overload the CPU. Delete redundant member interfaces. (UpperThreshold=[INTEGER])
The number of STP interfaces that were Up on a device exceeded the upper threshold.
Attribute
Alarm ID | Alarm Severity | Alarm Type |
---|---|---|
1.3.6.1.4.1.2011.5.25.42.4.2.26 | Warning | communicationsAlarm(2) |
Parameters
Name | Meaning |
---|---|
OID | Indicates the MIB object ID of the alarm. |
UpperThreshold | Upper threshold for the number of STP interfaces that are Up |
Possible Causes
Cause 1:
The number of STP interfaces that were Up on a device exceeded the upper threshold.
Procedure
- Run the display stp
brief command and display
interface brief command to check the STP interfaces that
are Up.
If some of the interfaces can have SPT disabled, go to Step 2.
If all the interfaces cannot have SPT disabled, go to Step 3.
- Run the stp disable or undo stp enable command in the interface view to disable STP and check whether the
device still receives this alarm.
If the device no longer receives this alarm, the alarm is cleared.
If the device still receives this alarm, the number of STP interfaces that are Up remains greater than the upper threshold. In this situation, go to Step 2.
- Collect alarm information and configuration information, and then contact technical support personnel.
MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.27 hwMstpPortCountExceedThresholdResume
Description
MSTP/4/PORT_COUNT_UNDER_THRESHOLD: OID [OID] The number of Up STP-capable interfaces fell below the lower threshold.(LowerThreshold=[INTEGER])
The number of STP interfaces that were Up on a device fell below the lower threshold.
Attribute
Alarm ID | Alarm Severity | Alarm Type |
---|---|---|
1.3.6.1.4.1.2011.5.25.42.4.2.27 | Warning | communicationsAlarm(2) |
Parameters
Name | Meaning |
---|---|
OID | Indicates the MIB object ID of the alarm. |
LowerThreshold | Lower threshold for the number of STP interfaces that are Up |
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.
Procedure
- 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.
- 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.
- Run the display stp [ process process-id ] [ instance instance-id ] [ interface interface-type
interface-number | 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.
- 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.
- Run the display stp [ process process-id ] [ instance instance-id ] [ interface interface-type
interface-number | 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.
- 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.
- 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.
- 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.
- 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.
- Collect alarm information and configuration information, and then contact technical support personnel.
- End.
MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.29 hwMstpProRootResume
Description
MSTP/4/PROROOTRESUME: OID [OID] The bridge resumes the position of root bridge.(ProcessID=[ProcessID], InstanceID=[InstanceID])
The device in an MSTP process had its root bridge role resumed.
Attribute
Alarm ID | Alarm Severity | Alarm Type |
---|---|---|
1.3.6.1.4.1.2011.5.25.42.4.2.29 | Warning | equipmentAlarm(5) |
Parameters
Name | Meaning |
---|---|
OID |
Indicates the MIB object ID of the alarm. |
ProcessID |
Process ID. |
InstanceID |
Instance ID. |
- MSTP_1.3.6.1.2.1.17.0.1 newRoot
- MSTP_1.3.6.1.2.1.17.0.2 topologyChange
- MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.1 hwMstpiPortStateForwarding
- MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.2 hwMstpiPortStateDiscarding
- MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.3 hwMstpiBridgeLostRootPrimary
- MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.4 hwMstpiPortRootGuarded
- MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.5 hwMstpiPortBpduGuarded
- MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.6 hwMstpiPortLoopGuarded
- MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.7 hwMstpiEdgePortChanged
- MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.15 hwMstpiTcGuarded
- MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.16 hwMstpProTcGuarded
- MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.17 hwMstpProRootChanged
- MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.18 hwMstpProNewPortStateForwarding
- MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.19 hwMstpProNewPortStateDiscarding
- MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.20 hwMstpProNewBridgeLostRootPrimary
- MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.21 hwMstpProNewPortRootGuarded
- MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.22 hwMstpProNewPortBpduGuarded
- MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.23 hwMstpProNewPortLoopGuarded
- MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.24 hwMstpProNewEdgePortChanged
- MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.25 hwMstpProLoopbackDetected
- MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.26 hwMstpPortCountExceedThreshold
- MSTP_1.3.6.1.4.1.2011.5.25.42.4.2.27 hwMstpPortCountExceedThresholdResume
- 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.29 hwMstpProRootResume