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


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


ECC Fails Because the SL64 Optical Board on the OptiX OSN 3500 Is Faulty

Publication Date:  2019-07-03 Views:  165 Downloads:  0

Issue Description

NEs 170, 178, 179, 180, 181, and 182 form an  ring counter clockwise. NE 170 is the OptiX OSN 7500, and other NEs are OptiX OSN 3500s. At site 178, the ECC link management shows that packets from NE 178 to NE 170 are forwarded by NE 179. NE 170, that is, 11-T2SL64, is interconnect with NE 178, that is, 8-N2SL64. multi-section protection

Alarm Information


Handling Process

1) Run CM-GET-BDINFO at the NMS. The execution result shows that the ECC assignment at NE 170 is normal.
The result is as follows: FIBER-PORT-STATE 
                  BID   PORT  PORT-STATE    PORT-RATE     LINK-CHAN  LOGIC-CHAN-STATE                  
                  6     1     port-enable   D1-D3         0          ok                                
                  6     2     port-enable   D1-D3         1          ok                                
                  7     1     port-enable   D1-D3         2          ok                                
                  8     1     port-enable   D1-D3         3          ok                                
                  11    1     port-enable   D1-D3         4          ok                                
                  12    1     port-enable   D1-D3         5          ok                                
                  13    1     port-enable   D1-D3         6          ok               
Run cm-get-chaninfo: 4 to check the ECC channel status of the corresponding board. The received and transmitted bytes are increasing. For details, see the attachment. In the displayed message, however, the DNEID is 0X00FFFFFF, and the SNEID is 0x000900b2(178).
2) Run cm-get-bdinfo at NE 178. The execution result shows that receiving fails.
                  BID   PORT  PORT-STATE    PORT-RATE     LINK-CHAN  LOGIC-CHAN-STATE                  
                  8     1     port-enable   D1-D3         0          rx_f                              
                  11    1     port-enable   D1-D3         1          ok  
Run cm-get-chaninfo:0 to query the data. The result shows only the transmitted bytes but no received bytes. In the displayed message, however, the DNEID is 0000000000, and the SNEID is 0000000000.
3) Run cm-get-chanerror at NEs 170 and 178. The execution result shows that no bit errors occur in the ECC channels of the two boards.
4) Perform a cold reset on the GSCC at sites 170 and 178. The fault persists. Perform a cold reset on the SL64 boards at sites 170 and 178. The fault persists.
5) Replace the SL64 board at site 178. The fault is rectified. 

Root Cause

1) The settings of the ECCs at sites 170 and 178 are incorrect. For example, the ECC is disabled, or the bytes used are different.
2) The number of ECC channels is insufficient.
3) The SCC board is faulty.
4) The line board is faulty.
5) Other faults occur. For example, the settings of the switch for checking the ECC protocol stack are different. 


The causes of the ECC fault are as follows: bit errors, inconsistent ECC check status, port assignment, enabling status, channel byte (D1-D12,D1-D3,D4-D12), host, and line board. The cm-get-eccroute, cm-get-bdinfo, cm-get-chaninfo, and cm-get-chanerror commands are useful to locate the fault. You can locate the faulty sites and the faulty boards by analyzing the returned parameters.