1521-tmseries_r19.0.1_a

IN COMMERCIAL CONFIDENCE UPGRADE INSTRUCTION

Date: Doc. number: Rev: Page

© Transmode 2010-06-02 1521-TM_15_0 A 1 (42)

TM-Series UPGRADE INSTRUCTION Release 19.0.1 Rev A, 2012-06-19



© Transmode 2012-06-19 1521-TM_R19.0.1 A 2 (42)

Transmode Systems AB © 2012 Transmode Systems AB Box 42114 All rights reserved. No part of this document SE-126 14 Stockholm may be reproduced without written Home page: www.transmode.com SWEDEN permission of the copyright holder

1 GENERAL

The purpose of this document is to provide step-by-step instructions of how to upgrade the Transmode TM-series SW from R17.0.3 and R18.0.1 to R19.0.1.

If an older software version than R17.0 is in use, a first upgrade to 17.0.3 is needed before performing the steps to upgrade to R19.0.1 in this instruction. For information of how to upgrade to 17.0.3, read upgrade instructions for the relevant release.

Table 1 in chapter ‘2.2 Supported versions to upgrade from’ show the number of upgrade steps that are needed to be performed for different releases before upgrading to R19.0.1.

All commands must be written exactly in the way they are written in this document e.g. some parameters in the string must be written using capitals “swu +FS upgrade……”. Make sure to follow the numbered steps below in chronological order.

There are three possible ways of upgrading the SW on a node: using TNM, ENM GUI or CLI. If using the TNM you can upgrade the whole network with a few simple steps.

The specifications and information within this manual are subject to change without further notice. All statements, information and recommendations are believed to be accurate but are presented without warranty of any kind. Users must take full responsibility for their application of any products.

In no event shall Transmode Systems AB be liable for any indirect, special, consequential or incidental damages, including, without limitation, lost profits or loss or damage to data arising from the use or inability to use this manual, even if Transmode or its suppliers have been advised of the possibility of such damages.

1.1 In commercial confidence

The manual is provided in commercial confidence and shall be treated as such.

1.2 Document Revision History

Revision Date Description of changes A 2012-06-19 First released R19.0.1 version

1.3 Versions

The new ENM-specification file is: enm001a-r19a-2. Depending on board type different files are used. For a list of all Software files, see Software versions at chapter 4 in this document.



© Transmode 2012-06-19 1521-TM_R19.0.1 A 3 (42)


1.4 Table of content

1 General.....................................................................................................2 1.1 In commercial confidence.........................................................................................2 1.2 Document Revision History .......................................................................................2 1.3 Versions ..................................................................................................................2 1.4 Table of content ......................................................................................................3

2 Important Information to read Before upgrading ..........................................4 2.1 TNM Compatibility....................................................................................................4 2.2 Supported versions to upgrade from .........................................................................4 2.3 Special Considerations..............................................................................................5 2.3.1 Multiservice Muxponder 10G (MS-MXP10G)................................................................6 2.3.2 Ethernet Muxponder (EMXP).....................................................................................7 2.3.3 Multi Service Access Hub (MXP-MBH/1) .....................................................................7 2.3.4 Quad 10Gb/s FEC Transponder (TPQ10GFEC)............................................................7 2.3.5 10G Tunable OTN Transponder (TP10GOTN/TC)........................................................7 2.3.6 MDU40 or VOA8CHII ................................................................................................8 2.4 Notice .....................................................................................................................9 2.4.1 TPDDGBE and TPD10GBE with amplifiers ..................................................................9 2.4.2 TPQMR....................................................................................................................9 2.4.3 OA17C or OA2 17/17C..............................................................................................9 2.4.4 Spare-part in slave subracks .....................................................................................9 2.4.5 CU/CU2OSC replacement with CU-SFP.......................................................................9

3 Upgrade instructions ................................................................................10 3.1 Software upgrade using TNM (multiple nodes).........................................................11 3.1.1 Preparations TNM ..................................................................................................11 3.1.2 Upgrade instructions TNM (multiple nodes) .............................................................12 3.2 Software upgrade using ENM (individual node) ........................................................15 3.2.1 Preparations ENM ..................................................................................................16 3.2.2 Upgrade instructions ENM (individual node).............................................................17 3.3 Software upgrade using CLI (individual node)..........................................................20 3.3.1 Preparations CLI ....................................................................................................21 3.3.2 Upgrade instructions CLI (individual node)...............................................................22

4 Software versions ....................................................................................26 4.1 The correct Software versions.................................................................................26 4.1.1 Software versions for first generation of Control Units ..............................................26 4.1.2 Software versions for second generation of Control Unit...........................................26 4.1.3 Software versions for third generation of Control Unit ..............................................26 4.1.4 Software versions for first generation of Traffic Units ............................................... 27 4.1.5 Software versions for second generation of Traffic Units........................................... 28 4.1.6 Software versions for third generation of Traffic Unit................................................29 4.1.7 Software versions for fourth generation of Traffic Unit ............................................. 30

5 Fall back .................................................................................................31 5.1 Fall back procedure using ENM ...............................................................................31 5.2 Fall back procedure using CLI (alternative 1) ...........................................................33 5.3 Fall back procedure using CLI (alternative 2) ...........................................................35

6 Contact information .................................................................................42



© Transmode 2012-06-19 1521-TM_R19.0.1 A 4 (42)


2 IMPORTANT INFORMATION TO READ BEFORE UPGRADING

2.1 TNM Compatibility

For full compatibility between ENM and TNM it is strongly recommended to upgrade both TNM and ENM to the same release (e.g. R19.0). A network running nodes on a later release than the TNM (e.g. TNM not upgraded to R19.0) will have the risk of displaying faulty information regarding traffic services in the TNM (showing services as "grey" or "incomplete")

2.2 Supported versions to upgrade from

Upgrade is supported from previous R17 and R18 releases.

When a system is required to be upgraded from earlier releases than R17.0 to R19.0.1, it is important to first upgrade the node to R17.0.3 before continuing to R19.0.1. Table 1 below shows the number of upgrade steps that are needed before upgrading to R19.0.1 for CU-SFP, CUOSC or CU systems.

If there are any questions please contact Transmode support [email protected] for additional information.

Upgrade procedure for CU-SFP, CUOSC and CU systems Release 1st upgrade to Upgrade to R19.0.1

R16.0.x and older Two releases at a time From R17.0.3/R18.0.1 R17.0 - Directly R17.0.1 - Directly R17.0.2 - Directly R17.0.3 - Directly R18.0 - Directly R18.0.1 - Directly R19.0 - Directly

Table 1: Upgrade towards R19.0.1 using CU-SFP, CUOSC and CU

Please read the release notes and upgrade instructions on how to upgrade to 19.0.1 from earlier releases described in this document.

If you have a system of an earlier release, you need to upgrade the system to at least 19.0.1 release in order to be able to use the new released boards such as VOA-8CH/SFP, please read the release notes and upgrade the system first and then insert the new boards afterwards.

mailto:[email protected]�



© Transmode 2012-06-19 1521-TM_R19.0.1 A 5 (42)


2.3 Special Considerations

A new release may contain both Software (SW) and Firmware (FW) upgrades. SW upgrades are non service affecting. Traffic FW upgrades will be service affecting, but only on those units that are targeted for a FW upgrade. After a FW upgrade the traffic will be recovered automatically after a short traffic hit during reboot. Prior to an upgrade, please check if the network that is to be upgraded contains any of the below listed units since traffic carried on these units will be affected.

SUMMARY OF UPGRADE DISTURBANCES

Yes = traffic disturbance No = no traffic disturbance N/A= board not released

Software Upgrade Path to R19.0.1

Board Type

R17.0 R17.0.1 R17.0.2 R17.0.3 R18.0 R18.0.1 R19.0

GBE10-EMXP10G/II Yes Yes Yes Yes Yes Yes Yes

GBE22-EMXP10G/II Yes Yes Yes Yes Yes Yes Yes

EMXP40G/II N/A N/A N/A N/A Yes Yes Yes

EMXP80G/II Yes Yes Yes Yes Yes Yes Yes

MXP-MBH/1 Yes Yes Yes Yes Yes Yes Yes

TPQ10GFEC Yes Yes Yes Yes Yes Yes No

TP10GOTN/TC Yes Yes Yes Yes Yes Yes No Yes,

if new fpga is

activated.

Yes, if new fpga is

activated

Yes, if new fpga is

activated

Yes, if new fpga is

activated

Yes, if new fpga is

activated

Yes, if new fpga is

activated

Yes, if new fpga is

activated

MS-MSXP10G

Traffic combination: -gbEx4Stm16Oc48x2 -stm16Oc48x4

For detailed information, read the chapter for this board type (2.3.1)

NOTE: Board types not listed above does not have reported disturbances.



© Transmode 2012-06-19 1521-TM_R19.0.1 A 6 (42)


2.3.1 Multiservice Muxponder 10G (MS-MXP10G)

2.3.1.1 Upgrade instructions when using MS-MXP10G

After an upgrade from R17.0.3 or R18.0.1 to R19.0.1 new traffic FPGA’s are introduced for the traffic combinations ‘gbEx4Stm16Oc48x2’ and ‘Stm16Oc48x4’, but are not loaded. The new traffic FPGA’s are compatible with the previous versions. In ENM it is possible to view information of which traffic FPGA that is currently in use. This information can be found below the ‘board’ tab in the “Additional Information” field.

A user of the MS-MXP10G board can choose to stay with the old FPGA version and avoid a traffic disturbance in the network.

Traffic Combination Old FPGA version New FPGA version (R19)

gbEx4Stm16Oc48x2 P1N P1O

Stm16Oc48x4 P1G P1H

Loading and activating the new R19.0.1 traffic FPGA will cause a traffic disturbance. There are two ways to load and activate the new FPGA version. Method 1: The fastest method to change the traffic FPGA is to cold start the board, e.g. pull the board out and re-insert it. The traffic FPGA version has now changed to the new R19.0.1 version. Method 2: Another way to activate the new traffic FPGA is to reconfigure the board in ENM to another traffic combination and then returning to the previous combination. Follow the procedure below:

1. In ENM, save a backup of the current configuration. (E.g. with the name ‘Config_backup.xml’)

2. In MS-MXP10G board ‘Line’ tab, take note of which traffic combination that currently is active (e.g. gbEx4Stm16Oc48x2). Click ‘Change’ button and choose a different traffic combination (e.g. Stm16Oc48x4), then ‘Apply’ the change. Click ‘Change’ button again and return to the previous combination.

Important: Do NOT save this configuration, otherwise previous configuration data may be overwritten with default settings.

The traffic FPGA has now changed to the new R19.0.1 version. This can be verified in the “Additional Information” field.

3. Click on ‘Maintenance’ tab and choose ‘Restart main CU’ and ‘Apply’. A message box appears saying ‘Configuration is not saved. Do you still want to reboot?’ Click ‘OK’ button.

4. After the CU restart has finished, the saved backup in step ‘1.’ is reloaded. The R19.0.1 traffic FPGA is loaded and active.



© Transmode 2012-06-19 1521-TM_R19.0.1 A 7 (42)


2.3.2 Ethernet Muxponder (EMXP)

2.3.2.1 Upgrade of GBE10-EMXP10G/II, GBE22-EMXP10G/II, EMXP40G/II and EMXP80G/II

Upgrade from R17.0.3 and R18.0.1 to R19.0.1 of the boards GBE10-EMXP10G/II, GBE22-EMXP10G/II, EMXP40G/II and EMXP80G/II will cause a traffic disturbance when the boards are restarted. The downtime during a reboot is roughly 45 seconds, it is however strongly dependent on the amount of configuration and can differ significantly from this value.

2.3.3 Multi Service Access Hub (MXP-MBH/1)

2.3.3.1 Upgrading MXP-MBH/1 from R17.0.3 to R18.0.1

When rebooting MXP-MBH/1 a traffic hit might occur. The SDH/SONET and Ethernet setting in MBA is lost in 1-2 sec resulting in lost traffic. The problem does not occur every time, it occurs 1 out of 3 times.

2.3.3.2 Upgrading MXP-MBH/1 from R17.0.3 or R18.0.1 to R19.0.1

When rebooting MXP-MBH/1 a traffic hit might occur. The SDH/SONET and Ethernet setting in MBA is lost in 10-60 sec resulting in lost traffic. The problem does not occur every time, it occurs 1 out of 50 times.

2.3.4 Quad 10Gb/s FEC Transponder (TPQ10GFEC)

2.3.4.1 Upgrading TPQ10GFEC from R17.0.3 and R18.0.1 to R19.0.1

Upgrade from R17.0.3 and R18.0.1 to R19.0.1 of the board TPQ10GFEC will cause a traffic disturbance when the board is restarted. The downtime during a reboot is roughly 45 seconds.

2.3.5 10G Tunable OTN Transponder (TP10GOTN/TC)

2.3.5.1 Upgrading TP10GOTN/TC from R17.0.3 and R18.0.1 to R19.0.1

After upgrading the TP10GOTN/TC to R19.0.1 a cold start of the board is required to guarantee that all new features are initialised and functional.



© Transmode 2012-06-19 1521-TM_R19.0.1 A 8 (42)


2.3.6 MDU40 or VOA8CHII

2.3.6.1 Upgrading MDU40 or VOA8CHII from R17.0.3 and R18.0.1 to R19.0.1

If you are using optical control loops (OCL) together with MDU40 or VOA8CHII it is important that the configuration is saved before upgrade to R19.0.1 from R17.0.3 or R18.0.1. If configuration is not saved before the upgrade there might be problems with the control loops if a "fallback" of SW is executed.



© Transmode 2012-06-19 1521-TM_R19.0.1 A 9 (42)


2.4 Notice

2.4.1 TPDDGBE and TPD10GBE with amplifiers

Disable APS on AMPs before upgrading.

In systems using TPDDGbE and/or TPD10GbE in combination with amplifiers with ”Automatic Power Shutdown” (=APS) enabled, Set APS to disabled for all active amplifiers (amplifiers with output power) in the network before upgrading and saving the configuration. Customers that desire to use the APS-feature must manually activate APS on the amplifiers after the upgrade.

2.4.2 TPQMR

If using a TPQMR of version R1A or R1B that is running 1 G FC or 2 G FC traffic, the format may be configured to “other” with speed “850” (when using 1G FC) or “other” with speed “1700” (when using 2G FC). This format should in such case be changed to “1GFC” or “2GFC” before the upgrade to avoid future problems with board replacements of TPQMR to revision R2A. The change of traffic format from “other/850” to “1GFC” or “other/1700” to 2GFC will not cause any traffic disturbances on TPQMR’s of revision R1A. Do not forget to save the changes!

2.4.3 OA17C or OA2 17/17C

An OA17C or OA2 17/17C with an earlier revision than R2B cannot be used with parameter amplifier type set to constantGainHI. This means that a board of earlier release than R2B cannot be used as a replacement to a board with the amplifier type set to ConstantGainHI.

2.4.4 Spare-part in slave subracks

If having more than one subrack in one node and replacing a board in any of the slave subracks, the SW in the spare-part board must be of release R8.0 or later. If SW in spare-part is of older release, the upgrade to R8.0 must be done manually. If you know that you have an older SW version than R8.0 on the spare-part you can also put that spare-part into a free slot in master subrack then the upgrade will be made automatically. Afterwards the board must be moved to the slot where the original board was located (in slave subrack) or the board have to be configured again in master subrack. If the spare-part with older SW than R8.0 is inserted first into slave-subrack and then into master subrack this solution WILL NOT work.

2.4.5 CU/CU2OSC replacement with CU-SFP

The CU-SFP can be used as a spare-part for CU/CU2OSC. The CU-SFP/II can be used as a spare-part for CU-SFP. However some special procedures are needed when such a replacement should be made. Please, read the ‘Spare-part handling Guide’ within System Manual Volume C (Operations & Maintenance).



© Transmode 2012-06-19 1521-TM_R19.0.1 A 10 (42)


3 UPGRADE INSTRUCTIONS

Please read the release notes and chapter ‘2.3 Special Considerations’ before upgrading to this release.

New units/products in this release are

VOA-8CH/SFP 8ch SFP-based VOA unit

VOA-SFP/01 VOA SFP 20dB range SM no PD

Always upgrade the system to R19.0.1 before inserting new boards.

All systems that should be upgraded to R19.0.1 must be first upgraded to R17.0.3 or later. If upgrading from older SW release then please follow the recommendations in chapter ‘2.2 Supported versions to upgrade from’.

Since the node uses ftp to download the software it is important that the network connection between the ftp-server and node is not too poor. If the network connection is poor, e.g. when using ADSL modems etc you might get timeouts when downloading the software.

The allowed set of characters from which backup filenames should be constructed are the following: A B C D E F G H I J K L M N O P Q R S T U V W X Y Z a b c d e f g h i j k l m n o p q r s t u v w x y z 0 1 2 3 4 5 6 7 8 9 . _ -

The last three characters are the <period>, <underscore>, and <hyphen> characters, respectively.



© Transmode 2012-06-19 1521-TM_R19.0.1 A 11 (42)


3.1 Software upgrade using TNM (multiple nodes)

It is important that the TNM SW is of release 19.0 or later when upgrading the nodes.

3.1.1 Preparations TNM

Before the upgrade can begin some preparations has to be made.

Step 1 Check that your TNM server is of version R19.0 or later. This is done by choosing Help and then About in TNM Client or TNM Server.

Step 2 Copy the ‘Downloadables’ directory from the ENM Software disc to the tftp subdirectory. This directory is usually located by default in:

For Windows operating systems:

‘C:\Program Files\Transmode TNM\tftproot\enmsw’

For Solaris operating systems:

‘/opt/Transmode_TNM/tftproot/enmsw’

Step 3 Rename the directory from ‘Downloadables’ to something more release-related (i.e. R19A-2).

Step 4 Login to the TNM client with an admin or operator user.

Step 5 Select the subnet that you want to upgrade.

Step 6 Check active alarms in all nodes and save the printouts by right-clicking in the subnet area and then choosing Alarm list. Then press Save as button to save the alarm list in optional directory in your computer. This alarm list will be used after the upgrade to compare with the alarm list after the upgrade.



© Transmode 2012-06-19 1521-TM_R19.0.1 A 12 (42)


3.1.2 Upgrade instructions TNM (multiple nodes)

Figure 1: TNM Software Upgrade

Step 1 Start TNM client and login as admin or operator.

Step 2 Select the subnet you want to upgrade in left pane.

Step 3 Verify that you do not have any alarms on the nodes that you want to upgrade that say ‘Configuration not saved’.

Step 4 Verify that none of the nodes that you want to upgrade is grey.

Step 5 Right-click in the subnet area and select Maintenance Software Upgrade.

Step 6 Enter a new task name in New name edit field, e.g. ‘Subnet-A-check’.

Step 7 Fill in your server path e.g. ‘/enmsw/R19A-2/enm001a-r19a-2.spec’ in the ENM Spec Path field.

Step 8 Select ‘Check’ in the Operation field and press Apply button.

If you do not want to upgrade some of the nodes in the list seen in the ‘Software Upgrade’ window, uncheck those nodes in the list.

Step 9 Verify that all selected nodes say Upgrade needed in the status field.

Step 10 Press New Task button.

Step 11 Enter a New Name, e.g. ‘Subnet-A-Upgrade’.



© Transmode 2012-06-19 1521-TM_R19.0.1 A 13 (42)


Step 12 Select ‘Upgrade’ in Operation field and press Apply button.

Step 13 Wait until all nodes are upgraded.

If upgrade of some nodes fails, identify and solve the source of the problem and repeat again steps 5 to 7.

Step 14 Press New Task button.

Step 15 Select ‘Restart All’ in Operation field and press Apply button to restart all upgraded nodes.

Step 16 After the restart, check the active alarms in all nodes by right-clicking in the subnet area and then choosing Active alarms. Compare this list with the one you saved before the upgrade. If the alarm list differs, try to find the root cause.

Step 17 Right-click in the subnet area and select Maintenance Software Upgrade.

Step 18 In the Task field select the first task made in these instructions, e.g. ‘Subnet-A-Check’.

Step 19 In the Task field select ‘New Task’.

If you did not upgrade some of the nodes in the list seen in the ‘Software Upgrade’ window, uncheck those nodes in the list.

Step 20 Select Check in the Operation field and press Apply button.

Step 21 Verify that all selected nodes say Up to date in the Status field.



© Transmode 2012-06-19 1521-TM_R19.0.1 A 14 (42)


Sometimes you might get an alarm in the TNM saying that the FTP to one or more of the node fails after the upgrade. This alarm will disappear within 15 minutes or when making a ‘Full refresh’ from the TNM.

In some rare cases when loosing contact with nodes during the upgrade you might need to “unlock” the upgrade process in the nodes and then perform the upgrade again. You can check if you are in this state by double-clicking on the status field for a specific node in Upgrade window. If the message says: ”Reserve node failed! Possible causes: Another task, or a local ENM GUI user may have an ongoing upgrade operation. SNMP SET operations are not enabled in the node. A previous task was abnormally terminated.” To unlock the node you can login to CLI and make a “swu unlock” or by using the unlock button in GUI, but make sure that no one else is trying to upgrade the node at the same time!

If the result of an upgrade is “failed”, then double-click on the status field in the Software Upgrade window at TNM Client. If the error message is “Verification script not found” or “Downloaded file is corrupt”, then the application has to be completely removed from the control unit and then run the upgrade procedure again. E.g. Status log (in TNM Client): 1.1 appl cuappl01a-r19a-4 Prepare activation failed 1.1 Verification script not found (/opt/appl/cuappl01a-r19a-4/etc/init.d/verify_startscript.sh) Activation is NOT performed Delete the application using CLI: Syntax: ‘swu delete appl <chassis> <slot> <file>’ swu delete appl 1 1 cuappl01a-r19a-4 Fault message in CLI: 1.1 Directory not found It could be the result, when the directory never was created during the installation (most likely if the executing SW are of release R19 or later).



© Transmode 2012-06-19 1521-TM_R19.0.1 A 15 (42)


3.2 Software upgrade using ENM (individual node)

It is important that only the user that performs the upgrade is logged in to the ENM GUI.

Figure 2 ENM GUI main window

Go through the numbered items below for all the nodes that need to be upgraded.

Work with one node at a time and finish the upgrade for that node before starting with the next node.

Be aware that the IP address used below is just an example and that it of course should be changed to the IP address for the tftp server computer.

The show command responses are examples as well.

The nodes can be upgraded in any order, as long as you work with one node at a time. However, Transmode recommends that you start with the far end nodes and work towards the node where the tftp server computer is connected to minimize the risk of losing the connectivity to whole network in the worst case.



© Transmode 2012-06-19 1521-TM_R19.0.1 A 16 (42)


3.2.1 Preparations ENM

Before the upgrade can begin some preparations have to be made.

Step 1 Create a new folder and name it “tftp” on your “tftp server computer”. Make sure that you choose a computer that can be reached from all the nodes that you want to upgrade.

Step 2 Put all 19.0.1 software files and the tftp program called tftpd32.exe in that folder. The files and the program can be found under directory “/downloadables” on the ENM CD you have got from Transmode or downloaded from our customers support pages: http://www.transmode.com/support

Step 3 Start the tftp server, by clicking on the file named tftpd32.exe.

Step 4 Press ‘Settings’ button in tftp-server window.

Step 5 Uncheck ‘Option negotiation’.

Step 6 Change Server Configuration timeout seconds to 8 in tftp-server.

Step 7 Change ‘Max retransmit’ to 9 in tftp-server.

Step 8 Press OK to apply the settings.

Step 9 Check active alarms in all nodes and save the printouts. This is done in the following way on a PC: 1. Select Active Alarms in left pane of the ENM GUI. 2. Mark all the alarm text. 3. Click on the right button. 4. Choose Copy. 5. Open ‘Notepad’ or ‘Wordpad’. 6. Select ‘Edit’ in the menu of Notepad or Wordpad. 7. Select ‘paste’. 8. Save the file.

Figure 3 Marking of Active Alarms

http://www.transmode.com/support�



© Transmode 2012-06-19 1521-TM_R19.0.1 A 17 (42)


3.2.2 Upgrade instructions ENM (individual node)

Step 1 Login to the node as an oper user, using the web-browser (ENM GUI).

Step 2 Check that you have a 17.0.3 release or later. If not then follow instructions at chapter 2.2 (supported versions to upgrade from). The information about software version could be read at the upper right corner of the ENM GUI, see Figure 2. (includes r17a-4 or later).

Step 3 Save the configuration before continuing, this is done by pressing the Diskette icon in ENM GUI, see Figure 4. Then enter a file name in the dialogue that appears and press the Save button.

Figure 4 Save dialog

In order to eliminate problems during the upgrade one should empty the cache and remove temporary information from the used web browser before starting the upgrade.

E.g. for Internet Explorer: Tools -> internet options -> delete files -> delete all offline content -> OK. Then refresh the page.

Close down all tabs that are not used at the moment. To have only one session is strongly recommended.



© Transmode 2012-06-19 1521-TM_R19.0.1 A 18 (42)


Step 4 Select Maintenance in left panel of ENM GUI.

Figure 5 ENM GUI Maintenance dialog

Step 5 Enter the IP address to your TFTP server in the IP edit field.

Step 6 Fill in your server path e.g. ‘/enm001a-r19a-2.spec’ in the Path field.

Step 7 Select ’Check’ in the Action field and press Apply button.

On some rare occasions you might need to press the refresh button in browser before you can press on the “Apply” button.

Step 8 Verify that ENM state field says: UpgradeNeeded.

Step 9 Select ’Upgrade’ in the Action field and press Apply. Now the software will be downloaded and installed.

Step 10 When the upgrade procedure is done, issue a second check.

Select ’Check’ in the Action field and press Apply button.

Step 11 Verify that ENM state field says: RebootNeeded.

If the ENM state is not correct, then repeat the upgrade step 9.



© Transmode 2012-06-19 1521-TM_R19.0.1 A 19 (42)


Step 12 When the correctness of the ENM state is verified then a reboot of all boards are needed in order to set the new software in use. Select ’Restart All Boards’ in the Action field and press Apply. Now all boards will be rebooted.

It will be impossible to log in to the node before it has started again, this could take 1-2 minutes.

Step 13 Login to the node again using ENM GUI. Login as user ‘oper’ or ‘root’.


Step 15 Insert the correct Server and the Path to the just loaded SW again.

Step 16 Select Action Check and press Apply button.

Step 17 Check that ENM state says: Uptodate.

Check the active alarms, compare with the active alarms before the SW upgrade by choosing Active Alarms in left pane of the ENM GUI. If the alarms differs, try to find the root cause.

If there are alarms saying “Interwork failed” then probably the SW is not correctly installed. Then repeat the steps in this description.

Step 18 Go back to step 1 and start with the next node in the network.

If the result of an upgrade in the Maintenance tab is “failed”, then check the text printout. If the error message is “Verification script not found” or “Downloaded file is corrupt”, then the application has to be completely removed from the control unit, then run the upgrade procedure again. E.g. 1.1 appl cuappl01a-r19a-4 Prepare activation failed 1.1 Verification script not found (/opt/appl/cuappl01a-r19a-4/etc/init.d/verify_startscript.sh) Activation is NOT performed

Deletion of the application is done in the CLI for the failed node. E.g. with the above error message would be:

swu delete appl 1 1 cuappl01a-r19a-4



© Transmode 2012-06-19 1521-TM_R19.0.1 A 20 (42)


3.3 Software upgrade using CLI (individual node)

Figure 6 CLI Maintenance interface

Go through the numbered items below for all the nodes that need to be upgraded.

Work with one node at a time and finish the upgrade for that node before starting with the next node.

Be aware that the IP address used below is just as an example and that it should of course be changed to the IP address for the tftp server computer.

The show command responses are examples as well. The actual printouts depend on the node configuration, the type and amount of boards can vary. The printouts below correspond to a basic configuration containing one control unit (CU) and only one traffic unit (TU).

The nodes can be upgraded in any order, as long as you work with one node at a time. However, Transmode recommends you to start with the far end nodes and work towards the node where the tftp server computer is connected.



© Transmode 2012-06-19 1521-TM_R19.0.1 A 21 (42)


3.3.1 Preparations CLI

Before the upgrade can begin some preparations have to be made.

Step 1 Create a new folder and name it “tftp” on your “tftp server computer”. Make sure that you choose a computer that can be reached from all the nodes you want to upgrade.

Step 2 Put all 19.0.1 software files and the tftp program called tftpd32.exe in that folder. The files and the program can be found under “//downloadables” on the ENM CD you have got from Transmode or downloaded from our customers support pages: http://www.transmode.com/support

Step 3 Start the tftp server, by clicking on the file named tftpd32.exe.

Step 4 Press Settings button in tftp-server window.

Step 5 Uncheck ‘Option negotiation’.

Step 6 Change Server Configuration timeout seconds to 8 in tftp-server.

Step 7 Change ‘Max retransmit’ to 9 in tftp-server.

Step 8 Press OK to apply the settings.

Step 9 Check active alarms in all nodes and save the printouts. These printouts should be compared with the alarm printouts after the upgrade. Use the command:

activeAlarms




© Transmode 2012-06-19 1521-TM_R19.0.1 A 22 (42)


3.3.2 Upgrade instructions CLI (individual node)

Step 1 Login to the node as an oper user, using the Command Line Interface (CLI).

Step 2 Check that you have at least a 17.0.3 release. This is done by verifying that all the softwares in the ‘Application’ column when performing ‘swu show executing’ includes r17a-4 or later. If not then follow instructions at chapter 2.2 (supported versions to upgrade from). Use the command: swu show executing Expected printout (for CU systems): Board Boot Kernel Application 1.1 cuboot02a-r17a-3 oskernel02a-r17a-1 cuappl02a-r17a-7 1.3 tuboot01a-r14a-1 oskernel01a-r8a-1 tuappl01a-r17a-4 1.5 tuboot02a-r17a-2 oskernel02a-r17a-1 tuappl02a-r17a-5

Step 3 Save the node configuration. Use the command:

save Expected printout: Transmode::> save saving to config.xml File exists, overwrite? (yes or no) (no) yes ....................................................... Saving backup on central unit. Invalidating backup copies on traffic units. Slot 5: done Slot 3: done Transferring backup to traffic units. Slot 5: done Slot 3: done Transferring additional persistent files to traffic units. Slot 5: snmpd.conf passwd done Slot 3: snmpd.conf passwd done Transmode::>



© Transmode 2012-06-19 1521-TM_R19.0.1 A 23 (42)


Step 4 Remove all old previous software. Use the command:

swu –F clean all all Expected printout: 1.1 boot Cleaned 04:35:37 1.1 kernel Cleaned 04:35:37 1.1 appl cuappl02a-r16a-11 Deleted 04:35:40 1.1 appl Cleaned 04:35:40 1.3 boot Cleaned 04:35:40 1.3 kernel Cleaned 04:35:40 1.3 appl tuappl01a-r16a-5 Deleted 04:35:43 1.3 appl Cleaned 04:35:43 1.5 boot Cleaned 04:35:43 1.5 kernel Cleaned 04:35:43 1.5 appl Cleaned 04:35:43 1.5 appl Cleaned 04:35:43 1.1 downloaded Cleaned 04:35:45 We are done.

Make sure that folder /tftpboot/download/ is cleaned and empty, before starting the upgrade (command: swu show downloaded).

Step 5 Upgrade application, boot, kernel and file system SW. Use the command:

swu +FS upgrade all all 172.16.12.59/enm001a-r19a-2.spec Expected printout: Downloading from host to node: Download complete. 584 bytes downloaded in 0.016 seconds 1.3 appl tuappl01a-r17a-4 Needs upgrading 1.3 tuappl01a-r19a-2 is expected … 1.5 appl tuappl02a-r17a-5 Needs upgrading 1.5 tuappl02a-r19a-5 is expected … Downloading 172.16.12.59/tuappl01a-r19a-2.ppc_8xx.rpm..Download complete. 6375506 bytes downloaded in 68.624 seconds …

Wait until all software is activated on each board.

Notice: If the upgrade fails for any reason at this stage, then one should repeat Step 4 and Step 5 again.



© Transmode 2012-06-19 1521-TM_R19.0.1 A 24 (42)


Step 6 Check that all boards have the expected software. Use the commands:

swu show next

Expected printout (for CU systems): Board Boot Kernel Application 1.1 cuboot02a-r19a-1 oskernel02a-r19a-1 cuappl02a-r19a-7 fs=r19a-2 1.3 tuboot01a-r14a-1 oskernel01a-r8a-1 tuappl01a-r19a-2 fs=r16a-2 1.5 tuboot01a-r19a-1 oskernel02a-r19a-1 tuappl02a-r19a-5

fs=r19a-2

Step 7 Check that all boards have the right file system installed. Use the command

swu show filesystem all

Expected printout: 1.1 fs r19a-2 15:18:11 1.3 fs r16a-2 15:18:11 1.5 fs r19a-2 15:18:11 We are done.

Step 8 Compare the software information in step 6 and step 7 with Table 2 to Table 7 at Chapter 4.

Make sure that all the software’s are correctly installed and activated for each board (i.e. Check that both CU and TUs have the same software release) before rebooting the node. If not all of the above expected-links are correct, go back and perform the upgrade procedure again.

Step 9 If all software corresponds to release R19.0.1 reboot all boards. Use the command:

swu reboot all

Expected printouts: 1.3 Reboot ordered 1.5 Reboot ordered 1.1 Reboot ordered We are done Transmode::> Rebooting... The system is going down NOW!



© Transmode 2012-06-19 1521-TM_R19.0.1 A 25 (42)


Step 10 Log in to the node again as oper user.


Step 11 Check the active alarms, compare with the active alarms before the SW upgrade. Use the command:

activeAlarms

If there are alarms saying “Interwork failed” then probably the SW is not correctly installed. Then repeat the steps in this description.

Step 12 Check that all boards have the right R19.0.1 software installed. Use the command:

swu show executing

Expected printout (for CU systems):

Board Boot Kernel Application 1.1 cuboot02a-r19a-1 oskernel02a-r19a-1 cuappl02a-r19a-7 fs=r19a-2 1.3 tuboot01a-r14a-1 oskernel01a-r18a-1 tuappl01a-r19a-2 fs=r16a-2

1.5 tuboot02a-r19a-1 oskernel02a-r19a-1 tuappl02a-r19a-5 fs=r19a-2 We are done. See Step 6 for information about what the software should be.

Step 13 Check that all boards have the right file system installed. Use the command

swu show filesystem all

Expected printout: 1.1 fs r19a-2 15:46:40 1.3 fs r16a-2 15:46:40 1.5 fs r19a-2 15:46:40 See Step 6 for information about what the software should be.

If all installed software corresponds to R19.0.1 you are finished, go back to item 1 and start with the next node in the network.



© Transmode 2012-06-19 1521-TM_R19.0.1 A 26 (42)


4 SOFTWARE VERSIONS

4.1 The correct Software versions

The correct R19.0.1 software versions are shown in this chapter.

4.1.1 Software versions for first generation of Control Units

Board type CU11

Application Software Boot Kernel File system

Released in

CU cuappl01a-r19a-4 cuboot01a-r14a-1

oskernel01a-r18a-1

osappl01a-r16a-2

1.0.1

CUOSC cuappl01a-r19a-4 cuboot01a- r14a-1

oskernel01a-r18a-1

osappl01a-r16a-2

4.1.1

Table 2: SW for Control Unit (CU1)

4.1.2 Software versions for second generation of Control Unit

Board type CU22


Released in

CU-SFP cuappl02a-r19a-7 cuboot02a-r19a-1

oskernel02a-r19a-1

osappl02a-r19a-2

8.0

Table 3: SW for Control unit (CU2)

4.1.3 Software versions for third generation of Control Unit

Board type CU33


Released in

CU-SFP/II cuappl03a-r19a-6 cuboot02a-r19a-1

oskernel02a-r19a-1

osappl02a-r19a-2

18.0

Table 4: SW for Control unit (CU3)

1 CU1 - Control board that has older CPU which is recognized by number 01 in the SW file name and suffix .rpm (xxxx01a-xxxx.ppc _8xx.rpm). 2 CU2- Control board that has new CPU which is recognized by number 02 in the SW file name, see below (xxxx02a-xxxx.powerpc.pkg). 3 CU3- Control board that has new CPU which is recognized by number 03 in the SW file name, see below (xxxx03a-xxxx.powerpc.pkg).



© Transmode 2012-06-19 1521-TM_R19.0.1 A 27 (42)


4.1.4 Software versions for first generation of Traffic Units

Board type TU14

Application Software in CU systems

CU-less Application Software5

Boot Kernel File system

Released in

4x2G5-MXP10G tuappl01a-r19a-2

cusomappl01a-r19a-3.ppc_8xx.rpm

tuboot01a-r14a-1

oskernel01a-r18a-1

osappl01a-r16a-2

10.0

GBE9-MXP10G tuappl01a-r19a-2

cu9gbeappl01a-r19a-3.ppc_8xx.rpm

tuboot01a-r14a-1

oskernel01a-r18a-1

osappl01a-r16a-2

6.0

GXP10/2500-SFP tuappl01a-r19a-2

cugxpappl01a-r19a-3.ppc_8xx.rpm

tuboot01a-r14a-1

oskernel01a-r18a-1

osappl01a-r16a-2

3.0

MDU40/50G-EVEN, MDU40/50G-ODD, MDU40/50G-EVEN-L, MDU40/50G-ODD-L

tuapp01a-r19a-2

cumduappl01a-r19a-3.ppc_8xx.rpm

tuboot01a-r14a-1

oskernel01a-r18a-1

osappl01a-r16a-2

10.0

17.0

MXP8, MXP28 tuappl01a-r19a-2

cumxpappl01a-r19a-3.ppc_8xx.rpm

tuboot01a-r14a-1

oskernel01a-r18a-1

osappl01a-r16a-2

2.3

OA10, OA210/10C, OA15, OA2x15, OA17, OA2x17, OA20, OA2x20, OA20C/LG, OA10C/FG, OA20C/VG, OA2-20/20/CC/VG

tuappl01a-r19a-2

cuoaappl01a-r19a-3.ppc_8xx.rpm

tuboot01a-r14a-1

oskernel01a-r18a-1

osappl01a-r16a-2

3.2, 3.2, 2.3.2, 2.3.2, 4.0, 4.0, 6.0, 6.0, 10.0, 10.0 17.0 17.0

TP10G, TP10G-LAN TP10GCLX/xxxx R1B

tuappl01a-r19a-2

cu10gappl01a-r19a-3.ppc_8xx.rpm

tuboot01a-r14a-1

oskernel01a-r18a-1

osappl01a-r16a-2

4.1.1, 2.3.2, 4.1.1

TP10GCLX/TC tuappl01a-r19a-2

cu10gtcappl01a-r19a-3.ppc_8xx.rpm

tuboot01a-r14a-1

oskernel01a-r18a-1

osappl01a-r16a-2

9.1.1

TPD10GBE-BU tuappl01a-r19a-2

cudtgappl01a-r19a-3.ppc_8xx.rpm

tuboot01a-r14a-1

oskernel01a-r18a-1

osappl01a-r16a-2

8.0

TPD10G-L-BU tuappl01a-r19a-2

cud10glappl01a-r19a-3.ppc_8xx.rpm

tuboot01a-r14a-1

oskernel01a-r18a-1

osappl01a-r16a-2

4.0

TPDDGBE tuappl01a-r19a-2

cuqxpappl01a-r19a-3.ppc_8xx.rpm

tuboot01a-r14a-1

oskernel01a-r18a-1

osappl01a-r16a-2

3.1

TPDFC tuappl01a-r19a-2

cudfcappl01a-r19a-3.ppc_8xx.rpm

tuboot01a-r14a-1

oskernel01a-r18a-1

osappl01a-r16a-2

2.1.2

TPDGBE tuappl01a-r19a-2

cudgbeappl01a-r19a-3.ppc_8xx.rpm

tuboot01a-r14a-1

oskernel01a-r18a-1

osappl01a-r16a-2

2.1.2

4 TU1- Traffic board that has older CPU that could be easily recognized by number 01 in the SW file name and suffix .rpm (xxxx01a-xxxx.ppc _8xx.rpm). 5 CU-less Application SW is always used for boards that should be spare-parts and most of the boards can also be run in “stand-alone” CU-less mode, see Release note for information about which boards that can be used in CU-less configurations.



© Transmode 2012-06-19 1521-TM_R19.0.1 A 28 (42)


Board type TU14




Released in

TPMR2500, TPMR25-V2

tuappl01a-r19a-2

cumrappl01a-r19a-3.ppc_8xx.rpm

tuboot01a-r14a-1

oskernel01a-r18a-1

osappl01a-r16a-2

1.0.1, 8.0

TPQMR, TPQMRi tuappl01a-r19a-2

cuqmrappl01a-r19a-3.ppc_8xx.rpm

tuboot01a-r14a-1

oskernel01a-r18a-1

osappl01a-r16a-2

2.1.2, 7.0

Table 5: SW for different TU1 boards

4.1.5 Software versions for second generation of Traffic Units

Board type TU26




Released in

1x2ROADM/100G 1x2ROADM/50G

tuappl02a-r19a-5

cur4x1appl01a-r19a-3.powerpc.pkg

tuboot02a-r19a-1

oskernel02a-r19a-1

osappl02a-r19a-2

17.0

1x4ROADM/100G Tuappl02a-r19a-5


tuboot02a-r19a-1

oskernel02a-r19a-1

osappl02a-r19a-2

12.0

1x8ROADM/50G Tuappl02a-r19a-5


tuboot02a-r19a-1

oskernel02a-r19a-1

osappl02a-r19a-2

15.0

GBE9/MXP10GFEC Tuappl02a-r19a-5

cumxfecappl01a-r19a-3.powerpc.pkg

tuboot02a-r19a-1

oskernel02a-r19a-1

osappl02a-r19a-2

12.0

GBE10-EMXP10 GBE22-EMXP10

tuappl02a-r19a-5

cuemxpappl01a-r19a-3.powerpc.pkg

tuboot02a-r19a-1

oskernel02a-r19a-1

osappl02a-r19a-2

12.0

MS-MXP, MSMXPDQGBE MSMXPQMS2G5

tuappl02a-r19a-5

cumsmappl01a-r19a-5.powerpc.pkg

tuboot02a-r19a-1

oskernel02a-r19a-1

osappl02a-r19a-2

11.0 13.0 14.0

OCM/2P tuappl02a-r19a-5

cuocmappl01a-r19a-3.powerpc.pkg

tuboot02a-r19a-1

oskernel02a-r19a-1

osappl02a-r19a-2

11.0

PCU/2P tuappl02a-r19a-5

cupcuappl01a-r19a-3.powerpc.pkg

tuboot02a-r19a-1

oskernel02a-r19a-1

osappl02a-r19a-2

13.0

TP10G/TC-ER, TP10GCLX/xxxx R1C TP10GOTN/TC

tuappl02a-r19a-5

cu10g2appl01a-r19a-3.powerpc.pkg

tuboot02a-r19a-1

oskernel02a-r19a-1

osappl02a-r19a-2

12.0 12.0 14.0

TPQMS tuappl02a-r19a-5

cuqmsappl01a-r19a-5.powerpc.pkg

tuboot02a-r19a-1

oskernel02a-r19a-1

osappl02a-r19a-2

13.0

6 TU2- Traffic board that has new CPU unit with SW that could be easily recognized by number 02 in the SW file name (xxxx02a-xxxx.powerpc.pkg) except for CU-less application (01). 7 CU-less Application SW is always used for boards that should be spare-parts and most of the boards can also be run in “stand-alone” CU-less mode, see Release note for information about which boards that can be used in CU-less configurations.



© Transmode 2012-06-19 1521-TM_R19.0.1 A 29 (42)


Board type TU26




Released in

VOA-8CH/II tuappl02a-r19a-5

cuvoa2appl01a-r19a-3.powerpc.pkg

tuboot02a-r19a-1

oskernel02a-r19a-1

osappl02a-r19a-2

11.0

VOA-8CH/SFP tuappl02a-r19a-5

cuvoa8sappl01a-r19a-3.powerpc.pkg

tuboot02a-r19a-1

oskernel02a-r19a-1

osappl02a-r19a-2

19.0


4.1.6 Software versions for third generation of Traffic Unit

Board type TU38




Released in

GBE10-EMXP10G/II

GBE22-EMXP10G/II

EMXP80G/II

tuappl03a-r19a-6

cuemxp2appl01a-r19a-7.powerpc.pkg

tuboot02a-r19a-1

oskernel02a-r19a-1

osappl02a-r19a-2

15.0

15.0

16.0

EMXP40G/II - cuemxp2appl01a-r19a-7.powerpc.pkg tuboot02

a-r19a-1 oskernel02a-

r19a-1 osappl02a-r19a-2

18.0

MSMXP10G

MSMXP10G/TC-ER

tuappl03a-r19a-6

cumsm10appl01a-r19a-5.powerpc.pkg

tuboot02a-r19a-1

oskernel02a-r19a-1

osappl02a-r19a-2

14.0

MXP8/II tuappl03a-r19a-6

cumxp2appl01a-r19a-3.powerpc.pkg

tuboot02a-r19a-1

oskernel02a-r19a-1

osappl02a-r19a-2

16.0

MXP-MBH/1 tuappl03a-r19a-6

cumbhappl01a-r19a-3.powerpc.pkg

tuboot02a-r19a-1

oskernel02a-r19a-1

osappl02a-r19a-2

17.0

TM-MBA/2, TM-MBA/2E

-

cumbaappl01a-r19a-3.powerpc.pkg

tuboot02a-r19a-1

oskernel02a-r19a-1

osappl02a-r19a-2

17.0


8 TU3- Traffic board that has new CPU unit with SW that could be easily recognized by number 03 in the SW file name (tuappl03a-xxxx.powerpc.pkg) except for CU-less application (01). 9 CU-less Application SW is always used for boards that should be spare-parts and most of the boards can also be run in “stand-alone” CU-less mode, see Release note for information about which boards that can be used in CU-less configurations.



© Transmode 2012-06-19 1521-TM_R19.0.1 A 30 (42)


4.1.7 Software versions for fourth generation of Traffic Unit

Board type TU410




Released in

TPQ10GFEC tuappl04a-r19a-3

cutpqappl01a-r19a-3.powerpc.pkg

tuboot02a-r19a-1

oskernel02a-r19a-1

osappl02a-r19a-2

17.0

TPQMP tuappl04a-r19a-3

cuqmpappl01a-r19a-3.powerpc.pkg

tuboot02a-r19a-1

oskernel02a-r19a-1

osappl02a-r19a-2

18.0

MDU16-CL/50G tuappl04a-r19a-3

cumdu16appl01a-r19a-3.powerpc.pkg

tuboot02a-r19a-1

oskernel02a-r19a-1

osappl02a-r19a-2

18.0


10 TU4- Traffic board that has new CPU unit with SW that could be easily recognized by number 04 in the SW file name (tuappl04a-xxxx.powerpc.pkg) except for CU-less application (01). 11 CU-less Application SW is always used for boards that should be spare-parts and most of the boards can also be run in “stand-alone” CU-less mode, see Release note for information about which boards that can be used in CU-less configurations.



© Transmode 2012-06-19 1521-TM_R19.0.1 A 31 (42)


5 FALL BACK

If for any reason the upgrade failed and one wants to revert to the old SW, use ENM or CLI to perform a downgrade of application, boot and kernel SW. The file system is backward compatible and will work with an earlier version of the SW.

It is very important that you never downgrade the boot and kernel SW on CU/CU2OSC to a release before 8.0.

If the Ethernet settings for the DCN port/s has been modified from the standard settings when using the R17.0.2, R17.0.3, R18.0, R18.0.1, R19.0 or R19.0.1 software, then they should be set back to standard values (Auto negotiation mode: On, Speed: both10and100, Duplex Capability: both) before proceeding with a fall back. If not, a cold start of the CUSFP or CU-less board will be needed to restore the standard settings.

Fallback procedure using ENM with ‘Server’ set to ‘local’ is currently not supported.

5.1 Fall back procedure using ENM

Follow the steps below to revert to the previous node SW.


Figure 7 ENM GUI Maintenance



© Transmode 2012-06-19 1521-TM_R19.0.1 A 32 (42)


Step 2 Enter the IP address to your TFTP server in the IP edit field.

Step 3 Fill in your server path e.g. ‘/enm001a-r17a-4.spec’ in the Path field.

Step 4 Select ’Upgrade’ in the Action field and press Apply. If the R17.0.3 application software is still available on board then it will be activated directly otherwise the application, boot and kernel software will be downloaded and installed.

Step 5 When the upgrade procedure is done, issue a check.

Select ’Check’ in the Action field and press the Apply button.

Step 6 Verify that ENM state field says: RebootNeeded.

If the ENM state is not correct, then repeat the upgrade Step 4.

Step 7 When the correctness of the ENM state is verified then a reboot of all boards are needed in order to set the new software in use. Select ’Restart all boards’ in the Action field and press Apply. Now all boards will be rebooted.


Step 8 Login to the node again using ENM GUI. Login as user ‘oper’ or ‘root’.


Step 10 Insert the correct Server and the Path to the just loaded SW again.

Step 11 Select Action Check and press Apply button.

Step 12 Check that ENM state says: Uptodate.

Check the active alarms, compare with the active alarms before the SW upgrade by choosing Active Alarms in left pane of the ENM GUI.

If there are alarms saying “Interwork failed” then probably the SW is not correctly installed. In this case repeat steps Step 1 to Step 12.

Step 13 Go back to Step 1 and start with the next node in the network.



© Transmode 2012-06-19 1521-TM_R19.0.1 A 33 (42)


5.2 Fall back procedure using CLI (alternative 1)


Step 1 Login to the node as an oper user, using the Command Line Interface (CLI).

Step 2 Clean temporary files from CU by using following command:

swu clean downloaded

Step 3 Downgrade application, boot and kernel to original SW release, In this case R17.0.3. Use the command:

swu upgrade all all 172.16.12.59/enm001a-r17a-4.spec

Expected printout: 1.3 appl tuappl01a-r19a-2 Needs upgrading to ... 14:22:48 1.3 tuappl01a-r17a-4 is expected 14:22:48 1.5 appl tuappl02a-r19a-5 Needs upgrading to ... 14:22:48 1.5 tuappl02a-r17a-5 is expected 14:22:48 … 1.1 boot cuboot02a-r19a-1 Needs activation of ... 14:22:48 1.1 cuboot02a-r17a-3 is expected 14:22:48 1.1 kernel oskernel02a-r19a-1 Needs activation of ... 14:22:48 1.1 oskernel02a-r17a-1 is expected 14:22:48 1.1 appl cuappl02a-r19a-7 Needs upgrading to ... 14:22:48 1.1 cuappl02a-r17a-7 is expected 14:22:48

Downloading 172.16.12.59./tuappl01a-r17a-4.ppc_8xx.rpm…………. Download complete. 6330983 bytes downloaded in 67.176 seconds … …

1.5 appl tuappl02a-r17a-5 Activate done 14:31:45 1.1 boot cuboot02a-r17a-3 Activate done 14:32:18 1.1 kernel oskernel02a-r17a-1 Activate done 14:32:40 1.1 appl cuappl02a-r17a-7 Activate done 14:32:41 1.1 '/etc/lumentis/cuappl02a-r17a-7' is not empty - no files copied (this version might have been active before?) We are done Wait until all software is activated on each board.



© Transmode 2012-06-19 1521-TM_R19.0.1 A 34 (42)


Step 4 When the upgrade procedure is done. Make sure that the correct software is installed and activated by using following commands at CLI:

swu show next

Board Boot Kernel Application 1.1 cuboot02a-r17a-3 oskernel02a-r17a-1 cuappl02a-r17a-7 fs=r17a-1 1.3 tuboot01a-r14a-1 oskernel01a-r8a-1 tuappl01a-r17a-4 fs=r16a-2 1.5 tuboot02a-r17a-2 oskernel02a-r17a-1 tuappl02a-r17a-5 fs=r17a-1 We are done

Step 5 If the software is not correctly installed or activated for any board then repeat the upgrade Step 2 and Step 3.

Step 6 When the correctness of activated application software is verified (compare to enm001a-r17a-4.spec) then a reboot of all boards are needed in order to set the new software in use. Use the command:

swu reboot all


If there are alarms saying “Interwork failed” then probably the SW is not correctly installed. In this case repeat steps Step 1 to Step 6.

If performing a ‘fall back’ to older release and using FC traffic on GXP10/2500-SFP boards the traffic might be interrupted after the ‘fall back’ until administrative state is toggled between down/up on the FC client ports.

Step 7 Log in to the node and check the active alarms. Note that it will be impossible to log in to the node before it has started again, this could take 1-2 minutes. Compare with the active alarms before the SW upgrade. Use the command:

ActiveAlarms If using OAR-450C a ‘Configuration’ error might appear after the ‘fall back’. Then make a ‘swu reboot cu’ and the alarm will disappear.

If you have done a ‘fall back’ and then upgrades to the same version of CU-application that was used before the ‘fall back’, the backup that was used before the ‘fall back’ will be used again. Please, contact Transmode support before doing the second upgrade.



© Transmode 2012-06-19 1521-TM_R19.0.1 A 35 (42)


5.3 Fall back procedure using CLI (alternative 2)


Step 1 Printout the executing application SW for the controller unit. Use the command:

swu show appl cu

Expected printout (for CU systems): 1.1 appl cuappl02a-r19a-7 <--- executing

cuappl02a-r17a-7 <--- previous We are done.

If using a system without CU you will see the executing and previous versions in a similar way.

Step 2 Revert to the previous version of the application SW. Use the command:

swu activate appl cu XXX where XXX is the previous application software in Step 1 above.

Expected printout (if using a CU-SFP):

1.1 '/etc/lumentis/cuappl02a-r17a-7' is not empty - no files copied (this version might have been active before?) 1.1 appl cuappl02a-r17a-7 Activate done 14:04:35 1.1 '/etc/lumentis/cuappl02a-r17a-7' is not empty - no files copied (this version might have been active before!) We are done

If using a system that has several subracks (Master-Slave) with different CU type, i.e. CU/CUosc(CU1) and CUsfp(CU2) then one had to repeat step 2 for each type. Naturally a warning message will be displayed where the CU type doesn’t match the software and therefore it will ask if the application should be activate for those that it match. The correct answer is Yes which result to activation of correct application for right CU type. Example below shows application activation of CUsfp when there is a CUosc in second subrack.

swu activate appl cu cuappl02a-r17a-7 2.1 appl cuappl01a-r17a-4 Prepare activation failed 13:13:31 2.1 The selected version (cuappl01a-r17a-4) is not installed properly under /opt/appl 1.1 '/etc/lumentis/cuappl02a-r17a-7' is not empty - no files copied (this version might have been active before?) The operation seems to fail on some boards. Do you want to proceed with activation anyway? [no] yes 2.1 appl cuappl01a-r17a-4 Activate failed 13:13:50 2.1 The selected version (cuappl01a-r17a-4) is not installed properly under /opt/appl



© Transmode 2012-06-19 1521-TM_R19.0.1 A 36 (42)


1.1 appl cuappl02a-r17a-7 Activate done 13:13:51 1.1 '/etc/lumentis/cuappl02a-r17a-7' is not empty - no files copied (this version might have been active before?) We are done

Step 3 If using a CU, printout the executing application SW for the traffic units. Use the command:

swu show appl tu

Expected printout:

1.3 appl tuappl01a-r19a-2 <--- executing tuappl01a-r17a-4 <--- previous

1.5 appl tuappl02a-r19a-5 <--- executing tuappl02a-r17a-5 <--- previous

Step 4 If using a CU/CUOSC or CU-SFP revert to the previous version of the TU application SW. Use the command:

swu activate appl tu XXX where XXX is the previous application software in Step 3 above.

Expected printout:

Transmode::$ swu activate appl tu tuappl01a-r17a-4 1.5 appl tuappl01a-r17a-4 Prepare activation failed 15:00:06 1.5 The selected version (tuappl01a-r17a-4) is not installed properly under /opt/appl The operation seems to fail on some boards. Do you want to proceed with activation anyway? [no] yes 1.3 appl tuappl01a-r17a-4 Activate done 15:00:15 1.5 appl tuappl01a-r17a-4 Activate failed 15:00:15 1.5 The selected version (tuappl01a-r17a-4) is not installed properly under /opt/appl We are done Transmode::$

If other TU board types exists (for example: 02 or 03), if needed, activate the application software for those types as well:

Transmode::$ swu activate appl tu tuappl02a-r17a-5 1.3 appl tuappl02a-r17a-5 Prepare activation failed 15:01:28 1.3 The selected version (tuappl02a-r17a-5) is not installed properly under /opt/appl The operation seems to fail on some boards. Do you want to proceed with activation anyway? [no] yes 1.3 appl tuappl02a-r17a-5 Activate failed 15:01:38 1.3 The selected version (tuappl02a-r17a-5) is not installed properly under /opt/appl 1.5 appl tuappl02a-r17a-5 Activate done 15:01:39 We are done Transmode::$



© Transmode 2012-06-19 1521-TM_R19.0.1 A 37 (42)


If using a system that has different TU type, i.e. TU1(old CPU) and TU2(new CPU) then one have to repeat step 4 for each type. Naturally a warning message will be displayed where the TU type doesn’t match the software and therefore it will ask if the application should be activated. The correct answer is Yes which result to activation of correct application for right TU type.

Example below shows activation of application for TU2(slot 5) when there is a TU1(slot 4). swu activate appl tu tuappl02a-r17a-5 1.4 appl tuappl01a-r17a-5 Prepare activation failed 14:10:31 1.4 The selected version (tuappl01a-r17a-5) is not installed properly under /opt/appl 1.5 '/etc/lumentis/tuappl02a-r17a-5' is not empty - no files copied (this version might have been active before?) The operation seems to fail on some boards. Do you want to proceed with activation anyway? [no] yes 1.4 appl tuappl01a-r17a-5 Activate failed 14:10:50 1.4 The selected version (tuappl01a-r17a-5) is not installed properly under /opt/appl 1.5 appl tuappl02a-r17a-5 Activate done 14:10:51 1.5 '/etc/lumentis/tuappl02a-r17a-5' is not empty - no files copied (this version might have been active before?) We are done

Step 5 Check that all ‘next’ links corresponds to the previous application SW. The ‘next’ links should read the same as the ‘previous’ SW in Step 1 and Step 3. Use the command:

swu show appl all


1.1 appl cuappl02a-r19a-7 <--- executing cuappl02a-r17a-7 <--- next

1.3 appl tuappl01a-r19a-2 <--- executing tuappl01a-r17a-4 <--- next

1.5 appl tuappl02a-r19a-5 <--- executing tuappl02a-r17a-5 <--- next

We are done

Step 6 Printout the executing kernel SW for the controller unit. Use the command:

swu show kernel cu

Expected printout (for CU systems): 1.1 kernel oskernel02a-r19a-1 <--- executing

oskernel02a-r17a-1 <--- previous We are done.




© Transmode 2012-06-19 1521-TM_R19.0.1 A 38 (42)


Step 7 Revert to the previous version of the kernel SW. Use the command:

swu activate kernel cu XXX where XXX is the previous kernel software in Step 6 above.


1.1 kernel oskernel02a-r17a-1 Activate done 07:40:25 We are done

Step 8 If using a CU, printout the executing kernel SW for the traffic units. Use the command:

swu show kernel tu

Expected printout:

1.3 kernel oskernel01a-r18a-1 <--- executing oskernel01a-r8a-1 <--- previous

1.5 kernel oskernel02a-r19a-1 <--- executing oskernel02a-r17a-1 <--- previous

Step 9 If using a CU/CUOSC or CU-SFP revert to the previous version of the TU application SW. Use the command:

swu activate kernel tu XXX where XXX is the previous kernel software in Step 8 above.

Expected printout:

Transmode::> swu activate kernel tu oskernel01a-r8a-1 1.5 kernel oskernel01a-r8a-1 Prepare activation failed 07:49:32 1.5 File (/opt/kernel/oskernel01a-r8a-1/boot/vmlinux.uboot) not found The operation seems to fail on some boards. Do you want to proceed with activation anyway? [no] yes 1.3 kernel oskernel01a-r8a-1 Activate done 07:49:52 1.5 kernel oskernel01a-r8a-1 Activate failed 07:49:52 1.5 File (/opt/kernel/oskernel01a-r8a-1/boot/vmlinux.uboot) not found We are done Transmode::>

If other TU board types exists (for example: 02), if needed, activate the kernel software for those types as well.

Transmode::> swu activate kernel tu oskernel02a-r17a-1 1.3 kernel oskernel02a-r17a-1 Prepare activation failed 07:52:56 1.3 File (/opt/kernel/oskernel02a-r17a-1/boot/vmlinux.ppcboot) not found The operation seems to fail on some boards. Do you want to proceed with activation anyway? [no] yes 1.3 kernel oskernel02a-r17a-1 Activate failed 07:52:59 1.3 File (/opt/kernel/oskernel02a-r17a-1/boot/vmlinux.ppcboot) not found 1.5 kernel oskernel02a-r17a-1 Activate done 07:53:23



© Transmode 2012-06-19 1521-TM_R19.0.1 A 39 (42)


We are done Transmode::>

Step 10 Check that all ‘next’ links corresponds to the previous kernel SW. The ‘next’ links should read the same as the ‘previous’ SW in Step 6 and Step 8. Use the command:

swu show kernel all


1.1 kernel oskernel02a-r19a-1 <--- executing oskernel02a-r17a-1 <--- next 1.3 kernel oskernel01a-r18a-1 <--- executing

oskernel01a-r8a-1 <--- next 1.5 kernel oskernel02a-r19a-1 <--- executing oskernel02a-r17a-1 <--- next We are done

Step 11 Printout the executing boot SW for the controller unit. Use the command:

swu show boot cu

Expected printout (for CU systems): 1.1 boot cuboot02a-r19a-1 <--- executing cuboot02a-r17a-3 <--- previous We are done.


Step 12 Revert to the previous version of the boot SW. Use the command:

swu activate boot cu XXX where XXX is the previous boot software in Step 11 above.


1.1 boot cuboot02a-r17a-3 Activate done 08:15:24 We are done

Step 13 If using a CU, printout the executing boot SW for the traffic units. Use the command:

swu show boot tu

Expected printout:

1.3 boot tuboot01a-r14a-1 <--- executing tuboot01a-r14a-1 <--- previous

1.5 boot tuboot02a-r19a-1 <--- executing tuboot02a-r17a-2 <--- previous



© Transmode 2012-06-19 1521-TM_R19.0.1 A 40 (42)


Step 14 If using a CU/CUOSC or CU-SFP revert to the previous version of the TU boot SW. Use the command:

swu activate boot tu XXX where XXX is the previous kernel software in Step 13 above.

Expected printout:

Transmode::$ swu activate boot tu tuboot02a-r17a-2 1.3 boot tuboot02a-r17a-2 Prepare activation failed 08:22:32 1.3 File (/opt/boot/tuboot02a-r17a-2/boot/ppcboot.bin) not found The operation seems to fail on some boards. Do you want to proceed with activation anyway? [no] yes 1.3 boot tuboot02a-r17a-2 Activate failed 08:22:39 1.3 File (/opt/boot/tuboot02a-r17a-2/boot/ppcboot.bin) not found 1.5 boot tuboot02a-r17a-2 Activate done 08:22:42 We are done Transmode::$

If other TU board types exists (for example: 01), if needed, activate the kernel software for those types as well.

In our case above it is not needed, the boot software for TU 01 is already an older or same version (tuboot01a-r14a-1) than what we intend to ‘fall back’ to (r17).

Step 15 Check that all ‘next’ links corresponds to the previous boot SW. The ‘next’ links should read the same as the ‘previous’ SW in Step 11 and Step 13. Use the command:

swu show boot all


1.1 boot cuboot02a-r19a-1 <--- executing cuboot02a-r17a-3 <--- next 1.3 boot tuboot01a-r14a-1 <--- executing tuboot01a-r14a-1 <--- previous 1.5 boot tuboot02a-r19a-1 <--- executing tuboot02a-r17a-2 <--- next We are done

Step 16 Reboot the node. Use the command:

swu reboot all

If performing a ‘fall back’ to older release and using FC traffic on GXP10/2500-SFP boards the traffic might be interrupted after the ‘fall back’ until administrative state is toggled between down/up on the FC client ports.



© Transmode 2012-06-19 1521-TM_R19.0.1 A 41 (42)


Step 17 Log in to the node and check the active alarms. Note that it will be impossible to log in to the node before it has started again, this could take 1-2 minutes. Compare with the active alarms before the SW upgrade. Use the command:

ActiveAlarms If using OAR-450C a ‘Configuration’ error might appear after the ‘fall back’. Then make a ‘swu reboot cu’ and the alarm will disappear.

If you have done a ‘fall back’ and then upgrades to the same version of CU-application that was used before the ‘fall back’, the backup that was used before the ‘fall back’ will be used again. Please, contact Transmode support before doing the second upgrade.

Due to problems in some Internet Browsers the graphical view is not updated with all new features or the view might look corrupt when using the ENM GUI after an upgrade. To fix this problem delete all offline temporary internet files.

E.g. for Internet Explorer: Tools -> internet options -> delete files -> delete all offline content -> OK Then refresh the page.



© Transmode 2012-06-19 1521-TM_R19.0.1 A 42 (42)


6 CONTACT INFORMATION

To get in contact with support personal at Transmode regarding upgrade, please use the contact information below: Name Web E-mail TAC www.transmode.com/support [email protected]

Table 9: Contact information


mailto:[email protected]�

1521-tmseries_r19.0.1_a

Documents

customers

file named

uncheck option

change max

command line

traffic unitapplication

ip edit field

show command