Aruba AP-375のアップリンク: Cisco BiDi SFPを動かす方法はあるか、それともAPは承認済みオプティクスに固定されているのか

完全なロックで、しかもよくあるコード化オプティクスの話ではありません。ArubaがAPアップリンク向けに認定しているのはSXとLXの2種類だけで、APのファームウェアにはアンロックコマンドが一切ないので、有効化できるものは何もなく、誰が作ったBiDiパーツであろうと受け入れられることはありません。

彼らが挙げる理由は商業的というより熱的なものです。AP筐体の内部は、通常の非産業用モジュールの定格をはるかに超える環境で動作します。中で加熱されたモジュールは早期に死ぬ可能性があり、ケージ内で故障したモジュールはAPそのものを道連れにすることもあります。承認リストが短く、それを広げる気がないのはこのためです。

現実的な回答としては、APの発注ガイドから承認済みのSXかLXの型番を取り出してそれを買うことです。あなたの1芯という制約が厄介な部分で、このAP向けにBiDiモジュールを認めているところはどこにもありません。

ありがとうございます、遠回りして自分で突き止めたことと一致します。APのCLIにはallow-unsupported-transceiverに類するものが本当に何もなく、APはモジュールを認識した素振りすら見せず、ただアップリンクが死んだまま座っています。同じBiDiペアは同じ1芯で2台のスイッチをリンクさせているので、オプティクスとファイバー自体は問題ではありません。

承認済みのLXを発注して、2本目の芯を引くことにします。ダクトには余裕があります。APがログに何も手がかりを残してくれないのには軽くいらだっていて、単純なunsupported-moduleのメッセージ一つあれば、波長を入れ替えて過ごした午後の時間が省けたはずです。

参考までに、スイッチ側でも同じ系統の苦労があります。うちのInstant Onスイッチは、そのポートに長年刺さっていたHPEブランドの1000BASE-Tモジュール、J8177Cに対してunsupported transceiverの警告を出し始めました。モジュールは変わっておらず、変わったのはソフトウェアの方です。トランシーバの検証はInstant Onソフトウェア2.9で導入され、承認リストの外にあるものは、HPEパーツの古いリビジョンも含めてすべてフラグが立ちます。allow-unsupported-transceiverも今はもうなく、リンクを保ったまま警告を黙らせる方法を見つけた人は、聞いた限り誰もいません。

1930系列では、見た目だけの警告では済まないこともあります。同僚のJL680Aでは、J8177D系統の銅線SFPが1000BASE-Tモジュールとして正しくログに記録されるのに、RJ45側に何を挿してもポートが一向にリンクせず、そのボックスにはオーバーライドが一切ありません。そこでのサードパーティ製品の結果はくじ引きのようで、FSの一部のパーツは上がったものの、他は一度もネゴシエーションできず、同じモジュールがCiscoの機器では問題なく動いていました。ボックスを発注する前に1個買ってテストしてください。