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

Master & slave GSCC boards failed to complete batch backup after software up gradation to V1R8C02SPC200 version.

Publication Date:  2012-07-25 Views:  61 Downloads:  0
Issue Description
Equipment Type: OSN-3500 (including extended sub rack)
Version before up gradation: 5.21.17.31P01
Target version for up gradation: 5.21.18.50P01
GSCC boards type: SSN3GSCC
It was required to upgrade the software version of NG-SDH (OSN-3500 & OSN-7500) from V1R6 & V1R7 (EOS & EOFS) to V1R8. During the software up gradation activities, onsite engineer checked the batch backup status which was normal 
0x00000003. After the completion of software up gradation to 5.21.18.50P01 (V1R8C02SPC200), it was observed that the active/standby GSCC boards failed to 
batch backup and remained in 0x00000002 state. After sometime GSCC boards failed to batch backup and SYNC_FAIL alarm appeared.
Alarm Information
SYNC_FAIL
Handling Process
Following steps were performed to handle and solve GSCC batch backup issue.
1- After the completion of the software up gradation to 5.21.18.50P01 (V1R8C02SPC200) batch backup was checked by hbu-get-backup-info command and the out put was 0x00000002 for long time which indicates that the batch backup is in progress. After waiting for 15 minutes the batch backup 
state changed to 0x00000000 and SYNC_FAIL alarm appeared on GSCC board. After this Soft reset was performed on standby GSCC board and checked but all 
in vain.
2- After above step, standby GSCC board was replaced with new board and upgraded to 5.21.18.50P01. Same problem occurred after replacing the board. 
3- After the above step, soft reset performed on AUX boards of main and extended sub rack but problem not resolved. 
4- Then the extended sub rack was disconnected from main sub rack by disconnecting the AUX cable. After doing this step, GSCC batch backup was checked and 
found normal (0x00000003). Then again extended sub rack cable was connected and after soft resetting standby GSCC board, batch backup was failed.
5- After all above steps, NE database, configuration data, History alarms and MO backup was forwarded to R&D for the further analysis of the problem.
6- R&D simulate this problem in lab and tested that after upgrading the NE version to 5.21.18.50P01, the GSCC board's memory is not sufficient for fully loaded main 
& extended sub rack equipment because 5.21.18.50P01 version supports other features occupying the GSCC memory. Therefore when the batch backup was 
completed after disconnecting the extended sub rack. At the time of GSCC batch backup for fully loaded equipment with extended sub rack more GSCC memory 
required as shown in the logs below. This is 5.21.18.50P01 software defect.
 bb0.log        2010-11-09 18:38:13          ErrCode:0xffffffff, Level:3, File:hbu_msg.cpp, Line:6621, Info:VFS_FRead     
  bb0.log        2010-11-09 18:38:17          ErrCode:0xffffffff, Level:3, File:dbms_file.cpp, Line:2633, Info:/drdb/db/BdInst.dbf                
  bb0.log        2010-11-09 18:38:17          ErrCode:0xffffffff, Level:3, File:dbms_hbu.cpp, Line:4655, Info:Dbms Copy From DRDB                 
  bb0.log        2010-11-09 18:38:18          ErrCode:0x2002, Level:3, File:dbms_hbu.cpp, Line:4788, Info:2(4:)            
copy(/drdb/db/BdInst.dbf,/tdrdb/db/BdInst.dbf) = ffffffff;
0x4966460 (017tDbmsDBT): memPartAlloc: block too big - 131072 in partition 0x2ec2fac.0x4966460 (017tDbmsDBT): 
ERROR!! copy(\ofs1\db\USER.DBF,\ofs2\db\USER.DBF) = ffffffff;
0x4966460 (017tDbmsDBT): memPartAlloc: block too big - 131072 in partition 0x2ec2fac.0x4966460 (017tDbmsDBT): 
ERROR!! copy(\ofs1\db\NSAPADDR.DBF,\ofs2\db\NSAPADDR.DBF) = ffffffff;0x4966460 (017tDbmsDBT)
Therefore when GSCC board tried to batch backup the configuration, batch backup failed due to the insufficient memory at that time.
7- After the above analysis, R&D suggested to upgrade the equipment (having extended sub rack) of 5.21.18.50P01 NE version to new 5.21.18.53 version which 
solved this problem.
8- According to R&D suggestion NE was upgraded to 5.21.18.53 (V1R8C02SPC300) version and after up gradation, it was found that the GSCC batch backup was 
completed because in this version the GSCC memory is enhanced as shown below.
memShow
 status    bytes     blocks   avg block  max block
 ------ ---------- --------- ---------- ----------
current
   free    7735048        38     203553    4600728   remaining system memory 7.37M
  alloc   34784632      3146      11056          -
cumulative
  alloc 1810020584   1655199       1093          -
value = 0 = 0x0
      
Root Cause
Following are the possible causes of GSCC batch backup failure.
1- Master and slave GSCC board's version mismatch.
2- GSCC board's database problem.
3- GSCC board's memory issue at the time of batch backup process.
3- GSCC board's hardware fault.
Suggestions
Dont upgrade the NE version of the OSN-3500 & OSN7500 equipment having extended subrack to 5.21.18.50P01 version. Directly upgrade to 5.21.18.53 or the later version suggested by R&D.

END