Cisco MDS 9000 Services-Oriented SANs

Cisco I/O Accelerator Deployment Guide

  • Viewing Options

  • PDF (820.0 KB)
  • Feedback


This document provides design and configuration guidance for deploying the Cisco ® MDS 9000 Family I/O Accelerator (IOA) feature, which significantly improves the performance of the SAN Extension solution to meet business continuity and disaster recovery requirements. Cisco IOA is a transport- and speed-agnostic traffic acceleration service capable of mitigating the effects of distance (and hence latency) on application throughput, thereby bringing flexibility to the choice of the data center location. This document focuses on deployment of disk-replication and tape-backup solutions using Cisco IOA, which are the most common applications for a SAN Extension solution.

Business Continuity and Disaster Recovery Requirements

A SAN Extension solution for business continuity and disaster recovery requires features and capabilities that provide flexibility and robustness to the deployment. Traffic acceleration and optimization services are needed to help to build a highly available and scalable business continuity and disaster recovery solution. This section discusses each of these requirements in detail and describes the way that Cisco IOA helps address these requirements.

Flexibility in Selecting the Data Center Location

An ideal business continuity and disaster recovery plan mandates the deployment of multiple data centers located at optimal distances and locations to protect against regional power failures or disasters, yet close enough for data replication without affecting the application performance. In many cases, the primary data center replicates data to a relatively nearby secondary data center over a metropolitan area network (MAN), and the secondary site in turn backs up the data to a more distant disaster recovery site across a WAN. This approach provides a good balance of recovery point objective (RPO) and recovery time objective (RTO) values for all levels of outage, but depending on the location, such a model can be costly. The challenge is to optimize the cost by finding the right data center locations for business continuity and disaster recovery. The main bottleneck for replication and backup between the data centers is the distance between them. Data center interconnect (DCI) distance adds to the latency of the link.
By reducing the latency of the I/O exchanges between the replication node and the secondary storage location, Cisco IOA extends distances for replication. This extension provides flexibility in selecting the locations while reducing the effect on application performance. The actual effective distance depends on the application requirements and the infrastructure.

Reduced Tape Backup Windows

Electronic data vaults using virtual or physical tape backup applications have become an integral part of an enterprise's business continuity and disaster recovery plan. However, uninterrupted and timely completion of the backup jobs is critical to meet stringent service-level agreements (SLAs), which include ever-smaller backup windows.
Cisco IOA accelerates tape read and write I/O between the backup applications and virtual or physical tape libraries, which not only reduces the backup windows but also enables remote tape vaulting over extended distances without degrading application performance. Remote tape vaulting gives customers the flexibility to locate their tape backup data centers remotely and to back up and restore data in real time without having to manually ship tapes to remote locations.

Highly Resilient and Scalable Infrastructure

Traffic acceleration improves the performance of replication and tape-backup deployments. However, the infrastructure needs to be highly resilient. Any failure can lead to aborted replication and backup operations, which generally then requires initial synchronization of the storage solution and restart of backup applications. This process can be very costly and detrimental to businesses.
Cisco IOA delivers acceleration as a service with high availability and scalability, including the following unique capabilities and features:

• Cisco IOA supports DCI multipath connectivity in the form of PortChannels and equal-cost multiple path (ECMP) to enhance link availability of the DCI.

• Cisco IOA uses the Lightweight Reliability Transport Protocol (LRTP), developed by Cisco, to provide resiliency to protect against Inter-Switch Link (ISL) failures, thereby protecting the application against planned and unplanned MAN and WAN ISL failures.

• Engine clustering protects against acceleration and compression engine failures by reassigning flows on the failed engines to the other engines.

• The multipath and clustering support makes Cisco IOA scalable by providing the flexibility to dynamically increase DCI bandwidth and acceleration capacity.

Flexible Choice of DCI Transport

Native Fibre Channel or Fibre Channel over IP (FCIP) can be used as a transport for the DCI. The choice of transport type is typically determined by several factors such as availability of certain transport, bandwidth requirements, and cost. Fibre Channel transport is generally expensive compared to IP. Distance requirements need to be considered as well.
As shown in Figure 1, FCIP has a longer reach than Fibre Channel, and it a clear choice for the distances ranges in which it excels. However, extended buffer-to-buffer (B2B) credits increase the native Fibre Channel range to up to 4000 km for a 2-Gbps transport. This extension is important given that performance of native Fibre Channel has lower latency and less variation in latency. If the availability and cost factors are overcome, Fibre Channel is the preferred option.

Figure 1. Distance Ranges for Fibre Channel and FCIP

Application acceleration is an important part of the SAN Extension solution. The current solutions on the market are tied to the transport. However, Cisco IOA is independent of transport, so choice of transport does not depend on the SAN Extension technology but rather on the other concerns that affect the business directly.

IOA Feature Overview

Cisco IOA provides a unified acceleration and compression service for SAN applications such as disk-replication and tape-backup solutions in a highly scalable and resilient manner. It is transport and speed agnostic and unifies both replication and backup infrastructure on one management interface. The same engine can perform both write and tape acceleration. Cisco IOA also enables engine clustering. With these features, Cisco IOA simplifies deployment and management of the SAN Extension infrastructure (Figure 2).

Figure 2. Unified and Transport-Agnostic Cisco IOA Architecture

Transport- and Speed-Agnostic Architecture

A main differentiator of Cisco IOA is that it is transport agnostic, so it can work with Fibre Channel and FCIP today and with Fibre Channel over Ethernet (FCoE) in future. This capability provides flexibility both in the choice of transport and the location of the disaster recovery sites. Cisco IOA also works with any transport speed: 2-, 4-, 8-, and 16-Gbps (future) Fibre Channel and Gigabit Ethernet and 10 Gigabit Ethernet (FCoE). These two differentiators help protect customers' investments in the SAN Extension solution.

Traffic Compression

Cisco IOA supports compression and can deliver compression ratios of up to 4:1 independent of the transport. Hence, it can compress traffic over Fibre Channel and FCIP transports. Note that the actual compression ratio depends on a variety of factors, including the data type.

Traffic Acceleration as a Service

Because of architectural and implementation limitations, traffic acceleration services have been dependent on transport and topology. However, the Cisco IOA transport- and topology-agnostic architecture enables Cisco IOA to be deployed anywhere in the SAN without consideration of the location of the application or the data. Cisco IOA uses Fibre Channel Redirect (FC-Redirect) infrastructure to direct the flows that need acceleration to its engines.
FC-Redirect is a generic flow-redirection technology that enables redirection of a flow to a specific service engine in the fabric to provide intelligent services such as Cisco IOA, Storage Media Encryption (SME), and Data Mobility Manager (DMM). The end devices that need the service must connect to a switch that supports FC-Redirect for the flows to be redirected to the correct service engine. FC-Redirect switches use Cisco Fabric Services to remain synchronized with peer switches.

Engine Clustering

By bringing multiple engines together as one logical group, or engine cluster, Cisco IOA provides a single point of management, automatic load balancing, and resiliency with automatic engine failover.

High Availability

Cisco IOA supports PortChannels and ECMP, engine clustering, and LRTP to provide highly resilient acceleration and compression service for replication and tape-backup deployments.

PortChannels and ECMP

Figure 3. Cisco IOA Supports PortChannels and ECMP

Cisco IOA supports PortChannels and ECMP for the DCI links, enhancing the availability of the deployed solution (Figure 3). The engine clustering also significantly increases availability of the infrastructure by adding engine resiliency.

Engine Clusters

Each cluster has more than one engine. If an engine fails, the flow on that engine is automatically reassigned and load-balanced to other available engines in that cluster. This process eliminates the need for operator intervention at the SAN level to restart failed applications.


Cisco IOA uses LRTP, which is a Cisco innovation for Fibre Channel that provides reliability and in-order delivery guarantees for Cisco IOA flows. It brings TCP-like reliability and retransmission capabilities. LRTP recovers from loss of packets resulting from ISL failures and from reordered packets due to natural delay variances over the various ISLs in PortChannels and ECMP. End applications such as tape backup and remote replication are unaware of transient loss of packets due to ISL failures. Note that the objective of LRTP is it is not to solve persistent drops in a Fibre Channel network the way that TCP does for IP networks, but rather to handle instances of out-of-order frames and lost frame retransmissions.

Load Balancing

Cisco IOA overlays an outer Fibre Channel header on the packets transmitted between the two Cisco IOA service engines. The exchange ID (OX_ID) values are controlled to efficiently use all the available paths as long as source ID (S_ID), destination ID (D_ID), and OX_ID load balancing is enabled in the fabric.


Cisco IOA engine capacity can be scaled up by adding more engines without the need for fabric reconfiguration and rewiring. Likewise, DCI bandwidth can be increased dynamically by adding more links to the existing PortChannels between the data centers.

Supported Hardware

Cisco IOA can be hosted as engines on the Cisco MDS 9000 18/4-Port Multiservice Module (MSM), MDS 9222i Multiservice Modular Switch (MMS) fixed module, and MDS 9000 16-Port Storage Services Node (SSN-16) module. While the Cisco MDS 9000 18/4-Port MSM and MDS 9222i MMS fixed module can host one Cisco IOA engine, the Cisco MDS 9000 16-Port SSN can host up to four engines.


Cisco IOA can be managed by using both a command-line interface (CLI) and the Cisco Fabric Manager like any other Cisco MDS 9000 Family feature. The Cisco Fabric Manager provides the Cisco IOA Wizard, which simplifies the provisioning of Cisco IOA throughout the fabric to just a few steps while providing a fabric-level view of the Cisco IOA configuration. In addition, the CLI provides the Cisco IOA Flow Setup Wizard to help with automatic batch provisioning of flows.

Traffic Engineering

Figure 4. Cisco MDS 9000 Family QoS Feature Can Be Used to Classify Traffic Groups

Cisco MDS 9000 Family switches provide flexible traffic engineering features that can be used to help ensure a specific quality of service (QoS) to certain accelerated traffic flows. For example, as illustrated in Figure 4, replication traffic can be deployed in a VSAN with higher QoS than for tape-backup traffic. More granular QoS configuration is possible as well. For example, within the replication VSAN, certain flows can be given higher priority than the others.

Cisco IOA Terminology

Figure 5. Cisco IOA Engine, Site, and Switch

Cisco IOA Engine

The Cisco IOA engine is an application engine that performs acceleration on the supported hardware modules.

• It is the Cisco IOA interface as specified in the configuration model.

• A Cisco IOA switch contains one or more Cisco IOA engines. Each switch belongs to one Cisco IOA site, as shown in the Figure 5, and hence an engine can be associated with only one Cisco IOA site.

• Each engine needs a separate Cisco IOA license.

• Each Cisco MDS 9000 18/4-Port MSM and MDS 9222i MMS fixed module can host one Cisco IOA engine, and the Cisco MDS 9000 SSN-16 module can host up to four engines.

Cisco IOA Cluster

Figure 6. Cisco IOA Engine Cluster

A cluster is a set of Cisco IOA engines in a pair of Cisco IOA sites that operate as one group to provide Cisco IOA service while isolating the control plane from other clusters. It has following characteristics:
A cluster can span only two sites.

• An Cisco IOA site can share multiple clusters (for example, a central site with all the tapes as shown in Figure 6).

• A Cisco IOA switch can be in multiple clusters.

• A Cisco IOA engine can be bound to only one cluster.

Cisco IOA Flows

Figure 7. Cisco IOA Flows and Flow Groups

A Cisco IOA flow is an initiator-target-VSAN tuple that needs traffic acceleration (Figure 7).

• A flow is always accelerated within a Cisco IOA cluster. Each flow is identified by {initiator PWWN, target PWWN, VSAN ID}

• Each flow can perform either write acceleration or tape acceleration, or both.

• A set of Cisco IOA flows are grouped into a Cisco IOA flow group. This classification be performed for a given purpose: for example, you can create a tape backup flow group, EMC Symmetrix Remote Data Facility (SRDF) flow group, and IBM Tivoli Storage Manager (TSM) flow group.

• Every flow needs to be in a flow group.

Deployment Considerations

Location of Engines

Although a Cisco IOA engine can be placed anywhere in the SAN because of its service-oriented architecture (SOA), it is suggested that it be placed in SAN core (Figure 8). Doing so helps ensure the following:

• Simple bandwidth capacity planning: Planning is based only on intersite bandwidth, not on all the ISLs leading to the Cisco IOA engine.

• Optimal routing: Flows always traverse core switches to reach the remote site.

• Best consolidation and scalability: All the flows typically traverse the cores, and all the acceleration can be consolidated at the core. If not consolidated at the core, more Cisco IOA engines may be required, which increases management overhead and the costs associated with the solution.

Figure 8. The Core Is the Best Place for Cisco IOA Engines

The following special considerations need to be addressed in multiple-core deployments (Figure 9):

• The core switches are interconnected to provide the best possible redundancy.

• The ISLs connecting the cores should have at least the same capacity as the aggregate MAN and WAN link connecting the two sites to make sure that the ISLs can carry the traffic in the case of a Cisco IOA engine failure.

Figure 9. Cisco IOA in a Multiple-Core Deployment

Each Cisco IOA engine provides 10 Gbps 1 of application acceleration throughput. However, both latency between the data centers and application I/O sizes needs to be considered.

Number of Cisco IOA Engines

At least one Cisco IOA engine per site is required. Beyond that, a number of factors together determine the number of engines needed:

• Required application throughput: Each Cisco IOA engine provides 10 Gbps2 of application throughput. It is important to account for both latency between the data centers and application I/O sizes since the engine performance also depends on these factors.

• Availability requirements: More engines are needed if availability requirements mandate the use of clustering to protect against engine failures.

• Number of interconnected sites: Each site pair needs at least one engine per site. Each additional site pair needs at least two engines. Also, the recommended approach is to use the same number of engines at both sites in the cluster.

Note that the same number of Cisco IOA engines is also needed for redundant fabrics.

Number of Cisco IOA Clusters

Each site pair needs a separate cluster. At least one cluster per site pair is needed. Depending on the size and management requirements, more clusters per site pair can be deployed. A separate cluster is needed for each fabric because clusters do not span fabrics.
The Cisco IOA clustering framework uses IP connectivity for its internal operation, helping ensure IP connectivity among Cisco IOA switches.
If multiple sites replicate or back up to one central site as illustrated in Figure 10, each site pair needs a separate cluster. This approach enables the use of separate administrative domains, thus simplifying Cisco IOA flow management.

Figure 10. Multiple Clusters Are Needed If Multiple Sites Replicate or Back Up to a Central Location


The Cisco MDS 9000 18/4-Port MSM, MDS 9222i MMS, and MDS 9000 SSN-16 3 can host Cisco IOA engines. If more than one Cisco IOA engine is required per site, the Cisco MDS 9000 SSN-16 provides the consolidated platform for hosting multiple Cisco IOA engines. This platform also reduces the number of slots required on the Cisco MDS 9000 Family switch chassis.
If multiple sites replicate or back up to a central location (as shown earlier in Figure 10), the Cisco MDS 9000 SSN-16 can provide the multiple engines required at the central location.


Each Cisco IOA engine needs a separate Cisco IOA license. For Cisco MDS 9000 18/4-Port MSM and MDS 9222i MMS, one license is required. To run four Cisco IOA engines, four Cisco IOA licenses are required.


Both Cisco IOA and FCIP are capable of performing compression. However, Cisco IOA compression throughput per engine is about 10 percent more than with the FCIP compression engine. In addition to throughput, other factors need to be considered. Cisco IOA provides an overall superior solution specific to compression for the following reasons:

• Better high availability: Although FCIP uses TCP retransmissions, link failures are not transparent to the applications, and applications hence may experience disruptions. However, the Cisco IOA LRTP protects against link failure and reduces the effect on the applications.

• Flexible scalability: Cisco IOA compression engine capacity can be scaled up by adding more engines without the need for fabric reconfiguration or rewiring. FCIP engines need Gigabit Ethernet port connectivity and wiring to the fabric. In addition, if Cisco FCIP Write Acceleration (FCIP-WA) is being used, DCI bandwidth is limited to 16 Gbps (16 Gigabit Ethernet ports in a PortChannel) because multiple paths are not supported for FCIP-WA. However, no such limit exists for Cisco IOA.

The compression decision also depends on the total number of FCIP and Cisco IOA engines (the Cisco MDS 9000 18/4-Port MSM can have one FCIP or Cisco IOA engine, and the Cisco MDS 9000 SSN-16 can have four FCIP or Cisco IOA engines) and hence the aggregate compression bandwidth. It is suggested that compression be enabled on the engine type with higher aggregate throughput. For example, if a system is using two FCIP engines and one Cisco IOA engine, FCIP provides higher compression throughput.

Traffic Engineering

If traffic needs to be classified, QoS features on the Cisco MDS 9000 Family switches can be uses to prioritize certain flows over others. As shown in Figure 4, flows can be placed in different VSANs with different QoS levels. Alternatively, source- and destination-based or flow-based priority controls can be used to achieve more granular QoS for replication and backup deployments using Cisco IOA.

FC-Redirect Requirement

FC-Redirect is a fundamental technology needed for Cisco IOA. It has evolved over the years, and FC-Redirect Version 2 (FC-Redirect v2) has been introduced to increase scalability. Hence, the following considerations must be addressed:

• The targets must be connected to a FC-Redirect-capable switch running Cisco MDS 9000 NX-OS Software Release 4.2(1) or later.

• The hosts must be connected to a FC-Redirect-capable switch running Cisco MDS SAN-OS Software Release 3.3(1c) or later.

• Up to 32 targets per Cisco IOA engine can be handled with FC-Redirect.

• With FC-Redirect v2, up to 128 hosts per target are supported. If you do not enable FC-Redirect v2, support is limited to 16 hosts per target.

• Advanced zoning capabilities such as QoS, logical unit number (LUN) zoning, and read-only LUNs must not be used for FC-Redirect hosts and targets.

• Scalability of FC-Redirect depends on the number of switches in the fabric since it uses Cisco Fabric Services to synchronize with other switches in the fabric. You should limit the number of switches to 34. If more than 34 switches are needed, Cisco Fabric Services regions should be used. Cisco Fabric Services regions provide a way to segregate the switch to limit the scope of the synchronization domain. Refer to the Cisco I/O Accelerator Configuration Guide for more information about this topic. One approach is to create a CFS region for all the switches participating in Cisco IOA as shown in Figure 11.

Figure 11. Creating a Separate Cisco Fabric Services Region for Switches Involved in Cisco IOA to Address FC-Redirect Scalability Needs

Resiliency Tuning Considerations

Fibre Channel Protocol 2 Sequence-Level Error Recovery

Fibre Channel Protocol 2 (FCP-2) sequence-level error recovery can be enabled on the devices (tapes and storage arrays) across the system to help recover from timeout scenarios. If this feature cannot be enabled, LRTP can address this problem.

LRTP and Error Detect Timeout Value

For LRTP to detect and recover from ISL failures, the LRTP retransmission time must be less than the error detect timeout value (E_D_TOV). You should reduce this value from the default of 2.5 seconds to 1.5 seconds.

FCIP Link Quick Flap Detection

By default, FCIP links detect a link failure in 6 seconds based on the default TCP maximum retransmission value of 4. Reduce this value to 1 in the FCIP profile to speed up flap detection.

Sample Deployments

Tape Backup

Tape backup typically requires high bandwidth between the data centers. PortChannels or multiple paths can scale the DCI bandwidth. In the case of FCIP, multiple paths may be needed depending on the number of physical links available between the sites. In this case, an Ethernet switch may be needed, depending the requirements of the deployment. Figure 12 shows a sample deployment.

Figure 12. Sample Tape Backup Deployment

Storage Array Replication

A replication deployment is typically guided by application performance requirements, especially the I/O latency seen at the application. Figure 13 shows a sample deployment.

Figure 13. Sample Storage Array-Based Replication

Migration Guidelines

As previously mentioned, the other acceleration solutions currently available have limitations and restrictions that increase the complexity of deployment and management. Migration from such solutions simplifies deployment and management and enhances the resiliency of business continuity and disaster recovery solutions. This section describes some of the main differences between the existing solutions and Cisco IOA and lays out the migration path from other solutions to Cisco IOA. Note that in addition to the migration guidelines presented here, all the considerations discussed elsewhere in this document may apply as well.

Migrating from FCIP to Fibre Channel

As discussed earlier, Fibre Channel has several advantages over FCIP, and hence migration to Fibre Channel may provide good results. The actual migration details depend on the current FCIP setup, but the following generic guidelines provide an overview.

• The correct number of B2B credits need to be provisioned on the Fibre Channel SAN switches for the links connecting the data centers, according to the distance requirements. The extended B2B credits feature on the Cisco MDS 9000 Family switches may be needed to acquire more B2B credits for the given distance.

• Cisco IOA can be hosted on the current Cisco FCIP engines (Cisco MDS 9000 18/4-Port MSM and MDS 9222i MMS) if needed. Depending on size requirements, more Cisco IOA engines may be needed.

Migrating from Cisco Fibre Channel Write Acceleration

Cisco Fibre Channel Write Acceleration (FC-WA) is supported on the Cisco MDS 9000 Storage Services Modules (SSMs) deployed on Cisco MDS 9500 Series directors and MDS 9222i MMS switches. Cisco IOA is supported on the Cisco MDS 9000 18/4-Port MSM and on Cisco MDS 9000 16-Port SSN modules on Cisco 9500 Series directors and MDS 9222i MMS switches.

• The Cisco MDS 9000 SSM has to be migrated to either the Cisco MDS 9000 18/4-Port MSM or MDS 9000 16-Port SSN platform.

• The throughput per Cisco MDS 9000 18/4-Port MSM engine is at least twice that of the Cisco MDS 9000 SSM. Hence, fewer MSMs may be required.

• With Cisco IOA, compression can be enabled to reduce the DCI bandwidth requirements.

Migrating from Cisco FCIP Write Acceleration

FCIP-WA is supported on Cisco MDS 9000 18/4-Port MSM modules and MDS 9222i MMS switches, and so is Cisco IOA.

• Disable FCIP-WA on all the FCIP engines between the sites.

• Set up multiple paths between the sites, if needed.

• New engines may be required depending on the size requirements and whether compression was enabled on the FCIP engines. Refer to the "Deployment Considerations" section for more information.

• If compression is needed in the new deployment, refer to the "Compression" section for guidelines on deciding between FCIP compression and Cisco IOA compression.

Migrating from Cisco FCIP Tape Acceleration

Cisco FCIP-TA) is supported on Cisco MDS 9000 18/4-Port MSM modules and MDS 9222i MMS switches, and so is Cisco IOA.

• Disable FCIP-TA on all the FCIP engines between the sites.

• Set up multiple paths between the sites in addition to PortChannels, if needed. This is possible since IOA TA supports port channels.

• New engines may be required depending on the size requirements and whether compression was enabled on the FCIP engines. Refer to the "Deployment Considerations" section for more information.

• If compression is needed in the new deployment, refer to the "Compression" section for guidelines on deciding between FCIP compression and Cisco IOA compression.

Migrating from Brocade Fibre Channel Fast Write

Brocade Fibre Channel Fast Write is deployed with Brocade 7500 Extension Switches or FR4-18i Director Blades on both locations. Here are some of the points to consider when migrating from Fibre Channel Fast Write:

• The initiator and targets (storage arrays) need to be connected to the Fibre Channel Fast Write-enabled switches or the blades directly. No such topological restrictions exist for Cisco IOA, and hence Cisco IOA provides an opportunity to simplify the deployment topology.

• To enable Fibre Channel Fast Write, special zones must be created. Cisco IOA uses flows to identify the flows to be accelerated, and hence Cisco IOA does not need any special zones.

• Fibre Channel Fast Write does not support multiple paths between two locations. No such topological restriction exists for Cisco IOA, and hence multiple paths can be added between data centers to increase the resiliency of the DCIs.

• Fibre Channel Fast Write does not support Fibre Channel compression. Cisco IOA supports Fibre Channel compression, which helps mitigate bandwidth constraints. Note that compression can be configured on a per-flow basis. To optimize the use of the infrastructure, especially the DCI, compression should be enabled.

• Brocade Fibre Channel Fast Write is restricted to 4 port in 8-port port groups, essentially decreasing the port density by half. No such limitation exists for Cisco IOA.

Migrating from Brocade FCIP Fast Write and Tape Pipelining

Brocade FCIP Fast Write and Tape Pipelining are deployed either with Brocade 7500 Extension Switches or FR4-18i Director Blades.

• The Cisco PortChannel and Brocade ISL Trunking features create logical bundles from more than one physical interface to scale up the DCI bandwidth and increase resiliency. Brocade FCIP Fast Write and Tape Pipelining do not support this feature on Brocade 7500 Extension Switches and FR4-18i Director Blades. Cisco IOA supports the PortChannel feature and hence overcomes the topological limitations that restrict Brocade FCIP Fast Write and Tape Pipelining.

• Brocade FCIP Fast Write and Tape Pipelining do not support multiple equal-cost paths. In addition, Brocade FCIP Tape Pipelining does not support multiple unequal-cost paths. Cisco IOA does not have such a limitation and hence offers more scalability and flexibility for SAN Extension design.

Figure 14 shows a sample migration.

Figure 14. Migration from SAN Extension Solution with Brocade to Cisco IOA

Deploying Cisco IOA in a Brocade SAN

If a complete migration is not feasible, the superior capabilities of Cisco IOA can be exploited in a Brocade VSAN. Cisco MDS 9000 Family switches can connect to a Brocade SAN using special interoperability modes. Cisco IOA can be deployed using Cisco MDS 9000 Family Inter-VSAN Routing (IVR) as illustrated in Figure 15. Interop Mode 3 is the suggested interoperability mode.

Figure 15. Using Cisco IVR and Interop Mode to Deploy Cisco IOA Between Two Brocade SANs

For More Information

• Cisco I/O Accelerator:

• Cisco I/O Accelerator Configuration Guide:

1Data measured for 10-ms round-trip delay and 64-KB application I/O size.
2Data measured for 10-ms round-trip delay and 64-KB application I/O size.
3The engines are hosted on either a Cisco MDS 9500 Series Multilayer Director or MDS 9222i MMS. Note that the Cisco MDS 9222i MMS has an MSM engine on the supervisor module.