English 
简体中文 
繁體中文 
Русский 
Español 
Deutsch 
Français 
Português 
Italiano 
Türkçe 
Polski 
Nederlands 
日本語 
한국어 
Bahasa Indonesia 
Bahasa Melayu 
العربية 
हिन्दी 
Tiếng Việt 
ภาษาไทย 
বাংলা 
اردو 
Kiswahili 
Oʻzbekcha 
አማርኛ 
فارسی FC-Portdiagnose: Zähler, Slow Drain, SFP-Prüfung
Ein SAN-Switch zählt alles, was auf einem Port schiefgeht, und die Zähler lassen sich sauber physikalischen Ursachen zuordnen – wenn man weiß, welcher Zähler „verschmutzter Steckverbinder" bedeutet und welcher „der Host leert seine Puffer nicht“. Diese Seite listet die Zähler der beiden dominierenden Plattformen auf, worauf jeder hinweist, wie sich Slow-Drain-Überlastung zeigt, und wie man das SFP selbst vom Switch aus ausliest.
Die Zähler
Zähler (Brocade porterrshow) | Cisco-MDS-Äquivalent (show interface fc… counters) | Bedeutung | Weist hin auf |
|---|---|---|---|
| enc_out – Encoding-Fehler außerhalb von Frames | invalid transmission words | fehlerhafte Symbole zwischen Frames | Optik, Kabel, Steckverbinder, Speed-Mismatch – der klassische Physical-Layer-Zähler |
| enc_in – Encoding-Fehler innerhalb von Frames | invalid transmission words / CRC | beschädigte Symbole innerhalb von Frames | gleiche Ursachen, schwerwiegender |
| crc_err | CRC errors | Frame hat CRC-Prüfung nicht bestanden | grenzwertiger Link: verschmutzte Stirnfläche, niedriger Rx, ausfallendes SFP; bei ISLs beide Enden prüfen |
| crc_g_eof | CRC with good EOF | CRC-Fehler, aber Frame wurde korrekt terminiert – entstanden upstream dieses Ports | vorherigen Hop prüfen |
| too_shrt / too_long / bad_eof | frame too short / too long / bad EOF | fehlerhaft geformte Frames | meist eine Folge von enc_in, oder ein defektes Gerät |
| link_fail | link failures | Link ist ausgefallen | Kabel gezogen, SFP-Defekt, Stromversorgung, Reset am fernen Ende |
| loss_sync / loss_sig | sync loss / signal loss | Signal- oder Wortsynchronisation verloren | niedriger Rx, LOS, Flapping – Link-Flapping |
| frjt / fbsy | F_RJT / F_BSY | Fabric hat Frames abgelehnt/als busy markiert | Fabric oder Zoning, nicht Optik |
| disc_c3 – Class-3-Discards | timeout discards | Frames nach Timeout im Switch verworfen | Slow Drain / Überlastung |
| c3timeout tx/rx | — | Richtung der Timeouts | tx-Timeouts: das angeschlossene Gerät ist langsam; rx: ein Upstream-Problem |
| pcs_err (16G+) | — | 64B/66B-PCS-Blockfehler | physikalische Schicht bei 16/32GFC |
| uncor_err (16G+ mit FEC) | FEC uncorrected | FEC konnte den Block nicht korrigieren | Link im Grenzbereich – VDM- & FEC-Metriken |
credit loss (portstatsshow: tim_txcrd_z) | credit loss / tx credit not available | Zeit mit null Transmit-Credits verbracht | Überlastung oder verlorene R_RDYs auf einem verschmutzten Link |
Faustregel: enc_out, crc_err, loss_sync, pcs_err wachsen bei einem physikalischen Problem; disc_c3, c3timeout, tim_txcrd_z wachsen bei einem Überlastungsproblem; frjt/fbsy bei einem Fabric-Problem. Zähler zurücksetzen, warten und auf Raten achten, nicht auf Summen.
Slow Drain
Ein Endgerät, das Credits langsam zurückgibt (ein überlasteter Host, ein ausfallender HBA, ein Speed-Mismatch entlang eines Pfads), hält Frames in Switch-Puffern zurück; diese Frames laufen in einen Timeout und werden verworfen, und die Überlastung breitet sich rückwärts über ISLs zu unbeteiligten Geräten aus. Es ist das schädlichste SAN-Problem, und es wirkt zunächst wie ein zufälliges Performance-Problem.
| Anzeichen | Wo |
|---|---|
| tim_txcrd_z steigt auf einem F_Port | das Gerät an diesem Port gibt Credits langsam zurück |
| disc_c3 / c3timeout tx am selben Port | Frames zu diesem Gerät laufen in Timeout |
| disc_c3 auf ISLs und anderen F_Ports | Überlastung hat sich ausgebreitet |
Bottleneck/MAPS-„latency“-Alarme (Brocade), show logging onboard flow-control request-timeout, Congestion-Drop-/Slow-Drain-Erkennung (Cisco) | Plattform-Tooling |
Abhilfe: das langsame Gerät reparieren oder isolieren (Port Fencing, Quarantäne in einen Virtual Channel niedriger Priorität), Congestion-Drop-Timeouts an Edge-Ports verkürzen, Speed-Sprünge entlang eines Pfads vermeiden, ISL-Überbuchung in vernünftigen Grenzen halten (SAN-Design). Optik ist so gut wie nie die Ursache von Slow Drain – aber ein grenzwertiger Link mit verlorenen R_RDYs kann es vortäuschen, daher zuerst enc_out/crc prüfen.
SFP-Prüfungen vom Switch aus
| Aufgabe | Brocade FOS | Cisco MDS / NX-OS |
|---|---|---|
| SFP-Identität und DDM | sfpshow <port> | show interface fc1/1 transceiver details |
| Portstatus und -geschwindigkeit | portshow <port>, switchshow | show interface fc1/1, show interface brief |
| Fehlerzähler | porterrshow, portstatsshow <port> | show interface fc1/1 counters [detailed] |
| Zähler zurücksetzen | portstatsclear / statsclear | clear counters interface fc1/1 |
| Link-Test | portloopbacktest, D_Port-Diagnose (portcfgdport, portdporttest) | show interface fc1/1 transceiver details + Loopback über Diagnosetools |
| Health-Policy | MAPS (Schwellwerte für CRC, ITW, Credit Loss, SFP-Leistung/-Temperatur) | Port-Monitor-Policies (RX/TX-Leistung, CRC, ITW, Credit Loss) |
sfpshow und die Transceiver-Details zeigen Hersteller, Teilenummer, Seriennummer, Geschwindigkeiten und DDM-Werte mit Schwellwerten – dieselben Bytes, die CodingBox auf der Werkbank ausliest. Beide Plattformen markieren nicht unterstützte Optik; ein Port, der in Mod_Inv, No_Module oder „unsupported transceiver“ hängen bleibt, ist eine Policy-Ablehnung, kein Defekt (Herstellersperre, FC-Optik).
Diagnoseablauf für einen fehlerhaften FC-Port
porterrshow/ Zähler: physikalisch (enc_out, crc, sync) vs. Überlastung (disc_c3, credits) vs. Fabric (rjt/bsy).- SFP-DDM: Rx-Leistung an beiden Enden gegen Klassenfenster prüfen (Typische Werte); Tx-Bias-Trend auf Alterung prüfen.
- Steckverbinder reinigen und inspizieren; Patchkabel tauschen; Zähler erneut in der Rate prüfen.
- Geschwindigkeit: die ausgehandelte Geschwindigkeit auf die niedrigere Generation erzwingen, um zu sehen, ob die Fehler aufhören (ein grenzwertiger 32G-Link kann bei 16G sauber sein) – Speed & Rate.
- D_Port-/Loopback-Test, um Switch, SFP und Kabel zu trennen.
- Bei Überlastung: das langsame Gerät über tim_txcrd_z finden, nicht über den Port, der sich meldet.
In CodingBox
Ein verdächtiges FC-SFP, das aus einem Switch gezogen wurde, lässt sich auf der Werkbank auslesen: Identität, FC-Speed-/Media-Codes, Prüfsummen und Live-DDM auf Check transceiver und DDM. Ein Modul, das auf der Werkbank einwandfrei ist und im Port Fehler zeigt, lenkt den Verdacht auf das Kabel, den Steckverbinder oder das ferne Ende.