Il Lenovo RackSwitch G8124E rifiuta un SFP+ 10G SR generico con UNAPPROVED - SR SFP+ is DISABLED
Abbiamo tirato fuori una coppia di G8124E da un rack dismesso e li sto ricostruendo come layer di aggregazione per un ambiente di test interno. Il budget per ottiche a marchio è zero, quindi va tutto dentro con moduli 10G SR generici dello stesso tipo che usiamo già altrove.
- Lenovo RackSwitch G8124E, chassis ex marchio IBM
- SFP+ 10G SR generici, duplex LC, stesso lotto di quelli che funzionano nel nostro top-of-rack di produzione
- patch OM3 verso una NIC server che si aggancia a 10G con lo stesso identico tipo di modulo
La porta si accende per un attimo e poi lo switch la spegne:
UNAPPROVED - SR SFP+ is DISABLEDDopo di che il link non si stabilisce mai e la porta resta giù.
Cosa ho già provato:
- spostato il modulo attraverso quattro gabbie diverse, messaggio identico ogni volta
- inserito un secondo modulo dallo stesso lotto e un terzo da un altro fornitore
- passato in rassegna la config dell'interfaccia cercando qualcosa come un interruttore allow-unsupported e non ho trovato niente
C'è un modo per far accettare a questa scatola ottiche di terze parti, o il controllo di approvazione è qualcosa che si può soddisfare solo con moduli a codifica Lenovo?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 5
Prima che qualcuno ti dia un comando, cosa riporta
show version? Su questa famiglia il rimedio non è un comando unico, si divide per code train: quello che fai su un'immagine 7.x non è quello che fai su una 8.x, quindi la versione va stabilita per prima cosa.Di' anche se i moduli sono generici puri o portano una stringa vendor riconoscibile nell'EEPROM. Il firmware valuta ogni modulo in base a quella stringa, e chi ha SFP+ a codifica Intel proprio su questo switch riceve comunque l'avviso di transceiver non approvato, quindi il messaggio da solo non dice molto sull'ottica in sé.
show versionla colloca su un'immagine 7.x, quindi il train più vecchio e non quello attuale.I moduli sono generici puri, senza codifica Intel o Cisco dentro, si identificano come l'OEM che li ha costruiti. Ho anche messo il terzo modulo in un IBM RackSwitch G8124 vicino e ho ottenuto lo stesso comportamento anche lì, quindi non è una gabbia difettosa o un'ottica difettosa isolata.
Sui filoni più vecchi c'è una variabile del boot loader che spegne il controllo di approvazione. È documentata per 5.x, 6.x, 7.x e 8.3.x o inferiori, quindi una scatola 7.x rientra.
Per questo serve la console seriale, la porta mini-USB RS232, non la rete. Ricarica lo switch e tieni premuto Shift+M durante il test di memoria finché il boot loader non ti dà il prompt
=>, poi:Il valore distingue maiuscole e minuscole,
Overridecon la O maiuscola. Eseguiprintenvprima dibootcosì puoi vedere davvero che la variabile è stata salvata. Una volta che lo switch finisce di avviarsi smette di disabilitare i moduli SFP+ non approvati e le porte salgono e basta.Due avvertenze. Questa è una misura da laboratorio e di emergenza, Lenovo non supporta ottiche di terze parti e niente di tutto ciò è ufficiale. E stai alla larga dalle ottiche dual-rate su queste scatole più vecchie, danno problemi anche dopo che il controllo è stato tolto di mezzo.
È la stessa storia su tutta la linea switch Lenovo, non solo sul G8124E. Ho qui un G8272 che valuta un Cisco-Finisar
SFP-10G-LR-Scome Unapproved, mostra la porta come Disabled e lascia il link giù. Ottica Cisco autentica, semplicemente non sulla lista di Lenovo.Sul lato ThinkSystem, NE1032 e NE1032T, è CNOS invece di ENOS, e lì la via d'ingresso è un comando a livello platform per permettere i transceiver non supportati invece del trucco del boot loader. Non l'ho provato io stesso, quindi verifica la sintassi sulla tua scatola prima di pianificarci intorno una finestra di manutenzione. Lo schema sottostante non cambia: il firmware confronta la stringa vendor dell'EEPROM con una lista e disabilita tutto quello che non riconosce.
Una cosa da aggiungere: l'override non sopravvive necessariamente a un aggiornamento firmware. Se spingi una nuova immagine e le porte muoiono di nuovo, torna sulla console seriale e controlla
printenvprima di iniziare a togliere moduli, la variabile potrebbe semplicemente essere sparita.E non trattare gli interruttori di sblocco vendor come affidabili in generale. Su Catalyst 9200 con IOS-XE 16.9.x
service unsupported-transceivernon ha alcun effetto grazie a CSCvk03296, e quello che la gente usava al suo posto erano errdisable recovery cause gbic-invalidin configurazione globale, che teneva le porte al riparo dall'err-disable e lasciava funzionare i moduli FS e Cables and Kits. Vendor diverso, stessa lezione: la manopola documentata e la manopola che funziona davvero non sono sempre la stessa.