ConnectX-4 MCX456A-ECAT não linka com um Cisco NCS em 100GBASE-LR4 enquanto o loopback passa nas duas pontas
Cuidamos de um par de racks que entrega tráfego para um Cisco NCS voltado para a operadora, e um dos uplinks de servidor de 100G nunca subiu desde a implantação. Mesmo resultado depois de mover o servidor para outro rack com um patch panel diferente, então parei de tratar isso como um caso isolado.
- servidor Supermicro, NVIDIA/Mellanox ConnectX-4 MCX456A-ECAT, as duas portas livres
- QSFP28 100GBASE-LR4 genérico, monomodo, alcance de 10 km, um em cada ponta
- Cisco NCS do outro lado, fibra escura entre as duas salas
A parte que me deixa travado: cada módulo passa num loopback no próprio equipamento. Com a fibra em loop direto de volta no mesmo QSFP28, a NIC reporta um link de 100G limpo, e o NCS faz o mesmo do lado dele. Coloca o trecho real no meio e não tem nada.
# module looped back on the NIC itself
Speed: 100000Mb/s
Link detected: yes
# same module, real span to the NCS
Speed: Unknown!
Link detected: noO que já tentamos:
- trocamos os dois módulos por reservas do mesmo lote, nenhuma mudança
- movemos o servidor e repatcheamos por um painel diferente
- abrimos um caso com o fabricante da NIC, e a resposta foi um direcionamento para a lista de transceivers validados nas release notes do firmware, o que não explica por que o loopback funciona
Existe alguma coisa sobre o LR4 no ConnectX-4 que deixaria ele linkar localmente mas nunca através de um trecho real, ou estou correndo atrás da ponta errada disso?
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 3
Isso soa como um caminho sujo, não um problema de compatibilidade.
Tudo que você já trocou está do lado que já testou bem, e é por isso que nada mudou - o trecho em si é a única coisa ainda intocada. Então trabalhe o caminho:
A lista de transceivers validados para a qual te apontaram vale uma olhada, mas um módulo que sobe limpo em loopback já está sendo acionado corretamente pela NIC. Listas de compatibilidade explicam módulos que são recusados de cara, não módulos que linkam localmente e morrem no trecho real.
Se limpar não resolver, o próximo passo é uma fonte de luz e um medidor de potência na fibra escura, ou um OTDR se você conseguir emprestado, antes de comprar outra NIC ou outro par de ópticas.
Um loopback só prova que uma porta consegue se ouvir - laser, receptor, configurações de taxa. Não diz nada sobre o vidro entre as suas duas salas, e essa é a única peça que você ainda não testou. Então antes de culpar a NIC de novo, tire números das duas pontas com o trecho real conectado: qual é a potência de Rx na porta do NCS, e qual é na NIC? Rx abaixo do limiar de Low Warn com o trecho no lugar é o indicador clássico apontando para a outra ponta ou para o caminho, não para a porta local. Do lado Linux o
ethtool -mdeveria te dar a mesma leitura, e se ele voltar comCannot get module EEPROM information: Input/output errornão leia isso como um módulo morto - no mlx5 isso geralmente é acesso a módulo do lado do firmware, emst start,mst cable adde depoismlxcablesvão te dar os valores de qualquer jeito.Limpar foi a resposta. Colocamos um scope nas faces de conector e os dois módulos mais os dois patch cords estavam contaminados; o cordão que passa pelo painel entre as salas era o pior dos dois. Limpamos tudo no caminho, reencaixamos, e o link de 100G para o NCS subiu na primeira tentativa e ficou up desde então.
Levemente irritado comigo mesmo por ter gastado tanto tempo no ângulo da compatibilidade quando o resultado do loopback estava me dizendo o tempo todo que os módulos estavam bons e o caminho não estava. Para quem chegar aqui depois: loopback prova a porta, não a fibra.