The zoning service in Fibre Channel (FC) makes security possible by ensuring that end devices are able to communicate only with the set of devices explicitly permitted. FC Zoning was the topic at our recent FCIA webcast “Fibre Channel Zoning Fundamentals: All You Need to Know.” At this presentation, our expert speakers AJ Casamento, Rupin Mohan, Craig Carlson and Kiran Ranabhor clearly defined FC zoning fundamentals with explanations on what zoning is, how it works, and different types of zones, as well as some best practices when using zoning. If you missed the live session, you can watch it on-demand and you can read our experts’ answers to the questions the attendees asked right here.
Q: What evidence should I have to make sure that my provider has actual proper zoning?
A: Any vendor that supports Fibre Channel standards should have a complete zoning implementation.
Q: In mainframe FICON environments, we usually use hard zoning. 1) the device’s link address should not be changed, 2) we usually have a zone with ALL ports in the logical switch, even if they are not currently in use. In the rare case of a device port failure, we can use portswap to move the link address and the zone does not have to change. It is far too much work to set up aliases for WWNs that do not move (often for 5 years, the length of the life of the box). Do you see the same?
A: We agree with both of your observations that in the FICON mainframe environment: 1) there is a requirement that switches support ‘static’ link address assignment, and 2) use of ‘one large zone’ is a common practice. In FICON environments access control between logical host instances and storage devices is governed by the mainframe I/O Configuration Dataset, and hence reliance on fabric zoning for such access control is not required in the same way as it is in distributed environments. However, reflecting the I/O configuration in the zone definition can also provide a second level of access control for environments that serve multiple, competing clients (i.e. often referred to as the “Coke/Pepsi” example). Also, for those environments that mix FICON and FCP solutions in their fabric, creating a “FICON zone” that is separate from the “distributed zones” is helpful in reducing access control errors. There are also other possible benefits of configuring smaller zones even in a FICON environment, such as a reduction in the amount of Registered State Change Notifications presented to ports not affected by the State Change event.
Q: It used to be that all members in a zone had to be in the same order or else a switch with its own zones could not merge. Has there been any standards update to fix this?
A: It seems like this is an issue specific to your vendor and not related to standards. We recommend you contact your vendor’s support team.
Q: We had 2 existing fabrics that had their own zones and we had to merge them. We added the other fabric’s zones into each with aliases, names etc being the same, but because they were not in the same ORDER they were segmented. It took a long time to figure this out.
A: Please see previous answer.
Q: If I understand this correctly, for target driven zoning the storage server must have explicit support in its software or firmware. How widespread is this support at this point?
A: Target driven zoning support requires capabilities in both the fabric and storage devices. Support is vendor specific.
