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>

Reminder

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

upgrade

NEs Interconnecting with Competitor Equipment Are Frequently Disconnected with the NMS Because DCC Channels Are Not Disabled

Publication Date:  2012-08-12 Views:  402 Downloads:  0
Issue Description
Customers feed back that two OptiX OSN 7500s on the MSP ring of an OptiX OSN 7500 are disconnected with the NMS for a short time in an office. The NE software of the OptiX OSN 7500 is 5.21.16.13P02. The version of the T2000 is T2000V200R004C01B01cSPC003. 
Alarm Information
The NMS reports NE_NOT_LOGIN and NE_COMMU_BREAK. 
Handling Process
Disable the DCC channels of the connected optical interfaces to solve the problem. 
Root Cause
Check the networking first. The network is an MSP protection ring composed of seven OptiX OSN 7500s. Two NEs incurring disconnection are not gateways. The networking topology is as follows: 
  
(1) No disconnection occurs on other NEs of the network, and gateways have not any problem. Thus, you can make sure that the DCN has no problem, and the ECC is highly unlikely to be faulty.
(2) According to the alarm information of two problematic NEs, communication interruption occurs on them at the same time, and remains within 10 seconds. It is improbably that two NEs incur faults simultaneously. Therefore, one of the NEs must have failed, causing ECC failure for both NEs.
(3) According to the network topology, two problematic NEs are neighbors, and the BMVLC exists between the short ECC path and the gateway BMSCB1. Because seven NEs are connected in a ring, data communication chooses the other direction of the ring (that is, switching to the ECC route) if any optical fiber incurs a fault. Therefore, ECC communication may be faulty between the BMCEJ and the BMVLC, thus causing temporary NE disconnection.
(4) The performance is normal on the optical path between BMCEJ and BMVLC. Because the fibers on the BMVLC are connected normally, check the data of the BMCEJ. According to the result of the cm-get-bdinfo command, the BMCEJ has ECC information on several optical interfaces. These interfaces are all connected with company A’s transmission equipment. When the DCC channels are disabled, NE disconnection does not occur any more.
Therefore, the problem lies in the non-disabled DCC channels of the optical interfaces connected with company A’s equipment. The NEs receive a great deal of illegal ECC information, thus causing ECC handling failure. According to the black box data from the front line, many error records about ECC handling exist. These records show that the NEs receive error packets exceeding the maximum length allowed by the ECC protocol stack. Relevant records are as follows:
bb0.log 2007-11-06 21:21:24 ErrCode:0x5fe, Level:3, File:ecc_hwecc.cpp, Line:235, Info:dwBufLen
bb0.log 2007-11-06 21:21:24 ErrCode:0x5fe, Level:3, File:ecc_hwecc.cpp, Line:235, Info:dwBufLen
bb0.log 2007-11-06 21:21:24 ErrCode:0x5fe, Level:3, File:ecc_hwecc.cpp, Line:235, Info:dwBufLen
bb0.log 2007-11-06 21:21:25 ErrCode:0x5fe, Level:3, File:ecc_hwecc.cpp, Line:235, Info:dwBufLen
bb0.log 2007-11-06 21:21:25 ErrCode:0x5fe, Level:3, File:ecc_hwecc.cpp, Line:235, Info:dwBufLen
bb0.log 2007-11-06 21:21:25 ErrCode:0x5fe, Level:3, File:ecc_hwecc.cpp, Line:235, Info:dwBufLen
bb0.log 2007-11-06 21:21:25 ErrCode:0x5fe, Level:3, File:ecc_hwecc.cpp, Line:235, Info:dwBufLen 
Suggestions
For safe and mitigation of unexpected risks, it is recommended to disable DCC channels of all optical interfaces connected with competitors' equipment. 

END