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 
አማርኛ 
فارسی Wie jedes NOS ein Modul prüft
Zwischen „Modul erkannt“ und „Port oben“ führt jedes Netzwerkbetriebssystem eine Prüfung der Identität des Moduls durch. Was verglichen wird, was bei einem fehlgeschlagenen Vergleich passiert und ob ein Administrator dies übersteuern kann, unterscheidet sich nach Hersteller, Plattform und Release — und genau dieser Unterschied ist das gesamte Thema der Transceiver-Kompatibilität. Diese Seite stellt die Verhaltensweisen nebeneinander, wie von den Herstellern dokumentiert und in der Praxis beobachtet, damit ein auf der Werkbank gelesenes Modul gegen die Box beurteilt werden kann, für die es gedacht ist.
Was geprüft werden kann
| Prüfung | Beteiligte Bytes | Wer es tut |
|---|---|---|
| Prüfsummen CC_BASE / CC_EXT | SFP 63/95, QSFP 191/223, CMIS 222/255 | fast alle — ein Fehlschlag ist invalid EEPROM (Prüfsummen) |
| Konsistenz von Identifier/Steckverbinder/Encoding | SFP 0, 2, 11; QSFP 0, 130, 139 | die meisten; unbekannte Typen werden als solche angezeigt |
| Compliance-Codes vs. Port | SFP 3–10, 36; QSFP 131–138, 192; CMIS-Applications | die meisten — speed and type not supported (Compliance-Codes) |
| Herstellername + Teilenummer gegen eine Liste | SFP 20–35, 40–55; QSFP 148–163, 168–183 | strikte und halbstrikte Plattformen (Teilenummern) |
| Herstellerspezifische Signatur | Herstellerbereich (SFP 96–127, QSFP 224–255, CMIS Custom) | wenige OEMs; ein an die Seriennummer gebundener Hash |
| Format der Seriennummer / Datumscode | SFP 68–91; QSFP 196–219 | selten; Support-Ingenieure sehen sie manuell durch |
| Leistungsklasse vs. Port | SFP 64; QSFP 129/107; CMIS 200–201 | alle, die Power-Management implementieren (Leistung & Wärme) |
Verhalten nach Hersteller
Öffentliche Befehle und Verhaltensweisen Stand aktueller Releases; Details variieren nach Plattform und Version.
| Hersteller / NOS | Prüfungen | Bei Fehlschlag | Override | DDM bei Drittanbietern |
|---|---|---|---|---|
| Cisco IOS / IOS-XE (Catalyst, ISR) | Hersteller-/PN-Liste und eine herstellerspezifische Prüfung; Prüfsummen | %PHY-4-UNSUPPORTED_TRANSCEIVER, Port errdisabled (gbic-invalid), Laser aus | service unsupported-transceiver (versteckt) + no errdisable detect cause gbic-invalid; nicht auf allen Plattformen; nicht vom TAC unterstützt | nach Annahme angezeigt; manche Felder leer |
| Cisco NX-OS (Nexus) | wie oben, auf vielen DC-Plattformen weniger strikt | oft up mit einem Log-Eintrag; strikte SKUs errdisablen | service unsupported-transceiver | meist angezeigt |
| Cisco IOS-XR | plattformspezifische Optikliste, Leistungsklasse | Status unsupported, Port bleibt eventuell unten | begrenzt; plattformabhängig | teilweise |
| Arista EOS | Prüfsummen, Typkonsistenz | protokolliert unsupported; Link kommt hoch | keiner nötig | vollständig |
| Juniper Junos | Hersteller-/PN-Liste für das Label „supported“, Prüfsummen | Link meist oben; show chassis pic markiert unsupported; manche EX/QFX-Plattformen halten DDM oder Geschwindigkeiten für unbekannte PNs zurück | keiner offiziell | vollständig bei bekannten PNs, teilweise bei unbekannten |
| Huawei VRP | Hersteller/PN; Nicht-Huawei → Alarm | Link oben mit wiederkehrenden phony-Transceiver-Alarmen; manche Plattformen schränken ein | transceiver phony-alarm-disable (System-View) | vollständig |
| H3C Comware | wie VRP | Alarm | transceiver phony-alarm-disable | vollständig |
| HPE Aruba AOS-S / AOS-CX | Hersteller-/PN-Liste | unsupported, Port unten | allow-unsupported-transceiver | vollständig |
| Dell OS10 / OS9 / PowerConnect | Prüfsummen; bei älteren Geräten teils Listenprüfung | Log-Eintrag; ältere: errdisable | service unsupported-transceiver (ältere) | vollständig |
| Extreme EXOS / VOSS | Prüfsummen, Typ | Log-Eintrag, oben | — | vollständig |
| Ruckus/Brocade ICX (FastIron) | Prüfsummen; optisches Monitoring bei manchen nur für Brocade-PNs | oben; DDM kann fehlen | — | teilweise |
| Brocade FOS (SAN) | auf den meisten Gen-5/6/7-Plattformen sind markengebundene Brocade-PN und -Seriennummer erforderlich | Port Mod_Inv, nicht aktiviert | keiner | nur Brocade-Optik |
| Nvidia/Mellanox (Onyx, Cumulus, IB) | Ethernet: Prüfsummen, Typ; InfiniBand: Kabelinfo vom Fabric-Manager validiert | Ethernet oben mit Log-Eintrag; IB läuft eventuell mit reduzierter Geschwindigkeit oder markiert | — | vollständig |
| SONiC / White-Box | Plattform-Plugin: Prüfsummen, CMIS-Parsing | oben; unbekannte Felder roh angezeigt | — | vollständig (Plugin-abhängig) |
| MikroTik RouterOS / SwOS | keine außer Parsing | oben | — | vollständig |
| Ubiquiti | keine außer Parsing | oben | — | vollständig |
| Server-NICs (Intel, Broadcom, Mellanox) | Treiber-Whitelists bei manchen Intel-Familien | Treiber verweigert das Hochfahren des Ports | Modulparameter allow_unsupported_sfp=1 (Intel ixgbe/i40e) | über ethtool -m |
Wo ein Override eines Herstellers existiert, wird er im Allgemeinen as is angeboten: Das Modul funktioniert, aber der Hersteller sichert die Unterstützung der Kombination nicht zu. Flottenentscheidungen liegen beim Netzbetreiber (Drittanbieter-Optik).
Was „codiert für Hersteller X“ erfüllen muss
| Plattformklasse | Minimum für die Annahme | Ebenfalls ratsam |
|---|---|---|
| Permissiv (Arista, SONiC, MikroTik, Extreme…) | gültige Prüfsummen, konsistente Typcodes | echter Herstellername und echte PN — bei OEM-Codierung nichts zu gewinnen |
| Listenprüfend (Juniper, Aruba, Huawei/H3C, NX-OS bei vielen SKUs) | Herstellername und PN exakt wie in der Liste der Plattform, korrekte Compliance-Codes für den Port | passender PN-Suffix/Grade; realistische Seriennummer und realistischer Datumscode |
| Signaturprüfend (Cisco IOS/IOS-XE, manche XR) | alles Obige plus der herstellerspezifische, für diese Seriennummer berechnete Bereich | Identitätsfelder konsistent mit der PN (Wellenlänge, Reichweite, Technologie) |
| Nur markengebunden (Brocade FOS) | Brocade-Herstellerstring und PN-Familie, Seriennummernformat | — |
Wie die Werkbank-Seite funktioniert: Herstellersperre & Codierung, EEPROM-Recodierung.
Die Ablehnung lesen
| Log-/Statustext | Bedeutung | Nächster Schritt |
|---|---|---|
unsupported transceiver, Mod_Inv, phony | Identität nicht auf der Liste | übersteuern oder auf eine gelistete PN codieren |
invalid EEPROM, checksum error | CC_BASE/CC_EXT falsch | neu berechnen (Prüfsummen) |
speed and type not supported, unknown media type | Compliance-Codes passen nicht zum Port | Codes korrigieren oder anderen Port-Modus nutzen (Geschwindigkeit & Rate) |
power class exceeds, hängt in LowPwr | Leistungsklasse vs. Käfig | Leistung & Wärme |
Module not ready, DP-Status stockt | CMIS-Bring-up | CMIS-Probleme |
Befehle je NOS, um diese Zustände zu sehen: Optik auf einem Switch verifizieren.
Änderungen bei Software-Upgrades
Hersteller verschärfen oder lockern Prüfungen zwischen Releases: neue Signaturvalidierung, neue Listen unterstützter Optik, entfernte versteckte Befehle, geändertes DDM-Handling. Eine Flotte aus Drittanbieter- oder codierter Optik, die gestern funktionierte, kann nach einem Upgrade errdisabled werden (Kompatibilitätsmatrizen & Firmware).
In CodingBox
CodingBox zeigt die exakten Bytes, die jede der obigen Prüfungen liest — Herstellername, PN, Prüfsummen, Compliance-Codes, Leistungsklasse — und die Code-Datenbank hält Identitäten fest, die eine bestimmte Plattformklasse akzeptiert. Nach dem Codieren an einem Testport verifizieren; der Switch, nicht die Werkbank, hat das letzte Wort (Transceiver prüfen).
Das Gegenstück auf der Serverseite — Treiber-Whitelists je NIC-Hersteller, Intel-Overrides, Verhalten von Windows und ESXi: Transceiver-Kompatibilität bei NICs.