Interesting Flow Vision bug

Ok, truth be told it is not a Flow Vision bug but in FOS 9.0.0 it is flagged as such under defect 653188.

As you know Flow Vision can be configured to monitor certain traffic flows. SCSI commands such as read, write, xfer-rdy,, status etc can be viewed with the flow –show command.

Output will look something like:

Sydney_ILAB_X6_43_TEST:FID43:admin> flow –show sys_mon_all_fports
========================================================================================================================
Name : sys_mon_all_fports Features: mon(Activated) noConfig: Off
Definition: IngrPort(*),SrcDev(*),DstDev(*)

Flow Monitor (Activated):
Monitor time: | Tue Dec 29 18:35:45 AEDT 2020 |———————————————————
——————————————————————————————————————————
|Ingr(*)|SID(*)|DID(*)| Rx Frames Count | Rx Frames per Sec. | Rx Bytes Count | Rx Throughput(Bps) | Avg Rx Frm Sz(Bytes)|
——————————————————————————————————————————
|101 |01e680|02ec40| 91 | 7 | 20.57k | 1.65k | 232 |
|98 |01e740|02e640| 74 | 4 | 16.16k | 1.01k | 224 |
|99 |01e700|01eb40| 54 | 3 | 4.00k | 303 | 76 |

=============

—————————————————————————————————————————
|SID(*)|DID(*)| I/O Count | I/O Per Sec.(IOPS) | I/O bytes Transferred | I/O bytes Per Sec. |
| | | Reads / Writes / Total | Reads / Writes / Total | Reads / Writes / Total | Reads / Writes / Total |
—————————————————————————————————————————
|01e680|02ec40| 22 / 27 / 49 | 2 / 2 / 4 | 1.44M / 13.82k / 1.45M |152.76k / 1.27k /154.04k |
|01e740|02e640| 23 / 18 / 41 | 1 / 1 / 2 | 1.50M / 9.21k / 1.51M |109.11k / 767 /109.88k |
|01e700|01eb40| / / | / / | / / | / / |
|01eec0|02e680| / 13 / 13 | / 1 / 1 | /294.91k /294.91k | / 32.39k / 32.39k |
|01ef00|02e6c0| / 14 / 14 | / 1 / 1 | /319.48k /319.48k | / 35.12k / 35.12k |

(pardon the layout. WordPress isn’t really cooperating here.)

As it turned out when you have an NVMe adapter or array connected to a port and monitor for these same values you will see that these counters also accumulate. This should not happen as basically NVMe is a different protocol and should be handled, or at displayed,  differently.

As you may know from one of my previous posts the frame header has a field that contains the frame type. That field contains the indicator of the protocol being used for that frame if the R_CTL field indicates a normal data frame (not 0x52 as below). For SCSI operations that field contains 0x08 and for FICON it can be 0x18, 0xB or 0x1C.

According to the FC-LS-5 specifications NVMEoFC should use 0x28 but it turns out that some vendors have reused the 0x08 value and thus it may be somewhat difficult to differentiate between NVMe and SCSI traffic when you use flow-vision and monitor.

Again as my mantra always shows: Keep your HBA drivers/firmware as well as array microcode up-to-date as these are the real culprits that may throw you off track when looking at the Flow Vision output.

From a support perspective this is also a major “pain-in-the-behind” when FC traces need to be looked at as the analysis software is thrown off-guard a bit and we would manually need to adjust these values. Besides incurring a lot of frustration it also does cost a lot of time and that will not help you either.

Hope this helps.

Regards,

Erwin

Print Friendly, PDF & Email

Subscribe to our newsletter to receive updates on products, services and general information around Linux, Storage and Cybersecurity.

The Cybersecurity option is an OPT-OUT selection due to the importance of the category. Modify your choice if needed.

Select list(s):