Zoning Management – Cisco Describing VSANs and Fibre Channel Zoning

April 6, 2024

Zoning Management

When managing the zoning configuration, you need to be aware of some additional guidelines, options, and recommendations. Therefore, before working on the zoning configuration, consider the following:

  • Zone membership is based primarily on WWNs or FCIDs.
  • Multiple zones can be members of a zoneset.
  • The zonesets are created per VSAN.
  • Each VSAN can have multiple zonesets, but only one zoneset can be active at any given time.
  • When you create a zoneset, that zoneset becomes a part of the full zoneset.
  • When a zoneset is activated, a copy of the zoneset from the full zoneset is used to enforce zoning, and it’s called the active zoneset.
  • An active zoneset cannot be modified.
  • A zone that is part of an active zoneset is called an active zone.
  • You can modify the full zoneset even if a zoneset with the same name is active. The changes do not take effect until the zoneset is activated with the zoneset activate name command.
  • During the activation, the active zoneset is stored in the persistent configuration. This process allows the switch to preserve the active zoneset information across switch resets. There is no need to use the copy running-config startup-config command to store the active zoneset. However, you need to save the running configuration of the switch to store the full zoneset.
  • All other switches in the fabric receive the active zoneset so they can enforce zoning in their respective switches.
  • An FCID or N_Port that is not part of the active zoneset belongs to the default zone. The default zone information is not distributed to other switches.
  • If one zoneset is active and you activate another zoneset, the currently active zoneset is automatically deactivated. You do not need to explicitly deactivate the currently active zoneset before activating a new zoneset.

Two types of zones are supported on the Cisco MDS switches. Up until now, we have discussed the regular zones. The other type is the default zone.

The default zone always exists for each VSAN on the Cisco Fibre Channel switches. All the end devices that connect to a VSAN and are not added to a zone are automatically put in the default zone. As the zoning is a security mechanism to allow communication between specific initiators and targets, adding them automatically to a zone might pose a significant risk. That’s why the communication policy inside the default zone is set to “deny” by default. This means that every end node in the default zone will be isolated.

At this point, the logical question is, why is the default zone needed if the devices will still be isolated until they become members to a zone? The answer is related to the design and scale of your SAN infrastructure. If you are dealing with a significantly small infrastructure and just a couple of initiators and a target, for example, you can set the policy for the default zone to “allow,” and the communication of all the devices connected to your switched fabric will be automatically allowed.

This is still a very risky approach, and it is recommended that you create a specific zoning configuration, no matter how small your environment is. Also, you should always set the default zone policy to deny.

Another interesting feature of the Cisco MDS zoning configuration is that you can control exactly what access the initiators will have to the target in a zone. By default, when an initiator and a target belong to a zone, and it is active, the initiator has read and write access. It can retrieve data from the storage system, and it can send data to be stored. But there might be a situation where you want a certain initiator (or initiators) to only be able to read data from a target. Then you will put the initiator(s) in a zone and will set the zone as read-only with the command attribute read-only in the zone configuration mode, as shown here:

Click here to view code image

mds-9200-a(config)#
zone name Zone999 vsan 999

mds-9200-a(config-zone)#
attribute read-only
mds-9200-a(config-zone)#

This command can also be used with the default zone.

As already mentioned, the zones belong to a VSAN, or each VSAN has its own zoning configuration. Also, if a VSAN with the same VSAN ID exists on two Fibre Channel switches and they are not connected to each other, these two VSANs are actually separate, different VSANs, regardless of whether you see the same VSAN ID. This also means that each of the VSANs will have its own zoning configuration—one or multiple zonesets with one or multiple zones per zoneset. It is interesting to see what happens when a link is created between these two switches, because then the two separate VSANs with the same VSAN ID will connect and will become one VSAN. In other words, a zone merge will occur between the zone servers of the two VSANs. This is the process where two zone servers need to compare the zones present in each of the VSANs and make sure the zones and the zonesets are the same (that is, the zones have the same members). The question here might be, why do the zone members have to be the same? Or, why do the zones have be the same? The answer is, because the zoning is a security feature, and the goal is always to be in control. Also, there’s a risk that suddenly allowing this communication that is not supposed to happen will result in merging together all the zones from the two VSANs, which can lead to serious consequences. Figure 12-7 illustrates the zone merge.

  

Figure 12-7 Fibre Channel Zone Merges

So, the zone merge will happen when the two switches are connected with a link. If the link is an ISL, which means that a single VSAN is allowed to communicate, the zone merge will happen only for this VSAN.

If the switches are connected with an EISL, allowing multiple VSANs, the zone merge will occur for each of the VSANs. Some VSANs might merge their zones successfully, but for others there might be different zoning configurations and the merge will fail. These VSANs will become isolated, and no traffic will be allowed to cross the EISL for these VSANs.

To recover from a zone merge failure, you basically have three options, all of them manual:

  • Import the full zoneset from one switch to the other.
  • Export the full zoneset from one switch to the other.
  • Manually fix the differences in the zoning configuration.

To import or export the full zoneset, the command is zoneset {distribute | export | import interface { fc slot-number | fcip interface-number | port-channel port-number}} vsan vsan-id.