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 
አማርኛ 
فارسی Bloqueo de fabricante y «unsupported transceiver»
El problema de transceptores más frecuente con diferencia. Los fabricantes de conmutadores y NIC (Cisco, Intel, HPE/Aruba, Juniper, Mellanox y otros) comprueban las cadenas de identificación que un módulo informa desde su EEPROM y rechazan o marcan los módulos que no reconocen.
Lo que los ingenieros aprenden a la fuerza: «no admitido» no significa «no funcionará». En la mayoría de las plataformas el estado es solo informativo y se puede hacer que el puerto suba.
Síntomas
| Plataforma | Qué se observa |
|---|---|
| Cisco IOS | Puerto notconnect — unsupported; registro %C4K_TRANSCEIVERMAN-3-INCOMPATIBLE |
| Cisco IOS tras una actualización | El puerto pasa a errdisable, motivo gbic-invalid |
| Mellanox | Se lee la EEPROM pero no hay enlace: speed and type: Not supported |
| Intel X520 / ixgbe | no carrier con un SFP que no es de Intel |
Qué funciona
Cisco. Dos comandos se incluyen habitualmente en las configuraciones base para permitir módulos de terceros en todos los puertos:
service unsupported-transceiver
no errdisable detect cause gbic-invalidPeculiaridades por plataforma: en algunas compilaciones de Catalyst 9200 el primer comando devuelve % Ambiguous command; escríbalo completo. En Nexus 9000 es un comando oculto sin autocompletado con tabulador, pero se acepta.
Intel X520 (Linux). Cargue el controlador con la opción que permite módulos que no son de Intel:
modprobe ixgbe allow_unsupported_sfp=1Existe una variante persistente que cambia un bit en la propia EEPROM de la NIC y está documentada en las fuentes de abajo; trátela con cuidado, ya que una escritura incorrecta en la EEPROM de la NIC no se puede recuperar en campo.
Serie ASR 9000. Un módulo insertado en un puerto ya activo puede no detectarse: aplique shut al puerto, inserte el módulo y después no shut.
La solución radical: recodificar el módulo. Reescriba el ID de fabricante y el número de pieza del módulo para que se presente como un módulo nativo. Esto es lo que hace CodingBox en el EEPROM editor, con CC_BASE/CC_EXT recalculados y una copia de seguridad tomada primero. Véase Recodificación de EEPROM para conocer la mecánica.
El consejo que todos repiten
Guarde un módulo OEM original de cada tipo en la estantería. Colóquelo antes de abrir un ticket de soporte, para que el fabricante no pueda atribuir el problema a la óptica de terceros.
Verificación en el conmutador
Tras cualquiera de estos pasos, confirme que el módulo se ve y se lee: véase Verificación de óptica en un conmutador para los comandos por NOS, y compare con la identidad que CodingBox lee en el banco.
Qué compara exactamente un host — nombre, PN, OUI, patrón de número de serie, firma de fabricante — y en qué paso del arranque rechaza: Campos de fabricante, Qué hace el host.
Comportamiento de validación y overrides por fabricante en una sola tabla: Cómo valida cada NOS un módulo; las cadenas PN exactas que esperan las plataformas: Números de pieza OEM; sintaxis de comandos por NOS: Recetas de configuración de puertos.