EX4200 reporta a EEPROM do SFP+ como mal programada depois de um upgrade do Junos, enquanto um MX960 ainda mostra DOM
Rodamos alguns enlaces DWDM de 80 km saindo de EX4200 com óptico de terceiros nas duas pontas, porque as peças DWDM da marca do fabricante nunca iam caber no orçamento. Isso funcionou bem por anos. Depois que as caixas EX foram para o Junos 12.3, os ópticos continuam nas mesmas portas e os enlaces continuam existindo, mas o switch parou de admitir que os módulos são ópticos, ponto.
- EX4200, Junos 12.3 (o DOM funcionava bem no 11.4 no mesmo chassi)
- Integra SFPP-C51-80-10GD, SFP+ DWDM 80 km
- MX960 na outra ponta do mesmo enlace, part number idêntico, DOM ainda completo
user@ex4200> show interfaces diagnostics optics xe-0/1/0
Physical interface: xe-0/1/0
Unknown cableO log de mensagens imprime exatamente uma linha quando o módulo é inserido: SFP+ of type 0 EEPROM is Mis Programmed.
O que já descartei:
- reencaixei o óptico e movi ele para outra porta no mesmo chassi, sem mudança;
- testei um EX3300 e um QFX5100 sobressalentes no laboratório, os dois se comportam do mesmo jeito, então não é uma caixa quebrada isolada;
- verifiquei a outra ponta de novo, o MX960 dá diagnóstico completo para a mesma peça do mesmo pedido.
Então o driver do EX está impondo alguma coisa na EEPROM que a versão mais antiga simplesmente ignorava? E se for isso, dá para fazer alguma coisa no próprio óptico, ou essa é uma conversa para ter com o fornecedor?
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
Essa linha de log não é uma reclamação genérica, é o driver dizendo qual checagem falhou.
Os bytes de 3 a 10 da página A0 guardam os códigos de compliance do transceptor descritos na SFF-8472 - os bits que dizem 10GBASE-SR, LR, ER, os códigos SONET, os de Fibre Channel e assim por diante. Nesse tipo de óptico os oito bytes são todos zero, e é por isso que a mensagem chama de type 0. A especificação espera que pelo menos um bit em algum lugar desse campo esteja setado; um campo de compliance todo zerado não é uma descrição de módulo válida. O código antigo do EX nunca olhava isso e ia direto para o parsing da página de diagnóstico, o driver mais novo valida o campo primeiro e depois recusa tratar o módulo como um óptico 10G conhecido. Daí o unknown cable e o DOM ausente. A linha MX não roda essa checagem no mesmo caminho, e é exatamente por isso que a mesma peça ainda funciona lá.
Prove isso antes de discutir com alguém: caia no shell e dê xcvrpeek na página A0 dessa porta, depois olhe os offsets de 3 a 10. Tudo zero fecha o caso.
Consertar isso no lugar é onde normalmente desanda. Em teoria, o xcvrpoke escreve esses mesmos bytes de volta. Na prática, muitos fabricantes travam a página A0 e a escrita retorna EIO, e não tem nada que você possa fazer sobre isso do lado do switch. O que sobra é o fornecedor: ou eles mandam ópticos programados com códigos de compliance reais, ou mandam com a A0 destravada para você mesmo setar os bits. Se não conseguem fazer nem uma coisa nem outra, isso é um problema de fornecedor fantasiado de problema do Junos.
Duas coisas vale a pena confirmar antes de qualquer um começar a chutar.
Primeiro, a versão exata em cada caixa. Você diz que o EX foi para o 12.3, mas o que o MX960 está rodando? Se ainda estiver numa versão mais antiga, as duas caixas não são realmente comparáveis e a diferença ainda não diz nada.
Segundo, a peça do lado do MX é literalmente o mesmo SFPP-C51-80-10GD do mesmo lote, ou o mesmo modelo de um pedido diferente? Lotes diferem mais do que qualquer um gostaria.
Poste
show interfaces diagnostics opticsdas duas pontas, mais tudo que o log de mensagens imprime quando você tira e reinsere o óptico, não só a linha que você já citou.Mesma peça nas duas pontas, SFPP-C51-80-10GD, mesmo pedido, seriais consecutivos.
No MX960,
show interfaces diagnostics opticsdá o conjunto completo: temperatura, corrente de bias do laser, TX power, RX power. No EX4200, o mesmo comando imprime o cabeçalho da interface e depois a linha unknown cable, nada mais. Reinserir o óptico produzSFP+ of type 0 EEPROM is Mis Programmedno log e nada além disso, não importa qual porta eu use.O que me incomoda é que, antes do upgrade, esse óptico exato nesse chassi e nessa porta exatos reportava DOM sem uma palavra de reclamação.
Vale acrescentar que a metade somente leitura disso existe do outro lado da cerca também. Na Cisco,
show idprom interface <if> detaildespeja os bytes de identificação sem nenhuma ginástica de shell, o que é útil para checar um lote num switch sobressalente antes de os módulos chegarem perto de uma caixa Juniper.Ler é inofensivo em qualquer lugar. Escrever a partir do host é outro animal: xcvrpoke é uma ferramenta interna, não é suportada como forma de consertar módulos, e como já dito é bloqueada pelo vendor lock em metade dos casos de qualquer jeito. Use para provar o que está errado na EEPROM, depois entregue essa prova para quem te vendeu o óptico.
Mesma classe de problema, sintoma completamente diferente, para o caso de alguém cair aqui vindo de uma busca.
Colocamos um SFP WDM BiDi de 1G sem marca na ge-0/0/1 de um EX4600 e a interface simplesmente não existia. Ausente do
show interfaces terse, e qualquer comando contra ela voltava comerror: device ge-0/0/1 not found. O log diziaOPTIC State changed for port: 0/0/1e depoisFibre channel transceiver plugged in without Fibre channel configuration!!. A EEPROM estava codificada de um jeito que o Junos classificava o módulo como um transceptor Fibre Channel em vez de Gigabit Ethernet, então nenhuma interface Ethernet chegava a ser criada para ele. Nenhuma quantidade de configuração conserta isso; um módulo codificado corretamente sim.E não é só na ponta barata do mercado. Teve um lote de SFP+ 10G de marca Citrix que fazia appliances NetScaler MPX e SDX registrarem
*** Unsupported SFP+/SFP type !no boot, nas próprias peças do fabricante. As unidades boas trazem uma marcação de revisão A2 na etiqueta, as ruins voltaram em RMA. Codificação errada acontece em qualquer faixa de preço.Confirmado, e obrigado pelos offsets precisos.
xcvrpeek na página A0 mostra os offsets de 3 a 10 como zeros em cada uma dessas unidades SFPP-C51-80-10GD que verifiquei, incluindo as que ainda estão na caixa. O xcvrpoke volta na hora com EIO, então a A0 está travada e não tem nada para salvar do nosso lado.
Voltei ao fornecedor com os offsets de byte e a linha de log citada. Eles aceitaram e estão recodificando o lote com códigos de compliance reais; as unidades que estão no MX960 ficam onde estão, já que nada nessa plataforma reclama. Marcando a explicação acima como resposta.