Introduction

The Cisco MDS 9000 Family of Multilayer Directors and Fabric Switches provides industry-leading availability, scalability, security, and management, allowing you to deploy high performance storage-area networks with lowest total cost of ownership. Layering a rich set of intelligent features onto a high performance, protocol agnostic switch fabric, the Cisco MDS 9000 Family addresses the stringent requirements of large data center storage environments: uncompromising high availability, security, scalability, ease of management, and seamless integration of new technologies.

Software Download Process

Use the software download procedure to upgrade to a later version, or downgrade to an earlier version, of an operating system. This section describes the software download process for the Cisco MDS SAN-OS and includes the following topics:

Determining the Software Version

To determine the version of Cisco MDS SAN-OS software currently running on a Cisco MDS 9000 Family switch using the CLI, log in to the switch and enter the show version EXEC command.

To determine the version of Cisco MDS SAN-OS software currently running on a Cisco MDS 9000 Family switch using the Fabric Manager, view the Switches tab in the Information pane, locate the switch using the IP address, logical name, or WWN, and check its version in the Release column.

Note We strongly recommend that you use the latest available software release supported by your vendor for all Cisco MDS 9000 Family products.

Downloading Software

The Cisco MDS SAN-OS software is designed for mission-critical high availability environments. To realize the benefits of nondisruptive upgrades on the Cisco MDS 9500 Directors, we highly recommend that you install dual supervisor modules.

To download the latest Cisco MDS SAN-OS software, access the Software Center at this URL:

See the following sections in this release note for details on how you can nondisruptively upgrade your Cisco MDS 9000 switch. Issuing the install all command from the CLI, or using Fabric Manager to perform the downgrade, enables the compatibility check. The check indicates if the upgrade can happen nondisruptively or disruptively depending on the current configuration of your switch and the reason.

Compatibility check is done:

Module bootable Impact Install-type Reason

------ -------- -------------- ------------ ------

1 yes non-disruptive rolling

2 yes disruptive rolling Hitless upgrade is not supported

3 yes disruptive rolling Hitless upgrade is not supported

4 yes non-disruptive rolling

5 yes non-disruptive reset

6 yes non-disruptive reset

At a minimum, you need to disable the default device alias distribution feature using the no device-alias distribute command in global configuration mode. The show incompatibility system bootflash:1.3(x)_filename command determines which additional features need to be disabled.

Migrating from Supervisor-1 Modules to Supervisor-2 Modules

As of Cisco MDS SAN-OS Release 3.0(1), the Cisco MDS 9509 and 9506 Directors support both Supervisor-1 and Supervisor-2 modules. Supervisor-1 and Supervisor-2 modules cannot be installed in the same switch, except during migration. Both the active and standby supervisor modules must be of the same type, either Supervisor-1 or Supervisor-2 modules. For Cisco MDS 9513 Directors, both supervisor modules must be Supervisor-2 modules.

Caution Migrating your supervisor modules is a disruptive operation. When migration occurs from a Supervisor 1 to a Supervisor 2 module, a cold switchover occurs and all I/O modules are reloaded. If a Supervisor 1 attempts to come up as the standby with the Supervisor 2 as the active supervisor, the standby is not brought up.

Note Migrating from Supervisor-2 modules to Supervisor-1 modules is not supported.

Configuring Generation 2 Switching Modules

The Cisco MDS 9500 Multilayer Directors are designed to operate with any combination of Cisco MDS 9000 Generation 1 and Generation 2 modules. However, there are limitations to consider when combining the various modules and supervisors in the Cisco MDS 9500 Series platform chassis. The references listed in this section provide specific information about configurations that combine different modules and supervisors.

Upgrading Your Version of Cisco Fabric Manager

As of Cisco SAN-OS Release 3.2(1), Cisco Fabric Manager is no longer packaged with a Cisco MDS 9000

Family switch. It is included on the CD-ROM that ships with the switch. You can install Fabric Manager from the CD-ROM or from files that you download.

Installing Cisco Fabric Manager is a multi-step process that involves installing a database, as well as Fabric Manager. The complete installation instructions are provided in the "Installation of Cisco MDS SAN-OS and Fabric Manager" section in the Cisco MDS 9000 Family Fabric Manager Configuration Guide, and are available on-screen once you launch the Fabric Manager installer from the CD-ROM.

Note When upgrading Fabric Manager, refer to the supported upgrade path shown in Table 6. For example, when upgrading from SAN-OS Release 3.1(x) to Release 3.3(1a), you will need to upgrade from Release 3.1(x) to Release 3.2(x) and then upgrade to Release 3.3(1a).

Table 6 Supported Fabric Manager Upgrade Paths

Current

Upgrade Path

3.0.x

3.1.x

3.1.x (HSQL)

3.2.x (Oracle)

3.1.x (HSQL)

3.2.x PostgreSQL

3.1.x (Oracle)

3.2.x (Oracle)

3.2.x (Oracle)

3.3.x (Oracle)

3.2.x (PostgreSQL)

3.3.x (PostgreSQL)

Note Fabric Manager Server can not be installed on an Active Directory Server when using PostgreSQL, Fabric Manager servers are domain controllers and can not create local PostgreSQL user accounts.

Upgrading from Release 3.1(2c) with the PostgreSQL Patch

To upgrade Fabric Manager to Release 3.3(1a) from the UBS special version of 3.1.2c with the PostgreSQL patch, do the following:

Step 1 Upgrade Fabric Manager to Release 3.2.1b, pointing to the same PostgreSQL database which was used by Release 3.1.2c.

Step 2 When the installation is complete, stop the Fabric Manager server.

Step 3 Run PM.sh s located in $InstallDir/bin to re-index the rrd files in the PostgreSQL database.

If you are upgrading Cisco Fabric Manager in Cisco SAN-OS Releases 3.1(2b) and later, be aware that data is migrated from the Hypersonic HSQL database to either the PostgreSQL database or Oracle Database 10g Express during the installation. Data is also migrated from Oracle Database 10g Express to Oracle Database 10g Express. If you migrate the database from Oracle to Oracle, the schema is updated. Refer to Table 6 for information on the supported upgrade path.

If you are upgrading Fabric Manager in a Cisco SAN-OS Release prior to 3.1(2b), be aware that data is migrated from the Hypersonic HSQL database to either the PostgreSQL database or the Oracle Database 10g Express during the installation. The Fabric Manager Installer installs the PostgreSQL database on Windows. If you want to install the PostgreSQL database on Solaris or Linux, or if you want to install the Oracle Database 10g Express database, follow the instructions in the "Installation of Cisco MDS SAN-OS and Fabric Manager" section in the Cisco MDS 9000 Family Fabric Manager Configuration Guide. Refer to Table 6 for information on the supported upgrade path.

4. If you are upgrading a previous installation of Fabric Manager, make sure the previous installation is installed and running. Do not uninstall the previous version. If the previous version is uninstalled, the database will not be migrated and your server settings will not be preserved.

5. Select the database.

If you want to use the Oracle Database 10g Express, you must install the database and create a user name and password before continuing with the Fabric Manager installation. We recommend the Oracle Database 10g Express option for all users who are running Performance Manager on large fabrics (1000 or more end devices).

If you want to install the PostgreSQL database, you must disable any security software you are running as PostgreSQL may not install certain folders or users. You must also log in as a Superuser before you start the installation.

6. Install Fabric Manager from the CD-ROM or from files that you download from Cisco.com at the following website:

Note If you use a Java JDK instead of a JRE on Solaris, you might encounter a problem trying to install the Device Manager from a web browser. This can happen because the installer heap limit of 256 MB is not sufficient. If you have this problem, save the jnlp link as file, increase the heap limit to 512 MB, and run javaws element-manager.jnlp at the shell prompt.

Installing Fabric Manager on Windows

This section describes how to install Fabric Manager on Windows.

Note Fabric Manager Server ca not be installed on an Active Directory Server when using PostgreSQL. Fabric Manager servers are domain controllers and cannot create local PostgreSQL user accounts.

Note If you are running Fabric Manager Server on Windows and using the PostgreSQL database, you should examine your Windows Active Directory environment for organizational units (OUs) and make the change recommended below to ensure that Fabric Manager Server does not periodically stop working.

On a Windows system, the Microsoft Active Directory applies a Group Policy Object (GPO) to the Fabric Manager Server. The GPO does not recognize the local user PostgreSQL because it is not in the GPO allow list. As a result, the GPO removes it, and the PostgreSQL database stops working.

To avoid this situation, you should move the Fabric Manager Server to its own OU and apply the same feature settings as the original OU, but remove the local user account to log in as a service.

If your server is running Terminal Services in Application mode, or if you are running Citrix Metaframe or any variation thereof, you need to issue the following command on the DOS prompt before installing Fabric Manager Server.

•Be aware that some features impact whether an upgrade is disruptive or nondisruptive:

–Fibre Channel Ports:Traffic on Fibre Channel portscan be nondisruptively upgraded. See Table 7 for the nondisruptive upgrade path for all SAN-OS releases.

–SSM: Intelligent services traffic on the SSM, such as SANTap, NASB, and FC write acceleration, is disrupted during an upgrade. SSM Fibre Channel traffic is not.

–Gigabit Ethernet Ports:Traffic on Gigabit Ethernet ports isdisrupted during an upgrade or downgrade. This includes IPS modules and the Gigabit Ethernet ports on the MPS-14/2 module, the MSM-18/4 module, and the MDS 9222i switch. Those nodes that are members of VSANs traversing an FCIP ISL are impacted, and a fabric reconfiguration occurs. iSCSI initiators connected to the Gigabit Ethernet ports lose connectivity to iSCSI targets while the upgrade is in progress.

–Inter-VSAN Routing (IVR): With IVR enabled, you must follow additional steps if you are upgrading from Cisco SAN-OS Release 2.1.(1a), 2.1(1b), or 2.1.(2a). See the "Upgrading with IVR Enabled" section for these instructions.

–FICON: If you have FICON enabled, the upgrade path is different. See Table 9.

Use Table 7 to determine your nondisruptive upgrade path to Cisco SAN-OS Release 3.3(1a). Find the image release number you are currently using in the Current column of the table and use the path recommended.

Upgrade to SAN-OS Release 2.1(2b) and then upgrade to Release 3.3(1a).orUpgrade to SAN-OS Release 2.1(2d) and then upgrade to Release 3.3(1a).orUpgrade to SAN-OS Release 2.1(2e) and then upgrade to Release 3.3(1a).orUpgrade to SAN-OS Release 2.1(3) and then upgrade to Release 3.3(1a).

SAN-OS 2.1(1b)

Upgrade to SAN-OS Release 2.1(2b) and then upgrade to Release 3.3(1a).orUpgrade to SAN-OS Release 2.1(2d) an3.3(1a)d then upgrade to Release 3.3(1a).orUpgrade to SAN-OS Release 2.1(2e) and then upgrade to Release 3.3(1a).orUpgrade to SAN-OS Release 2.1(3) and then upgrade to Release 3.3(1a).

SAN-OS 2.1(1a)

Upgrade to SAN-OS Release 2.1(2b) and then upgrade to Release 3.3(1a).orUpgrade to SAN-OS Release 2.1(2d) and then upgrade to Release 3.3(1a).orUpgrade to SAN-OS Release 2.1(2e) and then upgrade to Release 3.3(1a).orUpgrade to SAN-OS Release 2.1(3) and then upgrade to Release 3.3(1a).

SAN-OS 2.0(x)

Upgrade to SAN-OS Release 2.1(2b) and then upgrade to Release 3.3(1a).orUpgrade to SAN-OS Release 2.1(2d) and then upgrade to Release 3.3(1a).orUpgrade to SAN-OS Release 2.1(2e) and then upgrade to Release 3.3(1a).orUpgrade to SAN-OS Release 2.1(3) and then upgrade to Release 3.3(1a).

SAN-OS 1.x

Upgrade to SAN-OS Release 1.3(4a), then to Release 2.1(2b), and then upgrade to Release 3.3(1a).

FICON Supported Releases and Upgrade Paths

Cisco MDS SAN-OS Release 3.3(1a) does not support FICON.

Table 8 lists the SAN-OS and NX-OS releases that support FICON. Refer to the specific release notes for FICON upgrade path information.

Table 8 FICON Supported Releases

FICON Supported Releases

NX-OS

Release 4.1(1c)

SAN-OS

Release 3.3(1c)

Release 3.2(2c)

Release 3.0(3b)

Release 3.0(3)

Release 3.0(2)

Release 2.0(2b)

Upgrading with IVR Enabled

An Inter-Switch Link (ISL) flap resulting in fabric segmentation or a merge during or after an upgrade from Cisco MDS SAN-OS Release 2.0(x) to a later image where IVR is enabled might be disruptive. Some possible scenarios include the following:

•FCIP connection flapping during the upgrade process resulting in fabric segmentation or merge.

•ISL flap results in fabric segmentation or merge because of hardware issues or a software bug.

•ISL port becomes part of PCP results in fabric segmentation or merge because of a port flap.

If this problem occurs, syslogs indicate a failure and the flapped ISL could remain in a down state because of a domain overlap.

This issue was resolved in Cisco SAN-OS Release 2.1(2b); you must upgrade to Release 2.1(2b) before upgrading to Release 3.3(1a). An upgrade from Cisco SAN-OS Releases 2.1(1a), 2.1(1b), or 2.1(2a) to Release 2.1(2b) when IVR is enabled requires that you follow the procedure below, and then follow the upgrade guidelines listed in the "Upgrading Your Version of Cisco Fabric Manager" section. If you have VSANs in interop mode 2 or 3, you must issue an IVR refresh for those VSANs.

To upgrade from Cisco SAN-OS Releases 2.1(1a), 2.1(1b), or 2.1(2a) to Release 2.1(2b) for all other VSANs with IVR enabled, follow these steps:

Step 1 Configure static domains for all switches in all VSANs where IVR is enabled. Configure the static domain the same as the running domain so that there is no change in domain IDs. Make sure that all domains are unique across all of the IVR VSANs. We recommend this step as a best practice for IVR-non-NAT mode. Issue the fcdomain domain id static vsan vsan idcommand to configure the static domains.

Note Complete Step 1 for all switches before moving to Step 2.

Step 2 Issue the no ivr virtual-fcdomain-add vsan-rangesvsan-rangecommand to disable RDI mode on all IVR enabled switches. The range of values for a VSAN ID is 1 to 4093. This can cause traffic disruption.

Step 4 Issue the following commands for the isolated switches in Step 3:

switch(config)# vsan database

switch(config-vsan-db)# vsanvsan-idsuspend

switch(config-vsan-db)# no vsanvsan-idsuspend

Step 5 Issue the ivr refresh command to perform an IVR refresh on all the IVR enabled switches.

Step 6 Issue the copy running-config startup-config command to save the RDI mode in the startup configuration on all of the switches.

Step 7 Follow the normal upgrade guidelines for Release 2.1(2b). If you are adding new switches running Cisco MDS SAN-OS Release 2.1(2b) or later, upgrade all of your existing switches to Cisco SAN-OS Release 2.1(2b) as described in this workaround. Then follow the normal upgrade guidelines for Release 3.3(1a).

Note RDI mode should not be disabled for VSANs running in interop mode 2 or interop mode 3.

Reconfiguring SSM Ports Before Upgrading to SAN-OS Release 3.3(1a)

Starting with Cisco MDS SAN-OS Release 3.0(1), the SSM front panel ports can no longer be configured in auto mode, which is the default for releases prior to Release 3.0(1).

Note To avoid any traffic disruption, modify the configuration of the SSM ports as described below, before upgrading a SAN-OS software image prior to Release 3.3(1a).

If the configuration is not updated before the upgrade, the installation process for the new image will automatically convert all ports configured in auto mode to Fx mode. This change in mode might cause a disruption if the port is currently operating in E mode.

To upgrade the image on your SSM without any traffic disruption, follow these steps:

Step 1 Verify the operational mode for each port on the SSM using the show interface command:

Step 2 Change the configuration for the first port of the quad when the admin port mode is auto. (A quad is a group of four ports, supported by a data path processor (DPP). The groups are 1 to 4, 5 to 8, 9 to 12, and so on.) Do not leave the port mode set to auto.

a. Set the port admin mode to E or Fx if the current operational port mode is E, TE, F or FL.

switch# config t

switch(config)# interface fc 2/1

switch(config-if)# switchport mode fx

b. Set the port admin mode to E if the current operational port mode is E:

switch# config t

switch(config)# interface fc 2/5

switch(config-if)# switchport mode e

Step 3 Change the configuration for ports 2, 3, and 4 of the quad:

a. Set the admin port mode to Fx if the admin port mode of these ports is E, TE, or auto.

switch# config t

switch(config)# interface fc 2/2

switch(config-if)# switchport mode fx

b. If the first port in the port group has admin mode E or if the port is operational in E port mode, change the admin state of ports 2, 3, and 4 to shutdown.

Caution Upgrading from Cisco MDS SAN-OS Release 2.1(1b) or earlier to Release 2.1.2 or later can disrupt traffic on any SSM installed on your MDS switch

Upgrading a Switch with Insufficient Space for Two Images on the Bootflash

To upgrade the SAN-OS image on a Cisco MDS 9000 Family switch requires enough space on the internal CompactFlash (also referred to as bootflash) to accommodate both the old software image and the new software image.

As of Cisco MDS SAN-OS Release 3.1(1), on MDS switches with a 256-MB CompactFlash, it is possible in some scenarios that a user might be unable to fit two images on the bootflash. This lack of space on the bootflash might cause the upgrade process to fail because new images are always copied onto the bootflash during an upgrade.

The following MDS switches are affected by this issue:

•MDS 9216 and MDS 9216i

•MDS 9120 and MDS 9140

•MDS 9500 Series switches with a Supervisor 1 module

To work around an image upgrade failure caused by a lack of space on the bootflash, follow these steps:

Step 1 Prior to installing the new image, copy the old (existing) system image file to an external server. You may need to reinstall this file later.

Step 2 Delete the old system image file from the bootflash by using either the Fabric Manager install utility or the CLI delete bootflash: command. The system image file does not contain the word "kickstart" in the filename.switch# delete bootflash:m9200-ek9-mz.3.0.3.bin

Note On MDS 9500 Series switches, you also need to delete the image file from the standby supervisor after deleting it from the active supervisor.switch# delete bootflash://sup-standby/m9500-sf1ek9-mz.3.0.3.bin

Step 3 Start the image upgrade or installation process using the Fabric Manager install utility or the CLI install all command.

Step 4 If the new installation or upgrade fails while copying the image and you want to keep the old (existing) image, then copy the old image (that you saved to an external server in Step 1) to the bootflash using either Fabric Manager or the copy command.

Upgrading a Cisco MDS 9124 Switch

If you are upgrading from Cisco MDS SAN-OS Release 3.1(1) to Cisco SAN-OS Release 3.3(1a) on a Cisco MDS 9124 Switch, follow these guidelines:

•During the upgrade, configuration is not allowed and the fabric is expected to be stable.

•The Fabric Shortest Path First (FSPF) timers must be configured to the default value of 20 seconds; otherwise, the nondisruptive upgrade is blocked to ensure that the maximum down time for the control plane can be 80 seconds.

•If there are any CFS commits in the fabric, the nondisruptive upgrade will fail.

•If there is a zone server merge in progress in the fabric, the nondisruptive upgrade will fail.

•If a service terminates the nondisruptive upgrade, the show install all failure-reason command can display the reason that the nondisruptive upgrade cannot proceed.

•If there is not enough memory in the system to load the new images, the upgrade will be made disruptive due to insufficient resources and the user will be notified in the compatibility table.

Performing a Disruptive Upgrade on a Single Supervisor MDS Family Switch

Cisco MDS SAN-OS software upgrades are disruptive on the following single supervisor Cisco MDS Family switches:

•MDS 9120 switch

•MDS 9140 switch

•MDS 9216i switch

If you are performing an upgrade on one of those switches, you should follow the nondisruptive upgrade path shown in Table 7, even though the upgrade is disruptive. Following the nondisruptive upgrade path ensures that the binary startup configuration remains intact.

If you do not follow the upgrade path, (for example, you upgrade directly from SAN-OS Release 2.1(2) or earlier version to SAN-OS Release 3.3(1a)), the binary startup configuration is deleted because it is not compatible with the new image, and the ASCII startup configuration file is applied when the switch comes up with the new upgraded image. When the ASCII startup configuration file is applied, there may be errors. Because of this, we recommend that you follow the nondisruptive upgrade path.

Downgrading Your Cisco MDS SAN-OS Software Image

This section lists the guidelines recommended for downgrading your Cisco MDS SAN-OS software image and contains the following sections:

General Downgrading Guidelines

Use the following guidelines to nondisruptivelydowngrade your Cisco MDS SAN-OS Release 3.3(1a):

•Install and configure dual supervisor modules.

•Issue the system no acl-adjacency-sharing execute command to disable acl adjacency usage on Generation 2 and Generation 1 modules. If this command fails, reduce the number of zones, IVR zones, TE ports, or a combination of these in the system and issue the command again.

•Disable all features not supported by the downgrade release. Use the show incompatibility systemdowngrade-image CLI command to determine what you need to disable.

•Layer 2 switching traffic is not disrupted when downgrading to Cisco SAN-OS Release 2.1(2) or later.

•Use the show install all impactdowngrade-image CLI command to determine if your downgrade will be nondisruptive.

•Be aware that some features impact whether a downgrade is disruptive or nondisruptive:

–Fibre Channel Ports:Traffic on Fibre Channel portscan be nondisruptively downgraded. See Table 9 for the nondisruptive downgrade path for all SAN-OS releases.

–SSM: Intelligent services traffic on the SSM, such as SANTap, NASB, and FC write acceleration, is disrupted during a downgrade. SSM Fibre Channel traffic is not.

–Gigabit Ethernet Ports: Traffic on Gigabit Ethernet ports isdisrupted during a downgrade. This includes IPS modules and the Gigabit Ethernet ports on the MPS-14/2 module, the MSM-18/4 module, and the MDS 9222i switch. Those nodes that are members of VSANs traversing an FCIP ISL are impacted, and a fabric reconfiguration occurs. iSCSI initiators connected to the Gigabit Ethernet ports lose connectivity to iSCSI targets while the downgrade is in progress.

–iSCSI: If you are downgrading from SAN-OS version 3.0(x) to a lower version of SAN-OS, enable iSCSI if an IPS module, MPS-14/2 module, MSM-18/4 module, or the MDS 9222i switch is online. Otherwise, the downgrade will disrupt traffic.

–IVR: With IVR enabled, you must follow additional steps if you are downgrading from Cisco SAN-OS Release 2.1.(1a), 2.1(1b), or 2.1.(2a). See the "Upgrading with IVR Enabled" section for these instructions.

–FICON: If you have FICON enabled, the downgrade path is different. See Table 9.

Note A downgrade from NX-OS Release 4.1(1b) to SAN-OS Release 3.3(1x) is not supported on MDS switches, when FC-Redirect based applications, such as Data Mobility Manager or Storage Media Encryption, are configured in the fabric if either of the following conditions are satisfied:

1. A target for which FC-Redirect is configured is connected locally and there are Generation 1 modules with ISLs configured in the switch.

2. A host, for which FC-redirect is configured, is connected locally on a Generation 1 module.

If these conditions exist, remove the application configuration for these targets and hosts before proceeding with the downgrade.

Use Table 9 to determine the nondisruptive downgrade path from Cisco SAN-OS Release 3.3(1a). Find the SAN-OS image you want to downgrade to in the To SAN-OS Release column of the table and use the path recommended.

You can nondisruptively downgrade directly from SAN-OS Release 3.3(1a).

SAN-OS 3.2(3)

You can nondisruptively downgrade directly from SAN-OS Release 3.3(1a).

SAN-OS 3.2(2c)

You can nondisruptively downgrade directly from SAN-OS Release 3.3(1a).

SAN-OS 3.2(1a)

You can nondisruptively downgrade directly from SAN-OS Release 3.3(1a).

SAN-OS 3.1(4)

You can nondisruptively downgrade directly from SAN-OS Release 3.3(1a).

SAN-OS 3.1(3a)

You can nondisruptively downgrade directly from SAN-OS Release 3.3(1a).

SAN-OS 3.1(2b)

You can nondisruptively downgrade directly from SAN-OS Release 3.3(1a).

SAN-OS 3.1

You can nondisruptively downgrade directly from SAN-OS Release 3.3(1a).

SAN-OS 3.1(2)

You can nondisruptively downgrade directly from SAN-OS Release 3.3(1a).

SAN-OS 3.1(1)

You can nondisruptively downgrade directly from SAN-OS Release 3.3(1a).

SAN-OS 3.0(3a)

You can nondisruptively downgrade directly from SAN-OS Release 3.3(1a).

SAN-OS 3.0(3)

You can nondisruptively downgrade directly from SAN-OS Release 3.3(1a).

SAN-OS 3.0(2a)

You can nondisruptively downgrade directly from SAN-OS Release 3.3(1a).

SAN-OS 3.0(2)

You can nondisruptively downgrade directly from SAN-OS Release 3.3(1a).

SAN-OS 3.0(1)

You can nondisruptively downgrade directly from SAN-OS Release 3.3(1a).

SAN-OS 2.1(3)

You can nondisruptively downgrade directly from SAN-OS Release 3.3(1a).

SAN-OS 2.1(2e)

You can nondisruptively downgrade directly from SAN-OS Release 3.3(1a).

SAN-OS 2.1(2d)

You can nondisruptively downgrade directly from SAN-OS Release 3.3(1a).

SAN-OS 2.1(2b)

You can nondisruptively downgrade directly from SAN-OS Release 3.3(1a).

SAN-OS 2.1(2)

Downgrade to SAN-OS Release 2.1(2b) and then downgrade to Release 2.1(2).

SAN-OS 2.1(1b)

Downgrade to SAN-OS Release 2.1(2b) and then downgrade to Release 2.1(1b).

SAN-OS 2.1(1a)

Downgrade to SAN-OS Release 2.1(2b) and then downgrade to Release 2.1(1a).

SAN-OS 2.0(4a)

Downgrade to SAN-OS Release 2.1(2b) and then downgrade to Release 2.0(4a).

SAN-OS 2.0(4)

Downgrade to SAN-OS Release 2.1(2b) and then downgrade to Release 2.0(4).

SAN-OS 2.0(3)

Downgrade to SAN-OS Release 2.1(2b) and then downgrade to Release 2.0(3).

SAN-OS 2.0(2b)

Downgrade to SAN-OS Release 2.1(2b) and then downgrade to Release 2.0(2b).

SAN-OS 2.0(1b)

Downgrade to SAN-OS Release 2.1(2b) and then downgrade to Release 2.0(1b).

SAN-OS 1.x

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.

FICON Downgrade Paths

Cisco MDS SAN-OS Release 3.3(1a) does not support FICON.

Refer to Table 8 for a list SAN-OS and NX-OS releases that support FICON. Refer to the specific release notes for FICON downgrade path information.

Downgrading the SSI Image on Your SSM

Use the following guidelines when downgrading your SSI image on your SSM.

•On a system with at least one SSM installed, the install all command might fail on an SSM when you downgrade from Cisco SAN-OS Release 3.3(1a) to any SAN-OS 2.x release earlier than SAN-OS Release 2.1(2e). Power down the SSM and perform the downgrade. Bring up the SSM with the new bootvar set to the 2.x SSI image.

•Fibre Channel switching traffic on SSM portsis not disrupted under the following conditions:

–All SSM applications are disabled. Use the show ssm provisioning CLI command to determine if any applications are provisioned on the SSM. Use the no ssm enable feature configuration mode CLI command to disable these features.

Rekey Operations

It is necessary to change media encryption keys periodically to ensure that only a limited number of tape cartridges have the same key, when using the key per volume group option. Rekey operations can be performed on a regular basis, using the new Volume Group Key Rekey feature.

Cisco SME has the ability to create new smart cards if they are lost. Release 3.3(1a) includes the option to rekey the cluster with a new master key when replacing smart cards by using the new Master Key Rekey feature.

Off-line Data Restore Tool

The Off-line Data Restore Tool enables end-users to recover data on tape media from a tape device attached to a Linux server. This feature addresses the need to recover data without using Cisco MDS 9000 Family hardware.

Media Servers with Drives in Two Fabrics

SAN-OS Release 3.3(1a) allows end-users to use Cisco SME in an environment where a single media server may have access to different tape drives on in different fabrics that reside in a common tape library.

Expanded Interoperability

The following enhancements in Release 3.3(1a) expand Cisco SME interoperability:

•Sun StorageTek 9940B drive support

•Increased hosts per target

•Interoperability with Brocade/McDATA Fabrics

•BakBone NetVault support

Note HP Data Protector support was introduced in release 3.2(3).

Enhanced Performance

SAN-OS Release 3.3(1a) includes performance optimizations for Cisco SME. This includes exceeding the typical throughput requirements for Linear Tape Open (LTO) 3 tape drives. This enhancement increases the maximum throughput for individual tape drives, but it does not change the total aggregate throughput for each Cisco SME interface (module). In addition, Release 3.3(1a) optimizes load balancing. which eliminates unnecessary use of Inter-Switch Links (ISLs). Cisco SME can also rebalance the assignments to improve utilization of the encryption resources

Fx-port Zoning Support

Cisco SME release 3.2(2c) only supports pWWN N-port zoning (defines zone members based on the host or storage port). Though this is the most commonly used zoning method, support now includes other zoning types such as Fx-port zoning (defines zone members based on the switch port). This expands the range of environments Cisco SME can be deployed in without SAN reconfiguration.

NPV Traffic Management

Prior to Release 3.3(1a), assignment of hosts to ports connecting a Cisco MDS 9000 Family switch in the N-Port Virtualization (NPV) mode to a core switch was automatic. You can now select the ports that servers use to connect to the core switches. For information on NPV, refer to the Configuring N Port Virtualization chapter in the Cisco MDS 9000 Family Configuration Guides.

Starting in Cisco MDS SAN-OS Release 3.3(1a), NPV will be supported on the Cisco Fabric Switch for IBM BladeCenter.

Secure Erase

The secure erase feature erases existing data on a given target in such a way that reconstructing that data is virtually impossible. SAN-based secure erase has numerous advantages over traditional data erase mechanisms such as higher speed, lower cost, ease-of-execution, and platform independence.

FlexAttach

FlexAttach is supported on the Cisco Fabric Switch for HP c-Class BladeSystem switch, the Cisco Fabric Switch for IBM BladeCenter switch, the Cisco MDS 9124 switch, and the Cisco MDS 9134 switch, when NPV mode is enabled. The FlexAttach feature reduces the time and coordination effort required by SAN and server administrators when installing and replacing servers. To alleviate interaction between SAN administrators and server administrators, it is important that changes are not made to the SAN configuration when a new server is installed or when an existing server needs replacement. FlexAttach is a new feature included in SAN-OS Release 3.3(1a) that addresses this issue. For information on FlexAttach, refer to the Configuring FlexAttach Virtual pWWN chapter in the Cisco MDS 9000 Family Configuration Guides.

Administrators can benefit from FlexAttach in the following scenarios:

•Pre-configuring—Pre-configure the SAN-like zoning using the virtual port WWNs in an existing change window for new servers which are not yet there physically and hence the port WWNs are unknown. The new servers are then plugged into the fabric without any change needed in the SAN.

•Replacement (new server)—Replace a server in the current server port without changing the SAN. This is possible because FlexAttach assigns a virtual port WWN to the port.

•Replacement (spare)—Bring the spare online without changes to the SAN. This is achieved by moving the virtual port WWN from the current server port to the spare port.

•Moving the server to a different switch—Move the server to another NPV device for any reason without changing the SAN (i.e, LUN masking and zoning changes are not required).

•Assigning automatic or manual vpWWNs mappings—Automatically create a vpWWN and assign it to a port on an NPV switch; or manually map a physical pWWN to a vpWWN connected to an NPV switch.

SMI-S

Cisco SAN-OS Release 3.3(1a) includes the following SMI-S enhancements:

•FDMI subprofile supporting management of the HBA on the host and the storage device.

•SMIS 1.2 compliance with current SAN-OS support.

•Basic logging facility.

•SMI-S 1.2 compliance for the server and switch profiles with limited support for Indications.

FCIP Interop

In Release 3.3(1a), support is included for FCIP interop between the MSM-18/4 module or MDS 9222i switch and the MPS-14/2 module, the MDS 9216i switch, or the IPS-8 module. FCIP is supported on the MPS-14/2 module, MDS 9216i switch, IPS-8 module, IPS-4 module, MDS 9222i switch, and the MSM-18/4 module. Table 10 shows the FCIP interoperability.

Cisco Fabric Manager Enhancements

New Configuration Wizards

Two new configuration wizards are included in the Cisco Fabric Manager Java user interface: the port-security wizard, and the N-Port Virtualizer (NPV) wizard. The port-security wizard streamlines provisioning by simplifying configuration tasks.

The NPV wizard enables Cisco MDS 9000 switches to quickly change to the NPV mode. The NPV wizard allows administrators to configure the most important options across many switches (up to 100 switches) in a single pass, thus providing considerable time savings.

Scalability Improvement

Increasing Cisco Fabric Manager scalability is essential to keep up with the growing Cisco MDS 9000 Family fabrics. Cisco Fabric Manager now includes the capability to discover and manage up to 10,000 end-devices on a single server when performance monitoring is enable.

Metro-Optical Link Display

Cisco Fabric Manager now discovers links using DWDM optics and displays them with a distinctive line pattern. This feature provides an easy-to-read display showing that the link is used for SAN extensions (relatively long distance links).

Upgrading to Recover Loss of Performance Manager Data

Caution You must upgrade to Fabric Manager Release 3.1(x) and then upgrade to a later release of Fabric Manager to avoid losing Performance Manager data. If data has been lost, follow the steps below to recover the data.

Maximum Number of Zones Supported in Interop Mode 4

In interop mode 4, the maximum number of zones that is supported in an active zone set is 2047, due to limitations in the connected vendor switch.

When IVR is used in interop mode 4, the maximum number of zones supported, including IVR zones, in the active zone set is 2047.

SNMP Version 3 Authentication

Multiple Cisco products contain either of two authentication vulnerabilities in the Simple Network Management Protocol Version 3 (SNMPv3) feature. These vulnerabilities can be exploited when processing a malformed SNMPv3 message. These vulnerabilities could allow the disclosure of network information or may enable an attacker to perform configuration changes to vulnerable devices. The SNMP server is an optional service that is disabled by default. Only SNMPv3 is impacted by these vulnerabilities.

Note SNMP versions 1, 2 and 2c are not impacted by these vulnerabilities.

The United States Computer Emergency Response Team (US-CERT) has assigned Vulnerability Note VU#878044 to these vulnerabilities. Common Vulnerabilities and Exposures (CVE) identifier CVE-2008-0960 has been assigned to these vulnerabilities.

This advisory is posted at http://www.cisco.com/en/US/products/products_security_advisory09186a00809ac83b.shtml.

Workarounds are available for mitigating the impact of the vulnerabilities described in this document.

Java Web Start

When using Java Web Start, it is recommended that you do not use an HTML cache or proxy server. You can use the Java Web Start Preferences panel to view or edit the proxy configuration. To do this, launch the Application Manager, either by clicking the desktop icon (Microsoft Windows), or type ./javaws in the Java Web Start installation directory (Solaris Operating Environment and Linux), and then select Edit>Preferences.

If you fail to change these settings, you may encounter installation issues regarding a version mismatch. If this occurs, you should clear your Java cache and retry.

Storage Media Encryption Not Supported

MDS SAN-OS Release 3.3(1a) does not support the Storage Media Encryption application because of the open caveat CSCsw95386. A fix for this issue is available in SAN-OS Release 3.3(3) and in NX-OS 4.1(3a). Customers who do not plan to upgrade to SAN-OS Release 3.3(3) or NX-OS Release 4.1(3a), but who need an immediate fix for CSCsw95386 should obtain MDS SAN-OS Release 3.3(2E2), which is a special engineering release for customers who are running SAN-OS Release 3.3(2) and using SME.

Cisco MDS 9222i Module Upgrade

On the MDS 9222i module, an upgrade from SAN-OS Release 3.2(x) to Release 3.3(1a) is not supported if there is a Cisco SME or Cisco DMM configuration in the fabric for hosts and targets attached to the MDS 9222i module.

SANTap

The SANTap feature allows third party data storage applications, such as long distance replication and continuous backup, to be integrated into the SAN. SANTap is not supported in Release 3.3(1a).

Applying Zone Configurations to VSAN 1

In the setup script, you can configure system default values for the default-zone to be permit or deny, and you can configure default values for the zone distribution method and for the zone mode.

These default settings are applied when a new VSAN is created. However, the settings will not take effect on VSAN 1, because it exists prior to running the setup script. Therefore, when you need those settings for VSAN 1, you must explicitly issue the following commands:

•zone default-zone permitvsan 1

•zoneset distribute fullvsan 1

•zone mode enhancedvsan 1

Running Storage Applications on the MSM-18/4

The Cisco MDS 9000 18/4-Port Multiservice Module (MSM-18/4) does not support multiple, concurrent storage applications. Only one application, such as SME or DMM, can run on the MSM-18/4 at a time.

Compatibility of Fabric Manager and Data Mobility Manager

Cisco Fabric Manager in any MDS NX-OS 4.1(x) release does not support Data Mobility Manager (DMM) in any SAN-OS 3.3(x) release or in any 3.2(x) release. To use the Cisco Fabric Manager GUI for DMM, both Fabric Manager and DMM must be running NX-OS or SAN-OS software from the same release series.

PPRC Not Supported with FCIP Write Acceleration

Using IVR In a Fabric With Mixed Code Versions

If you are using IVR and you are running SAN-OS 3.x software on your MDS switches, make sure that all IVR switches run the same code version. Otherwise, if you have a fabric with mixed code versions, the switches running the higher version may not be able to see all IVR devices. The mixed fabric can cause an inconsistent database among IVR switches, which might affect IVR behavior. For this reason, it is important that all IVR switches run the same SAN-OS version, preferably SAN-OS Release 3.3(4a), which has device update (DU) support, or later.

Caveats

This section lists the open and resolved caveats for this release. Use Table 11 to determine the status of a particular caveat. In the table, "O" indicates an open caveat and "R" indicates a resolved caveat.

Resolved Caveats

•CSCso55990

Symptom: Traffic entering thru a Generation 1 module may be disrupted when upgrading from Release 3.1(3) and earlier to any image later that Release 3.1(3) but earlier than Relese 3.3(1a), if we have active egress SPAN sessions configured with the source as ports that are administratively up but operationally down.

Workaround: This issue is resolved.

•CSCsj68846

Symptom: In some instances, the host is not able to see the SAN Device Virtualization (SDV) virtual targets that it is zoned with. The host performs FLOGI, PLOGI and PRLI successfully, followed by SCSI inquiry. The hosts stop at REPORT LUNS.

Workaround: This issue is resolved.

•CSCsk58368

Symptom: During In-Service Software Upgrade (ISSU), Inter-VSAN Routing (IVR) gets initialized later than Fibre Channel Name Service(FCNS). FCNS checks with IVR for entries which it has in its persistent storage and that belong to IVR (for virtual domains). Since IVR is not initialized yet, it does not respond to FCNS. As a result, an end device may not be advertised to a transient VSAN or it may not be visible to the IVR end device in a target VSAN.

Workaround: This issue is resolved.

•CSCsk71439

Symptom: After upgrading to SAN-OS Release 3.2(3a) or later, the module stays in the "failure" state or rests.

Workaround: This issue is resolved.

•CSCsl90865

Symptom: Following and upgrade to SAN-OS Release 3.3(1a), if there is a VSAN mismatch on the external link between the NPV switch and the core switch, the link will not come up after a link flap or link re-initialization.

Workaround: This issue is resolved.

•CSCsl04532

Symptom: In a VSAN in which a large number of FICON devices exist and FICON tape acceleration is enabled, FICON tape acceleration performance degradation occurs. The FICON devices do not have to be tapes or virtual tapes; for example, they can be disks.

Workaround: This issue is resolved.

•CSCsl96144

Symptom: Under rare conditions, the standby Supervisor module and the active Supervisor module will not have the module capability synchronized. This can be seen by issuing the show system internal capability module <module-no> command on every standby module that is online. Review the output and locate the last entry: CAP_TYPE_MODULE_INFO. The output should display a status of ModuleOnline as shown in the example below.

switch#show system internal capability module <module-no>

113) Service:platform, Capability:CAP_TYPE_MODULE_INFO

Registered by node:0x102 at 1 usecs after Thu Jun 29 13:47:00 1978

Description:Sets Module online status

proc type Linecard

status Module Online

sw card id 2

switch#

Workaround: This issue is resolved.

•CSCsm12840

Symptom: During In-Service Software Upgrade (ISSU), SAN Device Virtualization (SDV) gets initialized later than Fibre Channel Name Service(FCNS). FCNS checks with SDV for entries which it has in its PSS and that belong to SDV (for virtual domains). Since SDV is not initialized yet, it will not respond to FCNS. As a result, the SDV entries in the virtual domain will be missing.

Workaround: This issue is resolved.

•CSCsm22961

Symptom: The accounting log does not record status updates for zone attribute changes in basic mode.

Workaround. This issue is resolved.

•CSCsm35980

Symptom: In a fabric with a very large number of Fibre Channel Name Server (FCNS) devices, if you add one more switch to the fabric, the name server on the newly added switch will receive a query from all other switches in the fabric. It will also receive responses to the queries it sent to other switches in the fabric. When all queries and responses are sent and received in a short period of time, the Fibre Channel 2 stack may drop some of them and the FCNS database may be out of sync.

Workaround. This issue is resolved.

•CSCsm37724

Symptom: When the active IVR zoneset contains enhanced device alias-based members, traffic to and from these devices could be disrupted during a stateful restart or a switchover to a Supervisor module. This issue occurs under the following conditions:

–The device alias feature is running in enhanced mode.

–The active IVR zoneset includes at least one member configured using the device alias name.

–Any one of the following events occurs:

a) The system is running a SAN-OS release earlier than Release 3.3(1a) and either a stateful restart of the IVR process or a switchover to another Supervisor running the same SAN-OS release occurs.

b) The system is downgraded to a SAN-OS release earlier than Release 3.3(1a).

Workaround: This issue is resolved.

•CSCsm59837

Symptom: A SAN Device Virtualization (SDV) configuration is terminated after an ACL failure due to a Ternary Content Addressable Memory (TCAM) Full condition. This occurs in situations where there are large SDV configurations (for example, 1,000 devices) and when the TCAM becomes full due to excessive entries on a single interface.

Workaround. This issue is resolved.

•CSCsm69351

Symptom: Inter-Switch Link (ISL) isolation is seen due to a zone merge failure in interop mode 1. This can occur when a Cisco MDS switch with a large active zoneset tries to merge with non-MDS switches. Since the merge request size is sent out incorrectly in MRRA, some non-MDS switches may reject the subsequent merge request frame leading to an ISL isolation.

Workaround. This issue is resolved.

•CSCsm87092

Symptom: A zone commit operation fails. The following message is displayed: No pending info found. This issue occurs when the device-alias is in basic mode and an enhanced zoning session exists. When those conditions exist, if a device-alias is renamed, the lock acquired in enhanced zoning is lost. This causes the zone commit operation to fail.

Workaround. This issue is resolved.

•CSCso59902

Symptom: On an MDS 9513 switch, if a hardware failure on one of the two redundant crossbar modules occurs, it is possible to experience traffic disruptions. Certain FC interfaces may go down and they may not come up again. The output of the show interface command for these interfaces may be similar to the following example.

fc1/2 is down (Link failure: Link Reset failed, non-empty recv queue)

Port description is vader

Hardware is Fibre Channel, SFP is short wave laser w/o OFC (SN)

Port WWN is 20:02:00:0d:ec:3b:09:00

Admin port mode is FX

snmp link state traps are enabled

Port vsan is 200

Receive data field Size is 2112

Beacon is turned off

5 minutes input rate 0 bits/sec, 0 bytes/sec, 0 frames/sec

5 minutes output rate 0 bits/sec, 0 bytes/sec, 0 frames/sec

2933212200 frames input, 4823200761788 bytes

0 discards, 0 errors

0 CRC, 0 unknown class

0 too long, 0 too short

9812020429 frames output, 9487579066196 bytes

0 discards, 0 errors

2 input OLS, 2 LRR, 0 NOS, 6 loop inits

3 output OLS, 2 LRR, 3 NOS, 5 loop inits

This happens only in conditions when a crossbar module on an MDS 9513 switch fails. The output of the show hardware command will indicate that the status of the crossbar module is not "ok".

Workaround: This issue is resolved.

•CSCso63759

Symptom: When IVR is configured, the active Supervisor may fail when issuing any of the following CLI commands:

show tech

show tech detail

show system interface fcfwd idxmap ...

This issue may also occur when using the show tech-support option in Fabric Manager.

Workaround: This issue is resolved.

•CSCso72056

Symptom: Whena SAN-OS upgrade is performed on a Supervisor 1 module, in rare cases, SNMP might fail and the upgrade may fail causing the upgrade to be disruptive.

Workaround: This issue is resolved.

•CSCso72187

Symptom: Polling does not work with multiple fabrics.

Workaround: This issue is resolved.

•CSCsl22293

Symptom: The accounting log does not record all commands that are run on the system.

Workaround. This issue is resolved.

•CSCsl33763

Symptom: In Cisco SME, tape device names can not include special characters (such as hyphens or underscores). This will cause future tape device creations for a tape group to fail.

Workaround: This issue is resolved.

•CSCsl70489

Symptom: When a QoS classmap is created from Fabric Manager with a space between the two words comprising a classmap (for example: "classmap sample map" instead of "classmap samplemap"), the switch accepts the configuration. However, the switch rejects the configuration during start up if the same information is stored in the start-up configuration because the CLI does not allow spaces.

Workaround. This issue is resolved.

•CSCsl99803

Symptom: When you run Encrypter.(sh | bat), you see the following exception:

In addition, the size of the login-config.xml file in the MDS 9000/jboss/server/default/conf directory becomes 0. This occurs when using JRE 1.6 or above.

Workaround: This issue is resolved.

Workaround: (for 3.2.1 to 3.3.1) For Linux or Solaris, go to the MDS 9000/bin directyory. Edit the Encrypter.sh file and remove the text $LIB/crimson.jar: in the file . Note the colon at the end of the text needs to be removed also.

For Windows, go to MDS 9000\bin directory. Edit the Encrypter.bat file and remove the text %INSTALLDIR%\lib\crimson.jar; . Note the semicolon at the end of the text need to be removed also.

After completing the steps above, replace the login-config.xml with the attached file. Find this string: <module-option name="username">DBUSER</module-option> and replace the DBUSER with your db username. Run the script again with the correct db password.

•CSCsm15556

Symptom: When you issue the show running-config command, the iSCSI initiators are not shown. This may occur even though the iSCSI session and the show startup-config command shows the iSCSI initiators correctly. Even after issuing the copy run-start command, the show running-diff command shows iSCSI information as the difference.

Workaround: This issue is resolved.

•CSCsm16449

Symptom: SAN Device Virtualization (SDV) virtual FCIDs are inconsistent across different switches. This issue can occur when SDV is enabled and if the SDV internal port-table is out of sync with the Fibre Channel Name Service (FCNS).

Workaround. This issue is resolved.

•CSCsm47300

Symptom: To send the SNMPv3 Inform packet, the SNMP remote user (the SNMPv3 user with an engineID other than the local engineID) credentials need to be configured on the switch. If the remote user name is configured as "admin", the remote user can not be deleted from the switch.

Workaround. This issue is resolved.

•CSCsm55837

Symptom: For an RMON alarm that uses event 0, the first rising alarm will trigger, but subsequent alarms will not. If the event identifier is changed to a configured event identifier, the alarm will work.

Workaround: This issue is resolved.

•CSCsm61993

Symptom: If there are uncommitted changes in Dynamic Port VSAN Membership (DPVM), while committing the changes for a device alias then the Messaging and Transanction Service (MTS) buffer may start to fill up and may eventually run out of space. When this occurs, the following error is displayed: mts_acquire_q_space failed for opcode.

Workaround. This issue is resolved.

•CSCsm75849

Symptom: On a Generation 2 Supervisor module, a PLOGI ACC frame generated by private loop devices (with the TL port attached) is forwarded with a swapped domain-IDand area-ID in the source FCID. The incorrect format is shown as AADDPP instead of DDAAPP (correct format). This prevents the PLOGI between the host and storage to complete successfully

Workaround. This issue is resolved.

•CSCsm82629

Symptom: The show running CLI command output displays the scheduler configuration with an incorrect schedule time value. However, this appears correctly when you issue the show scheduler config CLI command. As a result, if you issue the copy running-start command and the startup configuration is replayed, there will be a syntax error in the scheduler schedule CLI command.

Workaround. This issue is resolved.

•CSCsm92338

Symptom: Only the first 100 RMON hcalarms (64 bit) show up in the running-configuration and the startup-configuration. The configuration is kept in the system and will survive across reboots, but it cannot be moved to another Supervisor (for example, in the case of a total Supervisor replacement). This problem does not affect 32-bit alarms. This occurs when the RMON alarm limit has been raised from the default value of 100. This issue does not affect 32-bit alarms.

Workaround. This issue is resolved.

•CSCsm96032

Symptom: The number of maximum RMON alarms is not visible in the CLI.

Workaround: This issue is resolved.

•CSCso01396

Symptom: Using a third-party SNMP tool for a full SNMP walk on an MDS 9222i Switch may trigger a kernel failure. Using Fabric Manager or Device Manager will not cause a failure.

Prior to the failure, you might see a message similar to the following. This message indicates that full SNMP walks are occurring:

Symptom: Due to CSCsl96144, after a Supervisor switchover, the platform manager API failed when the ACL called it. Due to that failure, the ACL didn't handle the IVR request to program or delete the PLOGI capture properly. As a result, IVR could not finish the domain capture which stopped the IVR device export.

Workaround: This issue is resolved.

•CSCso58505

Symptom: Symptom: Using Fabric Manager Server, tape drives and tape groups are not listed in the tape group configuration. This occurs when a Cisco SME VSAN is isolated in the fabric or when the tape drives are in VSANs that are segmented in a fabric.

Workaround: This issue is resolved.

•CSCso69941

Symptom: In Fabric Manager, when using the Alias -> Enclosure button at the End Device Table, alias names are not converted. For example, "Alias-Port1" does not convert to "Alias"(by taking out the hyphen). In releases prior to Release 3.3(a), the convertion occurred correctly.

Workaround: This issue is resolved.

•CSCso71302

Symptom: When a bootflash failure occurs, Call Home destination profiles, for example, XML, with only the Cisco TAC alert group, do not get the notification.

Workaround: This issue is resolved.

•CSCso76844

Symptom: A login to Fabric Manager Server is not successful using a disconnected client.

Workaround: This issue is resolved.

•CSCso78523

Symptom: When 2 Fabric Manager clients simultaneously change the device alias for the same port using the End Device Table, an apply error is displayed on the second Fabric Manager client; and, after a refresh, the old value does not exist.

Workaround: This issue is resolved.

•CSCsm63009

Symptom: A 64-bit alarm may log a startup alarm after a system reboot.

Symptom: When you configure a 32-bit RMON alarm as a delta alarm, the switch sends rising and falling traps with alarmsampletype as absolute alarms not as delta alarms.

Workaround: This issue is resolved.

•CSCsm17768

Symptom: There is a observable performance drop for backup and restore when Cisco SME is introduced between a host and tape due to the increased latency.

Workaround: This issue is resolved.

Open Caveats

•CSCsc17059

Symptom: In rare circumstances, after upgrading the SAN-OS, a Generation 1 module may be rebooted as it stops responding to the keep alive messages from the Supervisor module.

Workaround: None.

•CSCsg49151

Symptom: If you bring up more than one link at a time between two VSANs that have overlapping domains and at least one of the switches is SDV enabled, one link will become isolated. The other links will come up, even though the domains are overlapping. In addition, the SDV virtual domains will change, causing traffic disruption on all devices associated with their old value.

Workaround: Bring up multiple links between two switches one at a time. Verify that the first link came up correctly before attempting to bring up the next link. If the first link fails to come up because of a domain ID overlap, resolve the domain conflict and then try again to bring up the links.

•CSCsi72048

Symptom: FCIP links may fail on an MDS 9216i switch that has compression set to auto when the other end of the FCIP link is terminated by an IPS-8 module. You may see the following message in the logs:

Workaround: If both ends of an FCIP link are not on an MPS-14/2 module, do not use mode 1 and auto.

•CSCsk43922

Symptom: A data path processor (DPP) might fail on an MDS switch running SSI Release 3.2(1) on the SSM. The failure occurs after several days of running traffic when a misbehaving target sends unexpected frames well after the response has already been received from the same target.

Workaround: None.

•CSCsk49029

Symptom: If there is a request to export a domain while the same domain is being cleaned up, domain entries might not be programmed. As a result, communication between IVR devices might not occur.

Workaround: Because the programming request was lost, the only way to retrigger the programming is to withdraw the domain and refresh IVR. Follow these steps:

1. Identify domains with problem using the show ivr internal dep command.

After waiting for a few minutes for IVR to stabilize, if the status column for the {vsan, domain} combination is NONE, then this problem has occurred the switch.

2. Withdraw the troubled domains using the ivr withdrawdomaindomainvsanvsan-id command.

3. Readvertise the withdrawn domains using the ivr refresh command.

•CSCsk49634

Symptom: In rare cases, an FCIP link might flap on a network with high latency and a consistently high loss rate (above 100ms RTT and 0.5% loss).

Workaround: None.

•CSCsk51193

Symptom: Following an upgrade to Cisco MDS SAN-OS Release 3.2(1) on a Cisco MDS 9124 switch, an interface is shown as up, but there is no FLOGI information for the port in the FLOGI database.

Workaround: Set the port mode to F.

•CSCsl32492

Symptom: Certain drivers cache the PRLI service parameters negotiated across the PLOGI/PRLI session establishment. If a library controller that does not support RETRY FCP-2 error recovery procedures is included in a SME configuration, SME may negotiate RETRY in PRLI with the host. Subsequently, if the library controller is removed from SME, the host driver may cache the PRLI parameter and attempt to perform SRR, which gets rejected by the target.

Workaround: When configuring an SME cluster through the web client, exclude the library controller target ports in the target port selection window. For those tape libraries, where the library controller and tape drives are exported as LUNs behind the target port, this is not an issue.

•CSCsl39215

Symptom: The CIM server stops. This occurs after creating a subscription using the same filter and handler.

Workaround: Reload the switch.

•CSCsl71227

Symptom: Using Fabric Manager Release 3.2(2), if you have an enclosure with multiple ports and you then use the Data Migration Wizard to create a job with that enclosure as the existing storage but don't select all the storage ports in the enclosure, an error is displayed in the creation wizard.

Workaround: Put the ports you plan to use as the existing storage in the migration into a separate enclosure, and use that enclosure in the wizard selection.

•CSCsm54544

Symptom: In some instances, when requests to the control virtual target (CVT) are made, Fabric Manager times out. Regardless of the timeout, the CVT is created in the specified VSAN.

Workaround: To verify this, do either of the following:

–Refresh the SANTap CVT field. The CVT will appear.

–Verify the CVT creation on the Supervisor by issuing the show santap module <#> cvt CLI command.

•CSCsm80790

Symptom: An FCIP link was going down because a data path processor (DPP) process had failed because of traffic on an internal chip.

Workaround: None.

•CSCso19341

Symptom: Under very rare circumstances, the ports on an MDS 9000 24-port 4-Gbps Fibre Channel module and on an MDS 9000 48-port 4-Gbps Fibre Channel module might fail and the state of the ports might change to hwFailure, or the module might reload when all the ports on the module fail.

If this occurs, the output of the show logging log command will be similar to the following:

Symptom: On the MDS 9222i module, an upgrade from SAN-OS Release 3.2(x) to Release 3.3(1a) fails when there is an active FC-Redirect configuration (created by Cisco SME or Cisco DMM applications) on the switch. An active FC-Redirect configuration is defined as:

–FC-Redirect configuration for hosts or target connected locally

–FC-Redirect configuration created by application running on that switch.

If an upgrade is attempted when such active configuration is present, the switch will go into a disruptive upgrade.

Workaround: None. On the MDS 9222i module, an upgrade from SAN-OS Release 3.2(x) to Release 3.3(1a) is not supported if there is a Cisco SME or Cisco DMM configuration in the fabric for hosts and targets attached to the MDS 9222i module.

•CSCso36760

Symptom: In Fabric Manager Release 3.3(x), zone set cloning returns an autoZoneEditing error. The option to clone a zone is missing.

Workaround: You can upgrade to Fabric Manager Release 3.4(1a), or, if you are using Fabric Manager Release 3.3(x), you can resolve the issue by following these steps:

1. Insert a new zone.

2. Select the zone you want to clone.

3. Select all the members in the zone to clone.

4. Drag the selected members to the new zone, which copies the zone members, but does not move them.

To resolve this issue from the CLI, enter the zoneset clone Zoneset1v1 clone # vsanvsan-id command.

•CSCso41087

Symptom: If FCIP is enabled and the SAN-OS is upgraded, the SNMP service will run into exception and the following syslog message is displayed: SNMP Operation(165) failed (62) setting error index.

Workaround: None. The chance of a module reload occurring again on the same module is very rare. Therefore, continued use of the module is acceptable.

A software workaround for this issue exists in SAN-OS Release 3.3.(2) and NX-OS Release 4.(1b). Upgrading to one of those releases will help decrease instances of modules reloads.

•CSCin95789

Symptom: When you configure Cisco Traffic Analyzer to capture traffic on one or more interfaces on a Windows platform, the configuration web page might not show that the interface has been selected for traffic capture even though traffic capture on that interface is enabled.

Workaround: Check the logs to clarify that the correct interface has been selected.

•CSCse31881

Symptom: If there are IP over Fibre Channel (IPFC) interfaces configured on an SSM, you might experience issues if you downgrade from SAN-OS Release 3.x to Release 2.x.

Workaround: Before downgrading, remove the IPFC interface on the module and then recreate the IPFC interface after the downgrade is complete.

•CSCse47687

Symptom: If IP ACLs are applied to any IP Storage Gigabit Ethernet port, implicit deny does not take effect.

Workaround: Configure explicit deny on the port.

•CSCsg19148

Symptom: Time zone changes that are executed on an MDS switch do not take effect on the 12-port, 24-port, and 48 port 1-Gbps/2-Gbps/4-Gbps Fibre Channel modules, and on the 4-port 10-Gbps module. This issue occurs in SAN-OS Releases 3.0(1), 3.0(2), 3.0(2a), and 3.0(3).

Time zone changes that are executed on an MDS switch do not take effect on the 16-port or 32-port 1-Gbps/2-Gbps module, on the 4-port or 8-port Gigabit Ethernet IP services module, the MPS-14/2 module, and on the SSM. This issue occurs in SAN-OS Release 3.0(3).

This issue has no effect on functionality. However, debug messages and syslogs from the MDS switching modules have incorrect timestamps if the time zone is configured on an MDS switch.

Workaround: None.

•CSCsg19303

Symptom: Graceful shutdowns of ISLs are not supported for IVR traffic.

Workaround: Increase the FSPF cost on the link before it is shut down, so that traffic will flow through an alternate path.

•CSCsi66310

Symptom: The management port on MDS switches supports one user-configured IPv6 address, but does not support autoconfiguration of an IPv6 address in Cisco SAN-OS Release 3.2(1).

Workaround: None.

•CSCsj24904

Symptom: On a Gigabit Ethernet interface on an MDS MSM-18/4 module, shut the interface before removing its IP address so that configuration changes on the interface can take effect. This applies only to the Gigabit Ethernet ports in slot 1 of the MDS 9222i switch and the MDS 9216i switch.

Workaround: Always shut the interface using the shutdown command before removing the IP address and making configuration changes.

•CSCsj72666

Symptom: In certain conditions, an MDS switch may not be able to determine the FC4-type of certain targets. This causes the targets to be listed in the hosts section during a Cisco SME tape group or tape device configuration.

Workaround: Issue the discover scsi-target vsan vsan-id fcid fcid command to re-discover the FC4-type of the targets. A Cisco SME tape group or tape device configuration will now list the targets correctly.

•CSCsk06186

Symptom: In rare situations, on an MDS 9513 director switch, an upgrade fails when a standby supervisor does not come up to a state that the installer recognizes. As a result, the standby supervisor is reloaded to recover and the system runs the older configuration version.

Workaround: Perform the upgrade again.

•CSCsk35725

Symptom: Fabric Manager takes 2 to 3 minutes to bring up the DMM job creation wizard in a setup with 25 switches, 400 enclosures, and 2400 entries in the name server.

Workaround: None.

•CSCsk35951

Symptom: In a configuration with a PortChannel with FCIP members and write acceleration in use, if IVR NAT is enabled on one end of the PortChannel and not enabled on the other end, then traffic over the FCIP tunnel might fail.

Workaround: Enable IVR NAT on both ends of the PortChannel or disable it on both ends.

•CSCsk49309

Symptom: IPv6 duplicate address detection (DAD) may not always works for the management port.

Workaround: None.

•CSCsk63929

Symptom: If DMM is provisioned on the SSM and you downgrade to a Cisco MDS SAN-OS release that does not support DMM, the configuration persists and the GUI and CLI show DMM as a provisioned application.

Workaround: Manually remove the DMM configuration from the switch before downgrading to a Cisco MDS SAN-OS release that does not support DMM, such as downgrading from SAN-OS Release 3.2(1) to SAN-OS Release 3.1(3). If you forget to remove the configuration before the downgrade, power off the module and purge the configuration on the SSM module by entering the following commands:

Symptom: If an NASB configuration in a VSAN is destroyed while a target discovery is pending, the NASB process fails. Issue the show nasb vsanx command on the SSM to view the target discovery in the Pending state.

Workaround: Reload the SSM.

•CSCsk87614

Symptom: When NASB is enabled in a VSAN, all targets that are visible in that VSAN are discovered by NASB. If a new target is added to the VSAN, NASB does not automatically discover the new target.

Workaround: To discover the new target, reload the SSM or disable and re-enable NASB in the VSAN.

•CSCsk93834

Symptom: In rare situations during a storage-based online data migration job, the user might not be able to destroy the job if the following sequence of events occurs:

1. A storage-based data migration job is executing.

2. A port flap occurs on the server and the server HBA port goes down.

4. The user issues the dmm modulemodule-idjobjob-iddestroy command to delete the storage-based data migration job, but the delete fails.

Workaround: Reload the SSM.

•CSCsk95241

Symptom: If you use JDK instead of JRE on Solaris, you might encounter a problem trying to install Device Manager from a web browser. This can happen because the installer heap limit of 256 MB is not sufficient.

Workaround: If you have this problem, save the jnlp link as file, increase the heap limit to 512 MB, and run javaws element-manager.jnlp at the shell prompt.

•CSCsl12130

Symptom: After a disruptive downgrade or upgrade between SAN-OS Release 3.2(2c) and Release 3.2(1a), issuing a no shutdown command on a Cisco SME interface fails. When issuing the install all command to perform the downgrade process, a warning is issued that indicates that the downgrade will be disruptive if Cisco SME is enabled.

Workaround: Disable Cisco SME before proceeding with the downgrade process. If you perform a disruptive downgrade, then issue the purge moduleslotrunning-config command for the MSM-18/4 modules where Cisco SME is configured after the downgrade is complete.

•CSCsl15511

Symptom: On the MDS 12-port, 24-port, and 48-port 4-Gbps Fibre Channel switching modules, and on the 4-port 10-Gbps Fibre Channel switching module for downgrades from 3.2(2c) to lower versions, if fcdomain persistency is disabled, F ports may not come up after a shutdown or no shutdown or a link flap.

Workaround: Shut the F port, enable and disable fcdomain persistency for that VSAN, and then bring up the F port.

•CSCsl17944

Symptom: During an MDS 9222i switch reload, the connection from the management port (mgmt0) to the Gigabit Ethernet interface goes down. When the connection comes back up, the Gigabit Ethernet interface doesn't go into forwarding mode until 30 seconds later. The Fabric Manager server is not able to communicate to the MDS 9222i switch through SNMP during this 30 second window.

Workaround: If the switch is in the Cisco Ethernet switch family, configure port-fast to resolve the issue. On Ethernet switches from other vendors, apply a similar configuration mode.

•CSCsl12611

Symptom: Devices attached on a remote McData switch do not show a correct physical connection on the correct port in Fabric Manager. This occurs because the registered devices in the McData nameserver are shifted by 4 from its actual physical port and Fabric Manager looks at this port address from the nameserver to locate the physical port.

Workaround: None.

•CSCsl31087

Symptom: In DMM, if a server I/O to a LUN fails during data migration, that session is marked as failed. The DMM migration job is then moved to a Failed state when the remaining sessions are complete. Such a failed migration job can be scheduled for a restart. If such a failed migration job is scheduled to start in less than 5 minutes from the time of scheduling, and another server I/O to a session LUN fails in that 5 minute window, the migration job will move from a Scheduled state to a Failed state. An administrator has the option to start the job immediately or schedule it again. This problem does not happen if an administrator schedules the migration job to start more than 5 minutes from the time of scheduling.

Workaround: Schedule the data migration job to start more than 5 minutes from the time of scheduling.

•CSCsl34922

Symptom: Dual-fabric DMM migration jobs can not have one fabric running Release 3.2(1a) and a peer fabric running Release 3.2(2c) due to a signal message change. This may cause unexpected results during a DMM migration job validation, creation, start, and so on.

Workaround: Run both fabrics with the same software image.

•CSCsl42571

Symptom: SNMP timeouts occur when a AAA user ages out.

By design, a AAA user is aged out every hour on a switch for security reasons. If a large fabric is discovered using a AAA user and a Performance Monitoring (PM) collection is added for such a fabric, a number of SNMP requests (related to the discovery or PM statistics collection) could time out. When a user views the PM statistics charts (in the Performance tab in the web client), the charts are not seen as continuous.

Workaround: There are two workarounds for this issue. One or both of these workarounds can be used to mitigate this issue.

•Turn on Interpolation by clicking on the Interpolation check box under Admin->Configure->Collections in the web client. This will insure that the charts are continuous in the case of any occasional legitimate timeouts.

•Use a non-AAA user (for example, use a local user on the switch) for a large fabric discovery and for Performance Monitoring. For provisioning and configuration through the Fabric Manager web client, the user can still be authenticated remotely using AAA.

•CSCsl65951

Symptom: Using Fabric Manager Release 3.2(2), an error is displayed in the creation wizard. This occurs when an enclosure spans multiple fabrics and not all fabrics are managed and when the Data Migration Wizard is used to create a job with that enclosure as the existing storage (selecting all ports listed in that enclosure).

Workaround: Put the ports you plan to use as the existing storage in the migration into a separate enclosure, and use that enclosure in the wizard selection.

•CSCsm08837

Symptom: When an IVR-enabled MDS switch with an empty device alias database, attempts to join a fabric which has approximately 7000 device aliases, the device alias merge fails. In this situation, the following occurs:

–During the merge process between local and remote switches, the remote device alias database is received on the local switch. The local switch validates those device aliases with SAP 110 (which is IVR).

–Since all 7000 aliases could not be sent in a single MTS message, the aliases are fragmented into 5 messages.

–While IVR requires approximately 20 seconds to process each fragment, effectively it takes around 100 seconds to process all 5 messages.

–Because DDAS has a timeout of around 60 seconds, the merge is rejected.

–The merge process is retried after few minutes and the process repeats. Then finally failed.

Workaround: Enable device alias CFS distribution before enabling IVR.

•CSCsm47252

Symptom: DMM jobs move to the Reset state and the following reason is displayed: Peer connection failure. In a Cisco DMM dual-fabric topology, the Storage Service Module (SSMs) in the two fabrics communicate with each other over IP by establishing a TCP connection. This connection is routed IP over FC to the local Supervisor and from the Supervisor it is switched over the IP mgmt interface. As a result, if there is a Supervisor switchover, the TCP connection may or may not survive the switchover. In the event that the TCP connection cannot be re-established in time, the DMM jobs in that SMM will move to the Reset state.

Workaround: None.

•CSCsm54071

Symptom: Data Virtual Targets (DVTs) are lost after a downgrade from Release 3.3(1) to earlier releases

Workaround: None.

•CSCsm63010

Symptom: In SAN-OS Release 3.2(3a) or earlier, Cisco DMM did not include Method1 and Method2 DMM jobs. In those releases, stored configurations were treated implicitly as Method1 DMM jobs. Configurations now stored by SAN-OS Release 3.3(1a) but read by Release 3.2(3a) or earlier, are assumed to be Method1 jobs.

Workaround: None.

•CSCsm68314

Symptom: For a storage-based DMM job that is in the Scheduled state, if the server HBA port goes offline, then the scheduled DMM job will not start. Scheduled DMM jobs start only when all server HBA ports and storage ports are up.

Workaround: For scheduled DMM jobs, make sure all server HBA ports and storage ports (both existing and new storage) are up.

•CSCsm94323

Symptom: When a PortChannel is created between 2 switches using the PortChannel wizard in Fabric Manager, the map might not immediately update and may not show the ISLs as part of the PortChannel. After a few discovery cycles, if the map is not updated, then the ISLs may be displayed along with the PortChannel in the map.

Workaround: Using Fabric Manager, remove the fabric and then re-discover the fabric.

•CSCso05448

Symptom: FCIP links might fail to come up after a module reload following a hardware failure on the module.

Workaround: Upgrade to NX-OS 4.1(1b) and reload the module where the failure occurred by entering the reload module command.

•CSCso02848

Symptom: In Cisco DMM, if a Data Migration Job is configured for an Active-Passive array, only the paths on the active controller of the storage are included as part of the job. (Refer to the Cisco MDS 9000 Family Data Mobility Manager Configuration Guide). As a result, if a LUN Trespass has occurred due to a controller fail-over, the host I/Os on the new path to the storage are not captured by DMM and they are not applied to the new storage.

Workaround: If a LUN trespass or controller-failover occurs during migration, destroy the job and recreate it to perform the migration again. This will ensure that the old and new storage are synchonized.

•CSCso55622

Symptom: In Microsoft Windows 2000, 2003, 2003 R2, and 2008, when installing Fabric Manager, Fabric Manager Server, and Device Manager, a service may not restart and/or may not properly execute the PostreSQL installer. This may lead to an incorrect conversion of the PostreSQL database and/or the service may not start. This occurs when running Microsoft Windows 2000, 2003, 2003 R2, or 2008 with Terminal Server running in Application mode.

Note This applies only to Terminal Server running in Application Mode. This issue does not affect users running a Terminal Server or Remote Desktop session in Remote Administration mode.

Workaround: Before you install Fabric Manager, Fabric Manager Server, and Device Manager when using Microsoft Terminal Server in Application mode, you must install the application for global use. This is required when a Service is installed and invoked, and when creating a local dbadmin user. To activate this setting, do the following:

1. Before running the installation script from the Fabric Manager Installation CD, open a command-line prompt: Start > Run, then type cmd and press Return.

2. At the command prompt type: Change user /install.

Note Do not close the command line window. This must remain open for the entire duration of the install.

Workaround: Do not use LUN 0x45F0 and LUN 0x50F0 when Generation 2 modules are present in the fabric.

•CSCsr85709

Symptom: Under certain conditions, the port manager can take a long time to respond to a port configuration, which can trigger a set-port-configuration failure. If this occurs, then the FCIP tunnel will not come up and will stay in a disabled state.

Workaround: Enter a shut command, followed by a no shut command on the FCIP interface at either end of the FCIP tunnel.

•CSCso49196

Symptom: During an upgrade from SAN-OS Release 3.2(3a) to Release 3.3(1a), when a switchover occurs to the Supervisor running Release 3.3(1a), Cisco SME traffic flows for hosts that are not connected locally to the switch that is getting upgraded, may get flapped for a very short time. This can also occur during a switchover to a Supervisor running Release 3.3(1a).

Workaround: None.

•CSCso31754

Symptom: IVR does not finish a domain capture which stops the export of IVR devices.

Workaround: To avoid the API errors that cause this ACL/IVR issue, enter the show system internal capability command on the standby Supervisor and look at the last entry under each module. (You can ignore the Supervisor.) If the output states online then you can do a switchover or an upgrade.

•CSCsi56167

Symptom: The response time shown in the output of a pingip-address command may not be accurate if there is an MDS MSM-8/4 in the path.

Workaround: Use the ips measure-rtt command to measure the round trip time.

•CSCsk91974

Symptom: When you issue the show tech-support sme or the show klm internal isapi_scsi command after attaching to a module, you may see this error message: cat: write error: Bad address. This issue does not affect the actual tech-support log.

Workaround: None.

•CSCsk73654

Symptom: In certain tape libraries, the tape drives are exported as LUNs. If these target ports are already a part of a Cisco SME configuration and new tape drives are added as LUNs, the new tape drives will not be discovered during a Cisco SME tape group or tape device configuration.

Workaround: Perform a rescan at the host level or a flap of the target port to allow Cisco SME to rediscover these newly added tape drives.

•CSCso50663

Symptom: The following syslog message is displayed: %SME_CPP-SLOT13-3-LOG_ERR_SME_ITL_CPP_ERR: Module:13 Host-Target IT Nexus I:0xc1f3202015180006 T:0xc5a0202000010006 vsan:3000 oid:0x117 LunID:0x0000. This message is for debugging purposes and is also displayed during the upgrade of an MSM-18/4 module. An upgrade of the MSM-18/4 module where Cisco SME is enabled, is disruptive; however, this syslog message does not indicate an issue.

Workaround: None.

•CSCsk43927

Symptom: The following Fabric Manager client components that use SSH and Telnet do not work well with NAT:

•DMM storage job creation

•Cisco SAN-OS software upgrade

•Zone activation

Workaround: None.

•CSCsm13002

Symptom: In rare cases, if a READ command issued by Cisco SME for media identification is dropped or lost, the tape is marked as a clear-text tape. Subsequently, a CHECK_CONDITION with ILI is returned when a READ is issued by the host. This can cause a backup application to mark the tape as read-only.

Workaround: Unmount and remount the tape from the backup application to resolve this issue.

•CSCsm15874

Symptom: In rare cases, when Cisco SME attempts to perform a tape device discovery of the backend tapes, a SCSI command can stall. This may cause Cisco SME to remain in the device discovery phase.

Workaround: Reload the module.

•CSCsm18303

Symptom: In certain cases with the Tape Recycle policy enabled in Cisco SME, a new key is generated when a tape is recycled and the old key is not purged.

Workaround: Manually purge the older version of the key.

•CSCsq74312

Symptom: After a 24-port 4-Gbps Fibre Channel module was replaced by a 12-port 4-Gbps Fibre Channel module on a switch with a Supervisor 2 module, the running configuration and the startup configuration were different.

Workaround: Purge the entries by inserting a new module with an equal number or more ports than are present on the module being replaced.

Related Documentation

The documentation set for the Cisco MDS 9000 Family includes the following documents. To find a document online, use the Cisco MDS SAN-OS Documentation Locator at: http://www.cisco.com/en/US/products/ps5989/products_documentation_roadmap09186a00804500c1.html. For information on IBM TotalStorage SAN Volume Controller Storage Software for the Cisco MDS 9000 Family, refer to the IBM TotalStorage Support website: http://www.ibm.com

Installation and Configuration Note

Obtaining Documentation and Submitting a Service Request

For information on obtaining documentation, submitting a service request, and gathering additional information, see the monthly What's New in Cisco Product Documentation, which also lists all new and revised Cisco technical documentation, at:

Subscribe to the What's New in Cisco Product Documentation as a Really Simple Syndication (RSS) feed and set content to be delivered directly to your desktop using a reader application. The RSS feeds are a free service and Cisco currently supports RSS version 2.0.

Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1005R)

Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.