SSN3GSCC

What you’ll do when NESF_LOST displayed after a software Upgrade?

Sometime after a software Upgrade from V1R8C02SPC200 to V1R10C03SPC203 one OSN3500 with two GSCC boards displayed the alarm NESF_LOST.

NESF_LOST was reported in the standby GSCC board. 

NESF_LOST inform us that there are missing software files in the GSCC board. According to the alarm parameters it is possible to know which files are missing 

It was necessary to find out why some files were deleted from one GSCC board after some time. It was necessary to check in detail the Upgrade guide. 

According to the guide: 

“If an NE is already upgraded by using the package loading method, the software loaded through simulation package loading is overwritten by the software loaded through package loading. As a result, simulation package loading fails. Package loading supports automatic software matching. When the system detects that on a board, the software loaded through simulation package loading is different from the software loaded through package loading, the system delivers the latter to the board. This leads to a failure of simulation package loading. To avoid this failure, you need to clear the software package  stored on the CF card of the SCC board and the package loading information on boards”. 



The U2000 always sends :sftm-clr-pkg:0 to clear the software package information when you start an Upgrade task, however this command does not clear the package information in the standby GSCC so some files of this board will be deleted after the Upgrade. 



N/A1, check the current alarm 

#9-12853:szhw [PRIN121 TX2                                                     ][][2013-09-03 05:20:49+08:00]> 

:alm-get-curdata:0,0 

                                                                                    CUR-ALM                                                                                    

  NUM         BID   EID                               SEVERITY    STATE       START-TIME                     END-TIME                       PARA1  PARA2  PARA3  PARA4  PARA5  

   607626      17    NESF_LOST                         CR          start       2013-09-03 05:04:03+08:00      None                           0x01   0x00   0x40   0x01   0xff   

  607627      17    NESF_LOST                         CR          start       2013-09-03 05:04:03+08:00      None                           0x01   0x00    0x41   0x01   0xff   

  607628      17    NESF_LOST                         CR          start       2013-09-03 05:04:03+08:00      None                           0x01   0x00    0x4e   0x01   0xff   

  607629      17    NESF_LOST                         CR          start       2013-09-03 05:04:03+08:00      None                           0x01   0x00   0x4f   0x01   0xff   

  Total records :16                         

Record the parameter 3 on each NESF_LOST alarm. 

2, to confirm which files are lost. 

Check the realchannel and status,if the  realchannel is 64, 65,78,79( 0x40,0x41,0x4e,0x4f) and status is 1, we can know those files are lost. 

#9-12853:szhw [PRIN121 TX2                                                     ][][2013-09-03 05:27:49+08:00]> 

:sftm-get-fpatrol-info:17 

                                                FPATORL_INFO                                                 

  FileName                          AlmId   Channel  RealChannel  Status  FileType  MonSlaveVer  MonBakVer   

  ofs1/hwx/pnp35.ini                215     2        84           0       3         2            2           

  ofs2/hwx/pnp35.ini                215     4        85           0       3         2            1           

  ofs1/hwx/pnp.ini                  215     6        82           0       3         2            2           

  ofs2/hwx/pnp.ini                  215     8        83           0       3         2            1           

   ofs1/fpga/ssn5gscc.pga            215     10       64           1       3         2            2
ofs2/fpga/ssn5gscc.pga            215     12       65           1       3         2            1          
 

  ofs1/hwx/3500app.hwx              215     14       66           0       3         2            2           

  ofs2/hwx/3500app.hwx              215     16       67           0       3         2            1           

  ofs1/hwx/n53500.hwx               215     18       68           0       3         2            2           

  ofs2/hwx/n53500.hwx               215     20       69           0       3         2            1      

  …………..    

    ofs1/hwx/n5ebios.hwx              215     38       78           1       3         2            1
ofs2/hwx/n5ebios.hwx              215     40       79           1       3         2            2       
    

  ofs1/hwx/bdver.ini                215     42       80           0       3         2            2            

  ofs2/hwx/bdver.ini                215     44       81           0       3         2            1           

  ofs1/hwx/dkm.ini                  215     46       33           0       3         2            2           

  ofs2/hwx/dkm.ini                  215     48       34           0       3         2            1           

   …………. 

3, copy the files from slot 18, because this GSCC board has the right files. 

  

:sftm-copy-file:18,” ofs1/fpga/ssn5gscc.pga”,17,” ofs1/fpga/ssn5gscc.pga” 

:sftm-copy-file:18,” ofs2/fpga/ssn5gscc.pga”,17,” ofs2/fpga/ssn5gscc.pga” 

:sftm-copy-file:18,” ofs1/hwx/n5ebios.hwx”,17,” ofs1/hwx/n5ebios.hwx” 

:sftm-copy-file:18,” ofs2/hwx/n5ebios.hwx”,17,” ofs2/hwx/n5ebios.hwx” 

  

After we finish this operation, we need hard reset the GSCC board in slot 17. 

In order to avoid this alarm after an Upgrade is necessary to clear the package loading information before performing the Upgrade. 



On the Navigator, run the :sftm-clr-pkg:0 command to clear the software package of CF card. 

Unfortunately, this command only clears the  package loading information in the working GSCC, so it is necessary to delete manually the ne.pkg file in the standby GSCC. Run the :sftm-clr-pkg:bid (bid indicates slot ID of the standby GSCC board) command to remove the software package information from the standby SCC board. 



Please notice that Is possible to check run  :sftm-show-dir:bid,”ofs1/pkg”  , no ne.pkg file has to be displayed.  (bid indicates slot ID of the working or standby GSCC board) 



This could be applied to any type of NG SDH NE, not only OSN3500. 

Thunder-link.com now have all versions of GSCC: N1GSCC,  N3GSCCN4GSCCN6GSCC. All are original new and have very competitve price. The highest discount reach  98% off list price. Do not hesitate, just come to visit www.thunder-link.com; or email for inquire: sales@thunder-link.com

Categories:

Comments are closed