mplsおよびtcpでopenvswitchを使用する
私はSDNで研究開発を行っています。この場合のシナリオでは、MPLSラベリングを使用し、ソフトウェアスイッチとしてOpenvSwitchを使用します。カーネルモジュールがロードされたovs2.6.0の2つのサーバーノードと2つのホストを使用しています。
これらは1ギガビットイーサネット接続を介して直接接続されており、約1ミリ秒のrttがあり、最初のパケットの場合は3ミリ秒未満です（pingユーティリティを使用）。テストを行うためにIperf3を使用しています。最初のテストはmplsラベリングを使用せずに達成されたパフォーマンスであり、2番目のテストはmplsラベリングを使用しています。 MTUはフラグメンテーションを行わないように調整されているため、これは問題ではありません。輻輳ウィンドウと、使用するTCPアルゴリズムなどの他のパラメータを調整してみました。
mar jul 4 12:21:09 CEST 2017
Connecting to Host 192.168.20.2, port 5201
[ 4] local 192.168.20.1 port 43526 connected to 192.168.20.2 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 112 MBytes 943 Mbits/sec 0 450 KBytes
[ 4] 1.00-2.00 sec 112 MBytes 937 Mbits/sec 0 516 KBytes
[ 4] 2.00-3.00 sec 112 MBytes 938 Mbits/sec 0 571 KBytes
[ 4] 3.00-4.00 sec 112 MBytes 937 Mbits/sec 0 625 KBytes
[ 4] 4.00-5.00 sec 112 MBytes 943 Mbits/sec 0 633 KBytes
[ 4] 5.00-6.00 sec 111 MBytes 933 Mbits/sec 0 633 KBytes
[ 4] 6.00-7.00 sec 111 MBytes 933 Mbits/sec 0 664 KBytes
[ 4] 7.00-8.00 sec 112 MBytes 944 Mbits/sec 0 664 KBytes
[ 4] 8.00-9.00 sec 111 MBytes 933 Mbits/sec 0 697 KBytes
[ 4] 9.00-9.16 sec 18.8 MBytes 977 Mbits/sec 0 697 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-9.16 sec 1.00 GBytes 939 Mbits/sec 0 sender
[ 4] 0.00-9.16 sec 1022 MBytes 935 Mbits/sec receiver
iperf Done.
<----------->
mar jul 4 12:40:10 CEST 2017
Connecting to Host 192.168.20.2, port 5201
[ 4] local 192.168.20.1 port 43530 connected to 192.168.20.2 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 203 KBytes 1.66 Mbits/sec 57 2.82 KBytes
[ 4] 1.00-2.00 sec 398 KBytes 3.26 Mbits/sec 124 2.82 KBytes
[ 4] 2.00-3.00 sec 400 KBytes 3.28 Mbits/sec 124 2.82 KBytes
[ 4] 3.00-4.00 sec 319 KBytes 2.61 Mbits/sec 124 2.82 KBytes
[ 4] 4.00-5.00 sec 398 KBytes 3.26 Mbits/sec 126 2.82 KBytes
[ 4] 5.00-6.00 sec 395 KBytes 3.24 Mbits/sec 124 2.82 KBytes
[ 4] 6.00-7.00 sec 398 KBytes 3.26 Mbits/sec 126 2.82 KBytes
[ 4] 7.00-8.00 sec 324 KBytes 2.66 Mbits/sec 124 2.82 KBytes
[ 4] 8.00-9.00 sec 398 KBytes 3.26 Mbits/sec 124 2.82 KBytes
[ 4] 9.00-10.00 sec 400 KBytes 3.28 Mbits/sec 126 2.82 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 3.55 MBytes 2.98 Mbits/sec 1179 sender
[ 4] 0.00-10.00 sec 3.42 MBytes 2.87 Mbits/sec receiver
MPLSとovsの使用に問題があることは知っていますが、この場合は奇妙な事実がいくつかあります。
- TCPの代わりにUDPを使用する場合、1つのパケットが故障していますが、残りは正常であるため、パケットはカーネルデータパスを使用していると思います。
- TCP送信の開始時に失われたパケットが9つあり、定期的に失われたパケットがさらにあります。tcpdumpトレースを見ると、これらのパケットは最初のノードで「欠落」しています。それらがキャプチャされないことをホップします。
- 上記のように、TCP MPLSラベリングなし）を使用した場合のパフォーマンスは非常に良好です。
この問題に取り組む方法を知っている人はいますか？
PD：英語のタイプミスの可能性について失礼します。
いくつかの調査を行った後、私は問題を切り分けて解決することができました。 NICは、いくつかのチェックサムとオフロードオプションがアクティブになっていて、パケットをユーザースペースに移動させました。ここでは、カプセル化が問題だったと思います。
ethtoolユーティリティを使用して、このオフロードを無効にできます。この場合、私は（rootとして）使用しました：
ethtool -K <iface> gso off && ethtool -K <iface> tso off && ethtool -K <iface> gro off
TCPセグメンテーションオフロード（TSO）、汎用セグメンテーションオフロード（GSO）、および汎用受信オフロード（GRO）を無効にするには）。また、rxおよびtxチェックサムも無効になります。
時が来たら、これが誰かに役立つことを願っています。