HP StorageWorks 2/16V HP StorageWorks Fabric OS 5.2.x administrator guide (569 - Page 216

Configuring LSANs and zoning An LSAN consists of zones in two or more edge or backbone fabrics that contain the same device(s). LSANs essentially provide selective device connectivity between fabrics without forcing you to merge those fabrics. FC routers provide multiple mechanisms to manage interfabric device connectivity through extensions to existing switch management interfaces. You can define and manage LSANs using Advanced Zoning or Fabric Manager. Use of administrative domains with LSAN Zones and FCR You can create LSAN zones as a physical fabric administrator or as an individual administrative domain (AD) administrator. The LSAN zone can be part of root zone database or the AD zone database. FCR harvests the LSAN zones from all administrative domains. If both edge fabrics have the matching LSAN zones and both devices are online, FCR triggers a device import. To support legacy applications, WWNs are reported based on the administrative domain context. As a result, you must not use the NAA field in the WWN to detect an FC Router. LSAN zone enforcement in the local fabric occurs only if the administration domain member list contains both of the devices (local and imported device) specified in the LSAN zone. For more information, see "Managing administrative domains" on page 127. Defining and naming zones Zones are defined locally. Names and memberships, with the exception of hosts and targets exported from one fabric to another, do not need to be coordinated with other fabrics. For example, in Figure 10, when the zones for Edge SAN 1 are defined, you do not need to consider the zones in Edge SAN 2, and vice versa. Zones that contain hosts and targets that are shared between the two fabrics need to be explicitly coordinated. Although an LSAN is managed using the same tools as any other zone on the edge fabric, two behaviors distinguish an LSAN from a conventional zone: • A required naming convention. The name of an LSAN begins with the prefix "LSAN_". The LSAN name is letter case insensitive; for example, lsan_ is equivalent to LSAN_, Lsan_, and so on. • Members must be identified by their port WWN because PIDs are not necessarily unique across fabrics. The names of the zones need not be explicitly the same, and membership lists of the zones need not be in the same order. LSAN Zones and fabric-to-fabric communications Because zoning is enforced by all involved fabrics, any communication from one fabric to another must be allowed by the zoning setup on both fabrics. If the SANs are under separate administrative control, then separate administrators maintain access control. NOTE: If you are managing other switches in a fabric, it is recommended that you run the defZone --show command on your Fabric OS v5.1.0 or later switches as a precaution. Default zoning behavior in Fabric OS v5.1.0 and later operates differently compared to other Fabric OS versions (versions 2.x, 3.x 4.x and 5.0.1). For example, if you issue the defZone --noaccess command on a Fabric OS v5.1.0 or later switch, then default zoning configurations will be created on each switch in the fabric (v2.x, v3.x, v4.x or v5.0.1 switches). Fabric OS v5.1.0 or later switches do not indicate that a default configuration is enabled when you use the cfgShow or cfgActvShow commands. For more information about default zoning, "Configuring LSANs and zoning" on page -216. The following example procedure illustrates how LSANs control which devices can communicate with each another. The example procedure shows the creation of two LSANs (called lsan_zone_fabric75 and lsan_zone_fabric2), which involve the following devices: • Switch1 and the host are in fabric75 • Switch2, Target A, and Target B are in fabric2 • Switch1 is connected to the 4/256 SAN Director with a B-Series MP Router blade using an EX_Port or VEX_Port 216 Using the FC-FC routing service