Ópticas SFP+ third-party ficam down em um DCS-7150S-24 de segunda mão: o arquivo enable3px na flash ainda é uma opção
Peguei alguns switches Arista de segunda mão para o laboratório e esbarrei direto na trava de ópticas. Módulos codificados Arista linkam, cabos DAC passivos linkam, e qualquer coisa third-party deixa a porta down.
O lado do laboratório:
- DCS-7150S-24, comprado usado, sem contrato de suporte e sem account team por trás de mim
- módulos SFP+ third-party variados
- cabos DAC passivos para os trechos curtos dentro do rack
Et1 passive DAC -> link comes up
Et5 third-party SFP+ -> port stays down
Et6 Arista-coded SFP+ -> link comes upO que já descobri até agora:
- o DAC subindo enquanto as ópticas não me diz que isso é uma checagem de coding, não cabeamento e não gaiola morta
- existe um comando de configuração no formato
service unsupported-transceiver CUSTOMERNAME LICENSEKEY, que obviamente quer uma chave que não tenho como conseguir - relatos mais antigos mencionam um arquivo marcador na flash em vez de uma chave, mas não consigo saber a qual geração isso se aplica
Qual dos dois mecanismos é o certo para uma caixa dessa idade, e o arquivo na flash ainda é uma opção em um 7150S, ou a chave é o único caminho que sobra?
Comments 6
Nessa geração é o arquivo, e é tão tosco quanto parece. Do CLI do EOS:
Um arquivo vazio, nada dentro dele - a mera presença liga as ópticas third-party depois do reload. A lista de plataformas onde isso funciona é longa: DCS-7120T-4S, a família DCS-7050 e toda a linha DCS-7150S entre outras, e cada modelo tem uma release mais nova do EOS que ainda respeita o arquivo, variando mais ou menos de 4.13.16M nas caixas mais antigas até o trem 4.23 no 7150S. Switches mais novos ignoram o arquivo completamente.
Então um 7150S-24 está do lado bom dessa linha, desde que você não tenha passado do que o modelo suporta. Tente isso antes de chegar perto do caminho da chave.
Que trem de EOS está nesse 7150S-24, e você atualizou depois de comprar? Isso importa, porque o corte é por plataforma e não por família. O arquivo de flag está documentado como funcionando no 7048T, no 7120T-4S, no 7140T-8S, nas variantes SFP+ 7124 e 7148, na série 7050 e 7150S e nos line cards 7548S-LC, mas a última release de EOS que ainda respeita ele difere para cada um deles.
Se você já atualizou o EOS em uma caixa usada, tem uma boa chance de você mesmo ter se atualizado para fora do truque, e aí o conserto barato é voltar um trem em vez de caçar uma chave.
Nunca mexi no EOS desde que a caixa chegou, então continua em qualquer trem que o vendedor deixou - o que acabou sendo sorte. Fiz o touch, write memory, reload - e os módulos SFP+ third-party que estavam mortos antes agora sobem como portas normais. Sem chave, sem account team, nada mais necessário. Os DACs continuaram funcionando o tempo todo, como esperado.
Para quem chegar aqui com uma caixa mais nova: o arquivo é genuinamente ignorado lá, e o único caminho é uma chave criptográfica por cliente que mora na running configuration como
A chave vem do account team ou do time de vendas, não do suporte - o TAC não tem autorização para emitir chaves de unlock e vai te mandar de volta para o account management, o que é um beco sem saída quando o switch veio do mercado de segunda mão.
Vale repetir para montagens de laboratório: cabos DAC passivos são aceitos por padrão qualquer que seja o estado de unlock. Se os trechos forem curtos o bastante, você contorna a questão inteira cabeando com DAC e guardando as ópticas para os links que realmente precisam delas.
Pequena correção a "mora na running configuration": no código mais antigo com que trabalhei também existia uma variante não documentada do mesmo comando, então se você encontrar uma referência que não bate com a sintaxe acima, é de lá que ela vem, não alguém digitando errado.
Na minha experiência a chave também fazia efeito sem reboot - a maioria das ópticas third-party começava a funcionar assim que o comando era digitado, embora alguns módulos ainda recusassem não importa o quê. Isso foi há um tempo em hardware que não tenho mais, então confira na sua própria caixa antes de planejar uma janela de manutenção em cima disso.
Já que essa comparação sempre aparece quando o assunto surge: no Cisco IOS-XE e IOS XR o equivalente são dois passos em vez de um. O comando global sozinho não basta, você também precisa do comando por interface em cada porta física que deve aceitar o módulo:
A linha por interface é a que pula a checagem de product-ID, então a porta pelo menos vai tentar acender a óptica - nenhuma promessa de que o módulo depois funciona, só que a plataforma para de recusá-lo. Já fiz isso em IOS XR 5.3.3 e em caixas IOS-XE.
A ressalva é a mesma nos dois vendors, e é a razão pela qual as pessoas continuam discutindo isso: se um defeito é rastreado até um transceiver third-party instalado pelo cliente, o suporte sob garantia ou contrato pode ser negado. Tranquilo para um laboratório, uma decisão que vale a pena tomar conscientemente em produção.