SFP+ DWDM de terceiros fica down em um Arista 7050T com EOS 4.10.6 - existe algo além de remendar a imagem?

Antes de alguém te mandar para o caminho da imagem, duas coisas.

Em qual trem de EOS você está realmente preso nesse 7050T? Se ele tem que ficar na 4.10.6, então um hack específico para o build pelo menos é consistente. Se dá para mover, entenda que o tratamento de transceptor foi reorganizado nas releases posteriores, e nenhuma receita escrita para a 4.10.6 se transfere.

E o que esse fornecedor realmente consegue gravar neles? Vale perguntar se o programador deles carrega um perfil Arista, ou só a codificação Cisco por plataforma que a maioria deles mantém - peças ASR9K, por exemplo, precisam do próprio perfil, e os vendors de óptica mantêm um. Recodificar o lote sai bem mais barato do que viver com uma imagem modificada. Separadamente: você já pediu ao seu account team a chave de unsupported-transceiver, ou isso está fora de cogitação por motivos comerciais?

O patch de imagem funciona sim nesse build exato, e não dá muito trabalho - mas faça isso numa caixa de laboratório ou sobressalente, nunca em algo carregando tráfego.

O formato: descompacte o EOS-4.10.6.swi e guarde os membros, que são boot0, initrd-i386, linux-i386, rootfs-i386.sqsh e version. Descompacte o sistema de arquivos raiz como root, edite o agente, empacote de novo:

unsquashfs rootfs-i386.sqsh
mksquashfs squashfs-root/ rootfs-i386.sqsh
zip -Z store EOS-4.10.6a.swi boot0 initrd-i386 linux-i386 rootfs-i386.sqsh version

A edição em si fica em squashfs-root/usr/lib/python2.7/site-packages/XcvrAgent.py: comente as quatro linhas perto da linha 172 que verificam o estado de presença e depois rodam a autenticação do transceptor. O -Z store no zip não é opcional, o swi precisa continuar sem compressão ou a caixa não vai dar boot nele.

Depois disso as portas sobem com qualquer coisa que você conectar, porque nada mais está validando. Dois preços: você fica sem suporte do vendor numa imagem modificada, e o patch está preso a esse build, então mantenha o .swi original na flash para voltar a dar boot nele quando algo der errado.

Respondendo às perguntas acima: a caixa é sobressalente e sem contrato de suporte, e o fornecedor não tem nenhum perfil Arista no programador deles - eles codificam para plataformas Cisco e é isso, fim da lista, então recodificar esse lote não está em oferta. O caminho do account team não está fora de cogitação, só que não me ajuda essa semana.

Reconstruí a 4.10.6 como descrito, dei boot na imagem com o patch, e as duas portas DWDM subiram na primeira tentativa. A imagem original continua na flash. O link está estável desde então, e a ponta remota não vê nada de anormal.

Bom que funcionou, mas seja honesto consigo mesmo sobre a vida útil desse patch, porque o tópico acima dá a entender que é mais geral do que realmente é.

Ele está escrito para a 4.10.6 e mais nada. Já perguntaram como repetir isso na 4.14.5F, na 4.14.7M e na 4.23.8M, e ninguém nunca postou uma resposta que funcionasse, porque o gerenciador de transceptor foi reorganizado nas releases posteriores, e essas quatro linhas não estão lá esperando por você. Todo upgrade também substitui a imagem, então o patch some e as portas caem na próxima vez que alguém fizer manutenção de rotina.

Os caminhos que sobrevivem a um upgrade são a chave service unsupported-transceiver específica do cliente que o account team emite, e nas plataformas mais antigas o arquivo marcador enable3px. Use a imagem com patch para manter uma caixa antiga útil, não como padrão para a rede.

Mesma briga do lado Cisco, com um detalhe que vale a pena trazer aqui. SFP+ DWDM de terceiros de 80 km (Pro10Optix, rotulado SFP-10G-DWDM-192) vinha rodando em switches Catalyst 6500 sem reclamar. Movidos para as portas SFP+ embutidas de um ASR 9001 no IOS XR 5.3.3, eles deram:

%PLATFORM-SFP-3-DEV_SFP_SUPPORTED_ERROR: SFP Module is not supported
%PLATFORM-SFP-3-DEV_SFP_PID_NOT_SUPPORTED: Not supported Product ID

LED da porta vermelho, interface down, estado reportado como perda de link ou pouca luz sem loopback, comprimento de onda lido como 0 nm e o laser nunca disparando. transceiver permit pid all na interface não mudou nada sozinho, e o service unsupported-transceiver global por cima também não salvou esse lote. A plataforma espera um part number no formato DWDM-SFP10G-xx.yy da própria matriz de ópticas, e um PID genérico não mapeia para nenhuma óptica suportada, então não há nada para o override relaxar.

Outra pessoa na mesma release conseguiu módulos Skylane SPDTU080100D139 de 80 km funcionando num 9001 - mas só com os dois comandos configurados, senão a interface não se recuperava depois de uma queda de link. O lote com problema acabou sendo trocado por módulos codificados corretamente.

Acrescentando algo que poupa uma ida e volta na hora de falar com um fornecedor: peça para eles codificarem para a plataforma, não para a marca. Boa parte desses tópicos são módulos que se identificam com o vendor certo, mas carregam um part number que a matriz da plataforma nunca ouviu falar, e overrides do tipo permit só relaxam a checagem para módulos que já parecem certos para a caixa.

Enquanto eles têm os módulos na bancada, peça para confirmarem que a EEPROM segue estritamente o SFF-8472. Dados A2h malfeitos voltam como lixo - o comprimento de onda de 0 nm mencionado acima é exatamente desse tipo - e, uma vez que a leitura esteja limpa e a plataforma ainda recuse a peça, você tem algo concreto para levar ao suporte do vendor, em vez de um argumento genérico sobre óptica de terceiros.