NVR500のL2TP/IPSec最大スループット計測は、「UP: 150Mbps/DOWN: 100Mbps」であった。Macbook proやWindows端末のL2TP/IPSec最大スループットは、どのくらいなのか計測するためIKEv2とL2TP/IPSecサーバを用意して計測する事にした。
端末からiperf3でIKEv2及びL2TP/IPSecのUP/DOWNスループットを計測するとIKEv2のDOWNストリームだけ約250Mbpsであった。
調べてみるとNVR500のIPv6ルーティングスループットも約250Mbpsであることが判った。
現状のホームネットワークを稼働させたまま、NVR500のルーティング・スループットを下記構成で確認してみた。
・NVR500からのTransix DS-Lite（IPv4 over IPv6）接続をWZR-HP-G300NH OpenWrtのDS-Liteを利用するよう変更
（PR-S300SEのデフォルトルートをOpenWrtへ変更）
・NVR500からのIPv4 PPPoE Plala接続を停止
・NVR500の設定をIPv4/IPv6ルータ（Security Filterなし）+ DHCP Server + DNS serverだけに変更
（１）計測方法
・「NVR500なし」は、「192.168.1.0/24」ネットワークにiperf3サーバとクライアントを設置し、GBTスイッチ間接続で計測
・「NVR500+fast」「NVR500+normal」は、「192.168.1.0/24」ネットワークにiperf3サーバ、「192.168.11.0/24」ネットワークにiperf3クライアントを設置
・「NVR500+fast」は、NVR500の「fastpath」設定（default）
[ ip routing process fast/ipv6 routing process fast ]
・「NVR500+normal」は、NVR500の「fastpath」なし設定
[ ip routing process normal/ipv6 routing process normal ]
・計測は、5回測定して最高値を採用
・iperf3でIPv4/IPv6TCPプロトコルのSender（アップロード方向）/Receiver［-Rオプション］（ダウンロード方向）で計測
・UDPは、受信側で受信失敗率10%以内となる最大スループット［-bオプション］を指定して計測
・UDPで「out of order」が発生したら再計測（続く場合は、［-bオプション］を下げる）
（２）NVR500ルータなしスループット計測
iperf3サーバとクライアントのGBTスイッチ直接接続で計測環境の最大スループット値を計測する
IPv4 TCP Sender（941Mbps）
IPv4 TCP Receiver（940Mbps）
IPv4 UDP Sender（347Mbps）
IPv4 UDP Receiver（955Mbps）
IPv6 TCP Sender（928Mbps）
IPv6 TCP Receiver（927Mbps）
IPv6 UDP Sender（325Mbps）
IPv6 UDP Receiver（940Mbps）
・TCPスループットは、GBTスイッチ接続で妥当な値
・UDPスループットは、IPv4/IPv6共にSender（クライアントからサーバーへの転送）側が低値。クライアントから「-b 1G」でテストすると送信できるが、サーバー側が受信できないのでサーバー側の能力不足が推定される。
（３）NVR500 + fastpathのスループット計測
iperf3クライアントをNVR500配下（LAN1側）に接続し計測
NVR500のルーティングプロセス設定は、とする（デフォルト値）。
IPv4 TCP Sender（824Mbps）
IPv4 TCP Receiver（939Mbps）
IPv4 UDP Sender（32.7Mbps）
IPv4 UDP Receiver（525Mbps）
IPv6 TCP Sender（777Mbps）
IPv6 TCP Receiver（249Mbps）
IPv6 UDP Sender（22.9Mbps）
IPv6 UDP Receiver（200Mbps）
IPv4 TCPは、Sender（アップロード方向）で若干低下（約100Mbps）。UDPのSender方向は、目を疑う低下。Receiver方向から1/16の低下。IPv6のSender方向は、IPv4と同様の傾向だが、Receiver方向がSender方向の1/4に低下。
フレッツ 光ネクスト ファミリー・ハイスピードタイプだと下り最大200Mbpsなので気がつかなかっただけなのか、不具合が発生しているのか、2011年9月導入から8年4ヶ月経過してハードウェア障害でも発生しているのか（考え難いが）？
（４）NVR500 + normalのスループット計測
NVR500のルーティングプロセス設定をとして計測
IPv4 TCP Sender（384Mbps）
IPv4 TCP Receiver（491Mbps）
IPv4 UDP Sender（29.7Mbps）
IPv4 UDP Receiver（540Mbps）
IPv6 TCP Sender（174Mbps）
IPv6 TCP Receiver（234Mbps）
IPv6 UDP Sender（19.8Mbps）
IPv6 UDP Receiver（205Mbps）
IPv4 TCPは、Sender/Receiver共に約1/2。UDPは、fastpathとほぼ同等。IPv6 TCPは、Sender側が約1/4、Receiver側が同程度。UDPは、fastpathとほぼ同等。
（５）NVR500スループット結果
・計測環境のIPv4/IPv6 UDP Senderスループットが低いのは、サーバー機のUDP受信処理能力による（サーバー機とクライアント機の接続するネットワークを相互に入れ替えて計測し、Sender/Receiverスループット値が逆転する事を確認済み）。
NVR500ルーティング・スループット値問題点
・IPv4/IPv6 TCP Sender方向（UPLOAD:LAN1->LAN2）がReceiver方向（DOWNLOAD:LAN2->LAN1）より約100Mbpsスループットが低い（10%ダウン）
・IPv6は、IPv4よりスループットが約1/2低い（fastpathオフ状態）
・IPv4/IPv6 UDP Sender方向（LAN1->LAN2）スループットは、Receiver方向（LAN2->LAN1）より異常に低い（約1/10）
・IPv4/IPv6 UDP は、fastpathオン状態でfastpathオフ状態と同等スループット値（TCPは、約2-3倍）
・IPv6 TCPは、fastpathオン状態でReceiver方向（LAN2->LAN1）スループット値がfastpathオフ状態と同等スループット値
-------
iperf3の測定データがfastpath動作外（normal動作）に該当しないか確認してみた。IPv4ではfastpath動作しているようなのでIPv6で動作しない理由が確認できなかった。ハードウェア障害も考え難い（導入後8年4ヶ月24時間稼働だが）。ソフトウェア不具合の可能性が高い。
---- 2020/2/15 追記：（原因解明）
「NVR500ルーティング・スループット計測（不具合の原因）」
確認のため、フレッツの「サービス情報サイトの通信速度測定」と「みんなのネット回線速度」で計測してみた。
フレッツ「サービス情報サイト」の「通信速度測定」
NVR500ルーティング「あり・なし」で大きな差異が無い。2019年10月末リニューアル前では、「マルチセッション」と「シングルセッション」での計測が提供されていた。記載されて無いが、「マルチセッション」計測が推定される。測定ツールは、RBBSと記載。NVR500ルーティングが介在有無に関わらず「約300Mbps」のスループットが測定された。
---- 2020/1/28追記 ----
「サービス情報サイト」の「フレッツ速度測定サイトのリニューアルについて」で「４）リニューアル後の速度測定サイトのURL」に記載された「SPEED TEST」で計測すると
IPv4は、「WZR-HP-G300NH+OpenWrtのTransix DS-Lite」接続のため低値。NGN内約350Mbps （約300-350Mbpsで変動）。インターネット上約250Mbps（約210-250Mbpsで変動）。
--------
「みんなのネット回線速度」
「HTML5 Speedtest」が使用されていると記載。「speedtest」は、ダウンロード計測時にマルチストリームで「デフォルト6ストリーム」。
IPv6ダウンロードでも「656.69Mbps」のスループットを計測している。何故？
iperf3を動作させているサーバ上に「HTML5 Speedtest（Librespeed）」を稼働させ確認してみた。
Apache/2.4.38 (Debian)
PHP 7.3.11-1~deb10u1
librespeed / speedtest
NVR500ルーティングなし/IPv4
NVR500ルーティングなし/IPv6
NVR500ルーティング/IPv4
NVR500ルーティング/IPv6
IPv6ダウンロード方向のスループットは、「262Mbps」でiperf3の計測結果と粗一致した。
「みんなのネット回線速度」のIPv6ダウンロード計測結果に疑問！
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
Linux strongSwan U5.7.2/K4.19.0-5-amd64 + xl2tpd-1.3.12調べてみるとNVR500のIPv6ルーティングスループットも約250Mbpsであることが判った。
現状のホームネットワークを稼働させたまま、NVR500のルーティング・スループットを下記構成で確認してみた。
・NVR500からのTransix DS-Lite（IPv4 over IPv6）接続をWZR-HP-G300NH OpenWrtのDS-Liteを利用するよう変更
（PR-S300SEのデフォルトルートをOpenWrtへ変更）
・NVR500からのIPv4 PPPoE Plala接続を停止
・NVR500の設定をIPv4/IPv6ルータ（Security Filterなし）+ DHCP Server + DNS serverだけに変更
NVR500 config
# NVR500 Rev.11.00.38 (Fri Apr 20 08:32:26 2018)
# MAC Address : 00:a0:de:AA:BB:CC, 00:a0:de:AA:BB:CD
# Memory 64Mbytes, 2LAN, 1BRI
# main: NVR500 ver=00 serial=S12345678 MAC-Address=00:a0:de:AA:BB:CC MAC-Address=00:a0:de:AA:BB:CD
# Reporting Date: Jan 15 13:47:05 2020
login password encrypted *
administrator password encrypted *
login user user1 *
console character ascii
ip route default gateway dhcp lan2
ipv6 route default gateway dhcp lan2
ipv6 prefix 1 dhcp-prefix@lan2::/64
ip lan1 address 192.168.11.250/24
ipv6 lan1 address dhcp-prefix@lan2::11:250/64
ipv6 lan1 rtadv send 1 o_flag=on
ipv6 lan1 dhcp service server
ip lan2 address dhcp
ipv6 lan2 address auto
ipv6 lan2 dhcp service client
syslog debug off
telnetd host none
dhcp service server
dhcp server rfc2131 compliant except remain-silent
dhcp scope 1 192.168.11.2-192.168.11.63/24
dhcp scope bind 1 192.168.11.5 ethernet 00:13:ce:12:34:56
dhcp scope bind 1 192.168.11.7 ethernet 00:21:70:12:34:57
dhcp scope bind 1 192.168.11.9 ethernet bc:c3:42:12:34:58
dhcp scope bind 1 192.168.11.11 ethernet 78:2b:cb:12:34:59
dhcp scope bind 1 192.168.11.23 ethernet c0:25:e9:12:34:5a
dhcp client release linkdown on
dhcp client option lan2 primary 50=c0,a8,01,33
dns service fallback on
dns server dhcp lan2
dns server select 500000 dhcp lan2 any .
dns domain somewhere
dns private address spoof on
ip host debian10.somewhere 192.168.1.57
ip host ds216j.somewhere 192.168.11.241
ip host gs116e.somewhere 192.168.11.249
ip host h2vmgr.somewhere 192.168.11.252
ip host hvl1-vol1.somewhere 192.168.11.240
ip host pc1.somewhere 192.168.11.7
ip host pc4.somewhere 192.168.11.23
ip host nvr500.somewhere 192.168.11.250
ip host nvr500-lan2.somewhere 192.168.1.2
ip host nvr500v4.somewhere 192.168.11.250
ip host openwrt.somewhere 192.168.12.1
ip host panasonic-fax.somewhere 192.168.11.9
ip host prs300se.somewhere 192.168.1.1
ip host rd-bz700.somewhere 192.168.11.102
ip host rd-h1.somewhere 192.168.11.100
ip host sx2000u2.somewhere 192.168.11.221
ip host ts9030.somewhere 192.168.11.222
ip host tv19re1s.somewhere 192.168.11.103
ip host tv42z8000.somewhere 192.168.11.101
ip host wl2.somewhere 192.168.11.253
ip host wl3.somewhere 192.168.11.254
ip host wl4.somewhere 192.168.11.251
dns static aaaa debian10.somewhere 2409:10:xxxx:yy00::1:110
dns static aaaa ds216j.somewhere 2409:10:xxxx:yy10::11:241
dns static aaaa nvr500.somewhere 2409:10:xxxx:yy10::11:250
dns static aaaa nvr500-lan2.somewhere 2409:10:xxxx:yy00:2a0:deff:feAA:BBCC
dns static aaaa openwrt.somewhere 2409:10:xxxx:yy20::12:1
dns static aaaa prs300se.somewhere 2409:10:xxxx:yy00:225:dcff:feAA:BBCD
dns static aaaa wl4.somewhere 2409:10:xxxx:yy10::11:251
dns private name nvr500.somewhere
schedule at 1 */* 01:26 * ntpdate ntp1.v6.mfeed.ad.jp
schedule at 2 */* 00:10 * mail notify account exec 1
schedule at 3 */1 01:00 pp 1 clear account pp
schedule at 4 */1 01:00 * clear account analog total
schedule at 5 */1 01:00 * clear account analog 1
schedule at 6 */1 01:00 * clear account analog 2
schedule at 50 */Sat 02:00 * lua sd1:/local/NgnRouteSetting.lua
schedule at 51 startup * lua sd1:/local/ckDHCPv6.lua
httpd host 192.168.1.0-192.168.1.255 192.168.11.0-192.168.13.255 2409:10:xxxx:yy00::-2409:10:xxxx:yy20:ffff:ffff:ffff:ffff
mail server name 1 v6mail.nvr500.somewhere
mail server smtp 1 v6mail.plala.or.jp port=587 smtp-auth someone@white.plala.or.jp password cram-md5
mail server name 2 nvr500.somewhere
mail server smtp 2 v6mail.plala.or.jp port=587 smtp-auth someone@white.plala.or.jp password cram-md5
mail template 1 1 From:nvr500@somewhere To:someone@white.plala.or.jp "Subject:nvr500 info" notify-wait-time=1
mail template 2 1 From:nvr500@somewhere To:someone@white.plala.or.jp "Subject:nvr500 intrusion info"
mail notify 1 1 trigger account
mail notify 2 2 trigger intrusion lan1 in lan2 in lan1 out lan2 out pp 1 in pp 1 out tunnel 1-2 in tunnel 1-2 out
sshd service on
sshd host key generate *（１）計測方法
・「NVR500なし」は、「192.168.1.0/24」ネットワークにiperf3サーバとクライアントを設置し、GBTスイッチ間接続で計測
・「NVR500+fast」「NVR500+normal」は、「192.168.1.0/24」ネットワークにiperf3サーバ、「192.168.11.0/24」ネットワークにiperf3クライアントを設置
・「NVR500+fast」は、NVR500の「fastpath」設定（default）
[ ip routing process fast/ipv6 routing process fast ]
・「NVR500+normal」は、NVR500の「fastpath」なし設定
[ ip routing process normal/ipv6 routing process normal ]
・計測は、5回測定して最高値を採用
・iperf3でIPv4/IPv6TCPプロトコルのSender（アップロード方向）/Receiver［-Rオプション］（ダウンロード方向）で計測
・UDPは、受信側で受信失敗率10%以内となる最大スループット［-bオプション］を指定して計測
・UDPで「out of order」が発生したら再計測（続く場合は、［-bオプション］を下げる）
（２）NVR500ルータなしスループット計測
iperf3サーバとクライアントのGBTスイッチ直接接続で計測環境の最大スループット値を計測する
IPv4 TCP Sender（941Mbps）
IPv4 TCP Receiver（940Mbps）
IPv4 UDP Sender（347Mbps）
IPv4 UDP Receiver（955Mbps）
IPv6 TCP Sender（928Mbps）
IPv6 TCP Receiver（927Mbps）
IPv6 UDP Sender（325Mbps）
IPv6 UDP Receiver（940Mbps）
・TCPスループットは、GBTスイッチ接続で妥当な値
・UDPスループットは、IPv4/IPv6共にSender（クライアントからサーバーへの転送）側が低値。クライアントから「-b 1G」でテストすると送信できるが、サーバー側が受信できないのでサーバー側の能力不足が推定される。
（３）NVR500 + fastpathのスループット計測
iperf3クライアントをNVR500配下（LAN1側）に接続し計測
NVR500のルーティングプロセス設定は、
ip routing process fast
ipv6 routing process fastIPv4 TCP Sender（824Mbps）
IPv4 TCP Receiver（939Mbps）
IPv4 UDP Sender（32.7Mbps）
IPv4 UDP Receiver（525Mbps）
IPv6 TCP Sender（777Mbps）
IPv6 TCP Receiver（249Mbps）
IPv6 UDP Sender（22.9Mbps）
IPv6 UDP Receiver（200Mbps）
IPv4 TCPは、Sender（アップロード方向）で若干低下（約100Mbps）。UDPのSender方向は、目を疑う低下。Receiver方向から1/16の低下。IPv6のSender方向は、IPv4と同様の傾向だが、Receiver方向がSender方向の1/4に低下。
フレッツ 光ネクスト ファミリー・ハイスピードタイプだと下り最大200Mbpsなので気がつかなかっただけなのか、不具合が発生しているのか、2011年9月導入から8年4ヶ月経過してハードウェア障害でも発生しているのか（考え難いが）？
（４）NVR500 + normalのスループット計測
NVR500のルーティングプロセス設定を
ip routing process normal
ipv6 routing process normalIPv4 TCP Sender（384Mbps）
IPv4 TCP Receiver（491Mbps）
IPv4 UDP Sender（29.7Mbps）
IPv4 UDP Receiver（540Mbps）
IPv6 TCP Sender（174Mbps）
IPv6 TCP Receiver（234Mbps）
IPv6 UDP Sender（19.8Mbps）
IPv6 UDP Receiver（205Mbps）
IPv4 TCPは、Sender/Receiver共に約1/2。UDPは、fastpathとほぼ同等。IPv6 TCPは、Sender側が約1/4、Receiver側が同程度。UDPは、fastpathとほぼ同等。
（５）NVR500スループット結果
・計測環境のIPv4/IPv6 UDP Senderスループットが低いのは、サーバー機のUDP受信処理能力による（サーバー機とクライアント機の接続するネットワークを相互に入れ替えて計測し、Sender/Receiverスループット値が逆転する事を確認済み）。
NVR500ルーティング・スループット値問題点
・IPv4/IPv6 TCP Sender方向（UPLOAD:LAN1->LAN2）がReceiver方向（DOWNLOAD:LAN2->LAN1）より約100Mbpsスループットが低い（10%ダウン）
・IPv6は、IPv4よりスループットが約1/2低い（fastpathオフ状態）
・IPv4/IPv6 UDP Sender方向（LAN1->LAN2）スループットは、Receiver方向（LAN2->LAN1）より異常に低い（約1/10）
・IPv4/IPv6 UDP は、fastpathオン状態でfastpathオフ状態と同等スループット値（TCPは、約2-3倍）
・IPv6 TCPは、fastpathオン状態でReceiver方向（LAN2->LAN1）スループット値がfastpathオフ状態と同等スループット値
-------
iperf3の測定データがfastpath動作外（normal動作）に該当しないか確認してみた。IPv4ではfastpath動作しているようなのでIPv6で動作しない理由が確認できなかった。ハードウェア障害も考え難い（導入後8年4ヶ月24時間稼働だが）。ソフトウェア不具合の可能性が高い。
---- 2020/2/15 追記：（原因解明）
「NVR500ルーティング・スループット計測（不具合の原因）」
確認のため、フレッツの「サービス情報サイトの通信速度測定」と「みんなのネット回線速度」で計測してみた。
フレッツ「サービス情報サイト」の「通信速度測定」
NVR500ルーティング「あり・なし」で大きな差異が無い。2019年10月末リニューアル前では、「マルチセッション」と「シングルセッション」での計測が提供されていた。記載されて無いが、「マルチセッション」計測が推定される。測定ツールは、RBBSと記載。NVR500ルーティングが介在有無に関わらず「約300Mbps」のスループットが測定された。
---- 2020/1/28追記 ----
「サービス情報サイト」の「フレッツ速度測定サイトのリニューアルについて」で「４）リニューアル後の速度測定サイトのURL」に記載された「SPEED TEST」で計測すると
IPv4は、「WZR-HP-G300NH+OpenWrtのTransix DS-Lite」接続のため低値。NGN内約350Mbps （約300-350Mbpsで変動）。インターネット上約250Mbps（約210-250Mbpsで変動）。
--------
「みんなのネット回線速度」
「HTML5 Speedtest」が使用されていると記載。「speedtest」は、ダウンロード計測時にマルチストリームで「デフォルト6ストリーム」。
IPv6ダウンロードでも「656.69Mbps」のスループットを計測している。何故？
iperf3を動作させているサーバ上に「HTML5 Speedtest（Librespeed）」を稼働させ確認してみた。
Apache/2.4.38 (Debian)
PHP 7.3.11-1~deb10u1
librespeed / speedtest
NVR500ルーティングなし/IPv4
NVR500ルーティングなし/IPv6
NVR500ルーティング/IPv4
NVR500ルーティング/IPv6
IPv6ダウンロード方向のスループットは、「262Mbps」でiperf3の計測結果と粗一致した。
「みんなのネット回線速度」のIPv6ダウンロード計測結果に疑問！
アクセス
トータル
