イーサネットをテストする必要があります！
チャネル帯域幅と提供された通信の品質のテストを実施するための正確な定義とレシピはありますか？ 私はロシアのネットワークが他の目的のために設計された方法を使用してテストされていることを明らかにしたいくつかの記事を見つけましたが、これは驚くことではありません。私たちの国の大都市での通信サービスは非常に発達しており、文字通りすべてのアパートに高速チャネルがあり、また、一部の通信事業者は既に家庭の顧客にギガビットチャネルを提供していますが、提供されるテレマティックサービスの品質のテスト方法について誰もが知っているわけではありません。
正確に何をテストする必要があるのですか？
今日、ポークのブタがどれくらいの頻度で購入されるかを考えてみましょう。
- リースまたはリースされた通信チャネル。
- あなたまたはあなたのために構築された通信チャネルの受け入れ;
- 特に契約にペナルティがある場合、通信サービスを提供します。
- あなたが購入したいが、彼らはあなたにそれを販売したい、そして彼らはそれが超クールで安価だと言う。
これは、顧客と通信事業者が今日危険にさらしているもののほんの一握りの例です。
「インターネット」をテストするためのソフトウェアユーティリティ
チャンネルの完全なテストはエコー要求にはなり得ません。pingとmtrはチャンネル容量が何であるかを決して知らせません。 Iperfおよびその他のソフトウェアユーティリティは、これを知ることができません。ネットワークを使用してソフトウェアユーティリティをテストしている間、現在チャネルにあるユーザーデータの量とソフトウェアテストを知らない間、パケットヘッダーの存在により、多くの不正確さが生じる可能性があるためですヘッダーはフレームサイズの標準の長さのままであり、データを含む本文は増減します。ソフトウェアユーティリティは、ヘッダーのサイズを考慮せずにチャネルの帯域幅を決定します。 パケットのサイズは、そのようなテストに特定の混乱をもたらします。
チャネルのロードスケジュールを確認したり、インターネットからバルクファイルをダウンロードしたりしても、リースされたVLANの品質を評価することはできません。 なぜspeedtest.netは提供されたチャンネルの速度を証明しないのでしょうか、おそらく指定する価値がないのでしょうか？ 結局のところ、すぐに明らかになります-どのチャネルとどのネットワークを介してスピードテストサーバーに行くかは不明であり、テスト中にチャネルがどれだけロードされているか、および他の多くのテストパラメータも不明です。 speedtestの結果は、実際の数値ではなく、特定の指標からのデルタです。
提供される通信サービスの品質は多くのパラメーターの組み合わせであり、適切なツールを使用すると、提供されるサービスに関する正確なデータを迅速かつ効率的に取得できます。 正確なデータを取得するだけでなく、そのデータを使用して、たとえば法廷で彼らのケースを証明できるという自信を持つことも重要です。
イーサネット技術とアナライザー
現在、帯域幅をテストするための2つの主要な方法があります。古いもの-RFC -2544と少し新しい ： Y.1564です。 ITU-T Y.1564方法論は、今日より関連性が高く、SLA（サービス層契約）に関する最新の概念を備えた最新の高速通信チャネルをテストするための説明があります。
イーサネットチャネルの品質は多くの要素の組み合わせであるため、適切なテストではこれらの組み合わせすべてを可能な限りカバーする必要があります。 テスト時には、多くの側面を考慮する必要があり、 BERテスト 、パケットジッタ、MPLSのサポート、QoS、アプリケーションレベルのプロトコル（http、ftpなど）の負荷テストなどの高度な機能があると便利です。
1Gから10G以上のチャネルをテストする場合、非専門の鉄を使用して負荷テストを行うことは非常に困難です。専門のテスターアナライザーとは異なり、プロセッサは多くの場合、十分なトラフィックを生成できません。 このようなデバイスは、ラック、キャビネット、屋根裏部屋の引き出しに入れてリモートでテストを実行したり、異なる時間間隔で自動測定を実行したりできます。 ポータブルアナライザーデバイスは、強度に関する厳しいテストに合格するため、下水道の厳しい条件で劣化することはありません。
通信チャネルの配信と受け入れ。
現場テストに特化した企業はインターネット上で見つけることができますが、建設されたラインと高速道路を引き渡しまたは受け入れるために、通常の兵器庫にテスター分析器を置くことが最善です。 何らかの理由で、テスターアナライザーの購入は非常に高価であると考えられています。
RFC-2544のテスト方法とその仕組みの詳細をご覧ください。
RFC-2544方法論では、さまざまなフレームサイズの測定を推奨しています。イーサネットトラフィックの場合、フレームのサイズは64、128、256、512、1024、1280、1518オクテットであり、フレームサイズごとに個別のシリアルテストが必要です。 必要に応じて、ジャンボフレーム（フレームサイズ4096または9000オクテット）をテストすることもできます。 さまざまなタイプのトラフィックをシミュレートするには、さまざまなフレームサイズが必要です。
当初、この手法は、たとえばスイッチの開発時など、ネットワークデバイスをテストするために直接開発されましたが、チャネルの品質を測定するために一連の機能が採用されました。 この技術は1999年にISOCによって承認されました。
この方法論では、6つのテストのセットを提供します。認識を明確にするために、テストの実行方法について詳しく説明します。
テスト対象デバイスのスループットの決定（スループット）
テストの説明：テスターによって特別に形成された少量のパケットが特定の速度でデバイスの入力ポートに送信され、出力ポートで数がカウントされます。受信したよりも多く送信された場合、速度が低下し、テストが再び開始されます。
フレーム遅延時間の決定（レイテンシー）
テストの説明：スループット（スループット）を決定した後、フレームサイズごとに、対応する最大速度で、パケットストリームが特定のアドレスに送信されます。 ストリームの最小期間は120秒である必要があります。 60秒後、ラベルが1パケットに挿入されます。 ラベルの形式は、機器の製造元によって決定されます。 送信側では、ラベル付きのパケットが完全に送信された時間が記録されます。 受信側では、マークが決定され、マーク付きパケットの完全な受信時間が記録されます。 遅延とは、送信時間と受信時間の差です。 方法論によれば、このテストは少なくとも20回繰り返す必要があります。 20回の測定結果に基づいて、平均遅延が計算されます。 テストは、テストストリーム全体を1つのアドレスに送信し、各フレームを新しいアドレスに送信して実行する必要があります。
フレーム損失率の決定
テストの説明：特定の数のフレームが特定の速度でデバイスの入力ポートに送信され、デバイスの出力ポートから受信したパケットの数がカウントされます。 フレーム損失率は次のように計算されます。
（（送信フレーム数-受信フレーム数）* 100）/送信フレーム数
最初の送信は可能な最大速度で行われ、その後、送信速度は10％の最大ステップで減少します。この方法では、％ステップを減少すると最も正確な結果が得られます。 速度の低下は、最後の2つの送信にエラーがなくなるまで、つまり、フレーム損失率が0になる最大データ転送速度を見つけるまで続ける必要があります。
バックツーバックフレームを処理する機能のテスト
テストの説明：テストは、テスト中のデバイスの入力ポートに最小のフレーム間遅延で一定数のフレームを送信し、デバイスの出力ポートからフレームをカウントすることまで続きます。 送信されたフレームと受信されたフレームの数が等しい場合、送信されたフレームのボリュームが増加し、テストが繰り返されます。受信されたパケットが送信されたフレームより小さい場合、送信されたフレームの量は減少し、テストが繰り返されます。 その結果、パケットサイズごとに損失なしで送受信されるパケットの最大数を取得する必要があります。これは、連続テストの値になります。 この手法によれば、フレームをデバイスポートに送信する時間は2秒以上で、最小数は少なくとも50回でなければなりません。 最後の図は、50回のテストの平均結果です。
過負荷後の回復（システム回復）、デバイスのテストにのみ適用可能
テストの説明：フレームストリームは、測定されたスループットテストに対して110％の割合で少なくとも60秒間デバイス入力に送信されます。 スループットテストが完全な結果を示した場合、この接続の最大速度が選択されます。 輻輳時には、流量が半分に減少し、流量が減少した時間と最後のフレームが失われた時間の差が検出されます。
再起動後のテスト済みデバイスの回復時間（リセット）、テストデバイスのみに適用
テストの説明：フレームの連続ストリームは、最小フレームサイズのスループットテストの結果として決定された速度でデバイスの入力に送信されます。 デバイスがリセットされます。 リセット後の回復時間は、リセット前に最後のパケットを受信した時間と、リセット後に最初のパケットを受信した時間との差です。 ハードウェアとソフトウェアの両方のリセットタイプがテストされます。
最新のY.1564テクニックで何が変わったのですか？
2011年のITUにより、新しい推奨事項が検討および承認されました。 すでに述べた推奨事項に、RFC 2544はパケットジッター（ジッタ）、つまり同じストリームに関連する一連の連続データパケットを受信するときの時間差を計算する機能を追加します。理想的な世界では存在しないはずですが、問題のあるネットワークでは、シーケンスはデータ処理の速度に影響を与える可能性があります。 RFC2544では、パケット損失がない最大チャネル速度でのみチェックを行うことができます。これは通常、 CIR（Committed Information Rate）レートよりも高くなります。 Y.1564はSLA専用に作成され、主要業績評価指標（KPI）に従って提供されたチャネルの速度と品質を評価し、契約に従って提供されたチャネルを確認できます。
Y.1564を使用すると、保証された帯域幅、最大許容帯域幅を確認したり、帯域を超える負荷を与えたりして、たとえばシェーパー設定を確認できます。
メソッドにはいくつかの違いがあります。RFC2544は、サービス設定の正確性を検証しません（指定されたものとのKPI準拠、およびネットワークの輻輳を回避するために速度制限がEIR（超過情報レート-最大保証帯域幅）よりも高い）。 RFC2544の元のバージョンでは、ジッタは測定されません。 RFC2544によれば、各テストは個別のフローで起動され、提供されるサービスの品質を総合的に測定することはできず、テスト時間は増加します。RFC2544のもう1つのマイナスは、ネットワークがQoSを使用する場合など、Y.1564は欠点とわずかに拡張された機能を考慮に入れています。
新しいチャネルのみをテストすることも、すでに動作しているチャネルもテストすることはできますか？
新しいチャネル、さらに古いチャネルをテストする必要があります。 顧客をサポートコールに誘導することなく、新たな問題について事前に学ぶことができます。 最新のテスターとアナライザーを使用すると、稼働中のネットワークでチェックを実行し、10/100 / 1000Mbitと10/40 / 100Gの両方の速度でチャネルをチェックできます。 1つありますが、何をどのように行っているかを理解することは非常に重要です。誤ってチャネルをテスト対象にしないことが重要です。
テストモード-イン/アウトオブサービス。
今日、ネットワークテストはチャネルを体系化して絶えず監視しようとしています.RFC2544方法論の以前のバージョンは、OutOfServiceモードでチャネル/機器をテストするために作成され、主に機器テストに使用されていましたが、今日ではテストデバイスのすべてのメーカーが新しいものに切り替えていますInServiceモードでネットワークを継続的に監視できるテスト標準。 このようなテストにより、クライアントを切断せずに帯域幅速度を確認できます。これは、通信サービスプロバイダーにとって重要です。
エピローグ
私の友人の一人が言うように、同志は「同僚」と一緒に戦い、私たちが構築しているものと悪用しているものをテストし始めましょう。
使用された文献：
RFC 2544方法論：https：//www.ietf.org/rfc/rfc2544.txt
メソッドY.1564： www.itu.int/rec/T-REC-Y.1564-201103-I/en
メソッドの違いに関するAndréの記事： www.mrv.com/blog/why-rcf2544-not-sufficient-anymore
*会社の意見は著者の意見と一致しない場合があります;-)