Kompatibilitätsmatrizen, Release Notes und Firmware-Änderungen

„Unterstützt“ ist eine Aussage über ein Tripel: dieses Modul, in dieser Plattform, auf diesem Software-Release. Hersteller veröffentlichen dieses Tripel in Kompatibilitätsmatrizen und Release Notes — und ändern es: Neue Optik kommt hinzu, alte fällt weg, Prüfungen werden strikter. Die Matrizen vor dem Kauf zu lesen und vor jedem Upgrade erneut zu lesen, ist die günstigste Kompatibilitätsarbeit, die es gibt. Diese Seite zeigt, wo die Information liegt, wie sie zu lesen ist und wie eine Flotte so betrieben wird, dass ein Software-Upgrade nicht zum Optik-Ausfall wird.

Wo Hersteller Support veröffentlichen

Hersteller	Ressource	Was sie listet
Cisco	Transceiver Module Group (TMG) Compatibility Matrix; plattformspezifische Datenblätter	PN ↔ Plattform ↔ Mindest-Software; Port-Einschränkungen
Juniper	Hardware Compatibility Tool (HCT)	Optik-PN ↔ Plattform ↔ Junos-Release, Geschwindigkeiten, DDM-Unterstützung
Arista	Transceiver and Cable Guide (PDF/online)	PN, PMD, Reichweite, unterstützte Plattformen pro EOS
Huawei	Hardware Center / Kompatibilitätslisten für Produkte	Codes optischer Module pro Switch-Modell
H3C	Transceiver Module Compatibility Matrix	pro Produktfamilie
HPE Aruba	Transceiver Guide, QuickSpecs	J/R-Nummern pro Switch-Familie und Firmware
Dell	Networking Optics/Cables Support Matrix	SKU ↔ Plattform ↔ OS10-Release
Nvidia/Mellanox	LinkX-Produktseiten, Cumulus-/Onyx-Release-Notes, InfiniBand-Firmware-Notes	Kabel-/Transceiver-PN ↔ Switch/HCA ↔ Firmware
Extreme, Ruckus	Transceiver-Kompatibilitätsleitfäden	pro Plattform
Brocade (SAN)	FOS-Release-Notes, Liste unterstützter Optik	markengebundene SFP-PNs pro FOS-Version
SONiC / White-Box	Hardware-Kompatibilitätsliste des Plattformherstellers, Community-Wiki	getestete Optik pro Plattform; oft Community-gepflegt
NIC-Hersteller	Kompatibilitätslisten der Intel-/Broadcom-/Mellanox-Adapter	unterstützte Module und Treiberversionen

Lesen Sie auch die Release Notes der von Ihnen betriebenen NOS-Version: Optik-Änderungen verstecken sich unter „Resolved Issues“, „Behaviour Changes“ und „New Hardware Support“.

Einen Matrix-Eintrag lesen

Spalte	Bedeutung	Worauf zu achten ist
Teilenummer	der exakte String, den der Switch im Modul erwartet (Teilenummern)	Grade-Suffixe (`-S`, `-I`, Revisionsbuchstaben) als eigenständige PNs behandelt
Plattform / Port	welches Chassis, welche Linecard oder welcher Portbereich	nur Uplink, „nur Ports 49–52“, nicht auf Breakout-Ports
Mindest-Software	erstes Release mit Unterstützung	eine neuere PN auf einem älteren Release = nicht unterstützt, auch wenn markengebunden
Geschwindigkeiten / Modi	welche Raten und Breakouts die PN an diesem Port unterstützt	4×25G-Breakout nur auf manchen Plattformen unterstützt
DDM / DOM	ob Diagnosedaten offengelegt werden	„DOM nicht unterstützt“ bei bestimmten Kombinationen
Anmerkungen	Temperatur, Reichweite, FEC-Anforderungen, EOL	Enddaten des Verkaufs und Nachfolge-PNs

Was sich mit der Software ändert

Änderung	Auswirkung auf die Optik	Erscheint als
Neue oder striktere Identitätsprüfung	zuvor tolerierte Drittanbieter- oder codierte Module abgelehnt	Ports nach dem Upgrade errdisabled (Wie jedes NOS ein Modul validiert)
Versteckter Override-Befehl entfernt oder umbenannt	`service unsupported-transceiver` nicht mehr akzeptiert	Konfiguration lädt nicht, Ports unten
CMIS-Handling verbessert oder geändert	400G+-Module, die Workarounds brauchten, funktionieren jetzt — oder umgekehrt	Module bleiben in LowPwr hängen (CMIS-Probleme)
FEC-/AN-Standardwerte geändert	Links, die sich auf alte Standardwerte verließen, fallen aus	Link unten bei guten Pegeln (FEC & AN)
DDM-Polling oder Schwellwert-Handling geändert	Alarme erscheinen oder verschwinden	neues Syslog-Rauschen oder Stille
Optik-PN erreicht Support-Ende	funktioniert weiterhin, nicht mehr gelistet	künftige Tickets als „nicht unterstützt“ geschlossen
Modul-Firmware-Update gebündelt	markengebundene Module erhalten neue Firmware	Verhaltensänderungen auf der Modulseite (Controller & Firmware)

Eine Flottenpraxis, die Überraschungen vermeidet

Inventarisieren — Hersteller, PN, Seriennummer, Revision und Firmware jedes Moduls pro Port (vom Switch oder von der Werkbank) in der CMDB dokumentieren.
Releases fixieren — die NOS-Version als Teil des Kompatibilitäts-Tripels behandeln; Access und Core nicht am selben Tag upgraden.
Release Notes lesen auf Optik-relevante Punkte vor jedem Upgrade.
Auf einem Labor- oder Kanarien-Switch testen mit je einem Exemplar jedes verwendeten Optiktyps — Drittanbieter- und codierte Module zuerst.
Das vorherige Image behalten und einen Rollback-Plan; wissen, welche Ports errdisable-anfällig sind.
DDM-Baseline vorher und nachher erstellen, damit Verhaltensänderungen im Monitoring sichtbar werden (Monitoring).
EOL verfolgen von Optik-PNs und ihren Nachfolgern, damit Ersatzteile zur Matrix passen.

Drittanbieter- und codierte Optik in diesem Bild

Ein auf eine OEM-PN codiertes Modul wird nach demselben Matrix-Eintrag beurteilt wie das Original — die Plattform kann den Unterschied nicht erkennen, wenn die Codierung vollständig ist —, aber die Support-Aussage des Herstellers erstreckt sich nicht darauf, und eine strengere Prüfung in einem neuen Release kann es entlarven. Codierte Module im Inventar identifizierbar halten (ihr echter Hersteller und ihre echte Seriennummer), sie bei Upgrades zuerst testen und für den Fall planen, dass ein Release die Tür schließt (Drittanbieter-Optik, Herstellersperre).

NIC- und Server-Seite

Server-Adapter haben ihre eigenen Matrizen (Adapter ↔ Modul ↔ Treiber/Firmware) und ihre eigenen Policies — manche Intel-Familien verweigern nicht gelistete SFPs, sofern kein Treiberparameter sie erlaubt; Mellanox-/Nvidia-Adapter validieren Kabel für InfiniBand. Treiber- und Firmware-Updates ändern diese Regeln ebenso wie NOS-Upgrades (Port-Konfigurationsrezepte).

In CodingBox

Die Werkbank-Seite der Flottenpraxis: Identität und Firmware-Version jedes Moduls bei der Wareneingangsprüfung in die Code-Datenbank einlesen, die Bytes eines verdächtigen Moduls mit dem Matrix-Eintrag auf Transceiver prüfen vergleichen und die Unterscheidung codiert/original in den Datenbank-Notizen festhalten, damit eine Ablehnung am Upgrade-Tag in Sekunden auf das Modul zurückgeführt werden kann.

NIC-Treiber- und Firmware-Policies im Detail, nach Hersteller und Betriebssystem: Transceiver-Kompatibilität bei NICs.

Die Flottenpraxis als Inbetriebnahme-Checkliste — vor der Konfiguration upgraden, Kanarientests, DDM-Baseline, Abnahmetest: Auswahl & Inbetriebnahme.

Wenn Sie in diesem Artikel eine Ungenauigkeit oder einen Fehler finden, markieren Sie die betreffende Stelle und drücken Sie Ctrl+Enter, um .