Cisco MDS 9000 Family Release Notes for Cisco MDS SAN-OS Release 3.3(2) (OL-14116-10 C0, November 2008)

Send documentation comments to [e-mail]
49
Cisco MDS 9000 Family Release Notes for Cisco MDS SAN-OS Release 3.3(2)
OL-14116-10
Caveats
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:
switch(config)# poweroff module slot
switch# purge module slot running-config
• CSCsk87502
Symptom: If an NASB configuration in a VSAN is destroyed while a target discovery is pending,
the NASB process fails. Issue the show nasb vsan x 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.
3. The storage-based data migration job continues executing until it completes.
4. The user issues the dmm module module-id job job-id destroy command to delete the
storage-based data migration job, but the delete fails.
Workaround: Reload the SSM.