TL-SG3428X-M2 (V1): slot SFP+ 26 não sobe link com nenhum TL-SM5310-T, slot 27 pisca junto
Cuido de uma rede de escritório pequena, um único closet de rede, e os quatro slots SFP+ do nosso switch de acesso carregam os links de 10G até o rack de servidores. Rodou meses sem dar trabalho nenhum e agora um dos slots simplesmente sumiu.
- TP-Link TL-SG3428X-M2 (V1), firmware 1.20.4 Build 20241104 Rel.40746, adotado no Omada
- quatro módulos TP-Link TL-SM5310-T 10GBASE-T nas portas SFP+ 25-28
- patch cords CAT6A, as pontas do outro lado são dois servidores e um NAS
Estado das portas agora:
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, 10GO que já tentei:
- girei os módulos pelos quatro slots: o módulo do 26 sobe link sem problema no 25 e no 28, e qualquer módulo que eu coloco no 26 fica apagado, então os módulos em si estão bons
- patch cords novos, portas diferentes do outro lado, nada muda
- reboot do switch, desabilitar/habilitar a porta, nada muda
O que eu não consigo explicar é a porta 27 oscilar quando a única coisa que mexo é a porta 26. O slot 26 está morto e vale abrir RMA, ou tem mais alguma coisa para descartar antes?
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
Isso é uma regressão de firmware na 1.20.4 Build 20241104, não hardware morto. O padrão que você descreve - um slot SFP+ que nunca acende com módulos que sabidamente funcionam, mais um vizinho que pisca quando você mexe no morto - é o que essa build faz com os módulos de cobre TL-SM5310-T.
Volte o switch para a versão anterior e as portas voltam. Na prática:
O próprio pessoal da TP-Link reconheceu que tem algo errado nessa versão em switches Omada adaptados para o controller v5.14, disse que estava sendo analisado, e recomendou ficar no firmware antigo por enquanto. Então não gaste um chamado de suporte com o hardware, gaste com o número da build.
Se você realmente não conseguir fazer o downgrade, a única saída é viver com os três slots que ainda funcionam e deixar a porta 26 vazia. Isso não é uma correção, é só um jeito de continuar operando até sair uma versão corrigida.
Antes de preencher um formulário de RMA: quando isso começou, e o switch recebeu alguma atualização de firmware por volta da mesma época? A 1.20.4 Build 20241104 é bem recente, e o controller empurra uma imagem nova sozinho e feliz da vida se a atualização automática ficou ligada.
Outra coisa para fechar: a porta 27 oscila só quando o 26 tem módulo dentro, ou também com o 26 vazio? Um slot morto normalmente não faz o vizinho oscilar. Isso cheira muito mais a software por trás das portas do que a uma solda rachada.
Mesmo switch, mesma build aqui, então você não está sozinho. A porta 25 estava ok, a porta 26 não dava link LED com nenhum módulo que eu tenho, e a 27 e a 28 iam e voltavam - uma delas alimenta um EAP783, então cada queda ficava bem visível. Passei exatamente pelo mesmo ritual de trocar módulo e me convenci de que era um slot morto.
Não era o slot. O equipamento tinha recebido uma atualização de firmware pouco antes do problema começar, e voltar para a imagem anterior trouxe as quatro portas SFP+ de volta. Confira o histórico de atualização antes de mandar qualquer coisa para qualquer lugar.
Confirmado, e é constrangedor o quanto eu estava perto de mandar o switch embora. O histórico de atualização mostra a 1.20.4 Build 20241104 chegando alguns dias antes de as portas começarem a agir estranho, e eu nunca iniciei isso na mão, então veio sozinha.
Voltei para a versão anterior, adotei de novo, e os quatro slots estão em 10G, incluindo a porta 26. A porta 27 não oscila mais quando mexo na 26. A atualização automática está desligada agora e a imagem antiga fica no servidor de arquivos ao lado do backup de configuração.
Para o arquivo: a mesma família tem outra armadilha de firmware que vale saber. Num TL-SX3008F (V1) com um SM5310-T(UN) alimentando uma estação de trabalho, os firmwares 1.20.2 e 1.20.3 deixavam a porta SFP+ morta assim que o PC entrava em suspensão ou era desligado. Mover o módulo para um slot livre funcionava exatamente uma vez por slot, e depois que todos os slots tinham sido usados só um reboot do switch trazia as portas de volta. Fixar a porta em 1G evitava o problema, ao preço da velocidade pela qual você pagou.
Outro dono passou pela mesma coisa com módulos RJ45 da 10Gtek (ASF-10G2-T), Wiitek e Xicom atrás de um adaptador Iocrest AQC113. Fazer downgrade para 1.20.0 Build 20231011 Rel.42220 resolveu para nós dois. Sintoma diferente, mesma lição: é no tratamento de SFP+ de cobre nessas builds que moram os bugs.
Guarda mais uma coisa na cabeça com essa linha de switches: um módulo ocioso pode custar mais que uma porta. Num TL-SX3016F rodando 1.0.0 Build 20210730 Rel.65115 a CPU ficava em 87-89% sem tráfego nenhum e jogava uma linha CPU RISING THRESHOLD no log a cada três minutos.
A carga acompanhava o número de módulos instalados - um módulo 0-1%, dois 73-76%, três ou mais 88-90% - e a causa eram módulos Mellanox MFM1T02A-SR com fibra conectada mas nada aceso do outro lado, então o link ficava caído. Trocar esses por Ubiquiti UF-MM-10G mantinha a CPU baixa não importa o que a porta estivesse fazendo, e simplesmente tirar os módulos sem uso também resolvia. A própria resposta da TP-Link foi que um módulo parado ali com o link caído é caro para o chipset, e que a carga volta ao normal assim que a porta linka direito. Isso deixa a metade estranha sem explicação: troca a marca, deixa o módulo igualmente ocioso, e a CPU fica quieta. Então, depois de voltar para o firmware antigo, dá uma olhada no gráfico de CPU também.