Adaptador QSA em uma gaiola QSFP28 com SONiC: a óptica de 10G linka mas não reporta DDM
Estamos reaproveitando uma pilha de ópticas de 10G em um switch whitebox rodando SONiC, então algumas gaiolas QSFP28 receberam adaptadores estilo QSA (10GTek QSA-100A) carregando módulos SFP+ de 10G comuns. Mecânica e eletricamente está tudo certo. O lado do management é onde tudo desanda.
- switch: whitebox 1U, SONiC compilado para essa plataforma
- adaptadores: 10GTek QSA-100A, gaiola QSFP28 para SFP+
- ópticas: módulos SFP+ de 10G retirados de um switch de acesso desativado
- as mesmas ópticas leem normalmente em uma gaiola SFP+ nativa em outro equipamento
O que vejo nas portas adaptadas:
QSFP28 cage -> QSA-100A -> 10G SFP+
link: up, traffic passes
inventory: port still handled as a QSFP cage
DDM/DOM: nothing returned for the portO que já tentei:
- troquei por um segundo adaptador e uma segunda óptica, comportamento idêntico;
- movi o par para outra gaiola QSFP28, mesmo resultado;
- confirmei que as ópticas reportam diagnóstico completo em uma porta SFP+ nativa em outro lugar.
A falta de dados de diagnóstico é algo que um adaptador passivo simplesmente não consegue carregar, ou isso é do lado do software do switch? E se for software, onde fica o conserto: na camada de plataforma ou no código genérico de transceiver?
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 7
Antes de alguém se enfiar no código da plataforma, uma pergunta que separa os dois casos. Coloque um módulo QSFP28 nativo nessa mesma gaiola: você tem diagnóstico dele, ou o DDM está morto nessa porta não importa o que você conecte?
Se a parte nativa lê certinho, a gaiola e o caminho I2C estão saudáveis e tudo se resume a como o driver da porta interpreta o que chega pelo adaptador. Se a parte nativa também vem em branco, pare de ler o resto do tópico, você tem um defeito diferente que não tem nada a ver com adaptadores.
Diferença bem conhecida e bastante chata na interface de management, e o adaptador não é o culpado aqui.
Do lado SFP entram em jogo dois endereços I2C: os dados de identificação moram em 0x50, o mapa de diagnóstico em 0x51. Uma peça QSFP guarda tudo sob 0x50 e alcança o resto trocando de page. Então um driver que foi informado que a gaiola é QSFP vai caçar pages em um único endereço e nunca pergunta nada a 0x51. A identificação volta plausível o bastante para a porta subir, o diagnóstico simplesmente nunca resolve, exatamente o formato do que você postou.
O conserto pertence à camada de plataforma, não à óptica e não ao adaptador. Cada plataforma traz sua própria implementação de SfpUtil; na sua, essa porta precisa ser declarada como gaiola SFP em vez de QSFP. Até alguém fazer isso, o DDM/DOM nas portas adaptadas continua vazio. Depois disso o módulo é lido do mesmo jeito que seria em uma gaiola SFP+ nativa.
Um link ativo sem nada por trás no diagnóstico é a cara de software errado nessas portas. Não é a cara de uma óptica no limite.
Vale nomear os padrões, porque aí a separação fica óbvia. O lado SFP é o SFF-8472, onde o diagnóstico mora em seu próprio mapa de memória alcançado pelo segundo endereço. QSFP e QSFP28 seguem o SFF-8636, e as peças mais novas o CMIS, onde tudo pende de um único endereço atrás de um page select.
O adaptador não consegue fazer essa ponte. É uma peça passiva, mecânica e elétrica, os fios de management passam direto por ele e nada os traduz no caminho. Então o host precisa ser informado qual dos dois modelos de memória se aplica antes de ler um único byte, e o adaptador não tem como avisar isso.
Em contraste, a mesma classe de problema em hardware Dell ONIE morde mais forte. Um QSA 407-BBRO com um SFP+ 10GBASE-SR 407-BBOU dentro (SFP-10GSR-85), nas portas de 40G de um S4048-ON e em qualquer porta de um S6010-ON, ambos rodando OpenSwitch OPX 3.1 dev2:
O opx-ethtool identifica a mídia corretamente, marca o transceiver como enabled e qualified, admin state up, velocidades suportadas 1000, 10000 e 40000 Mbps, e a porta mesmo assim nunca sobe, seja qual for a velocidade, duplex ou autoneg configurados, defaults incluídos. Alguém abriu isso no repositório OPX platform-config como enhancement request, please make the QSA work here, e ninguém nunca respondeu. Continua aberto até hoje.
Não é vendor lock nem óptica ruim. Essa gaiola simplesmente nunca é colocada em modo adaptador pelo network OS, e nenhuma combinação de configurações de interface vai fazer isso por você.
Relacionado, mas não misture os dois casos. O que o post original tem é um link funcionando com diagnóstico ausente: o caminho de dados está bem, só a leitura de management está errada, e corrigir o SfpUtil da plataforma resolve. O caso da Dell é uma porta que nunca sobe de jeito nenhum, porque o port profile daquela gaiola nunca chega a ser aplicado. Isso fica uma camada abaixo e precisa do seu próprio conserto.
Alguém comparando sintomas com pressa pode torrar um dia reescrevendo código de transceiver enquanto a porta dele está down por um motivo completamente diferente.
Mais uma variação de "o adaptador é um recurso de software" em vez de mecânico. Em um Z9264F-ON com OS10 10.5.2.7, usar adaptadores QSA28 para mídia SFP+ de 10G significa colocar a porta no mesmo port-group profile que um cabo breakout 4x10G usa:
Port-group profiles nessa plataforma agem sobre pares de portas QSFP28, então aplicar um desativa a porta parceira de cada par. Um QSA28 é uma interface única e mesmo assim você paga o preço de um breakout: 64 portas utilizáveis viram 32. Nem os guias de usuário do OS10 nem a planilha de especificações de ópticas da Dell documentam um modo QSA de porta única.
Se você precisa de bastante 10G nativo nessa caixa, planeje a perda de 2:1 desde o início ou coloque um switch 10G separado no rack.
Antes de alguém encomendar uma bandeja dessas coisas, eu colocaria duas checagens na lista. O network OS declara suporte a QSA para essa plataforma exata, e se declara, o que ligar isso custa: portas, diagnóstico, ou um profile que arrasta a gaiola vizinha junto. Encaixe nunca é o problema, todos esses adaptadores entram na gaiola sem reclamar.
Os casos nesse tópico diferem só em até onde o software vai. No SONiC você tem algo que pode consertar sozinho, declare a porta como SFP e o diagnóstico volta. Nas plataformas Dell acima você está esperando o código de plataforma de outra pessoa, e trocar adaptadores ou ópticas não muda nada nisso.