DAC 25G da Fortinet sobe entre FortiSwitch idênticos, mas não entre FS2048 e FS648
Estamos consolidando duas fileiras de agregação em FortiSwitch, e a última peça é uma interligação 25G entre um FS2048 e um FS648 em racks adjacentes. Tudo o mais no projeto subiu na primeira tentativa; só esse link se recusa.
- FortiSwitch 2048, porta 25G do painel frontal
- FortiSwitch 648, porta 25G do painel frontal
- Fortinet FN-CABLE-SFP28-5, DAC passivo, cabo do próprio fabricante, não é de terceiros
- Fora a configuração de VLAN, as duas portas continuam intocadas
O que aparece:
FS2048 port: down, no rx/tx counters moving
FS648 port: down, no rx/tx counters moving
same FN-CABLE-SFP28-5 between two FS648 units: up at 25G, stableJá tentado:
- troquei por um segundo FN-CABLE-SFP28-5 da mesma caixa, sem mudança
- movi as duas pontas para portas 25G diferentes em cada chassi, sem mudança
- comprovei que o cabo está bom ligando ele entre dois FS648 idênticos, onde sobe na hora
Então o cabo está bom e as portas estão boas, mas a combinação não está. Existe algo nas portas 25G que precisa bater entre os dois modelos antes de o link treinar?
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
É exatamente isso. Os dois chassis são construídos sobre gerações diferentes de ASIC e PHY, e a correção de erro que cada um assume sozinho em 25G não é a mesma dos dois lados, então o link nunca termina o treinamento. Sobra um down/down limpo e nada nos logs para se agarrar.
Fixe manualmente o mesmo modo de FEC nas duas portas:
Faça isso no FS2048 e no FS648, usando o nome de porta de cada lado. CL91 é a variante Reed-Solomon e limpa bem mais do que a opção firecode CL74, mas qual dos dois você escolhe importa muito menos do que escolher o mesmo dos dois lados: os dois PHYs precisam codificar e decodificar com um esquema idêntico ou o treinamento nunca termina, e "auto" em duas famílias de PHY diferentes não é um esquema idêntico.
A porta deve subir assim que o segundo lado for aplicado. Se depois você misturar um terceiro modelo nisso, configure isso explicitamente lá também em vez de supor que o padrão se manteve.
Um cabo que sobe entre unidades idênticas e morre entre modelos diferentes é a camada física não conseguindo concordar em alguma coisa, e em cobre 25G isso é quase sempre FEC.
Antes de mais nada, poste qual fec-state está configurado agora nas duas portas. O padrão não é o mesmo entre gerações de FortiSwitch, e os dois modelos que você está unindo não são da mesma família de ASIC/PHY, então "configuração de fábrica nas duas pontas" não significa "a mesma configuração nas duas pontas".
Se as duas portas voltarem com valores diferentes aí, você já tem a resposta antes de mexer em mais nada.
Nada foi mexido de nenhum dos lados, então as duas portas estão rodando o que a imagem define por padrão. O lado do FS2048 está limpo:
Mesma coisa no FS648. Velocidade e autonegociação também intocadas, só coloquei as portas na VLAN certa. Se os padrões diferem por modelo, isso explicaria por que o mesmo cabo fica perfeitamente feliz entre duas caixas idênticas.
Mesma classe de problema bem longe da Fortinet, para constar. Eu tinha um DAC passivo SFP28 25G que subia numa boa entre um UniFi USW-Pro-Aggregation e um servidor com placa Intel SFP28, e não dava nada na sfp28-2 de um MikroTik CCR2004-1G-12S+2XS - sem erro de nenhum lado, só sem link. Testei um Ubiquiti UACC-DAC-SFP28-3M e um Lenovo 7Z57A03558, mesmo resultado. Em um momento a porta chegou a subir e caiu de novo depois de uns dois segundos, o que foi a pista de que algo estava falhando no treinamento em vez de o cabo estar morto.
FEC de novo: o lado Ubiquiti mantém o FEC ligado sem nenhuma forma suportada de mudar isso, e o RouterOS moveu o padrão de fec91 para sem FEC na 6.49. O que funcionou aqui foi ir para o RouterOS 7.4, onde as opções de FEC ficam expostas, rodando
e depois configurando a porta para fec74 com autonegociação desligada, controle de fluxo desligado nas duas direções, 25 Gbps full duplex, mais um override de perfil de porta do lado Ubiquiti fixando 25G FDX. Isso é meu hardware e meu firmware, então trate essa receita exata como ponto de partida e confira no seu.
Vale acrescentar que o mesmo parâmetro tem um nome diferente dependendo da CLI em que você está, o que torna isso chato assim que um rack tem mais de um fabricante. Nos links 25G da Cisco entre um stack de Catalyst 9300 e um par de Catalyst 9500, fec cl108 nas duas pontas foi o que os fez subir; no 100G entre aquele par de 9500 e um Nexus 9000, o que funcionou foi fec off nos dois lados. Mesma decisão, palavras-chave diferentes.
E FEC nem sempre é algo que você liga. Num Nexus 93180YC-EX com SFP-H25GB-SR ligado a um adaptador Cavium 25G, a porta do switch ficava em FEC auto e esperava FEC por causa do óptico, enquanto a NIC não reportava nenhuma capacidade de FEC, então as pontas nunca concordavam e as interfaces ficavam down com os módulos reconhecidos. Ali, fec off na interface do switch foi a solução, e o show interface confirma o modo passando de Auto para Off.
Então a regra não é "use cl91", é "decida o modo e configure ele explicitamente nas duas pontas".
Confirmado. set fec-state cl91 na porta do FS2048 não mudou nada sozinho, depois o mesmo na porta do FS648 e o link subiu em poucos segundos. Contadores se movendo dos dois lados, e sobreviveu a um reboot de cada chassi.
Daqui para frente a configuração fica explícita em toda porta 25G desse par em vez de confiar num padrão. Duas noites trocando cabos perfeitamente bons por uma linha de config.