This section includes the following topics:

When you deploy IOA, consider these general configuration guidelines:

• The IOA flows bound to the IOA interfaces on the module undergoing an upgrade will be affected.
• Clustering infrastructure uses the management IP network connectivity to communicate with the other switches. In the case of a switchover, the management IP network connectivity should be restored quickly to preserve the cluster communication. If the management port is connected to a Layer 2 switch, spanning tree must be disabled on these ports. In a Cisco Catalyst 6500 Series switch, you can implement this disabling by configuring the spanning-tree portfast command on these ports which considers these ports as access or host ports.

For maximum scalability and optimal performance, follow these IOA configuration guidelines:

When you configure IOA, consider the following Zoning requirements:

• In certain tape backup environments, a common practice is to zone every backup server with every tape drive available to allow sharing of tape drives across all the backup servers. For small and medium tape backup environments, this may be retained when deploying IOA. For large backup environments, the scalability limit of number of flows in IOA must be considered to check if the zoning configuration can be retained. Best practice for such an environment is to create multiple tape drive pools, each with a set of tape drives and zones of only a set of backup servers to a particular tape drive pool. This practice sharing of tape drives drastically reduces the scalability requirements on IOA.
• Deploy IOA interfaces (Cisco MDS 24/10 port SAN Extension Module or Cisco MDS 9250i Switch) in the core switches in both core-edge and edge-core-edge topologies.
• When multiple core switches are interconnected across the MAN or WAN, do the following:
  • Deploy the IOA interfaces equally among the core switches for high availability.
  • Interconnect core switches in each site for optimal routing.
• Plan for Geneneration 2 and above line cards to avoid any FC-Redirect limitations.
• There is a limit of only 32 targets per switch if Generation 1 modules are used to link the ISLs connecting the IOA switch and target switches or if the host is directly connected to a Generation 1 module.
• Depending on the WAN transport used, you may have to tune the Fibre Channel extended B2B credits for the round-trip delay between the sites.

When you configure IOA, consider the following resiliency guidelines:

• Plan to have a minimum of one additional IOA service engine for each site for handling IOA service engine failures.
• Plan for E_D_TOV: Fibre Channel Error Detect Timeout Value (E_D_TOV) is used by Fibre Channel drives to detect errors if any data packet in a sequence takes longer than the specified timeout value. The default timeout value for E_D_TOV is 2 seconds. IOA has an built-in reliability protocol (LRTP) to detect and recover from ISL failures by doing the necessary retransmissions. However, you need to ensure that it recovers before the expiry of E_D_TOV. LRTP is not required if the FCP-2 sequence level error-recovery procedures are enabled end-to-end (primarily in the tape drivers) because this helps to recover from timeout issues.
• When the FCP-2 sequence level error-recovery procedure is not enabled, you must tune certain timers in order to protect the site from ISL failures.
  • Reduce the LRTP retransmit value from the default value of 2.5 seconds to 1.5 seconds. For more information, see the Setting the Tunable Parameters .
  • If the ISLs are FCIP links, the FCIP links must be tuned in order to detect link flaps quickly. By default, FCIP links detect a link failure in 6 seconds based on TCP maximum retransmissions. To reduce the time taken to detect failures, you need to set the maximum retransmission attempts in the FCIP profile from the default value of 4 to 1.

Caution

Modifying the default setting to a lower value results in quick link failure detections. You must make sure that this is appropriate for your deployment. We recommend that you modify the default setting only for those applications which are sensitive to E_D_TOV values. For other applications, the default configuration is sufficient.

When you configure IOA, consider the following guidelines and limitations:

• Starting from Cisco MDS NX-OS Release 6.2(1), IOA with IVR is not supported. Before configuring IOA, disable IVR support for Fibre Channel Redirect (FCR) using the no fc-redirect ivr-support enable command in global configuration mode.

• Only 512 flows are supported when IOA and IVR co-exists.

• IOA decides the master based on a master election algorithm. If you have multiple switches in the IOA cluster, you must add all the switches in the site that you manage through the cluster before adding switches from the remote site.

• IOA clustering framework uses IP connectivity for its internal operation. If an IOA cluster becomes nonoperational due to IP connectivity, IOA flows are brought down to offline state. In this state, the hosts may not be able to see the targets. To accelerate the IOA flows, the IOA cluster must be operational and there must be at least one IOA switch in each site that is online within this IOA cluster.

• If there are multiple IOA clusters in a region, a target can be part of the IOA configuration in only one cluster. To change the target to a different cluster, the configuration in the first cluster must be deleted before creating the configuration in the second cluster.

• IOA licenses are not tied to a specific IOA service engine. IOA licenses are checked out when any of the following event occurs:

  • An IOA interface is configured.

  • A line card that contains the IOA interface comes online. There are no links between an IOA license and a IOA service engine. If a line card goes offline, another IOA interface can be brought up using the same IOA license. In such cases, when the line card comes back online, the IOA interface is automatically brought down with status displaying No License. You need to install licenses corresponding to the number of IOA interfaces configured regardless of the status of the line card.

• If IOA flows are configured and a copy running to startup is not performed, FCR rules are removed automatically during a reload for all flows in all VSANs except VSAN 1. VSAN 1 is a default VSAN that is always persistent even without a copy running to startup and so FCR rules are preserved for this VSAN. To recover from this, you can enter the clear fc-redirect decommission-switch command before rebooting the switch to purge the FCR configurations in VSAN 1. Alternately, you can clean up the entire IOA flow configuration before rebooting the switch.

• If an MDS switch is connected through an ISL using a DS-X9248-96K9 line card module and the targets are connected to the MDS switch, then this MDS switch can connect to a maximum of 160 targets. This is because the maximum number of Extended Link Service (ELS) entries on the DS-X9248-96K9 line card module is 320 entries. For example, in an IOA configuration that has 5 flows (1 host: 1 target) you can have 10 ELS entries on a module with ISL and in a IOA configuration that has 10 flows (2 hosts: 1 target), you only can have 10 ELS entries. This is because ELS entries depends on the number of targets. The workaround for this situation is to implement an allowed VSAN on ISL. For example, if ISL-1 is connected to module 9 and is limited to VSAN 2000, then all the ELS entries specific to VSAN 2000 will be on module 9. If ISL-2 is connected to module 2 and is limited to VSAN-3000, then all the ELS entries specific to targets of VSAN-3000 will be on module 2.

• When IOA is used to accelerate the EMC SRDF family of products, switching between SRDF adaptive Copy and SRDF/A can cause your RDF pairs to go into TransIdle state. If your SRDF deployment requires switching between these two modes, we recommend that you use the FCIP write acceleration feature instead of IOA.

• IOA flow takes a few seconds to become active upon certain triggers such as host or target port flaps. Port login (PLOGI) from the hosts are buffered until the IOA flow becomes active. Once the IOA flow becomes active, it sends a Registered State Change Notification (RSCN) to request the host to PLOGI again. Certain target arrays perform a few back-to-back PLOGIs before the flow becomes active and when determining that a failure requires a manual corrective action. To prevent this, IOA flows that have been configured for write acceleration are set up with a default timeout of 10 seconds after which the flow becomes unaccelerated. This is useful specifically in cases where IOA is unable to take over the flow before the timeout. For example, the line card reloads where no other IOA interface is available to handle the flow. In certain target arrays, the 10-second timeout is not sufficient and these arrays may require manual recovery using the storage management interfaces. One example of this target array is HDS AMS.

  The workaround for this situation is to set the timeout to 5 seconds using the CLI command tune wa-fcr-rule-timeout 5 under the IOA cluster configuration submode. This configuration is cluster-wide persistent across reboots.

• If the MDS 9250i Switch is part of the cluster as an IOA node, then the maximum number of flows supported is 203 in one VSAN. If multiple VSAN are used, the maximum number of flows is 256.
• If the MDS 9250i Switch is connected through an ISL and the targets are connected to that ISL, then the MDS switch can connect to a maximum of 203 targets. This is because the maximum number of ELS entries on a MDS9250i switch is 406 entries. The 203 targets involved in IOA includes all VSANs. The 203 target limit exists if no IVR entries are programmed. In case of IVR, the corresponding number of targets will reduce accordingly depending upon the availability of the ELS region.
• ISSU on the Cisco MDS9250i with IOA disk flows greater than 180 flows is not supported.
• In a 4-node IOA cluster of the Cisco MDS 9250i Switch having 1020 flows with a 3:1 ratio and hosts or targets being distributed equally, you may get the following message:

  
  %ACLTCAM-2-ACL_TCAM_NO_TCAM_LEFT: ACLTCAM resource exhausted for interface on fcx/y.

  The above message indicates that the ACLTCAM usage for Region2 Security on the Cisco MDS 9250i Switch or the Cisco MDS 9148S Switch is full. Due to this, a few IOA flows may be offline. This is the expected behavior. In such a case, ensure that the number of flows that get bound to the IOA node on the Cisco MDS 9250i Switch is not more than 203.

  If either the hosts or the targets that are participating in IOA are connected to Cisco MDS 9148S Switch, then the maximum number of hosts or targets you can have is 203.

  Note	To view the ACLTCAM usage on the Cisco MDS 9250i Switch or the Cisco MDS 9148S Switch, use the show system internal acltcam-soc tcam-usage command.

• If FCIP is configured on a Cisco MDS 9700 Series switch and IOA VSAN is a part of that FCIP tunnel, then the targets participating in IOA cannot be locally present on that switch.

• When an IOA engine is reset, traffic in flows accelerated by it will revert to unaccelerated exchanges. This occurs during normal switch operations, namely—ISSU, ISSD, or reload of a module or switch hosting the IOA engine.

• Compression between Cisco MDS 24/10 port SAN Extension Module and Cisco MDS 9250i Switch works only when the switch is running in Cisco MDS NX-OS Release 8.2(1).

• From Cisco MDS NX-OS Release 8.2(1), there is no interoperability between Cisco MDS 24/10 port SAN Extension Module and Cisco MDS 18/4-Port Multiservice Module (MSM).

• From Cisco MDS NX-OS Release 8.2(1), there are only two IOA interfaces on a single Cisco MDS 24/10 port SAN Extension Module.

• From Cisco MDS NX-OS Release 8.2(1), FCIP and IOA together are not supported on a single Cisco MDS 24/10 port SAN Extension Module.

See the Cisco MDS NX-OS Configuration Limits document for information on the configuration limits for IOA.