HP AE370A - Brocade 4Gb SAN Switch 4/12, Administrator'S Manual

Page: 216 / 447

216 Using the FC-FC routing service
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