Catalyst 3850 coloca a porta em err-disable quando um ThinkSystem SR650 usa ópticas Lenovo 46C3447 SR
Host ESXi novo indo para um rack que fica pendurado num 3850 do campus. O gerenciamento em cobre subiu sem drama, os uplinks de 10G não: assim que o servidor liga, a porta do switch cai em err-disable e o host não vê nada naquela vmnic.
- Lenovo ThinkSystem SR650, 7X06CTO1WW, com um adaptador Emulex VFA5.2 2x10GbE SFP+
- Módulos Lenovo 10GBASE-SR, 46C3447, no adaptador
- Cisco WS-C3850-24XS-S com Cisco SFP-10G-SR do lado do switch
- Cordão OM3 LC-LC entre eles
Te1/0/7: goes err-disabled within seconds of the server powering on
ESXi: the uplink shows DISCONNECTED
Same patch cord, Cisco SFP-10G-SR at both ends switch to switch: link up and stableJá tentei:
- movi o servidor para outra porta no mesmo switch, mesmo comportamento
- troquei o 46C3447 pelo gêmeo da outra porta do adaptador
- cordão novo, limpei e reencaixei as duas pontas
A fibra e a óptica do lado do switch claramente estão boas, então alguma coisa está rejeitando o módulo Lenovo. Qual lado está fazendo essa rejeição aqui, o servidor ou o switch, e existe um jeito de fazer o 3850 conviver com isso?
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
Esse log resolve a questão.
gbic-invalidé o switch recusando o que ele lê como um módulo não autorizado, e a checagem que dispara mora do lado do Cisco, não no SR650 e não no ESXi. Ele rejeita a óptica SR codificada como Lenovo nesse link e mata a porta antes mesmo do link ser avaliado, e é por isso também que trocar de porta e trocar de cordão não mudou nada pra você.Duas linhas na configuração global:
A primeira diz ao switch para seguir em frente com um módulo que ele não reconhece, a segunda impede o err-disable de derrubar a porta quando essa checagem de CRC falha. Nenhuma das duas é retroativa, então reinicie a porta depois e reencaixe a fibra enquanto ela está desativada:
Salve a configuração assim que ela subir. Se ficar só na running config, a porta volta em err-disable no próximo reload e você vai debugar isso de novo num momento bem pior.
Duas ressalvas. Agora você está fora da configuração suportada pela Cisco: eles consideram ópticas de terceiros não testadas e o TAC pode recusar um caso de interoperabilidade que envolva uma, o que importa se esse link estiver sob contrato. E
service unsupported-transceivernão é uma solução universal. A mesma mensagem de bad crc sobrevive a ele quando o problema é a própria porta, por exemplo um slot SFP só de 1G com um módulo de 10G enfiado nele, então se a porta continuar down depois do reinício, confira em que velocidade cada lado está rodando de fato antes de culpar a óptica de novo.Antes de alguém ficar chutando: o que o switch realmente registra no log quando a porta cai? O err-disable sempre nomeia a causa, e a causa muda completamente a resposta. Uma reclamação de segurança ou de CRC sobre um módulo é um problema diferente de um flap ou de um problema de protocolo, e o remédio de um não faz nada pelo outro.
Puxe o
show loggingde perto do momento em que o servidor liga e poste as linhas daquela porta. Confirma também o que está fisicamente encaixado na Te1/0/7, você disse Cisco SFP-10G-SR, então o 46C3447 é a única peça não Cisco em todo esse caminho?Log do momento em que cai, duas linhas para aquela porta:
Então é a checagem de segurança disparando, não um flap. E sim, a ponta do switch é um Cisco SFP-10G-SR genuíno, tirado de uma caixa Cisco, o 46C3447 no servidor é a única peça codificada como Lenovo em todo o caminho. O que foi o que me confundiu, porque a mensagem nomeia a porta no switch e não nada do lado do servidor.