墜落日記 - 2008年1月20日の墜落
ダイヤルアップセッションからのエラー 31 です
昨日から、ネットワークの調子がとてもおかしい。
ルータ機の syslog を見ると昨日の午前 11 時くらいから、断続的に WAN 側の PPPoE が切断される。
Debian の PPPoE 接続は RP-PPPoE の様だが、そのログを syslog から抽出して見てみると、唐突にパケットが通らなくなって Modem hangup まで一直線だったりする。
しかもそれが全く法則性がない。
CHAP 認証まで通ることもあれば、その前でダメなこともある。
CHAP 認証が失敗してしまうケースもある。
NTT 東日本と ISP の WAKWAK に問い合わせるも、工事や回線障害の報告は上がっていない。
ONU の再起動もダメ。
ルータのネットワークカードがダメになったのかとも疑い eth5 から eth3 へ PPPoE で利用するポートを変えたりしたがダメ。
ちなみに我が家のルータ機には国内販売していない Matrox Networks の 4 ポート NIC、NS-FNIC/4 がささっており、eth2 ～ eth5 まではひとつのカードでまかなっている。
NS-FNIC/4 自体がイカれたことも想定に入れて、空いている安い NIC を増設してそちらで PPPoE 接続を試してみるも、やっぱりダメ。
繋がる時と繋がらない時の法則性が全く見いだせない。
（ちなみに、ぶらっとホームに国内流通経路がない Matrox Networks の NS-FNIC/4 の入荷を強行させたのは誰あろう自分である）
で、何故か昨日の 22 時に繋がって、今日の 10 時にまたハングアップ。
更に 13 時にハングアップ。
基本に立ち返って NTT 東日本が提供しているフレッツ接続ツールを使って繋いでみると………
「ダイヤルアップセッションからのエラー 31 です」
とか出やがって繋がらない。
でも再試行すると繋がってしまう………
なんじゃそりゃーっ！？
ヘルプを見ても Google で検索してみてもそんなメッセージは見つからない。
で、NTT の故障担当に電話してみると「二桁ですか！？」と大層驚かれたご様子。
エラーメッセージを検索して貰うと、どうも回線自体の異常などで繋がらない際に発生する可能性がある物らしい。
………って、それって光回線の何処かが接触不良起こしてるってネタですかーっ！！
またですかーっ！？
一昨年くらいにカラスに啄まれて切れたことがあったけど、もしかしてまたその類ってことですか………？
しかも完全に切れてくれれば切れた場所探して治すのも分かりやすいが、不安定な状態だとドコが切れたか現象が出ない可能性が………
現実に 2008-01-20 14:58:26 現在、回線は繋がっていたりなんかするし………(涙)
近所の電信柱には最近また鳥が集結しつつあるという噂もあるし、これはまた面倒くさい事態になった………(涙)
………新型ワークステーションからは ISDN でダイヤルアップ接続する設定を未だやっていない、これは光が繋がるウチにやっておくのが吉か………？
その後、16 時頃に再発。
この時もやはりフレッツ接続ツールでのテストを試みたのだが、今度はフレッツ・スクウェアへの接続と、テストへの接続が共に認証エラー。
当然これらは NTT 東日本が提供している機能で、認証も何も通常はこちら側が認識していない認証コード（ゲストとか）で接続するわけで、これらが認証エラーが起こるというのはただ事ではない。
しかし例によってしばらくすると繋がってしまう………(涙)
今一度 NTT 東日本の故障担当に電話、事情を説明すると、故障担当と自分の予測が一致した―――おそらく光回線の瞬断だろう。
瞬断である、困ったことに瞬断なのである。
常に切れているのなら切れている箇所を探して治してテストすればいいのだが、瞬断となるとそうはいかない。
瞬断しそうな場所を探して、よしんば見つかったとしてそこを治したとしてもそれで全部とは限らない。
治ったという事象を客観的に判断するのが難しいし、そもそも検査している最中に問題の箇所が見つかるかどうかも怪しい………
いっそ気持ちよくスパッと切れてくれっ！！
その方が原因が特定しやすいからっ！！
更に再発。
今度はフレッツ接続ツールでも繋がらない時間が長い………しかし ONU のランプは全部ちゃんと点灯している………
………もしかして ONU 自体の故障だろうか………？？
考えられるのは ONU 自体の故障か、基地局より先の故障か、少なくとも基地局から ONU までの回線は大丈夫ではないかと予測される。
仕方ないので、お休みのところを電話で職場の上司を呼び出して明日の休暇の許可を貰う。
で、もしも時のために用意しておいた緊急時のバックアップ回線 ISDN を使って、会社のグループウェアに休暇を登録、職場のメーリングリストに「休むよ」とポスト。
今までと違って、今回はなかなか繋がらない。
フレッツ接続ツールは「ダイヤルアップセッションからのエラー 31 です」とか「リモートコンピュータへの接続を確立できなかったので、この接続に使われたポートは閉じています」とか出ていて一向に繋がる気配を見せない。
むしろこれは僥倖である。
先にも書いたとおり、現象が出にくいのが最も調査、修理しにくい。
いっそこのまま繋がらない状態で、調査を迎えてくれれば………！！
で、結局繋がっちゃうトコロが悲しい………
現象が掴めねぇ～っ！！
19時30分くらい、NTT 東日本の故障担当から電話がかかってくる………
しかし携帯が鳴っていることに気付かずに、タッチの差で切られてしまう………無念。
明日雪らしいので、その辺りの話だろうと思って、故障担当に電話が取れなかったお詫びと、連絡待っている旨を NTT 東日本の故障担当窓口の留守録に登録する。
20時くらい、再び NTT 東日本から電話がかかってきて、今度は取ることに成功する。
で………
事態が急展開！？
なんでも、自分が使っている光回線のブロックで同様の問題が起こった人が現れたらしい。
で、色々調査してみると、光回線の帯域を専有してしまっている人が居るらしい、と。
なんでも ONU の LAN ポートから出たケーブルを再び LAN ポートに繋いでしまった馬鹿が居るとのこと………
ONU を２つ持っているのか、ONU から出たケーブルをループしたのか、ルータの意味も分からずに取り敢えず繋いでみたのか分からないが、そこで回線がループし自分が使っているブロックが不安定になっていたというのだ。
そのケーブルの付け直しをしたのが19時20分くらい………たしかに NTT 東日本からの電話を取り損なった19時30分にはフレッツ・スクウェアに繋がるようになっている………
その馬鹿がネットワークの配線を間違ったのがいつからかは知らないが、昨日の11時からだというならドンピシャだ。
一応聞いてみたのだが、流石にその時間までは把握できていないとのこと。
確かに、回線がハングアップした時刻を考えると納得できる部分もある。
今までの断続的に回線が切断されたタイミングを syslog を元にまとめてみると、
昨日が、
- 11時50分から12時40分くらい
- 14時20分から16時30分くらい
- 17時30分くらいに一回切れて
- 19時00分から22時10分くらい
で、昨日の22時10分から今日の10時00分くらいは問題なく繋がって、今日は、
- 10時00分から10時20分くらい
- 13時20分から14時20分くらい
- 15時25分から16時40分くらい
その後はフレッツ接続ツールでのテストに移行したのでログがない。
その他、家人の報告ではここ一週間くらい昼間は全然繋がらなくて夜は問題なく繋がる、という現象が発生している。
自分的には無線 LAN の問題だろうと考えていたが、自分が回線の状態を見るのは当然のことながら夜………
昨日、今日の現象と家人の報告には妙な類似点がある………
で、繋がる時間帯と繋がらない時間帯を重ね合わせて考えると、妙に人間の生活サイクルと一致する。
実際、今日の回線断のタイミングである10時と13時を見た瞬間に「現場に着いて午前の工事開始、昼飯喰って午後の工事開始」というシナリオも浮かんではいたのだ。
つまり今回の問題には人間系の要因が絡んでいたとする予測も出来るわけである。
もし件の馬鹿が―――在宅勤務だか SOHO だかしているのだろうが―――特定の時間だけ問題の機器を使っていたとしたら………
もちろん確証は無い。
取り敢えず、NTT 東日本と今後の方針を打合せ。
今夜中に問題が出なければ調査しても原因が掴めない可能性が高いので再現待ち、問題が出ればそのまま調査という段取りで、明日の7時過ぎくらいにこちらから連絡することに相成った。
幸いウチは常時接続のサーバとルータ機が稼働しているし、PPPoE 接続に不具合があれば syslog に吐かれる。
それを監視していればよい。
ただ、夜間はもともと問題が起こっていなかったことに一抹の不安材料は残っているが………
20時30分16秒、回線接続、ログ取得を再開………あとは明日の朝まで下手なログが出ないことを祈って………
まだ原因が特定できたわけではないが、今回の対応、なにげに土日で良かったのかもしれない。
平日だと NTT 東日本の修理担当は通常のオペレータが対応するのだが、日曜は留守電に登録して技術系の部署が直接に順次裁いているらしい。
つまり技術系に疎いオペレータではなく、技術畑の人達と直接会話できるわけである。
相手が技術畑ならばこちらよりプロフェッショナルなワケで、こちらの技術系の単語は無理なく通じる。
向こうもこちらがある程度の技術畑であると認識すれば、変に遠回しな表現をしないで直接的に技術的な用語を使ってくる。
そうすると話が早い。
こちらがしつこく電話したというのもあるだろうし、途中から向こう側の応対履歴を呼ぶために真っ先に COP から始まるお客様 ID を告げたのも正解だった。
担当者の名前も覚えているし、向こうも応対内容を覚えていてくれる。
取り敢えず、これで問題が再発しなかったら NTT 東日本の修理担当、日曜日の当直(？)の人達にグッジョブと言わざるを得まい。
コメントは投稿されていません。