07-15-2011 04:39 PM
I have 2 switches in each local and remote site, connected with a ISL link per switch, so, I have 2 fabrics . After a ISL link provider problem, that took a long period of time to resolve, all subordinate switches became to Principal, therefore I lost the fabric condition, with a Zone conflict message on each ISL port. A workaround to resolve this should be to save the zone config file, disable ISL ports, remove config from principal switches, enable the ISL ports, and let the config propagate through the fabric. I have not tested this yet, I think It might work, but I need to know why this problem happened. It's a code bug?, or a natural behavior, to protect the zone config after a log period of time without ISL connection? Both fabric present the same issue.
07-17-2011 10:22 AM
it looks that your zoning configuration has been changed while your fabrics were separated due to ISL failure.
If that is the case, you should identify which zoning configuration you want to keep and distribute that to all other switches in the same fabric.
If changes are minor, you might as well just redo the same changes on every switch which would be online procedure. Once zone configurations match, switches will be able to merge into fabric.
The way I would do it would be with switchdisable/cfgdisable/cfgclear but keep in mind that there are perhaps some devices on every switch that will start seeing each other if zoning configuration doesn't propagate successfully and defzone is set to "allaccess".
There can only be one configuration, whether or not it comes from a principal switch initially.
Hope this helps a bit,