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 
አማርኛ 
فارسی Come ogni NOS convalida un modulo
Tra «modulo rilevato» e «porta up» ogni sistema operativo di rete esegue un controllo sull’identità del modulo. Cosa confronta, cosa fa quando il confronto fallisce e se un amministratore può fare override differiscono per produttore, piattaforma e release — e questa differenza è l’intero argomento della compatibilità dei ricetrasmettitori. Questa pagina mette a confronto i comportamenti, come documentati dai produttori e osservati sul campo, in modo che un modulo letto al banco possa essere giudicato rispetto all’apparato a cui è destinato.
Cosa si può controllare
| Controllo | Byte coinvolti | Chi lo esegue |
|---|---|---|
| Checksum CC_BASE / CC_EXT | SFP 63/95, QSFP 191/223, CMIS 222/255 | quasi tutti — un fallimento è invalid EEPROM (Checksum) |
| Coerenza di identifier / connector / encoding | SFP 0, 2, 11; QSFP 0, 130, 139 | la maggior parte; i tipi sconosciuti sono mostrati come tali |
| Compliance code rispetto alla porta | SFP 3–10, 36; QSFP 131–138, 192; CMIS applications | la maggior parte — speed and type not supported (Compliance code) |
| Nome del produttore + part number rispetto a un elenco | SFP 20–35, 40–55; QSFP 148–163, 168–183 | piattaforme rigide e semi-rigide (Numerazione delle parti) |
| Firma specifica del produttore | area del produttore (SFP 96–127, QSFP 224–255, CMIS custom) | alcuni OEM; un hash legato al numero di serie |
| Formato del numero di serie / date code | SFP 68–91; QSFP 196–219 | raro; gli ingegneri di supporto li controllano manualmente |
| Classe di potenza rispetto alla porta | SFP 64; QSFP 129/107; CMIS 200–201 | tutti quelli che implementano la gestione della potenza (Potenza e termica) |
Comportamento per produttore
Comandi e comportamenti pubblici aggiornati alle release recenti; i dettagli variano per piattaforma e versione.
| Produttore / NOS | Controlli | In caso di fallimento | Override | DDM per terze parti |
|---|---|---|---|---|
| Cisco IOS / IOS-XE (Catalyst, ISR) | elenco produttore/PN e un controllo specifico del produttore; checksum | %PHY-4-UNSUPPORTED_TRANSCEIVER, porta in errdisable (gbic-invalid), laser spento | service unsupported-transceiver (nascosto) + no errdisable detect cause gbic-invalid; non su tutte le piattaforme; non supportato dal TAC | mostrato una volta accettato; alcuni campi vuoti |
| Cisco NX-OS (Nexus) | come sopra, meno rigido su molte piattaforme DC | spesso up con un log; gli SKU rigidi vanno in errdisable | service unsupported-transceiver | di solito mostrato |
| Cisco IOS-XR | elenco di ottici per piattaforma, classe di potenza | stato unsupported, la porta può restare down | limitato; dipende dalla piattaforma | parziale |
| Arista EOS | checksum, coerenza del tipo | registra nel log unsupported; il link si alza | non necessario | completo |
| Juniper Junos | elenco produttore/PN per l’etichetta «supported», checksum | il link di solito è up; show chassis pic segna unsupported; alcune piattaforme EX/QFX negano DDM o velocità per PN sconosciuti | nessuno ufficiale | completo per i PN noti, parziale per quelli sconosciuti |
| Huawei VRP | produttore/PN; non Huawei → allarme | link up con allarmi ricorrenti di ricetrasmettitore phony; alcune piattaforme limitano | transceiver phony-alarm-disable (system view) | completo |
| H3C Comware | come VRP | allarme | transceiver phony-alarm-disable | completo |
| HPE Aruba AOS-S / AOS-CX | elenco produttore/PN | unsupported, porta down | allow-unsupported-transceiver | completo |
| Dell OS10 / OS9 / PowerConnect | checksum; alcuni controlli su elenco per apparati più vecchi | log; sui più vecchi: errdisable | service unsupported-transceiver (sui più vecchi) | completo |
| Extreme EXOS / VOSS | checksum, tipo | log, up | — | completo |
| Ruckus/Brocade ICX (FastIron) | checksum; monitoraggio ottico solo per i PN Brocade su alcuni | up; il DDM può mancare | — | parziale |
| Brocade FOS (SAN) | PN e seriale a marchio Brocade richiesti sulla maggior parte delle piattaforme Gen 5/6/7 | porta Mod_Inv, non abilitata | nessuno | solo ottici Brocade |
| Nvidia/Mellanox (Onyx, Cumulus, IB) | Ethernet: checksum, tipo; InfiniBand: informazioni del cavo convalidate dal fabric manager | Ethernet up con log; IB può funzionare a velocità ridotta o segnalare | — | completo |
| SONiC / white-box | plugin di piattaforma: checksum, parsing CMIS | up; i campi sconosciuti sono mostrati grezzi | — | completo (dipende dal plugin) |
| MikroTik RouterOS / SwOS | nessuno oltre al parsing | up | — | completo |
| Ubiquiti | nessuno oltre al parsing | up | — | completo |
| NIC server (Intel, Broadcom, Mellanox) | whitelist del driver su alcune famiglie Intel | il driver rifiuta di attivare la porta | parametro modulo allow_unsupported_sfp=1 (Intel ixgbe/i40e) | via ethtool -m |
Dove esiste un override del produttore, viene generalmente offerto as is: il modulo funziona, ma il produttore non si impegna a supportare la combinazione. Le decisioni di flotta spettano al responsabile della rete (Ottici di terze parti).
Cosa deve soddisfare «codificato per il produttore X»
| Classe di piattaforma | Minimo per l’accettazione | Consigliabile anche |
|---|---|---|
| Permissiva (Arista, SONiC, MikroTik, Extreme…) | checksum validi, codici di tipo coerenti | nome del produttore e PN reali — nulla da guadagnare dalla codifica OEM |
| A verifica su elenco (Juniper, Aruba, Huawei/H3C, NX-OS su molti SKU) | nome del produttore e PN esattamente come nell’elenco della piattaforma, compliance code corretti per la porta | suffisso/grado del PN corrispondente; numero di serie e date code realistici |
| A verifica di firma (Cisco IOS/IOS-XE, alcuni XR) | tutto quanto sopra più l’area specifica del produttore calcolata per questo seriale | campi di identità coerenti con il PN (lunghezza d’onda, portata, tecnologia) |
| Solo a marchio (Brocade FOS) | stringa produttore Brocade e famiglia di PN, formato del seriale | — |
Come funziona il lato banco: Blocco del produttore e codifica, Ricodifica dell’EEPROM.
Leggere il rifiuto
| Testo di log / stato | Significato | Passo successivo |
|---|---|---|
unsupported transceiver, Mod_Inv, phony | identità non nell’elenco | override, oppure codifica su un PN elencato |
invalid EEPROM, checksum error | CC_BASE/CC_EXT errati | ricalcola (Checksum) |
speed and type not supported, unknown media type | i compliance code non si adattano alla porta | correggi i codici o usa un’altra modalità di porta (Velocità e rate) |
power class exceeds, bloccato in LowPwr | classe di potenza rispetto alla gabbia | Potenza e termica |
Module not ready, DP state bloccato | bring-up CMIS | Problemi CMIS |
Comandi per NOS per vedere questi stati: Verifica degli ottici su uno switch.
Modifiche con gli aggiornamenti software
I produttori inaspriscono o allentano i controlli tra una release e l’altra: nuova convalida della firma, nuovi elenchi di ottici supportati, comandi nascosti rimossi, gestione del DDM cambiata. Una flotta di ottici di terze parti o codificati che funzionava ieri può finire in errdisable dopo un aggiornamento (Matrici di compatibilità e firmware).
In CodingBox
CodingBox mostra i byte esatti che ciascun controllo sopra legge — nome del produttore, PN, checksum, compliance code, classe di potenza — e il code database conserva le identità che una determinata classe di piattaforma accetta. Verifica su una porta di test dopo la codifica; è lo switch, non il banco, ad avere l’ultima parola (Check transceiver).
La controparte lato server — whitelist dei driver per produttore di NIC, override Intel, comportamento Windows ed ESXi: Compatibilità dei ricetrasmettitori sulle NIC.