従来のツールが高速環境で機能しない理由
標準的なLinuxツールであるiperf3やnetperfは、ハードウェアが限界に達するずっと前に処理しきれなくなります。これらのツールはLinuxカーネルのネットワークスタックに依存しています。堅牢ではあるものの、カーネルは割り込み処理やコンテキストスイッチによって大きなオーバーヘッドを生みます。単一のiperf3ストリームで10Gbpsリンクに負荷をかけようとしたとき、CPUコアは100%に達したのに、スループットはわずか3.8Gbpsで頭打ちになってしまいました。
大規模な展開前にハイエンドルーターや次世代ファイアウォール（NGFW）を検証するには、ワイヤーレートのトラフィックが必要です。OSの制限を受けるわけにはいきません。そこで私はTRexに切り替えました。6ヶ月間データセンター間の接続をベンチマークした結果、安定して毎秒数百万パケットを生成できる唯一のオープンソースツールだと確信しています。
DPDKの優位性
TRexはData Plane Development Kit（DPDK）上で動作します。Linuxカーネルにパケット処理を任せるのではなく、TRexがNIC（ネットワークインターフェースカード）を直接制御します。カーネルを完全にバイパスするこのアーキテクチャにより、一般的なサーバー1台で数百ギガビットのトラフィックを生成できます。
TRexが一般的なトラフィックジェネレーターと異なる点は以下の通りです：
- 真のスケーラビリティ：10GbEリンクで毎秒1,488万パケット（pps）を転送可能。これは64バイトパケットの理論的な最大値です。
- IMIXトラフィック：64B、594B、1518Bのパケットを混在させた「インターネットミックス」パターンをシミュレートし、均一なデータストリームではなく実際のトラフィックを再現します。
- プロトコルの深さ：シンプルなL2/L3スループットのテストから、HTTPSやDNSといった複雑なL7アプリケーションフローのシミュレーションまで対応します。
私のチームはこれらの指標を使って、ファイアウォールのシリコンが処理しきれなくなる正確な限界点を特定しています。標準的なツールでは到底得られないデータです。
ハードウェアの選定と準備
最も多い落とし穴はハードウェアの互換性です。TRexはDPDKに依存するため、NICがサポートされている必要があります。Intel X520、X710、Mellanox ConnectX-5は業界標準として広く使われています。このガイドでは、Intel X722デュアルポート10G NICを搭載したUbuntu 22.04 LTSサーバーを使用します。
まず基本的な依存パッケージをインストールし、PCIバスアドレスを確認します：
sudo apt update
sudo apt install -y python3 python3-distutils zlib1g-dev pciutils
# NICのPCIアドレスを確認する
lspci | grep Ethernet0000:03:00.0のようなアドレスを探してください。後で設定ファイルにポートをマッピングする際に必要になります。
インストールとセットアップ
TRexは一般的なmake installのような手順を使いません。バイナリパッケージをダウンロードして展開し、直接実行します。このポータブルなアプローチは、ラボの異なるテスト環境間でツールを移動させるのに便利です。
mkdir -p /opt/trex
cd /opt/trex
wget https://trex-tgn.cisco.com/trex/release/latest
tar -xzvf latest
cd v3.0* # 現在のバージョンディレクトリに移動する環境を定義するために/etc/trex_cfg.yamlファイルを作成する必要があります。このファイルはNICの物理ポートをTRexソフトウェアにマッピングします。デュアルポート構成の基本的な設定例は以下の通りです：
- version: 2
interfaces: ["03:00.0", "03:00.1"]
port_info:
- dest_mac: "00:11:22:33:44:55" # ルーターのポート1のMACアドレス
src_mac: "00:55:44:33:22:11" # TRexのポート1のMACアドレス
- dest_mac: "00:11:22:33:44:66" # ルーターのポート2のMACアドレス
src_mac: "00:55:44:33:22:22" # TRexのポート2のMACアドレス初めてのストレステストを実行する
TRexはサーバー・クライアントモデルを採用しています。まずエンジンを起動し、次にコンソールでトラフィックを注入します。
ステップ1：エンジンを起動する
sudo ./t-rex-64 -i-iフラグは対話モードを有効にします。ポートの初期化が完了すると、サーバーは指示を待機します。
ステップ2：コンソールに接続する
2つ目のターミナルを開いてコントローラーを起動します：
./trex-consoleステップ3：10Gリンクを飽和させる
プロファイルを読み込みましょう。標準的なIMIXプロファイルを使用して、ポート0に10Gbpsのトラフィックを流します：
start -f stl/imix.py -p 0 -m 10gbpstuiと入力してテキストユーザーインターフェースを開きます。opackets（出力）とipackets（入力）の値を注意深く確認してください。出力が10Gbpsなのに入力が8Gbpsしかない場合、テスト対象デバイスがトラフィックの20%をドロップしていることがわかります。
スループットとレイテンシの同時分析
レイテンシが許容できないほど跳ね上がれば、高スループットも意味がありません。多くのルーターはパケットをドロップし始めるずっと前からジッターが発生します。TRexは高速トラフィックと専用のレイテンシプローブを組み合わせることでこれを計測できます。
これをテストするには、レイテンシ追跡を有効にして90%負荷でベンチマークを実行します：
start -f stl/bench.py -p 0 -m 90% --latency先日、コアスイッチのトラブルシューティングでこの手法を使いました。9Gbpsは難なくさばけていましたが、その負荷でレイテンシが15μsから450μsまで跳ね上がりました。単純なスループットテストでは見落とすところだったバッファブロート問題が明らかになったのです。
ラボで得た教訓
この1年で学んだことは、環境はソフトウェアと同じくらい重要だということです。守るべき3つのルールを紹介します：
- バックツーバックルール：まず必ずTRexのポートを互いに直接接続してテストします。ループバックで10Gbpsが出ない場合、問題はルーターではなくサーバーかPCI設定にあります。
- NUMAを尊重する：マルチソケットサーバーでは、NICとTRexプロセスを同じCPUソケットに配置してください。QPI/UPIバスをまたぐと性能が30%低下することがあります。
- CPSに注目する：ステートフルファイアウォールのテストでは、毎秒接続数（CPS）に注目してください。総帯域が低くても、毎秒5万の新規セッション確立を処理しようとしてクラッシュするファイアウォールは少なくありません。
まとめ
基本的なツールからTRexに移行したことで、ネットワーク容量の計画方法が大きく変わりました。ファイアウォールがピーク負荷を処理できるかどうかを推測する必要はなくなり、実際のデータで証明できます。DPDKのセットアップには多少の学習コストがかかりますが、結果はプロ品質です。専用ハードウェアなら数百万円かかるところを、標準的なLinuxサーバーを高性能トラフィックジェネレーターに変えることができるのです。
