Herstellersperre und „unsupported transceiver“

Das mit Abstand häufigste Transceiver-Problem. Switch- und NIC-Hersteller wie Cisco, Intel, HPE/Aruba, Juniper, Mellanox und andere prüfen die Identifikationsstrings, die ein Modul aus seinem EEPROM meldet, und weisen Module zurück oder markieren sie, die sie nicht erkennen.

Was Techniker meist auf die harte Tour lernen: „unsupported“ bedeutet nicht „funktioniert nicht“. Auf den meisten Plattformen ist der Status rein informativ, und der Port lässt sich zum Hochfahren bringen.

Symptome

Was hilft

Cisco. Zwei Befehle werden routinemäßig in Basis-Konfigurationen aufgenommen, um Drittanbietermodule an allen Ports zuzulassen:

service unsupported-transceiver
no errdisable detect cause gbic-invalid

Plattform-Eigenheiten: Bei manchen Catalyst-9200-Builds liefert der erste Befehl % Ambiguous command – ihn vollständig ausschreiben; auf Nexus 9000 ist es ein verstecktes Kommando ohne Tab-Vervollständigung, wird aber akzeptiert.

Intel X520 (Linux). Den Treiber mit der Option laden, die Nicht-Intel-Module zulässt:

modprobe ixgbe allow_unsupported_sfp=1

Es gibt eine dauerhafte Variante, die ein Bit im eigenen EEPROM der NIC umschaltet, dokumentiert in den Quellen unten – mit Vorsicht behandeln, denn ein fehlerhafter Schreibvorgang ins NIC-EEPROM lässt sich vor Ort nicht mehr rückgängig machen.

ASR-9000-Serie. Ein Modul, das in einen bereits aktiven Port eingesetzt wird, wird mitunter nicht erkannt: den Port mit shut abschalten, das Modul einsetzen, dann no shut.

Die radikale Lösung: das Modul umkodieren. Vendor-ID und Teilenummer des Moduls so umschreiben, dass es sich als natives Modul ausgibt. Genau das macht CodingBox im EEPROM editor, mit neu berechneten CC_BASE/CC_EXT und einer vorab angelegten Sicherung. Die Mechanik dazu in EEPROM-Umkodierung.

Der Rat, den alle wiederholen

Ein Original-OEM-Modul jedes Typs auf Vorrat halten. Es vor dem Öffnen eines Support-Tickets einsetzen, damit der Hersteller das Problem nicht auf Drittanbieter-Optik schieben kann.

Überprüfung am Switch

Nach jeder dieser Maßnahmen bestätigen, dass das Modul erkannt und gelesen wird: die Befehle je NOS in Optik am Switch überprüfen, und mit der Identität vergleichen, die CodingBox auf der Werkbank liest.

Was ein Host genau vergleicht: Name, PN, OUI, Seriennummernmuster, Herstellersignatur, und bei welchem Schritt der Inbetriebnahme er ablehnt: Herstellerfelder, Was der Host macht.

Validierungsverhalten und Overrides je Hersteller in einer Tabelle: Wie jedes NOS ein Modul validiert; die genauen PN-Strings, die Plattformen erwarten: OEM-Teilenummern; Befehlssyntax je NOS: Rezepte zur Port-Konfiguration.