Cautions for Recurring K Byte Caused by Optical Path Jitter of the RMS of the NG-SDH Product

[Problem Description]
Trigger conditions:
The RMS is in the switchover state, and the status of the Huawei optical fiber in the switchover section jitters. The MSprotocol repetitively switches between the state of waiting for recovery and the switchover state. As a result, the Kbyte in the loop recurs.

Fault symptom:
Scenario 1:
The services that pass through the switchover section remain interrupted. The MS protocol at the switchover site
stops and starts once every second. The APS_INDI alarm remains active, but does not change with the protocol.
The fault persists even after the optical path does not jitter.
Scenario 2
The services that pass the switchover section are interrupted and then automatically recovered.

Identification method:
1. Check whether the equipment is of versions listed in the “Related Version” row.
2. If the services are interrupted, query the BB9.log file of each cross-connect board in the MS ring. If a
cross-connect board has the following record, it indicates that a fault exists.
:log-query:10,”bb9.log”
bb9.log 2009-12-16 11:49:10 Level:2, RpsAdpt.cpp, Line:7404, PgId[1] RpsRestartProtocol
Success!
bb9.log 2009-12-16 11:49:15 Level:2, RpsAdpt.cpp, Line:7404, PgId[1] RpsRestartProtocol
Success!

[Root Cause]
To solve the problem of possible cross-connect board reset when the entire ring is in the pass-through state and
the K byte recurs frequently, the line board judges whether a frequently recurring K byte is received.
If a frequently recurring K byte is received, the line board requires the cross-connect board to restart the protocol
for self-healing.
If the line board does not judge whether a recurring K byte is received for multiple times in a second during
handling, the line board requires the cross-connect board to restart the protocol when a recurring K byte appears
for a long time.

[Impact and Risks]
When the optical path status changes frequently, the K byte recurs, leading to protocol restart. If the MS is in the switchover state, the services are interrupted transiently. If the K byte cycle is broken after protocol restart, the services are automatically recovered. Otherwise, the services remain interrupted.

[Measures and Solutions]
Recovery measures:
No intervention is required if the services are automatically recovered.
Recover the services as follows if the services remain interrupted:
1. Shut down the lasers at both ends of the switchover section.
2. Then clean the historical K bytes in all the line boards which belong to the MSP ring;
Use the following command:
:optp:bid (hex),0,9b,1,08,bc,portid(hex ),mspportid (hex, usually is 0)
OR soft reset all the line boards belong to the MSP ring.
3. Perform forcible switchover after the protocol restarts successfully.
4. Switch on the lasers. Cancel the forcible switchover after the status of the optical path in the switchover section becomes steady.

Workarounds:
None
Solutions:
Upgrade the NE software to the following versions:
V1R7C02SPC011 (5.xx.17.31p03) and later V1R7 version;
V1R8C02B01L (5.xx.18.50) + V1R8C02SPH011 and later V1R8 version;
V1R9C04SPC100 (5.21.19.22P01) and later version for MSTP TDM version;
V2R11C00 and later MSTP + version;
It is suggested to upgrade to the latest recommended maintenance version.

[Rectification Scope and Time Requirements]
If the V100R008C02B01L (5.**.18.50) version is adopted, the hot patch must be installed for rectification.

[Rectification Guide]
Install the hot patch of the V100R008C02SPH011 version on the cross-connect board to rectify the fault.
See the《 OptiX NG-SDH Product Hot Patch Version Upgrade Guide (Toolkit)-20091202-B》, or 《OptiX NG-SDH Product Hot Patch Version Upgrade Guide (Navigator)-20091202-B》.

Categories:

Comments are closed