こんばんは、執事です。
今回は、
これらの記事の続きです。
ファンを取り付けて落ち着いたと思ったんだけど、やっぱり瞬断が発生する。
しかも、主にipv4接続でのみ発生。
Xpass(DS-Lite)のIPoE（IP over Ethernet）でipv4って言ったら、プロバイダ側にある装置（AFTR）がIPv6のから、IPv4アドレスへの変換（NAT処理）する過程でのトラブルかなぁ？
つまり、XpassからIPv6に契約を変更しなきゃいけないかな？とか思ってたんですが、色々調べてみるとXG-100NEの方が相当に怪しい感じで…。
発生している障害について
まず、発生している障害と状況について書くと、
- en光クロス(10GB)でインターネットを使用していると主にipv4のサイトが突然遅くなる→開かなくなる
- ipv6対応のサイトだと普通に繋がる
- ASUSのRT-BE18000をAP設定で無線LAN機器(192.168.1.2）として使用
- XG-100NEをホームゲートウェイとして使用（ひかり電話の為に必要だった）
- ipv4が落ちている時にping -4 -t 192.168.1.1のログを見ても障害無し（ASUS⇔XG100NE間のLANに問題なし）
- XG-100NEのLAN側はLAN1~3(1GB)でもLAN4(10GB)でも同じように瞬断は発生する。
- XG-100NE⇔ASUS間のLANケーブルは、cat6Aを使用（当初はCat7にしてたけど変えた）
といった感じ。
この瞬断の厄介な所は、完全にランダムなタイミングで来る事。
そして、暫くリロードを繰り返すとその内復帰するので、XG-100NEの再起動をしなくても一応戻る。
この障害は7月にen光1Gbからen光クロス(10GB)に変更して間もない頃から発生していたけど、前述の記事のようになんやかんややってたらちょっと落ち着いていた。
けれど、8月くらいから頻度がどんどん上がっていって、今では一日に10回は落ちる様になってしまったので、これはいよいよちゃんと調べないと、と思った次第。
ipv4とipv6の接続状況を体感ではわかっていたけど、ちゃんと切り分ける。
まず、瞬断が発生するタイミングが読めないので、いつ発生してもわかるように2つのコマンドを使う。
ping -4 -t 8.8.8.8
ping -6 -t 2001:4860:4860::8888
ping -4 -t 8.8.8.8 の意味
-
-4：強制的に IPv4 プロトコルを使用して通信を行う。 -
-t：ユーザーが手動で停止する（Ctrl + Cを押す）まで、無制限にpingを送信し続ける。 -
8.8.8.8：宛先となるGoogleパブリックDNS（IPv4アドレス）。
つまり、「IPv4を使って、止めるまでずっとGoogleのDNSサーバーへ通信テストを続ける」という事。
ping -6 -t 2001:4860:4860::8888 の意味
-
-6：強制的に IPv6 プロトコルを使用して通信を行う。 -
-t：上と同様、手動で停止するまで無制限にpingを送信し続ける。 -
2001:4860:4860::8888：宛先となるGoogleパブリックDNSの IPv6アドレス 。
これらを使って取れたログがこちら。
←のipv6はちゃんとpingは通っているけど、→のipv4はタイムアウトしているのがわかる。
そして、ipv4がタイムアウトしていてもipv6は接続が継続しているのもわかる。
これと前提条件を合わせると、
XG-100NE → Ds-Lite → Xpass AFTR → IPv4 Internet
のどこかが怪しいな、って目星はついたわけです。
一体どの辺までルーティングできているかを調べる
次に使うコマンドがこちら。
tracert -4 8.8.8.8
tracertコマンドの意味
-
tracert：宛先までに経由するネットワーク経路（ルーターなど）を追跡（Trace Route）するコマンド。 -
-4：強制的に IPv4 プロトコルを使用して経路を追跡する。 -
8.8.8.8：追跡の宛先となるGoogleパブリックDNS（IPv4アドレス）。
つまり、「IPv4を使って、自分のパソコンからGoogleのDNSサーバーに届くまでに、どのネットワーク機器を経由しているかを調べる」という事。
主な用途と使い方
-
通信の遅延や切断箇所の特定：インターネットが重いときや繋がらないときに、どこまでの経路が正常で、どこから先に問題があるのかを切り分けるために使います。
で、これがそのログ。
これを見ると、←のtracertのタイムアウトと、→のpingのタイムアウトが重なっているものの、最終的に17msで繋がってはいる。
となると、ipv4の経路そのものが完全に切断されている感じではないカモってのがわかってきました。
DS-Lite/XpassのIPv4通信が一時的に極端なパケットロス状態になる → 数十秒後に自然復旧って感じ？
まだ対象範囲としては絞れてないけど、Xpass側の原因がちょっと薄くなったかな？
ipv4サイトであるyahoo.co.jpを使ってもうちょっと条件を加えて調べる
次に使うコマンドがこちら。
curl -4 -I https://www.yahoo.co.jp/
nslookup www.yahoo.co.jp 8.8.8.8
curl -4 -I https://www.yahoo.co.jp/ の意味
Webサーバーが正常に応答しているか、HTTPヘッダー（ステータスコードなど）を確認するコマンド。
-
curl：ネットワーク経由でサーバーとデータを送受信するコマンド。 -
-4：強制的に IPv4 プロトコルを使用。 -
-I：Webページの本棚（本文データ）は取得せず、サーバーの応答ヘッダー情報（HTTPステータスコードなど）だけを取得する。 -
https://www.yahoo.co.jp/：アクセス先のURL（Yahoo! JAPAN）。
つまり、「IPv4を使ってYahoo! JAPANのサーバーにアクセスし、ページが正常に表示できる状態か（エラーが出ていないか）をヘッダー情報だけで手軽に確認する」コマンド。
nslookup www.yahoo.co.jp 8.8.8.8の意味
ドメイン名からIPアドレスを引く（名前解決）ためのテストを行うコマンド。
-
nslookup：DNSサーバーにドメインの情報を問い合わせるコマンド。 -
www.yahoo.co.jp：調べたいWebサイトのドメイン名。 -
8.8.8.8：問い合わせ先として指定したDNSサーバー（この場合はGoogleパブリックDNS）。
「普段使っているプロバイダなどのDNSではなく、GoogleのDNSサーバー（8.8.8.8）に直接『www.yahoo.co.jpのIPアドレスを教えて』と問い合わせる」という意味。DNSが正常に機能しているかをテストしたいときに使う。
で、これのログがこちら。
障害そのものは瞬断で変わらないんだけど、色々やっている内にログの内容が変わった部分があります。
今までは瞬断発生してからpingを飛ばしてタイムアウトのログが発生するのを確認していましたが、-ｔでpingを流し続けたら、ipv4のpingの応答はあるけど、ipv4サイトに繋がらないっていう状態が確認できるようになりました。
これは「IPv4断」ではなく、TCP/UDP通信だけ一時的に壊れてる感じ。
| テスト | プロトコル | 障害時 |
|---|---|---|
ping -4 8.8.8.8 |
ICMP/IPv4 | 正常 17ms |
nslookup ... 8.8.8.8 |
UDP/53中心 | 失敗 |
curl -4 Yahoo |
TCP/443 | 失敗 |
| ブラウザ Yahoo | TCP/QUIC等 | 開かない→何度かで開く |
IPv4の経路そのものが消えているわけではないっぽい？
ICMPはDS-Liteを通って普通に往復できているのに、TCP/UDPの新規セッションが一時的に通ってない？
DS-Liteのセッション/NAT状態に関係する不具合かな？
PC
↓
ASUS（AP）
↓
XG-100NE
↓
IPv6網
↓
DS-Lite AFTR
↓
IPv4 Internet
この流れで繋がるはずなんだけど、ICMPが通っている以上、XG-100NE→IPv6網→AFTRまで全部死んでいるわけじゃなくて、
「新しいTCP/UDP通信を作る処理」
だけが一時的におかしくなっているっぽい。
完全な回線断なら、リロードを何回やっても回復しないはずなのに、
Yahooを何回かリロード
↓
ある時突然開く
そして同じ時間でも、
pingはずっと17ms
なので症状としては、
「パケットが全部落ちる」ではなく「一部の新規フローが作れない／作りにくい」
の可能性が高そう。
XG-100NEのログについて
XG-100NE
の障害ログ、通信ログ、
障害発生時間帯にWANリンクダウン等の明確な回線断を示すログ
DHCP関連では、WAN側IPv4アドレスのリース延長要求お
つまり、ログ上で障害になってそうなものは何も記載が見当たらない状態でした。
ここまでの切り分けの結果としてen光に送った内容
・ASUS RT-BE18000(192.168.1.2)はルーターモー
ドではなくAPモードで使用
・XG-100NEへの有線接続でも現象を確認
・障害中でもXG-100NE（192.168.1.1）へのLAN 内通信は正常
・IPv4の8.8.8.8へのICMP pingは正常な状態でも、IPv4 TCP/UDP通信が失敗することがある
・IPv6通信は正常なケースが多い
・XG-100NE再起動により一時的に改善する
・しばらくすると自然復旧する場合もある
・DHCPリース更新時刻と障害発生時刻には明確な相関なし
以上から、宅内LANやWi-Fiの単純な通信断というより、X
Xpass側設備を含め、
障害発生時のping、nslookup、curl等の結果を撮
必要であれば、次回障害発生時に追加で実施すべき確認方法・
よろしくお願いいたします。
って感じで今も絶賛障害対応中。
更に発生した追加の障害
en光に上記の障害報告を済ませて、ヤレヤレと思いながらLANポートを4（10ＧＢ）に戻したら…。
繋がらない(´；ω；`)
LAN4のままだと192.168.1.1にアクセスしても管理画面すら開かない。
pingを飛ばしてもタイムアウト。
そこでLAN1やLAN2に繋げるとちゃんと開けるし繋がる。
繋がった段階で管理画面を見るとLAN4でポートリンクのアップ、ダウンはできてるみたいだから、コネクタとかLANケーブルの不良ではなさげ。
これ、
-
LAN4の10GbE PHY/コントローラ周辺の異常
LAN1/2へ同じ端末・同じ構成で差し替えるだけで192.168.1.1へ接続できるなら、PC→ASUS→XG-100NEという宅内経路そのものは生きてる。差分がXG-100NEのポート側。
-
10GbEのリンクネゴシエーション異常
LAN4だけ10GbEなので、1GbEポートとはPHYもリンク確立処理も異なる。完全故障でなくても、10GBASE-Tのオートネゴシエーションが異常状態に陥ってリンクアップできなくなっている可能性あり。
偶然の可能性もあるけど、
「XG-100NE内部に何らかの不安定要因があり、それが以前は断続的な通信異常として現れ、今回は10GbEポートの完全停止として現れた」
という仮説も無視できない感じ？
まとめ
今回の自分の場合は、LAN4が逝った事も含めてen光のサポートには連絡済。
10GB回線で10GB使えないなんて本末転倒だから、XG-100NEの交換も並行して動いてもらっています。
あとはサポートからの返事があり次第、また記事にしようと思っています。
それにしても、色々調べてみるとXG-100NEでトラブルを抱えている人がめちゃめちゃ多い事がわかりました。
トラブルがあまりに多い割に完全解決に至ったって記事は皆無なので、積極的に情報拡散、共有をしていきたいですね。
コメント