中古のDCS-7150S-24でサードパーティ製SFP+オプティクスがdownのまま: enable3pxのflashファイルはまだ使えるのか
ラボ用に中古のArista製スイッチを数台入手したところ、いきなりオプティクスの関門にぶつかりました。Aristaコード品のモジュールはリンクが上がり、パッシブDACケーブルもリンクが上がりますが、サードパーティ製は何であれポートがdownのままです。
ラボの構成:
- DCS-7150S-24、中古購入、サポート契約もアカウントチームの後ろ盾もなし
- 各種サードパーティ製SFP+モジュール
- ラック内の短距離用パッシブDACケーブル
Et1 passive DAC -> link comes up
Et5 third-party SFP+ -> port stays down
Et6 Arista-coded SFP+ -> link comes upここまでわかったこと:
- DACは上がるのにオプティクスは上がらないということは、配線でも死んだケージでもなくコードチェックだということ
service unsupported-transceiver CUSTOMERNAME LICENSEKEYという形式のコンフィグコマンドがあるが、当然ながら入手のしようがないキーを要求してくる- 古い記事にはキーの代わりにflash上のマーカーファイルについての言及があるが、どの世代に当てはまるのか判断できない
この年代のボックスに当てはまるのは2つの仕組みのうちどちらで、7150Sではflashファイルはまだ選択肢として使えるのか、それとも残っているのはキーのルートだけなのでしょうか。
Comments 6
その世代ではファイルの方です。そして聞こえる通り、かなり原始的な仕組みです。EOSのCLIから:
中身のない空のファイルで、それが存在するというだけでreload後にサードパーティ製オプティクスが有効になります。これが効くプラットフォームのリストは長く、DCS-7120T-4S、DCS-7050ファミリー、DCS-7150Sシリーズ全体などが含まれます。そしてどのモデルにも、そのファイルをまだ尊重する最新のEOSリリースがあり、古いボックスではおおよそ4.13.16Mから、7150Sでは4.23トレインまでの範囲です。より新しいスイッチはこのファイルを完全に無視します。
つまり7150S-24は、そのモデルが対応する範囲を超えていない限り、その境界線のいい方に入っています。キーのルートに手を出す前に、まずこれを試してください。
その7150S-24にはどのEOSトレインが乗っていて、購入後にアップグレードしましたか。それが重要なのは、カットオフがファミリー単位ではなくプラットフォーム単位だからです。フラグファイルは7048T、7120T-4S、7140T-8S、7124と7148のSFP+バリエーション、7050と7150Sシリーズ、7548S-LCラインカードで動作すると文書化されていますが、それをまだ尊重する最後のEOSリリースはそれぞれ異なります。
中古のボックスで既にEOSをアップグレードしているなら、自分でこの裏技を使えなくしてしまっている可能性は十分にあります。その場合、安上がりな対処はキーを探し回ることではなく、トレインを1つ下げることです。
ボックスが届いてからEOSには一切触っていないので、売り手が残していたトレインのままです。それが幸運でした。touch、write memory、reloadを実行すると、それまで死んでいたサードパーティ製SFP+モジュールが普通のポートとして上がってきました。キーもアカウントチームも他には何も要りませんでした。DACはその間ずっと問題なく動いていました。想定通りです。
より新しいボックスでここにたどり着いた人向けに: そちらでは本当にこのファイルは無視されていて、唯一の手段はrunning configurationに以下の形で置く顧客ごとの暗号キーです
キーはサポートではなくアカウントチームかセールスチームから出るものです。TACにはアンロックキーを発行する権限がなく、アカウントマネジメントに差し戻されるだけで、スイッチが中古市場から来たものである場合それは行き止まりです。
ラボ構築向けに繰り返しておく価値がありますが、パッシブDACケーブルはアンロック状態にかかわらずデフォルトで受け付けられます。距離が十分短いなら、DACで配線して、オプティクスは本当に必要なリンクのために取っておくことで、この問題全体を回避できます。
「running configurationに置かれる」という部分への小さな訂正ですが、私が扱っていた古いコードには同じコマンドの未文書化のバリエーションもあったので、上と構文が一致しない記述に出くわしても、それは誰かの打ち間違いというよりそこが出所です。
私の経験では、キーは再起動なしでも効果がありました。コマンドを入力した直後にほとんどのサードパーティ製オプティクスが動き出しましたが、何をしても拒否され続けるモジュールも数個ありました。それはもう手元にないハードウェアでの、しばらく前の話なので、メンテナンスウィンドウを計画する前に自分のボックスで確認してください。
この話題になるたびにこの比較が出てくるので書いておくと、Cisco IOS-XEとIOS XRでの相当処理は1段階ではなく2段階です。グローバルコマンド単体では足りず、モジュールを受け付けるべき物理ポートごとにインターフェース単位のコマンドも必要です:
インターフェース単位の行がプロダクトIDチェックを飛ばす方で、これによってポートは少なくともオプティクスを光らせようとするようになります。その後モジュールが実際に動く保証ではなく、プラットフォームが拒否するのをやめるというだけです。私はIOS XR 5.3.3とIOS-XEのボックスの両方でやったことがあります。
注意点は両ベンダーとも同じで、これがこの話題が議論され続ける理由でもあります。障害の原因が客先で取り付けたサードパーティ製トランシーバに辿り着いた場合、保証やサポート契約に基づくサポートが受けられなくなることがあります。ラボなら問題ありませんが、本番環境では意識的に下すべき判断です。