OpenWRT(GL.iNet GL-MV1000)でBIGLOBEのIPoE(MAP-E)に接続した


いままでずっと自宅の回線がNTT東 Bフレッツマンションタイプだと思っていて、実際BIGLOBE側の契約管理画面でもそう表示されていたんだけど、NTT東でBフレッツマンションタイプは自動的にフレッツ光ネクストマンションタイプに移行させられていたということが判明。

そんなわけで「Biglobe IPv6接続(IPoE方式)」が使える様になったみたいなのでチャレンジ。

既にIPv6オプションは設定済みだったのでIPv6網への接続は完了している。BIGLOBE側の契約追加は必要なさそうなので、OpenWRT側の設定を実施。

まず、先行事例として参考になった記述は下記2つ。

OpenWrtでv6プラス (MAP-E) での IPv6 / IPv4 接続と、IPv4 PPPoEでのサーバー公開を両立する
OpenWrtでv6プラス(MAP-E)接続する手順

また、BIGLOBEで使われる DMR サーバのIPv6アドレスについては「biglobeのIPv4 over IPv6でハマった話 (RTX830)」に書かれている「https://api.enabler.ne.jp/6a4a89a8639b7546793041643f5da608/get_rules?callback=v6plus」で取得出来るJSONデータ内の「dmr」の値を参照した。(2404:9200:225:100::64だった)

まぁ、So-net事例と同じ値でしたけどね。

/lib/netifd/proto/map.shを編集して「# export LEGACY=1 」のコメントを外す必要あるし、ルーター再起動しないと駄目だったし、接続すると「MAP rule is invalid」で接続するとエラーになったので「Custom delegated IPv6-prefix」に値を設定しました。

「option encaplimit ‘ignore’」をつけないとRXがカウントされていない、という話については、現象は起こっていないので未設定です。

ニチバンのサイトにアクセスするとちゃんと表示されない問題はこちらでも発生中です。


2020/01/26追記

showroom-live.com で配信を見てると頻繁に接続できなくなる事態が発生。現状のshowroom-liveは映像配信についてはIPv6対応だが、ユーザアバターなどはIPv4のみという状況。これはもしや同時セッション数の問題?

OpenWrtでv6プラス(MAP-E)接続する手順」の「SNATを240ポート使えるように調整」(および元ネタの「 OpenWrt map-e (JPNE v6plus) において、割当ポート240個をちゃんと使わせるための設定 」)を実施。

すると期待通りに動作するようになった。

ニチバンのWebについてもスムーズに開けるようになった。

RD TC66Cのfirmwareをアップデート


うちにはUSB Type-Cの電圧電流計RD TC66Cが2種類ある。

そういや、新しいfirmwareがあるのかな?とRuiDengUSBMeterを起動してみると下記の様なダイアログが表示された。

[Download URL]
http://www.ruidengkeji.com/rdupdate/software/RuiDengUSBMeter/RuidengUSBMeter_V1.0.0.6.rar

2019.12.06 Version Number:V1.0.0.6
1.Change the software to installation free
2.Fix the bug of exporting data to excel

2019.12.06 版本号:V1.0.0.6

1.软件改为免安装使用

2.修复数据导出到Excel异常bug

あたらしいRuiDengUSBMeterソフトウェアが出たようなので「http://www.ruidengkeji.com/rdupdate/software/RuiDengUSBMeter/RuidengUSBMeter_V1.0.0.6.rar」からダウンロードして起動。

1111セールで買ったTC66はv1.14と最新だった。

以前からあるやつはv1.12と古い。

まず、TC66を1回外してから書き換えモードにする必要があります。

書き換えモードにしたあとRuiDengUSBMeterのFirmware Updateから「Update now」を実行

無事v1.14にアップデートされました。

ちなみに書き換えモードにしないでUpdate nowすると、下記の様なエラーとなります。

GL.iNet GL-MV1000でDynamic DNSが動かない


GL.iNet GL-MV1000のlcuiの方でdyn.comのDynamic DNSを設定したのだが、再起動時に自動実行してくれない。

設定画面としては下記の様になっている。

Enabledにチェックが入っているので、自動起動してもよさそうなのだがしていない。

とりあえず起動の仕組みをさぐるため、ルータにrootでログイン。

とりあえず「/etc/init.d」にはどんなファイルがあるのか確認してみると「ddns」というソレっぽいファイルが。

root@GL-MV1000:~# ls /etc/init.d
boot              firewall          gl_s2s            initswitch        openvpn           sysctl            usbmode
bootcount         firewall_gl       gl_tertf          led               qosswitch         sysfixtime        vpn-service
clear_flag        gl_fixdomain      gl_udp_server     lighttpd          relayd            sysntpd           wireguard
cron              gl_init           glcrond           log               rpcd              system            wireguard_server
ddns              gl_monitor        glfw              modem-init        samba             ucitrack
dnsmasq           gl_mqtt           glqos             mwan3             smstools3         uhttpd
done              gl_mv1000         gpio_switch       network           startvpn          umount
dropbear          gl_route_policy   haveged           odhcpd            stubby            urandom_seed
root@GL-MV1000:~#

/etc/rc.dには「S95ddns」と「K10ddns」(どちらも/etc/init.d/ddnsへのシンボリックリンク)

root@GL-MV1000:~# ls /etc/rc.d
K10ddns              S00sysfixtime        S19dnsmasq           S50glfw              S95ddns              S99lighttpd
K10gpio_switch       S10boot              S19dropbear          S50stubby            S95done              S99startvpn
K50dropbear          S10gl_mv1000         S19firewall          S60samba             S96led               S99urandom_seed
K51stubby            S10system            S19mwan3             S70modem-init        S98sysntpd           S99wireguard
K85odhcpd            S11sysctl            S20network           S80gl_tertf          S99bootcount         S99wireguard_server
K89log               S12log               S20usbmode           S80relayd            S99gl_monitor
K90network           S12rpcd              S21initswitch        S80ucitrack          S99gl_mqtt
K90sysfixtime        S13haveged           S35odhcpd            S90vpn-service       S99gl_route_policy
K98boot              S15gl_fixdomain      S50cron              S94gpio_switch       S99gl_s2s
K99umount            S18firewall_gl       S50glcrond           S94smstools3         S99gl_udp_server
root@GL-MV1000:~#

すでに/etc/rc.d/S95ddnsがあるので起動時から動作していても良さそうなのにしていない、ということはスクリプトの中で何らかの処理を行っているはず、ということで中身を確認。

root@GL-MV1000:~# cat /etc/init.d/ddns
#!/bin/sh /etc/rc.common
START=95
STOP=10
boot() {
return 0
}
reload() {
/usr/lib/ddns/dynamic_dns_updater.sh -- reload
return 0
}
restart() {
/usr/lib/ddns/dynamic_dns_updater.sh -- stop
sleep 1
enable=`uci -q get ddns.glddns.enabled`
if [ "$enable" = 1 ];then
        /usr/lib/ddns/dynamic_dns_updater.sh -- start
fi
}
start() {
enable=`uci -q get ddns.glddns.enabled`
if [ "$enable" = 1 ];then
        /usr/lib/ddns/dynamic_dns_updater.sh -- start
fi
}
stop() {
/usr/lib/ddns/dynamic_dns_updater.sh -- stop
return 0
}
root@GL-MV1000:~#

「start()」で「uci -q get ddns.glddns.enabled」の値を確認している。

root@GL-MV1000:~# uci -q get ddns.glddns.enabled
root@GL-MV1000:~#

現状は値が設定されていないため、起動していないようだ。

uciのパラメータを全部確認する場合は「uci -q show」で確認できるので、「uci -q show|grep dns.」を実行してみた。

root@GL-MV1000:~# uci -q show|grep dns.
ddns.global=ddns
ddns.global.ddns_dateformat='%F %R'
ddns.global.ddns_loglines='250'
ddns.global.upd_privateip='0'
ddns.myddns_ipv4=service
ddns.myddns_ipv4.lookup_host='yourhost.example.com'
ddns.myddns_ipv4.domain='yourhost.example.com'
ddns.myddns_ipv4.username='your_username'
ddns.myddns_ipv4.password='your_password'
ddns.myddns_ipv4.interface='wan'
ddns.myddns_ipv4.ip_source='network'
ddns.myddns_ipv4.ip_network='wan'
ddns.myddns_ipv4.service_name='dyn.com'
ddns.myddns_ipv4.enabled='0'
ddns.myddns_ipv6=service
ddns.myddns_ipv6.update_url='http://[USERNAME]:[PASSWORD]@your.provider.net/nic/update?hostname=[DOMAIN]&myip=[IP]'
ddns.myddns_ipv6.lookup_host='yourhost.example.com'
ddns.myddns_ipv6.domain='yourhost.example.com'
ddns.myddns_ipv6.username='your_username'
ddns.myddns_ipv6.password='your_password'
ddns.myddns_ipv6.use_ipv6='1'
ddns.myddns_ipv6.interface='wan6'
ddns.myddns_ipv6.ip_source='network'
ddns.myddns_ipv6.ip_network='wan6'
ddns.myddns_ipv6.enabled='0'
ddns.osakana=service
ddns.osakana.enabled='1'
ddns.osakana.lookup_host='********************'
ddns.osakana.service_name='dyn.com'
ddns.osakana.domain='********************'
ddns.osakana.username='********************'
ddns.osakana.password='********************'
dhcp.@dnsmasq[0]=dnsmasq
dhcp.@dnsmasq[0].domainneeded='1'
dhcp.@dnsmasq[0].boguspriv='1'
dhcp.@dnsmasq[0].filterwin2k='0'
dhcp.@dnsmasq[0].localise_queries='1'
dhcp.@dnsmasq[0].rebind_protection='1'
dhcp.@dnsmasq[0].rebind_localhost='1'
dhcp.@dnsmasq[0].local='/lan/'
dhcp.@dnsmasq[0].domain='lan'
dhcp.@dnsmasq[0].expandhosts='1'
dhcp.@dnsmasq[0].nonegcache='0'
dhcp.@dnsmasq[0].authoritative='1'
dhcp.@dnsmasq[0].readethers='1'
dhcp.@dnsmasq[0].leasefile='/tmp/dhcp.leases'
dhcp.@dnsmasq[0].resolvfile='/tmp/resolv.conf.auto'
dhcp.@dnsmasq[0].nonwildcard='1'
dhcp.@dnsmasq[0].localservice='1'
glconfig.ddns=service
glconfig.ddns.enabled='0'
luci.diag.dns='openwrt.org'
ucitrack.@dhcp[0].init='dnsmasq'
root@GL-MV1000:~#

ん?

「glconfig.ddns.enabled=’0’」?

もしかして、GL.iNet Admin Panelの方にある???

[アプリケーション]-[リモートアクセス]に「ダイナミックDNS」がありました。

有効化をしてみます

これにより「uci -q show|grep dns.」に大きな変化が・・・

root@GL-MV1000:~# uci -q show|grep dns.
ddns.global=ddns
ddns.global.ddns_dateformat='%F %R'
ddns.global.ddns_loglines='250'
ddns.global.upd_privateip='0'
ddns.global.use_curl='1'
ddns.osakana=service
ddns.osakana.enabled='1'
ddns.osakana.lookup_host='*******************'
ddns.osakana.service_name='dyn.com'
ddns.osakana.domain='*******************'
ddns.osakana.username='*******************'
ddns.osakana.password='*******************'
ddns.glddns=service
ddns.glddns.interface='wan'
ddns.glddns.check_interval='10'
ddns.glddns.check_unit='minutes'
ddns.glddns.force_interval='60'
ddns.glddns.force_unit='minutes'
ddns.glddns.ip_url='http://checkip.dyndns.com'
ddns.glddns.ip_source='web'
ddns.glddns.password='*******************'
ddns.glddns.username='*******************'
ddns.glddns.domain='cx0f702.glddns.com'
ddns.glddns.param_enc='cx0f702'
ddns.glddns.lookup_host='cx0f702.glddns.com'
ddns.glddns.service_name='glddns.com'
ddns.glddns.update_url='http://[USERNAME]:[PASSWORD]@ddns.glddns.com/nic/update?hostname=[PARAMENC]&myip=[IP]'
ddns.glddns.enabled='1'
dhcp.@dnsmasq[0]=dnsmasq
dhcp.@dnsmasq[0].domainneeded='1'
dhcp.@dnsmasq[0].boguspriv='1'
dhcp.@dnsmasq[0].filterwin2k='0'
dhcp.@dnsmasq[0].localise_queries='1'
dhcp.@dnsmasq[0].rebind_protection='1'
dhcp.@dnsmasq[0].rebind_localhost='1'
dhcp.@dnsmasq[0].local='/lan/'
dhcp.@dnsmasq[0].domain='lan'
dhcp.@dnsmasq[0].expandhosts='1'
dhcp.@dnsmasq[0].nonegcache='0'
dhcp.@dnsmasq[0].authoritative='1'
dhcp.@dnsmasq[0].readethers='1'
dhcp.@dnsmasq[0].leasefile='/tmp/dhcp.leases'
dhcp.@dnsmasq[0].resolvfile='/tmp/resolv.conf.auto'
dhcp.@dnsmasq[0].nonwildcard='1'
dhcp.@dnsmasq[0].localservice='1'
glconfig.ddns=service
glconfig.ddns.enabled='0'
glconfig.ddns.check_status='1'
glconfig.ddns.ddns_enabled='1'
glconfig.ddns.http_enabled='0'
glconfig.ddns.https_enabled='0'
glconfig.ddns.ssh_enabled='0'
luci.diag.dns='openwrt.org'
ucitrack.@dhcp[0].init='dnsmasq'
root@GL-MV1000:~#

そして、luciの方も無事Dynamic DNSが起動している状態となりました。

また、GL.iNetの提供するDynamic DNS(glddns)もあわせて有効になっています。

GL.iNet GL-MV1000をフレッツ光ネクストのIPv6網に接続した


GL.iNet GL-MV1000をバッファロー WSR-2533DHP2-CBのルーター機能の代わりに導入した。

うちはいまだにフレッツ光ネクスト+IPv6オプション環境なので、どうなるかなぁ?と思ったら標準設定ではIPv6での接続がうまくいかなかった。(注:BIGLOBE側の契約表記が「Bフレッツ マンションタイプ」のままなんだけど、フレッツ側の契約を確認してみるといつの間にか「フレッツ 光ネクスト」に切り替わっていた)

どうすればいいのかな?とググったら「フレッツ光 + OpenWrt で IPv6 を使う」に書いてある通りのことで対応できた。

GL.iNet GL-MV1000の標準状態で DHCPv6 クライアント の設定までは行われていたので、 /etc/config/dhcp のファイルを編集するだけで済んだ。

変更するためにはsshでアクセスして、rootユーザでログインすればOK

#初期状態
<略>
config dhcp 'lan'
	option interface 'lan'
	option start '100'
	option limit '150'
	option leasetime '12h'
	option force '1'
	option dhcpv6 'server'
	option ra 'server'

config dhcp 'wan'
	option interface 'wan'
	option ignore '1'
<略>

lanのところのdhcpv6とraの「server」を「relay」に変更し、ndpを追加

wan6を新規で追加し、項目を追加

# BフレッツIPv6対応
config dhcp 'lan'
        option interface 'lan'
        option start '100'
        option limit '150'
        option leasetime '12h'
        option force '1'
        option dhcpv6 'relay'
        option ra 'relay'
        option ndp 'relay'

config dhcp 'wan'
        option interface 'wan'
        option ignore '1'

config dhcp 'wan6'
        option dhcpv6 'relay'
        option ra 'relay'
        option ndp 'relay'
        option master '1'

参考にしたblogだとコマンドで「uci commit /etc/config/dhcp」を実行すればOKとあったが、うまく行かなかったので、ルータを再起動したところうまくいった。

なお、手動で変更したあと、luciのGUIを確認してみたが、変更された項目はなかったので、「 Powered by LuCI openwrt-19.07 branch (git-19.218.48058-9177466) / OpenWrt 19.07-SNAPSHOT r10273-2b88d02」「GL-MV1000 version 3.027」ではGUIの変更ができないようでした。

ONTAP9でボリューム削除して再作成しようとしたら空き容量がないと言われる


NetApp ONTAP8 7-modeで使用中のボリュームがあり、それをNetApp ONTAP9.5環境に対してtransitionのsnapmirrorを行った。

が・・・元ボリュームがqtree snapmirror中であったため、最後の処理で失敗した。(event log showの結果より)

1/14/2020 05:52:49  netapp95         ERROR         smc.snapmir.init.fail: Initialize from source volume 'netapp7mode:vol211' to destination volume 'netapp95svm:vol211' failed with error 'Transfer failed.'. Relationship UUID 'a3555a83-3360-11ea-a0b6-00a098f844df'.
1/14/2020 05:52:49  netapp95         ERROR         replication.dst.err: SnapMirror: destination transfer from netapp7mode:vol211 to vol211 : replication transfer failed to complete.
1/14/2020 05:52:49  netapp95         ERROR         snapmirror.dst.OnlineErr: SnapMirror not able to bring destination volume vol211 online, CR_TRANS_QTREE_REPLICA.
1/14/2020 05:52:46  netapp95         ERROR         wafl.voltrans.qtree.replica: The source of volume vol211 is a qtree replica. It cannot be transitioned to clustered Data ONTAP.

これについては、元のボリューム(netapp7mode:vol211)が受け側となっているqtree snapmirror全てに対して、「snapmirror quiesce netapp7mode:/vol/vol211/~」 と「snapmirror break netapp7mode:/vol/vol211/~」 を実行し、snapmirrorのステータスが「Broken-off」であれば7mode→ONTAP9へのtransition snapmirrorが成功することを確認。

で、snapmirrorの初期化(snapmirror initialize)にした場合、受け側のボリューム(今回はnetapp95svm:vol211)を削除して、再作成する必要がある。

netapp95上で「snapmirror delete -destination-path netapp95svm:vol211」でsnapmirror登録を消した後、ボリュームを「volume offline -vserver netapp95svm -volume vol211」でオフラインにしてから「volume delete -vserver netapp95svm -volume vol211」 で削除。

そして、「volume create -vserver netapp95svm -volume vol211 -aggregate aggr名 -size 22t -state online -type DP」で作成!

netapp95::> volume create -vserver netapp95svm -volume vol211 -aggregate aggr名 -size 22t -state online -type DP
[Job 351] Job is queued: Create vol211.                                        

Error: command failed: [Job 351] Job failed: Failed to create the volume on
       node "netapp95svm". Reason: Request to create volume "vol211" failed
       because there is not enough space in aggregate "aggr名". Either
       create 10.9TB of free space in the aggregate or select a size of at most
       11.2TB for the new volume. 
netapp95::>

おや?

netapp95::> storage aggregate show
Aggregate     Size Available Used% State   #Vols  Nodes            RAID Status
--------- -------- --------- ----- ------- ------ ---------------- ------------
<略>
aggr名 
           29.41TB   11.29TB   62% online       2 netapp95svm      raid_dp,
                                                                   normal
<略>
netapp95::>

まだ使用中という認識になっている???

いろいろ調べた結果、ONTAP 8.3より導入されたVolume Recovery Queueにより、削除したボリュームは12時間残しておく、という機能によるものだった。

How to use the Volume Recovery Queue feature in clustered Data ONTAP 8.3
How to enable the volume recovery queue in clustered Data ONTAP 8.3
After deleting a volume, the volume is brought offline with type DEL

強制的に削除するにはdiagモードにあるvolume recovery-queue purgeを使用する。

netapp95::> set diag 
Warning: These diagnostic commands are for use by NetApp personnel only.
Do you want to continue? {y|n}: y

netapp95::*> volume recovery-queue show
Vserver   Volume      Deletion Request Time     Retention Hours
--------- ----------- ------------------------  ---------------
netapp95svm vol211_1032_1032 
                      Thu Jan 16 14:33:18 2020               12

netapp95::*> 

上記の「volume recovery-queue show」で現在保持している削除したボリュームを確認できる。

削除は「volume recovery-queue purge -vserver netapp95svm -volume vol211_1032_1032」というような感じで実行する。

netapp95::*> volume recovery-queue purge -vserver netapp95svm -volume vol211_1032_1032 
Queued private job: 251                                                        

netapp95::*> volume recovery-queue show
This table is currently empty.

netapp95::*> 

消えたのでaggregateは復活したはず!!!

netapp95::*> df -A -h
Aggregate                total       used      avail capacity
<略>
aggr名                    29TB       18TB       11TB      61%
aggr名/.snapshot            0B         0B         0B       0%
<略>
netapp95::*>

あれ????

なぜだろー??

なぜだろー???としばらく検索してから、再度実行

netapp95::*> df -A -h
Aggregate                total       used      avail capacity
<略>
aggr名                    29TB       16TB       12TB      57%
aggr名/.snapshot            0B         0B         0B       0%
<略>
netapp95::*> 

おや?空き容量が少し増えてる?

「df -A」の実行に切り替えてみると、徐々に空き容量が増えていっていることが判明。

どうやら内部処理に時間がかかっているだけのようでした。