HP Cisco MDS 9020 Cisco MDS 9000 Family Release Notes for Cisco MDS NX-OS Rele - Page 31

Downgrading from NX-OS 4.x to SAN-OS 3.x, To SAN-OS Release, Nondisruptive Downgrade Path

Page 31 highlights

Downgrading Your Cisco MDS SAN-OS Software Image Send documentation comments to [email protected] Table 13 Nondisruptive Downgrade Path from NX-OS Release 4.1(1b) (continued) To SAN-OS Release Nondisruptive Downgrade Path SAN-OS 2.0(1b) Downgrade to SAN-OS Release 3.3(1a) or 3.3(1c) first, then to Release 2.1(2x), then downgrade to Release 2.0(1b). SAN-OS 1.x Downgrade to SAN-OS Release 3.3(1a) or 3.3(1c) first and then downgrade to SAN-OS to Release 2.1(2b), then to Release 1.3(4a), and then downgrade to your SAN-OS 1.x release. Use Table 14 to determine your nondisruptive downgrade path, if you have FICON enabled, from Cisco NX-OS Release 4.1(1b) Find the image release number you are currently using in the Current Release with FICON Enabled column of the table and use the path recommended. Table 14 FICON Downgrade Path from NX-OS Release 4.1(1b) To SAN-OS Release with FICON Enabled SAN-OS 3.3(1c) SAN-OS 3.0(3b) SAN-OS 3.0(2) SAN-OS 2.0(2b) SAN-OS 1.3(4a) Downgrade Path You can nondisruptively downgrade directly from NX-OS Release 4.1(1b) First downgrade to SAN-OS Release 3.3(1c) and then downgrade to Release 3.0(3b). First downgrade to SAN-OS Release 3.3(1c) and then downgrade to Release 3.0(2). Use the interface shutdown command to administratively shut any Fibre Channel ports on Generation 1 modules that are in an operationally down state before nondisruptively downgrading from NX-OS Release 4.1 to SAN-OS Release 3.3(1c) then to SAN-OS Release 3.0(3b) or SAN-OS Release 3.0(2), and then to SAN-OS Release 2.0(2b). An operationally down state includes Link failure or not-connected, SFP not present, or Error Disabled status in the output of a show interface command. When an interface is administratively shut it will then show as Administratively down. Interfaces that are currently up or trunking do not need to be shut down. Downgrade to SAN-OS Release 3.3(1c) and then to Release 3.0(2). Use the shutdown command to shut all the ports operationally down and administratively up on all the Generation 1 modules before nondisruptively downgrading to Release 2.0(2b) and then downgrade to 1.3(4a). Downgrading from NX-OS 4.x to SAN-OS 3.x If you need to downgrade from an NX-OS 4.x image to a SAN-OS 3.x image, make sure that you enter the system health check bootflash command on the switch running NX-OS 4.x before you downgrade to SAN-OS 3.x. The system health check bootflash command, which is available starting in NX-OS 4.1(1b), ensures that the available free space is taken into account properly. MDS 9100 and 9200 Series Switches Before downgrading from an NX-OS 4.x image to a SAN-OS 3.x image on an MDS 9100 or 9200 Series switch, follow these steps: 1. Telnet to the switch to be downgraded and log in. OL-17675-02 Cisco MDS 9000 Family Release Notes for Cisco MDS NX-OS Release 4.1(1b) 31

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66

Send documentation comments to [email protected]
31
Cisco MDS 9000 Family Release Notes for Cisco MDS NX-OS Release 4.1(1b)
OL-17675-02
Downgrading Your Cisco MDS SAN-OS Software Image
Use
Table 14
to determine your nondisruptive downgrade path, if you have FICON enabled, from Cisco
NX-OS Release 4.1(1b) Find the image release number you are currently using in the Current Release
with FICON Enabled column of the table and use the path recommended.
Downgrading from NX-OS 4.x to SAN-OS 3.x
If you need to downgrade from an NX-OS 4.x image to a SAN-OS 3.x image, make sure that you enter
the s
ystem health check bootflash
command on the switch running NX-OS 4.x before you downgrade
to SAN-OS 3.x. The s
ystem health check bootflash
command, which is available starting in NX-OS
4.1(1b), ensures that the available free space is taken into account properly.
MDS 9100 and 9200 Series Switches
Before downgrading from an NX-OS 4.x image to a SAN-OS 3.x image on an MDS 9100 or 9200 Series
switch, follow these steps:
1.
Telnet to the switch to be downgraded and log in.
SAN-OS 2.0(1b)
Downgrade to SAN-OS Release 3.3(1a) or 3.3(1c) first, then to Release 2.1(2x),
then downgrade to Release 2.0(1b).
SAN-OS 1.x
Downgrade to SAN-OS Release 3.3(1a) or 3.3(1c) first and then downgrade to
SAN-OS to Release 2.1(2b), then to Release 1.3(4a), and then downgrade to your
SAN-OS 1.x release.
Table 13
Nondisruptive Downgrade Path from NX-OS Release 4.1(1b) (continued)
To SAN-OS Release
Nondisruptive Downgrade Path
Table 14
FICON Downgrade Path from NX-OS Release 4.1(1b)
To SAN-OS Release with FICON Enabled
Downgrade Path
SAN-OS 3.3(1c)
You can nondisruptively downgrade directly from NX-OS Release 4.1(1b)
SAN-OS 3.0(3b)
First downgrade to SAN-OS Release 3.3(1c) and then downgrade to Release
3.0(3b).
SAN-OS 3.0(2)
First downgrade to SAN-OS Release 3.3(1c) and then downgrade to Release
3.0(2).
SAN-OS 2.0(2b)
Use the
interface shutdown
command to administratively shut any Fibre
Channel ports on Generation 1 modules that are in an operationally down
state before
nondisruptively downgrading from NX-OS Release 4.1 to SAN-OS Release
3.3(1c) then to SAN-OS Release 3.0(3b) or SAN-OS Release 3.0(2), and
then to SAN-OS Release 2.0(2b). An operationally down state includes
Link
failure or not-connected, SFP not present
, or
Error Disabled
status
in the output of a
show interface
command. When an interface is
administratively shut it will then show as
Administratively down
.
Interfaces that are currently up or trunking do not need to be shut down.
SAN-OS 1.3(4a)
Downgrade to SAN-OS Release 3.3(1c) and then to Release 3.0(2). Use the
shutdown command to shut all the ports operationally down and
administratively up on all the Generation 1 modules before nondisruptively
downgrading to Release 2.0(2b) and then downgrade to 1.3(4a).