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

Fail to query MSP Ring Switching status after GSCC upgrade

Publication Date:  2012-07-25 Views:  34 Downloads:  0
Issue Description

During the upgrade process of the TBGA/FLOR OSN 3500 Equipment from V1R2 to V1R3 and error message appeared related one of the SL4 boards that had a Ring MSP configured. The upgrade of the N1GSCC board had just been finished, the nesoft, FPGA and extended BIOS were correctly uploaded to the board and the Basic BIOS was uploaded and activated apparently with no problems. But when querying the MS parameters of the protection subnet through T2000 to know the switching status of the Ring, the following error message appeared (picture attached):

Querying of the MS maintenance parameter failed. Error code: 1090603123


As a result the status of the MS protocol was not updated (picture attached). The protection did actually exist; it was checked by T2000 and Navigator). But as did not refresh it, we did not know if the ring was switched or on idle state which put under risk the traffic of the node considering that the upgrade process was not finished and line boards would need to hard reset.



Alarm Information
Querying of the MS maintenance parameter failed. Error code: 1090603123



Query of switching status not updated:





Handling Process
First we tried to query the status of the ring several times on the Protection subnet parameters with the same result. Then we performed upload in all the equipments of the ring and query the switching status again but this was not refreshed.

After that we queried the status of the protocol in each node belonging to the ring, we noted that on one of the equipments Buc Lago 9500 belonging to that ring,the status of one of the line interfaces related to that MSP appeared as unknown. Picture attacted.


We tried then to stop and restart the protocol under the Protection Subnet Maintenance menu of the T2000 but the status did not refresh. Next we tried to stop and restart the protocol but this time in each one of the equipments, but the same result was obtained, it did not refresh the switching status of the ring.

We decided then to delete the MS Protection subnet and perform the search of the protection subnet. This process succeded partially showing a similar error message than the one referenced before (picture attached):



This time the error code was: 1090603116 (Checking network-wide MS parameters failed). Then it was decided to delete it again and create it but this time node by node creating the respective protection group. To do this we put especial atention to the connections among sites, node IDs, SD, WTR, mapping direction, etc. After this was done and the switching status was queried again it finally showed the current status as idle. (picture attached)




After this was executed, no further problems were presented and the upgrade process could be continued and successfully ended with no services reported as affected.




Root Cause
During the upgrade process an inconsistency between the NMS and the NE information related to the configured MS parameters occurred. During the upgrade a consistency check was required before continuing with the process, this consistency check was not completely successful and some invalid path ID errors related to the J2 byte configuration were shown (picture attached). We consider this







Suggestions
When upgrading a NG-SDH Equipment from V1R2 to V1R3 that has MSP Rings configured, you have to be especially careful with the switching status of the configured protections. An upload to all the equipments of the ring is suggested and also to perform a query on all the MSP protections subnets configured on that ring and check that the switching status is coherent with the network conditions before proceding with the upgrade.

If abnormalities are found on the protection subnets parameters, first try to solve them before perform the upgrade. If cannot solve them and the upgrade is required, backup information is crucial in case protection subnets need to be recreated as in this case. If this is necessary, query again the switching status of the rings to confirm they are related with the network conditions.


END