実験室試験で損失が発生しただけでは、スイッチが不適格であることの証明にはならず、スコアを改善するためだけに機能を無効化する根拠にもなりません。まず試験器、リンク、フレーム形式、トラフィックモデルを検証し、その後で送信と受信を比較します。本記事では、試験条件の問題と転送能力の限界を区別します。本番環境の輻輳診断とは分けて利用してください。
1. 目的と安全な実施範囲を定義する
スループット、フレーム損失率、遅延、バースト耐性は、それぞれ異なる問いに答える指標です。実験室での最大性能は、本番アプリケーションの使用感と同じではありません。RFC 2544は、ネットワーク相互接続機器のベンチマーク方法を定義しています。高負荷試験は分離された環境で実施し、制御、監視、電話サービスを運用中のネットワークに飽和トラフィックを流さないでください。
使用が許可された機器、ポート、ファームウェア、構成を確認します。配線、有効な機能、速度、デュプレックスモードを記録します。復旧計画を用意し、試験装置が予定したトラフィックを生成・受信できることを検証します。一般的なコンピューター上のソフトウェア生成器は、NIC、ドライバー、プロセッサー、OSのスケジューリングに依存します。コンピューターがラインレートに達しないという事実だけでは、スイッチの転送能力不足を証明できません。
2. 送信フレームと受信フレームを同じ基準で数える
まず低負荷で転送が成立することを確認します。送信元・宛先アドレス、VLANタグ、フレーム長、ペイロード、シーケンス番号を確認します。無関係な管理フレームやバックグラウンドフレームを試験トラフィックとして数えないでください。試験器のビットレートが、回線占有レート、Ethernetフレームのビットレート、アプリケーションペイロードのレートのいずれを意味するかを明記します。これを明確にしなければ、同じ数値でも異なる印加負荷を表す可能性があります。
フレーム損失率は、同じ有効な試験集合内で、送信フレーム数から受信フレーム数を引き、その値を送信フレーム数で割って算出できます。重複、順序の入れ替わり、不正形式のフレームは別々に記録します。受信総数の中で重複が損失を相殺しないようにする必要があります。試験方法と測定器に応じて、送信停止後も伝送中のフレームを受信するための適切な時間を確保し、受信を早く停止したために見かけの損失が発生しないようにします。
3. FCSエラーを、原因と決めつけずリンク状態の証拠として調べる
FCSエラーは、受信フレームが所定の完全性チェックに合格しなかったことを意味します。生成器が意図的に無効なフレームを送信していないか、インターフェースが適合しているか、ケーブルとモジュールが正常かを確認します。適合するケーブル、モジュール、ポートのいずれかを1つ交換した後にエラーが消えれば、有用な証拠になります。ただし、それを根拠に、すべてのFCSエラーが光ファイバーの損傷を証明すると主張したり、出力キューでの廃棄を同じ事象として扱ったりすることはできません。
光リンクでは、速度、波長、光ファイバー、送受信の組み合わせを確認します。ポートをのぞき込まず、適切な方法で端面を点検・清掃します。正常と確認済みの交換部品であっても、仕様に適合している必要があります。適切な場合は、スイッチを追加する前に試験器の両端を直接接続してベースラインを取得します。これにより試験システムを確認できますが、複雑なアプリケーションのあらゆる条件を網羅することはできません。
4. 小さいフレームと大きいフレームでは負荷がかかる側面が異なる
同じビットレートでは、一般にフレームが小さいほど、毎秒のフレーム数と処理回数が増えます。プリアンブルとフレーム間隔も回線時間を占有します。帯域幅をペイロードだけで割って最大パケットレートを求めないでください。長さにFCS、VLANタグ、回線上のオーバーヘッドを含むかどうかを明記し、IPパケット長とEthernetフレーム長を混同しないでください。
大きいフレームでの不具合には、最大対応フレームサイズ、パスMTU、カプセル化タグ、試験形式、バッファーが関係する可能性があります。小さいフレームでの不具合には、毎秒の転送処理回数、試験器の能力、チップのリソースが関係する可能性があります。ある1つのフレーム長で損失が発生しただけでは、バッファー不足やディスクリプターの枯渇を証明できません。カウンター値を保存し、文書と再現可能な条件を用いて可能性を絞り込みます。
5. アドレス学習とアグリゲーションの分散を確認する
多数の送信元MACアドレスを試験する前に、学習、アドレス規模、エージングの条件を定義します。宛先が未知の場合はフラッディングが発生し、意図したユニキャストモデルとは異なるトラフィック分布になる可能性があります。MACアドレス容量と検索の仕組みは、チップやモデルによって異なります。すべての学習失敗をハッシュ衝突と決めつけないでください。テーブルエントリー、関連カウンター、実際の出力先を調べ、再現可能な証拠を得ます。
アグリゲーションのメンバー間で、すべてのフローが均等に分散されるとは限りません。特定のフロー特性によってトラフィックが1つのメンバーに集中し、アグリゲーション全体には未使用容量があっても局所的な輻輳が生じる場合があります。フロー数と、送信元・宛先アドレス、プロトコル、ポートの組み合わせを明記します。トラフィックモデルを比較する前に、メンバーごとの負荷を確認します。試験に合格するためにハッシュ設定を変更した場合、その構成変更を報告せずに済ませてはいけません。
6. 比較可能な試験を設計する
ベースラインを固定したら、フレーム長、印加負荷、アドレス数、ポートの組み合わせのうち、条件を1つずつ変更します。試験を繰り返し、結果を記録します。従来のEthernetベンチマークでは、一般に64、128、256、512、1024、1280、1518バイトのフレームを対象とします。タグ付きフレームやジャンボフレームについては、長さの定義、対応状況、目的を別途明記します。この従来の一覧は、すべての機器に対する必須の対応能力を保証するものではありません。
スループットとフレーム損失をそれぞれの方法に従って測定し、継続時間、負荷の増分、反復回数、実際に適用した構成を報告します。フレーム長ごとにバッファーを内密に再調整したり、1組のポート間の結果を、全ポートが同時にラインレートで転送した結果として説明したりしないでください。複数ポート、チップ間、スタックの経路では結果が異なる場合があります。測定した経路と測定していない経路を明確に示します。
7. 第三者が独立して再現できる報告書を作成する
完全な報告書には、モデル、ファームウェア、試験器のバージョン、配線、有効な機能、フレーム形式、トラフィックモデル、元の送受信カウント値を記載します。リンクエラー、廃棄、遅延、アプリケーション条件を区別します。問題をエスカレーションする前に、異常を再現し、ログを保存します。ベンダーがリソースやソフトウェアの問題を特定するには、背景情報のないフレーム損失のスクリーンショットではなく、これらの条件が必要です。
FCTELのポート速度、管理、アグリゲーションなどの機能は、実際のモデルとファームウェアに照らして確認します。本記事は、すべてのモデルがベンチマークに合格した、あるいはチップのバッファーを調整できると主張するものではありません。調達時の受入判定では、実際のアプリケーション、電源、産業現場の条件も考慮する必要があります。実験室での適格性確認と本番環境での安定稼働は関連していますが、互いに代替できません。導入時には、引き続き管理された条件下でのアプリケーション検証が必要です。
図は、確認済みの一般的な仕組みを示しています。機器や測定器の画面は、製品写真や実測結果ではなく、性能を保証するものでもありません。
中国語の技術記事から翻訳。原文初公開：2020-11-26。原文最終改訂：2026-10-13T14:51:17+08:00。 中国語の原文を読む
