rabbit51

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

NVR500 IPv6 ルーティング障害発生 #2 (LAN1・LAN2入替確認)

2020-02-20 17:00:00 | NVR500
NVR500 IPv6 ルーティング 障害発生」の原因を探るため、実環境から切り離したNVR500のLAN2にiperf3サーバー、LAN1にiperf3クライアントを接続し、最小限のconfigで確認を行った。configを最小限に変更(DHCP設定、DNS設定、スケデュール設定、メール設定の削除)し、再起動を何度かしているうちに、IPv6のルーティングが復帰してしまった。
IPv6 Download方向の速度低下の原因が解明できたので、NVR500 ルーティング・スループット計測も行ったが、計測中にUpload方向で約100Mbps程度のスループット変化が観測され、安定しない。

iperf3サーバー/クライアントのSender/Receiverでネットワークインターフェースin/out方向を確認しているが、LAN1にiperf3サーバー、LAN2にiperf3クライアントを接続するようNVR500のconfig設定を変更して計測してみた。念の為計測確認。
CROSS.config
# # NVR500 Rev.11.00.38 (Fri Apr 20 08:32:26 2018)
ipv6 prefix 1 2409:10:XXXX:YY40::/64
ipv6 prefix 2 2409:10:XXXX:YY00::/64
ip lan1 address 192.168.1.50/24
ipv6 lan1 address 2409:10:XXXX:YY00::10/64
ipv6 lan1 rtadv send 2
ip lan2 address 192.168.5.1/24
ipv6 lan2 address 2409:10:XXXX:YY40::1/64
ipv6 lan2 rtadv send 1
dhcp service server
dhcp server rfc2131 compliant except remain-silent
dhcp scope 1 192.168.5.2-192.168.5.191/24
dhcp scope 2 192.168.1.51-192.168.1.60/24
予想通り、変化なし。

何が原因なのだろうか。。。
コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

NVR500ルーティング・スループット計測(不具合の原因)

2020-02-15 14:00:00 | NVR500
NVR500ルーティング・スループット計測でIPv6 Download方向がUpload方向の1/3程度しかない。原因を探っているうちに、「NVR500 IPv6 ルーティング障害」が発生し、NVR510に更新した。入れ替える前に、未接続状態と運用接続状態で基本的なスループットを計測した。計測時にNVR500と同様にNVR510でもIPv6ルーティング・スループットがDownload方向で低下するのが観測された。
新品の機器でこのような事象発生は考えにくい。計測時にiperf3サーバとiperf3クライアント間経路のスイッチポートLEDだけでなく、PR-S300SEのスイッチポートLEDも点滅していた。解析の結果下記のことが判った。



(1)PR-S300SE設定
電話関連以外の設定変更は、デフォルトから下記の通り軽微。LAN側は、「192.168.1.0/24」でDHCPサーバが機能。IPv6静的ルーティング設定は、PPPoE接続IFだけ有効。DHCPv6-PDでLAN側にリースされるprefixへは、リース先へルーティング。その他は、上位ルータへリンクアドレスで転送。NGN側のDNSサーバへ問い合わせ時に、「prefix::/56+::1::/64+LAN側Modified EUI-64」のIPv6アドレスがソースアドレスとして使われる(記載なし-ping6応答あり)。
上図で「2409:10:XXXX:YY01:225:dcff:fe12:3456/64」。
ファームウェアバージョン:22.01
接続先設定(IPv4 PPPoE): 未設定
接続先設定(IPv6 PPPoE): 未設定
DHCPv4サーバ機能: 使用する
IPv6パケットフィルタ設定(IPoE): icmpv6, 公開サーバ(http/IKEv2)のポート開放
  「光ネクストPR-S300SEのIPv6 IPoEにICMPv6フィルタ 」
  「PR-S300SEのIPv6セキュリティフィルタを調整」
  「China Telecom領域からのIPv6スキャンをフィルタする」
IPv6セキュリティレベル: 高度
LAN側静的ルーティング: 
  「0.0.0.0/0 gw 192.168.1.51」(Transix DS-Lite IPv4 over IPv6)
  「192.168.11.0/24 gw 192.168.1.51」
PPPoEブリッジ: 使用する
UPnP設定: 使用する

(2)NVR500設定
IPv4アドレスは、LAN2がdhcp取得(PR-S300SEの再起動時にIPアドレスが変化しないように、「dhcp client option lan2 primary 50=c0,a8,01,33」指定)、LAN1が固定アドレス。IPv6アドレスは、LAN2がRA+Modified EUI-64、LAN1がDHCPv6-PDで委任されたprefixに基づく固定アドレス。LAN1は、DHCPサーバとRA。IPv4公開アドレスからのアクセスは、「ぷららPPPoE接続」経由、その他は、「Transix DS-LiteのIPv4 over IPv6」経由。
ファームウェアバージョン: Rev. 11.00.38
ip route default gateway pp 1 filter 10 11 12 gateway tunnel 1 weight 1000 hide gateway pp 1 weight 1 hide
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

(3)iperf3 on Debian10サーバー
IPv4は、DHCP取得。PR-S300SEの再起動でアドレスが変化しないように、「send dhcp-request-address 192.168.1.57;」を設定。
IPv6は、固定。DHCPv6-PDでprefixの委任を受ける。
/etc/dhcp/dhclient.conf
interface "enp3s0" {
    send dhcp-requested-address 192.168.1.57;
}

/etc/network/interfaces
iface enp3s0 net dhcp
    address 192.168.1.57
    up ip route add 192168.11.0/24 via 192.168.1.51 dev enp3s0
    down ip route del 192.168.11.0/24 via 192.168.1.51 dev enp3s0

iface enp3s0 inet6 dhcp
    autoconf 0
    request_prefix 1

iface enp3s0 inet6 static
    address 2409:10:XXXX:YY00::1:110/64
    gateway 2409:10:XXXX:YY00:225:dcff:fe12:3456

(4)iperf3クライアント on macOS 10.14.6 Mojave
NVR500のLAN1配下のネットワークにDHCP接続

(5)iperf3クライアントからサーバへのUpload経路
iperf3クライアントからiperf3サーバーへのIPv4およびIPv6パケットは、default gatewayであるNVR500へ転送される。NVR500ルータ上では、iperf3サーバーのアドレスがLAN2インタフェースのimplicit経路に適合し、iperf3サーバーへ転送される。

(6)iperf3サーバーからクライアントへのDownload経路
iperf3サーバーからiperf3クライアントへのIPv4パケットは、サーバーのroute tableに「192.168.11.0/24 gw 192.168.1.51」経路がstatic設定されており、適合するためNVR500ルータへ転送され、iperf3クライアントへ転送される。
IPv6パケットは、IPv6 route tableに適合する経路が無いため、DHCPv6-PDで設定されるdefault gateway(PR-S300SE)へ転送される。PR-S300SEでは、NVR500に委任したprefix内の転送先となるためNVR500へ転送され、iperf3クライアントへ転送される。

(7)対策
debian10のIPv6 route tableにIPv6経路を追加する。
これで、IPv6 LAN2->LAN1(Download)方向の経路からPR-S300SEが経由されなくなる。
iface enp3s0 inet6 static
    address 2409:10:XXXX:YY00::1:110/64
    gateway 2409:10:XXXX:YY00:225:dcff:fe12:3456
    up ip -6 route add 2409:10:XXXX:YY10::/60 via fe80::2a0:deff:feAA:BB:CC dev enp3s0
    down ip -6 route del 2409:10:XXXX:YY10::/60 via fe80::2a0:deff:feAA:BB:CC dev enp3s0
大規模ネットワークであれば、ルータ間のRIPv2, BGP4, OSPFv3プロトコルなどで、このような問題発生は無い。個人宅などネットワーク1個でも問題は発生しない。静的経路設定で対応することにした。

(7)再計測
NVR500は、IPv6ルーティング障害でNVR510に変更した。
PR-S300SEのLAN側にVLAN(ID=2)でNVR500のLAN2を接続し、dhcpでIPv4アドレス、DHCPv6-PDでprefix取得、RA+SLAACでIPv6アドレスを設定、LAN1を192.168.5.0/24 LAN2で取得したprefix::/64のネットワーク構成でconfigを変更した(下記)。IPv4だけスループット計測する予定だったが、IPv6スループットも復活してしまった。。。
ipv6 prefix 1 dhcp-prefix@lan2::/64
ip lan1 address 192.168.5.1/24
ipv6 lan1 address dhcp-prefix@lan2::1/64
ipv6 lan1 rtadv send 1
ip lan2 address dhcp
ipv6 lan2 address auto
ipv6 lan2 dhcp service client
dhcp service server
dhcp server rfc2131 compliant except remain-silent
dhcp scope 1 192.168.5.2-192.168.5.191/24
dhcp client option lan2 primary 50=c0,a8,01,32
iperf3 IPv6 Receiver方向のスループット低下は、解消された。Sender方向のスループットで約100Mbpsの変化が発生する。発生するとしばらく続く。「NVR500 IPv6 ルーティング障害」と関係があるのかもしれない。この点を除けば、PR-S300SE配下のネットワークで計測しても、このサイトのNVR500スループット計測と比較して、Sender方向でスループット低下が計測されるが、実環境での計測に問題なさそうである。


確認のため、計測環境のVLANを変更しPR-S300SE配下から切り離し、スループットを計測してみた

ipv6 prefix 1 2409:10:XXXX:YY40::/64
ipv6 prefix 2 2409:10:XXXX:YY00::/64
ip lan1 address 192.168.5.1/24
ipv6 lan1 address 2409:10:XXXX:YY40::1/64
ipv6 lan1 rtadv send 1
ip lan2 address 192.168.1.10/24
ipv6 lan2 address 2409:10:XXXX:YY00::10/64
ipv6 lan2 rtadv send 2
dhcp service server
dhcp server rfc2131 compliant except remain-silent
dhcp scope 1 192.168.5.2-192.168.5.191/24
dhcp scope 2 192.168.1.50-192.168.1.60/24
PR-S300SEを経由しない構成で、IPv6 Receiver(LAN2->LAN1)方向のスループット低下は確認されなかった。Sender(LAN1->LAN2)方向のスループット値が変化する。IPv4もIPv6も同様の傾向がある。稼働中のPR-S300SE配下でスループットを計測しても影響は、軽微。 Sender/Receiver及び計測値の変動は、NVR500の故障が濃厚。中途半端に動作している状態だと安心出来ない。



コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

NVR500 IPv6 ルーティング 障害発生

2020-01-31 14:00:00 | NVR500
NVR500ルーティング・スループット計測(不具合or故障?)」の状態が続いていたが、昨日(1月30日)NVR500の再起動後に配下のPCからIPv6インターネットアクセスが出来なくなった。「ping6」でテストしてみるとIPv6のLAN2側からLAN1側へルーティングが出来ない状態を確認した。

NVR500からIPv6での通信が可能。IPv4は、NVR500を起点にTransix DS-LiteのAFTRにIPv4 over IPv6で処理されインターネットアクセスが可能、イントラネット内も通信可能。
・「ipv6 routing process normal」でも通信不可
・何回か再起動したが変化なし
2011年9月から8年4ヶ月間24時間稼働させてきた(約73,000時間)。
急遽「NVR510」をamazon primeで注文。 明日、2月1日には、到着予定。

NVR510に変更後、障害の原因を探ってみることに。。。
コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

NVR500ルーティング・スループット計測(不具合or故障?)

2020-01-25 16:30:00 | NVR500
NVR500のL2TP/IPSec最大スループット計測は、「UP: 150Mbps/DOWN: 100Mbps」であった。Macbook proやWindows端末のL2TP/IPSec最大スループットは、どのくらいなのか計測するためIKEv2とL2TP/IPSecサーバを用意して計測する事にした。
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
端末から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 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 *

(1)計測方法
・「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オプション]を下げる)

(2)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」でテストすると送信できるが、サーバー側が受信できないのでサーバー側の能力不足が推定される。

(3)NVR500 + fastpathのスループット計測
iperf3クライアントをNVR500配下(LAN1側)に接続し計測
NVR500のルーティングプロセス設定は、
ip routing process fast
ipv6 routing process fast
とする(デフォルト値)。

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ヶ月経過してハードウェア障害でも発生しているのか(考え難いが)?

(4)NVR500 + normalのスループット計測
NVR500のルーティングプロセス設定を
ip routing process normal
ipv6 routing process normal
として計測

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とほぼ同等。

(5)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追記 ----
サービス情報サイト」の「フレッツ速度測定サイトのリニューアルについて」で「4)リニューアル後の速度測定サイトの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ダウンロード計測結果に疑問!
コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

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

2019-12-01 12:01:00 | NVR500
NVR500のL2TP/IPsecの最大VPN回線速度(スループット)は、「100Mbps(Up:150Mbps/Down:100Mbps)」だった。
ESP暗号化方式「AES-CBC/SHA-HMAC」での計測だったが、「AES256-CBC/SHA-HMAC」で変化するか確認してみた(「AES256-CBC/SHA256-HMAC」は、Windows10、macOS Mojave及びiOSからNVR500へのVPN接続でエラーが発生するため確認出来ない)。


NVR500のSecurity Policyを変更し
tunnel select 2
ipsec sa policy 2 2 esp aes256-cbc sha-hmac
接続する


iperf3 -c -V <iperf3 server>


iperf3 -c -V -R <ipref3 server>


「AES-CBC/SHA-HMAC」と「AES256-CBC/SHA-HMAC」でスループット低下は、微小。


------------
NVR500 L2TP/IPsecの最大VPN回線速度計測 #2
NVR500 L2TP/IPsecの最大VPN回線速度計測
コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする