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

The NE ID and IP of the standby SCC board are changed and the NE becomes unmanageable after the switching between the active and standby SCC boards

Publication Date:  2012-07-24 Views:  38 Downloads:  0
Issue Description
One day, software upgrade is performed for the OSN 1500 of an office. The NE ID of 315. Before the upgrade, we check the batch backup state of the active and standby SCC board, and the state is normal. After the standby SCC board (in slot 83) is upgraded, we perform cold reset. When the cold reset succeeds, perform another cold reset for the active SCC board (in slot 82) for the purpose of forced switching. After the switching, the NE becomes unreachable to the T2000, but the service is normal, and the ACTC indicator of the standby SCC board is on.      
Alarm Information
None      
Handling Process
1. The ACTC indicator of the standby SCC board is on. This indicates the active/standby switching is successful, that is, the standby SCC board (83) is active already.
2. Unplug the current active SCC board (83) to switch back to the original active SCC board (82), and find everything recovers to normal.
3. Perform cold reset of the SCC board (82) to switch over forcibly, and the NE becomes unmanageable again. Now log in to the neighboring NE 316 to query the ECC route, but no NE with ID 315 is found.
4. Log in to NE 316 and run :cm-get-bdinfo; to query ECC distribution of the NE. The results are: For the optical board connected directly with NE 315, the ECC number of slot 5 is 1 and the state is normal.
5. Log in to NE 316 and run :cm-get-maccon; to query the link data on the physical layer. The result is: The NE connected directly with slot 5 of the optical board has an ID of 0x0004004e.
6. Log in to the NE with an ID of 0x0004004e. Consequently, we find it is exactly NE 315. We query the IP address and the result is 3.1.4.78, which does not belong to the default network segment 129.9.x.x.
7. Change the NE ID to 9-315, and change the IP address to 129.9.0.1, and the NE resets automatically. Upon successful reset, everything recovers to normal, and the problem is solved.       
Root Cause
The NE ID and IP of the standby SCC board are changed and thus conflict with the NE ID on the NMS.      
Suggestions
1. This case may occur when the NE IP, ID and NodeID (which are all stored in the system parameter area) are upgraded after they are downgraded for modification.
2. This board is not downgraded on the site or in the period from deployment to upgrade. Occurrence of such a case may result from change of the NE ID and IP, and the change is probably caused by downgrade operation in the factory and upgrade operation on the site.       

END