The zoning service within a Fibre Channel (FC) fabric was designed to provide security between devices sharing the same fabric. The primary goal was to prevent certain devices from accessing other devices within the fabric. With many different types of servers and storage devices on the network the need for security is critical. For example, if a host were to gain access to a disk being used by another host, potentially with a different operating system, the data on this disk could become corrupted. To avoid any compromise of critical data within the Storage Area Network (SAN), zoning allows the user to overlay a security map dictating which devices, namely hosts, can see which targets thereby reducing the risk of data loss.

Zoning does however have its limitations. Zoning was designed to do nothing more than prevent devices from communicating with other unauthorized devices. It is a distributed service that is common throughout the fabric. Any installed changes to a zoning configuration are therefore disruptive to the entire connected fabric. Zoning also was not designed to address availability or scalability of a Fibre Channel (FC) infrastructure.


What are the benefits of Zoning?

  • Enhanced Device Security— By deploying zoning within a Fibre Channel (FC) fabric, device access is limited to devices within the zone. This allows the user to segregate devices based on access to a particular storage device (target). This is generally an absolute requirement when dealing with multi-OS environments accessing the same physical fabric. Most operating systems cannot read or understand the block layout or file system structure of different operating systems. Should, for example, a Windows-based host see a disk being utilized by an AIX host, the file structure would look foreign and may be viewed by the Windows system as being a corrupt Windows volume that is available and must be repaired. Once the Windows server writes its “signature” to that disk it will now look foreign to the original AIX server and data corruption will occur. This is exactly the type of scenario zoning was designed to prevent and the reason zoning is so critical. Each time a zone configuration is installed, whether it is port-based or WWN-based, the configuration is actually downloaded into hardware and a frame-by-frame hardware-based filter is installed to ensure no frames shall pass that are disallowed by the zoning configuration.


  • RSCN Suppression— By implementing zoning within a Fibre Channel (FC) network, Registered State Change Notifications (RSCNs) are isolated to the devices within the zone in which the state change happened. This causes fewer disruptions to devices within the fabric, especially to devices that have no reliance or are not in the proximity of the actual state change. In some instances however, such as a storage array interface that may reside in several zones simultaneously, zoning cannot provide complete protection.

  • Multiple Zones per Port  When utilizing zoning to isolate device connectivity, a single shared device may have to exist in multiple zones at the same time. This typically occurs when multiple servers require access to the same disk subsystem interface. Each server usually resides in a separate zone with the disk subsystem interface and hence the disk subsystem interface resides in a zone with each server. This allows access to the common device, the storage subsystem interface, while preventing the servers themselves from communicating with each other.


What are the limitations of Zoning?


  • Scalability— While Fibre Channel networks today are relatively limited in size compared to a typical IP network, the increasing scale of storage networks in the future will likely reveal design limitations. Fibre Channel not only dictates a limit on the number of domains (typically one switch per domain) within the fabric, but also the number of ports within the domain. Zoning does nothing to provide a higher level of scalability for the network. Even though devices may be in separate zones, such zones still reside in one common fabric bound by the addressing limitations and routing scalability within the fabric. In addition, as fabrics grow larger, so too will the number of deployed zones and the control plane bandwidth required to manage the higher number of zones.


  • Fabric Availability— While zoning, when enforced by hardware, can provide significant security benefits within a network it does nothing to provide enhanced availability within the fabric itself. Should the name server stop responding or FSPF begin to route erratically this will have a very disruptive effect on the entire storage network as common fabric services are shared across all zones within a fabric. In addition, due to the distributed nature of zoning, any changes made to an active zone set have fabric-wide impacts and potential disruptions as the zone set changes are installed.



  • Traffic Management— Zoning is very effective in managing connectivity between end devices within a storage network. However, zoning does not offer any capability to control the path selection and flow through a storage network between zoned devices. As long as two devices are allowed to communicate as dictated by the zoning configuration, their flows can traverse any path within the SAN as determined by routing protocols within the fabric. The requirement to engineer traffic flows becomes increasingly important as storage networking environments grow to ensure fabric bandwidth is utilized in an optimal manner.


  • Manageability— As zoning is a common distributed service throughout the fabric, it is managed as a common service. Therefore as organizations look to collapse multiple applications on fewer larger SAN fabrics, zoning will still exist as a common distributed service. Zoning is not a service that was designed to have its management partitioned amongst different management groups. Therefore, if an organization were to collapse an HR application infrastructure along with an Engineering application infrastructure onto the same SAN fabric, extensive and critical coordination is required between the application owners to ensure the one common zone set shared by the two application groups doesn't become corrupted or unintentionally altered.



  • Zone Management Security— The zoning service is implemented as a distributed service within a Fibre Channel (FC) storage (SAN) network. A distributed database is synchronized and maintained within all member switches of the storage network. As a distributed service, the zoning database can be updated by any member switch of the fabric. Therefore, although zoning is a security service, its very implementation is relatively insecure. If a member switch within the fabric were to be compromised, fabric-wide zoning configurations could be adversely affected. While new proposals exist within the ANSI T11 community to secure the zoning service, today's zoning implementations have their weaknesses.


  • Accounting— Zoning is a relatively dynamic service that can be modified frequently for a variety of application-oriented reasons. As such, it is exceedingly difficult to account for bandwidth usage amongst application groups that may be defined by their zoning definition. Therefore if a common fabric is built to contain multiple applications, each divided by a zoning definition, it is generally impossible with today's hardware to isolate and account for usage on a per-zone basis.