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 
አማርኛ 
فارسی Blocco del produttore e «unsupported transceiver»
Il problema più comune in assoluto con i ricetrasmettitori. I produttori di switch e NIC — Cisco, Intel, HPE/Aruba, Juniper, Mellanox e altri — controllano le stringhe di identificazione che un modulo riporta dal proprio EEPROM e rifiutano o segnalano i moduli che non riconoscono.
La cosa fondamentale che gli ingegneri imparano a proprie spese: «non supportato» non significa «non funzionerà». Sulla maggior parte delle piattaforme lo stato è informativo e la porta può essere fatta funzionare.
Sintomi
| Piattaforma | Cosa vedi |
|---|---|
| Cisco IOS | Porta notconnect — unsupported; log %C4K_TRANSCEIVERMAN-3-INCOMPATIBLE |
| Cisco IOS dopo un aggiornamento | La porta passa a errdisable, motivo gbic-invalid |
| Mellanox | L’EEPROM viene letto ma non c’è collegamento: speed and type: Not supported |
| Intel X520 / ixgbe | no carrier con un SFP non Intel |
Cosa funziona
Cisco. Due comandi vengono regolarmente inseriti nelle configurazioni di base per consentire moduli di terze parti su tutte le porte:
service unsupported-transceiver
no errdisable detect cause gbic-invalidParticolarità per piattaforma: su alcune build di Catalyst 9200 il primo comando restituisce % Ambiguous command — scrivilo per esteso; su Nexus 9000 è un comando nascosto senza tab-completion, ma viene accettato.
Intel X520 (Linux). Carica il driver con l’opzione che consente moduli non Intel:
modprobe ixgbe allow_unsupported_sfp=1Esiste una variante persistente che inverte un bit nell’EEPROM della NIC stessa ed è documentata nelle fonti sotto — trattala con cautela, dato che una scrittura sbagliata nell’EEPROM della NIC non è recuperabile sul campo.
Serie ASR 9000. Un modulo inserito in una porta già attiva potrebbe non essere rilevato: fai shut sulla porta, inserisci il modulo, poi no shut.
La soluzione radicale — ricodificare il modulo. Riscrivi l’ID produttore e il part number del modulo così che si presenti come un modulo nativo. È esattamente ciò che fa CodingBox nell'EEPROM editor, con CC_BASE/CC_EXT ricalcolati e un backup preso prima. Vedi Ricodifica EEPROM per la meccanica.
Il consiglio che ripetono tutti
Tieni uno scaffale con un modulo OEM originale per ogni tipo. Inseriscilo prima di aprire un ticket di supporto, così il produttore non può attribuire il problema all’ottica di terze parti.
Verifica sullo switch
Dopo una qualsiasi delle operazioni precedenti, conferma che il modulo venga visto e letto: vedi Verifica delle ottiche su uno switch per i comandi per ciascun NOS, e confronta con l’identità che CodingBox legge sul banco.
Cosa confronta esattamente un host — nome, PN, OUI, pattern del seriale, firma del produttore — e a quale passaggio del bring-up rifiuta: Campi del produttore, Cosa fa l’host.
Il comportamento di convalida per singolo produttore e gli override in un’unica tabella: Come ogni NOS convalida un modulo; le stringhe PN esatte che le piattaforme si aspettano: Numerazione delle parti; sintassi dei comandi per NOS: Ricette di configurazione delle porte.