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

port status of EOS board displayed on U2000 mismatch the actual status due to collaboration exception of SCC and NMS

Publication Date:  2012-07-25 Views:  126 Downloads:  0
Issue Description
it is found in operation status & service is OK has no problem we have OOS alarm ,the Ethernet board used is EGS2 and the ver. of OSN is 5.21.18.50p01
Why the operational status of all Ethernet ports in the network are showing Out Of Service (OOS) even though they are in service. help with an explanation as to why a working port is showing OOS instead of IS-NR? We need to know why all the ports are in maintenance mode when they are supposed to be in service mode.
The Huawei RNC and Errison RNC all connect to EGS2 port, while the Errison RNC seems have service difficulty.
SCC version:5.21.18.50P01
Board version:
SSN2 EGS2 5.50
SSN2 EFS4 1.17
NMS version:
U2000 V1R2C01SPC100

Alarm Information
OOS
Handling Process

1. Firstly, we run the EGS2 data collector script on navigator, feedback the result to R&D , after

analyzing it, they found there was no problem.

2. Secondly, ask the experts on NMS to confirm it, they explained the port status displayed on NMS is according to the query result of SCC, so we need go for SCC experts for deepen analysis.

3. We can use “cfg-get-stam” command to query the port status on navigator, for example,

:cfg-get-stam:1,29,1,1
STAM-STATE
LEVEL BID PORT PATH ADMIN AU LPBK
1 29 1 1 1 1 0
Total records :1
Focus on the “ADMIN,AU and LPBK” section, the result could only be 0 and 1 for each section, in this example, SCC would send the 110 to NMS, there are 8 kinds of combination, we define the combination of 110 as “IS-NR” in version V1R8 ,but the NMS display “OOS-AUMA”, so this problem was caused by the collaboration exception of SCC and NMS.

4. We organized a conference ,asking experts on SCC and NMS to get together to solve this problem, through check over all the version of MSTP,MSTP+ and DWDM , we get a conclusion as following:

a. All versions of MSTP+ and NGSDH R8C02 , partly versions of DWDM are consistent with T2000,but opposite with the interface documents.

b. NGSDH R9 and later version are consistent with U2000, consistent with the interface documents

So this problem was caused by the collaboration exception of SCC and NMS.


Root Cause
V1R8 is a mainstream version, it is steady, it is not possible to break out so many problem in a time,
It is confirmed by R&D that it is not a known issue, we suspect it maybe an error caused by NMS.


Suggestions
Work around:upgrade to the V1R9 or later version, or use T2000 to manage NEs
solution:experts on NMS modify the code to solve this issue

END