TL-SG3428X-M2 (V1): SFP+-slot 26 geeft met geen enkele TL-SM5310-T link, slot 27 knippert weg
Ik beheer een klein kantoornetwerk, één netwerkkast, en de vier SFP+-slots op onze access switch dragen de 10G-links naar het serverrack. Het draaide maandenlang zonder problemen en nu is er ineens één slot dood.
- TP-Link TL-SG3428X-M2 (V1), firmware 1.20.4 Build 20241104 Rel.40746, geadopteerd in Omada
- vier TP-Link TL-SM5310-T 10GBASE-T-modules in SFP+-poorten 25-28
- CAT6A-patchkabels, de andere kant zit op twee servers en een NAS
Poortstatus op dit moment:
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, 10GWat ik al geprobeerd heb:
- de modules rondgewisseld over alle vier de slots: de module uit 26 doet het prima in 25 en 28, en elke module die ik in 26 stop blijft donker, dus de modules zelf zijn in orde
- nieuwe patchkabels, andere poorten aan de andere kant, geen verschil
- switch herstart, poort disable/enable, geen verschil
Wat ik niet kan verklaren is dat poort 27 hapert zodra ik alleen aan poort 26 zit. Is slot 26 dood en de moeite van een RMA waard, of is er nog iets anders om eerst uit te sluiten?
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
Dit is een firmwareregressie in 1.20.4 Build 20241104, geen kapotte hardware. Het patroon dat je beschrijft - één SFP+-slot dat nooit oplicht met modules waarvan je weet dat ze goed zijn, plus een buurpoort die hapert zodra je aan de dode zit - is precies wat die build doet met koperen TL-SM5310-T-modules.
Zet de switch terug naar de vorige release en de poorten komen terug. In de praktijk:
TP-Link zelf heeft erkend dat er iets mis is in die release op Omada-switches onder controller v5.14, zei dat er naar gekeken werd, en adviseerde voorlopig op de oudere firmware te blijven. Verspil dus geen supportcase aan de hardware, besteed hem aan het buildnummer.
Als downgraden echt niet kan, is de enige workaround leven met de drie slots die nog werken en poort 26 leeg laten. Dat is geen oplossing, alleen een manier om in bedrijf te blijven tot er een gecorrigeerde release komt.
Voordat je een RMA-formulier invult: wanneer begon dit, en heeft de switch rond dezelfde tijd een firmware-update binnengehaald? 1.20.4 Build 20241104 is behoorlijk vers, en de controller pusht graag uit zichzelf een nieuwe image als automatische updates aanstonden.
Ook de moeite waard om vast te stellen: hapert poort 27 alleen als er een module in 26 zit, of ook als 26 leeg is? Een dood slot laat een buurpoort normaal niet flapperen. Dat ruikt veel meer naar de software achter de poorten dan naar een gescheurde soldeerverbinding.
Zelfde switch, zelfde build hier, dus je staat er niet alleen voor. Poort 25 was in orde, poort 26 gaf met elke module die ik heb geen link-LED, en 27 en 28 kwamen en gingen - een ervan voedt een EAP783, dus elke drop was goed zichtbaar. Ik heb precies hetzelfde module-wisselritueel doorlopen en mezelf ervan overtuigd dat het slot dood was.
Het lag niet aan het slot. De switch had kort voor het probleem begon een firmware-update gehad, en teruggaan naar de vorige image bracht alle vier de SFP+-poorten terug. Check de updategeschiedenis voordat je ook maar iets ergens naartoe stuurt.
Bevestigd, en het is gênant hoe dicht ik erbij was om de switch op te sturen. De updategeschiedenis laat zien dat 1.20.4 Build 20241104 een paar dagen voor de poorten raar gingen doen binnenkwam, en ik heb hem nooit zelf gestart, dus hij kwam er vanzelf in.
Teruggezet naar de vorige release, opnieuw geadopteerd, en alle vier de slots staan op 10G, poort 26 inbegrepen. Poort 27 hapert niet meer als ik aan 26 werk. Automatische updates staan nu uit en de oude image staat op de fileserver naast de config-backup.
Voor het archief: dezelfde familie heeft nog een firmwareval die het weten waard is. Op een TL-SX3008F (V1) met een SM5310-T(UN) naar een werkstation liet firmware 1.20.2 en 1.20.3 de SFP+-poort dood achter zodra de pc in slaap ging of werd uitgezet. De module naar een vrij slot verplaatsen werkte precies één keer per slot, en zodra alle slots gebruikt waren, bracht alleen een switch-herstart de poorten terug. De poort vastzetten op 1G voorkwam het, tegen de prijs van de snelheid waarvoor je betaald had.
Een andere eigenaar liep tegen hetzelfde aan met RJ45-modules van 10Gtek (ASF-10G2-T), Wiitek en Xicom achter een Iocrest AQC113-adapter. Downgraden naar 1.20.0 Build 20231011 Rel.42220 loste het voor ons allebei op. Ander symptoom, zelfde les: de afhandeling van koperen SFP+ in deze builds is waar de bugs zitten.
Nog iets om in je achterhoofd te houden bij deze lijn switches: een inactieve module kan je meer kosten dan een poort. Op een TL-SX3016F met 1.0.0 Build 20210730 Rel.65115 stond de CPU op 87-89% zonder enig verkeer en zette elke drie minuten een regel CPU RISING THRESHOLD in het log.
De belasting volgde het aantal geplaatste modules - één module 0-1%, twee 73-76%, drie of meer 88-90% - en het kwam neer op Mellanox MFM1T02A-SR-modules met vezel erin maar niets aan de andere kant, dus de link bleef down. Die vervangen door Ubiquiti UF-MM-10G hield de CPU laag ongeacht wat de poort deed, en de ongebruikte modules er gewoon uittrekken hielp net zo goed. TP-Link zelf antwoordde dat een module die daar met een dode link zit gewoon duur is voor de chipset, en dat de belasting terugzakt zodra de poort goed linkt. Dat laat de lastige helft onverklaard: verander het merk, laat de module even inactief, en de CPU blijft rustig. Dus zodra je terug bent op de oudere firmware, kijk ook even naar de CPU-grafiek.