Table Of Contents

Interoperability with Inter-VSAN Routing

Setting Up IVR with Interop Mode

Interoperability with Inter-VSAN Routing

---

With the introduction of Inter-VSAN routing (IVR) in Cisco MDS SAN-OS Release 1.3(2a), it became possible to have a device in a native (or interop mode 1) VSAN communicate with another device within a native (interop mode 1) VSAN. Cisco MDS SAN-OS Release 1.3(4a) allows a device in any mode VSAN to communicate with a device in another VSAN of any mode.

This ability allows the MDS 9000 switch to consolidate multiple physical fabrics of different modes into a single physical fabric separated by VSANs, while leveraging IVR to provide the necessary connectivity between the VSANs on a per device basis. IVR provides additional benefits, including the ability to connect a core PID 0 Brocade switch to a core PID 1 Brocade switch. Normally, an outage would be required to change the core PID of one of the switches. IVR allows the MDS 9000 switch to act as a conduit between two different legacy switch interop modes. Third-party switches are allowed to be members of an IVR transit VSAN.

Topologies such as the one shown in Figure 11-1 are now possible.

Figure 11-1 Coexisting with Third Party Switches

In Figure 11-1, IVR would enable Host A (which is in VSAN 40 on a McData 6140) to access the storage attached to the Brocade 3800 (Disk A). Prior to MDS SAN-OS Release 1.3(4a), an outage would be required on both the McData director and the Brocade 3800 to configure them for a common interop mode. Host C, residing on a McData 6140, can also access devices on any other VSAN.

Setting Up IVR with Interop Mode

To set up IVR with interop mode VSANs, follow these steps:

---

Step 1 Establish ISL connectivity between the MDS 9000 switch and the third-party switch. VSANs, ISLs, and third-party switches should be configured as specified in the appropriate sections of this document.

Step 2 Enable RDI mode for IVR on the interop mode VSANs using the command: ivr virtual-fcdomain-add <VSAN range>.

Step 3 Configure IVR topologies, zones, and zone sets on the IVR-enabled MDS 9000 switch as specified in the Cisco MDS 9000 Family CLI Configuration Guide.

---

---

Note When third party switches are involved in an IVR configuration, use the ivr virtual-fcdomain-add command to enable RDI mode, as third party switches do not often query the remote name server unless it is present in the domain list. Issuing this command causes all virtual domains to appear in the domain list. This command should only be issued in the VSANs (border VSANs) in which the specified switch is present. Issuing the ivr virtual-fcdomain-add command is required only in edge or border VSANs. It is not required in MDS native VSANs.

Enabling RDI mode on a VSAN which already has an active IVR zoneset can potentially be disruptive to the IVR traffic in that VSAN. If the VSAN does not have any active IVR zones, then enabling RDI mode is not disruptive.

If multiple IVR-enabled switches exist in an edge or border VSAN, the following error message may be displayed in the system messages: (DEVICE_ON_WRONG_NATIVE_VSAN). This message can be ignored.

---

Common commands issued on a Brocade switch show the expected information when working with devices presented via IVR. For example:

Top3800:admin> topologyshow

4 domains in the fabric; Local Domain ID: 8

Domain   Metric   Hops   Out Port   In Ports   Flags   Bandwidth   Name

-----------------------------------------------------------------------

   1      1500      2       10     0x00000040    D      2 (Gbs)   "IVR-9509"

 109       500      1       10     0x00000040    D      2 (Gbs)   "ca-9506"

 239      1501      3       10     0x00000040    D      2 (Gbs)   "IVR-9509"

Notice that domain 239 is on the same switch as domain 1, but it has a cost of one more. The higher cost is because IVR adds 1 for converting from one VSAN to another. However, the Brocade thinks it is actually another hop.

Top3800:admin> nsallshow

{

  0816dc ef0004       <==== FCID ef0004 is created by IVR

2 Nx_Ports in the Fabric }

Top3800:admin> cfgshow

Defined configuration:

cfg:   iscsi   iscsi_vsan114; IVRZ_AIX5_JBOD1123 <= All IVR zones are prefixed with "IVRZ"

 zone:  IVRZ_AIX5_JBOD1123

                21:00:00:20:37:4b:9a:bc; 10:00:00:00:c9:34:a5:be

 zone:  iscsi_vsan114

                23:23:23:23:23:23:23:23; 22:00:00:20:37:14:74:e8;

                22:00:00:20:37:14:74:49; 22:00:00:20:37:04:ea:2b;

Effective configuration:

 cfg:   iscsi

 zone:  IVRZ_AIX5_JBOD1123

                21:00:00:20:37:4b:9a:bc

                10:00:00:00:c9:34:a5:be

 zone:  iscsi_vsan114

                23:23:23:23:23:23:23:23

                22:00:00:20:37:14:74:e8

                22:00:00:20:37:14:74:49

                22:00:00:20:37:04:ea:2b

When working with IVR-1 there are two caveats that should be noted:

1. When routing between an interop mode 1 or 4 VSAN and a non-interop mode 1 or 4 VSAN, make sure that there are no domains in the native, or legacy switch interop modes 2 or 3 VSANs that are outside of the 97 to 127 range. Domains outside of this range cannot be created in the interop mode 1 VSAN. This is not a limitation of IVR-1, but a restriction imposed upon the configuration by interop mode 1. Since IVR-2 rewrites the domain ID and FCID of the device in the non-interop mode 1 or 4 VSAN, this is not an issue.

2. If an IVR zone set is active in a VSAN running in an interop mode, regular zone changes (such as zone set activation, reactivation or deactivation for zones that do not require IVR services) should always be initiated from the IVR border switch (the IVR-enabled MDS 9000 switch) for that VSAN. This prevents disruption to ongoing traffic between IVR initiators and targets that are allowed by both the previous active zone set and the new active zone set. Otherwise, traffic disruption is expected in the aforementioned case and a zone change may also fail, because only the border switch has the IVR configuration for that VSAN.