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

RTN900 series version display incorrect in T2000 because the database was not cleared properly during the upgrading using FTP method

Publication Date:  2012-07-25 Views:  57 Downloads:  0
Issue Description
A large number of the RTN950/910 is display as “5.76.01.15” in T2000. It should display as V100R001C00SPC100 or SPC101. Actually “5.76.01.15” is the internal version identifier which also identify as 
V100R001C00SPC101. 
This phenomenon is happen after a case of upgrading a number of RTN in the warehouse, which involve using FTP method which is not recommended. 
Alarm Information
Null
Handling Process
Perform “delete database” on the RTN refresh/rebuild database automatically to enable T2000 to recognized it as RTN equipment.
1. Firstly recommend using DC to upgrade the RTN. Before upgrading, locate the RTN and increase the bandwidth for the inband DCN because this will help speed up the loading software stage to the RTN. To do 
the select RTN, go to NE explorer>Communication>DCN Management. *Before perform upgrade, make sure critical alarm which will affect the DCN/upgrade cleared.*
 
2. Create a task in DC in T2000 or DC client which is upgrade task. Go to Data Center>Task Management
 
3. Start the task after creating it, recommend to check “Load software, Dispense, Activate, Commit”. Picture shown above was because the Software was loaded to the RTN CF before I create the task to continue the 
remaining steps.
 
4. Upon finishing the upgrade, Go to the Device Operation and click on “Get version” button to verify the version that obtain in T2000.
 
5. T2000 has shown the correct version, I logged into Navigator and use the command to verify :-
:sftm-get-testver:7
:ver
BIOS        8.29.02T05 20090416 11:05:59 inactive
ExtBios     9.29.03T01 20090604 10:35:55 active
NeSoft(D)   5.76.01.15 20090826 09:11:58
Platform(D) 5.00.21.223 20090709 20:34:58
AosSoft(D)  5.99.31.03.B01h 20090706 12:02:22
Logic       (U63)130
Dsp    
:sftm-query-pkgver 
:swdl-rtrv-pkgver
Active Standby
V100R001C00SPC101 V100R001C00SPC101
Root Cause
1. The first step taken was communicating with the R&D in HQ regarding the FTP method which is used to upgrade the RTN. Due to the reason the R&D engineer has left the country thus we don’t have the exact 
details, especially the file use and the step by step taken by him to upgrade the RTN.
2. I then use the Navigator to connect to the RTN and perform certain commands to verify the version that is in the RTN :-
:sftm-get-testver:7
:ver
:cfg-get-devicetype
BIOS        8.29.02T05 20090416 11:05:59 inactive
ExtBios     9.29.03T01 20090604 10:35:55 active
NeSoft(D)   5.76.01.15 20090826 09:11:58
Platform(D) 5.00.21.223 20090709 20:34:58
AosSoft(D)  5.99.31.03.B01h 20090706 12:02:22
Logic       (U63)130
Dsp    
DEVICE-TYPE
OptiXPTN950
Based on the date shown, it is correct version that loaded into the RTN.
But the device-type is shown incorrect.
3. Further discussion with the R&D conclude that the database was not cleared properly during the upgrading using FTP method. R&D has encountered this situation before and thus the conclusion of deleting 
database will be able to resolve this issue.
Suggestions
The RTN not reading the version from CF card; and obtaining from other area. The version displayed was not correct due to improper upgrade to the RTN.
During upgrade using DC, in the Loading Software stage, it will push the file into the CF card in RTN; then in the Dispense stage, it will perform clearing up the file and dispense the file from CF to internal memory 
of the RTN. Bear in mind, that the software upgrade file always remain in the CF as a backup. Even after the RTN is finish upgrade, the files inside the CF is always remain. Thus the RTN normally obtain the 
version of it from the CF card file.
How does this happen?
The upgrade for the RTN occurred as a case of RTN in the warehouse was using TR5 version and it is deems as not usable in the market. Thus a recommendation to upgrade the RTN before leaving the 
warehouse was initiated. An R&D engineer was involved in the upgrading the RTN, and as this is a new equipment which release, thus compatibility issues occurred with the DC to upgrade the RTN.
In the mist of urgent delivery to the RTN to install the equipment, the FTP method is used during the upgrade of the RTN.
Let me briefly explain how the FTP method runs, this method is commonly used by R&D as it is not required to create a task using software to performing the upgrade stage by stage which is “load software, 
dispense, active and commit”. Indeed the method is faster but pose high risk because if this is done in a live customer network, the stability of the network is an main factor. The risk in the upgrade in warehouse is 
lower because it doesn’t include the stability issues which occurred during loading the file into the RTN using FTP but still there is always the risk of whether the upgrade that was done is success or failure.
I would suggest if required to upgrade the RTN, please use the DC. FTP method can be used if it is during testing or POC but not during the urgent period of deploying to RFI sites. This pose unnecessary risk such 
as this case and most of the time, even the R&D will have doubt whether the RTN is upgraded properly or not.

END