
私は、ストア アンド フォワード ギガビット スイッチで UDP パケットが失われたケースをデバッグしており、問題の要点をよりよく理解するために、スイッチ内部で何が起こっているかを視覚化したいと考えていました。
シナリオは単純です。2 つのバースト データ ストリームがスイッチ内の 2 つのポートを通過し、両方とも 3 番目のポート (両方に共通) から出力されます。そのため、スイッチはパケット バッファにデータをしばらく保持する必要があります。
問題は、私の単純な計算に基づくと、バッファは私が調査しているケースを処理するのに十分な大きさである必要があるということです。1 つのデータ ストリームは 1.56 ミリ秒ごとに 25 kB (1514 B パケットに分割) のバーストを送信し、もう 1 つは 1 ミリ秒ごとに 60 kB のバーストを送信します。現在、Netgear GS105E などの SOHO スイッチでも、バッファ サイズは 128 kB です。したがって、単純な計算 (25+60 < 128) により、ストリームが同時に入力されても (他の大量のトラフィックがない場合) 機能するはずです。
実際のテストでは、両方のストリームからの多くのパケットが一部のスイッチで失われることがわかりました (バッファ サイズに関係しているようですが、それだけではありません)。私のシミュレーションでは、128 kB に設定してもバッファがオーバーフィルすることはありません。
このアニメーションは、オーバーフィルが発生している 24 kB サイズのバッファで記録されました。ただし、バッファを数バイト増やすだけで問題が解決し、すべてのパケットが通過することが簡単にわかります。
このシミュレーションでは、いくつかの簡略化を行いました。すべてのパケットの QoS は同じです (実際のケースでも同じです)。そのため、シミュレーションから QoS キューを除外し、すべてのトラフィックを同等に重要なものとして扱っています。次に、バッファのメモリ管理を除外しました。これが問題の重要な部分であることは想像できますが、完全な割り当てによる私の簡略化が実際のケースから 10% 以上間違っているとしたら驚きです。また、スイッチが最初のバイトを受信するときにフレームの長さを認識し、最初に必要なメモリをすべて予約すると仮定します。ポートの入力/出力キューのサイズに関するドキュメントが見つからなかったため、それらはすべて共有パケット バッファに配置され、必要に応じてバッファの大部分を占有できると想定しています (ただし、原因はどこかにあると思います)。各パケットの処理遅延を 512 ns (64 B パケットの伝搬遅延) に設定しました。
それが役割を果たしているかどうかはわかりませんが、ストリームは断片化された UDP パケットで構成されています (つまり、25 kB バーストは 17 個の IP フラグメントに断片化された単一の UDP パケットです)。2 番目のストリームは、それぞれ 14 個の IP フラグメントに断片化された 2 つまたは 3 つの 20 kB UDP パケットとしてバーストを作成します。
実際のストリームと同様のストリームを複製するための Iperf 3.7 コマンドは次のとおりです。
iperf3 -c sink -u -b 128M -t 600 -l 25256 --pacing-timer 1560
iperf3 -c sink -u -b 400M -t 600 -l 20k --pacing-timer 1000
シミュレーションが現実からかけ離れてしまう原因として、他に何を考慮に入れ忘れたのか、何か考えはありますか? ご協力ありがとうございます!
アニメーションのソースコードはhttps://gist.github.com/peci1/a0346538acc6c289b2c6d596b184ad21。
実際の実験から得た結果表を以下に示します。データ ストリーム 1 は固定で、1.56 ミリ秒ごとに 25 kB の UDP パケットで 128 Mbps です。2 番目のストリームのパラメータを変更して、最初のストリームのパケットがスイッチによって失われ始める限界を見つけようとしました。UDP-l
パケットのサイズを指定する (長さ) パラメータと、-b
これらのパケットが生成する帯域幅を指定する (帯域幅) パラメータを変更しました--pacing-timer
。2 番目のストリームでは常に 1000 に設定されていました。D-Link と Netgear GS105 は 60 kB のバーストにまったく対応できないことがわかります。GS108 は、ほぼ同じスイッチ チップ (同じ「ファミリー」で、ポート数が異なり、バッファが少し大きいだけ) を搭載しているにもかかわらず、GS105 よりもはるかに優れています。
スイッチ | バッファサイズ [kB] | 最大トラフィック 1.5kB バースト | 最大トラフィック 20kB バースト | 最大トラフィック 60kB バースト |
---|---|---|---|---|
ギガブロックス ラギッド (VSC7512) | 220 | 825 Mbps | 825 Mbps | 825 Mbps |
ギガブロックス (RTL8367N-VB-CG) | 250 | 730 Mbps | 750 Mbps | 790 Mbps |
D-Link DIS-100G-5W (QCA8337N-AL3C) | 128 | 110 Mbps | 1Mbps | すべてのバーストでパケットが失われる |
ザイクセル XGS 1210-12 (RTL9302B) | 1500 | 800 Mbps | 830 Mbps | 830 Mbps |
ネットギア GS310-TP (RTL8380M) | 520 | 830 Mbps | 830 Mbps | 835 Mbps |
ネットギア GS308T (RTL8380M) | 520 | 830 Mbps | 835 Mbps | 835 Mbps |
ネットギア GS108 v3 (BCM53118) | 192 | 630 Mbps | 660 Mbps | 710 Mbps |
ネットギア GS105E (BCM53114) | 128 | 120 Mbps | 1Mbps | すべてのバーストでパケットが失われる |
レンクフォース RF-4270245 | ? | 740 Mbps | 760 Mbps | 800 Mbps |
ミクロティック RB260GS (AR8327) | 128 | 835 Mbps | 835 Mbps | 835 Mbps |
ジュニパー EX2300 | 4ギガバイト? | 800 Mbps | 830 Mbps | 830 Mbps |
(この質問はhttps://networkengineering.stackexchange.com/questions/78529/how-to-simulate-what-happens-inside-the-packet-buffer-of-a-simple-switchトピック外としてマークされていた箇所)。