Information About San Congestion Caused By Over Utilization; Information About Congestion Detection, Avoidance, And Isolation; Information About Congestion Detection - Cisco MDS 9000 Series Configuration Manual

Congestion Detection, Avoidance, and Isolation

Information About SAN Congestion Caused by Over Utilization

Small Computer Systems Interface (SCSI) host devices request data via various SCSI read commands. These
SCSI read commands contain a data length field, which is the amount of data requested in the specific read
request. Likewise, SCSI targets request data via the SCSI Xfr_rdy command and the amount of data requested
is contained in the burst size. The rate of these read or Xfr_rdy requests coupled with the amount of data
requested can result in more data flowing to the specific end device than its link can support at a given time.
This is compounded by speed mismatches, hosts zoned to multiple targets, and targets zoned to multiple hosts.
The switch infrastructure (SAN) can buffer some of this excess request, but if the rate of requests is continuous
then the queues of a switch can fill and Fibre Channel or FCoE back pressure can result. This back pressure
is done by withholding BB_credits on Fibre Channel and by sending PFC pauses on FCoE. The resulting
effects to the SAN can look identical to slow drain, but the root cause is much different. The main mechanism
for detecting congestion caused by over utilization is by monitoring the Tx data rate of the end device ports.
Port monitor can be used to detect congestion caused by over utilization.

Information About Congestion Detection, Avoidance, and Isolation

Information About Congestion Detection

The following features are used to detect congestion on all slow-drain levels on Cisco MDS switches:
• All Slow-Drain Levels
milliseconds. Also, the frames that are dropped when the no-credit-drop (Fibre Channel) or pause-drop
threshold is reached are also marked as timeout drops.
• Credit Loss Recovery (Fibre Channel only): Credit Loss Recovery is when a port is at zero remaining
Tx credit count continuously for 1 second (F or NP port) or 1.5 seconds (E port). When this condition
occurs a Link Credit Reset Fibre Channel primitive is sent to reinitialize the credits (both directions)
on the link. If a Link Credit Reset Response (LRR) is returned, the link resumes normal operation.
If an LRR is not returned, the link fails and must completely reinitialize.
• Link Credit Reset (LR) (Fibre Channel only): LR is a Fibre Channel primitive that is used at link
initialization, as well as, to reinitialize BB_credits in both directions on an active link when credits
are lost.
• Link Credit Reset Response (LRR) (Fibre Channel only): LRR is a Fibre Channel primitive that is
a positive response to an LR.
Display of credits agreed to along with the remaining credits on a port (Fibre Channel only)—The credits
that are agreed to in both directions in FLOGI (F ports) and Exchange Link Parameters (ELP) for ISLs
are displayed via the show interface command. Also, the instantaneous value of the remaining credits
is also displayed in the output of the show interface command. The credits agreed to is static and
unchanging information, at least when the link is up. However, the remaining credit values are constantly
changing because each time a frame is transmitted, the Tx remaining count is decremented, and each
time a credit is received, the Tx remaining count is incremented. When the remaining credits approach
or reach zero, it indicates congestion on that port.
The following example displays the transmitted and received credits information on an F port:
switch# show interface fc9/16
Information About SAN Congestion Caused by Over Utilization
Cisco MDS 9000 Series Interfaces Configuration Guide, Release 8.x
137