Fabrikantvergrendeling en codering

Veel switches inspecteren de identiteit van een transceiver — fabrikantnaam, artikelnummer, soms serienummer — en beschouwen modules die niet overeenkomen met een goedgekeurde lijst als ‘niet ondersteund’. Dit is fabrikantvergrendeling, en daarom kan een volledig goede optische module in de ene switch worden afgewezen en in een andere werken.

Hoe switches reageren

• Sommige platforms waarschuwen maar laten de module toe.
• Sommige schakelen de poort uit of weigeren diagnostiek voor een niet-herkende optische module.
• Cisco IOS heeft bijvoorbeeld de globale optie service unsupported-transceiver die optische modules van derden toestaat.

Wat codering doet

Codering schrijft de fabrikant- en artikelnummervelden die een doelswitch verwacht in het geheugen van de module, zodat de switch deze accepteert. Omdat die velden door checksums worden beschermd, moeten ze na de wijziging opnieuw worden berekend. CodingBox berekent CC_BASE en CC_EXT automatisch opnieuw in de EEPROM editor.

Veilig werken

1. Lees de module uit en laat CodingBox hem opslaan in de codedatabase; vóór elke schrijfactie wordt een back-up gemaakt.
2. Bewerk de identiteitsvelden (en ontgrendel zo nodig beveiligde pagina's).
3. Schrijf de gekozen pagina's en lees ze daarna terug ter bevestiging.

Codeer transceivers alleen voor interoperabiliteit waartoe u gerechtigd bent en volg het beleid van uw organisatie en van fabrikanten.

Verder lezen

• Hoe elk NOS een module valideert — wat wordt vergeleken, wat gebeurt er bij fouten, gedocumenteerde overrides, per fabrikant.
• Recepten voor poortconfiguratie — opdrachten voor snelheid, FEC, AN, breakout en overrides voor 12 systemen naast elkaar.
• Compatibiliteitsmatrices & firmware — waar ondersteuning wordt gepubliceerd, hoe u die leest, wat er bij upgrades verandert, praktijk voor de omgeving.