こんばんは、執事です。
今回は、
これらの記事の続きです。
ファンを取り付けて落ち着いたと思ったんだけど、やっぱり瞬断が発生する。
しかも、主にipv4接続でのみ発生。
Xpass(DS-Lite)ではIPv6はIPoEでそのまま通信し、IPv4はDS-LiteによってIPv4パケットをIPv6の中にカプセル化して運びます。
そのIPv4パケットをXpass側のAFTRで取り出し、IPv4側へNATして通信するので、その辺の処理でトラブルが起きているのかな？
つまり、Xpassをやめて別のIPv4 over IPv6方式に変更しないとダメなのかな？
とか思ってたんですが、色々調べてみるとXG-100NEの方が相当に怪しい感じで…。
発生している障害について
まず、発生している障害と状況について書くと、
- en光クロス(10Gbps)でインターネットを使用していると主にipv4のサイトが突然遅くなる→開かなくなる
- ipv6対応のサイトだと普通に繋がる
- ASUSのRT-BE18000をAP設定で無線LAN機器(192.168.1.2）として使用
- XG-100NEをホームゲートウェイとして使用（ひかり電話の為に必要だった）
- XG-100NE管理画面のルータ設定→高度な設定内で「省電力型イーサネット機能」は無効
- ipv4が落ちている時にping -4 -t 192.168.1.1のログを見ても障害無し（ASUS⇔XG100NE間のLANに問題なし）
- XG-100NEのLAN側はLAN1~3(1Gbps)でもLAN4(10Gbps)でも同じように瞬断は発生する。
- XG-100NE⇔ASUS間のLANケーブルは、cat6Aを使用（当初はCat7にしてたけど変えた）
といった感じ。
この瞬断の厄介な所は、完全にランダムなタイミングで来る事。
そして、暫くリロードを繰り返すとその内復帰するので、XG-100NEの再起動をしなくても一応戻る。
この障害は7月にen光1Gbpsからen光クロス(10Gbps)に変更して間もない頃から発生していたけど、前述の記事のようになんやかんややってたらちょっと落ち着いていた。
けれど、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で繋がってはいる。
tracertでは途中に*が出ていますが、途中のルーターがTracerouteへ応答しないだけの場合もあるため、これだけで障害箇所とは判断できません。
最終的には8.8.8.8まで到達していました。
この時点では「IPv4経路が完全に消えているわけではなさそう」というところまでしか判断できませんでした。
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へHTTPS接続し、HEADリクエストに対してHTTPレスポンスが返るか確認するコマンド。
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自体が完全に落ちているのではなく、少なくとも確認した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（10Gbps）に戻したら…。
繋がらない(´；ω；`)
LAN4のままだと192.168.1.1にアクセスしても管理画面すら開かない。
pingを飛ばしてもタイムアウト。
そこでLAN1やLAN2に繋げるとちゃんと開けるし繋がる。
ポートリンクアップ自体は認識されているので、完全な断線ではなさそう。
でも、ケーブル挿してもLEDランプが点灯しない。
これ、
-
LAN4の10GbE PHY/コントローラ周辺の異常
LAN1/2へ同じ端末・同じ構成で差し替えるだけで192.168.1.1へ接続できるなら、PC→ASUS→XG-100NEという宅内経路そのものは生きてる。差分がXG-100NEのポート側。
-
10GbEのリンクネゴシエーション異常
LAN4だけ10GbEなので、1GbpsEポートとはPHYもリンク確立処理も異なる。完全故障でなくても、10GBASE-Tのオートネゴシエーションや10GbEのリンクトレーニング周辺で異常があり、リンクアップと判定されても正常なEthernet通信が成立していない可能性。
偶然の可能性もあるけど、
「XG-100NE内部に何らかの不安定要因があり、それが以前は断続的な通信異常として現れ、今回は10GbEポートの完全停止として現れた」
という仮説も無視できない感じ？
まとめ
今回の自分の場合は、LAN4が逝った事も含めてen光のサポートには連絡済。
10Gbps回線で10Gbps使えないなんて本末転倒だから、XG-100NEの交換も並行して動いてもらっています。
あとはサポートからの返事があり次第、また記事にしようと思っています。
XG-100NEについて調べてみると、通信不調や接続トラブルを報告している事例はいくつか見つかりました。
ただし症状や原因はそれぞれ異なるので、今回と同じ原因かどうかは不明です。
今回のケースについては引き続き経過を共有していこうと思います。
関連記事
コメント