Background info
Current-generation Fibre Channel adapters expose SFP transceiver diagnostics, which are readable from the OS.
On IBM i, the fcioa -sfpinfo macro in SST/DST already surfaces this data.
With the November 2025 GA of V7R5 TR7 and V7R6 TR1, IBM i extended this further: using the RDP ELS, it can now also retrieve SFP data from the remote ports on the other end of the fibre link giving administrators a full end-to-end view of link health and actionable insight from a single command.
Example 1: Detailed information on the SFP on a specific local adapter with resource name DC08:
IOA DC08 Port 0. Supported speed: 16Gb 32Gb 64Gb
Vendor: AVAGO
Part number: AFBR-57H5MZ-QM1 Revision: 0001
Serial number: ########### Date (YY-MM-DD): 22-08-16
=============================================================================|
Diagnostic| Temp(C) | Volt(V) | Bias(mA) | TxPwr(mW/dBm) | RxPwr(mW/dBm) |
=============================================================================|
Measured | 36.23 | 3.2867 | 6.874 | 1.1137/ 0.4 | 0.8927/ -0.4 |
----------+----------+----------+----------+----------------+----------------|
LowAlarm | -5.00 | 2.9700 | 2.000 | 0.0831/-10.8 | 0.0446/-13.5 |
LowWarning| 0.00 | 3.1349 | 3.000 | 0.1659/ -7.8 | 0.0891/-10.5 |
HiWarning | 75.00 | 3.4649 | 8.500 | 2.5118/ 3.9 | 2.5118/ 3.9 |
HiAlarm | 80.00 | 3.6300 | 10.000 | 5.0117/ 6.9 | 5.0117/ 6.9 |
=============================================================================|
Example 2: Showing Attached "Remote" port Information
Attached port:
Vendor: BROCADE Supported speed: 16Gb 32Gb *64Gb
Part number: ############# Revision: B
Serial number: ################ Date (YY-MM-DD): 21-03-23
=============================================================================|
Diagnostic| Temp(C) | Volt(V) | Bias(mA) | TxPwr(mW/dBm) | RxPwr(mW/dBm) |
=============================================================================|
Measured | 39.00 | 3.2931 | 6.952 | 0.9006/ -0.4 | 1.0559/ 0.2 |
----------+----------+----------+----------+----------------+----------------|
LowAlarm | -5.00 | 2.9700 | 2.000 | 0.0831/-10.8 | 0.0446/-13.5 |
LowWarning| 0.00 | 3.1349 | 3.000 | 0.1659/ -7.8 | 0.0891/-10.5 |
HiWarning | 75.00 | 3.4649 | 8.500 | 2.5118/ 3.9 | 2.5118/ 3.9 |
HiAlarm | 80.00 | 3.6300 | 10.000 | 5.0117/ 6.9 | 5.0117/ 6.9 |
=============================================================================|
For comparison, AIX and VIOS OS do not yet have equivalent capability.
Administrators on those platforms are limited to server-side adapter metrics, with no visibility into the remote attached port diagnostics data.
In addition, the current statistics retrieved by the fcstat (Read SFP command) on AIX/ VIOS contain SFP threshold ranges aligned with SFF specifications which are too broad and do not provide actionable insight:
FC SFP Information
Vendor Name: FINISAR CORP.
Vendor OUI: 00009065
Vendor PN: FTLF8532P5BCV-QM
Temperature: 35.246 C [Range -128 C - +128 C]
Voltage: 3.377 V [Range 0 V - +6.55 V]
TX Bias: 6.120 mA [Range 0 mA - 131 mA]
TX Power: -0.2738 dBm [Range -40 dBm - +8.2 dBm]
0.9389 mW [Range 0 mW - 6.5535 mW]
RX Power: 0.0299 dBm [Range -40 dBm - +8.2 dBm]
1.0069 mW [Range 0 mW - 6.5535 mW ]
Problem
FC link-related field issues are a recurring source of multi-team escalations.
When FC link degrades, SAN, Power Systems, AIX, VIOS and Storage support teams each collect diagnostic data independently from respective endpoints.
Because there is no unified view, correlating data across teams is time-consuming, and identifying which part on the SAN is at fault often takes far longer than it should, driving up support costs, operational overhead and time to resolution.
Without a combined view and continuous collection of SFP metrics, early warning and alarm signals go undetected until the link fails in production.
There is no practical path today for an AIX or VIOS administrator to diagnose end-to-end fibre link health without engaging various support and infrastructure teams.
Idea
This proposal is to evaluate the implementation of RDP-based SFP diagnostic capability on AIX and VIOS, similar to the existing IBM i feature. This includes:
Retrieval of SFP diagnostic data from both the local FC adapter port and the remote attached ports via RDP ELS
Coverage of all key diagnostic parameters for both local and remote SFPs: vital product data, temperature, voltage, bias, Tx/Rx optical power, etc. and the full set of alarm and warning thresholds (LowAlarm, LowWarning, HiWarning, HiAlarm).
AIX command that enables : safe and continuous capture of RDP metrics: local and remote SFP statistics and actionable thresholds notification; a summary of all SFP measurements on all eligible adapters on a partition.
Future integration with Call Home service for the managed system.
Expected Benefits
Making RDP data available on AIX and VIOS enables proactive detection of SFP degradation before a link fails, reduces dependence on multi-team coordination for diagnosis and opens a path to automated alerting and self-service.
Yes, it's a very important hint to see actual connectivity status in advance we got. I've already used "emfc_power" utility for VIOS/AIX for each fiber channel component on VIOS.
I approve!
Good idea, such tool would have been helpful with our latest FC issue at customer.
One additional consideration would be to make the SFP threshold evaluation specific to the transceiver/adapter type and the negotiated FC link speed. Different transceivers and link speeds may have different applicable operating ranges, so using the appropriate thresholds would make the signal strength/quality assessment more accurate and help avoid misleading alerts.
Yes, this would be very helpful for one of our big customers.
Great idea. This puts the transport layer monitoring back into the hands of our capable end customers AIX / VIOS administrators.
Its good idea and very helpful.
Yes another good idea, and very useful.
I definitely agree this is useful.
Very good and useful idea, I support it entirely.
For a better overview of signal strength/quality on the host (VIOS/AIX) side it will be necessary to specify SFP threshold ranges based on the adapter type, but also on the link speed negotiated with the switch. This should be taken into consideration for that idea as well.
Indeed, this will be extremely useful.