03-23-2016 08:32 AM
We are adding a new zone to an exisintg config but BNA is giving us this warning. We are not running FICON (at least that we are aware of..!) but regardless of that we don't think that we have 'mixed' zones anyway. Is there an easy way to tell if we do have any zones anywhere that do contain a mix 'WWN and Domain, Port Index Zone Members', as far as we can tell all our zoning is WWPN?
03-23-2016 11:24 AM
First things first:
If want to determine if your fabric is ficon enabled, issue the command configshow|grep -i ficon and it will bring you a line like this:
FCSWITCH> configshow |grep -i ficon
If ficon is enabled, the value has to be 1 otherwise you do not run ficon in your fabric.
In order to determine if you have active Domain,Index zone members in your actual config, run cfgactvshow |grep "," if you get some return, so you do have a zone with Domain,Index members mixed with wwn.
To get the exact zone i only know how to do this by some scripting. I made a python program that can look for port member alias. Let me know if you are interested in use it.
03-23-2016 11:42 AM
Thats great, thanks.
Slighlty confusingly this just confirms what we thought - none of the switches/fabrics have FICON mode enabled and none of the active zones contain anything other than WWPNs.
Not sure now why BNA is displaying that warning whenever we try to create a zone..!
03-24-2016 05:05 AM
i had similarly problem long time ago - if i remember correct with FOS 7.1 - in my case VF was enabled and a Logical Switch configured. BNA show the same error message.
03-24-2016 05:15 AM
Yes, this does seem to be the case - the BNA warning has come in since we have introduced some new devices with logical switches.
03-24-2016 05:57 AM
I was able to reproduce the message excactly as you exposed.
FOS 6.4.0c VF enabled, BNA 12.4 and the message appeared when making some zone changes. thanks for sharing!
03-24-2016 06:07 AM
here is a workaround how to resolve the problem, however I don't have at the moment the DOC on the hand, or better to say cannot find it.
I come back when i find it.
04-12-2016 06:44 AM
Did you ever manage to dig out that workaround so we don't get this alert anymore please?
04-12-2016 11:49 PM - edited 04-12-2016 11:51 PM
Beside of any workaround that just hides the inapplicable message, please consider to just not using mixed zoning. From my experience it's a bad idea.
Over the years there were several bugs that only triggered if session-based hard-zoning is active (which you have as soon as you have mixed zoning) and even without bugs you could run in ugly situations.
Zoning is not enforced in the FC ASIC then. Imagine a device (big storage or even worse: a central storage virtualization) with a lot of devices zoned to it is handled in session-based hard-zoning. That means every end-to-end PLOGI is catched by the switch's ASIC and sent towards the CPU to verify if the zoning allows it.
Now imagine that big central device coming online. All the zoned devices get an RSCN and after a short query to the nameserver they now send their PLOGI to said big device. The ASIC connection to the CPU is limited and therefore such internal queries have a risk to be dropped in busy times (without any obvious hint in the support data). So you COULD run into the problem that some of your paths just don't come online. This lack of redundancy would maybe go unnoticed for a while, but would hit you, as soon as you actually need it.
And again, this is just the normal behavior. The actual bugs that you can find while searching for session-based hard-zoning in the release notes (or Brocade's knowledge base) look much more horrifying.
My recommendation: Avoid mixed zoning wherever you can.