There are occasions where you need to remove an entire zoning configuration from a switch. One of them is if you need to add a switch to an existing fabric and it still has a configuration in it. If these two conflict the switch will simply segment and the ISL’s get disabled. Another reason might be in case of configuration conflicts where and administrator had made zone changes whilst one switch was not participating in the fabric. Depending on how the switch is set up and the actual fabric state you need to follow different procedures.
If you have a switch you need to insert into an existing fabric make sure that it is properly setup to get attached via ICL’s and/or ISL’s. If you don’t know, don’t hook up any cables as you would have no idea of what may happen.
Mistakes happen.
I recently ran into two cases where a customer ran the “cfgclear” and “cfgsave” commands on a switch AFTER he had hooked it up to an existing fabric. These two commands work extremely well in the sense that fabric-wide the entire zoning configuration got deleted.
[sam_pro id=”0_1″ codes=”true”]
As the zoning configuration is a distributed entity and by default there are no restrictions as from where it can be managed, these commands work from every switch in the fabric andwill get distributed to every other switch in that fabric.
Prevention.
There are a few ways to prevent such accidents from happening:
- Keep the switch isolated. Do not connect any cables before you are sure the switch has all the correct settings and is able to join an existing fabric . (See the Brocade best practices config guide on my blog)
- Use ACL policies. This way the switch is unable to join a fabric unless both parties have agreed on a mutual set “key”. Create your procedures in such a manner that this is the last step of the configuration setup. The chance of making mistakes that then have fabric-wide impact is much less.
- Use FCS policies. This determines which switch in the fabric is allowed to make changes that would affect fabric wide settings. Even if a new switch was able to join a fabric and adopt a zone configuration from the established fabric, it would not be able to make changes as these would be denied.
- And lastly, segregate administrative commands for different users and assign only the required privileges to those who need them.
Now, I agree that sometimes implementing these things can somewhat limit your day-to-day operations. It’s handy to be able to manage a switch with administrative privilges but you can see from the example I gave above it can also have significant impact when a fairly simple mistake is made.
Be vigilant in your procedures and always think twice before you use commands that have fabric-wide implications.
