IBM Flex System EN4093 derruba portas de trunk SFP+ em ERRDISABLE no boot e durante a operação
Dois chassis Flex System, cada um com um EN4093R 10Gb Scalable Switch (opção 49Y4270) como módulo de rede. As portas voltam error-disabled depois de um evento de energia no chassi, e com menos frequência caem no mesmo estado enquanto tudo está rodando. Nem sempre são as mesmas portas, o que torna isso bem cansativo de perseguir.
Configuração:
- IBM Flex System EN4093 10Gb Scalable Switch, opção 49Y4270
- trunk de uplink de quatro portas para o core, óptica IBM mais um DAC adicionado depois
- porta QSFP+ dividida (breakout) em direção ao segundo chassi
- MSTP rodando do nosso lado, o core é de outro fabricante
O que a lista de portas mostra depois de um boot:
port 5 ERRDISABLE reason: link flap detect threshold exceeded
port 17 ERRDISABLE reason: mismatched link capabilities
port 19 ERRDISABLE reason: mismatched link capabilitiesJá tentei:
- shutdown / no shutdown nas portas afetadas traz a maioria de volta até o próximo evento
- limpei e reencaixei toda fibra do trunk, nenhuma mudança no padrão
- comparei a configuração da porta na outra ponta, as velocidades batem no papel
O que está realmente empurrando essas portas para errdisable, e tem algum jeito de parar isso de acontecer a cada boot em vez de limpar na mão toda vez?
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 5
Esse switch tem sete estados documentados que desabilitam uma porta, e eles têm muito pouco a ver uns com os outros:
A sua é a quarta, e é a que mais gente encontra, porque é a que você mesmo constrói: misture velocidades ou tipos de módulo dentro de um único trunk e o switch reclama. Um DAC sentado ao lado de três módulos ópticos já basta. Tire o DAC de lá e preencha o slot com um módulo igual aos outros três.
Para a porta no detector de flap, reiniciar ela continua sendo a recuperação documentada:
Depois disso, releia a configuração de spanning tree naquele link e revise o cobre e a fibra na mão. Siga toda mudança de configuração com um reload, ou o estado em execução silenciosamente para de bater com o que você acha que configurou.
Duas coisas para não esperar. Dois desses sete estados mantêm a porta down depois que o timeout expira e querem uma mão na porta. E nenhuma versão de firmware corrige isso - a linha do fabricante é que você configura em volta do problema, então módulos idênticos em todo membro do trunk mais fibra limpa é até onde a prevenção vai.
Duas razões diferentes no mesmo trecho colado é por onde eu começaria. Uma porta específica sempre volta desabilitada pela mesma razão, ou uma que caiu por capacidades nesse boot dispara o detector de flap no próximo? Uma razão que fica fixa por porta e uma razão que vagueia são duas investigações separadas, e só uma delas termina com você comprando hardware.
A segunda coisa que vale fixar é o que o core roda para spanning tree. Você está em MSTP; se o outro lado coloca BPDUs PVST com sabor Cisco nesses uplinks, esse switch tem um mecanismo de proteção que reage exatamente a isso e derruba a porta, e de fora parece a falha que você já está perseguindo. Você consegue saber se alguma das quedas bate com uma mudança de topologia no core em vez de com seus próprios boots?
Por porta é consistente, na caixa como um todo não é. Os membros de trunk que caem sempre voltam com mismatched link capabilities, e a porta de acesso na 5 só dispara o detector de flap, em nenhum intervalo em que eu consiga achar um padrão. Então parece mesmo duas falhas vestindo o mesmo casaco.
Spanning tree do outro lado eu ainda não consigo responder - o core pertence a outra equipe e perguntei o que eles realmente emitem nesses uplinks. Nada no nosso log liga uma queda a uma mudança de topologia lá até agora, mas eu estava lendo em busca de eventos de link, não daquilo, então eu não diria que está descartado.
Fabricante diferente, mesmo formato. Tínhamos um FortiGate 201F pendurado num FortiSwitch 548D em SFP+ com o DAC da própria Fortinet entre eles, e o link 10Gbps simplesmente não ficava em pé - caía não importa o que fizéssemos com speed e duplex, e voltar as duas pontas do FortiOS 7.4 para 7.2.5 não mudou nada.
O que se sustentou no fim foi um DAC Fortinet mais curto com STP desligado só naquele link, e está em pé desde então. A parte que vale carregar é o raciocínio que veio depois: quanto mais longo o trecho de cobre passivo, mais o sinal se degradou até chegar, então em 10G qualquer DAC longo ou no limite entra na lista de suspeitos, seja qual for a marca impressa nele. Com três ópticas e um DAC num trunk em errdisable, eu estaria olhando forte para o que destoa.
Uma coisa para fazer antes de mexer em qualquer hardware: anote a cadência exata dos flaps contra os timestamps do log.
Num switch completamente sem relação, um TL-SG3452X, toda porta SFP+ populada caía e voltava a cada dez a quinze minutos com mensagens de STP no log a cada flap, e a conclusão óbvia era óptica ruim - até um DAC TL-SM5220-1M de primeira parte flapear exatamente no mesmo ritmo. Isso matou a teoria da óptica num único teste e apontou para uma regressão de firmware em vez disso; a única resposta que funcionou lá foi ficar na build mais antiga.
Um intervalo regular significa que algo está estourando timeout numa agenda. Um aleatório significa algo físico. Teste barato, e poupa você de comprar módulos que não precisa. Também compensa manter a imagem de firmware anterior por perto, para o downgrade continuar na mesa.