We currently use a SAN that consists of 2 fabrics.

In this SAN I am a the moment busy with

replacing the current switches in both fabrics with a 2/128 Director switch and a 2/16 switch for
each fabric.

Some time ago I connected the 2 Directors to the existing fabrics so I can do the migration in
phases. Both Directors are subordinate switches in the fabric, because the 1Gbit switches in the
existing fabrics already were the principal.

Before disabling the 1Gbit switch the configuration of each fabric was:
1 2/128 Director switch --> subordinate
1 2/16-EL switch --> subordinate
1 2/16 switch --> subordinate
1 1/16 switch --> principal

When I disabled the 1Gbit switch the Director did not become the principal, but the 2/16 switch
became the principal. This is not what I expected, I assumed the Director would become the
principal switch, because it is the largest switch in the fabric.

How is the principal switch in a fabric being elected? I know it is normally the switch that is first
turned on in the fabric, but how does it work in an existing fabric when the principal leaves the
fabric?

How can I force the 2/128 Director to be the principal switch?

Is it a problem that the Director is not the principal?

"...but how does it work in an existing fabric when the principal leaves the fabric?"

Can you show us a diagram of how your switches are interconnected to each other? I think that the
order would be the same as the boot order... since the 1/16 was the principal and the 2/16 was
possibly already in place with the 2/128 being added afterwards, the 2/16 would be "next in line".
I do not know if this is the case or if there is any logic behind the scenes that helps selects which
becomes the principal.

"How can I force the 2/128 Director to be the principal switch? "

If you reboot both the 2/16 and the 2/16el, the director should become the principal. Not the best
way since you will disrupt production, but if done off hours....

Another way would be to shutdown everything then reboot in a specific order... the 2/128 first,
then the 2/18 then the 2/18el then your storage....then tape devices...then servers.

"Is it a problem that the Director is not the principal?"

I do not see a problem with any switch being subordinate or principal unless you WANT to see a
particular switch as the principal. Some environments are like that. ;o)

Rebooting the other switches is not a good option because this would mean downtime for some
servers connected to the fabric. We have a number of systems that have only one connection to the
SAN, this is due to an explosive grow in servers connected to the SAN and a shortage of fiber
uplinks to the Directors. This is also why we have placed a 2/16 switch in a rack with blade
servers (switch12).

I prefer the Directors being the principal switches in the fabric, because they are the Core switches
in our SAN. Eventually they will become the principal anyway, but I am just wondering if it is
possible to force them to become the principal.

I'm interested in how the election of the principal switch in a fabric works, is there any
information about that?

The default behavor of the switches in the fabric is that the switch with the lowest WWN will
become principal.

Starting at FabricOS versions 4.1.0 and 3.1.0, a fabricPrincipal option was added to set a prefered
Principal switch for the fabric.

When this option is set, the switch with the lowest WWN of the switches that have the option set
will become the principal.

Note, when setting this option, a new principal is not elected until there is a fabric reconfig
uration. This usually happens when a switch joins or leaves the fabric. (The switchDisable and
switchEnable commands can cause this to happen as well as a switch reboot.)

Typically, it is not a problem that the Director is not the principal.

If the director is a core switch in the SAN, then it might be preferable to have it as the principal.
This is especially true in a larger fabric with many edge switches.

I checked the WWID's and the switch with the lowest WWID indeed is the principal!!

I believe the correct name for the setting is: fabric.principalSwSelMode. Can I modify this
parameter on a running switch or do I have to disable the switch to change this paramet er?

I have a cascaded fabric with a 4/32 switch(subordinate) and a 4/16 switch(principal). I need to
power off the principal switch next week during off hours to change the power source.

Currently, there's no production traffic over the ISL but there are zoned ports on both switches.
The 4/32(subordinate)has all our live production nodes and our EVA connected.

Should I just power off the 4/16 and let the fabric(4/32) go through a reconfiguration?

What happens when I recable and apply power to the 4/16 again? Will the old configure tion still
be saved and recognized by the 4/32 switch?

I don't this would be any different than if a cascaded switch had a power supply fail...

You should be fine just powering off the 4/16.

When you do that the fabric should reconfigure and the 4/32 will become the principal. When the
4/16 comes back up it will become the subordinate. You shouldn't lose any configuration.

when u power off the 4/16 switch.The 4/32 will become primary switch.Once u bring back the
4/16 switch voting (ELP & EFP) will happen once again.The lowest wwn number will become
Principal Switch when u power off the 4/16 switch.The 4/32 will become primary switch.Once u
bring back the 4/16 switch voting (ELP & EFP) will happen once again.The lowest wwn number
will become Principal Switch.

One last item - you can also "nail" the principal switch (rather than using the lowest WWN
algorithm) with the "fabricprincipal" command.

Adding in the new switch shold effectively remove it's status as "principal" and make it
subordinate in the existing fabric. Even if it stayed as Principal, it would have to do a fabric merge
first and the existing configuration would still be in place.

As for the determining factor as to who gets to be principal, I think it iwas found out a while ago
that the switch with the lowest WWID wins the election, if and when it happens.

Furthermore, no "set" of switches win when joining them. The fabrics merge to become 1 bigger
fabric. if the merge does not happen, then the switch does not join the fabric.

What I would do Adam is completely remove any zoning information in the DID 2 switch and
then physically connect it into your existing fabric. This will ensure there are no conflicts during
the "merge" - the existing zoning configuration will be blown into the DID 2 switch in its entirety.
As for which switch becomes principal (because of lowest WWID) - it doesn't matter. Zoning
merge conflicts would have the same effect no matter which switch ended up trying to be principal
- which is why I prefer to avoid them altogther.
HP also had be set "Insistent Domain ID Mode". They argued that I wouldn't get "2", like I
wanted, unless I did this.

As said, the switch with the lowest WWN generally becomes principal when a a fabric change hap
pens (e.g. add or remove a switch)

But you can also use the fabricprincipal command on a particular switch so that this switch will
become principal with the next change. We have a core/edge fabric topology with 2 core switches
per fabric. On both of these switches the fabricprincipal is set to 1, on all others it remains at 0
(default). Beforehand one of our old Brocade 2800 edge switches became principal, as it had a low
WWN number. Now it's always one of our core switches (Brocade 48000). The fabricpricipal
command is not available on all version of Fabric OS.

You should then perform any zoning changes from the principal switch. ANd also try to ensure
that the Fabric OS version is consistent across the fabric, if that's possible. Our 2800s are running
2.6.2c, all other switches are on 5.0.3

I have never used Insistent Domain IDs, we set the domain ID of any new switch before it joins
the fabric using the configure command, and it never changes. Also, when adding a switch, we use
the same procedure you used:
switchdisable
configure
cfgdisable
cfgclear
cfgsave
plug in first ISL
switchenable
fabricshow
check to see if it merged, and if so plug in any other ISLs

You can connect the 2 Brocade switches without disrupting anything in the SAN fabric. First
make sure that both switches do not have the same domain id. If they do, change one by running
the CONFIGURE command.
I recommend getting the ISL created first.

The Brocade FOS will then make one switch the principal and one the subordinate. The principal
will be the switch with the lowest numbered switch node WWN address.

Once this is done, use only the principal to setup your zoning on both switches. If you configure
zoning on each switch, the zoning configuration must be identical for the ISL connection to work.
So it is much easier and best practice to create and maintain zoning on the one principal switch.
You create zones and add members and verify the zoning without changing the default where
everything can access everything else. It is not until you do the last step with the command CFG
ENABLE that it actually takes effect.

Disruption to traffic? Brocade says there is none unless there are changes to traffic isolation zones,
TI zones. If you have no existing config, this is not an issue.