Flets光クロスのレンタルルータの挙動がおかしい

Publish on: 2021-11-15 Update on: 2022-09-25 Classify at: cloud

Words:6836 Read:≈ 14min Views:

2021 年 4 月頃に光コラボ回線の事業者さんからフレッツ光クロスへの変更を提案する営業電話がかかってきた。フレッツ光クロスは NTT のフレッツの中でも今の所最上位のサービスで 10Gbps 回線をベストエフォートで提供するサービスとなっている。提供エリアがそもそもそんなにまだ広くなく、申し込みも少ないのかもしれない。光コラボの回線事業者さんを応援したい気持ちもあったし、今の契約もフレッツ NEXT というそこそこ古い契約で 200Mbps のベストエフォート回線だ。まぁ 10 年前に引っ越してきた際に契約したものなので。

という事で契約変更依頼。1 ヶ月後位に工事日が設定された。ベストエフォートとはいえ 10Gbps の回線。そんな回線に対応するルータは民生向けにはまだ発売されておらず、スモールビジネス向けの機器を買おうとすると 30 万近くしてしまう。ちょっと厳しいよね、って事で月々 500 円でお借りすることにした。WiFi 部分も含めるとコンデンサなどが劣化してしまうこともあり、購入するよりレンタルする方がコスパ良かったりもするのでオススメではある。借りられる機器は XG-100NE と言う装置。XG-100NE は WAN/LAN それぞれ 10Gbps が 1 ポートあり、LAN 側には加えて 1Gbps のポートが 3 ポートあります。また、WiFi6 にも対応しているものになります。これが月 500 円で借りられるならまぁ悪くないかなって思いました。

ただしちゃんと動けば。

不具合の気づき

夏前頃から、時折回線が途切れる事を感じていた。しかしまぁ民生品の装置でもあるしネットワークが切れることはまれにあるかな、なんて思っていたのであまり気になっていなかった。しかし、徐々にその頻度が上がっていく。先月くらいに流石におかしくないか？と思いはじめ、装置に入りログを眺めてみた。

ログは過去 1000 件分保管されており、それより前のものは残っていない。残念だが仕方ないので直近 1000 件分でどれだけ再起動を繰り返しているか調べた。

なお再起動した事を確認するにはいくつかの文字列で探す事が出来るが、 reboot で探すと良いだろう。この文字列はユーザーが手動で再起動操作を行なった際にも出るので、その分は除外している。下記のリストは勝手に再起動しているものだけ抽出した。

なおユーザ操作による再起動はこのような感じでログに残る。

473. 2021-07-18 19:21:11 JavaVM正常停止(reboot)
474. 2021-07-18 19:21:11 ユーザ操作による再起動

勝手に再起動した頻度

There are 1000 entries.
   17. 2021-10-14 17:35:28 JavaVM起動(reboot)
   27. 2021-10-14 08:03:32 JavaVM起動(reboot)
   51. 2021-10-10 21:27:11 JavaVM起動(reboot)
   73. 2021-10-07 16:21:40 JavaVM起動(reboot)
   96. 2019-01-01 00:00:41 JavaVM起動(reboot)
  107. 2021-10-05 08:56:03 JavaVM起動(reboot)
  124. 2021-10-04 08:49:59 JavaVM起動(reboot)
  158. 2021-09-28 17:12:07 JavaVM起動(reboot)
  171. 2021-09-27 14:57:28 JavaVM起動(reboot)
  181. 2021-09-26 09:55:04 JavaVM起動(reboot)
  213. 2021-09-20 07:03:26 JavaVM起動(reboot)
  224. 2021-09-18 20:55:43 JavaVM起動(reboot)
  236. 2021-09-16 09:49:01 JavaVM起動(reboot)
  252. 2021-09-13 00:34:16 JavaVM起動(reboot)
  295. 2021-08-31 06:00:25 JavaVM起動(reboot)
  323. 2021-08-22 18:27:34 JavaVM起動(reboot)
  357. 2021-08-15 09:02:57 JavaVM起動(reboot)
  370. 2021-08-13 12:38:50 JavaVM起動(reboot)
  384. 2021-08-11 12:15:18 JavaVM起動(reboot)
  414. 2021-07-31 05:09:34 JavaVM起動(reboot)
  425. 2021-07-30 00:46:32 JavaVM起動(reboot)
  458. 2021-07-21 02:58:44 JavaVM起動(reboot)
  469. 2021-07-18 19:22:19 JavaVM起動(reboot)
  490. 2021-07-15 10:47:09 JavaVM起動(reboot)
  500. 2021-07-14 07:33:58 JavaVM起動(reboot)
  519. 2021-07-09 22:10:14 JavaVM起動(reboot)
  531. 2021-07-07 16:34:27 JavaVM起動(reboot)
  572. 2021-06-25 02:15:56 JavaVM起動(reboot)
  634. 2021-06-07 10:52:56 JavaVM起動(reboot)
  674. 2021-05-28 10:01:01 JavaVM起動(reboot)
  762. 2021-05-18 15:23:13 JavaVM起動(reboot)
  770. 2021-05-16 22:34:03 JavaVM起動(reboot)
  801. 2021-05-05 21:30:34 JavaVM起動(reboot)
  886. 2021-04-24 21:17:01 JavaVM起動(reboot)
  896. 2021-04-24 01:02:10 JavaVM起動(reboot)
  908. 2021-04-22 02:56:28 JavaVM起動(reboot)
  916. 2021-04-21 01:32:46 JavaVM起動(reboot)
  998. 2021-04-19 18:02:00 JavaVM起動(reboot)

頑張って 1 週間、ダメだとその日のうちとかそんな感じで再起動している。大体平均すると 3 日に 1 回と言う感じだ。深夜だったり早朝だったり利用してない時間に再起動してくれる分には全く問題ないが、テレワーク中にぶっつり切れてしまうのは中々に困る。当初はホームゲートウェイ以外でテレワークの部屋で利用していた機器である WiFi ルータもあり、そちらはかなりの安物を使っているのでそちらの被疑も考えていたが、有線接続に切り替えたデスクトップ PC でも WiFi 機器類と同じタイミングで切れている事が確認されたので、これは WiFi ルータではなく NTT からレンタルしている HGW が悪いのでは、と切り分ける事が出来た。

原因を探る

安直に毎朝仕事を開始する前に再起動しておけばいいのかな、なんて思っていたのだが、その日のうちに再起動している事もあるので、毎朝再起動させる事はあまり対処にならない。って事で原因を考察してみる事にした。真っ先に頭に浮かんだのは 2 点

パケット過多による CPU 過負荷
利用セッション過多による NAPT テーブル溢れ

ただ、ログからわかるのは深夜の 3 時とかにもこの再起動は発生しているという事。深夜の 3 時に上記の原因となるようなパケット過多になる事も NAPT が溢れてしまう事も考えにくい。

そもそもこの装置はどれだけ NAPT 出来るのか？とざっくり調べた感じでは 4096 セッションっぽいので 2 人暮らしの我が家なら余裕、テレワークのために仕事中は複数 PC を起動し、場合によっては Webex や Teams で Web 会議を開きっぱなしにしていたりするが Webex も Teams も IPv6 でセッションを持っているようなので、多分 NAPT が溢れることはなさそう。ただそれ以外でも今どき宅内にはスマートスピーカーなど沢山の機器があるので、テレワークの時間中は NAPT 溢れている可能性はあるかなぁ、気づかないだけで NAPT 溢れによる速度低下は発生しているかも知れないとは思う。しかし切断・ルータのリセットとなると話は別だ。

冒頭に記載しているがなんといっても深夜 3 時にも再起動しているので NAPT テーブル溢れによるメモリリークなどは再起動の原因とするには常識的に考えてちょっと考えにくい。

原因不明

色々考察はして見たものの、原因を特定するには情報が足りなさすぎるので一個人では原因究明は不可能です。Twitter などを検索してみても同じように困っている方がいらっしゃる様なので、早くメーカーのエンジニアさんに声が届いて修正されるといいのだけれど…

Flets に関する技術ついて学ぼう

原因を特定していくに当たってはそもそもどういう仕組みでネットワークが作られているか理解する必要がある。という事で文献を探してみたら、JPNE さん監修でこの PDF 無料で公開しちゃって本当にいいの？！という位高品質なドキュメントとなる徹底解説 v6 プラスと言う本が見つかった。自宅の光ケーブルはどこに繋がるか、その中で JPNE さんが担う役割はどこか、と言った学びとともに、IPoE 方式と PPPoE 方式の違いから、MAP-E や DSlite と言う IPoE 方式の中で使われる技術仕様まできっちり書かれている。とても良いドキュメントなので一読される事をオススメしたい。

ホームゲートウェイでの挙動が書いてあった

ひかり電話の契約があり、 NTT 東西のひかり電話ルーターまたはホームゲートウェイを利用する場合には、 MAP-E の機能を提供する JPNE のソフトウェアをホームゲートウェイにインストールする必要があります。ホームゲートウェイを利用する形で v6 プラスの利用を申し込むと自動的にインストールされるので、エンドユーザ側で 6.2 ひかり電話の有無で変わる IPv6 ネットワーク構成の作業は不要です。

ひかり電話の契約はないが、フレッツ光クロス契約だと 10Gbps の市販ルータがない事もありホームゲートウェイをレンタルする事になります。実際にはレンタルせずとも良いらしいのですが、一部 ISP 等では ユーザーは必ずホームゲートウェイをレンタルする と言う契約導線になっています。(実際にはそんな ISP でも別途相談するとホームゲートウェイナシの契約にも出来ます %別記事参照%)

JPNE のソフトウェアは、 NTT 東西による「フレッツ・ジョイント」というサービスによって配布されています。フレッツ・ジョイントは、事業者がホームゲートウェイに対してフレッツ網からソフトウェアを配信できるようにするサービスです。JPNE が NTT 東西とフレッツ・ジョイントの契約を行っており、これを通じて JPNE のソフトウェアがユーザのホームゲートウェイにインストールできるようになっています。

と言う事でホームゲートウェイを ONU へ接続するとフレッツ・ジョイントの機能を用いて JPNEソフトウェアが配信 されてきます。このJPNEソフトウェア が MAP-E の処理をしてくれて IPv4 での通信が出来るようになります。ONU へ接続してしばらくすると IPv4 で通信できるようになるのですが、IPv6 での通信は接続した瞬間から出来ます。IPv6 での通信可能なサイトであれば MAP-E の機能を通さず通信する事ができるのです。

この JPNEのソフトウェア こそ、ログの再起動の際に出てくる文字列 JavaVM になります。

試しに MAP-E 対応の手持ちのルータを繋いで見た

ホームゲートウェイ同様接続した瞬間に IPv6 での通信は確立します、が、IPv4 通信が出来ません。MAP-E 対応ですが MAP-E に関する情報がルータに届かずいくら待っても MAP-E での通信が確立しません。これにはフレッツ・ジョイントが関連してきます。

ホームゲートウェイ利用契約のままでは市販ルータは利用できない

フレッツ光クロスを契約し、その際にホームゲートウェイ（レンタルルータ）をレンタル契約している場合、このフレッツ・ジョイントを用いた JPNE ソフトウェアの配信が設定されます。自前でルータを用意して接続した場合は MAP ルール配信サーバから MAP ルールを取得する事が期待されますが、まずはフレッツ・ジョイントにより不要なのに JPNE ソフトウェアを配信のシーケンスが走ります。市販のルータでは MAP-E のためのソフトウェア配信を受ける必要が無いので当然この配信シーケンスは失敗する訳ですが、この配布した JPNE のソフトウェアに MAP-E ルールを配信するような設定になっていると想定されますので、JPNE ソフトウェアの配信が完了しないと MAP-E ルールの配信が始まりません。 JPNE ソフトウェアの配信がエラーになるので、そこで処理が完了。IPv6 での通信はできるのですが MAP-E ルールが処理されない事から IPv4 での通信路が確立しない事になります。

ホームゲートウェイの利用を諦めて市販のルータを買ってきて契約変更をする顛末などは別記事に記載しました、よければそちらもどうぞ。

再起動するのは本体か？JavaVMだけなのか？

ホームゲートウェイにフレッツ・ジョイントでMAP-Eを処理するソフトウェアが配信される事がここまででわかりました。でも再起動する原因がこの JPNEのソフトウェア 側にあるのか、それとも JavaVM を動作させるホームゲートウェイ側にあるのかは不明ですが、何らかの不具合が XG-100NE の中で発生し再起動してしまうようです。詳細はメーカーのエンジニアでないとわかりませんが、この再起動の事象が起きるとIPv4もIPv6も切断され、たまたまホームゲートウェイの近くに居た際に再起動になったのでわかったのですが、本体LEDも全部消灯するレベルで再起動になります。JavaVMが死ぬだけでそんな事になったりするんですかね、VMが本体を殺す…って結構クリティカルに思えます。

機器交換

最終的には結構業務時間に再起動を起こす事が多くなってきました。最近は大事な会議に参加する事も多いためあまりに頻度が多いと、これだからテレワークは。出社して仕事したら？みたいなマインドが社内に生まれてしまうのでそういうのは避けたい。こんなに頻繁に再起動しては困るのでユーザーサポートにサポートを依頼。

光コラボの弱点

ドコモ光を契約しているのでいわゆる光コラボです。まずはドコモ光の故障受付に。状況を伝えるのにログとかもみて欲しかったので Web フォームでまずはコンタクト。程なくして折り返し電話がかかってきます。情報を先に送っているので話は早い。でも結局光コラボなのでドコモでは故障対応が出来なくて、NTT の故障受付に転送されるという。という事でエスカレーションをお願いし、エスカレーション先からの電話を待った。

NTT 故障受付からの電話

その日の深夜に故障受付から電話が来た。23 時近かったのでこんな時間でも相談に乗ってくれてありがたいなー、と思いつつ、結局故障受付の方なのでそれほど技術に明るいわけでもなく、NAPT や MAP-E と言った単語を交えて状況説明してもピンと来てなかったみたい。仕方ない。

結局故障対応は訪問になる、ということで、ハード故障では無さそうだしなぁ…とは思いつつも、エンジニアの方に状況をお伝えしないと始まらないだろう？との思いから故障対応をお願いした。

訪問対応

数日後 NTT のエンジニアさんが来訪。状況説明するために障害ログを抜き出し再起動の頻度をマーキングしたファイルを用意しておき、大画面のモニタに大きく映して状況をお伝えするプレゼンを数分行い、せっかく来ていただいたがハード故障とは考えていない旨をお伝えした。

念のためという事で光のレベル測定を計測するも当然問題なし。ハード故障とは考えられないのでログを取得して持って帰って頂いて状況確認していただければいいよ？と提案したが、来たからには交換して帰らないと、という事で交換して頂いた。持ち帰ったハードを解析していただくのも場合によっては必要だと思うのでそれはそれで良いかもしれない。

機器交換後

機器を交換してしばらくは安定して動いていた。ここ最近は大体 3〜4 日間隔で落ちていたので機器交換後に 1 週間再起動しなかったので、お？回復？！なんて思った矢先にやはり再起動を繰り返すようになった。

設定チューニングでどうにかならないか悪あがき

NAPT テーブルが溢れたメモリリークの線も全く消えたわけでもないし、チューニングで少しはマシに出来るかな？という事でチューニングを試みる。

http://ntt.setup:8888/t/ にログインするとホームゲートウェイにダウンロードされたアプリケーション一覧が表示される。ホームゲートウェイは全ての機能をファームウェアとして機能を全て持っている訳ではなく、必要な機能を Java アプリケーションをダウンロードし利用するようになっている。今回は IPoE を用いるプロバイダを利用しているので IPoE に関するアプリをダウンロードして動かしている感じ。このホームゲートウェイには電話用のモジュラージャックもあり、現在は利用できないが様々 NTT 局社側の設備などが整ったら現在は提供されていないひかり電話サービスも利用できるようになるだろう、その際には契約したらひかり電話サービス用のアプリがダウンロードされて使えるようになる、という感じになる。仕組みとしてはよくできていると思う。

アプリのチューニングで各種タイムアウト値を変更できる、これを少し短めに設定する事でアプリやブラウザ起動時のセッション保持は短くなるので体感として若干遅くなる場合があるが、より NAT テーブルが溢れにくくなるようにすることが出来る。

みたいな設定をしてみたものの、全く関係なく普通に再起動を繰り返しているので、色々悩んで検索してこのページに辿り着いたみたいな方には申し訳ないですが、チューニングしても無駄っぽいです。

MAP-E でも DS-Lite でも起きているらしい

様々インターネットで調べると昨今の ISP は MAP-E でサービスしている所が多いので MAP-E の事象が多いのだが、DS-Lite でも同様に再起動を繰り返す事象が発生しているようだ。MAP-E に関する部分ではなくアプリの共通部分的な所であったり、JavaVM の動作管理を行なっている Firmware だったりが怪しいのかなぁ。と言う所感。

今後の対応

この不安定なネットワークを利用し続けるのは正直しんどいので、フレッツ光クロスを出来れば解約したいと考えています。Nuro 光とか他社に行くのでは違約金なども発生してしまいますし、10Gbps の世界を諦めてフレッツ光クロスからフレッツ光ネクストギガラインサービスとかに変更できたら良いなと思っています。フレッツ光ネクストに変更させてもらえなかったとしても、XG−100NE をこの不安定のまま使い続ける気もないので、在宅勤務への投資という事でブランチ向けのルータ NEC UNIVERGE IX2207 を購入しました。新品で。

中古でも十分だとは思うのですが、お仕事にも用いる所ですし NW 機器って結構コンデンサまわりが痛みやすいですし、ちゃんと Firmware サポートも受けたいですし、投資投資。

今回は取り急ぎここまで。回線契約を変更できるのか？安定したネットワークを取り戻すことが出来るのか？乞うご期待。