For more details, please see ourCookie Policy.

Fibre Channel (SAN)

New Contributor
Posts: 3
Registered: ‎08-02-2016

Merging multiple Brocade SAN Switch in different Data Center


Hello All,


Need your support to get understand the merging of multiple Brocade SAN switch in different SAN switch.

In our environment we 2 data center. 

Each Datacenter has 2 Core switch and 2 HP C7000 Enclosure and 1 Storage

Each C7000 enclosure aslo has 2 SAN switch and 16 Balde serevr.


Each blader switch is connected with Core switch in each data center with trunking.

Also two Data Center also connected each other with ISL trunking.


Now from where I can start zoning, It would be helpful if you share the steps.


I am also attaching the logical diagram of our environment for better understanding.







Posts: 56
Registered: ‎05-12-2013

Re: Merging multiple Brocade SAN Switch in different Data Center

What type of SAN switches do you have? Are you wanting to connect the two data centers with fiber or will you have to use FCIP? Do you want to merge fabrics or keep them separate and use FCR?
New Contributor
Posts: 3
Registered: ‎08-02-2016

Re: Merging multiple Brocade SAN Switch in different Data Center

Thank your for your response.


In each blade we have ""Brocade 8/16Gb FC Switch (T5517A)

Data Center switch "" Brocade 16Gb/16c Embedded SAN Switch (C8S45A)


We are going to use Dark Fiber between site.


Yes we have to merge febric.

Broadcom Moderator
Posts: 108
Registered: ‎03-29-2010

Re: Merging multiple Brocade SAN Switch in different Data Center



There are several conditions which will not allow two fabrics(single switches, or multiple switch fabrics) to merge when connected with a native fiber cable(ISL). It's unlikely that you have changed any of the fabric parameters, but that will stop a fabric from merging together.


Most common are differences in the zone configuration between the two fabrics. One fabric will have the zone info for its devices, and the other fabric will have zone info for its devices. When you try to merge two fabrics, there are two basic scenarios where you can setup the zoning so that the fabrics will merge.


The general rule is that the Effective and Defined zone entries must match EXACTLY. Including the size of all the entries in the zone databases, and the order of the members in the zone.


Here is an abstract of the process from the SAN admin guide for FOS 7.4.x, with the relevant steps for checking a zone conflict in bold near the bottom.


Zone merging

When a new switch is added to the fabric, it automatically takes on the zone configuration information from the fabric. You can verify the zone configuration on the switch using the procedure described in Viewing the configuration in the effective zone database.

If you are adding a switch that is already configured for zoning, clear the zone configuration on that switch before connecting it to the zoned fabric. Refer to Clearing all zone configurations for instructions.

Adding a new fabric that has no zone configuration information to an existing fabric is very similar to adding a new switch. All switches in the new fabric inherit the zone configuration data. If the existing fabric has an effective zone configuration, then the same configuration becomes the effective configuration for the new switches.

Before the new fabric can merge successfully, it must pass the following criteria:

  • Before merging - To facilitate merging, check the following before merging switches or fabrics:
    • Defaultzone: The switches must adhere to the default zone merge rules, as described in Zone merging scenarios.
    • Effective and defined zone configuration match : Ensure that the effective and defined zone configurations match. If they do not match, and you merge with another switch, the merge may be successful, but unpredictable zoning and routing behavior can occur.
  • Merging and segmentation

The fabric is checked for segmentation during power-up, when a switch is disabled or enabled, or when a new switch is added.

The zone configuration database is stored in nonvolatile memory by the cfgSave command. All switches in the fabric have a copy of this database. When a change is made to the defined configuration, the switch where the changes were made must close its transaction for the changes to be propagated throughout the fabric.

If you have implemented default zoning, you must set the switch you are adding into the fabric to the same default zone mode setting as the rest of the fabric to avoid segmentation.

  • Merging rules - Observe these rules when merging zones:
    • Local and adjacent configurations: If the local and adjacent zone database configurations are the same, they will remain unchanged after the merge.
    • Effective configurations: If there is an effective configuration between two switches, the effective zone configurations must match.
    • Zone object naming: If a zoning object has the same name in both the local and adjacent defined configurations, the object types and member lists must match. When comparing member lists, the content and order of the members are important.
    • Objects in adjacent configurations: If a zoning object appears in an adjacent defined configuration, but not in the local defined configuration, the zoning object is added to the local defined configuration. The modified zone database must fit in the nonvolatile memory area allotted for the zone database.
    • Local configuration modification: If a local defined configuration is modified because of a merge, the new zone database is propagated to other the switches within the merge request.
    • TI zones: If there is an effective configuration between two switches and TI zones are present on either switch, the TI zones are not automatically activated after the merge. Check the TI zone enabled status using the zone --show command, and if the status does not match across switches, issue the cfgEnable command.


  • Merging two fabrics

Both fabrics have identical zones and configurations enabled, including the default zone mode. The two fabrics will join to make one larger fabric with the same zone configuration across the newly created fabric.

If the two fabrics have different zone configurations, they will not be merged. If the two fabrics cannot join, the ISL between the switches will segment.

  • Merge conflicts

    When a merge conflict is present, a merge will not take place and the ISL will segment. Use the switchShow or errDump commands to obtain additional information about possible merge conflicts, because many non-zone-related configuration parameters can cause conflicts. Refer to the Fabric OS Command Reference for detailed information about these commands.

    If the fabrics have different zone configuration data, the system attempts to merge the two sets of zone configuration data. If the zones cannot merge, the ISL will be segmented.

    A merge is not possible if any of the following conditions exist:

    • Configuration mismatch: Zoning is enabled in both fabrics and the zone configurations that are enabled are different in each fabric.
    • Type mismatch: The name of a zone object in one fabric is used for a different type of zone object in the other fabric.
    • Content mismatch: The definition of a zone object in one fabric is different from the definition of the zone object with the same name in the other fabric.
    • Zone database size: The zone database size exceeds the maximum limit of another switch.
If the zone set members on two switches are not listed in the same order, the configuration is considered a mismatch, resulting in the switches being segmented from the fabric. For example, cfg1 = z1; z2 is different from cfg1 = z2; z1 , even though members of the configuration are the same. If zone set members on two switches have the same names defined in the configuration, make sure zone set members are listed in the same order.
In a large fabric, especially with 1 MB or more zone configuration takes some amount of time for zone merge. This may cause host device to not to discover the target in other end of the fabric for a short duration. This problem may not be seen if the you follow the guidelines of joining the stable fabric one by one with devices offline and ensure that the zone merge operation is completed before enabling the devices.
Some administrators attempt to build a new config file with both sets of zone members together, and then load that new larger config on each side of the fabrics to be merged. If you work on this, remember that the file must match exactly in each fabric config file.
Once you have a large config file with all members from both original zones, and it is loaded, note that you can connect the ISL, and if there is a segmentation, the results will be shown in the errdump.
Further reading is suggested in the FOS admin guide, the number for that guide for FOS 7.4.x is 53-1003509-04  and is found under the "Support Document library" tab on Search for: "Zone merging scenarios" in the guide, and find your situation. Tables 61 through 69 cover all the typical conditions found in the field.
Finally, there is no damage, and very little chance of data loss in the event of the fabrics failing to merge. the errdump will have the results of the failure.

Any and all information provided by me is for entertainment value and should not be relied upon as a guaranteed solution or warranty of mechantability. All systems and all networks are different and unique. If you have a concern about data loss, or network disconnection, please open a TAC service request for service through Brocade, or through your OEM equipment provider. If this provided you with a solution to this issue, Please mark it with the button at the bottom "Accept as solution".

Join the Broadcom Support Community

Get quick and easy access to valuable resources across the Broadcom Community Network.