HP StorageWorks Fabric OS 6.x administrator guide (5697-7344, March 2008)

324 Troubleshooting
Recognizing port initialization and FCP auto discovery process
The steps in the port initialization process represent a protocol used to discover the type of connected
device and establish the port type. The possible port types are as follows:
• U_Port—Universal FC port. The base Fibre Channel port type and all unidentified, or uninitiated ports
are listed as U_Ports.
• FL_Port—Fabric Loop port. Connects both public and private loop devices.
• G_Port—Generic port. Acts as a transition port for non-loop fabric capable devices (E_Port / F_Port).
• E_Port—Expansion port. Assigned to ISL links.
• F_Port—Fabric port. Assigned to fabric capable devices.
• EX_Port—A type of E_Port. It connects a Fibre Channel router to an edge fabric. From the point of view
of a switch in an edge fabric, an EX_Port appears as a normal E_Port. It follows applicable Fibre
Channel standards as other E_Ports. However, the router terminates EX_Ports rather than allowing
different fabrics to merge as would happen on a switch with regular E_Ports.
• VE_Port—Like an E_Port. However, it terminates at the switch and does not propagate fabric services or
routing topology information from one edge fabric to another.
• VEX_Port—A type of VE_Port. It connects a Fibre Channel router to an edge fabric. From the point of
view of a switch in an edge fabric, an VEX_Port appears as a normal VE_Port. It follows the same Fibre
Channel protocol as other VE_Ports. However, the router terminates VEX_Ports rather than allowing
different fabrics to merge as would happen on a switch with regular VE_Ports.
The FCP auto discovery process enables private storage devices that accept PRLI to communicate in a
fabric.
If device probing is enabled, the embedded port PLOGIs and attempts a PRLI into the device to retrieve
information to enter into the name server. This enables private devices that do not FLOGI but accept PRLI to
be entered in the name server and receive full fabric citizenship. Private hosts require the QuickLoop
feature which is not available in Fabric OS 4.0.0 and later.
A fabric-capable device will implicitly register information with name server during a FLOGI. These devices
will typically register information with the name server before querying for a device list. The embedded
port will still PLOGI and attempt PRLI with these devices.
You can view the name server table in Web Tools by clicking Name Server in the fabric toolbar. See the
Web Tools Administrator’s Guide for more information.
Using port mirroring
Port mirroring lets you configure a switch port to connect to a port to mirror a specific source port and
destination port traffic passing though any switch port. This is a useful way to troubleshoot without bringing
down the host and destination links to insert an inline analyzer.
Port mirroring captures traffic between two devices. It mirrors only the frames containing the SID/DID to the
mirror port. Because of the way it handles mirroring, a single mirror port can mirror multiple mirror
connections. This also means that the port cannot exceed the maximum bandwidth of the mirror port.
Attempts to mirror more traffic than available bandwidth result in the port mirror throttling the SID/DID
traffic so that traffic does not exceed the maximum available bandwidth.
Port mirroring is supported between VE_Ports (VE_Port to VE_Port) with FCIP and no routing. The mirror port
can be any port located on the same switch as the source identifier (SID).
Use port mirroring to detect missing frames, which may occur with zoning issues or hold timeouts, capture
protocol errors, and capture ULP traffic (SCSI/FICON). This feature cannot be used on embedded switch
traffic.
Port mirroring is only available using the FOS 5.2.0 or later CLI and is not available through Web Tools.
For a complete list of port mirroring commands, see the Fabric OS Command Reference.
To ensure proper failover in HA configurations, both the active and the standby control processors (CP)
must have firmware version 5.2.0 or later installed and running. If the OS on the standby CP does not
support mirroring, failing over the standby CP could cause the HA failover to fail.