English 
Русский 
简体中文 
Español 
Deutsch 
Français 
Português 
Italiano 
日本語 
한국어 
Türkçe 
Polski 
Nederlands 
العربية 
हिन्दी 
Bahasa Indonesia 
Tiếng Việt 
ไทย 
বাংলা 
اردو 
Kiswahili 
Oʻzbekcha 
አማርኛ 
فارسی 
繁體中文 
Bahasa Melayu Como cada NOS valida um módulo
Entre “module detected” e “port up”, todo sistema operacional de rede executa uma verificação da identidade do módulo. O que ele compara, o que faz quando a comparação falha e se um administrador pode contornar isso variam por fabricante, plataforma e versão — e essa diferença é todo o assunto da compatibilidade de transceptores. Esta página coloca os comportamentos lado a lado, conforme documentado pelos fabricantes e observado em campo, para que um módulo lido na bancada possa ser avaliado em relação ao equipamento ao qual se destina.
O que pode ser verificado
| Verificação | Bytes envolvidos | Quem faz |
|---|---|---|
| Somas de verificação CC_BASE / CC_EXT | SFP 63/95, QSFP 191/223, CMIS 222/255 | quase todos — uma falha é invalid EEPROM (Somas de verificação) |
| Consistência de identificador / conector / codificação | SFP 0, 2, 11; QSFP 0, 130, 139 | a maioria; tipos desconhecidos são exibidos como tal |
| Códigos de conformidade vs. porta | SFP 3–10, 36; QSFP 131–138, 192; aplicações CMIS | a maioria — speed and type not supported (Códigos de conformidade) |
| Nome do fabricante + número de peça comparados a uma lista | SFP 20–35, 40–55; QSFP 148–163, 168–183 | plataformas estritas e semiestritas (Numeração de partes) |
| Assinatura específica do fabricante | área do fabricante (SFP 96–127, QSFP 224–255, personalizada no CMIS) | poucos OEMs; um hash vinculado ao número de série |
| Formato do número de série / código de data | SFP 68–91; QSFP 196–219 | raro; engenheiros de suporte verificam manualmente |
| Classe de potência vs. porta | SFP 64; QSFP 129/107; CMIS 200–201 | todos que implementam gerenciamento de energia (Energia e aspectos térmicos) |
Comportamento por fabricante
Comandos e comportamentos públicos conforme as versões recentes; os detalhes variam por plataforma e versão.
| Fabricante / NOS | Verificações | Em caso de falha | Override | DDM para terceiros |
|---|---|---|---|---|
| Cisco IOS / IOS-XE (Catalyst, ISR) | lista de fabricante/PN e uma verificação específica do fabricante; checksums | %PHY-4-UNSUPPORTED_TRANSCEIVER, porta em errdisable (gbic-invalid), laser desligado | service unsupported-transceiver (oculto) + no errdisable detect cause gbic-invalid; não em todas as plataformas; não suportado pelo TAC | exibido após aceito; alguns campos em branco |
| Cisco NX-OS (Nexus) | como acima, menos estrita em muitas plataformas de DC | geralmente up com um log; SKUs estritos entram em errdisable | service unsupported-transceiver | geralmente exibido |
| Cisco IOS-XR | lista de módulos ópticos por plataforma, classe de potência | estado unsupported, a porta pode permanecer down | limitado; depende da plataforma | parcial |
| Arista EOS | checksums, consistência de tipo | registra unsupported no log; o enlace sobe | nenhum necessário | completo |
| Juniper Junos | lista de fabricante/PN para o rótulo “supported”, checksums | o enlace geralmente fica up; show chassis pic marca como unsupported; algumas plataformas EX/QFX retêm o DDM ou as velocidades para PNs desconhecidos | nenhum oficial | completo para PNs conhecidos, parcial para desconhecidos |
| Huawei VRP | fabricante/PN; não Huawei → alarme | enlace up com alarmes recorrentes de transceptor phony; algumas plataformas restringem | transceiver phony-alarm-disable (system view) | completo |
| H3C Comware | como o VRP | alarme | transceiver phony-alarm-disable | completo |
| HPE Aruba AOS-S / AOS-CX | lista de fabricante/PN | unsupported, porta down | allow-unsupported-transceiver | completo |
| Dell OS10 / OS9 / PowerConnect | checksums; alguns equipamentos mais antigos fazem verificação por lista | log; mais antigos: errdisable | service unsupported-transceiver (mais antigos) | completo |
| Extreme EXOS / VOSS | checksums, tipo | log, up | — | completo |
| Ruckus/Brocade ICX (FastIron) | checksums; monitoramento óptico apenas para PNs Brocade em alguns modelos | up; o DDM pode estar ausente | — | parcial |
| Brocade FOS (SAN) | PN e número de série da marca Brocade exigidos na maioria das plataformas Gen 5/6/7 | porta Mod_Inv, não habilitada | nenhum | somente módulos ópticos Brocade |
| Nvidia/Mellanox (Onyx, Cumulus, IB) | Ethernet: checksums, tipo; InfiniBand: informações do cabo validadas pelo fabric manager | Ethernet up com log; o IB pode rodar em velocidade reduzida ou sinalizar | — | completo |
| SONiC / white-box | plugin de plataforma: checksums, parsing de CMIS | up; campos desconhecidos exibidos em bruto | — | completo (depende do plugin) |
| MikroTik RouterOS / SwOS | nada além do parsing | up | — | completo |
| Ubiquiti | nada além do parsing | up | — | completo |
| Server NICs (Intel, Broadcom, Mellanox) | listas de permissão (whitelist) do driver em algumas famílias Intel | o driver recusa subir a porta | parâmetro de módulo allow_unsupported_sfp=1 (Intel ixgbe/i40e) | via ethtool -m |
Quando existe um override do fabricante, ele geralmente é oferecido as is: o módulo funciona, mas o fabricante não se compromete a dar suporte à combinação. As decisões de frota cabem ao dono da rede (Módulos ópticos de terceiros).
O que “codificado para o fabricante X” precisa satisfazer
| Classe de plataforma | Mínimo para aceitação | Também recomendável |
|---|---|---|
| Permissiva (Arista, SONiC, MikroTik, Extreme…) | checksums válidos, códigos de tipo consistentes | nome de fabricante e PN reais — nada a ganhar com a codificação OEM |
| Verificação por lista (Juniper, Aruba, Huawei/H3C, NX-OS em muitos SKUs) | nome de fabricante e PN exatamente como na lista da plataforma, códigos de conformidade corretos para a porta | sufixo/grau de PN compatível; número de série e código de data realistas |
| Verificação por assinatura (Cisco IOS/IOS-XE, alguns XR) | tudo o que foi dito acima, mais a área específica do fabricante calculada para esse número de série | campos de identidade consistentes com o PN (comprimento de onda, alcance, tecnologia) |
| Somente marca (Brocade FOS) | string de fabricante Brocade e família de PN, formato de número de série | — |
Como funciona o lado da bancada: Bloqueio do fabricante e codificação, Recodificação de EEPROM.
Interpretando a rejeição
| Texto de log / status | Significado | Próximo passo |
|---|---|---|
unsupported transceiver, Mod_Inv, phony | identidade fora da lista | override, ou codificar para um PN listado |
invalid EEPROM, checksum error | CC_BASE/CC_EXT incorreto | recalcular (Somas de verificação) |
speed and type not supported, unknown media type | os códigos de conformidade não combinam com a porta | corrigir os códigos ou usar outro modo de porta (Velocidade e taxa) |
power class exceeds, preso em LowPwr | classe de potência vs. gaiola (cage) | Energia e aspectos térmicos |
Module not ready, o estado DP trava | bring-up do CMIS | Problemas de CMIS |
Comandos por NOS para ver esses estados: Verificando módulos ópticos em um switch.
Mudanças nas atualizações de software
Os fabricantes tornam as verificações mais rígidas ou mais permissivas entre versões: nova validação de assinatura, novas listas de módulos ópticos suportados, comandos ocultos removidos, tratamento de DDM alterado. Uma frota de módulos ópticos de terceiros ou codificados que funcionava ontem pode entrar em errdisable depois de uma atualização (Matrizes de compatibilidade e firmware).
No CodingBox
O CodingBox mostra os bytes exatos que cada verificação acima lê — nome do fabricante, PN, checksums, códigos de conformidade, classe de potência — e o code database guarda as identidades que uma determinada classe de plataforma aceita. Verifique em uma porta de teste depois de codificar; quem tem a palavra final é o switch, não a bancada (Check transceiver).
A contrapartida do lado do servidor — listas de permissão de driver por fabricante de NIC, overrides da Intel, comportamento no Windows e no ESXi: Compatibilidade de transceptores em NICs.