Zyxel XS1930-10 verlinkt einen 5-m-10Gtek-DAC nicht, der an einem XGS1250-12 noch funktioniert
Kleines Heim-Rack, ein Server und ein Switch. Ein XGS1250-12 wurde durch einen XS1930-10 ersetzt, und das Einzige, was den Tausch nicht überlebt hat, ist der Server-Uplink.
- Zyxel XS1930-10, SFP+-Port mit Media-Type auf DAC10G gesetzt
- Asus XG-C100F im Server
- 10Gtek CAB-10GSFP-P5M, 5 m passives Twinax, AWG26
- ein zweiter 10Gtek-DAC, 1,5 m, als Ersatz in der Schublade
Der Switch-Port bleibt unten, während die NIC überzeugt ist, einen Link zu haben:
XS1930-10, SFP+ port: media type DAC10G link status Down
server, XG-C100F:
Speed: 10000Mb/s
Duplex: Full
Link detected: yesWas schon versucht wurde:
- der 1,5-m-10Gtek-DAC im selben Port, derselben NIC - verlinkt sofort
- Media-Type explizit auf DAC10G statt auf auto belassen - keine Änderung
- das 5-m-Kabel zurück an den XGS1250-12 - funktioniert dort weiter, das Kabel ist also nicht tot
Sind 5 m passives AWG26 für diesen Switch einfach zu viel, oder gibt es am XS1930-10 eine Porteinstellung, die noch fehlt?
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
Rechne damit, dass das Loopback hochkommt und der Link zur NIC trotzdem unten bleibt - das ist bei diesem Fall die übliche Form.
Der Media-Type ist eine Voraussetzung, keine Lösung. Auf auto belassen neigt ein SFP+-Port dazu, mit einem DAC gar nicht erst zu verlinken, DAC10G muss also gesetzt sein. Sobald das gesetzt ist und der Port trotzdem unten bleibt, sind die Einstellungen ausgereizt, und man ist beim physikalischen Budget des Ports.
Fünf Meter passives AWG26 sind für diese Switch-Klasse eine Menge Kupferdämpfung. Zyxels abschließende Position zum XS1930-10 lautet, dass eine so lange passive Strecke zu viel Signal für ihre SerDes verliert und dass alles jenseits von etwa 3 m auf Faser gehört; die Garantie ging ohnehin nie über die eigenen gebrandeten Module und DAC-Kabel hinaus. Das erklärt auch die andere Beobachtung - dass dasselbe Kabel am XGS1250-12 funktioniert, beweist beim XS1930-10 gar nichts, denn eine Twinax-Länge, die sich in der Cage eines Modells brav verhält, sagt sehr wenig über das nächste Modell, selbst innerhalb der Range eines einzigen Herstellers.
Praktischer Weg: das 1,5-m-Kabel für diesen Link behalten, und falls die 5-m-Distanz wirklich gebraucht wird, SR-Optik und ein Duplex-LC-Patch statt Twinax einsetzen. Wer es aktenkundig haben will: Media-Type setzen, bestätigen, dass es weiter fehlschlägt, und ein Support-Ticket öffnen - beim XGS1930-52HP ist das genau der Weg, den die eigene FAQ für einen DAC angibt, der nach gesetztem Media-Type weiter unten bleibt, und das läuft über das Nebula Control Center, hier wäre dieselbe Behandlung zu erwarten. Auf ein Firmware-Release zu warten, das die Dämpfung eines Kabels ändert, würde ich nicht.
Bevor irgendwas über das Kabel entschieden wird, es loopen: beide Enden des 5-m-DAC in die zwei SFP+-Ports des XS1930-10 selbst, Media-Type DAC10G auf beiden. Kommt es im Loopback hoch, sind Kabel und Cages in Ordnung, und es liegt ein Paarungsproblem vor, kein Kabelproblem.
Zwei Dinge fehlen noch. Ist der Port auf 10G Vollduplex fest eingestellt, oder bleibt er nach dem Setzen des Media-Type auf auto? Und worauf stand der Port am XGS1250-12, als dasselbe Kabel dort funktionierte - auto oder DAC? Falls auto, den vor dem Vergleich der beiden Switches auf DAC umstellen: Der Media-Type ist auf beiden Boxen eine Pro-Port-Einstellung, ein Test, bei dem einer der beiden auf auto steht, ist also nicht wirklich derselbe Test.
Anderer Hersteller, gleiche Kategorie Überraschung. Ein SFP+-DAC, der zwischen einem TL-SG2210MP, wo die Cage ein schlichter 1G-SFP ist, und einem TL-SX3008F auf Firmware 1.2 nicht verlinken wollte. Beide Ports fest auf 1000 Mbps Vollduplex zu stellen änderte nichts, und dasselbe Kabel war zwischen zwei 10G-fähigen Boxen problemlos.
Die Erklärung war dort Codierung statt Länge: Reichlich passive SFP+-Assemblies bewerben nur 10G und sonst nichts, ganz ohne 1000BASE-X-Fallback, sie liegen also dunkel in einer 1G-Cage, während ein Dual-Rate-Kabel verlinkt. Jemand in derselben Diskussion hatte einen Unifi-SFP+-DAC zwischen einem ER8411 und einem SG2428P laufen, völlig ohne Drama.
Nicht der vorliegende Fall, da hier beide Enden 10G sind. Der Punkt ist, dass 'funktioniert dort drüben' bei Twinax deutlich weniger zählt als bei Faser.
Gut zu wissen, wie der Host überhaupt etwas über ein Twinax-Kabel erfährt: Ein passiver DAC trägt seine Länge und seine Dämpfung im EEPROM, gemäß SFF-8472, und der Port steuert die Cage nach dem, was die Assembly behauptet. Gemessen wird auf der Leitung nichts. Das ist ein großer Teil davon, warum sich ein 5-m-Kabel an zwei Switches derselben Marke unterschiedlich verhält - unterschiedliche Empfänger, unterschiedliche Toleranz dafür, was diese Behauptung an Dämpfung tatsächlich kostet.
Auch nicht auf Twinax zählen, wenn ein langsamerer Link als die Kabelrate gebraucht wird. An einem Netgate 6100 gibt ein DAC einen 10G-Link und nichts Langsameres, ohne jede Möglichkeit, ihn auf 1 Gbps herunterzuziehen; das Interface kommt schlicht als 10Gbase-Twinax Vollduplex hoch. Hängt am anderen Ende also etwas fest auf Gigabit, kommt man mit Twinax nicht hin, und es geht zurück zu 1G-Optik. Kurze Kabel sind bei dieser Marke generell unauffällig - ein CAB-10GSFP-P1M und ein Ubiquiti UACC-DAC-SFP10 laufen hier beide mit 10 GbE in einen USW-Enterprise-8-PoE. Die Länge ist die Variable, die zuerst getestet wird, nicht die Marke.