Arista 7050T(EOS 4.10.6)でサードパーティ製DWDM SFP+がリンクしない: イメージパッチ以外に手段はあるか

誰かがイメージの話に誘導する前に、2点。

その7050Tは実際どのEOSトレインに縛られている? 4.10.6に留まらなければならないなら、ビルド限定のハックでも一応筋は通る。動かせるなら知っておくべきだが、トランシーバの扱いは後のリリースで再編されていて、4.10.6向けに書かれた手順はそのままでは通用しない。

それと、そのサプライヤーは実際に何を書き込めるのか。プログラマーがそもそもAristaプロファイルを持っているのか、それとも大半が抱えているプラットフォームごとのCiscoコーディングしかないのか、確認する価値がある。例えばASR9K向けの部品には専用プロファイルが要るし、光モジュールベンダーはちゃんとそれを持っている。バッチを書き直してもらうほうが、改造イメージで運用し続けるよりずっと安上がりだ。あと別件として、account teamにunsupported-transceiverキーを頼んでみたか、それとも商業的な理由でその選択肢自体がないのか。

そのビルドに限れば、イメージパッチは実際に効く。作業量も大したことはない。ただしラボか予備機でやること、トラフィックを載せている機器では絶対にやらないこと。

大まかな流れはこうだ。EOS-4.10.6.swiをunzipして、boot0、initrd-i386、linux-i386、rootfs-i386.sqsh、versionというメンバーを取り出しておく。rootでルートファイルシステムを展開し、エージェントを編集して、再パックする:

unsquashfs rootfs-i386.sqsh
mksquashfs squashfs-root/ rootfs-i386.sqsh
zip -Z store EOS-4.10.6a.swi boot0 initrd-i386 linux-i386 rootfs-i386.sqsh version

編集そのものはsquashfs-root/usr/lib/python2.7/site-packages/XcvrAgent.pyの中で、172行目付近にあるpresence状態をassertしてからトランシーバ認証を実行する4行をコメントアウトする。zipの-Z storeは省略できない、swiは非圧縮のままでないとボックスが起動できない。

そのあとは何を挿してもポートが上がるようになる、もう何も検証していないので。代償は2つ。改造イメージにはベンダーサポートが一切つかないこと、そしてこのパッチはこのビルド専用なので、何かおかしくなったときに戻れるよう、純正の.swiをflashに残しておくこと。

上の質問への回答として。このボックスはサポート契約のない予備機で、サプライヤーのプログラマーにはAristaプロファイルが一切ない。Ciscoプラットフォーム向けのコーディングしかしておらず、それで終わりなので、このバッチを書き直してもらう選択肢はない。account team経由の道が完全になくなったわけではないが、今週の役には立たない。

説明の通りに4.10.6を再構築し、パッチ済みイメージで起動したところ、DWDMの両ポートとも一発でリンクアップした。純正イメージはまだflashに残してある。リンクはそれ以来安定していて、対向側でも特に異常は見えていない。

うまくいったのは何より。ただ、そのパッチの賞味期限についてはシビアに見ておいたほうがいい、上のスレッドだと実際よりも汎用的な話に聞こえてしまうので。

これは4.10.6専用で、それ以外では通用しない。4.14.5F、4.14.7M、4.23.8Mで同じことをする方法を聞いた人たちがいるが、動く答えを投稿した人は誰もいない。後のリリースではtransceiver managerが再編されていて、あの4行はそのままの形で待っていてはくれないからだ。アップグレードのたびにイメージも置き換わるので、パッチは消え、次に誰かが通常のメンテナンスをした時点でポートは落ちる。

アップグレードを生き延びるルートは、account teamが発行する顧客固有のservice unsupported-transceiverキーと、旧世代プラットフォームでのenable3pxマーカーファイルだけだ。パッチ済みイメージは古いボックスを延命させるために使うものであって、ネットワークの標準にするものではない。

Cisco側でも同じ戦いをした、持ち越す価値のある詳細付きで。サードパーティ製の80km DWDM SFP+(Pro10Optix、SFP-10G-DWDM-192とラベル表記)はCatalyst 6500では何の問題もなく動いていた。それをIOS XR 5.3.3のASR 9001に内蔵のSFP+ポートに移したところ、次が出た:

%PLATFORM-SFP-3-DEV_SFP_SUPPORTED_ERROR: SFP Module is not supported
%PLATFORM-SFP-3-DEV_SFP_PID_NOT_SUPPORTED: Not supported Product ID

ポートのLEDは赤、インターフェースはdown、状態はlink lossまたはlow light(ループバックなし)と報告され、波長は0nmと読み返され、レーザーは一度も発光しなかった。インターフェースにtransceiver permit pid allを入れても単体では何も変わらず、その上にグローバルのservice unsupported-transceiverを重ねてもそのバッチは救えなかった。このプラットフォームは自分の光学マトリクスからDWDM-SFP10G-xx.yy形式のパートナンバーを期待していて、汎用PIDはどの対応光モジュールにもマッピングされない。つまり、オーバーライドが緩めるべき対象がそもそも存在しない。

同じリリースの別の人はSkylaneのSPDTU080100D139 80kmモジュールを9001で動かせていたが、それも両方のコマンドを設定した場合に限られていて、そうしないとリンクが一度落ちたあとインターフェースが復帰しなかった。失敗したバッチは最終的に正しくコード化されたモジュールに交換された。

サプライヤーに戻るときに手戻りを減らせる点を一つ付け加えると、ブランド向けではなくプラットフォーム向けにコードしてもらうよう頼むこと。この手のスレッドの多くは、ベンダーとしては正しく名乗っているのにプラットフォームのマトリクスが知らないパートナンバーを持っているモジュールで、permit系のオーバーライドはボックスから見て他は正しそうに見えるモジュールのチェックしか緩めてくれない。

モジュールが手元のベンチにある間に、EEPROMが厳密にSFF-8472準拠かどうかも確認してもらうこと。雑なA2hデータは意味不明な値として読み返される、上で触れた波長0nmはまさにそのパターン。読み出しがきれいになってもなおプラットフォームがそのパーツを拒否するなら、サードパーティ製光モジュールについての一般論ではなく、ベンダーサポートに出せる具体的な材料が手に入る。