Zyxel RGS200-12P druckt "% SFP module doesn't support DDMI" für zwei Avago-SFPs
Wir übergeben Industrieschränke mit dem eigenen Monitoring des Kunden obendrauf, lesbares DDMI auf den Uplink-Ports ist also Teil der Abnahmeliste. Auf einem RGS200-12P weigern sich die zwei relevanten Ports, nach dem Aktivieren von DDMI überhaupt irgendetwas zu drucken, obwohl beide Links up sind und weiterleiten.
- Zyxel RGS200-12P, DDMI aktiviert
- Port 1/9: AVAGO ABCU-5740RZ-HP8, 1000BASE-T Kupfer-SFP
- Port 1/11: AVAGO AFBR-5710PZ, 1000BASE-SX
- beide Links up, saubere Zähler auf beiden Seiten
% SFP module doesn't support DDMIWas ich schon gemacht habe:
- DDMI aus- und wieder eingeschaltet, gespeichert, Switch neu geladen
- beide Module neu eingesetzt und in andere Käfige gesteckt - gleiche Antwort auf jedem Port
- geprüft, dass die Links selbst in Ordnung sind, Traffic läuft ohne Fehler durch
Also was ist es: Weigert sich der Switch, Optiken zu lesen, die er nicht verkauft hat, oder haben zwei Avago-Teile tatsächlich keine Diagnostik zum Herausgeben? Ich muss dem Kunden vor der Übergabe die eine oder die andere Antwort geben, kein Schulterzucken.
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 4
Es gibt zwei verschiedene Ursachen, die sich hinter einer Fehlermeldung verstecken.
Der Kupfer-Port ist erwartetes Verhalten. 1000BASE-T-SFPs als Kategorie implementieren keine digitale Diagnostik - es gibt keine optische Leistung zu melden, und diese Teile tragen generell keine Diagnostikseite, 1/9 mit dem ABCU-5740RZ-HP8 wird also nie Temperatur, Spannung oder Leistung zeigen, egal wie DDMI konfiguriert ist. Nichts zu reparieren, nichts zu eskalieren.
Der Faser-Port landet aus einem anderen Grund beim gleichen Ergebnis: Dieses bestimmte Avago-Teil hat keine DDM-/DDMI-Seite in seinem EEPROM. SFF-8472 macht die Diagnostikseite optional, und etliche 1000BASE-SX-Module dieser Generation wurden ohne sie ausgeliefert. Der Switch blockiert hier kein fremdes Modul, er berichtet die Wahrheit - im Modul gibt es nichts zu lesen.
Der Test, der es in fünf Minuten klärt, ist der schon vorgeschlagene: ein als DDM-fähig spezifiziertes Modul im selben Käfig. Ein Zyxel SFP-LX-10-E in einem RGS200-12P druckt den kompletten DDMI-Block, was beweist, dass Switch und Konfiguration in Ordnung sind. Übliche Einschränkung bei diesem Hersteller: Seine erklärte Position ist, dass Drittanbieter-Optiken nicht abgedeckt sind und Paketverlust und Verbindungsprobleme bringen können, wenn Diagnostik also ein Abnahmekriterium ist, "DDM/DOM capable" in die Einkaufsspezifikation schreiben statt zu hoffen.
Wenn sich die Optik in diesem Schrank nicht ändern lässt, diese zwei Ports über Linkstatus und Interface-Zähler überwachen und das so ins Übergabedokument schreiben. Das ist eine ehrliche Antwort, und sie schlägt eine leere DDMI-Seite, die ein Jahr später niemand mehr erklären kann.
Zwei Dinge, die getrennt werden sollten, bevor irgendetwas aufgeschrieben wird. Erstens: Druckt dieser Switch überhaupt für irgendetwas DDMI? Ein Modul ausleihen, von dem bekannt ist, dass es DDM-fähig ist, es in 1/11 stecken und denselben Befehl ausführen. Kommt ein vollständiger Block heraus, ist die Switch-Seite bewiesen, und die zwei Avago-Teile sind die einzige verbleibende Variable.
Zweitens: Das Kupfermodul nicht als Beleg in die eine oder andere Richtung werten, es ist eine eigene Kategorie. Und was sagt das Datenblatt des AFBR-5710PZ eigentlich zu digitaler Diagnostik? Das Teil ist alt genug, dass ich nicht davon ausgehen würde, dass es sie überhaupt hat.
Auf der Werkbank bestätigt. Ein SFP-LX-10-E ausgeliehen, mit derselben Faser in 1/11 gesteckt, und DDMI druckt den vollen Satz - Temperatur, Spannung, Bias-Strom, Tx- und Rx-Power. AFBR-5710PZ wieder eingesetzt, und die Fehlermeldung kehrt sofort zurück. Port 1/9 mit dem Kupfermodul verhält sich genau wie zuvor, was ich jetzt erwarte, statt dem hinterherzujagen.
Der Switch macht also seinen Job, und die Module sind die Antwort. Das geht als Moduleigenschaft ins Übergabedokument, und DDM-Fähigkeit kommt in die Spezifikation für die nächste Charge Optiken. Das hat mir eine Diskussion über einen "kaputten" Switch erspart.
Gut zu wissen, dass sich dieselbe Situation je nach Plattform völlig anders liest, weshalb das immer wieder als Bugreport zurückkommt.
Bei PAN-OS druckt
show transceiver-detail allpro Modul ein Felddiagnostic-monitor:Yesheißt, es implementiert optisches Monitoring,Noheißt, es tut das nicht, und im zweiten Fall wird das Modul trotzdem normal identifiziert, während jeder Diagnostikwert alsN/Azurückkommt. Kein Fehler, nur Leerstellen - viel leichter zu interpretieren als eine Ablehnungsmeldung.Bei einer Nokia 7210 SAS können die fehlenden Werte stattdessen an der Software liegen: Frühe Releases implementieren DDM überhaupt nicht, und die Dokumentation fügt hinzu, dass für Module, die Nokia nicht geliefert hat, die Daten zwar angezeigt werden können, Format und Genauigkeit aber nicht garantiert sind. Drei mögliche Verantwortliche für ein leeres Feld - Modul, Plattform oder Release.
Und manchmal ist es nur das Interface: Bei TP-Link-Switches, die in Omada übernommen wurden, gibt es im Controller keine DDM-Seite, man öffnet dessen Terminal, tippt
enableund führtshow ddm statusaus.