Table Of Contents
Interoperability Limitations
Cisco MDS 9000 Family
Standard Interoperability Mode Limitations
Quality of Service in Interoperability Modes
About the QoS Operational Model
QoS Application Scenarios
QoS Operating on One Non-MDS Switch and Two MDS Switches
Changing Interop Modes to Default Modes
Nondisruptive Change
Disruptive Change
Legacy Switch Interoperability Modes (2 and 3)
Legacy Switch Interoperability Mode 4
Inter-VSAN Routing (IVR)
McData Switches
Brocade Switches
Interoperability Limitations
This chapter describes the restrictions and limitations imposed on specific vendor switches when working in interoperability mode. It includes the following sections:
•
Cisco MDS 9000 Family
•McData Switches
•Brocade Switches
Cisco MDS 9000 Family
The standard interoperability mode, which has been a fully functional feature since MDS SAN-OS Release 1.0(1), enables the MDS 9000 switch to interoperate with Brocade and McData switches when they are configured for interoperability. The standard interoperability mode allows the MDS 9000 switch to communicate over a standard set of protocols with these vendor switches.
Note The MDS 9020 switch does not support individual interop modes. To see how to interoperate the MDS 9020 with third-party switches, see Chapter 10, "MDS 9020 Switch Interoperability."
This section covers the following topics:
•Standard Interoperability Mode Limitations
•Quality of Service in Interoperability Modes
•Changing Interop Modes to Default Modes
•Legacy Switch Interoperability Modes (2 and 3)
•Legacy Switch Interoperability Mode 4
•Inter-VSAN Routing (IVR)
Standard Interoperability Mode Limitations
When a VSAN is configured for the default interoperability mode, the MDS 9000 Family of switches is limited in the following areas when interoperating with non-MDS switches:
•Interop mode only affects the specified VSAN. The MDS 9000 switch can still operate with full functionality in other non-interop mode VSANs. All switches that partake in the interoperable VSAN should have that VSAN set to interop mode, even if they do not have any end devices.
•Domain IDs are restricted to the 97 to 127 range, to accommodate McData's nominal restriction to this same range. Domain IDs can either be set up statically (the MDS 9000 switch will only accept one domain ID; if it does not get that domain ID, it isolates itself from the fabric), or preferred (if the MDS 9000 switch does not get the requested domain ID, it takes any other domain ID).
•TE ports and PortChannels cannot be used to connect an MDS 9000 switch to a non-MDS switch. Only E ports can be used to connect an MDS 9000 switch to a non-MDS switch. However, TE ports and PortChannels can still be used to connect an MDS 9000 switch to other MDS 9000 switches, even when in interop mode.
•Only the active zone set is distributed to other switches.
•In MDS SAN-OS Release 1.3(x), Fibre Channel timers can be set on a per VSAN basis. Modifying the times, however, requires the VSAN to be suspended. Prior to SAN-OS Release 1.3, modifying timers required all VSANs across the switch to be put into the suspended state.
•If a Brocade switch issues a cfgsave command, the MDS 9000 switch rejects this vendor specific command. The full zone database on the MDS 9000 switch is not updated. You must manually update the full zone database or copy the active zone set to the full zone database.
•The MDS 9000 switch still supports the following zoning limits per switch across all VSANs:
–2000 zones (as of SAN-OS 3.0, 8000 zones)
–20000 aliases
–1000 zone sets
–20000 members
–8000 LUN members
–256 LUN members per zone/alias
Note Before configuring this number of zones in a mixed environment, determine the maximum number that can be supported by the other vendors present in the environment.
Table 2-1 provides a summary of features and behaviors in standard interop mode for an MDS 9000 switch.
Table 2-1 Summary of Features in Standard Interop Mode for an MDS 9000 Switch
Feature
|
Requirement / Behavior
|
Minimum Firmware Level
|
1.0(1) standard interop mode.
|
VSANs
|
Only the VSANs explicitly set for interop mode are affected. All others maintain their independence.
|
High Availability
|
Fully redundant dual supervisor modules maintain full functionality.
|
Domains
|
Domain IDs are restricted to the 97 to 127 range.
|
PortChannels and TE Ports
|
They can still be used to directly connect two MDS 9000 switches together, even while in interop mode. However, they cannot be used to directly connect to a non-MDS 9000 switch. Standard E ports are required to connect to non-MDS switches.
|
Zones and Zone Sets
|
Only the active zone set is propagated. Up to 2000 zones (8000 for SANOS 3.0+) can be supported by the MDS 9000 switch. The default zone policy changes to deny.
|
Fabric Manager and Device Manager
|
They can still be used to fully manage the MDS 9000 switch, and to create zones to be distributed to the non-MDS platforms. Fabric Manager can still view the entire mixed topology.
|
Security
|
SSH, Telnet, SNMP-v3, RADIUS and TACACS+ are supported.
|
Device Support
|
Fabric (F), Public Loop (FL), and Translative Loop (TL) are fully supported.
|
Inter-VSAN Routing (IVR)
|
Fully supported in SAN-OS Release 1.3(4a) and later with all interop modes.
|
Quality of Service in Interoperability Modes
Quality of service (QoS) is the method of prioritizing traffic and providing preferential forwarding for higher priority traffic over lower priority traffic. QoS features provide better and more predictable network service by:
•Supporting dedicated bandwidth
•Improving loss characteristics
•Avoiding and managing network congestion
•Shaping network traffic
•Setting traffic priorities across the network
This chapter describes the aspects of QoS and how it works in the interoperability modes. It includes the following sections:
•About the QoS Operational Model
•QoS Application Scenarios
About the QoS Operational Model
QoS provides guaranteed and differentiated services in the network. Traffic-conditioning functions at the network boundary are required to deliver differentiated services within the network domain. These functions provide packet classifier, marker, and scheduler. Figure 2-1 shows the QoS processing in a network node.
In a network, packets are generally differentiated on a flow basis by the fields in the packet header. An individual flow is made up of packets going from an application on a source machine to an application on the destination machine. Packets belonging to a flow carry the same values for the packet header fields. The routers at the network boundary perform classifier functions to identify packets into classes based on the service levels. A marker function marks the classified traffic by setting the Differentiated Services Code Point (DSCP) field. The marker function marks packets with information that determines the associated service level. The scheduler schedules the traffic packets by providing the required service level that guarantees on latency and bandwidth.
Figure 2-1 QoS Operational Model
QoS Application Scenarios
The effectiveness of QoS depends on the location of Cisco MDS 9000 Family switches in the fabric relative to the location of the source or destination of the prioritized devices. QoS is carried over ISL only if it is in trunking mode, that is, when switches are connected over TE ports (as with MDS 9000 switches). In the interoperability modes, QoS functions only up to the MDS switch boundary when the MDS switches are interconnected with TE links. QoS does not operate with non-MDS switches.
This concept is illustrated in the following scenarios:
•QoS Operating on Three MDS Switches
•QoS Operating on One Non-MDS Switch and Two MDS Switches
QoS Operating on Three MDS Switches
The example in this section describes how QoS functions on the data traffic between three MDS 9000 switches.
In this example topology, data traffic is handled by three MDS switches, S1, S2, and S3, as shown in Figure 2-2. Switch S1 is connected to hosts H1 and H2 and switch S3 is connected to targets T1 and T2. The TE ports connect the MDS 9000 switches with each other. The switches use interswitch links, ISL1, and ISL2, to route the traffic between the source and destination.
Figure 2-2 QoS Between Three Cisco MDS Switches
Data flow traffic in the direction from switch S1 to switch S3
Data packets enter S1 through the access port. The packets are classified into certain classes based on one or more fields and then marked to indicate their traffic class. The traffic scheduling then transmits packets, based on their priority, to the next switch, S2. The marker information is available at switch S2 because TE ports connect the switches, and the packets are sent with the same precedence to switch S3. QoS is applied in all the switches in the forward direction.
Data traffic flow in the direction from switch S3 to switch S1
The packets from switch S3 are classified and marked and then sent to switch S2 based on their priority. The marker information is available at switch S2 because TE ports connect the switches, and the packets are transmitted to switch S1 in the same precedence as they are received. QoS is applied in all the switches in the backward direction.
QoS Operating on One Non-MDS Switch and Two MDS Switches
The following examples describe how QoS works in the data traffic between MDS switches and a non-MDS switch:
•Switch S1 is a Non-MDS Switch
•Switch S2 is a Non-MDS Switch
Switch S1 is a Non-MDS Switch
In this example topology, data traffic is been handled by one non-MDS switch S1 and two MDS switches, S2 and S3, as shown in Figure 2-3. Switch S1 is connected to hosts H1 and H2 and switch S3 is connected to targets T1 and T2. Switch S1 is connected to S2 through E ports because trunking is not supported between a MDS 9000 switch and a non-MDS switch. The switches use interswitch links, ISL1 and ISL2, to route the traffic between the source and destination.
Figure 2-3 Switch S1 is a Non-MDS
Switch
Data flow traffic in the direction from switch S1 to switch S3
Data packets enter switch S1 through the access port. The classification and marking of packets are implemented by the non-MDS switch and transmitted, based on their priority, to MDS switch S2. The marking information of the packets received at switch S2 cannot be identified because the switches are connected by E ports. Because the marking information cannot be determined, the packets are not sent with the assigned priority to switch S3. QoS is applied only on switch S1 in the forward direction.
Data traffic flow in the direction from switch S3 to switch S1
The packets from switch S3 are classified and marked and then sent to switch S2 based on their priority. The marker information is available at switch S2 because the switches are connected through TE ports. The packets are transmitted to switch S1 in the same precedence as they are received. QoS is applied only on switch S3 and switch S2 in the backward direction.
Switch S2 is a Non-MDS Switch
In this example topology, data traffic is been handled by Cisco MDS switch S1, non-MDS switch S2, and Cisco MDS switch S3 as shown in Figure 2-4. Switch S1 is connected to hosts H1 and H2 and switch S3 is connected to targets T1 and T2. The switches are connected through E ports because trunking is not supported between the MDS 9000 switch and a non-MDS switch. The switches use interswitch links, ISL1 and ISL2, to route the traffic between the source and destination.
Figure 2-4 Scenario 3 - Switch S2 is a Non-MDS Switch
Data flow traffic in the direction from switch S1 to switch S3
Data enters switch S1 and the classifying functions differentiates the packets into classes and the marking functions marks and prioritizes the packets. The scheduling capabilities transmit the packets based on priority to switch S2. The non-MDS switch S2 does not have the marking information of the incoming packets because the switches are connected through E ports. The priority of the packets cannot be determined and packets that are transmitted to switch S3 does not conform to the set priority levels. QoS is applied only on switch S1 in the forward direction.
Data flow traffic in the direction from switch S3 to switch S1
The packets are classified and marked, and the differentiated traffic is transmitted from switch S3 to switch S2 based on the priority. Because the marker information is not available at switch S2, the precedence of packets cannot be determined and traffic scheduling is not able to transmit data packets to switch S1 based on priority. QoS is applied only on switch S3 in the backward direction.
Note To learn more about QoS, refer to Cisco MDS 9000 Family Fabric Manager Configuration Guide.
Changing Interop Modes to Default Modes
This section covers the following topics:
•Nondisruptive Change
•Disruptive Change
Nondisruptive Change
The MDS interoperability modes 1, 2, and 3 in a VSAN can be changed to the native mode without disruption.
Before changing interop modes 1, 2, and 3 ensure do the following configurations. If they are not configured, configure them before proceeding:
•Configure a static domain ID in the VSAN.
•Enable persistent FC IDs in the VSAN.
To nondisruptedly change the interop mode to a native mode VSAN, follow these steps:
Step 1 Back up the running configuration.
Step 2 Verify that the default zone is set to deny. If not, set the zone to deny.
Step 3 Disable the active zone set in the VSAN.
Step 4 Clear the zone set in the VSAN.
Step 5 Change the interop mode in the VSAN to the default mode.
Step 6 Restart the domain in the VSAN with fcdomain restart vsan x command (configuration mode).
Step 7 Restore the zone set from the backup configuration.
To restore the zone set from the backup configuration, first extract the zone set from VSAN x from the uploaded configuration and then download the configuration.
The following are examples of configurations with extracted zone sets:
Full Zone Database Section for vsan 10
zone name SoIP_BOATEST vsan 10
member pwwn 10:00:00:00:c9:2d:43:e2
member pwwn 10:00:00:00:c9:2d:43:e3
zone name SoIP_boatest2 vsan 10
member pwwn 21:00:00:20:37:8f:db:e5
member pwwn 21:00:00:20:37:d8:4c:84
zone name SoIP_zone1 vsan 10
member pwwn 50:06:04:82:bf:d0:7f:43
member pwwn 50:06:04:82:bf:d0:7f:53
zoneset name test_router_zone vsan 10
zoneset activate name test_router_zone vsan 10
Disruptive Change
Changing interop mode 4 causes the FC IDs of devices to change because of McData's unique design of FC IDs. McData uses an offset of 96 between the configured domain ID and what is actually distributed in the fabric (on the wire).
For example if a domain ID is configured as 4 in the McData native mode, the domain ID part of the FC IDs for devices attached would be 4+96 = 100 since 96 is the offset. If a static domain ID is configured and the interoperability mode is changed to a default mode, the domain ID does not change and remains as 4. The FC IDs would have to change from 100 to 4, and this action causes the device to log out and log in. This is a restriction imposed upon the configuration by the McData design.
The interop mode 4 VSAN also requires the Organizational Unique Identifier (OUI) part of the WWN to be changed. Therefore, interop mode 4 VSAN cannot be changed nondisruptedly to the default VSAN.
Before you change an interop mode into a native mode VSAN, follow these steps:
Step 1 Back up the running configuration.
Step 2 Verify that the default zone is set to deny, if not, set it to deny.
Step 3 Disable the active zone set in the VSAN.
Step 4 Clear the zone set in the VSAN.
Step 5 Suspend the VSAN.
Step 6 (Optional) For interop mode 4, restore the WWN of the interop mode VSAN to default VSAN. Change the McData Organizational Unique Identifier (OUI) 08:00:88 to Cisco OUI 00:0d:ec in the WWN. You can ignore this step for other interop modes.
Step 7 Change the interoperability mode.
Step 8 Restore the zone set and zones from the backed-up configuration.
Step 9 Unsuspend the VSAN.
Step 10 Activate the zone set.
The same rule applies if you are changing from an MDS native mode VSAN to interop mode 1, 2, or 3. If the VSAN to be changed spans multiple switches, first suspend that VSAN on all switches, and then continue to unsuspend them.
Note For information on configuring and managing zones and VSANs, refer to the Cisco MDS 9000 Family CLI Configuration Guide and the Cisco MDS 9000 Family Fabric Manager Configuration Guide.
Legacy Switch Interoperability Modes (2 and 3)
Starting in MDS SAN-OS Release 1.2(1) and continuing in Release 1.3(2a), two legacy switch interoperability modes were introduced:
•Interop Mode 2—Introduced in MDS SAN-OS Release 1.2(1), legacy switch interoperability mode 2 allows an MDS VSAN to communicate seamlessly with a Brocade 2100, 2400, 2800 or 3800 series switch without having to modify the configuration of the Brocade switch. Chapter 7, "MDS 9000 Legacy Switch Interop Mode 2," provides additional information and a tutorial using this mode.
•Interop Mode 3—Introduced in MDS SAN-OS Release 1.3(2a), legacy switch interoperability mode 3 allows an MDS VSAN to communicate seamlessly with a Brocade 3900 or 12000 model switch without having to take the Brocade switch offline. Chapter 8, "MDS 9000 Legacy Switch Interop Mode 3,"provides additional information about this mode.
When a VSAN is configured for one of the legacy switch interoperability modes, the Cisco MDS 9000 Family of switches is limited in the following areas when interoperating with Brocade switches:
•Legacy switch interop modes only affect the specified VSAN. The MDS 9000 switch can still operate with full functionality in other non-interop mode VSANs. All switches that partake in the interoperable VSAN should have that VSAN set to Legacy Switch Interop, even if they do not have any end devices.
•TE ports and PortChannels cannot be used to connect an MDS 9000 switch to non-MDS switches. Only E ports can be used to connect an MDS 9000 switch to a non-MDS switch. However, TE ports and PortChannels can still be used to connect an MDS 9000 switch to other MDS 9000 switches, even when in interop mode.
•The active zone set and full zone databases are distributed to other switches.
•In MDS SAN-OS Release 1.3(x), Fibre Channel timers can be set on a per VSAN basis. Modifying times, however, requires the VSAN to be suspended. Prior to Release 1.3, modifying timers required all VSANs across the switch to be put into the suspended state.
•If new zones are added and the cfgsave command is issued on the Brocade switch, vendor specific frames are sent to the other switches in the fabric. The MDS 9000 switch parses these frames and modifies the full database accordingly. However, the MDS 9000 switch does not save the full database to nonvolatile memory unless the copy running startup command is issued. Using the MDS zoneset distribute vsan # command causes the MDS 9000 switch to emulate the Brocade cfgsave behavior by instructing other switches to save their configuration. The MDS 9000 switch will not save its own configuration unless a copy running-configuration startup-configuration command is issued. When a zone set is activated by the MDS 9000 switch, it implicitly sends a cfgsave command to the Brocade switches.
•The MDS 9000 switch continues to support the following zoning limits per switch across all VSANs:
–2000 zones (8000 in SAN-OS Release 3.0)
–2000 aliases
–1000 zone sets
–20000 members
–8000 LUN members
–256 LUN members per zone/alias
Note Before configuring this number of zones in a multi-vendor environment, determine the maximum number that can be supported by the other vendors present in the environment.
Table 2-2 provides a summary of features and behaviors in legacy switch interop mode for an MDS 9000 switch.
Table 2-2 Summary of Features in Legacy Switch Interop Mode for an MDS 9000 Switch
Feature
|
Requirement / Behavior
|
Minimum MDS SAN-OS Release
|
1.2(1) for legacy switch interop mode 2; 1.3(2a) for legacy switch interop mode 3.
|
VSANs
|
Only the VSANs explicitly set for interop mode are affected. All others maintain their independence.
|
High Availability
|
Fully redundant dual supervisor modules maintain full functionality.
|
PortChannels and TE Ports
|
They can still be used to directly connect two MDS 9000 switches together, even while in interop mode. However, they cannot be used to directly connect to a non-MDS switch. Standard E ports are required to connect to non-MDS switches.
|
Zone and Zone Sets
|
Only the active zone set is propagated. Up to 2000 zones can be supported by the MDS 9000 switch.
|
Fabric Manager and Device Manager
|
They can still be used to fully manage the MDS 9000 switch, and to create zones to be distributed to the non-MDS platforms. Fabric Manager can still view the entire mixed topology.
|
Security
|
SSH, Telnet, SNMP-v3, and RADIUS are supported.
|
Device Support
|
Fabric (F), Public Loop (FL), and Translative Loop (TL) are fully supported.
|
Inter-VSAN Routing
|
Fully supported in SAN-OS Release 1.3(4a) and after with all interop modes.
|
Legacy Switch Interoperability Mode 4
In Cisco MDS SAN-OS Release 3.0(1), legacy switch interoperability mode 4 was introduced to enable seamless integration with McData switches that are running in McData Fabric 1.0 mode. Chapter 9, "MDS 9000 Legacy Switch Interop Mode 4" provides additional information about this mode.
When a VSAN is configured for interoperability mode 4, the Cisco MDS 9000 Family of switches is limited in the following areas when interoperating with McData switches:
•Legacy switch interop modes only affect the specified VSAN. The MDS 9000 switch can still operate with full functionality in other non-interop mode VSANs. All switches that partake in the interoperable VSAN should have that VSAN set to legacy switch interop mode 4, even if they do not have any end devices.
•TE ports and PortChannels cannot be used to connect an MDS 9000 switch to non-MDS switches. Only E ports can be used to connect an MDS 9000 switch to a non-MDS switch. However, TE ports and PortChannels can still be used to connect an MDS 9000 switch to other MDS 9000 switches, even when in interop mode, and TE ports and PortChannels can carry interop mode 4 VSANs.
•Only the active zone set is distributed to other switches.
•In MDS SAN-OS Release 1.3(x), Fibre Channel timers can be set on a per VSAN basis. Modifying timers, however, requires the VSAN to be suspended. Prior to Release 1.3, modifying timers required all VSANs across the switch to be put into the suspended state.
•The MDS 9000 switch continues to support the following zoning limits per switch across all VSANs:
–2000 zones (8000 in SANOS 3.0)
–20000 aliases
–1000 zone sets
–20000 members
–8000 LUN members
–256 LUN members per zone/alias
Note Before configuring this number of zones in a multi-vendor environment, determine the maximum number that can be supported by the other vendors present in the environment.
Table 2-3 provides a summary of features and behaviors in legacy switch interop mode for an MDS 9000 switch.
Table 2-3 Summary of Features in Legacy Switch Interop Mode 4 for an MDS 9000 Switch
Feature
|
Requirement / Behavior
|
Minimum MDS SAN-OS Release
|
SAN OS 3.0(1)
|
VSANs
|
Only the VSANs explicitly set for interop mode 4 is affected. All others maintain their independence.
|
High Availability
|
Fully redundant dual supervisor modules maintain full functionality.
|
PortChannels and TE Ports
|
They can still be used to directly connect two MDS 9000 switches together, even while in interop mode. However, they cannot be used to directly connect to a non-MDS switch. Standard E ports are required to connect to non-MDS switches.
|
Zone and Zone Sets
|
Only the active zone set is propagated. Up to 2000 zones (8000 in MDS SAN-OS Release 3.0) can be supported by the MDS 9000 switch.
|
Fabric Manager and Device Manager
|
They can still be used to fully manage the MDS 9000 switch, and to create zones to be distributed to the non-MDS platforms. Fabric Manager can still view the entire mixed topology.
|
Security
|
SSH, Telnet, SNMP-v3, and RADIUS are supported.
|
Device Support
|
Fabric (F), Public Loop (FL), and Translative Loop (TL) are fully supported.
|
Inter-VSAN Routing
|
Fully supported in MDS SAN-OS Release 1.3(4a) and later with all interop modes.
|
Inter-VSAN Routing (IVR)
Inter-VSAN routing (IVR) allows a device that is in one VSAN to communicate with a device that is located in another VSAN. IVR was introduced in MDS SAN-OS Release 1.3(2a).
MDS SAN-OS Release 1.3(4a) introduced IVR for all interop modes within a configuration, so that inter-VSAN routing is now possible between all interop mode VSANs.
See Chapter 11, "Interoperability with Inter-VSAN Routing," for more information on IVR and interoperability.
McData Switches
Note Prior to performing an installation, see "McData Switches" in Chapter 14, "Caveats," for the latest issues with McData switch interoperability.
When configured for interoperability mode (Open Fabric 1.0), McData switches have the following restrictions and limitations:
•Interoperability mode is switch-wide.
•Enabling interoperability mode is a disruptive process to the entire switch.
•Zoning is restricted to pWWN, and port number zoning is not allowed.
•The default zone behavior changes to deny (devices that are not explicitly in a zone are isolated from all other devices).
•Domain IDs are restricted to the 97 to 127 range. However, when configuring domain IDs on the McData switch, a range of 1-31 is specified. McData uses an offset of 96 between the configured domain ID and what is actually distributed in the fabric (on the wire).
•Fabric Config Server (FCS) is not supported.
When configured for McData Fabric 1.0, in conjunction with an MDS interop mode 4 VSAN (see Chapter 9, "MDS 9000 Legacy Switch Interop Mode 4"), McData switches have the following restrictions and limitations:
•McData Fabric 1.0 is configured switch wide, and all McData switches must be configured in the same mode.
•FC IDs are restricted to the 97 to 127 range. However, when configuring domain IDs on the McData switch, a range of 1-31 is specified. McData uses an offset of 96 between the configured domain ID and what is actually distributed in the fabric (on the wire).
•McData SANtegrity features are not supported with an MDS switch in interop mode 4.
Brocade Switches
Note Prior to performing an installation, see "Brocade Switches" in Chapter 14, "Caveats," for the latest issues with Brocade interoperability.
When interoperability mode is set, the Brocade switch has the following limitations:
•All Brocade switches should be in Fabric OS 2.4 or later.
•Interop mode affects the entire switch. All switches in the fabric must have interop mode enabled.
•Msplmgmtdeactivate must be run prior to connecting the Brocade switch to either an MDS 9000 switch or a McData switch. This command uses Brocade proprietary frames to exchange platform information. The MDS 9000 switch and McData switches do not understand these proprietary frames, and rejection of these frames causes the common E ports to become isolated.
•Enabling interoperability mode is a disruptive process to the entire switch. It requires the switch to be rebooted.
•If there are no zones defined in the effective configuration, the default behavior of the fabric is to allow no traffic to flow. If a device is not in a zone, it is isolated from other devices.
•Zoning can only be done with pWWNs. You cannot zone by port numbers or nWWNs.
•To manage the fabric from a Brocade switch, all Brocade switches must be interconnected. This interconnection facilitates the forwarding of the inactive zone configuration.
•Domain IDs are restricted to the 97 to 127 range to accommodate McData's nominal restriction to this same range.
•Brocade WebTools will show a McData switch or an MDS 9000 switch as an anonymous switch. Only a zoning configuration of the McData switch or the MDS 9000 switch is possible.
•Private loop targets will automatically be registered in the fabric using translative mode.
•Fabric watch is restricted to Brocade switches only.
•The full zone set (configuration) is distributed to all switches in the fabric. However, the full zone set is distributed in a proprietary format, which only Brocade switches accept. Other vendors reject these frames, and accept only the active zone set (configuration).
•The following services are not supported:
–Alias Server
–Secure fabric OS
–Management server
•The following services are disabled:
–Virtual channels
–Quickloop
–QuickLoop Fabric Assist zones
•The following services are not valid:
–Broadcast zones
–Domain/port representation in zones
–Trunking
Figure 2-5 displays the features and functionality that are maintained or disabled in a sample MDS 9000 switch to Brocade fabric.
Figure 2-5 Sample Topology with Interop Mode Features
