Lenovo RackSwitch G8124Eが汎用10G SR SFP+をUNAPPROVED - SR SFP+ is DISABLEDで拒否する
廃止されたラックからG8124Eを2台取り外して、社内テスト環境のアグリゲーション層として組み直しています。ブランド物の光モジュールに使える予算はゼロなので、すでに他所で運用しているのと同じタイプの汎用10G SRモジュールで全部揃えています。
- Lenovo RackSwitch G8124E、旧IBMブランドのシャーシ
- 汎用10G SR SFP+、デュプレックスLC、本番のtop-of-rackで動いているのと同じバッチ
- OM3パッチでサーバーNICへ、まったく同じタイプのモジュールで10Gリンクする相手
ポートは一瞬生き返りますが、そのあとスイッチが落とします:
UNAPPROVED - SR SFP+ is DISABLEDそのあとリンクは一切確立せず、ポートはダウンしたままです。
すでに試したこと:
- モジュールを4つの異なるケージに順番に挿したが、毎回同じメッセージ
- 同じバッチから2個目のモジュール、別の供給元から3個目のモジュールを試した
- allow-unsupportedのようなノブがないかインターフェース設定を一通り見たが何も見つからなかった
この箱にサードパーティの光モジュールを受け入れさせる方法はありますか、それともこの承認チェックは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
誰かがコマンドを渡す前に、
show versionは何を報告していますか? この機種ファミリーでは対処法は1つのコマンドではなく、コードトレインによって分かれます: 7.xイメージでやることと8.xでやることは違うので、まずバージョンを確定させる必要があります。あとモジュールが単なる汎用品なのか、それともEEPROMに認識可能なベンダー文字列を持っているのかも教えてください。ファームウェアはその文字列でモジュールを評価していて、まさにこのスイッチでIntelコードのSFP+を使っている人たちもunapproved transceiverの警告を受けているので、メッセージだけでは光モジュール自体についてあまり多くは分かりません。
show versionによると7.xイメージなので、現行ではなく古い方のトレインです。モジュールは正真正銘の汎用品で、IntelもCiscoもコーディングされておらず、製造したOEMとして識別されます。3個目のモジュールを隣に立っているIBM RackSwitch G8124にも挿してみましたが、そこでも同じ挙動でした。なので特定の不良ケージや不良光モジュール1個の話ではありません。
古い方のストリームには、承認チェックをオフにするブートローダ変数があります。5.x、6.x、7.x、8.3.x以下について説明されているので、7.x機は対象内です。
これにはシリアルコンソールが必要です、ネットワークではなくmini-USBのRS232ポートです。スイッチをリロードして、ブートローダが
=>プロンプトを出すまでメモリテストの間Shift+Mを押し続けてください、それから:値は大文字小文字を区別します、
Overrideは先頭が大文字のOです。変数が実際に保存されたことを確認できるよう、printenvをbootの前に実行してください。スイッチの起動が完了すると、未承認のSFP+モジュールを無効化するのをやめ、ポートはそのまま上がってきます。2点注意があります。これはラボ用・緊急用の措置で、Lenovoはサードパーティの光モジュールをサポートしておらず、ここに書いたことは何も公式ではありません。あとこれらの古い機種ではdual-rateの光モジュールは避けてください、チェックを回避した後でもトラブルの原因になります。
これはG8124Eだけでなく、Lenovoのスイッチライン全体で同じ話です。手元のG8272はCisco-Finisarの
SFP-10G-LR-SをUnapprovedと評価し、ポートをDisabledと表示してリンクをダウンのままにします。正真正銘のCisco製光モジュールですが、単にLenovoのリストに載っていないだけです。ThinkSystem側、NE1032とNE1032Tでは、ENOSではなくCNOSで、そちらではブートローダの裏技ではなく、未サポートのトランシーバを許可するプラットフォームコマンドが入り口になります。自分ではまだそれを実行したことがないので、作業ウィンドウを計画する前に自分の機体で構文を確認してください。根底のパターンは変わりません: ファームウェアがEEPROMのベンダー文字列をリストと照合し、認識できないものを無効化します。
一つ付け加えると: そのオーバーライドはファームウェアのアップグレードを必ずしも生き残るわけではありません。新しいイメージを入れてポートがまた死んだら、モジュールを抜き始める前にシリアルコンソールに戻って
printenvを確認してください、変数が単純に消えている可能性があります。それとベンダーのアンロックスイッチ全般を信頼できるものとして扱わないでください。IOS-XE 16.9.xのCatalyst 9200では、CSCvk03296のせいで
service unsupported-transceiverはまったく効きません。代わりに人々が使っていたのはグローバルコンフィグのno errdisable recovery cause gbic-invalidで、これによってポートがerr-disabledになるのを防ぎ、FSやCables and Kitsのモジュールを動かせました。ベンダーは違いますが教訓は同じです: 文書化されているノブと実際に効くノブが同じとは限りません。