IVR supports the following features:

• Accesses resources across VSANs without compromising other VSAN benefits.
• Transports data traffic between specific initiators and targets on different VSANs without merging VSANs into single logical fabric.
• Establishes proper interconnected routes that travels one or more VSANs across multiple switches. IVR is not limited to VSANs present on a common switch.
• Shares valuable resources (such as tape libraries) across VSANs without compromise. Fibre Channel traffic does not flow between VSANs, nor can initiators access resources across VSANs other than the designated VSAN.
• Provides efficient business continuity or disaster recovery solutions when used in conjunction with FCIP. See the figure, Traffic Continuity Using IVR and FCIP.
• Is in compliance with Fibre Channel standards.
• Incorporates third-party switches, however, IVR-enabled VSANs may need to be configured in one of the interop modes.

Note	To configure the sample scenario shown in the following figure, follow the steps in IVR Auto Topology Mode Configuration Example.

The following IVR-related terms are used in the IVR documentation:

• Native VSAN—The VSAN to which an end device logs on is the native VSAN for that end device.
• Current VSAN—The VSAN currently being configured for IVR.
• Inter-VSAN Routing zone (IVR zone)—A set of end devices that are allowed to communicate across VSANs within their interconnected SAN fabric. This definition is based on their port world-wide names (pWWNs) and their native VSAN associations. Prior to Cisco SAN-OS Release 3.0(3), you could configure up to 2000 IVR zones and 10,000 IVR zone members on the switches in the network. As of Cisco SAN-OS Release 3.0(3), you can configure up to 8000 IVR zones and 20,000 IVR zone members on the switches in the network.
• Inter-VSAN routing zone sets (IVR zone sets)—One or more IVR zones make up an IVR zone set. You can configure up to 32 IVR zone sets on any switch in the Cisco MDS 9000 Series. Only one IVR zone set can be active at any time.
• IVR path—An IVR path is a set of switches and Inter-Switch Links (ISLs) through which a frame from an end device in one VSAN can reach another end device in some other VSAN. Multiple paths can exist between two such end devices.
• IVR-enabled switch—A switch on which the IVR feature is enabled.
• Edge VSAN—A VSAN that initiates (source edge-VSAN) or terminates (destination edge-VSAN) an IVR path. Edge VSANs may be adjacent to each other or they may be connected by one or more transit VSANs. VSANs 1, 2, and 3 (see Traffic Continuity Using IVR and FCIP), are edge VSANs.

Note	An edge VSAN for one IVR path can be a transit VSAN for another IVR path.

• Transit VSAN—A VSAN that exists along an IVR path from the source edge VSAN of that path to the destination edge VSAN of that path. VSAN 4 is a transit VSAN(see Traffic Continuity Using IVR and FCIP).

Note	When the source and destination edge VSANs are adjacent to each other, then a transit VSAN is not required between them.

• Border switch—An IVR-enabled switch that is a member of two or more VSANs. Border switches, such as the IVR-enabled switch between VSAN 1 and VSAN 4(see Traffic Continuity Using IVR and FCIP), span two or more different color-coded VSANs.
• Edge switch—A switch to which a member of an IVR zone has logged in to. Edge switches are unaware of the IVR configurations in the border switches. Edge switches do not need to be IVR-enabled.
• Autonomous Fabric Identifier (AFID)—Allows you to configure more than one VSAN in the network with the same VSAN ID and avoid downtime when configuring IVR between fabrics that contain VSANs with the same ID.
• Service group—Allows you to reduce the amount of IVR traffic to non-IVR-enabled VSANs by configuring one or more service groups that restrict the traffic to the IVR-enabled VSANs.

For information on IVR configuration limits, see Cisco MDS NX-OS Configuration Limits, Release 8.x.

IVR virtualizes the remote end devices in the native VSAN using a virtual domain. When IVR is configured to link end devices in two disparate VSANs, the IVR border switches are responsible for modifying the Fibre Channel headers for all communication between the end devices. The sections of the Fibre Channel frame headers that are modified include:

• VSAN number
• Source FCID
• Destination FCID

When a frame travels from the initiator to the target, the Fibre Channel frame header is modified such that the initiator VSAN number is changed to the target VSAN number. If IVR Network Address Translation (NAT) is enabled, then the source and destination FCIDs are also translated at the edge border switch. If IVR NAT is not enabled, then you must configure unique domain IDs for all switches involved in the IVR path.

To use IVR NAT, it must be enabled on all IVR-enabled switches in the fabric. For information on distributing the IVR configuring using CFS, see Distributing the IVR Configuration Using CFS. By default, IVR NAT and IVR configuration distributions are disabled on all switches in the Cisco MDS 9000 Family.

See About IVR NAT and IVR Auto Topology Mode for information on IVR requirements and guidelines as well as configuration information.

IVR uses a configured IVR VSAN topology to determine how to route traffic between the initiator and the target across the fabric.

IVR auto topology mode automatically builds the IVR VSAN topology and maintains the topology database when fabric reconfigurations occur. IVR auto topology mode also distributes the IVR VSAN topology to IVR-enabled switches using CFS.

Using IVR auto topology mode, you no longer need to manually update the IVR VSAN topology when reconfigurations occur in your fabric. If an IVR manual topology database exists, IVR auto topology mode initially uses that topology information. The automatic update reduces disruption in the network by gradually migrating from the user-specified topology database to the automatically-learned topology database. User-configured topology entries that are not part of the network are aged out in about three minutes. New entries that are not part of the user-configured database are added as they are discovered in the network.

When IVR auto topology mode is enabled, it starts with the previously active IVR manual topology if it exists, and then the discovery process begins. New, alternate, or better paths my be discovered. If the traffic is switched to an alternate or better path, there may be temporary traffic disruptions that are normally associated with switching paths.

Note	IVR topology in IVR auto topology mode requires Cisco MDS SAN-OS Release 2.1(1a) or later and CFS must be enabled for IVR on all switches in the fabric.

When using the IVR feature, all border switches in a fabric must be Cisco MDS switches. However, other switches in the fabric may be non-MDS switches. For example, end devices that are members of the active IVR zone set may be connected to non-MDS switches. Non-MDS switches may also be present in the transit VSAN(s) or in the edge VSANs if one of the interop modes is enabled.

For additional information on switch interoperability, refer to the Cisco Data Center Interoperability Support Matrix .

The IVR feature uses the Cisco Fabric Services (CFS) infrastructure to enable efficient configuration management and to provide a single point of configuration for the entire fabric in the VSAN. For information on CFS, refer to the Cisco MDS 9000 Series System Management Configuration Guide .

The following configurations are distributed:

• IVR zones
• IVR zone sets
• IVR VSAN topology
• IVR active topology and zone set (activating these features in one switch propagates the configuration to all other distribution-enabled switches in the fabric)
• AFID database

Note	IVR configuration distribution is disabled by default. For the feature to function correctly, you must enable it on all IVR-enabled switches in the network.

Before configuring an IVR SAN fabric to use IVR NAT and IVR auto topology mode, consider the following:

• Configure IVR only in the relevant switches.
• Enable CFS for IVR on all switches in the fabric.
• Verify that all switches in the fabric are running Cisco MDS SAN-OS Release 2.1(1a) or later.
• Acquire a mandatory Enterprise License Package or SAN-EXTENSION license package if you have Cisco MDS SAN-OS Release 2.1(1a) or later and one active IPS card for this feature. For information on licensing, refer to the Cisco MDS 9000 Series Licensing Guide .

Note	The IVR over FCIP feature is bundled with the Cisco MDS 9216i Switch and does not require the SAN extension over IP package for the fixed IP ports on the supervisor module.

Tip	If you change any FSPF link cost, ensure that the FSPF path distance (that is, the sum of the link costs on the path) of any IVR path is less than 30,000.

Note	IVR-enabled VSANs can be configured when the interop mode is enabled (any interop mode) or disabled (no interop mode).

The requirements and guidelines for using IVR NAT are listed below:

• IVR NAT port login (PLOGI) requests that are received from hosts are delayed a few seconds to perform the rewrite on the FC ID address. If the host’s PLOGI timeout value is set to a value less than five seconds, it may result in the PLOGI being unnecessarily terminated and the host being unable to access the target. We recommend that you configure the host bus adapter for a timeout of at least ten seconds (most HBAs default to a value of 10 or 20 seconds).

• IVR NAT requires Cisco MDS SAN-OS Release 2.1(1a) or later on all IVR switches in the fabric.

• IVR non-NAT mode is not supported from Cisco NX-OS Release 5.2(x) and later releases. If you have IVR non-NAT mode configured, see the Upgrading Guidelines Specific to NX-OS Release 5.2(8c) section for instructions on how to migrate to IVR NAT mode.

• IVR NAT allows you to set up IVR in a fabric without needing unique domain IDs on every switch in the IVR path. IVR NAT virtualizes the switches in other VSANs by using local VSAN for the destination IDs in the Fibre Channel headers. In some Extended Link Service message types, the destination IDs are included in the packet data. In these cases, IVR NAT replaces the actual destination ID with the virtualized destination ID. IVR NAT supports destination ID replacement in the Extended Link Service messages described in the following table.

• If you have a message that is not recognized by IVR NAT and contains the destination ID in the packet data, you cannot use IVR with NAT in your topology.

Note	Don't enable IVR NAT when IVR Topology includes FICON VSANs. If IVR NAT is enabled along with FICON VSAN, the switch throws the fcid-nat cannot be enabled if FICON enabled VSANs and topology VSANs overlap error.

To view the status of the IVR virtual domain configuration, use the show ivr virtual-fcdomain-add-status command.

switch# show ivr virtual-fcdomain-add-status
IVR virtual domains are added to fcdomain list in VSANS: 1
(As well as to VSANs in interoperability mode 2 or 3)

To clear the IVR fcdomain database, use the following command:

switch# clear ivr fcdomain database

As part of the IVR configuration, you need to configure one or more IVR zones to enable cross-VSAN communication. To achieve this result, you must specify each IVR zone as a set of (pWWN, VSAN) entries. Like zones, several IVR zone sets can be configured to belong to an IVR zone. You can define several IVR zone sets and activate only one of the defined IVR zone sets.

Note	The same IVR zone set must be activated on all of the IVR-enabled switches.

The following table identifies the key differences between IVR zones and zones.

The following table identifies the IVR zone limits per physical fabric.

Note	A zone member is counted twice if it exists in two zones. See Database Merge Guidelines.

Caution

If you want to downgrade to a release prior to Cisco SAN-OS Release 3.0(3), the number of IVR zones cannot exceed 2000 and the number of IVR zone members cannot exceed 10,000.

The following figure depicts an IVR zone consisting of four members. To allow pwwn1 to communicate with pwwn2, they must be in the same zone in VSAN 1, as well as in VSAN 2. If they are not in the same zone, then the hard-zoning ACL entries will prohibit pwwn1 from communicating with pwwn2.

A zone corresponding to each active IVR zone is automatically created in each edge VSAN specified in the active IVR zone. All pWWNs in the IVR zone are members of these zones in each VSAN.

The zones are created automatically by the IVR process when an IVR zone set is activated. They are not stored in a full zone set database and are lost when the switch reboots or when a new zone set is activated. The IVR feature monitors these events and adds the zones corresponding to the active IVR zone set configuration when a new zone set is activated. Like zone sets, IVR zone sets are also activated nondisruptively.

Note	If pwwn1 and pwwn2 are in an IVR zone in the current as well as the new IVR zone set, then activation of the new IVR zone set does not cause any traffic disruption between them.

IVR zone and IVR zone set names are restricted to 64 alphanumeric characters.

Caution

Prior to Cisco SAN-OS Release 3.0(3), you can only configure a total of 2000 IVR zones and 32 IVR zone sets on the switches in the network. As of Cisco SAN-OS Release 3.0(3), you can only configure a total of 8000 IVR zones and 32 IVR zone sets on the switches in the network. See Database Merge Guidelines .

Once the zone sets have been created and populated, you must activate the zone set. When you activate an IVR zone set, IVR automatically adds an IVR zone to the regular active zone set of each edge VSAN. If a VSAN does not have an active zone set, IVR can only activate an IVR zone set using the force option, which causes IVR to create an active zone set called “nozoneset” and adds the IVR zone to that active zone set.

Caution

If you deactivate the regular active zone set in a VSAN, the IVR zone set is also deactivated. This occurs because the IVR zone in the regular active zone set, and all IVR traffic to and from the switch, is stopped. To reactivate the IVR zone set, you must reactivate the regular zone set.

Note

If IVR and iSLB are enabled in the same fabric, at least one switch in the fabric must have both features enabled. Any zoning-related configuration or activation operation (for normal zones, IVR zones, or iSLB zones) must be performed on this switch. Otherwise, traffic might be disrupted in the fabric. If a segmented VSAN is present in an IVR topology, then the IVR zone set will not be activated.

You can also use the force command to activate IVR zone sets. The following table lists the various scenarios with and without the force command option.

Caution

Using the force command of IVR zone set activation may cause traffic disruption, even for devices that are not involved in IVR. For example, if your configuration does not have any active zone sets and the default zone policy is permit, then an IVR zone set activation will fail. However, IVR zone set activation will be successful if the force command is used. Because zones are created in the edge VSANs corresponding to each IVR zone, traffic may be disrupted in edge VSANs where the default zone policy is permit.

Verify the IVR zone and IVR zone set configurations using the show ivr zone and show ivr zoneset commands.

Displays the IVR Zone Configuration

switch# show ivr zone
zone name sample_vsan2-3
    pwwn 21:00:00:e0:8b:02:ca:4a vsan 3
    pwwn 21:00:00:20:37:c8:5c:6b vsan 2
zone name ivr_qa_z_all
    pwwn 21:00:00:e0:8b:06:d9:1d vsan 1
    pwwn 21:01:00:e0:8b:2e:80:93 vsan 4
    pwwn 10:00:00:00:c9:2d:5a:dd vsan 1
    pwwn 10:00:00:00:c9:2d:5a:de vsan 2
    pwwn 21:00:00:20:37:5b:ce:af vsan 6
    pwwn 21:00:00:20:37:39:6b:dd vsan 6
    pwwn 22:00:00:20:37:39:6b:dd vsan 3
    pwwn 22:00:00:20:37:5b:ce:af vsan 3
    pwwn 50:06:04:82:bc:01:c3:84 vsan 5

switch# show ivr zone name sample_vsan2-3
zone name sample_vsan2-3
    pwwn 21:00:00:e0:8b:02:ca:4a vsan 3
    pwwn 21:00:00:20:37:c8:5c:6b vsan 2

switch# show ivr zone name sample_vsan2-3 active
zone name sample_vsan2-3
    pwwn 21:00:00:e0:8b:02:ca:4a vsan 3
    pwwn 21:00:00:20:37:c8:5c:6b vsan 2

switch# show ivr zoneset
zoneset name ivr_qa_zs_all
  zone name ivr_qa_z_all
    pwwn 21:00:00:e0:8b:06:d9:1d vsan 1
    pwwn 21:01:00:e0:8b:2e:80:93 vsan 4
    pwwn 10:00:00:00:c9:2d:5a:dd vsan 1
    pwwn 10:00:00:00:c9:2d:5a:de vsan 2
    pwwn 21:00:00:20:37:5b:ce:af vsan 6
    pwwn 21:00:00:20:37:39:6b:dd vsan 6
    pwwn 22:00:00:20:37:39:6b:dd vsan 3
    pwwn 22:00:00:20:37:5b:ce:af vsan 3
    pwwn 50:06:04:82:bc:01:c3:84 vsan 5
zoneset name IVR_ZoneSet1
  zone name sample_vsan2-3
    pwwn 21:00:00:e0:8b:02:ca:4a vsan 3
    pwwn 21:00:00:20:37:c8:5c:6b vsan 2

switch# show ivr zoneset active
zoneset name IVR_ZoneSet1
  zone name sample_vsan2-3
    pwwn 21:00:00:e0:8b:02:ca:4a vsan 3
    pwwn 21:00:00:20:37:c8:5c:6b vsan 2

switch# show ivr zoneset name IVR_ZoneSet1
zoneset name IVR_ZoneSet1
  zone name sample_vsan2-3
    pwwn 21:00:00:e0:8b:02:ca:4a vsan 3
    pwwn 21:00:00:20:37:c8:5c:6b vsan 2

switch# show ivr zoneset brief Active
zoneset name IVR_ZoneSet1
  zone name sample_vsan2-3

switch# show ivr zoneset brief Active
zoneset name IVR_ZoneSet1
  zone name sample_vsan2-3

switch# show ivr zoneset status
Zoneset Status
_______________
    name               : IVR_ZoneSet1
    state              : activation success
    last activate time : Sat Mar 22 21:38:46 1980
    force option       : off
status per vsan:
__________________
     vsan     status
     ____     ______
       1      active
       2      active

Tip	Repeat this configuration in all border switches participating in the IVR configuration.

Note	You can use Cisco Fabric Manager to distribute IVR zone configurations to all IVR-capable switches in the interconnected VSAN network. Refer to the Cisco Fabric Manager Inter-VSAN Routing Configuration Guide .

Clearing a zone set only erases the configured zone database, not the active zone database.

To clear the IVR zone database, use the clear ivr zone database command.

switch# clear ivr zone database 

This command clears all configured IVR zone information.

Note	After issuing a clear ivr zone database command, you need to explicitly issue the copy running-config startup-config command to ensure that the running configuration is used when you next start the switch.

Use the show logging level command to view the configured logging level for the IVR feature.

switch# show logging level
Facility        Default Severity        Current Session Severity
--------        ----------------        ------------------------
...
ivr                     5                       4
...
0(emergencies)          1(alerts)       2(critical)
3(errors)               4(warnings)     5(notifications)
6(information)          7(debugging)

If a merge failure occurs, you can use the following CLI commands to display the error conditions:

• show ivr merge status
• show cfs merge status name ivr
• show logging last lines (and look for MERGE failures)

To resolve merge failures, review the failure information indicated in the show command outputs, then find the scenario in this list that relates to the failure and follow the troubleshooting instructions:

Note	After a successful CFS commit, the merge will be successful.