Table Of Contents

MDS 9000 Legacy Switch Interop Mode 3

Specifications

Configuration

Zone Merge Support Using RCS

Zone Merge Started by MDS Switch

Zone Merge Started by Other Vendor Switch

Zone Merge Process with Redundant Links

RCS Features

RCS Information Request

RCS Support in MDS

MDS 9000 Legacy Switch Interop Mode 3

---

This chapter describes how to set up an MDS 9000 legacy switch interop mode 3 topology, with Cisco MDS 9000 VSANs and Brocade 16-port switches.

This chapter includes the following sections:

•Specifications

•Configuration

•Zone Merge Support Using RCS

Specifications

Legacy switch interoperability mode 3 for Brocade switches with more than 16 ports (currently, the Brocade 3900 and 12000 models) was introduced with MDS SAN-OS Release 1.3. With this VSAN-based interop mode, Brocade switches do not have to be altered from their native mode and can be seamlessly added to a new or existing MDS SAN-OS VSAN.

MDS switches supports domain/port and pWWN zoning in interop mode 4. Domain/port zoning cannot be used for MDS-attached hosts because the McData switches do not understand the MDS 9000 switch fWWN interface nomenclature.

The primary difference between legacy switch interop mode 3 and legacy switch interop mode 2 is how the Brocade switch sets the core PID. If a Brocade fabric has switches with more than 16 ports, the core PID will be set to 1. For switches with fewer than 16 ports, Brocade initially allocated one nibble of the FC ID / PID in area field 0x0 - F for the port number. This limited the port count to 16. When the core PID is set to 1, the allocated bytes in the FC ID / PID allow the use of port numbers 0x00 - FF.

•FC ID / PID 0x021F00—Core PID 0 means domain ID 02, 1 is always set, port is 15, 00 is assigned N port or ALPA.

•FC ID / PID 0x021F00—Core PID 1 means domain ID 02, port is 31, 00 is assigned address or ALPA. Even though the FC ID is the same, the entire second byte is used for the port number.

For VSANs running in legacy switch interop mode 3, the core PID on the Brocade switch is set to 1. This can be verified with the Brocade configshow command.

Configuration

The configuration of the Brocade switch and the MDS 9000 switch is the same as the configuration for legacy switch interop mode 2 with the exception that the interop mode parameter is changed from 2 to 3.

MDS_5# config t

MDS_5 (config)# vsan database

MDS_5 (config-vsan-db)# vsan 113 interop 3

You need to make the same modifications related to portcfgislmode on the Brocade switches as specified in Chapter 7 "MDS 9000 Legacy Switch Interop Mode 2." See the "Configuration" section for more information on setting up an MDS 9000 switch and a Brocade switch for interoperability without having to change the Brocade switch from its native interoperability mode.

Zone Merge Support Using RCS

Reliable Commit Service (RCS) protocol supports MDS interoperability with other vendor switches. The other vendor switches were previously using a different proprietary protocol to distribute zone database changes to the entire fabric. The other vendor switches currently are using a new proprietary protocol called RCS for zone database change distribution. The RCS protocol sequence for a zone database change distribution is different from its previous proprietary sequence that MDS expects. The other vendor switches stopped supporting its previous proprietary protocol for a zone database change distribution from firmware version 5.3. Because of this, MDS interoperability with the other vendor switches in interop mode 3 is not working from their firmware version 5.3. Therefore, as of MDS NX-OS Release 5.0(1) and later, MDS supports the RCS protocol to provide interoperability with the other vendor switches with firmware version 5.3.

Whenever a new switch joins the fabric, the zone database merge process starts. The process of merge is as follows depending on the switch that starts the merge process:

•Zone Merge Started by MDS Switch

•Zone Merge Started by Other Vendor Switch

•Zone Merge Process with Redundant Links

•RCS Features

•RCS Information Request

•RCS Support in MDS

Zone Merge Started by MDS Switch

The MDS switch starts the zone merge process by sending Merge Request in ASCII format. The receiving switch will start to merge the received zone database with its database. When the receiving switch is able to merge, it will send the ACCEPT response, otherwise it will send REJECT response.

Zone Merge Started by Other Vendor Switch

The other vendor switch starts the zone merge process by sending the zone database checksum request. The other vendor switch calculates the checksum based on its active and full zone database. Because MDS does not know how to calculate the checksum, it will always respond with the reason saying that checksums are not same to get the merge request in the ASCII format. When MDS receives the merge request in ASCII format, it will try to merge receiving zone database with its database. Once the merge is successfully completed, the ACCEPT response will be sent; otherwise, the REJECT response will be sent.

Zone Merge Process with Redundant Links

There can be redundant links between two switches to avoid data losses. The zone merge will be performed only through the link which comes first. The zone merge will not be performed again through the subsequent links when they come up. When any link between the two switches goes down, the zone merge will not be initiated again through other up links. The two switches are considered to be part of the same fabric until all the links between two switches go down.

RCS Features

RCS provides more general and robust mechanism to manage databases in a fabric. It also provides generalized locking scheme to lock databases only with respect to a specific service or an application. For example, if a management entity is currently effecting zoning changes, this should not disallow another management entity from effecting platform registrations at the same time.

Zoning update mechanism defined in FC-SW3 is not providing option to handle certain error conditions. For example, when a managing station goes down before sending UFC to all the switches in a fabric then some switches in the fabric might have the updated databases, other switches might not have. RCS provides proper error recovery mechanism to handle such cases.

RCS Information Request

The RCS information request is used to exchange the version and capability of RCS between two switches. Whenever a switch detects a new domain, it will send the RCS information request to the new domain. The RCS information request payload has the RCS version and capability of the switch which sent the request. The receiving switch will respond with its RCS version and capability.

The RCS version and capability are used to determine the format of the RSFC application payload. Whether a switch can support the encryption of application payload is determined by its RCS version and capability.

RCS Support in MDS

MDS supports both the RCS and non-RCS protocol. When all the switches in the fabric support RCS, then the RCS support is enabled. When any switch in the fabric does not support RCS, then RCS support is disabled.

Whether a switch can support RCS or not, it can be found by issuing a RCS information request. Whenever a new switch comes up, the RCS information request will be sent to the new switch. Based on the response to this frame, the RCS support will be enabled or disabled.

When all the switches that are not supporting RCS go down in the fabric, the RCS support will be turned on immediately when there is no zone database change in progress. When there is zone database change in progress, the RCS support will be turned on only after the change operation is completed. When a switch that is not supporting RCS joins the fabric, the RCS support will be turned off.