English 
简体中文 
繁體中文 
Русский 
Español 
Deutsch 
Français 
Português 
Italiano 
Türkçe 
Polski 
Nederlands 
日本語 
한국어 
Bahasa Indonesia 
Bahasa Melayu 
العربية 
हिन्दी 
Tiếng Việt 
ภาษาไทย 
বাংলা 
اردو 
Kiswahili 
Oʻzbekcha 
አማርኛ 
فارسی Cómo valida cada NOS un módulo
Entre "módulo detectado" y "puerto activo", cada sistema operativo de red ejecuta una verificación sobre la identidad del módulo. Qué compara, qué hace cuando la comparación falla y si un administrador puede anularla difiere según el fabricante, la plataforma y la versión — y esa diferencia es todo el tema de la compatibilidad de transceptores. Esta página pone los comportamientos uno junto a otro, tal como los documentan los fabricantes y se observan en el campo, para que un módulo leído en el banco pueda juzgarse frente a la caja para la que está destinado.
Qué se puede verificar
| Verificación | Bytes involucrados | Quién lo hace |
|---|---|---|
| Sumas de comprobación CC_BASE / CC_EXT | SFP 63/95, QSFP 191/223, CMIS 222/255 | casi todos — un fallo es EEPROM inválida (Sumas de comprobación) |
| Coherencia de identificador / conector / codificación | SFP 0, 2, 11; QSFP 0, 130, 139 | la mayoría; los tipos desconocidos se muestran como tales |
| Códigos de cumplimiento frente al puerto | SFP 3–10, 36; QSFP 131–138, 192; aplicaciones CMIS | la mayoría — velocidad y tipo no compatibles (Códigos de cumplimiento) |
| Nombre de fabricante + número de parte contra una lista | SFP 20–35, 40–55; QSFP 148–163, 168–183 | plataformas estrictas y semiestrictas (Numeración de partes) |
| Firma específica del fabricante | área del fabricante (SFP 96–127, QSFP 224–255, personalizada CMIS) | algunos OEM; un hash ligado al número de serie |
| Formato del número de serie / código de fecha | SFP 68–91; QSFP 196–219 | raro; los ingenieros de soporte los revisan a mano |
| Clase de potencia frente al puerto | SFP 64; QSFP 129/107; CMIS 200–201 | todos los que implementan gestión de energía (Potencia y térmica) |
Comportamiento por fabricante
Comandos y comportamientos públicos a partir de versiones recientes; los detalles varían según la plataforma y la versión.
| Fabricante / NOS | Verificaciones | En caso de fallo | Anulación | DDM para terceros |
|---|---|---|---|---|
| Cisco IOS / IOS-XE (Catalyst, ISR) | lista de fabricante/PN y una verificación específica del fabricante; sumas de comprobación | %PHY-4-UNSUPPORTED_TRANSCEIVER, puerto en errdisable (gbic-invalid), láser apagado | service unsupported-transceiver (oculto) + no errdisable detect cause gbic-invalid; no en todas las plataformas; no soportado por el TAC | se muestra una vez aceptado; algunos campos en blanco |
| Cisco NX-OS (Nexus) | como arriba, menos estricto en muchas plataformas de DC | a menudo activo con un registro; los SKU estrictos van a errdisable | service unsupported-transceiver | normalmente se muestra |
| Cisco IOS-XR | lista de óptica por plataforma, clase de potencia | estado no compatible, el puerto puede quedar caído | limitada; depende de la plataforma | parcial |
| Arista EOS | sumas de comprobación, coherencia de tipo | registra unsupported; el enlace sube | no se necesita ninguna | completo |
| Juniper Junos | lista de fabricante/PN para la etiqueta "compatible", sumas de comprobación | el enlace normalmente sube; show chassis pic marca unsupported; algunas plataformas EX/QFX retienen el DDM o las velocidades para PN desconocidos | ninguna oficial | completo para PN conocidos, parcial para desconocidos |
| Huawei VRP | fabricante/PN; no Huawei → alarma | el enlace sube con alarmas recurrentes de transceptor phony | algunas plataformas restringen | transceiver phony-alarm-disable (vista de sistema) |
| H3C Comware | como VRP | alarma | transceiver phony-alarm-disable | completo |
| HPE Aruba AOS-S / AOS-CX | lista de fabricante/PN | no compatible, puerto caído | allow-unsupported-transceiver | completo |
| Dell OS10 / OS9 / PowerConnect | sumas de comprobación; algunas verificaciones de lista en equipos más antiguos | registros; en equipos antiguos: errdisable | service unsupported-transceiver (antiguos) | completo |
| Extreme EXOS / VOSS | sumas de comprobación, tipo | registros, sube | — | completo |
| Ruckus/Brocade ICX (FastIron) | sumas de comprobación; monitorización óptica solo para PN de Brocade en algunos casos | sube; el DDM puede faltar | — | parcial |
| Brocade FOS (SAN) | se requiere PN y número de serie de marca Brocade en la mayoría de las plataformas Gen 5/6/7 | puerto Mod_Inv, no habilitado | ninguna | solo óptica Brocade |
| Nvidia/Mellanox (Onyx, Cumulus, IB) | Ethernet: sumas de comprobación, tipo; InfiniBand: información del cable validada por el gestor de fabric | Ethernet sube con registro; IB puede funcionar a velocidad reducida o marcarse | — | completo |
| SONiC / white-box | plugin de plataforma: sumas de comprobación, análisis de CMIS | sube; campos desconocidos mostrados en crudo | — | completo (depende del plugin) |
| MikroTik RouterOS / SwOS | ninguna más allá del análisis | sube | — | completo |
| Ubiquiti | ninguna más allá del análisis | sube | — | completo |
| NIC de servidor (Intel, Broadcom, Mellanox) | listas blancas del controlador en algunas familias Intel | el controlador se niega a activar el puerto | parámetro de módulo allow_unsupported_sfp=1 (Intel ixgbe/i40e) | vía ethtool -m |
Donde existe una anulación del fabricante, generalmente se ofrece tal cual: el módulo funciona, pero el fabricante no se compromete a dar soporte a la combinación. Las decisiones de flota corresponden al propietario de la red (Óptica de terceros).
Qué debe satisfacer un módulo "codificado para el fabricante X"
| Clase de plataforma | Mínimo para la aceptación | También recomendable |
|---|---|---|
| Permisiva (Arista, SONiC, MikroTik, Extreme…) | sumas de comprobación válidas, códigos de tipo coherentes | nombre de fabricante y PN reales — nada que ganar con codificación OEM |
| Verificación por lista (Juniper, Aruba, Huawei/H3C, NX-OS en muchos SKU) | nombre de fabricante y PN exactamente como en la lista de la plataforma, códigos de cumplimiento correctos para el puerto | sufijo/grado de PN coincidente; número de serie y código de fecha realistas |
| Verificación de firma (Cisco IOS/IOS-XE, algunos XR) | todo lo anterior más el área específica del fabricante calculada para este número de serie | campos de identidad coherentes con el PN (longitud de onda, alcance, tecnología) |
| Solo de marca (Brocade FOS) | cadena de fabricante Brocade y familia de PN, formato de número de serie | — |
Cómo funciona el lado del banco: Bloqueo de fabricante y codificación, Recodificación de EEPROM.
Cómo leer el rechazo
| Texto de registro / estado | Significado | Siguiente paso |
|---|---|---|
unsupported transceiver, Mod_Inv, phony | identidad no está en la lista | anular, o codificar a un PN listado |
invalid EEPROM, checksum error | CC_BASE/CC_EXT incorrecto | recalcular (Sumas de comprobación) |
speed and type not supported, unknown media type | los códigos de cumplimiento no encajan con el puerto | corregir códigos o usar otro modo de puerto (Velocidad y tasa) |
power class exceeds, atascado en LowPwr | clase de potencia frente a jaula | Potencia y térmica |
Module not ready, el estado DP se estanca | arranque de CMIS | Problemas de CMIS |
Comandos por NOS para ver estos estados: Verificación de la óptica en un conmutador.
Cambios con las actualizaciones de software
Los fabricantes endurecen o relajan las verificaciones entre versiones: nueva validación de firma, nuevas listas de óptica compatible, comandos ocultos eliminados, manejo de DDM modificado. Una flota de óptica de terceros o codificada que funcionaba ayer puede quedar en errdisable tras una actualización (Matrices de compatibilidad y firmware).
En CodingBox
CodingBox muestra los bytes exactos que lee cada verificación anterior — nombre de fabricante, PN, sumas de comprobación, códigos de cumplimiento, clase de potencia — y la base de datos de códigos guarda identidades que una clase de plataforma determinada acepta. Verifique en un puerto de prueba después de codificar; el conmutador, no el banco, tiene la última palabra (Check transceiver).
La contraparte del lado del servidor — listas blancas de controlador por fabricante de NIC, anulaciones de Intel, comportamiento de Windows y ESXi: Compatibilidad de transceptores en NIC.