こんばんは、執事です。
今回は、
この記事の続き。
前回、en光クロスに変更してから続いている謎のIPv4瞬断について色々切り分けをしていたところ、
XG-100NEのLAN4（10Gbpsポート）が完全に通信できなくなる
という、なんとも分かりやすい故障っぽい症状まで出てきました。
LAN1～3の1Gbpsポートなら繋がる。
LAN4だとリンクアップのログ自体は出る。
でも、192.168.1.1のXG-100NE管理画面にすらアクセスできない。
いや、もうお前が原因やろ(´・ω・`)
と思うじゃないですか。
で、NTTに来てもらってXG-100NEそのものを交換してもらいました。
これで全部解決！
……すると思ってたんですけどね。
XG-100NEを新品交換。LAN4は復活した
NTTの業者さんに来てもらい、XG-100NEを交換。
まず、完全に通信できなくなっていたLAN4（10Gbpsポート）は普通に使えるようになりました。
なので、
旧XG-100NEのLAN4側には、少なくとも何らかの不具合があった可能性が高そう。
これはこれで交換してもらって正解だったと思います。
LAN4からASUS RT-BE18000へ繋ぎ、
PCからXG-100NEの管理画面にもアクセスできる。
インターネットも繋がる。
よし。
これで長かった障害調査も終わりかな？
と思いながら使っていたんですが……。
交換したXG-100NEでもIPv4が落ちた
また落ちた(´；ω；`)
症状は交換前とほぼ同じ。
IPv4側のサイトが突然開かなくなる。
でもIPv6側は普通に通信できる。
以前は障害に気付いてからコマンドを打っている間に復帰してしまうことも多かったんですが、今回はちょうど症状が出ている真っ最中に確認できました。
使ったのは前回と同じく、
ping -4 8.8.8.8 nslookup www.yahoo.co.jp 8.8.8.8 curl -4 -I https://www.yahoo.co.jp/
結果はこちら。
まず、
ping -4 8.8.8.8
は連続タイムアウト。
その後、何も再起動していないのに突然19ms程度で応答が戻る。
次に、
nslookup www.yahoo.co.jp 8.8.8.8
こちらもタイムアウト。
これはXG-100NEやプロバイダから配布されたDNSではなく、
Google Public DNSの8.8.8.8を直接指定
しています。
なので、
「XG-100NEのDNS Proxyがおかしいだけ」
とか、
「en光側のDNSサーバーがおかしいだけ」
という話ではなさそう。
更に、
curl -4 -I https://www.yahoo.co.jp/
も、
curl: (28) Failed to connect ...
となって約21秒で失敗。
つまり今回は、
IPv4のICMP、DNS、HTTPSがまとめて一時的に通信できない
という状態を確認できました。
新品交換しても再発したという事はどういう事なのか？
ここが今回一番大きいところ。
交換前までは、
- XG-100NEのDS-Lite処理がおかしい？
- XG-100NE内部のSPIやNAT周辺がおかしい？
- LAN4まで死んだし、やっぱり本体故障？
- Xpass側の設備がおかしい？
と、色々候補がありました。
ところが、
XG-100NE本体を交換しても同じIPv4障害が再発した。
こうなると、
「前のXG-100NE個体だけが壊れていた」
では説明しづらくなります。
もちろん、
同じXG-100NE、同じファームウェア、同じDS-Lite機能を使っているので、
XG-100NEという機種共通の処理やソフトウェア側に何かある
という可能性までは消えません。
でも少なくとも、
旧XG-100NE固有の個体故障だけが原因
という線はかなり薄くなりました。
LAN4が死んだ件とIPv4瞬断は、
もしかすると別件だったのかもしれません。
改めてXpass（DS-Lite）の通信経路を考えてみる
ここで、そもそもIPv4通信がどこを通っているのかを整理。
自宅側は、
PC ↓ ASUS RT-BE18000 ↓ XG-100NE ↓ ONU ↓ NTT東日本のフレッツ網 ↓ Xpass側 ↓ Internet
という流れ。
ASUS RT-BE18000はAPモードなので、今回のIPv4 over IPv6処理をしているわけではありません。
IPv4通信の場合はXG-100NE側でIPv4パケットをIPv6の中にカプセル化して、
Xpass側のAFTRまで運びます。
ざっくり書くと、
IPv4通信 ↓ XG-100NE ↓ IPv4パケットをIPv6内にカプセル化 ↓ NTT IPoE網 ↓ Xpass ↓ AFTR ↓ IPv6の殻を外す ↓ CGN/NAT ↓ IPv4 Internet
みたいな感じ。
一方でIPv6通信は、
IPv6通信 ↓ XG-100NE ↓ NTT IPoE網 ↓ IPv6 Internet
という感じで、IPv4通信で必要になるAFTRやIPv4用のNAT処理を通りません。
で、今回の症状は、
IPv4が止まっている時でもIPv6サイトは普通に見られる。
つまり、
光回線全体が落ちているとか、
Wi-Fiが切れているとか、
XG-100NEとASUS間のLANが死んでいる、
という感じではない。
IPv4 over IPv6固有部分が怪しい。
という切り分けになってきます。
NTTの業者さんから気になる話を聞いた
今回XG-100NEを交換しに来てくれた業者さんと話していた時に、
ちょっと気になる話を聞きました。
最近、
「プロバイダ側設備の容量不足で通信トラブルが起きている事例を聞くようになった」
とのこと。
もちろん、これは今回の自宅の障害がそれだと断定する話ではありません。
業者さんから聞いた事例の話です。
ただ、今回の通信経路を考えると気になる。
DS-Liteでは、IPv4通信がXpass側のAFTRへ集約されます。
AFTR側では、
IPv4 over IPv6の終端、
IPv4への戻し、
CGN/NAT、
大量のユーザーのセッション管理、
などを処理する事になります。
なので仮に、
- AFTRの処理負荷
- CGN/NATのセッション資源
- NAT用ポート資源
- 収容設備の負荷
- AFTRからIPv4 Internetへ出ていく設備や回線
のどこかで一時的な逼迫が起きれば、
「IPv6は生きているのにIPv4だけおかしい」
という事自体は理屈としてはあり得る。
しかも今回の障害は、
ずっと止まるわけではなく、
数十秒～数分程度で勝手に復帰する。
というのがまた嫌らしい。
調べた時には正常。
でも数分前には死んでいた。
こういう障害が一番面倒なんよ(´・ω・`)
enひかりから届いた前回の調査結果
XG-100NE交換前にenひかりへ障害報告を出していました。
その回答がこちら。
以前頂いていたトレース情報で調査完了しました。
該当時間帯にて弊社にて工事故障情報はございませんでした。
また、クロスパス設備を確認いたしましたが、調査時点にて異常は見受けられません。
なお、お手数をおかけいたしますが、次回事象発生時につきましては、
通信元から通信先への経路だけでなく、通信先から通信元への経路を含めた、
双方向のトレースルートをご確認いただきますようお願いいたします。
ここでちょっと気になったのが、
「調査時点にて異常は見受けられません」
という部分。
今回の障害は自然復旧します。
例えば、
23:32 障害発生 23:34 復旧 翌日 調査 ↓ 正常
なら、
その時点で正常なのは当然なんですよね。
知りたいのは、
障害が発生していた2026年9月16日の23:32～23:34の間にXpass側設備で何が起きていたか。
です。
交換後の再発を受けてenひかりへ再調査を依頼
そこで今回、
XG-100NEを新品交換した後でも同じ障害が発生したことと、
障害発生中に取得したログを追加してenひかりへ連絡しました。
送った内容はこんな感じ。
XG-100NE本体を新品交換後も同一のIPv4通信障害が再発。
障害発生中に、
ping -4 8.8.8.8
→複数回タイムアウトnslookup www.yahoo.co.jp 8.8.8.8
→Google DNSを直接指定してもタイムアウトcurl -4 -I https://www.yahoo.co.jp/
→約21秒後に接続失敗を確認。
DNSだけではなくIPv4のICMP・DNS・HTTPSが同時に通信不能となっている。
発生時刻は2026年9月16日23:32～23:34頃。
調査時点の正常・異常だけではなく、障害発生時刻について、クロスパス側の収容設備、AFTR、CGN/NATセッション、IPv4出口設備等にパケットロス、セッション異常、設備負荷、収容逼迫等の記録がないか確認してほしい。
という内容。
これまでよりかなり具体的な情報は渡せたと思います。
「双方向のtraceroute」って一般ユーザー側で取れるの？
あと、enひかりから言われた、
「通信先から通信元への経路を含めた双方向のtraceroute」
について。
自宅からGoogleなら、
tracert -4 8.8.8.8
で調べられます。
でも、
Google ↓ 自宅
のtracerouteは、
Google側からコマンドを実行できないと普通は取れません。
しかもDS-Liteでは、
自宅の192.168.1.xというIPv4アドレスがそのままInternetに出ているわけではなく、
Xpass側のAFTR/CGNを経由してグローバルIPv4を共有しています。
なので、
「通信先から自宅までの逆tracerouteを取ってください」
と言われても、
具体的にどうやって？(´・ω・`)
となる。
なのでこの点についても、
具体的にどのサービスや測定方法を想定しているのか、enひかり側へ確認しています。
IPv6セキュリティログにも障害時間帯の記録があった
ちなみにXG-100NEのログをもう一度細かく見ていたところ、
2026年9月16日23:32～23:34頃、
IPv6のセキュリティログにSPIで破棄されたパケットが複数記録されていました。
※ここにIPv6セキュリティログ画像
最初、
「これ、今回の障害と関係ある？」
と思ったんですが、
送信元IPv6アドレスをXG-100NEの端末接続ログから逆引きしてみると、
自分が障害調査に使っていたWindows PCではなく、
別のAndroid端末でした。
しかも、おそらく外出中の家族のスマートフォン。
なのでこのIPv6 SPIログについては、
現時点では今回のIPv4障害との直接的な関連は確認できていません。
同時刻だったから気にはなりますが、
SPIログが出た＝今回の原因、
と決めつけるのは早そう。
ここは一旦保留です。
現在のところ一番疑っている場所
今までの切り分けを全部並べると、
PC・スマホ ↓ ASUS RT-BE18000 ↓ XG-100NE ↓ NTTフレッツ網 ↓ Xpass ↓ AFTR / CGN ↓ IPv4 Internet
このうち、
ASUSはAPモード。
XG-100NEへのLAN内pingは正常。
XG-100NEは新品交換済み。
IPv6通信は障害中も使える。
でもIPv4側だけ、
ping、
DNS、
HTTPS、
が一時的に失敗する。
となると、
今のところ個人的には、
XpassのDS-Lite固有部分、特にAFTR/CGN周辺またはその先のIPv4出口側
がかなり気になっています。
ただし、
まだ「Xpass設備が原因」と断定できる証拠まではありません。
XG-100NEという機種共通のDS-Lite処理に何かある可能性も残ります。
なので今は、
犯人を決める段階じゃなくて、逃げ道を一個ずつ潰してる段階。
って感じ。
まとめ
今回分かった事としては、
XG-100NEのLAN4不具合については、本体交換で復旧しました。
ただし、
肝心のIPv4瞬断は新品XG-100NEへ交換しても再発。
なので、
「XG-100NEの旧個体が壊れていただけ」
では説明できなくなりました。
そして今回は障害発生中に、
IPv4 ping → timeout Google DNS直接指定 → timeout IPv4 HTTPS → timeout
というログも取れた。
一方でIPv6通信は利用できる。
となると、
DS-LiteでIPv4だけが通る経路、
特にXpass側のAFTR、CGN/NAT、IPv4出口設備周辺はやっぱり気になります。
enひかりには障害発生時刻を指定して、
その瞬間の設備負荷やセッション異常まで見てもらえないか
と再調査を依頼中。
いやぁ……、
最初は、
「Wi-Fiかな？」
「DNSかな？」
「ASUSかな？」
「LANケーブルかな？」
「XG-100NEかな？」
とかやってたんですが、
まさかここまで長引くとは思わなかった。
10Gbpsにして速くなったはずなのに、回線障害の勉強ばっかり詳しくなっていく(´；ω；`)
まぁでも、
ここまで来たら最後まで原因を追ってみます。
enひかりからクロスパス側の調査結果が返ってきたら、また続きを書こうと思います。
コメント