Upgrading Anything Lenovo IBM BNT Switches 2.2
Upgrading Anything Lenovo IBM BNT Switches 2.2
This document contains examples of commands to upgrade BNT, IBM and Lenovo switches, as well as converting
between ENOS to CNOS and CNOS to ENOS on Rack switches capable of such changes. It also includes sections on Flex
switch upgrades, IBM Rack switch upgrades, and IBM BladeCenter switch upgrades. These instructions are not all-
inclusive of all of the ways to upgrade these switches, but rather more about showing examples. More detailed
instructions on upgrades can be found in the Application Guide for the specific switch and code version in use.
Important note: These instructions currently do not include upgrading the Lenovo CE (Campus) series of switches
Most ENOS switches have a built in GUI that lets you upgrade via the same methods available via the CLI, but also an
option to upgrade code via HTTP. This is handy for those without a TFTP/FTP/SFTP server. Using the GUI for upgrades is
covered at in Appendix A. Note CNOS switches do not have a GUI option for upgrading. And a few ENOS switches (i.e.
the Flex SI4093) do not have this GUI option as well.
This document has four sections:
Section 1: Rack switches (Lenovo, IBM and BNT)(ENOS and CNOS)
Section 2: Flex switches (Lenovo and IBM)(ENOS only)
Section 3: BladeCenter switches (IBM, BNT and Nortel)(ENOS only)
Appendix A: How to upgrade ENOS via GUI (ENOS only)
Appendix B: Example output of a CNOS-to-CNOS upgrade
Appendix C: List of all model switches and what NOS(s) they run
For reference, All CNOS code starts at 10.X, Lenovo ENOS starts at 8.X, and all code 7.X and lower represents IBM or BNT
ENOS code (one exception is for the very first BNT switch, the Nortel 4-7 load balancer for IBM BladeCenter, that used a
21.X release train).
There have been many streams of code for this train of switches, including code from the original Alteon Networks in
the BladeCenter, Nortel Networks, Blade Networks, IBM, and Lenovo networking products. This document attempts to
cover most of these trains, but is far from complete or perfect.
Note A: Upgrading or downgrading between 7.X (IBM) and 8.X (Lenovo) code is both a legal and technical discussion,
and is beyond the scope of this document. Please contact your local Lenovo networking expert for rules and
procedures for such migrations between revisions 7.X and 8.X.
Note B: All Flex code starts at 7.X. ToR and BladeCenter code goes back as far 1.X. This document focuses at most on
5.X code and later. If you are working with any code prior to 5.X, please contact your Lenovo networking expert for
assistance.
All CNOS code and 8.X (Lenovo ENOS) Rack switch code can be found on lenovo.com, at the following location (enter the
model of switch in the search bar area to see available code for that model – click on “View all” next to Top downloads):
https://support.lenovo.com/us/en/
All 8.X (Lenovo ENOS) Flex switch code can be found at lenovo.com, at the following location
https://datacentersupport.lenovo.com/au/en/products/servers/flex/enterprise-chassis/8721/downloads
If there is an older version you want to load and it is not visible, click on the latest version details link to drill down to the
contents and scroll down and click on “Show previous versions”.
All 7.X and earlier code (for IBM Rack switch, IBM Flex switches and IBM BladeCenter switches) can be found on
ibm.com, at the following location (under the dropdown for “System Networking” for Rack switches, “PureSystems” for
Flex switches, and “BladeCenter” for BladeCenter switches): https://www-945.ibm.com/support/fixcentral/
General considerations for upgrading:
In general, upgrading is done via an Ethernet connection, which means the switch needs an IP address to perform an
upgrade. If the device holding the code is across subnets, a default gateway is also required on the switch. The
IP/gateway can be associated with an out of band RJ45 management port, or in-band using an SVI or routed port.
Note most Lenovo/IBM/BNT switches will get a default IP address on at least one interface, if none is defined. The
following represent these defaults
For BladeCenter and Flex switches:
Module location Default IP – BladeCenter Default IP – Flex
AMM or CMM 192.168.70.125/24 192.168.70.100/24
Bay 1 192.168.70.127/24 192.168.70.120/24
Bay 2 192.168.70.128/24 192.168.70.121/24
Bay 3 192.168.70.129/24 192.168.70.122/24
Bay 4 192.168.70.130/24 192.168.70.123/24
Bay 5 192.168.70.131/24 N/A
Bay 6 192.168.70.132/24 N/A
Bay 7 192.168.70.133/24 N/A
Bay 8 192.168.70.134/24 N/A
Bay 9 192.168.70.135/24 N/A
Bay 10 192.168.70.136/24 N/A
For rack switches
Where assigned Default IP – ENOS Default IP – CNOS
Out of Band Management port 192.168.50.50/24 192.168.50.50/24
VLAN 1 192.168.49.50/24 N/A
Exception: G8124 has two OOB management ports. For G8124, OOB management port A is same as above. OOB
Management port B is – 192.168.51.50/24
It is also possible to perform an upgrade over a serial connection. This is usually only done in situations where a switch
can not boot up high enough to get an IP address operational. Procedures for using serial upgrade are beyond the scope
of this document, but the following are a few pointers:
1) Needless to say, you will have to have serial console access
2) On most newer code it is possible to use a “Shift-B” key sequence during boot time (either during the memory
test at the start of boot, or at a point in time were an option will be displayed, alerting the user of “Shift”
options at boot up) to get to a boot menu, that will offer an option to perform a serial recovery of code
3) On older code without a “Shift-B” option, there is often a “Shift-M” option at boot time, which will take you to a
low level prompt similar to Cisco ROMMON – this one is far more cryptic and definitely beyond the scope of this
document
A common issue when doing upgrades over Ethernet are firewalls between the switch and the device holding the code.
Or a firewall directly on the server holding the code. At a minimum, the switch should be able to ping the device holding
the code, and at a deeper level, there must be an open path for the TCP/UDP port used for whatever protocol (TFTP,
FTP, SFTP, etc) being used for upgrading. To minimize obstacles it is often best to use a server on the same subnet as the
switch, and disable the firewall on that server if attempts to upgrade time out.
For most upgrades, remember to save any config to NVRAM before reloading. This will be “copy running startup” or
“write mem” on all ENOS and CNOS 10.7 and later. For CNOS 10.6 and lower use the “save” command.
Section 1 - Rack Switches:
CNOS can be broken up into two major CLI trains:
1) Everything 10.7.X and later (Cisco-like CLI – i.e. “show” instead of “display”, “copy” instead of “cp”)
2) Everything 10.X below 10.7.X (skewed Cisco-like CLI – i.e. “display” instead of “show”, “cp” instead of “copy”)
➢ TFTP (these procedures assume starting from factory default – can use you own IPs if non-factory default)
o If you have a laptop with a TFTP server, set its IP address to 192.168.50.100/24 and plug its Ethernet
port into the RJ45 Ethernet management port of the switch
o Extract the *.imgs file from the code zip file to the root of the TFTP server
o Open an SSH session to the switch (default IP = 192.168.50.50) and log in with the default credentials
(admin/admin)
o Enter “enable” to go to the # prompt and run the following command (replace the*. imgs file name
with your switch and version file name)
cp tftp tftp://192.168.50.100/G8272-CNOS-10.4.4.0.imgs system-image all vrf management
o Once the initial download is complete, the switch will begin to extract and install a number of files (see
screen shot of example in Appendix B). Once done, you will receive a prompt “Do you want to change
that to the standby image? (y/n)”. Answer “y” to use the new OS on the next reload
o If not already done, remember to save the running config to NVRAM “(cp running startup” or “save”
o Once new code is in place in flash and config saved, issue a “reload” command to allow the new code to
take effect.
o Once reload is complete, log back in and confirm version is correct with the command “display version”
➢ USB key
Note: NE1032, NE1032T, NE1072T and all GXXX CNOS switches come with a physical USB-type-A port to plug in a
memory key. NE2572 and NE10032 have a micro-USB-A port and ship with a special cable to convert micro-USB-
A-to-USB-Type-A to plug in a memory key
o Format a USB key with FAT32 and extract the *.imgs file in the ZIP to the root of the USB key
o Install USB key into switch and log in
o Enter “enable” to go to the # prompt and run the following command (replace the*. imgs file name
with your switch and version file name)
cp usb1 G8272-CNOS-10.4.4.0.imgs system-image all
o Once done, use the command “system eject-usb” and then physical unplug the USB key (not available
on some older versions of code)
o See comments in blue above for steps to complete this upgrade process
o Note 10.4.2.0 code had issues with USB access and may need to use some other method to upgrade
➢ Important note: Some code versions 10.6.X and earlier will indicate some part of the upgrade failed. If this
happens, the upgrade may have actually completed just fine, but did not set the boot variable to use the new
image. Use the command “display boot” to see if the Standby image has been selected to use during next
reload. If not, and the proper code is in the Standby image area, you must manually set this boot variable with
the conf d command “startup image standby”
CNOS to ENOS:
This includes G8272, G8296, G8332 series Rack switches (these are the only Rack switches that support both ENOS and
CNOS) - Notes:
• When performing downgrade conversions from CNOS to ENOS
o There are restrictions on how old the 8.X code can be. Release notes for the CNOS version you are using
provide minimum 8.X code supported for downgrade. If you need to down grade to older versions of
8.X, you can follow the release notes recommendation, but if release notes are not handy, a best
practice is to first upgrade to latest 10.X code, then downgrade to latest 8.X code, then downgrade to
what ever older 8.X code you plan to use. Note: Attempting to downgrade to versions below the
minimum approved 8.X version can result in turning the switch into a brick, and a replacement switch
will be required to recover.
o On newer versions of CNOS code, can just copy the latest 8.X OS file to system-image and reload
o On older versions of CNOS code, after putting on the latest 8.X OS file on the switch, reload, and on the
serial console, go into "Shift-B" during memory test, and select the option to boot ENOS, and then
reload again
o It is not possible to convert from CNOS to 7.X and lower directly.
• Depending on versions, going from CNOS to ENOS (and ENOS to CNOS) will lose the existing config. If going from
10.8 to 8.4, if there was an existing ENOS config it will still be present after booting back into ENOS (and the
CNOS config is also preserved such that if you re-upgrade into 10.8 or later, the previous CNOS config will
return). But do not count on config preservation during upgrades and down grades.
➢ TFTP (these procedures assume starting from factory default – can use you own IPs if non-factory default)
o If you have a laptop with a TFTP server, set its IP address to 192.168.50.100/24 and plug its Ethernet
port into the RJ45 management port of the switch
o Extract the *.imgs files from the code zip file to the root of the TFTP server
o Open an SSH session to the switch (default IP = 192.168.50.50) and log in with the default credentials
(admin/admin)
o Enter “enable” to go to the # prompt and run the following command (replace the*. imgs file name
with your switch and version OS and Boot file names – use “cp” instead of “copy” if on 10.6 or earlier)
copy tftp tftp://192.168.50.100/G8272-8.4.6.0_OS.imgs system-image os vrf management
Note a “show boot”/”display boot” after this is complete will still show active image as 10.X, this is
normal, just make sure the messages confirmed OS image was installed successfully
copy tftp tftp://192.168.50.100/G8272-8.4.6.0_Boot.imgs system-image boot vrf management
o Once complete, reload the switch, log back in and confirm version is correct with the command “show
version”
➢ USB key
Note: All GXXXX switches come with a physical USB-type-A port to plug in a memory key.
o Format a USB key with FAT32 and extract the *.imgs file in the ZIP to the root of the USB key
o Install USB key into switch and log in
o Enter “enable” to go to the # prompt and run the following commands one at a time (replace the*. imgs
file name with your switch and version OS and Boot file names – use “cp” instead of “copy” if on 10.6
or earlier)
copy usb1 G8272-8.4.6.0_OS.imgs system-image os
copy usb1 G8272-8.4.6.0_Boot.imgs system-image boot
o Once complete reload the switch, log back in and confirm version is correct with the command “show
version”
ENOS to CNOS:
This includes G8272, G8296, G8332 series Rack switches (these are the only Rack switches that support both ENOS and
CNOS)
Notes:
• You should upgrade to a recent version of 8.X code before attempting to convert to CNOS. Also note 7.X
switches cannot be directly upgraded to CNOS (and depending on purchase date may not be able to convert to
CNOS at all)
• When upgrading form ENOS to CNOS, the ENOS config will not carry forward. If a previous CNOS config had been
present, the switch will pick it up after booting into CNOS. If this switch had never run CNOS before, the switch
will boot into factory default config
• If you are upgrading from 8.X to 10.X, use 8.X commands to copy the CNOS image into image1
• Recommend using USB or SFTP, as TFTP may have issues (timeouts mid-tftp) on some older CNOS code.
Solarwinds has a free SFTP sever if needed.
➢ SFTP (these procedures assume starting from factory default – can use you own IPs if non-factory default)
o If you have a laptop with a SFTP server, set it’s IP address to 192.168.50.100/24 and plug its Ethernet
port into the RJ45 management port of the switch
o Extract the downloaded zip file to the root of the SFTP server
o Open an SSH session to the switch (default IP = 192.168.50.50) and log in with the default credentials
(admin/admin)
o Enter “enable” to go to the # prompt and run the following command
copy sftp image1 mgt-port
Follow prompts for IP, file name, user, etc
Once copied to image1, a "show boot" shows image 1 as still 8.X (this is normal if odd) and bootloader
and Boot kernel as the 10.X version.
o Once complete reload the switch with the “reload” command (will report “Reset will use software
"image1" and the **UNKNOWN** config block.”, this is normal), log back in and confirm version is
correct with the command “show version” or “display version” command
o it is recommended to also now do a CNOS-to-CNOS upgrade sequence (using same CNOS release) to
ensure all images and boot area are correct (see previous section for CNOS-CNOS upgrade)
➢ USB key
Note: All GXXXX switches that support CNOS come with a physical USB-type-A port to plug in a memory key.
o Format a USB key with FAT32 and extract the *.imgs files in the ZIP to the root of the USB key
o Install USB key into switch and log in
o Enter “enable” to go to the # prompt and run the following command (replace the*. imgs file name
with your switch and version file name)
usbcopy fromusb G8272-CNOS-10.4.4.0.imgs image1
o Once complete reload the switch, log back in and confirm version is correct with the command “display
version” (or “show version if 10.7.X or later CNOS)
o Like with the SFTP example, it is recommended to also now do a CNOS-to-CNOS upgrade sequence
(using same CNOS release) to ensure all images and boot area are correct (see previous section for
CNOS-CNOS upgrade)
ENOS to ENOS:
This includes all GXXXX series Rack switches
Notes:
• Upgrading should always result in any config being maintained if saved in NVRAM
• Downgrading may lose commands that changed or were not supported in the older release downgrading to
• All 8.X and later code files end in “imgs”. All 7.X and earlier code ends in “img” (no “s” at the end)
• G8052 does not have an Out of Band “mgt-port”, just in band management via an SVI, such as “int vlan 1”. So at
the end of any copy command you can leave out the mgt-port option on a G8052
➢ TFTP (these procedures assume starting from factory default – can use you own IPs if non-factory default)
o If you have a laptop with a TFTP server, set it’s IP address to 192.168.50.100/24 and plug its Ethernet
port into the RJ45 management port of the switch
o Extract the downloaded zip file to the root of the TFTP server
o Open an SSH session to the switch (default IP = 192.168.50.50) and log in with the default credentials
(admin/admin)
o Enter “enable” to go to the # prompt and run the following commands (one at a time) (replace the*.
imgs file name with your switch and version OS and Boot file names)
copy tftp boot address 192.168.50.200 filename G8272-8.4.6.0_Boot.imgs mgt-port
copy tftp image1 address 192.168.50.200 filename G8272-8.4.6.0_OS.imgs mgt-port
o Once the initial download is complete for each command, the switch will extract and install the code.
Once done, you may receive a prompt saying the new code is not the active code. If so, answer “y” to
point at the new image location
o If not already done, remember to save the running config to NVRAM (“copy running startup” or “write
mem”)
o Once new code is in place in flash (do “show boot” to confirm) and config saved, issue a “reload”
command to allow the new code to take effect.
o Once reload is complete, log back in and confirm version is correct with the command “show version”
o Note you can also do prompted upgrades with “copy tftp boot” for the boot file, and “copy tftp image1”
for the OS file, and follow prompts for each step.
➢ USB key
Note: all Flex and BladeCenter switches, and some early rack switches (G8000 and G8124) do not have USB ports
and can not use the USB upgrade option
o Format a USB key with FAT32 and extract the *.imgs files in the ZIP to the root of the USB key
o Install USB key into switch and log in to switch
o Enter “enable” to go to the # prompt and run the following commands (one at a time) (replace the*.
imgs file name with your switch and version OS and Boot file names)
usbcopy fromusb G8272-8.4.6.0_Boot.imgs boot
usbcopy fromusb G8272-8.4.6.0_OS.imgs image1
o See comments in blue above for steps to complete this upgrade process
Notes about upgrading stacked Rack switches:
The G8052 and G8264 ENOS Rack switches both support stacking (no other Rack switches support stacking at this time,
ENOS or CNOS).
➢ On 7.X code, upgrading a stacked set of switches requires a reload of the entire stack to perform the upgrade.
The procedure to upgrade is the same for stacked and un-stacked (same set of commands followed by a reload),
except in stacking, the copy not only copies the code to the master, but also pushes the code to all of the
member switches automatically. Use the command “show stack push” to see if code has been pushed to all
members. Use the command “show stack version” to see the version of code running on all switches in the stack
• On 8.X code there is an option to perform a rolling upgrade. This is not automatic and must be requested during
the upgrade process. To perform a rolling upgrade first tftp the boot image to the master, then when tftping the
OS image, add the option “staggered-upgrade” to the copy command that brings the image on to the switch. For
example:
copy tftp boot add 192.168.50.100 file GbScSE-10G-8.4.6.0_Boot.imgs mgt-port
copy tftp image1 add 192.168.50.100 file GbScSE-10G-8.4.6.0_OS.imgs mgt-port staggered-upgrade
Once the image is downloaded and pushed to all members in the stack, the stack will begin reloading switches
one at a time, starting with the backup, then the master, then each member (all with delay in between to ensure
no disruption if servers are all dual attached and using teamed NICs)
Notes about upgrading vLAGed pairs:
Most Lenovo switches support vLAG (similar to Cisco vPC) to support cross switch aggregations. There are some simple
rules to follow to minimize any outage incurred during upgrade of a vLAGed pair.
Note 1: if everything is done correctly, the impact should be minimal (i.e. a ping or two lost at most)
Note 2: Except where noted, this section applies to ALL switches that support vLAG. This includes:
➢ ENOS (7.X and 8.X, Rackswitch, Flex switches and BladeCenter switches)
➢ CNOS (G8272, G8332, G8296 and all NE series)
Note 3: See specific section after this section for the NE2572 and NE10032 when upgrading to 10.9 when coming from a
CNOS version below 10.9
Normal upgrade to vLAG notes:
1) Upload code to both switches before performing any reload
2) If spanning-tree is enabled on the vLAGed pair, make sure server (non-network) ports have the spanning-tree
portfast option configured (should have this anyway, regardless of upgrades or not)
a. ENOS: “spanning-tree portfast” interface command
b. CNOS: “spanning-tree port type edge” interface command
3) If spanning-tree is disabled on the vLAGed pair, make sure any upstream connecting devices facing the vLAGed
pair have their equivalent of portfast/edge applied to them – If they do not you may experience a 30 to 45
second outage during the reloads
4) Before doing any reload, make sure any server is correctly teamed, and all desired links are operational
5) Once all is in ready (steps 1-4 above), reload the current vLAG primary switch first (as seen with “show vlag info”
command) and wait for it to fully boot up and bring all ports into operational state. This may take up to 5
minutes from reload to ready if using the default vLAG timers
a. For both ENOS and CNOS monitor both switches with the following commands (use “display” instead of
“show” commands on 10.6.X and earlier CNOS code):
i. “show vlag info” and confirm “ auto recovery” and “startup delay” timers have finished
ii. “show int status” and confirm all links are up and not err-disabled
iii. Confirm any LACP aggregations are up:
1. ENOS: “show lacp info” – Want to see “up” on any LACP trunks
2. CNOS: “show port-chan sum” - Want to see “P” on port status
6) DO NOT reload the second switch until the first switch is back up and fully healthy – Patience is a virtue when
upgrading vLAGed pairs!!!
7) Once the first switch is reloaded and confirmed operational on new code, reload the second switch in the pair to
let it come up to the latest code
Notes specific to upgrading to CNOS 10.9 (10.9.1, 10.9.3) on a vLAG pair when coming from a CNOS version below 10.9
– This applies only to the NE2572 and NE10032 model Lenovo switches running as a vLAG pair:
10.9.1 CNOS specifically on NE2572 and NE10032 introduced a change to the protocol (ECP) used by vLAG to
communicate over the ISL, and it is not compatible with older versions of CNOS. A new command was created for 10.9.1
to allow a 10.9.1 switch to use the old ECP, and needs to be enabled, and then disabled, to permit a hitless upgrade to
10.9.X. Note starting in 10.10 this process was automated so the command was removed and is no longer necessary
once upgraded to 10.10 or later. Summary of when you do and do not need to follow this procedure:
➢ Upgrade from 10.8.X (or lower) to any 10.9.X version -> this procedure is needed
➢ Upgrade from 10.8.X (or lower) to 10.10.X (or higher) -> this procedure is not needed. This is because 10.10 and
above automatically detect when previous ECP version is running.
➢ Upgrade from 10.9.1 to any newer version -> this procedure is not needed. This is because starting with 10.9.1
both switches will run the new ECP version so no need for backwards compatibility
Note 1: The “show vlag info” command displays the configured and operational role for each vLAG peer. The following
steps assume that the Primary/Secondary terms refer to the operational role
Note 2: Per comments above, this procedure ONLY applies to switches that have all of the following in common:
A) Switch is a model NE2572 or NE10032
B) It is a pair of vLAGed switches
C) It is running code lower than 10.9.X
D) It is desired to upgrade this code from the older code to some version of 10.9 specifically (not 10.10 or later)
If the switches are not an NE2572/NE10032, or they are not vLAGed together, or they are not running code less than
10.9, or the plan is to upgrade to something newer than 10.9.X (i.e. 10.10), you do not need to follow the below
instructions (use the previous instructions for a normal vLAG upgrade)
1) Load the CNOS 10.9.X image on both of the switches. Note: Do not reboot the switches yet
2) On the Primary switch, shutdown all the port-channels associated with the vLAG instances (but NOT the ISL). All
traffic goes through the Secondary switch. Note: Do not save the configuration with the disabled port-channels
3) Reload the Primary switch so that the current Secondary switch becomes the new Primary. Note: The
operational vLAG roles are swapped after this step
4) After reboot, the auto-recovery timer starts on the switch but the ISL remains in the inactive state. Use the “ecp
compatibility-mode” command on this switch (the one running 10.9) so that the ISL becomes Active and the
vLAG instances are brought up (after the startup delay timer expires)
a. Note: In 10.9.3, a syslog notification appears alerting the user that the vLAG OS version is mismatched,
but vLAG is operational with all its instances in the Formed state (this message is not generated in
10.9.1). This just alerts the user to finish the upgrade to the other switch, as leaving this mismatch with
these two versions can lead to instabilities in the pair
5) On the new Primary switch (running older code), shutdown all the port-channels associated with the vLAG
instances (nut NOT the ISL). All traffic goes through the newly upgraded Secondary switch. Note: Do not save
the configuration with the disabled port-channels
6) Reload the Primary switch so that the current Secondary switch becomes the new Primary. Note: The
operational vLAG roles are swapped after this step (the initial roles from the beginning of this procedure are
restored).
7) After reboot, the auto-recovery timer starts on the switch, but the ISL remains in the Inactive state. Use the “no
ecp compatibility-mode” command on the other switch (the first switch to have been upgraded) so that the ISL
becomes Active and the vLAG instances are brought up (after the startup delay timer expires).
Section 2 - Flex Switches:
Notes:
• This includes the following Flex switches: EN4093, EN4093R, CN4093, SI4093, SI4091 and EN2092
• There is no 8.X code for the EN2092 or EN4093 (non-R )- 7.X code only
• Flex switches do not have a USB port so any upgrade must take place via in band or out of band connections
using TFTP, FTP, SFTP or SCP. This document only shows an example using TFTP via out of band management
CMM uplink connection.
Sub-note: All Lenovo Flex switches mentioned have a serial console port (mini-USB-A) that can be used for
emergency upgrades. Using the serial port for emergency upgrades is beyond the scope of this document.
• Very early 7.X code defaulted to an older menu-driven CLI. Syntax for the menu driven CLI is beyond the scope
of this document, but is somewhat covered in the BladeCenter section of this document, in the section titled
“Menu based CLI”
• By default, upgrade can only be performed via the CMM uplink (mgt-port path). If you want to upgrade over any
uplink/data ports on the switch (i.e. data-port or extm-port), you must enable “Enable external management
over all ports” in the CMM GUI for each switch that you want to upgrade via this path
• Upgrading or downgrading between 7.X and 8.X is both a legal and technical discussion, and is beyond the
scope of this document. Please contact your local Lenovo networking expert for rules and procedures for such
migrations.
The following commands apply to both 7.X ENOS and 8.X ENOS (the only codes available on the Flex series switches)
➢ TFTP
o Set up a TFTP server that is accessible via the CMM uplink
o Extract the downloaded zip file to the root of the TFTP server
o Open an SSH session to the switch (IP assigned by the CMM) and log in with the default credentials
(admin/admin)
o Enter “enable” to go to the # prompt and run the following commands (one at a time) (replace the*.
imgs file name with your switch and version OS and Boot file names)
copy tftp boot filename GbScSE-10G-8.4.6.0_Boot.imgs address X.X.X.X mgt-port
copy tftp image1 address X.X.X.X filename GbScSE-10G-8.4.6.0_OS.imgs mgt-port
Note: Replace X.X.X.X with IP of TFTP server
o Confirm code has been copied with the “show boot” command
o Once the initial download is complete for each command, the switch will extract and install the code.
Once done, you may receive a prompt saying the new code is not the active code. If so, answer “y” to
point at the new image location
o If not already done, remember to save the running config to NVRAM “(copy running startup” or “write
mem”)
o Once new code is in place in flash and config saved, issue a “reload” command to allow the new code to
take effect.
o Once reload is complete, log back in and confirm version is correct with the command “show version”
Note you can also do prompted upgrades with “copy tftp boot” for the boot file, and “copy tftp image1”
for the OS file, and follow prompts for each step.
Notes about stacked Flex switches:
The EN4093R and CN4093 switches support stacking (no other Flex switches support stacking at this time). You can
create a stack up to 8 EN4093R switches, or 2 x CN4093 + up to 6xEN4093R switches (in a hybrid stack only the CN
switches can be master or backup master when a CN4093 is included in a stack)
➢ On 7.X code, upgrading a stacked set of switches requires a reload of the entire stack to perform the upgrade.
The procedure to upgrade is the same for stacked and un-stacked (same set of commands followed by a reload),
except in stacking, the copy not only copies the code to the master, but also pushes the code to all of the
member switches automatically. Use the command “show stack push” to see if code has been pushed to all
members. Use the command “show stack version” to see the version of code running on all switches in the stack
• On 8.X code there is an option to perform a rolling upgrade. This is not automatic and must be requested during
the upgrade process. To perform a rolling upgrade first tftp the boot image to the master, then when tftping the
OS image, add the option “staggered-upgrade” to the copy command that brings the image on to the switch. For
example:
copy tftp boot add 192.168.50.100 file GbScSE-10G-8.4.6.0_Boot.imgs mgt-port
copy tftp image1 add 192.168.50.100 file GbScSE-10G-8.4.6.0_OS.imgs mgt-port staggered-upgrade
Once the image is downloaded and pushed to all members in the stack, the stack will begin reloading switches
one at a time, starting with the backup, then the master, then each member (all with delay in between to ensure
no disruption if servers are all dual attached and using teamed NICs)
o Note that the staggered upgrade option will not work when downgrading code, only upgrading
• In the CN4093 code download there are usually two sets of code files. The normal boot and OS files (named
something like GbScSE-10G-CS-8.4.27.0_Boot.imgs and GbScSE-10G-CS-8.4.27.0_OS.imgs), and ones in a
subfolder called “HeterogeneousStack” with the files called GbScSE-10G-CS-HeterogeneousStack-
8.4.27.0_Boot.imgs and GbScSE-10G-CS-HeterogeneousStack-8.4.27.0_OS.imgs. Either set of code supports
stacking but only the HeterogeneousStack code contains the necessary images to let a CN4093 master
upgrade/downgrade an EN4093R in the stack. So while either set of images can be used for stacking, it is
recommended to always use the HeterogeneousStack code on any CN4093’s in a mixed stack.
• There is a feature called FSIF (Flex System Interconnect Fabric) that is a super-stack of a combination of a pair of
G8264CS Rack switches, and some number of SI4093 and/or EN4093R Flex switches (up to 18). The discussion of
upgrading a super-stack is beyond the scope of this document. Contact your Lenovo networking expert for
details on upgrading FSIF super-stacks (hint, on 7X code it was similar to stacked 7.X switches (disruptive), and
on 8.X it can be done non-disruptively).
isCLI:
➢ TFTP
o Set up a TFTP server that is accessible via the AMM uplink
o Extract the downloaded zip file to the root of the TFTP server
o Open a telnet or SSH session to the switch (IP assigned by the AMM) and log in with the default
credentials (admin/admin) if available
o Enter “enable” to go to the # prompt and run the following commands (one at a time) (IP and file name
will vary for your environment)
copy tftp boot address 192.168.50.200 filename GbESM-1-10U-7.4.15.0_Boot.img
copy tftp image1 address 192.168.50.200 filename GbESM-1-10U-7.4.15.0_OS.img
o Confirm code has been copied with the “show boot” command
o Once the initial download is complete for each command, the switch will extract and install the code.
Once done, you may receive a prompt saying the new code is not the active code. If so, answer “y” to
point at the new image location
o If not already done, remember to save the running config to NVRAM “(copy running startup” or “write
mem”)
o Once new code is in place in flash and config saved, issue a “reload” command to allow the new code to
take effect.
o Once reload is complete, log back in and confirm version is correct with the command “show version”
Note you can also do prompted upgrades with “copy tftp boot” and “copy tftp image1” and follow
prompts for each step.
Menu based CLI:
➢ TFTP
o Set up a TFTP server that is accessible via the AMM uplink
o Extract the downloaded zip file to the root of the TFTP server
o Open a telnet or SSH session to the switch (IP assigned by the AMM) and log in with the default
credentials (admin/admin)
o At the Main prompt run the following commands (one at a time)(IP and file name will vary)
/boot/gtimg boot 192.168.50.200 GbESM-1-10U-7.4.15.0_Boot.img
/boot/gtimg 1 192.168.50.100 GbESM-1-10U-7.4.15.0_OS.img
o Follow any prompts to complete the process
o Ensure both boot and image file are upgraded with the command “/boot/cur”
o Save running config to NVRAM with the “save” command
o Once confirmed, run the command “/boot/reset” to reload the switch and have the new code take
effect
Note you can also just run “/boot/gtimg” and it will prompt you for all information.
Notes about stacked BladeCenter switches:
The 1/10G ESM and the 10G Virtual Fabric Switch Module (VFSM) both support stacking (only to their own kind, i.e.
1/10G to 1/10G, or VFSM to VFSM). No other BNT/IBM branded BladeCenter switches support stacking.
Note Cisco offers two switch models that support stacking (3010G and 3010X). Please contact Cisco for questions on
upgrading these switches when in stacked mode
➢ Upgrading a stacked set of BladeCenter switches requires a reload of the entire stack to perform the upgrade.
The procedure to upgrade is the same for stacked and un-stacked (same set of commands followed by a reload),
except in stacking, the copy not only copies the code to the master, but also pushes the code to all of the
member switches automatically. Use the command “show stack push” to see if code has been pushed to all
members. Use the command “show stack version” to see the version of code running on all switches in the stack
Note: There are a few ENOS based switches that do not support the GUI, such as the Flex SI4093.
To begin, point your browser at the IP address of the switch. Note older code used HTTP by default, newer code uses
HTTPS by default, so you will have to pick the specific protocol to connect (i.e. https://192.168.1.156)
If your browser presents any security messages, click on the necessary option to continue. Log in using an admin level
user (i.e. default = admin/admin). Once logged in you will be presented with a GUI with three tabs at the top. Use the
following steps to perform the desired code upgrade without the use of a special server:
1) On top click on "Configure" tab
2) On left click on folder of the switch
3) Under the folder click on the "System" folder
4) Under the System folder click on "Config/Image control"
5) On the right, scroll down to the “Image Settings” section
6) Select the desired code slot to load (Image 1, Image2 or boot)
7) Click on the “Choose File” button and find the desired OS or Boot file (depending n if you are upgrading an
image slot of the boot slot) and click on that file
8) Click on the “Download via Browser” option and let the transfer run its course.
➢ Note it will take several minutes and you may not get much feedback during the process.
➢ Typically the screen will refresh when done, and at the top of the screen on the right it will show the new code
for the desired slot installed. If in doubt you can always log into the CLI and run a “show boot” and see what
code is selected. If the “show boot” hangs that is usually a sign that the code is being written to flash, and the
CLI output will finish once the code write is complete.
➢ It is recommended to upgrade both Image 1, Image 2 and boot, to ensure all code is in sync and the coming
reload will have a match for the Boot and OS in use.
➢ Once the desired boot and image slots are upgraded, perform a reload for the new code to take effect. There is
an option for “Reboot” at the bottom of the right hand screen, or you can perform a “reload” from the CLI.
➢ As always, make sure any changes have been saved to NVRAM before reloading (For example, from the CLI,
“copy running start” or “write mem”).
Appendix B: