- コンシューマ向けルーター内部のように、スイッチチップをLinuxが直接制御する構成を再現するため、RTL8367SベースのギガビットスイッチPCBを設計し、DSA/switchdevに接続
- 選定した RTL8367S は、5ポートにPHYを内蔵した7ポートのギガビットスイッチチップで、専用CPUポートの代わりにポート0をネットワークケーブルでLinuxボードのEthernetに接続
- ハードウェア製作では、電源レールを 3.3V と 1.1V に単純化し、起動設定ピン・EEPROM・SPIフラッシュ・シリアルポートといった設定経路を検証
- Linuxとの接続にはPINE64 A64-ltsボード、カスタムカーネルオプション、Device Treeの修正が必要で、起動後は
eth0 の配下に lan1〜lan4 がローカルネットワークインターフェースのように現れる
- この方式はLinux bridgeや
ethtool のような既存ツールと相性がよいが、一般的なPC・サーバーやUSBネットワークインターフェースでは、Device Tree と GPIO の制約のためそのまま使うのは難しい
管理型スイッチとLinux DSAの構成
- 一般的な管理型スイッチは、Webインターフェースで設定を変更し、ポート状態を確認でき、より高価な機器ではtelnetやシリアルコンソールのような追加インターフェースも提供される
- コンシューマ向けルーター内部のスイッチも、別カテゴリの 管理型スイッチ と見なせる
- ルーターは小型のLinuxデバイスであり、内部にスイッチチップを持つ
- 1つ以上のポートはCPUに内部接続され、残りは物理ポートとして外部に露出する
- Linuxの DSA と switchdev サブシステムを使うと、スイッチに接続されたポートが実際の「ローカル」ネットワークポートのように動作する
- ルーターSoCとスイッチの間には、SGMIIまたはRGMIIのような接続と、SMIまたはMDIOのような管理バスが必要
- 一般的な既製スイッチは必要なチップ接続が外部に露出していないため、この方式で制御するのは難しい
RTL8367Sベースのスイッチボード製作
- 自作したギガビットスイッチは、Realtek RTL8367S チップを使用
- 広く使われている5ポートのギガビットスイッチチップ
- 実際には7ポート構成で、5ポートにはPHYを内蔵し、2ポートはCPU接続用
- データシートは最小限の情報しか提供しておらず、類似のRealtekチップを使った機器の回路図やEthernet設計文書も併せて参照
- 当初は約7本の電源ネットが必要に見えたが、電圧範囲が重なるネットをまとめることで、3.3V と 1.1V のレギュレータだけを使う構成が可能だった
- Linux switchdevでは、CPU接続が必ずしも専用CPUポートである必要はないため、この設計ではポート0をケーブルでLinuxボードに接続
- switchdevドライバからは、途中にEthernet PHYがないように見える
スイッチチップ設定とPCBでの試行錯誤
- RTL8367Sには複数の 設定経路 があるが、データシートだけでは通常のdumb switchとして動作させるための最小設定を把握しにくかった
- 起動時に読み取られる8本のピンは、ポートLEDピンと共有されている
- i2cバスはEEPROMチップ接続に使えるが、必要なSMIバスとピンを共有している
- SPIバスではNORフラッシュを接続し、設定レジスタや内蔵8051コアのファームウェアを保存できる
- シリアルポートは、8051ファームウェアがなければ動作しないと判断した
- 最初のボードは、実際に発注した後ではんだ付け配線を変えながら動作条件を探る方針で進めた
- フラッシュチップのフットプリントは入れたが、最終的には不要だった
- 設定ピンにはソルダージャンパを設けた
- LEDは設定可能にするのが難しく、搭載しなかった
- ギガビットEthernetの設計文書ではインピーダンス制御と厳密な長さ合わせが強調されるが、低価格スイッチ実機の設計はそこまで厳密には見えなかった
- より重要と考えたのは、ネットワークペア間の スキュー合わせ
- 4本のネットワークペア全体の長さを互いに揃えることには大きな意味がないと判断
- ネットワークケーブル内部でも4ペアの撚り率が異なり、長さにはもともと大きな差がある
- 初期のボードリビジョンでは、スイッチ側トランスのセンタータップをグラウンド基準にするためのコンデンサ処理を誤り、Ethernetが動作しなかった
- テストでは細いトレースを切ってグラウンドショートを解消
- テスト構成では、センタータップが浮いた状態でも動作した
- 最終設計では該当コンデンサを追加した
完成したスイッチとLinux接続
- 完成したボードは、少し変わった形の ギガビットスイッチ
- 4ポートは一方向を向く
- 1ポートは反対方向を向き、Linuxボード接続に使われる
- 電源は2.54mmピンヘッダから供給
- USB Type-Cコネクタのフットプリントも追加し、DuPontワイヤなしで給電できるようにした
- テスト用Linuxボードには PINE64 A64-lts を選択
- コネクタ位置がおおむね望んだ配置と一致していた
- Device Treeの変更が必要なため、x86ではないプラットフォームであることが重要だった
- カーネルは、スイッチ関連モジュールが通常有効になっていないため再ビルド
CONFIG_NET_DSA: Distributed Switch ArchitectureCONFIG_NET_DSA_TAG_RTL8_4: Realtekスイッチチップのポートタグ付けCONFIG_NET_SWITCHDEV: ネットワークスイッチドライバシステムCONFIG_NET_DSA_REALTEK, CONFIG_NET_DSA_REALTEK_SMI, CONFIG_NET_DSA_REALTEK_RTL8365MB: 実際のスイッチチップドライバ
- Device Tree overlayをU-Bootで読み込む代わりに、A64-ltsボードのDevice Treeを直接パッチした
realtek,rtl8365rb の互換文字列でドライバをロード- このドライバは、使用したRTL8367Sを含む複数のRealtekスイッチチップをサポートする
- ドキュメント例のCPUポート定義を削除し、5つの通常スイッチポートを定義
port@0 は背面向きのポートで、A64-ltsの &emac に接続
- 残りのポートは、スイッチチップ内部の各PHYに接続される
- Device Tree上部には、SDA/SCLおよびResetに接続される3本のGPIOが定義されている
Linuxネットワークツールと制約
- 起動後のLinuxには、通常の
eth0 デバイスとともに、Device Treeで定義したスイッチポートインターフェースが現れる
lan1@eth0lan2@eth0lan3@eth0lan4@eth0
- 実際に動作させるには、
ip link set eth0 up と各 lan インターフェースを有効にする必要がある
- 標準的なLinuxネットワークツールとの統合は自然
- 複数の
lan ポートをLinux bridgeに入れると、switchdevがそのポートブリッジ処理をスイッチチップ内部で処理する
- Linuxがそのトラフィックを直接フォワードする必要はない
ethtool lan3 でリンク情報を確認できるethtool -S lan3 は、スイッチが完全に処理したパケットを含む標準的な状態情報を返す
- ただし、一般環境で使うには制約が大きい
- 自分でネットワークスイッチを作るか、既存スイッチを開けて必要な接続を探す必要がある
- 一般的なPCやサーバーはDevice Treeベースの構成ではなく、カーネルが制御するGPIOピンも通常は使えない
- USBネットワークインターフェースには、conduitポートとして指定するDevice Treeノードハンドルがなく、この方式には使いにくい
- 一部の制約は回避できる可能性もあるが、GPIOを露出する特殊なUSBデバイスやARMデバイス以外の環境でswitchdevをロードする方法については、さらに多くの文書が必要
1件のコメント
Hacker News のコメント
たとえば古い Dell OS9 スイッチのペアは、48 個の 10Gb/s ポートと 4 個の 40Gb/s QSFP+ 光ポートを備えた旧式のスタック対応機器で、スイッチ 1 台で最大 1.28Tb/s を処理できます
今では VAT 込みで約 1800 ポンドで入手でき、ほぼ永遠に使えます
こうした試みは良いものですが、Netgear などが全ポート PoE 対応の 8 ポート 1Gb スイッチを約 125 ポンドで売っている点も考慮する必要があります
プロジェクトの採算性を見るときに、自分の時間を時給 20〜50 ポンドで計算するなら既製品が正解かもしれませんが、目的がプロジェクトそのものなら価格は気にしなくてよいでしょう
(1) https://i.dell.com/sites/doccontent/shared-content/data-shee...
(2) https://www.etb-tech.com/dell-force10-s4820t-10gbe-switch-os...
ASIC の価格は予想できる範囲で、実際の数字は知りませんが数百ドルくらいだったと思います
ソフトウェアインターフェースのドキュメントは非常にお粗末で、すべての Broadcom スイッチ ASIC をサポートするライブラリだったため、数百 MB の
.aファイルには「このデバイスではサポートされていません」というエラーだけを返す関数が大量にあり、実際に呼び出してみるまで分かりませんでしたより単純な用途なら、たいていは管理型スイッチチップを使う OpenWRT 対応ルーターを入手でき、OpenWRT が VLAN やさまざまなオプションを設定しやすいインターフェースを提供してくれます
ただし PoE や 10Gb/SFP+ ポートのような機能のサポートは限定的な場合があり、現在の状況ははっきりしません
しかしこのプロジェクトは「非管理型スイッチに外部の頭脳を付ける」方式ではなく、私が初めて見た自作の管理型スイッチに近いものです
ハードウェア側の性能は良さそうですが、実際の差を示すテストがあったのかは分かりません
USB アダプターを使うと、USB は多くの面で共有バスなので最大帯域にすぐ達してしまい、データが CPU まで入ってからまた出ていく必要があるため、なおさらです
ソフトウェアでスイッチングすると、各パケットを処理して正しい場所へ送り直す時間が追加され、インターフェース自体の遅延も加わります
アダプターごとに独自のネットワーク PHY とハードウェアがあるため消費電力が増え、追加処理も合わさって消費電力はさらに大きくなります
ハードウェアオフロードやその他の性能改善もあまり活用できず、システム全体がパケット移動により多く関与することになります
機能面では選んだハードウェア次第で、安価な USB ギガビットアダプターの中には VLAN などの機能がきちんと動かないものもありました
逆に PCIe カードを複数使えば機能はずっと良くなり得ますが、その時点からはスイッチングというよりルーティングに近くなります
ホスト OS が落ちてもスイッチングは動き続けられますし、ウォッチドッグと復旧を組み合わせれば、一時的に一部機能が使えなくても、ソフトウェアブリッジより可用性の高いシステムを作れます
ただし、スイッチチップ自体が死んだりハングしたりしないことが前提です
目的によりますが、スイッチを通るすべてのトラフィックを検査したいなら、4 つのインターフェースのほうが明らかに優れています
ホストベースのスイッチが通信も多く行うなら、4 つのインターフェースはホストに 4Gbps を提供し、単一の 1Gbps より有利です
企業向けの中古クアッド 1G カードは eBay で 15 ドル以下で買え、私は Silicom quad bypass 1g
PEG4BPI-SDを好んでいますバイパス機能が面白く珍しいのでさらに安いですが、たいていは一度「標準 NIC」のように設定しておけば、大きな問題なく別の場所に挿して使えます
初期製品は PCI ID のベンダーとサブベンダーが Silicom になっていて使うのがより難しく、
-SDカードは Intel のベンダー ID と Silicom のサブベンダーなので一般的なドライバーが付きます4x10G ポートは管理することが多く、ホストシステムによってはソフトウェアブリッジングのスループットが十分でない場合があります
クアッドポート 10G カードは入手しにくいですが、2x10G なら待てば妥当な価格で手に入ります
スイッチは CPU ではなく ASIC でパケットスイッチングを行うため CPU 性能に左右され、通常は持っている計算資源を効率よく使う方法ではありません
それでも設計と製作の手間を無視すれば、全体のハードウェアコストは 100 ドル未満にできる可能性があり、複数インターフェースを備えたコンピューターより安上がりかもしれません
ただし 1Gb/s ネットワークはかなり古い部類です
既製部品だけでも、200ドルを少し超える程度の費用で、より大きく高速なマネージド・ネットワークスイッチを作れる
例えば、2ポートを備えた Odroid H4+ と、イーサネットポートを4つ追加する M.2 拡張カードを使えば、6ポートの 2.5Gb/s スイッチを作れる
もう一つの方法は、N100 CPU と4つの 2.5Gb/s ポートを備えた小型コンピュータを使うことで、この価格帯で複数の中国メーカーから購入できる
6つの 2.5Gb/s ポートを備えた同様の小型コンピュータは少し高く、300ドルをやや超える場合がある
こうしたデバイスにぴったり合いそうだが、実験室環境を整えるのがほぼ不可能で、興味を失ってしまった
CPU でスイッチングすると負荷が大きいので、そうしたチップが必要なのだと思う
88E6393Xは、ファームウェアなしで「シンプル／外部管理」モードで動作するこの記事のデバイスのように、Linux switchdev と併用できる
ハードウェアスイッチがシステムの他の部分とどう接続されるかを示すために RouterBoard のブロック図をモデルにしたのに、続けてそうしたデバイスは扱えない、あるいは扱いにくいと主張しているように見える
ここで RouterBoard を実際に入手したことがあるのか気になる
ほとんどの RouterBoard 向けに OpenWRT をビルドできるはずで、2011 は中古市場でもかなり一般的な機器だろう
より良い問いは、目標が最初から ゼロから自作 することだったのか、それとも他人のハードウェアを使うという考えを特定の理由で捨てたのか、という点だ
RB2011 の図はシンプルで説明が分かりやすいと思ったので持ってきた
技術的には、同じスイッチチップを使う RB1100AHx4 のほうが良い例だが、2つの CPU ポートを一緒に使い、エンコードのオーバーヘッドを無視したまま、2本の 1.25Gbps リンクを 2.5Gbps リンクだと主張していて、かえって分かりにくい
ゼロから作った理由は、コストが妥当で、このデバイスを FOSDEM の映像録画ボックスに組み込む必要があるからだ
その設計に特有の問題をいくつか解決する必要があり、ケースのフロントパネルにネットワークポート4つを露出しつつ、内部の SBC にも接続されていなければならない
ケース内には、SBC 用の外部ループケーブルなしでスイッチまでパススルーを入れる余地があまりなく、単純なスイッチを使うとシステム監視もできない
こうしたボックスをかなり多数作るので妥当な解決策であり、設計時間を無視すればボランティア作業なので可能だ
問題は NAND とある程度関係しているようで、記憶ではサポートされている他の RouterBoard とは何かが違う
誰かがこの問題に対する新しい解決策を提案したが、まだ取り込まれていない: https://forum.openwrt.org/t/wiki-cleanup-for-mikrotik-rb2011... および他のスレッド