Virtual SANs (VSANs) improve storage area network (SAN) scalability, availability, and security by allowing multiple Fibre Channel SANs to share a common physical infrastructure of switches and ISLs. These benefits are derived from the separation of Fibre Channel services in each VSAN and the isolation of traffic between VSANs. Data traffic isolation between the VSANs also inherently prevents sharing of resources attached to a VSAN, such as robotic tape libraries. Using IVR, you can access resources across VSANs without compromising other VSAN benefits.
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 a single
Establishes proper interconnected routes that traverse
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.
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
The following IVR-related terms are used in the IVR
The VSAN to which an end device logs on is
the native VSAN for that end device.
The VSAN currently being configured for
Inter-VSAN Routing zone (IVR zone)
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
Inter-VSAN routing zone sets (IVR zone sets)
Inter-VSAN routing zone sets (IVR zone sets)-One or
more IVR zones make up an IVR zone set.
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.
A switch on which the IVR feature is enabled.
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
An edge VSAN for one IVR path can be a transit VSAN
for another IVR path.
A VSAN that exists along an IVR path from
the source edge VSAN of that path to the destination edge VSAN of
When the source and destination edge VSANs are
adjacent to each other, then a transit VSAN is not required between
An IVR-enabled switch that is a member
of two or more VSANs.
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
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.
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.
Fibre Channel Header Modifications
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:
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.
IVR Database Merge
A database merge refers to the combination of the configuration database and static (unlearned) entries in the active database.
Consider the following when merging two IVR fabrics:
The IVR configurations are merged even if two fabrics contain different configurations.
If dissimilar zones exist in two merged fabrics, the zone from each fabric is cloned in the distributed zone set with appropriate names.
You can configure different IVR configurations in different Cisco SAN switches.
To avoid traffic disruption, after the database merge is complete, the configuration is a combination of the configurations that were present on the two switches involved in the merge, as follows:
A combination of zones and zone sets are used to get the merged zones and zone sets. If a dissimilar zone exists in two fabrics, the dissimilar zones are cloned into the zone set with appropriate names so both zones are present.
The merged topology contains a combination of the topology entries for both fabrics.
The merge will fail if the merged database contains more topology entries than the allowed maximum.
The following total number of items across the two fabrics cannot exceed the maximum allowed in one fabric:
VSANs.VSANs with the same VSAN ID but different AFIDs are counted as two separate VSANs.
Zone members. A zone member is counted twice if it exists in two zones.
Table 1 Results of Merging Two IVR-Enabled Fabrics
IVR Fabric 1
IVR Fabric 2
Merge succeeds and NAT is enabled
Auto mode enabled
Auto mode disabled
Merge succeeds and IVR auto topology mode is enabled
Conflicting AFID database
Conflicting IVR zone set database
Merge succeeds with new zones created to resolve conflicts
Combined configuration exceeds limits (such as maximum number of zones or VSANs)
Service group 1
Service group 2
Merge succeeds with service groups combined
User-configured VSAN topology configuration with conflicts
User-configured VSAN topology configuration without conflicts
If you do not follow these conditions, the merge will fail. The next distribution will forcefully synchronize the databases and the activation states in the fabric.
Copies the running configuration to the startup configuration.
Commiting IVR Changes
If you commit the changes made to the active database, the configuration is committed to all the switches in the fabric. On a successful commit, the configuration change is applied throughout the fabric and the lock is released.
Before You Begin
Ensure you have enabled CFS distribution for IVR.
(Optional) copy running-config startup-config
Command or Action
switch# configure terminal
Enters global configuration mode.
switch(config)# ivr commit
Commits all pending IVR changes into the active IVR database.
switch# show ivr merge status
switch# show cfs merge status name ivr
switch# show logging last 100
Review the information from these show commands. Look for MERGE failures in the log output.
For failures because the merged fabric exceeded the maximum configuration limits(VSANs, IVR-enabled switches, zone members, zones, or zone sets) where you have a different versions of NX-OS running on Cisco SAN switches, upgrade to the most recent Cisco NX-OS version for all switches, or reduce the configuration below the maximum limits.
For failures because the merged fabric exceeded the maximum configuration limits(VSANs, IVR-enabled switches, zone members, zones, or zone sets) and all switches are at the same release for their platform, identify the switch that has the correct configuration and perform a CFS commit to distribute the IVR configuration
For other failures, resolve the error causing the merge failure on the switch that has the correct configuration and perform a CFS commit to distribute the IVR configuration.
After a successful CFS commit, the merge will be successful.