8 Krypton

Re: Defined ZoneCFG's out of sync between dual core directors

I'm a bit confused by the scenario presented as a fabric shares a zoning config. You can't have different zoning configs on the two chassis if they are actually in a single fabric.

The first thing I would check is that the ISLs are actually working as ISLs and that your fabric isn't segmented. If CMCNE shows everything is OK then you need to log directly onto one of the switches and check through either the WebTools GUI or the CLI. If you use the CLI you can do a fabricshow to see if the ISLs are functioning properly.

If everything proves that these two switches are still part of the same fabric and your zoning appears different between the two then you need to get a support case open.

Back to the question of how CMCNE chooses a switch to "zone" through, it's not so much that it picks a switch for that purpose, but when you discover a fabric CMCNE defines one of the switches in the fabric as the "seed" switch. This is the primary point of contact for fabric based communication from CMCNE. You can change the seed switch (if allowed). There are rules that are used to determine which switch should be the seed. The first one I believe is that the switch with the highest FOS version should be the seed. Other rules follow below that priority. You can see which switch is seed from the Fabric Discovery dialog.

Just as I'm writing this I'm thinking there is one other possibility. I can't imagine how they would get in that state without it being done on purpose but if the new chassis was set up for Virtual Fabrics then it is possible something got mixed up and part of the chassis is ISLed to the old switch and part is its own fabric. That's an unlikely one but it's about the only way I can imagine two chassis with valid ISLs having different zoning configs.

0 Kudos