TL-SG3428X-M2 (V1): SFP+-Cage 26 bekommt mit keinem TL-SM5310-T Link, Cage 27 flackert dabei weg
Ich betreue ein kleines Büronetz mit einem Netzwerkschrank, und die vier SFP+-Cages an unserem Access-Switch tragen die 10G-Links zum Serverrack. Lief monatelang problemlos, und jetzt ist eine Cage auf einmal weg.
- TP-Link TL-SG3428X-M2 (V1), Firmware 1.20.4 Build 20241104 Rel.40746, in Omada adoptiert
- vier TP-Link TL-SM5310-T 10GBASE-T-Module in den SFP+-Ports 25-28
- CAT6A-Patchkabel, am anderen Ende zwei Server und ein NAS
Port-Status, wie er gerade steht:
port 25 up, 10G
port 26 down, no link LED with any module
port 27 up, 10G, but drops for a moment whenever a cable goes into or out of port 26
port 28 up, 10GWas ich versucht habe:
- die Module durch alle vier Cages rotiert: das Modul aus 26 verlinkt problemlos in 25 und 28, und jedes Modul, das ich in 26 stecke, bleibt dunkel - die Module selbst sind also gesund
- neue Patchkabel, andere Ports am anderen Ende, keine Änderung
- Switch-Neustart, Port deaktiviert/aktiviert, keine Änderung
Den Teil, den ich mir nicht erklären kann: Port 27 zuckt, obwohl ich nur an Port 26 etwas anfasse. Ist Cage 26 tot und ein Fall für RMA, oder gibt es noch etwas anderes, das ich zuerst ausschließen sollte?
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 6
Das ist eine Firmware-Regression in 1.20.4 Build 20241104, keine tote Hardware. Das Muster, das du beschreibst - eine SFP+-Cage, die mit nachweislich funktionierenden Modulen nie angeht, plus ein Nachbar, der zuckt, sobald man die tote Cage anfasst - ist genau das, was dieser Build mit TL-SM5310-T-Kupfermodulen anstellt.
Switch auf das vorherige Release zurückstufen, und die Ports sind wieder da. In der Praxis:
TP-Links eigene Leute haben bestätigt, dass in diesem Release bei Omada-Switches unter Controller v5.14 etwas nicht stimmt, sagten, man schaue sich das an, und rieten, vorerst auf der älteren Firmware zu bleiben. Also keinen Support-Case auf die Hardware verschwenden, sondern auf die Build-Nummer.
Wenn ein Downgrade wirklich nicht geht, bleibt als Workaround nur, mit den drei funktionierenden Cages zu leben und Port 26 leer zu lassen. Das ist keine Lösung, nur ein Weg, bis zu einem korrigierten Release im Betrieb zu bleiben.
Bevor du ein RMA-Formular ausfüllst: Wann hat das angefangen, und hat der Switch etwa zur gleichen Zeit ein Firmware-Update bekommen? 1.20.4 Build 20241104 ist ziemlich frisch, und der Controller schiebt ohne Weiteres von selbst ein neues Image nach, wenn automatische Upgrades an geblieben sind.
Auch klären: Zuckt Port 27 nur, wenn in 26 ein Modul steckt, oder auch wenn 26 leer ist? Eine tote Cage bringt normalerweise keinen Nachbarn zum Flattern. Das riecht viel mehr nach der Software hinter den Ports als nach einer gerissenen Lötstelle.
Gleicher Switch, gleicher Build hier, du bist also nicht allein. Port 25 war in Ordnung, Port 26 gab mit jedem Modul, das ich besitze, keine Link-LED, und 27 und 28 kamen und gingen - einer von beiden versorgt einen EAP783, jeder Drop war also gut sichtbar. Ich bin genau durch dasselbe Modul-Tausch-Ritual gegangen und habe mir eine tote Cage eingeredet.
Es war nicht die Cage. Die Box hatte kurz vor Beginn des Problems ein Firmware-Update bekommen, und die Rückkehr zum vorherigen Image brachte alle vier SFP+-Ports zurück. Update-Verlauf prüfen, bevor irgendwas irgendwohin eingeschickt wird.
Bestätigt, und es ist mir unangenehm, wie nah ich dran war, den Switch einzuschicken. Der Update-Verlauf zeigt 1.20.4 Build 20241104 ein paar Tage bevor die Ports verrückt spielten, und ich habe es nie von Hand gestartet, es kam also von selbst rein.
Auf das vorherige Release zurückgestuft, neu adoptiert, und alle vier Cages sind auf 10G oben, Port 26 eingeschlossen. Port 27 zuckt nicht mehr, wenn ich an 26 arbeite. Automatische Upgrades sind jetzt aus, und das alte Image liegt auf dem Fileserver neben dem Config-Backup.
Fürs Archiv: Dieselbe Familie hat noch eine Firmware-Falle, die man kennen sollte. An einem TL-SX3008F (V1) mit einem SM5310-T(UN) vor einer Workstation ließen die Firmwares 1.20.2 und 1.20.3 den SFP+-Port tot liegen, sobald der PC in den Schlafmodus ging oder heruntergefahren wurde. Das Modul in eine freie Cage zu stecken funktionierte genau einmal pro Cage, und sobald alle Cages durch waren, brachte nur noch ein Switch-Neustart die Ports zurück. Den Port fest auf 1G zu stellen umging es, zum Preis der Geschwindigkeit, für die man bezahlt hat.
Ein anderer Besitzer hatte dasselbe mit RJ45-Modulen von 10Gtek (ASF-10G2-T), Wiitek und Xicom hinter einem Iocrest-AQC113-Adapter. Das Downgrade auf 1.20.0 Build 20231011 Rel.42220 hat es für beide erledigt. Anderes Symptom, gleiche Lehre: Der Umgang mit Kupfer-SFP+ in diesen Builds ist, wo die Bugs sitzen.
Noch etwas für den Hinterkopf bei dieser Switch-Reihe: Ein untätiges Modul kann mehr kosten als nur einen Port. An einem TL-SX3016F mit 1.0.0 Build 20210730 Rel.65115 lag die CPU bei 87-89 % ganz ohne Traffic und setzte alle drei Minuten eine Zeile CPU RISING THRESHOLD ins Log.
Die Last folgte der Anzahl gesteckter Module - ein Modul 0-1 %, zwei 73-76 %, drei oder mehr 88-90 % - und lief auf Mellanox MFM1T02A-SR-Module hinaus, bei denen Faser steckte, am anderen Ende aber nichts leuchtete, der Link also unten blieb. Die gegen Ubiquiti UF-MM-10G zu tauschen hielt die CPU niedrig, egal was der Port gerade tat, und die ungenutzten Module einfach zu ziehen hat es genauso behoben. TP-Links eigene Antwort war, dass ein Modul mit totem Link den Chipsatz einfach Leistung kostet und die Last zurückgeht, sobald der Port sauber verlinkt ist. Unerklärt bleibt dabei die unangenehme Hälfte: Marke wechseln, Modul genauso untätig lassen, und die CPU bleibt ruhig. Also, sobald die ältere Firmware wieder läuft, auch einen Blick auf die CPU-Grafik werfen.