単純なスイッチのパケット バッファー内で何が起こるかをシミュレートするにはどうすればよいでしょうか?

単純なスイッチのパケット バッファー内で何が起こるかをシミュレートするにはどうすればよいでしょうか?

私は、ストア アンド フォワード ギガビット スイッチで 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トピック外としてマークされていた箇所)。

関連情報