Fabrikantvergrendeling en «unsupported transceiver» · Veelvoorkomende problemen en oplossingen · Optische transceivers en kabels · Documentatie · CodingBox
CodingBox Documentatie

Fabrikantvergrendeling en «unsupported transceiver»

Het meest voorkomende probleem met transceivers. Fabrikanten van switches en NIC's — Cisco, Intel, HPE/Aruba, Juniper, Mellanox en andere — controleren de identificatiestrings die een module uit zijn EEPROM meldt en weigeren of markeren modules die zij niet herkennen.

De harde les die engineers leren: «niet-ondersteund» betekent niet «zal niet werken». Op de meeste platforms is de status alleen informatief en kan de poort alsnog actief worden.

Symptomen

PlatformWat u ziet
Cisco IOSPoort notconnect — unsupported; log %C4K_TRANSCEIVERMAN-3-INCOMPATIBLE
Cisco IOS na een upgradePoort gaat naar errdisable, reden gbic-invalid
MellanoxEEPROM wordt gelezen maar geen link: speed and type: Not supported
Intel X520 / ixgbeno carrier met een niet-Intel SFP

Wat werkt

Cisco. Twee opdrachten worden standaard in basisconfiguraties opgenomen om modules van derden op alle poorten toe te staan:

service unsupported-transceiver
no errdisable detect cause gbic-invalid

Platformspecifieke bijzonderheden: op sommige Catalyst 9200-builds geeft de eerste opdracht % Ambiguous command terug; typ deze volledig uit. Op Nexus 9000 is dit een verborgen opdracht zonder tabaanvulling, maar deze wordt geaccepteerd.

Intel X520 (Linux). Laad de driver met de optie die niet-Intel-modules toestaat:

modprobe ixgbe allow_unsupported_sfp=1

Er bestaat een permanente variant die een bit in de EEPROM van de NIC zelf wijzigt; deze is in de onderstaande bronnen gedocumenteerd. Ga er zorgvuldig mee om, want een onjuiste schrijfbewerking naar de EEPROM van de NIC is in het veld niet herstelbaar.

ASR 9000-serie. Een module die in een reeds actieve poort wordt geplaatst, wordt mogelijk niet gedetecteerd: voer shut uit op de poort, plaats de module en voer vervolgens no shut uit.

De ingrijpende oplossing: hercodeer de module. Herschrijf de fabrikant-ID en het artikelnummer zodat de module zich als een eigen module presenteert. Dit doet CodingBox in de EEPROM editor, met herberekende CC_BASE/CC_EXT en eerst een back-up. Zie EEPROM-hercodering voor de werkwijze.

Het advies dat iedereen herhaalt

Bewaar van elk type één originele OEM-module op voorraad. Plaats deze vóór het openen van een supportticket, zodat de fabrikant het probleem niet aan optische modules van derden kan wijten.

Verifiëren op de switch

Bevestig na elk van de bovenstaande maatregelen dat de module wordt gezien en gelezen: zie Optische modules op een switch verifiëren voor de opdrachten per NOS en vergelijk die met de identiteit die CodingBox op de werkbank leest.

Wat een host precies vergelijkt — naam, PN, OUI, serieel patroon, handtekening van de fabrikant — en bij welke stap van het opstarten deze de module afwijst: Fabrikantvelden, Wat de host doet.

Validatiegedrag en overrides per fabrikant in één tabel: Hoe elk NOS een module valideert; de exacte PN-strings die platforms verwachten: OEM-artikelnummers; opdrachtsyntaxis per NOS: Recepten voor poortconfiguratie.


Vindt u een onjuistheid of fout in dit materiaal? Selecteer het betreffende fragment en druk op Ctrl+Enter om .