11
09
2025
FLET’S光クロスを試してみる
とりあえずFLET’S光クロスを導入してみることにした
NURO光（マンションタイプ）の現状
ここ24時間/１週間のNURO側の対抗ルータへのPINGレスポンスグラフ
上記のsmokepingのグラフはNURO側の対向ルータへ向けたPINGレスポンスを示しているが、時間帯によっては結構な遅延が発生していることがうかがえる．やはりユーザの増加にNURO側の設備が追いついていないのだろう．
NURO光の2Gサービスが従来のIPv4/IPv6デュアルスタック方式からMAP-E方式に切り替えが進んでいる旨の記事を書いたが、現時点では我が家のNURO光の2GサービスはIPv4/IPv6デュアルスタックのままだ．
勿論、NURO側によってMAP-E方式に強制的に切り替えられてしまったら速攻で解約して、FLET’S系のサービスへ切り替える予定だ．その時のための準備という訳ではないが、以前引いていたFLET’S光回線を予め復活させておくことにした．
私の家のNURO環境が未だにMAP-E方式へ切り替えが行われていないのは、恐らく現時点で導入されているGPON-ONU（ルータ）がZTEのF660Aなので、ファームウェアの強制書き換えによるMAP-E方式へ切り替えに何らかの問題を抱えているのではないかと思う．
ZTEのF660PタイプのGPON-ONUが支給されている人たちはMAP-E方式になっているので、F660Aを使っているユーザはこのままF660Aを使い続ける方が得策だ．デュアルスタックを使い続けたい場合は間違っても別なGPON-ONUへの交換を依頼しないこと．強制的にMAP-E方式に切り替えられてしまうだろう．
とは言え、導入当初は快適だったNURO光もユーザ数の増加により、日に日に利用環境が悪化してきているので、乗り換えを検討しなくてはならない．我が家のエリアではNURO光の10Gサービスも利用可能なのだが、10Gサービスへ切り替えてしまうと有無を言わさずMAP-E方式になってしまう．
結局、FLET’S系のサービスしか選択肢がないのだが、折角なのでNTT東西連合が積極的に推進している10G系のアクセス回線であるFLET’S光クロスとやらを試して見ることにした．
今回はコラボレーションサービスでFLET’S光クロスを申し込むことにした
今回FLET’S光クロスを導入するにあたり、NTTに直接申し込んで自分でプロバイダ（VNE）事業者と契約するか、プロバイダとFLET’Sサービスがパックになったコラボレーションサービスを選ぶ場合とで色々と比較検討してみたが、やはりNTTに直接申し込むと割高なので、今回はFLET’S光クロス最安をうたっている、enひかりさんのサービスを申し込むことにした．
enひかりさんに決めたのにはもう一つ理由があって、オプションサービスの『enひかり電気』を利用したかったからだ．契約アンペアに応じた基本料金が発生しないことと、使用した電力量に単純比例したシンプルな料金体系で、25.3円/kWh（+再生可能エネルギ発電促進付加金 3.98円/kWh）というかなり割安な料金だ．東電などのように沢山電力を消費する奴にはペナルティーとして高額な料金を奪い取るというような腹立たしい料金体系ではないのが良い．
enひかりクロスサービスはFLET’S光クロス回線とプロバイダサービス（VNE事業者が提供するIPoEサービス）がセットになっており、VNE事業者としてJPIX（MAP-E：v6プラス）、アルテリアネットワークスのXpass（DS-Lite）を組み合わせることができ、どちらも固定IPv4アドレス（x1) のオプションサービスを選ぶことが可能だ．
FLET’S光クロス回線のみのサービスもあり、この場合はユーザ側でIPoE方式のVNEプロバイダサービスを別途契約する必要があるが、OCNのバーチャルコネクトや複数個の固定IPv4サービスなどを組み合わせることが可能だ．この場合のenひかりクロスサービスの料金は4,370円/月なので、NTTに直接申し込む場合の6,050円/月に較べるとかなり安い．
とりあえずXpass（固定IP）プランにしてみたけど．．．
今回はアルテリアのXpass（固定IP）プランでenひかりクロスを申し込んだ．NTTのフレッツ回線は以前使用していたので、棟内のスプリッターから宅内まではそのままインドア光ファイバケーブルがつながっているので、派遣工事なしの事前にONUだけを送付して貰うという形で問題なくフレッツ回線が開通した．
FLET’S光クロス回線では 光電話契約の有無にかかわらず56bit長のprefixがユーザに配布され、IPv6アドレスはDHCPv6-PD によるの割り当てとなる．最初はFLET’S網内だけの56bit長のprefix(2408: … ::/56) が割り当てられていたが、Xpassが開通した時点でアルテリアネットワークスのprefix(2001: … ::/56）に切り替わった．
10Gに対応したメーカー製ルータの手持ちが無かったので、とりあえず以前に1Gのフレッツ回線で利用していたNECのIX-2215が余っていたので、動作検証用としてXpassの固定IPの設定を入れて試して見ることにした．
NECのホームページの設定例『クロスパス（Xpass） 「固定IPサービス」 設定ガイド』を参考にコンフィグを流し込むが、以前のTransixの固定IPを利用して居たときのコンフィグをベースに、Xpassのアップデートサーバ廻りだけを手直しして接続してみた．
Xpassのアップデートサーバ廻りの設定は、Transixのアップデートサーバよりは設定項目が多いが、アップデートサーバへ当方のIPv6のトンネル終端情報を正確に伝えるという基本的な部分は同じだ．以前、Transixの固定IP設定でトラブルが発生した場合は、IPv6のトンネル終端アドレスの制限があり、この制限によって上手くIPv6トンネルが張れなかった（参考記事『InterlinkのZOOT NATIVE サービスがTransix 固定IPv4 方式に対応』）が、トンネル終端アドレスをTransix側の仕様？に合わせることで解決することができた．
IX-2215でXpass固定IP接続に問題発生
Xpassの固定IP用の設定を行い動作確認を行ってみたが、固定IP用のIPv6トンネルは問題なく通じているようだが、中のIPv4トンネルが通信できていない状態だ．現時点ではまだ原因の特定が出来ていないが、Xpassの固定IP接続は、Transixの固定IP接続よりも設定条件がシビアなのかもしれない．
とりあえず、現状の固定IP用トンネルの状況を表示して置くことにする．コンフィグの主要部分とIPv6アドレスの割り当て状況、DDNSアップデート、IPv6トンネルの状況を下記に示す．
[ IX-2215のコンフィグの主要部分の抜粋 ]
...
ipv6 dhcp client-profile dhcpv6pd-client
option-request dns-servers
option-request ntp-servers
ia-pd subscriber GigaEthernet2:1.1 ::c8:0:0:0:fe/64 <=== 共有AFTR IPv4セグメント
ia-pd subscriber GigaEthernet2:1.2 ::c9:0:0:0:fe/64 <=== 固定IPv4セグメント
ia-pd subscriber GigaEthernet2:1.3 ::ca:0:0:0:fe/64
!
ddns profile ddns-xpass-profile
url https://zzzzzzzzz.yyyy.vbbnet.jp/cgi-bin/ddns_api.cgi
query d=xxxxxxxx.v4v6.xpass.jp&p=DDNS-PASSWORD&a=&u=xxxxxxxx.v4v6.xpass.jp
account BASIC-AUTH-ID
password plain BASIC-AUTH-PASSWORD
transport ipv6
notify-interface GigaEthernet2:1.2
source-interface GigaEthernet2:1.2
update-interval 10
!
interface GigaEthernet2:1.1
description XPass-Shared-AFTR
encapsulation dot1q 200 tpid 8100
auto-connect
ip address 172.25.200.254/24
ip dhcp binding vlan200profile
ipv6 enable
ipv6 dhcp server dhcpv6pd-sv200
ipv6 nd ra enable
ipv6 nd ra other-config-flag
no shutdown
!
interface GigaEthernet2:1.2
description XPass-Fixed-IPv4
encapsulation dot1q 201 tpid 8100
auto-connect
ip address 172.25.201.254/32
ip dhcp binding vlan201profile
ip policy route-map rtmap-fixed
ipv6 enable
ipv6 dhcp server dhcpv6pd-sv201
ipv6 nd ra enable
ipv6 nd ra other-config-flag
no shutdown
!
...
interface Tunnel0.0
description Arteria XPass AFTR
tunnel mode 4-over-6
tunnel destination fqdn dgw.xpass.jp
tunnel source GigaEthernet2:1.1
ip unnumbered GigaEthernet2:1.1
ip tcp adjust-mss auto
no shutdown
!
interface Tunnel1.0
description Arteria IPoE Fixed IP
tunnel mode 4-over-6
tunnel destination XPAASS-IPV6-TUNNEL-ADDRESS
tunnel source GigaEthernet2:1.2
ip address FIXED-IPV4-ADDRESS/32
ip tcp adjust-mss auto
ip napt enable
ip napt service sslvpn 172.25.199.1 none tcp ppppp
no shutdown
!
interface Tunnel2.0
description Private-Tunnel-to-USGW
tunnel mode 4-over-6
tunnel adjust-mtu 1400
tunnel destination 2001:xxxx:yyyy:zzzz:aaaa:bbbb:febd:dddd
tunnel source GigaEthernet2:1.3
ip address 192.0.0.10/30
ip tcp adjust-mss auto
ip napt enable
no shutdown
!
...
[ IPv6アドレスの割り当て状況 ]
ix2215-01(config)# show ipv6 addr
Interface GigaEthernet0.0 is up, line protocol is up
Global address(es):
2001:xxx:yyyy:zz00:: prefixlen 56 anycast
Link-local address(es):
fe80::260:b9ff:fee2:4624 prefixlen 64
fe80:: prefixlen 64 anycast
...
Interface GigaEthernet2:1.1 is up, line protocol is up
Global address(es):
2001:xxx:yyyy:zzc8::fe prefixlen 64
Valid lifetime 8530, preferred lifetime 6730
2001:xxx:yyyy:zzc8:: prefixlen 64 anycast
Link-local address(es):
fe80::26a:fbff:fee2:4624 prefixlen 64
fe80:: prefixlen 64 anycast
...
Interface GigaEthernet2:1.2 is up, line protocol is up
Global address(es):
2001:xxx:yyyy:zzc9::fe prefixlen 64
Valid lifetime 8524, preferred lifetime 6724
2001:xxx:yyyy:zzc9:: prefixlen 64 anycast
Link-local address(es):
fe80::26b:fbff:fee2:4624 prefixlen 64
fe80:: prefixlen 64 anycast
...
Interface GigaEthernet2:1.3 is up, line protocol is up
Global address(es):
2001:xxx:yyyy:zzca::fe prefixlen 64
2001:xxx:yyyy:zzca:: prefixlen 64 anycast
Link-local address(es):
fe80::26c:fdff:fee2:4624 prefixlen 64
fe80:: prefixlen 64 anycast
...
ix2215-01(config)#
...
[ DDNSによるIPv6アドレス情報の通知ステータス ]
ix2215-01(config)# show ddns
profile-name : ddns-xpass-profile
Registered time : 2025/11/03 13:32:50
IPv6 address : 2001:xxx:yyyy:zzc9::fe
result
HTTP/1.1 200 OK
Date: Mon, 03 Nov 2025 04:32:52 GMT
Server: Apache
X-Frame-Options: DENY
Content-Length: 424
Connection: close
Content-Type: text/html
Content-Language: ja
<HTML><BODY>
<H1>DDNS API</H1><HR>
<H2>* Query parameter check : OK</H2>
FQDN=xxxxxxxx.v4v6.xpass.jp<BR>
Password=DDNS-PASSWORD<BR>
IPv6=2001:xxx:yyyy:zzc9::fe<BR>
UID=xxxxxxxx.v4v6.xpass.jp<BR>
Address=2001:xxx:yyyy:zzc9::fe<BR>
<H2>* routerinfo check : OK</H2>
<H2>* records check : OK</H2>
<H2>* routerinfo update : OK</H2>
<H2>* records update : OK</H2>
<H2>* DDNS API update : Success [2025-11-03 13:32:52 1762144372]</H2>
</BODY></HTML>
ix2215-01(config)#
...
[ IX-2215側のトンネルインタフェース(Tunnel1.0) の状態 ]
ix2215-01(config)# show int Tunnel1.0 detail
Interface Tunnel1.0 is up
Description: Arteria IPoE Fixed IP
Fundamental MTU is 1460 octets
Current bandwidth 1G b/s, QoS is disabled
Datalink header cache type is ipv6-tunnel: 0/0 (standby/dynamic)
IPv4 subsystem connected, physical layer is up, 1:34:40
Dialer auto-connect is enabled
Inbound call is enabled
Outbound call is enabled
Dial on demand restraint is disabled, 0 disconnect
SNMP MIB-2:
ifIndex is 1206
Logical INTERFACE:
Elapsed time after clear counters 4:18:36
2600 packets input, 415459 bytes, 0 errors
2600 unicasts, 0 non-unicasts, 0 unknown protos
0 drops, 0 misc errors
897 output requests, 174967 bytes, 0 errors
897 unicasts, 0 non-unicasts
0 overflows, 0 neighbor unreachable, 0 misc errors
2 link-up detected, 1 link-down detected
Encapsulation TUNNEL:
Tunnel mode is 4-over-6
Tunnel is ready
Destination address is XPAASS-IPV6-TUNNEL-ADDRESS
Source address is 2001:xxx:yyyy:zzc9::fe
Source interface GigaEthernet2:1.2
Nexthop address is fe80::d677:98ff:fe1c:6f53
Outgoing interface is GigaEthernet0.0
Interface MTU is 1460
Path MTU is 1500
Statistics:
2601 packets input, 415545 bytes, 0 errors
897 packets output, 174967 bytes, 0 errors
Received ICMP messages:
0 errors
0 no route to destination
0 administratively prohibited
0 beyond scope of source address
0 address unreachable
0 port unreachable
0 packet too big
0 hop limit exceeded in transit
0 parameter problem
...
[ IX-2215側からXpassのIPv6トンネル終端への疎通確認 ]
ix2215-01(config)# ping6 XPAASS-IPV6-TUNNEL-ADDRESS
PING 2001:xxx:yyyy:zzc8::fe > XPAASS-IPV6-TUNNEL-ADDRESS 56 data bytes
64 bytes from XPAASS-IPV6-TUNNEL-ADDRESS icmp_seq=0 hlim=57 time=3.977 ms
64 bytes from XPAASS-IPV6-TUNNEL-ADDRESS icmp_seq=1 hlim=57 time=4.075 ms
64 bytes from XPAASS-IPV6-TUNNEL-ADDRESS icmp_seq=2 hlim=57 time=3.874 ms
--- XPAASS-IPV6-TUNNEL-ADDRESS ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip (ms) min/avg/max = 3.874/4.058/4.257
ix2215-01(config)#
[ 外部のNWからIX-2215側のIPv6トンネル終端への疎通確認 ]
yasuaki@Mac-mini ~ % ping6 2001:xxx:yyyy:zzc9::fe
PING6(56=40+8+8 bytes) 240d:aaaa:bbbb:ccxx:9131:8df:b5:76c8 --> 2001:xxx:yyyy:zzc9::fe
16 bytes from 2001:xxx:yyyy:zzc9::fe, icmp_seq=0 hlim=51 time=7.888 ms
16 bytes from 2001:xxx:yyyy:zzc9::fe, icmp_seq=1 hlim=51 time=8.242 ms
16 bytes from 2001:xxx:yyyy:zzc9::fe, icmp_seq=2 hlim=51 time=7.843 ms
^C
--- 2001:xxx:yyyy:zzc9::fe ping6 statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 7.843/7.991/8.242/0.178 ms
yasuaki@Mac-mini ~ %
[ 外部のNWからIX-2215側のグローバルIPv4アドレスへの疎通確認 ]
yasuaki@Mac-mini ~ % ping FIXED-IPV4-ADDRESS
PING FIXED-IPV4-ADDRESS (FIXED-IPV4-ADDRESS): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
^C
--- FIXED-IPV4-ADDRESS ping statistics ---
4 packets transmitted, 0 packets received, 100.0% packet loss
yasuaki@Mac-mini ~ %
上記の結果を要約すると、
IPv6のアドレス配布情報： 想定通り
DDNSアップデートサーバへのIPv6アドレス通知 : 想定通り
IPv6トンネル終端へのIPv6による通信： 想定通り
IPv6トンネル内のIPv4通信： × （通信できていない）
固定IPセグメント(VLAN201) クライアントから外部へのIPv6通信 : 想定通り
ちなみに、DS-Lite(AFTR)による共有IPセグメント(VLAN200）の通信は正常に行えており、プライベートのIPv4 over IPv6 トンネル(Tunnel2.0）も問題なく稼働している．固定IPv4アドレスでの通信が、IX-2215側とXpass側とのルータの間で通信ができていないようだ．
念のため．NECのホームページに記載されている、Xpassの固定IPの設定例『クロスパス（Xpass） 「固定IPサービス」 設定ガイド』をそのまま IX-2215 に投入してみたが、固定IPv4アドレスでの接続はできたので今回の設定で問題となる箇所の特定するのはもう少し時間が掛かりそうだ．
YAMAHA NVR510 でも試してみることにする
NEC のIX-2215 で固定IPでの通信が上手く行かない問題はまだ解決できていないが、問題の切り分けのため、手持ちの使っていないなYAMAHA NVR510ルータを用いて シンプルな設定のXpass（固定IP）を行って検証してみた．
NVR510ではXpassの固定IP接続は問題なく行えている
YAMAHAのホームページにある参考コンフィグ『【設定例4：固定IP1契約 DHCPv6-PD】』を少し手直しして、NVR510に投入してテストしてみると、とりあえずIPv4の通信は固定IPアドレス経由で通信できていることが確認された．どうやらXpass側の問題というよりも、IX-2215側の設定内容やお互いのプロトコルの相性？の問題かもしれない．
今回の検証で用いた NVR510ルータの コンフィグデータは “NVR510-XpassFixedIPv4-sample.txt” に置いてある．
このコンフィグ内容を確認しれ貰えれば直ぐに判ることだが、YAMAHAのNVRやRTX系のルータではIPoE系の固定IPアドレスサービスの設定を行うのは大変骨の折れる設定を行わなければならない．
以前にも指摘したが、DDNSの実装がYAMAHAのネットボランチというYAMAHA独自のサービス向けに実装されているため、今回のようなIPoE系のDDNSサーバと通信を行うためには、わざわざそれ専用のLuaスクリプトをユーザが独自に実装しなければならない．
仕事先では YAMAHAのRTX1200シリーズやRTX1300シリーズを導入しているが、私がIPoE系のサービスでYAMAHAのRTXシリーズを避けているのはこのような面倒で複雑な設定を行いたくないからだ．
このLuaスクリプトでは、SYSLOG出力に吐き出されたメッセージを監視して当方のIPv6トンネルのアドレス情報をXpass側のDDNSサーバへ通知を行っている．ちなみに起動時に吐き出されるSYSLOGメッセージはこんな感じだ．
2025/11/09 10:32:40: Restart by restart command
2025/11/09 10:32:40: NVR510 Rev.15.01.26 (Fri Aug 23 10:36:30 2024) starts
2025/11/09 10:32:40: main: NVR510 ver=00 serial=M4.....1 MAC-Address=ac:44:xx:yy:zz:00 MAC-Address=ac:44:xx:yy:zz:01
2025/11/09 10:32:43: [SCHEDULE] Startup: lua emfs:/xpass_pd.lua
2025/11/09 10:32:43: [DHCPD] LAN1(port4) Allocates 172.25.200.101: 00:aa:bb:cc:dd:0c
2025/11/09 10:32:45: Add IPv6 prefix 2001:xxxx:yyy:zz00::/64 (Lifetime: 14400) via LAN1 by DHCPv6
2025/11/09 10:32:47: [Xpass] An update request message was sent to the DDNS update server. (IPv6 Addrress : 2001:xxxx:yyyy:zz00::1)
2025/11/09 10:32:47: [Xpass] Update succeeded. (result code : 200)
2025/11/09 10:33:50: Login succeeded for Serial
2025/11/09 10:33:56: 'administrator' succeeded for Serial
2025/11/09 10:35:01: Login succeeded for HTTP: 172.25.200.101
2025/11/09 10:35:01: 'administrator' succeeded for HTTP: 172.25.200.101
上記のコンフィグでは当方のルータ側のIPv6トンネルアドレスが 2001:xxxx:yyyy:zz00::1/64 となっているので、IX-2215側のIPv6トンネルアドレスを同様に2001:xxxx:yyyy:zz00::1/64に設定して試して見たが、結果は変わらずにIPv4固定IPアドレスでの通信はできないままだった．
FLET’Sクロス回線のスピードはどの程度出るのだろう？
FLET’Sクロス回線を導入する目的の一つとして、これまでのインターネット回線よりも格段にスピードアップしたインテーネット接続環境を手に入れたいという人が殆どだろう．私の場合は、スピードアップよりも安定していてかつ柔軟な運用が可能なインターネット環境を手に入れることが目的なので、別にFLET’Sクロス回線でなくても十分なのだが、今回は技術的な面からFLET’Sクロス回線の状況が知りたかったので、敢えてFLET’Sクロス回線を導入してみた．
手持ちのメーカー製10Gルータは近々導入する予定（Forigate 100FかIX-3315：勿論中古品しか買えない）だが、IX-2215やNVR510などのインタフェースが1Gbps系のルータではインタフェーススピードと同程度のスピードが出ていたので、10Gインタフェースに切り替えることができれば数Gbps程度のスピードは確保できるだろう．
以前、FLET’Sクロス回線を導入する際の検証用に 10Gインタフェースを有するBnananaPi R4を購入していたが、BnananaPi R4にOpenWRTを載せて、10G環境での簡易スピード測定を行ってみた．
Banana Pi R4 とOpenWRTの組み合わせで簡易スピードテストを実施してみる
OpenWrtの10G SFP+ インタフェースを使ってスピード測定を行う
OpenWRTの設定に関してはまだ経験が浅いので、Xpass固定IP接続の設定はまだ未完成の中途半端な状態ではあるが、とりあえずIPv6系の通信は問題なく通信出来ているので、IPv6 Native での通信で、簡易スピード測定サイトとの間で通信速度を測ってみることにする．
測定した時間帯は、土曜日の午後8時前後なのでインターネットは結構混雑している時間帯なのでスピード測定を行うには不利なのだが、物理インタフェースの速度を10Gbpsにすると、数Gbps程度のスピードが得られるようなので、現在のスピードに不満があるのであればアクセス回線をFLET’S光クロスに切り替えるのは有効かもしれない．
今回のFLET’S光クロスはマンションタイプの設備での利用なので、戸建てタイプの接続の場合は実際のスプリッターによる分岐数が少ないと思われるので、アクセス回線のスピード面ではもう少し有利かもしれない．
尤も今回のスピード測定結果はVNE事業者がアルテリアネットワークスの場合なので、他のVNE事業者で同じようなスピードが出るかどうかは実際に試してみないと判らない．光コラボレーションサービスの場合は、VNE事業者を簡単には変更できないが、enひかりクロスのサービスではFLET’S光クロス回線のみの契約も可能なので、この場合は自分で組み合わせるVNEプロバイダを自由に切り替え可能なので、VNEプロバイダ選びを迷っている場合は、このenひかりクロスのサービス（VNE契約なしタイプ）の利用をお勧めする．
FASTスピードテストの結果
USENスピードテストの結果
enひかりクロスのサービス（VNE契約なしタイプ）に変更することにした
今回のIX-2215でのXpass固定IP接続で問題が発生してしまったが、アルテリアネットワークスさんに直接問い合わせたりサポートを受けることはアルテリアさんとの契約が無いので不可能だ．
勿論、enひかりさんを通じてアルテリアネットワークスさんに何らかの問い合わせをすることは可能だとは思うが、アルテリアネットワークスさんとenひかりさんの間でどのようなサポート契約がなされているのか不明だ．
以前、仕事先の専用回線調達の件でアルテリアネットワークスさんの10G専用線を何本か引いたことがあり、アルテリアネットワークスさんのサポートがしっかりしているのは知っているので、アルテリアさんとの間でやりとりできれば今回のトラブルも直ぐに解決するのだろうが．．．
enひかりさんはインターネット回線の単なる再販業者で、自前のサーバやネットワーク施設を使ってユーザにインターネットプロバイダサービスを提供する会社ではないので、enひかりの契約者に対する技術的なサポートを期待することはできない．
結局、VNE事業者との間でまともなサポートを受けようと思うと、エンドユーザが直接これらのVNE事業者のサービスを契約する必要があるが、初期ののVNE事業者は法人向けのサービスしか扱っていなかったが、後発のVNEサービス事業者であるビッグローブ、朝日ネット、OCNなどは一般ユーザ向けのIPoEサービスも提供しているようだ．
Interlinkさんや琵琶湖ネット、カモメネットワークさんのような以前よりPPPoE接続などのインターネット差ビスを提供しているプロバイダであれば、独自のユーザサポート体制が整っているので、技術的な問題が発生してもきちんとサポートして貰えるので安心だ．VNE事業者によるIPoEサービスであっても、VNE事業者との間に入ってのサポートを期待できそうだ．
…という訳で、プロバイダサービスの料金は現状よりも高くなってしまうが、今回はenひかりクロスのサービス（VNE契約なしタイプ）に契約変更することにした．まだVNEサービスプロバイダを何処にするかは決めていないが、問題があれば別なプロバイダ（VNE事業者）に切り替えることができるので気が楽だ．
