全二重通信と半二重通信の混在環境における問題

進捗報告
九州大学システム情報科学府
情報知能工学専攻
林健太朗
実験の目的

前回のPPTP実験における低いスループットの結果
は、遅いCPUに原因があったのか確認する

前回使用したPC
 クライアント・サーバどちらもIntel

Pentium Ⅲ
今回使用するPC
 サーバ：Intel
Xeon X5272 3.4GHz コア4
 クライアント：Intel Xeon E5450 3.0GHz コア4
2
実験構成


PPTPなしの状態でスループット測定
PPTPセッション上のスループット測定
PPTPサーバ
PPTPクライアント
G ethernet
PPTP
jikoku.qgpop.net
172.16.34.2/22
172.16.32.3/22
3
結果

PPTPなし
 サバ→クラ
９４３Mbps
 クラ→サバ９４２Mbps

PPTPセッション上
 サバ→クラ
２６３Mbps
 クラ→サバ３７５Mbps
(前回測定)PPTPなし９４Mbps
PPTP上
３０Mbps前後
4
考察


前回測定と同じように、PPTPセッション上のスループ
ットはPPTPなしの時に比べ、3割前後しかでなかった
スループット低下の原因はCPUの速さではない！
 どの階層かは特定できないが送受信処理のアルゴリズム
に原因がありそう
 (ちなみに)PPTPセッション上では、上りの方が最大帯域の
1割ほどスループットが高い模様
5
そもそもの問題



dstIPが別セグメントなので、送信パケットのdstMACアドレス
はGW
そのパケットを受信するのはGW or dst端末
dst端末では受信パケットを破棄
問題
srcMAC A
dstMAC GW
srcIP 133.5.7.41
dstIP 133.5.7.49.217
MACアドレス GW
133.5.7.254/24
bond0:133.5.7.41/24
MACアドレス A
？
パケット送信
133.5.49.254/26
bond0:133.5.49.217/26
MACアドレス B
6
VPNによる解決



VPNによりサーバとクライアントが同セグメント
同セグメントなので、arpは直接dst端末のMACアドレスを取得
する
dstMACアドレスはdst端末
srcMAC A
dstMAC B
srcIP 192.168.0.1
dstIP 192.168.0.2
MACアドレス GW
133.5.7.254/24
？
bond0:192.168.0.1/24
133.5.49.254/26
bond0:192.168.0.2/26
VPN
MACアドレス A
MACアドレス B
7
VPNの問題


VPNにより通信は可能になった
しかし、VPNはスループットが低い
 およそVPNなしに比べ３０～４０％

VPNとVPNなしをbondingした場合、スループットは
VPNなし1本の時よりも低下する

VPNを使わない別の方法？
8
別の解決案１

dst端末において、dstMACアドレスがGWのものを受
信するようにする
srcMAC A
dstMAC GW
srcIP 133.5.7.41
dstIP 133.5.7.49.217
MACアドレス GW
133.5.7.254/24
bond0:133.5.7.41/24
MACアドレス A
？
パケット送信
133.5.49.254/26
bond0:133.5.49.217/26
MACアドレス B
MACアドレス GW
9
別の解決案２


ローカル側にルータがあるように見せかける
実際はローカルだけど別セグメントとして通信する
srcMAC A
dstMAC GW
srcIP 133.5.7.41
dstIP 133.5.7.49.217
MACアドレス GW
？
133.5.7.254/24
bond0:133.5.7.41/24
MACアドレス A
133.5.49.254/26
パケット送信
133.5.7.254/24
133.5.49.254/26
仮想的なルータがあるように見せかける
bond0:133.5.49.217/26
MACアドレス B
10

Download Report