自作ルーターを作っていくのにR86S U1を買ったのもあり、遂にフレッツ光クロス、10Gbps対応に関する覚書で構想した10GbE LAN環境の構築を実行してみた。有線部分のみの対応で無線部分は放置している。
フレッツ光クロスとフレッツ光ネクスト隼のコスト比較をしてみた結果、クロスの導入コストが高すぎたのでLAN内だけ10GbE対応としている。そもそも出先から10GbE接続できるとは思えないのもあり、WANまで10GbE対応にする意味はNAS目的では薄そうだ。
恐らく現状で10G対応WANが活躍するシーンは、BitTorrentみたいに異なる相手から複数ストリームを並列でやり取りするみたいな用途くらいな気はする。
今回揃えたもの
| 分類 | 機器 | 詳細 | 参考価格 |
|---|---|---|---|
| スイッチ | MikroTik CRS305-1G-4S+IN | 10GBASE, SFP+ 4口, 1000BASE-T 1口 | 27,349円 |
| DACケーブル | 10Gtek CAB-10GSFP-P0.5M-30 | 10GBASE, CAT8, 0.5m Twinaxケーブル | 1,999円 |
| DACケーブル | 10Gtek CAB-10GSFP-P1M-30 | 10GBASE, CAT8, 1.0m Twinaxケーブル | 2,199円 |
| DACケーブル | 10Gtek CAB-10GSFP-P2M-30 | 10GBASE, CAT8, 2.0m Twinaxケーブル | 2,419円 |
| Windows用NIC | Mellanox ConnectX-4 Lx | PCIe3.0 x8, SFP28ポート * 2 | 3,359円 |
| Ubuntu用NIC | 同上 | 同上 | 同上 |
スイッチを除くと1GbE用の設備と比べてもそこまで高くない印象で、案外負担にならない印象だ。
特にMellanox ConnectX-4 Lxは中古が安く流通しているので、かなり助かる。このNICはQSFP対応の25GbE対応とオーバースペックだが、SFP28とSFP+には互換性があるため問題ない。
むしろSFP+対応で10GbEのX-3は最新のUbuntuに対応させるのに手間が掛かったり、Windows 11が起動しなくなるなどの問題があると聞くため、これが無難な選択肢だろう。しかし軽く見た感じボードメーカーの記載がなく、どこが作ったものなのかは不明だ。
価格的にも2ポートの方が1ポートより安いなど、SFP+対応NICはジャストスペックを狙うより、オーバースペックの方がコストを抑えられ、将来の拡張性も得られて嬉しいかもしれない。
なお、Windows側はx8に空きがなかったため、PCIe 4.0 x4に挿して使っており、Ubuntu側はCPUの制限によりPCIe 5.0 x16がPCIe 4.0 x4にダウングレードされたスロットを使っている。
リンク速度はWindowsはHWiNFOで確認した限り「バージョン: 3.0」「現在のリンク幅: x4」「現在のリンク速度: 8.0GT/s」で、Ubuntuはsudo lspci -vvで確認した限りSpeed 8GT/s, Width x4だった。これだけを見ると10Gbps出ない気もするが、実際のところはどうなのか、この後計測してゆく。
速度ベンチ
iperf3でWindowsとUbuntu間を計測した結果。
変更前(1GbE環境)
確認環境
NICやルーターは2.5GbEに対応しているが、1GbEスイッチを挟んでいる関係で1Gbpsが上限となる。接続はすべてCAT6のLANケーブル。
Windows→Ubuntu
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.01 sec 119 MBytes 981 Mbits/sec
[ 5] 1.01-2.01 sec 112 MBytes 949 Mbits/sec
[ 5] 2.01-3.00 sec 113 MBytes 950 Mbits/sec
[ 5] 3.00-4.00 sec 113 MBytes 949 Mbits/sec
[ 5] 4.00-5.01 sec 115 MBytes 950 Mbits/sec
[ 5] 5.01-6.01 sec 112 MBytes 949 Mbits/sec
[ 5] 6.01-7.00 sec 113 MBytes 949 Mbits/sec
[ 5] 7.00-8.02 sec 114 MBytes 950 Mbits/sec
[ 5] 8.02-9.01 sec 113 MBytes 949 Mbits/sec
[ 5] 9.01-10.01 sec 113 MBytes 950 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.01 sec 1.11 GBytes 953 Mbits/sec sender
[ 5] 0.00-10.03 sec 1.11 GBytes 949 Mbits/sec receiver
Ubuntu→Windows
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 115 MBytes 962 Mbits/sec 0 471 KBytes
[ 5] 1.00-2.00 sec 112 MBytes 938 Mbits/sec 0 494 KBytes
[ 5] 2.00-3.00 sec 112 MBytes 942 Mbits/sec 0 520 KBytes
[ 5] 3.00-4.00 sec 113 MBytes 946 Mbits/sec 0 549 KBytes
[ 5] 4.00-5.00 sec 112 MBytes 942 Mbits/sec 0 577 KBytes
[ 5] 5.00-6.00 sec 112 MBytes 938 Mbits/sec 0 577 KBytes
[ 5] 6.00-7.00 sec 113 MBytes 946 Mbits/sec 0 577 KBytes
[ 5] 7.00-8.00 sec 112 MBytes 939 Mbits/sec 0 577 KBytes
[ 5] 8.00-9.00 sec 113 MBytes 946 Mbits/sec 0 617 KBytes
[ 5] 9.00-10.00 sec 112 MBytes 942 Mbits/sec 0 646 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 1.10 GBytes 944 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 1.10 GBytes 941 Mbits/sec receiver
変更後(10GbE環境)
確認環境
Windows側はPCIe 4.0 x4、Ubuntu側は
1GbE環境とルーターが同じだが、これはR86Sが10GbEと2.5GbEの二種類のポートを持っているためだ。
R86SはSFP+ポートが10GbE、RJ45ポートが2.5GbE対応になっている。
Windowsにドライバ入れる前
Windows→Ubuntu
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.01 sec 1.08 GBytes 9.22 Gbits/sec
[ 5] 1.01-2.01 sec 1.10 GBytes 9.36 Gbits/sec
[ 5] 2.01-3.00 sec 1.08 GBytes 9.36 Gbits/sec
[ 5] 3.00-4.01 sec 1.09 GBytes 9.36 Gbits/sec
[ 5] 4.01-5.00 sec 1.08 GBytes 9.36 Gbits/sec
[ 5] 5.00-6.01 sec 1.10 GBytes 9.36 Gbits/sec
[ 5] 6.01-7.01 sec 1.10 GBytes 9.36 Gbits/sec
[ 5] 7.01-8.01 sec 1.08 GBytes 9.36 Gbits/sec
[ 5] 8.01-9.01 sec 1.10 GBytes 9.36 Gbits/sec
[ 5] 9.01-10.02 sec 1.09 GBytes 9.36 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.02 sec 10.9 GBytes 9.35 Gbits/sec sender
[ 5] 0.00-10.02 sec 10.9 GBytes 9.34 Gbits/sec receiver
Ubuntu→Windows
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 256 KBytes 2.09 Mbits/sec 2 1.41 KBytes
[ 5] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes
[ 5] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 5] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes
[ 5] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 5] 5.00-6.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 5] 6.00-7.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes
[ 5] 7.00-8.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 5] 8.00-9.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 5] 9.00-10.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 256 KBytes 210 Kbits/sec 5 sender
[ 5] 0.00-10.00 sec 0.00 Bytes 0.00 bits/sec receiver
Windowsにドライバ入れた後
Windows→Ubuntu
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.01 sec 1.11 GBytes 9.51 Gbits/sec
[ 5] 1.01-2.01 sec 1.11 GBytes 9.50 Gbits/sec
[ 5] 2.01-3.01 sec 1.10 GBytes 9.49 Gbits/sec
[ 5] 3.01-4.00 sec 1.10 GBytes 9.49 Gbits/sec
[ 5] 4.00-5.01 sec 1.11 GBytes 9.50 Gbits/sec
[ 5] 5.01-6.01 sec 1.11 GBytes 9.50 Gbits/sec
[ 5] 6.01-7.01 sec 1.11 GBytes 9.49 Gbits/sec
[ 5] 7.01-8.01 sec 1.10 GBytes 9.49 Gbits/sec
[ 5] 8.01-9.00 sec 1.10 GBytes 9.49 Gbits/sec
[ 5] 9.00-10.01 sec 1.11 GBytes 9.49 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.01 sec 11.1 GBytes 9.49 Gbits/sec sender
[ 5] 0.00-10.01 sec 11.1 GBytes 9.49 Gbits/sec receiver
Ubuntu→Windows
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 1.10 GBytes 9.43 Gbits/sec 0 1.33 MBytes
[ 5] 1.00-2.00 sec 1.10 GBytes 9.42 Gbits/sec 0 1.33 MBytes
[ 5] 2.00-3.00 sec 1.10 GBytes 9.42 Gbits/sec 0 1.33 MBytes
[ 5] 3.00-4.00 sec 1.09 GBytes 9.41 Gbits/sec 0 1.33 MBytes
[ 5] 4.00-5.00 sec 1.10 GBytes 9.42 Gbits/sec 0 1.54 MBytes
[ 5] 5.00-6.00 sec 1.10 GBytes 9.42 Gbits/sec 0 1.54 MBytes
[ 5] 6.00-7.00 sec 1.09 GBytes 9.41 Gbits/sec 0 1.54 MBytes
[ 5] 7.00-8.00 sec 1.10 GBytes 9.42 Gbits/sec 0 1.54 MBytes
[ 5] 8.00-9.00 sec 1.10 GBytes 9.41 Gbits/sec 0 1.54 MBytes
[ 5] 9.00-10.00 sec 1.10 GBytes 9.42 Gbits/sec 0 1.54 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 11.0 GBytes 9.42 Gbits/sec 0 sender
[ 5] 0.00-10.00 sec 11.0 GBytes 9.41 Gbits/sec receiver
まとめ
| 回線状況 | Windows→Ubuntu(上り) | Windows→Ubuntu(下り) | Ubuntu→Windows(上り) | Ubuntu→Windows(下り) |
|---|---|---|---|---|
| 1GbE | 953 Mbps | 949 Mbps | 944 Mbps | 941 Mbps |
| 10GbE(Windowsドライバなし) | 9.35 Gbps | 9.34 Gbps | 210 Kbps | 0 bps |
| 10GbE(Windowsドライバあり) | 9.49 Gbps | 9.49 Gbps | 9.42 Gbps | 9.41 Gbps |
Windowsにドライバがない状況だとiperf3では何故かまともに疎通できない状態だった。何故かは不明。SFTPを使ったファイル転送は出来たのでiperf3との相性が悪かった可能性もあるが、ドライバを入れて改善したところから、ドライバレスでは何かしら不都合がある可能性がある。
またWindowsよりUbuntuの方が若干速度が落ちる傾向があることも分かった。
やったこと
デフォルトではIB(InfiniBand)だからETH(Ethernet)にモード変更が必要というのをネットで見ていたが、私の場合そんなことはなかった。ひょっとしたら中古なので設定が書き換えられたままだったのかもしれない。
Ubuntu
Ubuntu 24.04.3 LTSではNICを挿すだけで動いたので特に何もしていない。デフォルトでETH動作だった。
Windows
こちらもデフォルトでETH動作で、挿すだけでも動いた。
しかしConnectX-4用のドライバを入れることで性能が改善した。具体的にはiperf3で受信速度が0bpsだったのが9.5Gbpsくらいになった。
開封の儀
NIC
メーカー不詳のMellanox ConnectX-4 Lxボードだ。PCIe3.0 x8でSFP28ポートが二つ付いている。
Windows用とUbuntu用で二つ買っている。2ポートあるのは2ポートの方が安かったから。
ヒートシンクが付いてたり、SFP+用の長いソケットがついていたり、放熱用なのか穴が開いていたり、中々厳つい。
SFP+対応NICはショートブラケットが多く、ロングブラケットがないという話も聞くが、安心のロングブラケット入りを買ったので、ロングブラケットがちゃんと付いていた。
中身を取り出したところ。
ショートブラケットとロングブラケットでネジが異なるのだが、ロングの用のネジもちゃんと付いていて嬉しかった。というのも、このボードは中古なので不必要なパーツは紛失していても不思議がないからだ。
NIC装着(Ubuntu)
このNICをあてがう為だけに存在するようなPCIeレーンを解き放つ時が来た。見た目はx16だが、CPUが貧弱なのでx4しか出せない。
差し込んでみると中々いい感じだ。
いつも思うのだが、PCIeカードの窪みはケーブルを通すためにあるのだろうか?私はよくケーブルを通すのに使っていて、この写真でもケーブルを通している。
SFP+ジャックがいい感じに光る見た目になった。
スイッチ
MikroTik CRS305-1G-4S+INという、Amazonで売られている10GbE対応SFP+ジャック付きのイーサネットスイッチだ。Cloud Switch seriesとあるので、データセンター向け製品なのかもしれない。そもそもSFP+端子そのものがコンシューマー向けではないというのもある気はするが…w
こちらは新品で、中には簡単なマニュアルと本体、ACアダプタが入っていた。
外観はこんな感じ。ファンレスでパンチホールが沢山空いている。特に発熱のあるSFP+周りに穴が多い。PoE給電にも対応しているようだが、我が家には対応設備がなかった。
背中にはアースとAC入力が二つあった。どうやら電源を多重化し、片方が死んでも死なないようにするための仕組みらしい。RTX830にはなかった気がするので、こちらの方がよりハイグレードな設計といえるだろう。
裏面には壁にぶら下げる穴みたいなのもあった。
側面にはインジゲーターがあり、疎通状況などが確認できる仕組みになっていた。いかにも熱くなりそうなマークも目を引くポイントだ。10GbEは発熱が凄いと聞くので、恐らくその関係だろう。
なお今のところそんなに熱くなってはいない。
起動するとめっちゃ青く光る。
SFP+DACケーブル(Twinaxケーブル)
10GtekのDACケーブル。両端がSFP+端子になっているものをTwinaxケーブルというらしい。
こんな感じの袋に入っている。
中身はこんな感じ。端子がごつく、中の基板がむき出しで見えるのが面白い。
因みにこれは30cmのケーブルで、ケーブル延長が30cmだと思ったら、端子部分まで含めて30cmだったので使い物にならなかったやつだ。短すぎるケーブルを買う場合は注意した方がいいだろう。
マシンに差し込んだところ。金属端子がカッコいい感じだ。
NIC装着(Windows)
まずは元々使っていた玄人志向 GBE2.5-PCIE(Realtek RTL8125BG)を抜く。これはマザボ側のインターフェースが不安定なので使っていたカードだ。WindowsとIntelのネットワークインターフェースはここ数年相性が最悪レベルなのが困りものだ。
次に今回買ったNICを挿す。買う前から解ってはいたが、見事にスロットからはみ出ている。
こちらは抜き取ったRJ45端子のNIC(2.5GbE)。
配線状況
大まかな外観はこんな感じになった。逸般の誤家庭には程遠いが、それっぽさはあり、個人的には満足している。
しかしR86Sのファンはお世辞にも長生きしそうにない上に、凄い勢いでファンに埃が詰まっていっているのもあり、このまま使っていくのならば、ちゃんとしたクーラーを用意した方がいい気配がしている。
配線状況を図にするとこんな感じ。WiFi APを2.5GbEや10GbEに対応させることも考えたが、SFP+に対応したものは巨大すぎるので置き場所に困るし、SFP+とRJ45の変換は端子が90度に達するとも聞くので、運用できる気がしない。2.5GbEに絞ってみても高い端末や、やけにでかい端末しか見つからなかったので諦めた。
特に関係ないが、おまけで物理ネットワーク全体と言う事で、現在のデスク風景も残しておく。
感想
機材コストはそこそこしたものの、思ったよりトラブルなく移行できたのは良かった。
PCIeのリンク速度が8GT/sだったため、10Gbps出るかどうか懐疑的だったが、実効速度としては9.5Gbps出ており、1Gbps時代も950Mbpsだったことを考えればフルで出ていると考えて支障ない数値だ。8GT/sとは一体何なのかという感じだが、深く考えないでおこう。
ファイル転送速度も爆発的に上がり、LAN内でNASを運用する場合にも支障がだいぶ減った。とはいえ、流石にローカルのNVMeと比較すると全然物足りない速度ではある。
ストレージ面ではSATA IIIの速度が6Gbpsであるため、10Gbpsになったことにより、LAN内でSATAを扱う場合に遅延が無くなったと言える。NVMeSSDは7GByte/sとかなので、全く足りないがSATAを扱う場合は十分な速度といえるだろう。NVMeSSDをネットワーク越しに扱う場合には100GbEクラスが必要になってくると思われるが、ここまで来るとHPC(High Performance Computing)クラスになると思われるので、流石にやりすぎだとは思う。
但し実現自体は不可能ではなさそうで、アリエクでは100GbE対応NICであるMellanox MCX455A-ECAT ConnectX-4 EDR+100GbEが1.3万程度で売られているし、10Gtekも4~5000円で100GBASEのDACを売っているので、その気になれば構築は不可能ではなさそうだ。但しスイッチはMikroTik CRS504-4XQ-INでは13万円ほどし、ルーターは見つけることが出来なかったので、100GBASE対応NICを挿した適当なマシンでルーターPCを組む必要があると思われる。
今回の対応ではルーターまでが10Gbpsとなったため、宅内にボトルネックが仮にあればWANの速度も増えるかと思ったが、そんなことはなく、普通に据え置きで終わった。正直平均以上出てるので、ないとは思っていたが、まぁ、そうだよねという…w
それはさておきとして、一旦機材面では整ってきたと思うので、次はネットワーク機器やサーバーの監視体制を整えていきたいところだ。
コネクタを傷めないための備忘録。
死ぬほど硬いのでなかなか抜けなかったり、挿したつもりが刺さっていなかったりする。
抜き方
普通は紐をまっすぐ引っ張れば抜けるが、どうしても抜けない場合にロックを外す方法。
こう刺さっている場合、手前の凹の出っ張り部分に爪楊枝を差し込み、てこの原理で持ち上げるとロックが外れるので、この状態で紐を真っすぐに引っ張る。
挿し方
まず刺さっているかどうかの確認方法。確認環境はUbuntu 24.04.3 LTS。
ethtool enp1s0f0np0の出力に以下の内容が含まれることを確認Speed: Unknown!
Duplex: Unknown! (255)
Link detected: no- 以下のコマンドでカーネルレベルで抜けていることを確認
sudo dmesg | grep -i 'mlx5' | grep -i 'Cable unplugged' - NICのコネクタのランプが点灯していなければ挿しなおす
Amazonや公式サイトにある情報が本当に正しいとは限らないので実地検分。
やり方
# これでCPUの情報が取れる
cat /proc/cpuinfo
# これでメモリの情報が取れる
opkg install dmidecode
dmidecode -t 17
# これでCPU, NICの情報が取れる
opkg install hwinfo
hwinfo
# これでeMMCのベンダ情報が取れる
cat /sys/class/mmc_host/mmc0/mmc0:0001/name
cat /sys/class/mmc_host/mmc0/mmc0:0001/manfid
調査ログ
CPU
cat /proc/cpuinfoの結果から取得した情報。
model name : Intel(R) Celeron(R) N5105 @ 2.00GHz
メモリ
dmidecode -t 17の結果から取得した情報。
MicronのLPDDR4でDDR4-3200相当であるとわかる。
Physical Memory Array
Location: System Board Or Motherboard
Use: System Memory
Error Correction Type: None
Maximum Capacity: 8 GB
Error Information Handle: Not Provided
Number Of Devices: 2Memory Device
Array Handle: 0x003A
Size: 4 GB
Form Factor: Row Of Chips
Locator: Controller0-ChannelA
Type: LPDDR4
Speed: 3200 MT/s
Manufacturer: Micron Technology
NIC(RJ45)
hwinfoの結果から取得した情報。
pci 0x125cはI226-VなのでIntel Ethernet controller I226-V
Hardware Class: network
Model: "Intel Ethernet controller"
Vendor: pci 0x8086 "Intel Corporation"
Device: pci 0x125c
SubVendor: pci 0x8086 "Intel Corporation"
SubDevice: pci 0x0000
Revision: 0x04
Driver: "igc"
Driver Modules: "igc"
Device File: eth2
NIC(SPF+)
以前分解したときのラベルと、hwinfoの結果から取得した以下の情報と突き合わせるとMellanox ConnectX-3 En10*2 Gigabit Ethernet CX341Aであることが分かる。
Hardware Class: network
Model: "Mellanox MT27500 Family [ConnectX-3]"
Vendor: pci 0x15b3 "Mellanox Technologies"
Device: pci 0x1003 "MT27500 Family [ConnectX-3]"
SubVendor: pci 0x15b3 "Mellanox Technologies"
SubDevice: pci 0x0113
Driver: "mlx4_core"
Driver Modules: "mlx4_core"
Device File: eth3
ストレージ(eMMC)
以下の結果から、name: SCA128, manfid: 0x0000dfであることから、メーカー不詳のSCA128という製品であることが分かる。ググってもメーカー情報は不明だった。
cat /sys/class/mmc_host/mmc0/mmc0:0001/name
cat /sys/class/mmc_host/mmc0/mmc0:0001/manfid
まとめ
公式サイト?の情報やAmazonの情報と比べると微妙に差異があり、また、書いてない情報も取れたので調べてよかったなと思った。
| 構成 | 製品 | 備考 |
|---|---|---|
| CPU | Intel Celeron N5105 | 6T6C, 2.00GHz, TDP10W |
| MEM | Micron | LPDDR4-3200 4GB * 2 |
| Storage | SCA128 | 128G EMMC |
| NIC | Intel Ethernet controller I226-V | RJ45 2.5GbE * 3 |
| NIC | Mellanox ConnectX-3 En10*2 Gigabit Ethernet CX341A | SPF+ 10GbE * 2 |
前回、OSインストールの記事を書いてから約四ヶ月、今回は実際にインターネットへの接続をやっていく。接続にはOCN バーチャルコネクトを利用する。
色々あって四ヶ月放置していたR86Sにはいい感じに埃が積もっていた。
確認環境
- R86S U1
- OpenWrt 24.10.0
- OCNバーチャルコネクト
手順
OSインストールが終わっているものとする。
また、この手順ではLANケーブル(RJ45)を使って進めている。
途中でインターネットを利用する場面が何度かあるため、キャリア回線でWWWに出られるスマホがあると便利だ。
R86Sに接続する
eth1にWAN, eth0にLANを接続する。
パッケージのインストール
SSHで192.168.1.1に接続し次のコマンドを流しパッケージをインストールする。
opkg update
opkg install luci
opkg install map
reboot
Web管理画面へのアクセス
http://192.168.1.1/にアクセスするとWeb管理画面が開くので、ここから設定をしていく。
設定情報の取得
管理画面上部のNetworkからInterfacesを開き、wan6のIPv6にある先頭4セクションを控え、http://ipv4.web.fc2.com/map-e.htmlを開き入力、計算する。出力されたoption始まりの行の内容をすべて控えておく。
wan6のIPv6にある先頭4セクション(aaaa:bbbb:cccc:dddd)とoptionの値は後で使うので全部控えておく。
WAN側IPv6のDHCP(DHCPv6 client)の設定
wan6のEditボタンを押す。
DHCP Serverタブを開き、「Set up DHCP Server」ボタンを押す。
IPv6 Settingsタブを開きRA-Service、DHCPv6-Service、NDP-Proxyをrelay modeに変更し、保存する。
LAN側IPv6のDHCPの設定
先ほどと同様にDHCP Serverタブ→IPv6 Settingsタブと開き、RA-Service、DHCPv6-Service、NDP-Proxyをrelay modeに変更し、保存する。
ルータ広告用のインターフェースの作成
画面左下にある「Add new interface...」ボタンを押し、以下の要領で選択し作成する。ルーター広告はIPv6のRouter Advertisementのことなのでインターフェース名をwan6raとしている。
| 項目 | 値 |
|---|---|
| Name | wan6ra |
| Protocol | Static address |
| Device | Alias Interface: "@wan6" |
Deviceは項目選択後は画像のように@wan6表記になる。
ルータ広告用のインターフェースの設定
ここでは控えておいたwan6のIPv6にある先頭4セクション(aaaa:bbbb:cccc:dddd)を利用する。
wan6raインターフェースのEditボタンを押し、General Settingsタブにある項目を次の要領で設定する。
| 項目 | 値 |
|---|---|
| IPv6 address | aaaa:bbbb:cccc:dddd::1001 |
| IPv6 gateway | aaaa:bbbb:cccc:dddd::1 |
| IPv6 routed prefix | aaaa:bbbb:cccc:dddd::/56 |
各設定項目に応じて、先頭4セクションの後ろに::1001、::1、::/56を追記するイメージ。
疎通確認
Save&Applyを押し、以下のサイトが開けることを確認する。
この段階ではIPv6にしか繋がらないため、続けてIPv4向けの設定をしてゆく。
MAP-E用インターフェースの作成
次の要領でインターフェースを作成する。
| 項目 | 値 |
|---|---|
| Name | wanmap |
| Protocol | MAP / LW4over6 |
MAP-E用インターフェースの設定
ここでは控えておいたoption始まりの行の内容を利用する。
wanmapインターフェースのEditボタンを押し、General Settingsタブにある項目を次の要領で設定する。
| 項目 | 値 |
|---|---|
| Type | MAP-E |
| BR / DMR / AFTR | option peeraddrの値 |
| IPv4 prefix | option ipaddrの値 |
| IPv4 prefix length | option ip4prefixlenの値 |
| IPv6 prefix | option ip6prefixの値 |
| IPv6 prefix length | option ip6prefixlenの値 |
| EA-bits length | option ealenの値 |
| PSID-bits length | option psidlenの値 |
| PSID offset | option offsetの値 |
Advanced Settingsタブを開き「Use legacy MAP」にチェックを入れ、保存する。
Firewallの設定
SSHで192.168.1.1に接続し/etc/config/firewallを開く。
config zone
option name 'wan'
...
list network 'wan'
list network 'wan6'
となっている箇所の末尾に以下を追記し保存。rebootコマンドで再起動する。
list network 'wan6ra'
list network 'wanmap'
ルーター再起動後、http://wa.kiriwake.jpne.co.jp/に接続し、判定ボタンを押し、試験1~4と、契約中のフレッツ東西の光がOKになっていれば疎通は問題ないと思われる。
後は適当に幾つかサイトを開いたりfast.comで回線速度を見て疎通確認を実施した。
ストレージの拡張(2025/08/26追記)
イメージを焼いた関係で、初期パーティションが狭い。R86S U1のeMMCは128GBもあるので、これを拡張する。
- GPartedのサイトからイメージを落とし、最新のRufusで適当なメディアにイメージを焼く。
- GPartedを焼いたメディアをR86Sに接続
- R86Sを起動しDeleteボタン連打でBIOSに入る
- Boot OptionでGPartedの起動順位をトップにする

- 再起動し一番上のGParted Live(Default settings)で起動

- 起動するとGPartedの画面が出ているのでパーティションを最大まで広げる
やり終えてから思ったが、OpenWrtインストール時に使ったUbuntuServerにpartedくらい入ってるだろうし、それでやってもよかったかもと思った。
発生したトラブル
192.168.1.1に繋がらない
eth0にLANを接続する事で繋がる。初期設定ではeth0がブリッジ、eth1がWAN、eth2は未設定。
ポート不足?(ニチバン問題?)(未解決)
ニチバン問題と同じものかはわからないがコネクションが225を超えた付近で通信が詰まる傾向があった。このため、Configuring OpenWrt to work with Japan NTT IPv6 (MAP-E) serviceのADVANCED CUSTOM CONFIGURATIONを利用し解決を試みたが、たぶん特に意味はなかった。
以下のコマンドを流すことで導入できた。
cd /lib/netifd/proto
mv map.sh map.sh.orig
wget -O map.sh https://raw.githubusercontent.com/fakemanhk/openwrt-jp-ipoe/refs/heads/main/map.sh.new
reboot
ひとまず変更して、意図的に大量のサイトを開いた状態がこちら。一見解消しているように見えるが、人為的にやった結果なので同等の結果かどうかは怪しい。
また一気に大量のサイトを開きまくると、流石に若干詰まりが見られたが、詰まっていた時はルーターさえ疎通しなかったので、単にOSのポートを食いつぶしていただけという可能性もある。
参考までに元のmap.shに戻して同じ操作をしてみたところ、ちゃんとコネクションが張れたので関係なさそう。
以前と比べてネットワーク構成が変わっており、Buffaloのルーターをスイッチングハブとして使っている影響などが関係しているかもしれないので、しばし静観の方向で…。
ルーター起動後、Windowsでネットワークアダプタが認識中のままになる、インターネットに繋がらない
電源投入からOCNバーチャルコネクトのリンクアップまで20~50秒ほどかかるので気長に待つ。
LAN側IPv6のDHCPの設定でDHCPv6-Serviceの値はrelay modeかserver modeか?
OpenWrtではDHCPv6の運用が難しいため、基本的にrelay modeでよいと思う。
おまけ
eth0をWAN、eth1をLANにする方法
- NetworkからInterfacesを開く
- wanとwan6のDeviceをeth0に変更
- Devicesタブに切り替る
- br-lanの「Configure…」ボタンを押す
- General device optionsのBridge portsをeth1にして保存
- Save & Applyを押す
CPU温度を見る方法
luci-app-temp-statusをインストールする。
2025年8月4日時点では以下のコマンドでインストールできる。
wget --no-check-certificate -O /tmp/luci-app-temp-status_0.7.1-r2_all.ipk https://github.com/gSpotx2f/packages-openwrt/raw/master/current/luci-app-temp-status_0.7.1-r2_all.ipk
opkg install /tmp/luci-app-temp-status_0.7.1-r2_all.ipk
rm /tmp/luci-app-temp-status_0.7.1-r2_all.ipk
service rpcd restart
インストールが終わるとトップ画面にTemperatureが出てくるほか、Status→Realtime GraphsにもTemperatureが出てくるようになる。
セットアップが完了したR86Sの姿
まぁまぁいい塩梅だと思う。
撤去されたYAMAHA RTX830
R86S + OpenWrtを導入するまで使っていたRTX830。価格の割にIPv6向けの機能が貧弱だったり、設定が手間だったり、マニュアルが雑目だったり、あまりいい思い入れはなかった。
OCNバーチャルコネクトの接続がBuffaloルーターより早く安定している点と、LAN向けのDNSがあるのは便利だったが、あの読みづらいマニュアルはもう少し何とかした方がよいと思う。
今回セットアップした感想
今のところ予想以上にトラブルや問題がなく、平然と動いているため、かなり満足している。
RTX830との比較
管理画面の操作性や充実度はRTX830を遥かに超えており、非常に体験がよかった。
設定変更についてもSave & Applyを押すまでは保留状態になるため、間違った設定が即座に反映されないのもよい。
しかもPending changesをクリックすると設定ファイルに対する差分も確認でき、大変便利だ。
電源投入からOCNバーチャルコネクトへのリンクアップまでの時間も体感RTX830と大差なく、Buffaloルーターのように接続ネゴシエーションの成功を祈っていたら1~2時間経過していたみたいなこともないのは素直にうれしい。fast.comで計測した限りでは速度やレイテンシの劣化もなく大変満足している。
DHCP設定の静的リースのUIが便利すぎる
Network→DHCP and DNS→Static Leasesから現在繋いでいる機器が見れるのがありがたいし、リース情報もわかりやすい。
しかも静的リースを行うときにOpenWrtが把握しているMACアドレスとドメイン名の一覧が出てくるので、手打ちしたり、確認する手間が省けるのも便利だ。リース時間も設定できるし、至れり尽くせりである。
ちょっとうるさい
唯一残念なところを挙げるとするとファンが微妙にうるさく、2mの距離があってもモスキート音レベルのささやかな動作音が聞こえる部分だ。これは慣れれば気にならなくなると思いたい。今の時期だとエアコンの音にかき消されてほぼ聞こえないが、それでも寝る前だと個人的には若干気にならなくもない程度だ。薄型のシロッコファンゆえにNoctuaのファンに変えるのも難しく、正直解決策としては物理的に遠くするか、間に何か防音材を放熱の邪魔にならないように挟むくらいしかないだろう。一応メーカー的には静穏ファンとのこともあり、大半の人は気にならないとは思う。
Banana Pi BPI-R4にもSPF+が2つあり、RJ45ソケットもあり、2.5万程度と安価なため、冷却装置をDIYして静穏化する場合はこちらの方が向いている可能性がある。実際にやってる人もいる。
ただまぁスペックはR86Sの方が上等なので、安く静かで多くを求めず、多少大きくてもいいならBanana Pi BPI-R4、多少の騒音を許容でき、スペックが欲しい場合はR86Sというのもありだろう。一般家庭のルーターに、そこまでスペック要るのかどうかというのはさておき…。
微妙なスイッチングハブの使用による性能劣化
今回ルーター側のポート数の制約により、ルーター直結でなくスイッチングハブを通してWWWに接続している。使えるものがBuffaloのWiFiルーターのAPモード(スイッチングハブとして機能する)しかなかったので、これを使っているが、直結と比べた場合にあからさまな性能劣化が見られた。以下は数回計測した上での平均値。小数点以下は切り捨て。
直結時
| 下り速度 | 上り速度 | アンロードレイテンシ | ロード済みレイテンシ |
|---|---|---|---|
| 435Mbps | 430Mbps | 4ms | 5ms |
Buffalo経由時
| 下り速度 | 上り速度 | アンロードレイテンシ | ロード済みレイテンシ |
|---|---|---|---|
| 357Mbps | 422Mbps | 5ms | 13ms |
上りは誤差だが、下りが78Mbps低く、ロード済みレイテンシも倍以上の差が出ている。MMOを辞めた今となっては問題ないとはいえ、なんとも微妙だ…。
ただまぁ、将来的には10GbEスイッチを購入する予定であるため、恐らくソフトウェア的な制御によって起きているであろうこの問題は、いずれ解消するとは思う。
次の作業に向けて
設定のカスタマイズなどを通してよりよい環境にしていき、IP変動環境でIPv6を利用した自宅サーバーの公開や、10GbEの導入などに向けて挑戦していきたいところだ。




















































