Matrizes de compatibilidade, release notes e mudanças de firmware

“Suportado” é uma afirmação sobre um trio: este módulo, nesta plataforma, nesta versão de software. Os fabricantes publicam esse trio em matrizes de compatibilidade e notas de versão, e o alteram — módulos ópticos novos aparecem, os antigos saem de linha, as verificações ficam mais rígidas. Ler as matrizes antes de comprar e relê-las antes de atualizar é o trabalho de compatibilidade mais barato que existe. Esta página mostra onde essa informação está, como lê-la, e como operar uma frota para que uma atualização de software não se transforme em uma interrupção dos módulos ópticos.

Onde os fabricantes publicam o suporte

Leia também as notas de versão do NOS que você utiliza: mudanças relacionadas a módulos ópticos se escondem em “resolved issues”, “behaviour changes” e “new hardware support”.

Como ler uma entrada da matriz

O que muda com o software

Uma prática de frota que evita surpresas

1. Inventário — registrar fabricante, PN, número de série, revisão e firmware de cada módulo por porta (a partir do switch ou da bancada) no CMDB.
2. Fixar versões — tratar a versão do NOS como parte do trio de compatibilidade; não atualizar acesso e core no mesmo dia.
3. Ler as notas de versão em busca de itens relacionados a módulos ópticos antes de cada atualização.
4. Testar em um switch de laboratório ou canary com um exemplar de cada tipo de módulo óptico em uso — primeiro os módulos de terceiros e codificados.
5. Manter a imagem anterior e um plano de rollback; saber quais portas são propensas a errdisable.
6. Estabelecer a linha de base de DDM antes e depois, para que mudanças de comportamento fiquem visíveis no monitoramento (Monitoramento).
7. Acompanhar o EOL dos PNs de módulos ópticos e de seus sucessores, para que as substituições correspondam à matriz.

Módulos ópticos de terceiros e codificados neste cenário

Um módulo codificado com um PN de OEM é avaliado pela mesma entrada da matriz que o original — a plataforma não consegue perceber a diferença se a codificação estiver completa — mas a declaração de suporte do fabricante não se estende a ele, e uma verificação mais rígida em uma nova versão pode expô-lo. Mantenha os módulos codificados identificáveis no inventário (seu fabricante e número de série reais), teste-os primeiro nas atualizações, e planeje-se para o caso em que uma versão feche essa porta (Módulos ópticos de terceiros, Bloqueio do fabricante).

Lado de NIC e servidor

Os adaptadores de servidor têm suas próprias matrizes (adaptador ↔ módulo ↔ driver/firmware) e suas próprias políticas — algumas famílias Intel recusam SFPs não listados, a menos que um parâmetro de driver os permita; adaptadores Mellanox/Nvidia validam cabos para InfiniBand. Atualizações de driver e firmware mudam essas regras tanto quanto as atualizações do NOS (Receitas de configuração de porta).

No CodingBox

O lado de bancada dessa prática de frota: registrar a identidade e a versão de firmware de cada módulo no code database já na inspeção de entrada, comparar os bytes de um módulo suspeito com a entrada da matriz em Check transceiver, e manter a distinção codificado/original nas notas do banco de dados, para que uma rejeição no dia da atualização possa ser rastreada até o módulo em segundos.

Políticas de driver e firmware de NIC em detalhe, por fabricante e sistema operacional: Compatibilidade de transceptores em NICs.

A prática de frota como lista de verificação de comissionamento — atualizar antes de configurar, testes canary, linha de base de DDM, teste de aceitação: Seleção e comissionamento.