Catalyst 2960XがSFPダンプの何を計算しているのか: ベンダーコード、名前、MD5、そしてダンプのコピーが通らない理由
プロバイダのネットワークを保守していて、モジュールの構成が混在しているため、特定のスイッチ向けにモジュールを用意する作業が定期的に発生します。ダンプを当てずっぽうで選ぶのではなく、チェックの仕組みをきちんと理解したいと思っています。
手元にあるもの:
- Cisco Catalyst 2960X-24PS-L、手持ちの中で一番うるさい
- QTECH QSW-3750-28TX-ACとD-Link DGS-3420、こちらは同じモジュールが素直に上がる
- モジュールはSNR-SFP+SRとSFP-10G-BX
Catalystで受け入れられるモジュールのダンプでは、先頭にベンダーコードのバイト、続いてASCIIの名前が見えます。
0E 43 49 53 43 4F ...試したこと: C2960X-24PS-Lで上がるモジュールからダンプを取り、そのダンプのベンダー名だけを別のモジュールに書き込みました。QTECHとD-Linkではこれで問題なく上がりますが、Catalystはそのモジュールを受け付けません。書き換えたバイトはドナーと1バイトも違わず一致しているのに、です。
そこでチェックの仕組みについて質問です。Ciscoは実際に何をどのバイトから計算していて、結果はモジュールのどこに置かれているのか。そして動作するダンプからコピーしたベンダー名だけでは、なぜ足りないのか。ロジックさえ分かれば、あとは自分で何とかします。
Show original (Русский)
Also available in: Русский
العربية
Deutsch
English
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Türkçe
Tiếng Việt
简体中文
Comments 6
仕組み自体は単純で、とっくに解析されています。チェックされているのは単独のフィールドではなく組み合わせで、ベンダーコードのバイトとベンダー名のバイト列です。この並びからMD5を取った結果がモジュール自体に置かれていて、スイッチは同じ計算をして比較します。
標準ユーティリティだけで再現でき、特別なものは何も要りません。
自分のコードと自分のベンダー名を当てはめれば、モジュールに入っているべき値が得られます。ダンプで実際に見かけるコードとしては、02がFinisar、0EがMethode、11もよく出てきますが、どこのものかはついに特定できませんでした。コードと名前のペアが整合していてハッシュもそれに対応していれば、モジュールはC2960X-24PS-Lを通ります。
前の投稿への補足です。受信側に実際何が入っているか見せてください。ベンダーコードのバイトは何が残っていて、隣の名前は何になっていますか。書かれている内容からすると、名前だけ移してコードかハッシュ自体は元のモジュールのままなのでは。だとすると組み合わせがずれて、Catalystが弾くのは完全に正当です。スイッチの出力に見える項目だけでなく、三つとも一度に確認してください。
確認しました、そちらの説明どおりでした。ドナー側は0Eの後にCISCOと続きますが、受信側は確かに名前だけ書き換えていて、ベンダーコードは元のまま、ハッシュも古いままでした。両方の組み合わせをxxd -r -pとmd5sumに通したところ、ドナー側はモジュールに入っている値と一致しましたが、自分で手作業で組んだ方は一致しませんでした。
つまり移すのはフィールド単体ではなく組み合わせ全体だということですね。おかげでポートにモジュールを挿す前に、どこを見て何を照合すればいいか、少なくとも分かるようになりました。
みんな忘れがちな重要な帰結があります。ベンダーコードと名前が整合していなければ、スイッチで非対応モジュールを許可する設定にしていても、Catalystではモジュールは通りません。よそのダンプが当たり外れなのはまさにこのためで、部分的にしか修正されておらず、チェックは組み合わせを見ているからです。
ここから容量についての実務上の結論が出ます。256バイトのダンプでは意味があるのは最初の128バイトまでで、その先はベンダー領域です。イメージ全体を持ってくる必要はなく、前半をまとめて整合を取って移す必要があります。スイッチの出力には目に見えないフィールドも含めてです。
ちなみにダンプだけですべて解決するわけではありません。Medick SFP-10G-BXの中身はメモリではなくC8051F392マイコンで、A0とA2をエミュレートしていて、パスワードやベンダー側の問い合わせを保持していることも十分あり得ます。そこでは組み合わせをバイト単位まで合わせたところで、外から書いたものは単純に受け付けられません。実際に使っているツールとしてはSNR SFP WriterとSFPTotal Plusで、同僚のところではCH341ベースの自作品もあります。
後から来る人が混乱しないよう、少し補足しておきます。このMD5はMSAのチェックサムとは何の関係もありません。SFF-8472のCC_BASEとCC_EXTは単純なバイト加算で計算されていて、簡単に計算し直せます。ベンダー側のチェックはその上に、独自ルールで乗っていて、MSAのサムが完全に正しいそのタイミングでモジュールを弾きます。だからこそ、ダンプは正しいはずなのにモジュールが受け付けられないという感覚になるわけです。
ちなみにCiscoは決して最悪の部類ではなく、仕組みが理解でき再現もできるだけましです。一番厄介なのはHPとArubaで、メモリがインタラクティブに振る舞い鍵を要求してきます。あそこはもうダンプだけではどうにもなりません。