web-dev-qa-db-ja.com

TCPパケット損失なしでダンプする

ネットワークを実際に通過するすべてのパケットがキャプチャされ、何も失われないことが保証されているTCPダンプを作成するにはどうすればよいですか？

詳細：SCTPスタックの上にソリューションを提供するサードパーティベンダーに問題があり、彼もそれを実装しています。
非常に高いスループット（52 000メッセージ/秒、平均メッセージサイズは500バイト）では、SCTPリンクが切断されます。
バグはベンダーのSCTPスタックにあると考えています。
しかし、ベンダーによると、これは、SCTPスタックがメッセージを送信し、ACKを受信せず、多数の再送信を送信し、それらでもACKを受信せず、SCTPリンクを閉じるために発生します。
ベンダーによると、これはパケットを失うために有罪となるネットワークです。

クライアントとサーバーの両側のTCPダンプでは、元のメッセージがサーバーに到達し、サーバーがACKで応答しないことがわかります。しかし、ベンダーはTCPダンプは信頼できません。TCPダンプをキャプチャすると、libpcapライブラリは1つのハードウェアスレッド内でのみ機能するため、一部のパケットをキャプチャできませんでした。その能力が十分でない可能性があります。すべてのパケットをログに記録します。

技術データ：52000メッセージ/秒、平均メッセージサイズは500バイトであるため、合計26 MB /秒、4つのSCTPリンクが使用されます。
ハードウェア：CPU E5-2670、2.6 GHz、8HWスレッド
ネットワーク：10 GBit、トラフィックは1つのラックにあるHPブレード間です。
RHEL6。

linuxnetworkingtcpdumpsctp
4
Neighbour

あなたのトラフィック量では、特に非効率的な設定がない限り、libpcapはドロップされたパケットに問題がないはずだと私は主張します。キャプチャにtcpdumpを使用している場合は、ドロップされたパケットの量が最終出力行に報告されます。ドロップされたパケットが表示された場合は、 -B option デフォルトの2MBよりかなり高い値を設定します。

それでも、 PF_RING ：を確認することをお勧めします。

PF_RING™が必要なのは誰ですか？

基本的に、1秒あたり多くのパケットを処理する必要があるすべての人。 「多く」という用語は、トラフィック分析に使用するハードウェアによって異なります。 1,2GHzで80kpkt/sec ARMからローエンドの2,5GHzXeonで14Mpkt/sec以上）の範囲になります。PF_RING™を使用すると、パケットをより高速にキャプチャできるだけでなく、 、CPUサイクルを維持しながら、パケットをより効率的にキャプチャします。いくつかの数値を示すために、NetFlow v5/v9プローブであるnProbeがPF_RING™を使用して実行できる速度を確認するか、以下の表を参照してください。

Core2Duo 1.86GHzおよびローエンドのXeon2,5Ghzで実行された10ギガビットテスト

                                    ixgbe 
            Application                                 Rate 
pfcount (RX, with PF_RING™ DNA)        11 Mpps (Core2Duo), 14.8 Mpps (Xeon) 
pfsend (TX, with PF_RING™ DNA)         11 Mpps (Core2Duo), 14.8 Mpps (Xeon)

PF_RINGユーザーガイド は、パケットキャプチャにlibpcapアプリケーションを使用することを主張する場合に、PF_RING対応のlibpcapライブラリをコンパイルおよび構成する方法を説明しています。

8
the-wabbit