Uplink 100GE de um Huawei CE6800 para um Profitap XX-3200G nunca sobe com ópticas SR4
Substituindo o par de agregação existente de um cliente por equipamento CloudEngine, e o único link que se recusa a subir é o feed de 100GE para o packet broker deles. Todo o resto no switch entrou sem drama.
- Huawei CloudEngine 6800, porta 100GE
- módulos QSFP28 100GBASE-SR4, peças Huawei, uma em cada ponta
- packet broker Profitap XX-3200G do outro lado
As duas pontas enxergam o módulo delas. O log do switch não tem nada além de entradas de inserção e remoção de transceiver de quando eu estava reencaixando as coisas, nenhum alarme, e a interface simplesmente fica down:
<CE6800> display interface 100GE1/0/1
...
FEC : RS-FECJá tentei:
- troquei os dois módulos por reservas e limpei as pontas MPO, nenhuma mudança;
- movi o link para outra porta 100GE no switch;
- conferi o lado do broker, ele detecta o próprio módulo e não reporta nada de errado.
Então as ópticas são reconhecidas nas duas pontas, nada está reclamando, e não tem link. O que mais precisa bater entre uma porta 100GE de um CloudEngine e uma caixa de terceiros 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 3
Isso é um descasamento de FEC. O CloudEngine habilita RS-FEC por padrão em portas 100GE com ópticas SR4, o broker não tem configuração de FEC e por isso roda sem ele, e duas pontas que discordam em FEC nunca terminam de treinar. Nada está quebrado, então nada é logado, e é por isso que o log só tem suas mensagens de inserção e remoção.
Desligue isso no switch, na view da interface:
undo fec modefaz a mesma coisa. A segunda linha é a que importa. CE é configuração em dois estágios, e umfec mode nonesem commit parece perfeitamente correto quando você relê a config, enquanto a porta continua exatamente tão down quanto antes. Já vi um caso de cliente se arrastar por mais um dia inteiro por essa razão, com todo mundo convencido de que o FEC já tinha sido desabilitado.Depois do commit, o
display interfacedeve mostrar FEC: NONE e a porta deve treinar.Se a outra ponta algum dia ganhar uma configuração de FEC, o melhor ajuste é habilitar RS-FEC lá e deixar o switch no padrão dele, já que em 100G você realmente quer a correção. Entre dois vendors diferentes eu configuraria o FEC explicitamente nos dois lados em vez de confiar em qualquer negociação automática.
O que o broker diz sobre FEC do lado dele, se é que diz alguma coisa? Você já postou a metade interessante sozinho: a porta do switch está rodando RS-FEC. A Huawei é explícita que as duas pontas de um link 100GE precisam usar o mesmo modo de FEC, senão as interfaces nunca sobem, e essa falha parece exatamente com a sua: os dois módulos saudáveis, nenhum alarme, nenhum log, porta down.
A maioria dos packet brokers e taps com que já trabalhei não expõe nenhum ajuste de FEC, o que significa que eles rodam sem ele e o switch é o lado que precisa ceder. Confirme isso primeiro, depois mude uma coisa só.
Vale acrescentar que o padrão do CloudEngine não é um valor único, depende do módulo. O QSFP28-100G-LR4 e o QSFP28-100G-LR1 rodam com FEC desligado, conforme o IEEE 802.3, enquanto todos os outros tipos de QSFP28 vêm com FEC ligado por padrão. Então o conselho de simplesmente desabilitar está errado num link LR4, onde o switch já está desligado e o descasamento mora do outro lado.
Mais duas regras do mesmo capítulo que já me pegaram:
Então confira o que você realmente tem em mãos com
display transceiver interface 100GE1/0/1 verboseantes de decidir para que lado empurrar o FEC, e lembre do commit de qualquer jeito.