TL-SG3428X-M2 (V1): lo slot SFP+ 26 non fa link con nessun TL-SM5310-T, il 27 sfarfalla insieme a lui
Gestisco la rete di un piccolo ufficio, un solo armadio switch, e i quattro slot SFP+ sullo switch di accesso portano i link a 10G verso il rack dei server. Ha funzionato per mesi senza darmi pensieri, e adesso uno slot è semplicemente sparito.
- TP-Link TL-SG3428X-M2 (V1), firmware 1.20.4 Build 20241104 Rel.40746, adottato in Omada
- quattro moduli TP-Link TL-SM5310-T 10GBASE-T nelle porte SFP+ 25-28
- cavo patch CAT6A, agli altri capi due server e un NAS
Stato delle porte in questo momento:
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, 10GCosa ho già provato:
- ho fatto ruotare i moduli tra tutti e quattro gli slot: il modulo dello slot 26 fa link senza problemi nel 25 e nel 28, e ogni modulo che metto nel 26 resta spento, quindi i moduli in sé sono sani
- nuovi cavi patch, porte remote diverse, nessun cambiamento
- riavvio dello switch, disable/enable della porta, nessun cambiamento
La parte che non riesco a spiegarmi è che la porta 27 sfarfalla quando l'unica cosa che tocco è la porta 26. Lo slot 26 è morto e vale la pena aprire un RMA, o c'è qualcos'altro da escludere prima?
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
Questa è una regressione del firmware nella 1.20.4 Build 20241104, non hardware morto. Lo schema che descrivi - uno slot SFP+ che non si accende mai con moduli sani e testati, più un vicino che sfarfalla quando disturbi quello morto - è esattamente quello che fa quella build con i moduli in rame TL-SM5310-T.
Riporta lo switch alla release precedente e le porte tornano. In pratica:
Lo stesso personale TP-Link ha riconosciuto che c'è qualcosa che non va in quella release sugli switch Omada adottati con controller v5.14, ha detto che la cosa era sotto esame, e ha consigliato di restare sul firmware precedente per il momento. Quindi non sprecare una richiesta di supporto sull'hardware, spendila sul numero di build.
Se davvero non puoi fare il downgrade, l'unico workaround è vivere con i tre slot che funzionano ancora e tenere la porta 26 vuota. Non è una soluzione, solo un modo per restare operativi finché non esce una release corretta.
Prima di compilare un modulo RMA: quando è iniziato tutto questo, e lo switch ha ricevuto un aggiornamento firmware più o meno nello stesso periodo? La 1.20.4 Build 20241104 è piuttosto recente, e il controller pubblica volentieri una nuova immagine da solo se gli aggiornamenti automatici sono rimasti attivi.
Vale la pena anche chiarire: la porta 27 sfarfalla solo quando il 26 ha un modulo inserito, o anche a vuoto? Uno slot morto normalmente non fa flappare un vicino. Questo aspetto sa molto più di software dietro le porte che di una saldatura incrinata.
Stesso switch, stessa build anche qui, quindi non sei solo. La porta 25 andava bene, la 26 non dava LED di link con nessuno dei moduli che possiedo, e 27 e 28 andavano e venivano - una delle due alimenta un EAP783, quindi ogni caduta era molto visibile. Ho fatto esattamente lo stesso rituale di scambio moduli e mi ero convinto di uno slot morto.
Non era lo slot. Lo switch aveva ricevuto un aggiornamento firmware poco prima che iniziassero i problemi, e tornare all'immagine precedente ha riportato tutte e quattro le porte SFP+. Controlla la cronologia degli aggiornamenti prima di spedire qualsiasi cosa da qualche parte.
Confermato, ed è imbarazzante quanto sono stato vicino a rispedire lo switch. La cronologia aggiornamenti mostra la 1.20.4 Build 20241104 arrivata pochi giorni prima che le porte iniziassero a comportarsi in modo strano, e non l'ho mai avviata a mano, quindi è arrivata da sola.
Tornato alla release precedente, riadottato, e tutti e quattro gli slot sono su a 10G, porta 26 inclusa. La porta 27 non sfarfalla più quando lavoro sulla 26. Gli aggiornamenti automatici ora sono disattivati e la vecchia immagine sta sul file server accanto al backup della configurazione.
Per l'archivio: la stessa famiglia ha un'altra trappola firmware da conoscere. Su un TL-SX3008F (V1) con un SM5310-T(UN) che alimenta una workstation, i firmware 1.20.2 e 1.20.3 lasciavano la porta SFP+ morta non appena il PC andava in sospensione o veniva spento. Spostare il modulo in uno slot libero funzionava esattamente una volta per slot, e una volta usati tutti gli slot solo un riavvio dello switch riportava le porte indietro. Fissare la porta a 1G evitava il problema, al prezzo della velocità per cui l'avevi pagato.
Un altro proprietario ha avuto lo stesso problema con moduli RJ45 di 10Gtek (ASF-10G2-T), Wiitek e Xicom dietro un adattatore Iocrest AQC113. Il downgrade alla 1.20.0 Build 20231011 Rel.42220 ha risolto per entrambi. Sintomo diverso, stessa lezione: la gestione del rame SFP+ in queste build è dove vivono i bug.
Tieni a mente un'altra cosa con questa linea di switch: un modulo inattivo può costarti più di una porta. Su un TL-SX3016F con la 1.0.0 Build 20210730 Rel.65115 la CPU stava all'87-89% senza traffico alcuno e buttava nel log una riga CPU RISING THRESHOLD ogni tre minuti.
Il carico seguiva il numero di moduli installati - un modulo 0-1%, due 73-76%, tre o più 88-90% - e la causa erano moduli Mellanox MFM1T02A-SR con la fibra inserita ma nulla acceso all'altro capo, quindi il link restava giù. Sostituirli con Ubiquiti UF-MM-10G teneva la CPU bassa qualunque cosa facesse la porta, e anche semplicemente togliere i moduli inutilizzati risolveva il problema. La risposta di TP-Link è stata che un modulo lì fermo con il link giù è semplicemente costoso per il chipset, e che il carico scende non appena la porta fa link correttamente. Resta però la parte scomoda senza spiegazione: cambi marca, lasci il modulo altrettanto inattivo, e la CPU resta tranquilla. Quindi una volta tornato al firmware più vecchio, dai un'occhiata anche al grafico della CPU.