Supermicro E300-9A no pfSense Plus 22.05: ix2 e ix3 ficam em no carrier com um DAC que linka normal num USW-Aggregation
Meu firewall é um Supermicro E300-9A rodando pfSense Plus 22.05, e as duas portas SFP+ 10G se recusam a subir. Nem a ix2 nem a ix3 nunca mostram carrier, seja lá o que eu coloque na gaiola.
Hardware:
- Supermicro E300-9A, pfSense Plus 22.05
- Ubiquiti DAC-SFP10-0.5M e um cabo twinax passivo 10Gtek
- módulos ópticos Supermicro AXS85-192-M3 como alternativa
- Ubiquiti USW-Aggregation do lado do switch
# ifconfig ix2
ix2:
media: Ethernet autoselect
status: no carrierA ix3 mostra a mesma coisa.
Já tentei:
- os dois cabos funcionam no USW-Aggregation entre outros equipamentos, então não estão mortos
- troquei o cobre pelos módulos ópticos AXS85-192-M3, mesmo no carrier nas duas portas
- reiniciei o appliance várias vezes, inclusive inserindo um módulo com ele ligado
Tem alguma coisa nessa caixa que precisa ser chutada antes das gaiolas começarem a funcionar, ou estou olhando para duas portas mortas mesmo?
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
Reboot a quente não leva a lugar nenhum - essas portas travam um estado de mídia e nunca reexaminam isso num restart. Desligue o appliance direito, tire o adaptador de energia da tomada por uns dois minutos, e ligue de novo com o módulo já inserido. Foi isso que trouxe as duas portas de volta aqui, e outra pessoa descreveu o mesmo comportamento numa porta Intel X552, por isso acho que é um estado de mídia obsoleto, não um problema do pfSense.
Se você inserir um módulo com o sistema já rodando, reinicie a interface em vez de reiniciar a caixa:
Isso faz o driver olhar para a gaiola de novo. Não é uma correção permanente para nada, mas evita um reboot quando você está trocando módulos na bancada. Confira o resultado com
ifconfig -aem vez do painel frontal.Faça a remoção completa de energia primeiro e confirme as duas gaiolas com um DAC antes de mexer no lado do switch. Depurar uma coisa de cada vez importa aqui, porque "no carrier com todo módulo" e "link sobe na velocidade errada" costumam ser duas falhas separadas que só calham de estar no mesmo trecho de cabo.
A remoção completa de energia resolveu. Desliguei, tirei o adaptador, esperei uns dois minutos, liguei de novo - as duas portas subiram. Fiz um loop de DAC entre ix2 e ix3 e consegui um link 10G limpo, e o par AXS85-192-M3 também faz 10G entre as duas portas, então as gaiolas e os módulos estão bem.
O lado do switch é outra história. Em direção ao USW-Aggregation o link só negocia em 1G, e se eu forço 10G em qualquer uma das pontas ele cai e fica caído. Então metade do problema sumiu e a metade chata continua aqui.
A metade do fallback para 1G parece bem familiar. Persegui o mesmo sintoma num TL-SG3428X e num TL-SX3008F: reiniciar um servidor pendurado numa dessas portas SFP+ e ele voltava negociado em 1G, não importa para que a porta do switch estivesse configurada. Adaptadores Intel X520-DA2, Mellanox e HP, ópticas Intel E10GSFPSR e 10GTek, atualizações de firmware, várias versões de driver no Linux e no Windows, perfis de porta - nada disso mudou nada. Um reboot do switch, ou alternar a velocidade da porta para fora do 10G e de volta, restaurava o link 10G até o próximo reset do host.
O que realmente resolveu foi trocar as ópticas, não mexer no host: módulos TP-Link SM5110-SR do lado do switch e o link voltava em 10G toda vez. Outra pessoa confirmou a mesma coisa num SG3428XMPP. A leitura foi que o switch renegocia errado com alguns módulos de terceiros depois de um reset de link do lado do host.
Fabricante diferente do seu lado, mas o formato bate. Antes de comprar um lote de qualquer coisa, pegue emprestado um único módulo de marca Ubiquiti e teste uma porta no switch de agregação.
Sobre forçar 10G: fazer isso só numa ponta piora as coisas, não melhora. O par ainda está tentando negociar e uma configuração fixa não dá nada para ele negociar contra, então o link simplesmente fica caído - que é exatamente o comportamento que você descreve. Fixe velocidade e duplex nas duas pontas, ou em nenhuma.
Dois casos parecidos do mundo MikroTik, caso soem familiares. Num RB4011 um Finisar FTLF8524P2BNV-BR foi detectado com sfp-rx-loss e sfp-tx-fault mostrando os dois no, e a interface ainda dizia no-link, porque um SFP 1G numa gaiola SFP+ tem que ser fixado, não negociado:
e, de novo, nas duas pontas. O segundo caso foi um CCR1072 onde a auto-negociação ficava em DONE depois de uma perda de link e o driver nunca reiniciava ela; desabilitar o autoneg e fixar a velocidade trouxe o link de volta, à custa de perder a detecção correta de queda de link.