rabbit51

it's since Nov.30 2005
May.29 2014, transferred from broach

NVR500 L2TP/IPsecの最大VPN回線速度計測 #2

2019-11-28 17:00:00 | NVR500
NVR500 L2TP/IPsecの最大VPN回線速度計測」でNVR500のL2TP/IPsec最大VPN回線速度が「175Mbps」と測定したが、「RTX810 <-> Debian9+StrongSwan5.5.1のL2TP/IPsecスループット」と計測差があった事。その後の計測で175Mbpsが計測出来ないため検討してみた。
計測時の構成は、下記のように「Macbook pro」でインターネットアクセスが出来るよう、WiFi接続のOn/Offを行なっていた。


差異要因を推定
1)VPN端末からのiperf3計測パケットが送受異なった経路で計測された
WiFi接続でiperf3計測が行われた後、VPN接続でWiFi接続時のIPアドレスが配布され送受の経路が異なった。「iperf3」クライアント接続では、受信は「ack」だけなのでスループット増加は、微増程度。

2)VPNを経由せずWiFi経由で計測
WiFiは、「AirMac Time Capsule」2.4GHz 802.11n(転送レート約200Mbps。接続時の自動チャンネル選択により約100Mbps程度の時もある)/5Ghz 802.11ac(転送レート約1000Mbps)で距離約1-2m。802.11nでスループットを計ると約130Mbps程度なので、無線環境条件により175Mbpsのスループット計測可能性がある(150Mbps程度の計測値が行えたが、175Mbps程度の計測値を再現できていない)。

175Mbpsのスループット計測値を再現できないので、計測をやり直すことにした。

再計測条件
NVR500 L2TP/IPsecの最大VPN回線速度計測」からの変更点

1)iperf3サーバのOSを変更
CPU=Intel Core i7-2600 @ 3.40GHz, Memory=8Gbytes
Linux 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5+debian10u2(2019-08-08) X86_64 GNU/Linux

2)計測時WiFiオフ

3)MTU
NVR500 L2TP/IPsecの初期値MTU=1258とmacOSのL2TP/IPsecのMTU=1280で計測
pp select anonymousで「ip pp mtu 1258」「ip pp mtu 1280」の2条件で計測

4)iperf3でサーバ側からの送信時のスループット計測

計測値

1−1)NAPT=off/Filter=off/MTU=1258(クライアント送信)

iperf3のMSS=1206は、MTU(1258)-IP(20)-TCP(20)-TCPオプション(12)

1ー2)NAPT=off/Filter=off/MTU=1258(サーバー送信)


2−1)NAPT=off/Filter=off/MTU=1280(クライアント送信)

iperf3のMSS=1228は、MTU(1280)-IP(20)-TCP(20)-TCPオプション(12)

2−2)NAPT=off/Filter=off/MTU=1280(サーバー送信)


3−1)NAPT=on/Filter=off/MTU=1280(クライアント送信)


3−2)NAPT=on/Filter=off/MTU=1280(サーバー送信)


4−1)NAPT=on/Filter=on/MTU=1280(クライアント送信)


4−2)NAPT=on/Filter=on/MTU=1280(サーバー送信)


計測結果
RTX810 <-> Debian9+StrongSwan5.5.1のL2TP/IPsecスループット」と同等のスループット測定結果となった。

「Send」と「Receive」でスループットが1.5倍異なる原因を探ってみた。
IN側とOUT側ポートを同時にミラー設定してwiresharkでキャプチャした。
NVR500のポートは、GBT。mirrorポートに100BTのPanasonic CF-W4を接続してwiresharkでキャプチャしたところNVR500接続ポートも100BTに制限された。原因を掴むのに時間を要してしまった。当然と言えば当然。
GBTポートを持ったDynaBook SS RX2に変更して測定した。タイミングによりIN側とOUT側同時にパケットが発生しmirrorポートでキャプチャデータが破棄される事象が観られた。実環境と手持ち機器での評価は、難しい。。。
「Send」では、VPN端末からの暗号化されたESPパケットからDecryptが行われiperf3サーバーに早出する時間を計測。
「Receive」では、iperf3サーバからのパケットを暗号化しESPとしてVPN端末へ早出する時間を計測した。
計測対象は、TCPの同一Sequence番号を持つパケットの時間から計算した。
「Send」時のDecryption時間と「Receive」時のEncryption時間に有意な差があった。iperf3の10秒間計測中データから1秒後あたりと5秒後あたりで5ポイント程度でEncryption/Decryption時間比較してみた。1秒後で3.5msec/3msec、5秒後で7.4msec/3.5msecと差異が大きいがEncryptionに時間が掛かる結果と推定される。

NVR500のL2TP/IPsecでデフォルト設定されるMTUは、MTU=1258。IPv4パケットが効率よく(ESP Trailerに挿入されるPadがゼロ)なる値が選択されているようだ。IPv6パケットの最小MTUは、MTU=1280とされているため、macOSでは、MTU=1280がデフォルト。Win10は、理由が推測出来ないがMTU=1400がデフォルト

現時点(2019/11/27)でNVR500もNVR510もIPv6未対応となっているためMTU=1258で良いのだが、IPv6化を目指すためVPNのMTUをMTU=1280で統一設定する事にした。

------------
NVR500 L2TP/IPsecの最大VPN回線速度計測 #3
NVR500 L2TP/IPsecの最大VPN回線速度計測 #2
NVR500 L2TP/IPsecの最大VPN回線速度計測

コメント    この記事についてブログを書く
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする
« China Telecom領域からのIPv6... | トップ | NVR500 L2TP/IPsecの最大VPN... »
最新の画像もっと見る

コメントを投稿

ブログ作成者から承認されるまでコメントは反映されません。

NVR500」カテゴリの最新記事