PORTSWITCH-FAIL alarm processing

14

1. Perform a cold reset on the board. The alarm persists.
2. Remove and re-insert the board onsite. The alarm is cleared.

Other related questions:
Method used to process and analyze the CPW_OTU_TEL_PATHMIS alarm
1. Possible causes for the CPW_OTUk_TEL_PATHMIS alarm are as follows: (1) The optical-layer ASON and electrical-layer ASON are enabled at the same time. (2) The resource reservation statuses on the source and sink boards are inconsistent. (3) The resource occupancy statuses on the source and sink boards are inconsistent. (4) The cross-connection configurations on the source and sink boards are inconsistent. (5) The networkwide electrical-layer flooding modes are inconsistent. 2. Solutions: (1) Possible cause 1: If the optical-layer ASON and electrical-layer ASON are enabled at the same time but the electrical-layer ASON is not required, disable the electrical-layer ASON. (2) Possible cause 2: Confirm with the customer to change the resource reservation statuses to the same. (3) Possible cause 3: Confirm with the customer to change the resource occupation statuses to the same. (4) Possible cause 4: Check the channel occupation statuses at both ends of the link. If the link is occupied by static services at one end but is occupied by ASON services at the other end, downgrade ASON services to static services. Check whether the egress channel is idle but the ingress channel is not. If unidirectional cross-connections are residual, delete unidirectional cross-connections or add reversed cross-connections. (5) Possible cause 5: Change the flooding modes of networkwide electrical-layer links to the same.

Processing of transient TF alarms on WDM equipment
The processing rules are as follows: 1. If the TF alarm is reported by TC1 or TC2, directly replace the board no matter whether the alarm is reported transiently or persistently. 2. For 71SC1/71SC2: a. If the TF alarm is transiently reported, upgrade the board software to 1.12 or a later version. b. If the TF alarm persists for 5s or longer, or the alarm is still transiently reported after the board software upgrade, replace the board. Most transient TF alarms can be avoided by software upgrades. 3. E1SC1/SC2: a. If the TF alarm is transiently reported, upgrade the board software to 1.27 or a later version. For versions earlier than 1.27, the workarounds are not complete therefore the board software upgrade cannot avoid this alarm. b. If the TF alarm persists for 5s or longer, or the alarm is still transiently reported after the board software upgrade, replace the board. Most transient TF alarms can be avoided by software upgrades.

How to solve MAC address flapping on S series switch
Firstly, check whether a loop occurs on the network. Secondly, use one of the following methods to prevent MAC address flapping: 1. Run the mac-address static mac-address command in the system view to configure static MAC addresses on an interface. 2. Configure the MAC address learning priority on an interface. That is, run the mac-learning priority priority-id command in the interface view on modular switches or S5720HI, S6720EI, and S5720EI fixed switches or run the mac-spoofing-defend enable command in the interface view on S5700LI, S5700S-LI, S5710-X-LI, S2750EI, S5720S-SI, and S5720SI fixed switches. After different MAC address learning priorities are configured for interfaces, only the MAC address entry learned by a high-priority interface can overwrite that learned by a low-priority interface if different interfaces have learned the same MAC address entry. This prevents MAC address flapping. Note that SA cards of modular switches do not support the MAC address learning priority configuration. You can run the undo mac-learning priority priority-id allow-flapping command in the system view to prohibit MAC address flapping between interfaces with the same priority.

Failed to report eService alarms
Why does an eService alarm fail to be reported and how do I resolve the problem? 1. The network connection between eService and the device that is responsible for reporting alarms is abnormal. Handling method: Check whether the network configuration between the eService program and the reporting device is correct. If the network configuration is incorrect, configure the network again. 2. The SNMP Agent process is not started. Handling method: Log in to the device and start the SNMP Agent process. 3. SNMP communication parameters are incorrectly configured. Handling method: Correctly configure the SNMP communication parameters. For details about how to set SNMP parameters, see section 2.1.5 "Preparing Information for Configuration" in the eService User Guide.

If you have more questions, you can seek help from following ways:
To iKnow To Live Chat
Scroll to top