EX4200がJunosアップグレード後にSFP+ EEPROMをmis-programmedと報告、MX960ではDOMが出たまま
EX4200からいくつかの80km DWDM区間を、両端ともサードパーティ製オプティクスで運用しています。ベンダー純正のDWDM部品では到底予算に収まらなかったためです。それで何年も問題なく来ました。EX側をJunos 12.3に上げた後、オプティクスは同じポートに挿さったままで区間もそのまま存在しているのに、スイッチはそのモジュールがオプティクスであることすら認めなくなりました。
- EX4200、Junos 12.3(同じシャーシの11.4ではDOMは問題なく動いていた)
- Integra SFPP-C51-80-10GD、DWDM 80km SFP+
- 同じ区間の対向にあるMX960、部品番号は同一、DOMは変わらず完全に出る
user@ex4200> show interfaces diagnostics optics xe-0/1/0
Physical interface: xe-0/1/0
Unknown cableモジュールを挿入するとmessagesログにはちょうど1行だけ出ます。SFP+ of type 0 EEPROM is Mis Programmed
すでに除外したこと:
- オプティクスを挿し直し、同じシャーシの別のポートに移してみたが変化なし
- ラボの予備のEX3300とQFX5100でも試したが、どちらも同じ挙動なので1台だけの故障ではない
- 対向側をもう一度確認したが、MX960では同じ発注の同じ部品でフル診断が出る
つまりEX側のドライバは、古いリリースでは単に無視していたEEPROM内の何かを、今は厳格にチェックしているのでしょうか。もしそうなら、オプティクス自体に何か手を打てることはあるのか、それともこれはサプライヤーと話すべき話なのでしょうか。
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 6
そのログの行はただの一般的な文句ではなく、ドライバがどのチェックに失敗したかを教えてくれているものです。
ページA0のバイト3から10には、SFF-8472で定義されたトランシーバのコンプライアンスコードが入っています。10GBASE-SR、LR、ER、SONETのコード、ファイバーチャネルのコードなどを示すビットです。この種のオプティクスではこの8バイトすべてがゼロになっていて、だからメッセージはtype 0と呼んでいます。仕様ではこのフィールドのどこかに少なくとも1ビットが立っていることを想定していて、全ビットゼロのコンプライアンスフィールドは有効なモジュール記述ではありません。古いEXのコードはここを見ずにいきなり診断ページのパースに進んでいましたが、新しいドライバは先にこのフィールドを検証し、既知の10Gオプティクスとして扱うことを拒否します。だからunknown cableになりDOMも出ないわけです。MX系は同じ経路でこのチェックを行わないので、まさにそれが同じ部品がそちらでは動き続けている理由です。
誰かと議論する前にまず自分で証明してください。シェルに落ちて、そのポートでxcvrpeekのページA0を見て、オフセット3から10を確認します。全部ゼロならそれで決着です。
その場で直そうとすると、たいていここで詰まります。理論上はxcvrpokeで同じバイトを書き戻せます。ただ実際には多くのベンダーがA0ページをロックしていて、書き込みはEIOを返し、スイッチ側からはどうにもできません。残るのはサプライヤーです。実際のコンプライアンスコードを書き込んだ状態でオプティクスを出荷するか、A0のロックを外した状態で出荷して自分でビットを立てられるようにするか、どちらかしかありません。どちらもできないなら、それはJunosの衣装を着ているだけのサプライヤー側の問題です。
誰かが推測を始める前に、はっきりさせておく価値のあることが2つあります。
まず、それぞれの機器の正確なリリースです。EXは12.3に上げたとのことですが、MX960は何を動かしていますか。まだ古い系統のままなら2台は本当の意味で比較にならず、その違いからはまだ何も分かりません。
次に、MX側の部品は文字通り同じバッチのSFPP-C51-80-10GDですか、それとも別の発注の同じモデルですか。バッチ間の違いは誰もが思っている以上に大きいものです。
両端から
show interfaces diagnostics opticsの結果を貼ってください。それと、オプティクスを抜き差ししたときにmessagesログに出るものを、すでに引用した1行だけでなく全部お願いします。両端とも同じ部品、SFPP-C51-80-10GD、同じ発注で、シリアル番号も連番です。
MX960では
show interfaces diagnostics opticsが温度、レーザーバイアス電流、TXパワー、RXパワーとフルセットを出します。EX4200では同じコマンドがインターフェースのヘッダーとunknown cableの行を出すだけで、他には何もありません。オプティクスを挿し直すと、どのポートを使ってもログにSFP+ of type 0 EEPROM is Mis Programmedが出るだけで、それ以上は何もありません。引っかかるのは、アップグレード前はまさにこのオプティクスがまさにこのシャーシのこのポートで、何の文句もなくDOMを報告していたということです。
付け加えると、この読み取り専用の部分は柵の反対側にも存在します。Ciscoでは
show idprom interface <if> detailが識別バイトをシェルに落ちるような曲芸なしにそのままダンプしてくれるので、モジュールをJuniperの機器に近づける前に、予備のスイッチでバッチを確認するのに便利です。読み取りはどこでも無害です。ホストから書き込むのはまったく別物で、xcvrpokeは内部ツールであり、モジュールを修理する手段としてはサポートされていません。すでに触れた通り、どのみち半分近くはベンダーロックで書き込みがブロックされます。これはEEPROMの何がおかしいかを証明するために使い、その証拠をオプティクスを売った相手に渡してください。
同じ種類の問題ですが症状はまったく違う話を、検索でここにたどり着いた人のために書いておきます。
無名メーカーの1G BiDi WDM SFPをEX4600のge-0/0/1に挿したところ、インターフェース自体が存在しませんでした。
show interfaces terseにも出てこず、何かコマンドを打ってもerror: device ge-0/0/1 not foundが返ってくるだけです。ログにはOPTIC State changed for port: 0/0/1、続いてFibre channel transceiver plugged in without Fibre channel configuration!!と出ていました。EEPROMのコーディングのせいでJunosはこのモジュールをGigabit Ethernetではなくファイバーチャネルトランシーバとして分類し、そのためEthernetインターフェースが一切作られませんでした。これはどれだけ設定をいじっても直らず、直るのは正しくコードされたモジュールに替えた時だけです。そして安物市場に限った話でもありません。Citrixブランドの10G SFP+のあるバッチでは、ベンダー純正の部品なのにNetScaler MPXとSDXアプライアンスが起動時に
*** Unsupported SFP+/SFP type !とログに出しました。当たりのユニットはラベルにA2リビジョンの表示があり、はずれはRMAで返品になりました。コーディング不良はどの価格帯でも起こります。確認できました、正確なオフセットをありがとうございます。
ページA0でxcvrpeekを実行すると、確認したSFPP-C51-80-10GDのすべてでオフセット3から10がゼロでした。箱に入ったままの分も含めてです。xcvrpokeはすぐにEIOを返してくるので、A0はロックされていて、こちら側で救える部分はありません。
バイトオフセットと引用したログの行を持ってサプライヤーに戻りました。先方はそれを受け入れて、バッチを実際のコンプライアンスコードで再コードしているところです。MX960に挿さっている分はそのままにしておきます、あちらのプラットフォームでは何も文句を言わないので。上の説明を回答としてマークします。