|
2004年9月14日
今朝，いつものように仕事を始めようとしたら，『ぷらら』に繋がらない。おかしいと思ってサーバを調べると，こちらの方は『かもめ』への接続が4時34分に切れて以来ずーっと再接続動作を繰り返している。で，調べてみると，PPPoEの認証でこちらからパスワード情報を送るところまではいいのだが，その後の応答が返らず，タイムアウトしてしまう。『ぷらら』も『かもめ』も同じ現象だ。パスワード情報は最終的にISPの認証サーバまで転送され，そこから応答が返ってくるのだが，両方とも応答がないっていうことは，ISPの認証サーバに転送動作がおかしいということだ。これはNTT東の責任範囲のはずなので，とりあえずNTT東に電話してみる。
案の定，混み合っているようで，再度こちらから連絡するかれ連絡先を知らせよ，というボイスメッセージの声が聞こえる。そこで当方の電話番号を告げ，待つことしばし。電話してから20分ほどたった9時過ぎに連絡があり，回線を収容している設備の故障があり，機器を交換しているところだという。で，復旧したら連絡するので待ってほしいとのこと。仕方ないのでしばらく待つと，9時12分頃復旧。そして，いつものように仕事し始めると，10時頃になって復旧を知らせる電話があった。
まあ，ときには機械が壊れることだってあるから，それはそれで仕方ないのだが，対応が遅いのは問題だ。NTT東の説明では，4時50分頃故障に気づいて復旧作業に入ったということだが，こちらでは4時34分に接続が切れている。障害の検出に15分はちょっと長いんじゃないかなぁ。で，機器の交換に4時間。何を交換したのやら。で，復旧してから連絡があるまで50分。何もないよりましだけど，50分後じゃ連絡する意味ないよなぁ。なんとかしてよー。
2002年11月14日
はっきりとは覚えていないが，1週間ほど前からクライアント用に使っている『ぷらら』の速度が明らかに低下した。それ以前，インターネットの速度計測サイトでの計測結果は15～20メガビット／秒程度だったのが，7～8メガビット／秒程度に低下したのだ。その程度に低下することはこれまでもあったのだが，今はそれとは違う。早朝などの空いている時間帯も含めて，いつも安定してその程度の速度しか出ないのだ。一方，サーバ用の『かもめ』の速度は以前と変わらない。だから，フレッツの部分が混雑しているのではないだろう。『ぷらら』で帯域制限しているのだろうか。うーむ。
2002年9月22日
最近，クライアントからのインターネットアクセスに使っている『ぷらら』の調子が悪い。夜とか，休みの日とか，皆が使っていそうな時間帯になると，ログインできないのだ。PPPoEのやり取りを調べてみると，NTTのPPPoEサーバとのセッションが始まって，LCPのやり取りが終わり，こちらからCHAPのレスポンスを送った後，応答が返ってこない。普通だったら，この後，IPアドレスなどを通知してきてログイン動作が終わるのだが，CHAPレスポンスを送ったところで止まってしまう。数回レスポンスを送り直してもナシのつぶてでタイムアウトしてしまう。このPPPoEのやり取りの相手はNTTのサーバだが，CHAPのレスポンスとして送ったパスワード情報は，NTTのサーバを経由してぷららのサーバまで届くはずであり，そこから応答が返ってこないから，NTTのサーバから何も返ってこないのだと思う。まさか，グローバルアドレスが足りなくて，ログインできないなんてことはないよねー（疑いの眼）。混み合うとログインできなくなるなんてモデムやISDNと一緒じゃない。FTTHってその程度のものなのぉー。カンベンしてよー，もおぉー。
2002年7月2日
このところ，Bフレッツが切れることが多いので，サーバのログで切断回数を調べてみたら，ナント，6月は13回も切断していた。ほとんどは再接続動作ですぐにつながったようだが，そのうち1回は切断時間が1時間10分にも及ぶものだった。Bフレッツへの移行を決めた2月には1回しか切断事故がなかったのに，どうなっているんだぁ。ADSLじゃないんだから，回線の品質が悪いってことはないんだぞ。
2002年5月31日
午後3時28分，PPPoEの接続が切れた。普段，自分の作業用マシンとサーバの両方で，それぞれ別々にPPPoEセッションを張っているのだが，両方とも一緒に切れた。再接続を試してみるが，PPPoEサーバを探し出すディスカバリパケットの応答が返ってこない。パケットのやり取りが全然できない状態だ。
以前，フレッツADSLを使っていたとき，似たような現象に何回か遭遇したが，そのときは1～2分で回復していた。だから，今回も，と10分ほど待ってみたのだが，今日は回復の気配がない。待っているだけじゃ能がないのでNTT東の故障窓口に電話してみたのだが，あっさり繋がって，機種は何を使って云々，というお決まりの質問が飛んできた。面倒くさいので，PPPoEのディスカバリに応答が返ってこないこと，光ファイバ終端装置のLEDは正常に点灯していることなど，ズバリ状況を説明したのだが，パソコンのエラー表示はどうなっているか，とマニュアルどおりの質問は変わらなかった。カンベンしてよぉー，こっちは締め切り前で忙しいんだから。
その後，電話を切り，状況を調べてもらったが，トンチンカンな質問の電話が2回かかってきただけで，向こう側の状況の説明はなかった。そして，4時25分頃，先ほど電話した障害受付窓口の担当者から，最寄の電話局で3時28分に故障があった旨電話連絡が入ってきた。オイオイ，そんなことを調べるのにどうして1時間もかかるんだよぉー，という気持ちを抑え，他にも故障の連絡があるんじゃないかと，聞いてみたら，他には故障の問合せはないとのこと。最寄の電話局は住宅街だから，まだ，お客さんが少ないんじゃないんですかぁ，だって。1時間も止まっているのに，苦情は1件だけってことかぁ？ Bフレッツってぇのはその程度のサービスなのか？ いやはや。
その電話の直後，4時29分頃，障害は回復した。やれやれ。
2002年3月13日
日記をサボっているうちに，またまた，新たな展開になってしまった。実は，昨日，Bフレッツが100メガのベーシックタイプに切り替わった。いきなり，そこまで行っちゃうと話が見えなくなるので，順番に書こう。
1月末にBフレッツのファミリータイプを導入した後，しばらく様子を見ていたのだが，結果はまずまずの合格点といえるものだった。その間使用したのは，地元横浜にある『かもめインターネット』というプロバイダだったが，一月の間にトラブルは一回。PPPoEのセッションが切れただけだった。それもすぐに再接続できたので，実害はないという程度のものだった。PPPoEのセッションだから，原因はNTT東の方にあるような気がするけど，まあ，それをとやかく云っても仕方がない。ユーザとしては両方をワンセットで使うしかないんだから，どっちが悪い，なんてところにエネルギ使っても仕方がないからだ。とにかく，合格点だった。
ところが，一つ問題があった。BフレッツのファミリータイプはPPPoEのセッションを一つしか張れない点だ。『かもめ』は固定グローバルアドレスを割り当てるサービスを1000円／1アドレスで提供している。それを使えばサーバを設置できてよいのだが，そうしたとき，クライアントはどうなるのか？そこが問題だった。セッションを複数張れれば，そのうちの一つをこのサービスでサーバ用に使い，もう一つのセッションで別のプロバイダに繋いでクライアントはそちらを使うという方法がとれるが，セッションが一つなのでサーバで使ったら，それで終わりなのだ。クライアントにプライベートアドレスを割り当て，サーバでNATを動かして，サーバ経由でインターネットにアクセスすればいい，という考え方もなくはないが，そのやり方は嫌いだ。これまでも度々書いてきたように，プライベートアドレスはアプリケーションが制限されるからだ。方法はもう一つある。いわゆるネットワーク型接続というのだろうか，グローバルアドレスを8個とか16個とか固定で割り当てるサービスを利用する方法だ。でも，これは高い。NTT東のプロバイダ紹介ページからあちこち飛んで調べると，安いところでも2万円近くする。Bフレッツのファミリーと合わせると2万5千円は超えてしまう。10メガのスピードなんだから，それでも充分に安いのだが，すんなりそこに乗っかるのも面白くない。
そこで考えたのが，Bフレッツのベーシックタイプに移行する方法だった。ベーシックタイプはセッションを二つ張れるので，さっき書いたように，一つをサーバ用，もう一つをクライアント用にすれば，とりあえず，当方の要求は満たすことができる。それで，料金は，ファミリータイプ＋ネットワーク型接続より安い。Bフレッツが10,100円，『かもめ』の固定グローバルアドレスのサービスが4850＋1000円，そしてクライアント用の『ぷらら』が4000円，合計約2万円だ。
昨日，そのベーシックタイプへの移行工事が終わって，100メガが開通したというわけだ。そして，『かもめ』の固定グローバルアドレスサービスでサーバを100メガに接続し終わった。
では，100メガ体験2日目の速報を書こう。まず，スループットだが，クライアント用に使っている『ぷらら』に接続して『SPEED
TEST』というサイトで計測すると，結構変動が大きく，10メガ～40メガの範囲をうろうろといったところ。連続して何回か試すと，その間でも結構数値が上下する。ヤマカンで平均すると，10メガ台の後半といったところだろうか。10メガのファミリータイプは4～7メガ程度だったので，それよりは速いが，10倍速いわけではない。しかも，速度計測サイトだからこれだけの差が出るのであって，普通にWebサイトにアクセスするときの差はほとんどない。このくらいのスピードになると，LANと同じなのでWebサイトにアクセスしてもページはあっという間に表示される。だから，10メガと100メガの違いなんかわからない。ファイルをダウンロードすれば違いがわかるかと思ったが，こちらの方は1メガ以上のスピードでダウンロードできるサイトには滅多に出会わない。だから，10メガも100メガも一緒なのだ。
しかし，プロバイダの料金は違う。安いところしか調べていないが，ファミリータイプなら1,500円から2,000円なのが，ベーシックタイプだと4,000円から5,000円となる。3倍以上違うということだ。両者は実質的に違いはないのだから，ファミリータイプの方がお得であることは間違いない。まあ，ベーシックタイプのユーザはほとんどが企業ユーザだということだから，NATを介してクライアントを何台も繋ぐのだろう。そうすれば違いは出てくるかもしれないが，それにしたって，ごく一部の業種を除けばインターネットばかりアクセスしているわけではないから，何台かクライアントをぶら下げたところで，10メガと100メガの違いを体感できるほどにはならないだろう。だから，3倍以上も料金差があるのは，ちょっといただけない。セッションを二つ欲しかったら，ファミリータイプを2本契約した方が賢いっていうことだ。Bフレッツには，セッションを四つまで張れるビジネスタイプというのもあるが，これも同様に，ファミリータイプを4本契約した方がお得だろう，多分。
とにかく，100メガでサーバも繋がったので，日本テレコムは，残念ながら，さようなら，だ。これで，2年に渡る我が家のブロードバンド計画も一段落ということになるのだろうか。それとも，もっと安くて良いサービスが出てくるのだろうか。その可能性もないではない。PPPoEは所詮ダイヤルアップの延長で，接続動作が必要だし，切れることもあるから，サーバを設置するには不安がある。同じ100メガで，同等の値段で，PPPoEじゃないサービスが出てきたら乗り換えるんだろうなぁ，やっぱり。まあ，それまでの間よろしくね，NTT東さん，『かもめ』さん。
2002年1月30日
日本テレコムのJ-DSLで手間取っている間に，光ファイバも開通してしまった。NTT東のBフレッツファミリータイプ（伝送速度10Mbps）だ。こちらは，さすがに光ファイバだけのことはある。インターネットの速度計測サイトで計ると，実効速度で6～7Mbpdほどの速度が出ている。Webページの表示も速くなったけど，ファイルをダウンロードすると違いがわかる。本当に速い。10Mバイトくらいあっても，あっという間。ローカルのサーバからファイルを読み込むのとさほど変わらない感じ。しかも，月々7千円以下。スゴイわぁ。本当。
ただ，以前のフレッツADSLの経験だと，NTTの地域IP網に少し不安がある。PPPoEの接続が切れることがあったからだ。しばらく様子を見て，その辺に問題がなければ，こっちの方を中心に考えることにしよう。
2002年1月21日
いろいろと忙しく，J-DSLへの切り替えの経過報告が中断してしまった。さて，その結果だが，回線そのものは12月8日に開通し，状態はまあままといったところか。ルータのログを見ると，12月8日から今日（2002年1月21日）までの間で，切断と再接続を行った跡が10回以上記録されている。そのほとんどは，2～3分以内に再接続動作が完了しているので，当方のようなサイトでは，実害は少ない。だから，まあまあ，といったのだが，安心してサーバを接続できるサービスかというと，どうだろうか。DSLは所詮その程度，と割り切りが必要のようだ。
さて，回線はそんな感じで当初の予想から大きく外れていないのだが，ドメインの切り替えでつまづいてしまった。というか，まだつまづいたままだ。
最初からDSLをあまり信用していなかったため，OCNから一気に切り替えずに，1ケ月程度は両方併行して使うつもりでいた。そのため，J-DSLのドメインには，一時的に，違うドメイン名を割り当てた。そして，回線の状態もわかってきたので，glasscom.comをOCNからJ-DSLに切り替えようとしたのだが，そこでつまづいたのだ。問題は，J-DSL用に一時的に登録したDNSサーバの情報がレジストラのデータベースから削除できなくなってしまったのだ。
ドメインを登録するときは，そのドメインを管理するDNSサーバをレジストラに登録するのだが，今回のケースでは，J-DSLに接続したDNSサーバのIPアドレスを一時的なドメイン名と一緒に国内のレジストラ代理店を通じて登録した。ここまでは問題ない。そして，これをglasscom.comに切り替えるには，国内のレジストラ代理店を通じて登録した一時的なドメイン名とIPアドレスを削除して，その後，glasscom.comを登録したVeriSign（旧Network
Solutions）のDNSサーバのIPアドレスをJ-DSLのアドレスに変更すればよいはずだった。
ところが，一時的なドメイン名の方を削除したところ，表面上削除したように見えたのだが，実はこれが削除できていなかった。そのため，VeriSignでIPアドレスを変更しようとするとエラーになってしまうのだ。VeriSignへの登録はメールで行い，本当なら，エラーが起こるとその旨記載したメールが返ってくるのだが，今回のケースでは何も反応がなかった。そのため，あれ～～おかしいなぁ～？？ということで何回かやり直しするはめとなった（実は，これがいけなかった。）。レジストラの登録変更は，バッチ処理されるので，データベースが更新されるのは一日に2回しかない。つきっきりで作業しているわけじゃないから，思い出したときに結果を見るためにデータベースを調べるのだが，何も変わっていない，という状況が続いた。これで何日が無駄にした。エラーのメールが返ってこないので理由がわからず，VeriSignにメールで問い合わせると，『そのIPアドレスは他で使っているよ』と答えが返ってきて，そこではじめて国内での削除がうまくいっていなかったことがわかった。もっと早く気づけばよかったのだが，削除できていないなんて思ってもいなかった。おまけに時期も悪かった。クリスマスシーズンで人がいなかったのだろう。VeriSignから返事が返ってきたときには年を越していた。
今度は日本のレジストラ代理店に問い合わせるのだが，今度はお正月だ。メールの答えが返ってきたのは，2回も催促した後の1月16日だった。何でも担当者が入院してしまったとのこと。そこからメールのやり取りが始まったが，先方はこちらの状況をなかなか理解できず（レジストラのデータベースがおかしいなんて考えてなかったのだろう），ようやく今日になってデータベースの異常を伝えてきた。おまけに，改善の見込みも不詳とのこと。
文句言っても仕方がない。ただ，原因がわかったので，後は対処するだけだ。つまり，登録したIPアドレスを削除するのはあきらめて，新しいIPアドレスでglasscom.comのプライマリサーバに新しいIPアドレスを割り当てればよいだけだ。日本テレコムに，その旨伝えることにしよう。普通だったら一回ですむところを，一時的なドメイン名を登録したり，それを変更したり，さらにIPアドレスも変えてくれ，と日本テレコムにはわがままなお願いをしなければいけないが，まあ，そんな事情だから許して欲しい。ゴメンね，日本テレコムさん。
2001年11月29日
あれこれ調べた結果，日本テレコムのJ-DSLオフィスに乗り換えることにした。そして，12月7日に工事が行われる手はずとなった。しかし，これもすんなりといったわけではない。
まず，J-DSLサービスを申し込むために，日本テレコムの問い合わせ窓口に電話したら法人営業から連絡させるとのことだったが，いつまで待っても連絡がなく，3回も催促してやっと連絡が来た。そこまでなんと2週間。そこからは早く，12月7日に工事するところまで段取りを付けるのに2日だったのだが，その後がいけない。
日本テレコム営業が云うには，タイプ2のフレッツADSLを他社サービスに乗り換えるには，フレッツの撤去と新サービスの導入を同じ日に実施しないとNTT側の工事ができないらしく，12月7日にフレッツを解約するよう依頼があった。で，依頼に従って解約手続きをとったところまではよいのだが，1週間ほどすると，同日工事は不可能で，フレッツ撤去の一週間後にJ-DSL導入にして欲しい，とNTTから日本テレコムに連絡があったようで，日本テレコム営業がその旨連絡してきた。当方は早くJ-DSLに切り替えたかったので，フレッツ撤去を12月7日の1週間前，つまり，11月30日にしてもらった。ところが，今日になってフレッツ撤去は12月3日にして欲しいとNTTから連絡が入った。そもそも，同日工事が必要って云っていたくせに，何やっているんだか。
実は，これだけじゃなく，フレッツ解約のためにNTT窓口に電話したときもひどかった。その日の10時前，日本テレコムから前記のフレッツ解約の依頼があったので，すぐにNTT窓口に解約の電話を入れたのだが，さんざん待せされ，やっと繋がったと思ったら，今は混んでて担当が手一杯だから後でNTTからかけ直すっていい始めた。で，いつになるのか聞いたら，なんと夕方だという。2時には日本テレコムから連絡が入ることになっており，夕方まで待ってられないので，そのまま待つと伝えたら電話が切れてしまった。仕方なく，窓口にかけ直し，またまた，さんざん待たされ，結局，解約の手続きが終わったときは2時になっていた。
みんな，ヤル気あるのかよぉー。
2001年10月25日
昨日，KDDIのモデムはブリッジタイプだと書いたが，間違いだった。問合せ窓口でそう聞いたし，Webサイトの絵もモデムとルータが別に書あったのだが，法人営業に確認するとルータタイプとのことだった。しかも，そのルータはKDDI側で設定するので，IPフィルタリングは不可能とのこと。KDDI，お前もか。というか，日本テレコムよりもっと悪い。うーむ。
さて，どうしたものか。ルータでのフィルタリングはあきらめ，DMZを設けることにしよう。それには，IPアドレスを16個に増やさなければならない。まあ，仕方がないか。
2001年10月24日
ブロードバンドブームのおかげで，価格性能比の優れたサービスが増えてきた。今使っているOCNエコノミーをそちらに乗り換えようと検討しているので，その状況を報告しておこう。移行のねらいはOCNエコノミーと同程度で数倍の高速化だ。候補は，すでに書いたとおり，日本テレコムのJ-DSLオフィス，KDDIのビジネスDSL，ビットキャットのFTTHサービスの三つだ。ビットキャットはサービス開始が年末から年初の予定なので，当面の候補は日本テレコムとKDDIとなるが，結論からいえば，KDDIが有力だ。その選定理由はモデムにある。
日本テレコムがレンタル用に用意しているモデムはルータタイプなのだが，IPフィルタリングの機能が足りない。具体的には，フィルタリング条件の設定可能数が少ないのだ。接続の方向性を判断するためにTCPプロトコルのSYNフラグをフィルタリングの条件として指定する機能も怪しい。サポート窓口に電話で聞いた限りでは，SYNフラグは検証していないという。
大規模なサイトなら，ファイアウォールを設けて，そこでフィルタリングするからルータのフィルタリング機能の重要度は低いが，我が家のような小規模サイトでわざわざファイアウォールを設置するのは面倒だ。面倒だというだけでなく，IPアドレスも足りない。日本テレコムのサービスはグローバルアドレスを8個割り当てるものだが，ファイアウォールを設置してDMZを設けるためにサブネットに分けると，各サブネットのIPアドレスは4個ずつになる。このうち両端の二つは使えないし，ルータやファイアウォールにアドレスを割り当てるとことを考えると，サーバ1台分のアドレスがかろうじて残るだけとなる。それじゃ，DNSのセカンダリサーバも置けない。もちろん，DMZなど設けなければ，こうした問題は起こらないが，それじゃ危ない。だから，ルータのフィルタリング機能が重要なのだ。
今，OCNで使っている富士通のルータは3年以上も前の機種だが，当方の要望に応えるだけの機能を持っているので，当然，日本テレコムのモデムも大丈夫だろうと思っていた。ところが，念のために確認すると，この結果なのだ。そのレンタル用の機種ではなく，自分でルータを購入する方法もある。しかし，検証済みの機種は一つしかなく，3万5千円もする。未検証の機種を使う方法もないではないが，ただでさえ不安なADSL側でトラブルが起こると面倒なことになる。
一方，KDDIはどうかというと，こちらのモデムはブリッジタイプだという。それなら，自分で好きにできる。Linuxマシンをモデムに直結して，ルータ兼ファイアウォールにすればよいからだ。Windows
2000だって，そういう使い方はできる。
さて，わざわざ，こんなことを書いたのは，その辺の事情をISPがどの程度理解しているのか疑問に思うからだ。中途半端なルータと8個のIPアドレスの組み合わせじゃ，実用上問題が生じる。IPアドレスが8個しか割り当てられないのなら，ルータはちゃんとした機種じゃないと困るし，ルータでのフィルタリングを考えないのなら，IPアドレスは16個必要なのだ。もっと，基本的な考え方に遡れば，モデムはルータタイプではなく，ブリッジタイプを用意すべきだ。ブリッジタイプのモデムの方が，自由度が高く，いろいろなケースに対応できるからだ。ただ，ブリッジタイプを使いこなすには，それなりの技術が必要であり，それができないユーザもいる。まあ，Linuxマシンじゃなくて，市販のブロードバンドルータを使えばそんなに技術はいらないが，それだと余分に費用がかかる。だから，そうしたユーザ向けにルータタイプも用意しておく，というのが筋じゃないのかしら。それも，中途半端なルータじゃなくて，IPフィルタリングなどの機能のしっかりした機種をね。
2001年10月x日
フレッツ接続ツールの顛末を書いておこう。9月8日の後，何回かNTTとメールの投げ合いがあり，次のような説明があった。まず，フレッツ接続ツールでDHCPを使っているように見えるのはPPPoEドライバの内部の動作だということ。つまり，PPPoE用のインタフェースからDHCPのパケットが出るのだが，それはLANに出て行くのではなく，ドライバ内にある擬似的なDHCPサーバが受け取り，そこからPPPoEインタフェースにIPアドレスを割り当てる応答パケットをする，ということらしい。そして，その擬似DHCPサーバが応答するIPアドレスは，PPPoEプロトコルによって，網側から割り当てられたアドレスとなる，とのことだ。当方は，EtherealによってPPPoE用のインタフェースから出入りするパケットをキャプチャしたのでDHCPのパケットが見えたが，そのパケットは実際にはドライバの内部での擬似的なやり取りであり，LANにはDHCPのパケットが出て行かないはずだとのことだった。これで，DHCPの謎は解けたのだが，それにしても，なんというか，面白いことを考える人がいるもんだと関心してしまった。
しかし，謎が解けても，現象が改善したわけではない。今後の改善について前向きな回答がないし，NTTの説明には，細かいところで腑に落ちない箇所が残っている。だから，この問題はここで終わり，つまり，フレッツ接続ツールはお払い箱にして，同時に試していたWhistlerサーバのPPPoEの方を使うことにした。そっちの方は，その後，1ケ月間毎日使っているが問題は起こらない。それに，Windows
XPでもWhistlerサーバのPPPoEと同様のドライバが標準装備されているはずだから，いずれ，世の中はそちらの方に進むことになる。フレッツ接続ツールはそれまでの繋ぎに過ぎないんだから，フレッツ接続ツールを深追いしてもねぇ。
ただ，自分の普段使いのマシンをWhistlerサーバに切り替えたおかげで，いくつか問題が起こるようになった。でも，Whistlerサーバはまだベータ版なのだから仕方がない，とあきらめることにしよう。
それから，フレッツ接続ツールの問題に限らず，途中で切れてしまうなどの問題があり，フレッツADSLは頼りないことがわかったので，別のサービスを試すよう，方針を変えることにした。次の候補は二つある。一つは，同じADSLだが，NTTの地域IP網を使わずに，直接プロバイダの網に接続するタイプのサービス。都内と違って，サービス提供業者が少ないが，KDDIや日本テレコムといったNCC系のサービスなら我が家周辺でもサービスされている。そして，もう一つはFTTHだ。三井不動産系のビットキャットという会社が，年末か年始頃，我が家の周辺でFTTHサービスを始めるという。FTTHの初期工事費はさすがに高いが，月額使用料はDSLと変わらない。いずれも，512Kbpsで月額3万円程度だ。
2001年9月8日
フレッツ接続ツールの挙動が腑に落ちないので，Whistlerサーバ（ベータ版）のPPPoEクライアントも試してみた。次期WindowsにはPPPoEクライアントが最初からOSに組み込まれているのだ。こちらは予想通り，PPPoEサーバが割り当てた設定値をLANインタフェースに設定する。やっぱりね。
WhistlerのPPPoEにはフレッツ接続ツールとは違うところがもう一つある。LANインタフェースが複数存在するとき，フレッツ接続ツールはその中のどれを使ってPPPoEのやり取りをするのか，事前に設定する。ところがWhistlerの方は，存在するLAN全部にPPPoEサーバを探すブロードキャストパケットを流し，応答が返ってきた相手と，その後のやり取りを行うのだ。これなら設定は不要だし，状況の変化にも対応できる。この流儀の方がPPPoEの本来の考え方を反映しているように思う。まあ，ブロードキャストを無駄に流すのはどうか，という声もあるかもしれないけれど，接続時にパケット１個送る程度なら問題はほとんどないだろう。
それから，昨日NTTに問い合わせのメールを送っておいたら，今日返事が来た。フレッツ接続ツールの古いバージョンで同様の現象があり，それは最新版では改善されているから，バージョンを確かめろとのことだった。でも，当方のバージョンは，その改善されているはずの最新版だ。やれやれ。
2001年9月7日
一昨日，『フレッツ接続ツール』がまともに動くようになった，と書いたけど，ぬか喜びだったようだ。今日は，まともに動いてくれない。で，調べてみた。
まず，前提知識からいこう。フレッツ接続ツールはPPPoEプロトコルを扱うクライアントソフトなので，そのPPPoEとは何ぞや，という話からだ。PPPoEは，ダイヤルアップ接続のときに使うPPPプロトコルをイーサネット上で使うためのものだ。フレッツは地域IP網を介してプロバイダに接続するのだが，その地域IP網にダイヤルアップ接続時の電話網と同じ役割を持たせるのが，PPPoEを使う目的だ。モデムでダイヤルアップして電話網を介してプロバイダに繋ぐ代わりに，PPPoEで接続動作を行って地域IP網を介してプロバイダに繋ぐのだ。ダイヤルアップの場合は，ダイヤルした相手に繋がり，相手と1対1で通信する。PPPoEの場合はダイヤリングの代わりにブロードキャストによって，PPPoEの相手（サーバ）を探し，そこと仮想的な接続動作を行う。これで，イーサネット上で1対1の通信を行う環境が整う。つまり，ダイヤルアップでサーバと接続したときと同じ状態となる。また，PPPは接続時に，サーバ側からIPアドレスなどの設定情報をもらって，それをクライアント側に設定するが，PPPoEの場合もそれと同じことを行う。つまり，ブロードキャストで探し出した相手からIPアドレスなどの設定情報をもらい，それをクライアント側に設定する。その設定が終われば，ダイヤルアップと同様に，PPPoEサーバを経由して，その先のネットワークと通信できるようになる。
と思っていたのだが，実際の動作はこれとは違っていた。PPPoEサーバが送ってきた設定情報をクライアント側に設定するのではなく，PPPoEの接続動作が終わった後，DHCPによってIPアドレスなどの設定情報を受け取っているのだ。フレッツ接続ツールでの設定がうまく行かないのは，そのDHCPの応答を正しく受け取れていないことが原因と判明した。サーバ側からDHCPの応答が返ってくるが，それを無視して，繰り返しDHCPのリクエストが送っているのだ。今まで何度か，接続がうまくいかないときにPPPoEのパケットを覗いていたが，正常時と異常時の違いがわからなかったのはそのためだ。原因はPPPoEが終了した後にあるのだから，PPPoEをいくら一生懸命眺めたって，わかるはずがない。
PPPoEとはそういうものなのか。それとも，Windows
2000特有の問題なのか。どっちなのだろう。PPPoEでサーバ側から受け取った設定情報を正しく設定できないと，LANインタフェースは未設定の状態となる。その未設定の状態でインタフェースがアクティブになったためにWindowsのDHCPの機能が動くのかもしれない。未設定のインタフェースがあったときに，それを設定しようとするのがDHCPの役目だからだ。DHCPの設定に失敗したときに，169.254.x.xというリンクローカルアドレスを割り当てるのは，Windowsの動作そのものだから，WindowsのDHCP機能が動き出したと考えることもできる。それとも，フレッツ接続ツールは，WindowsのDHCPが動くことを期待して，PPPoEサーバから設定情報を受け取っても，それをインタフェースに設定しないようになっているのか。今，書きながら気づいたが，後者の考え方が正しそうだ。というのも，フレッツ接続ツールで接続動作を行うと，途中経過を表示してくれるが，そこにDHCPサーバから送られてきたアドレスが表示される，つまり，フレッツ接続ツールはDHCPを使うことを前提に作ってある，思えるからだ。すると，なぜ，使いもしない設定情報をPPPoEサーバからもらうのか。うーむ。なぞだ。
とにかく，DHCPがうまく動いていないことだけは確かなので，NTTにレポートでもしてみるか。
2001年9月5日
フレッツADSLは，ユーザ宅 － NTT地域IP網 －
プロバイダ，という構成をとっており，『フレッツ接続ツール』というPPPoEクライアントソフトを使って，地域IP網の先にあるプロバイダに接続操作を行う。その接続ツールの動作には不審な点があった。PPPoEでプロバイダからIPアドレスなどの割り当てを受けるのだが，それがOSに反映されないことが度々あったのだ。具体的には，Windows
2000サーバ版に接続ツールをインストールして使っており，PPPoEで割り当てられたIPアドレスがインタフェースにセットされなかったり，デフォルトゲートウェイがルーティングテープルに反映されない，という現象が起こっていたのだ。
加入直後の6月頃は，稀にしか現象が起こらなかったのだが，徐々に増え，8月にはかなりの頻度で現象が起こるようになっていた。それが，今月に入って，全然起こらなくなった。接続ツールをアップデートしたわけでもないので，何かネットワーク側で変更があったのだろう。
この現象が起こるとき，PPPoEのパケットの流れは一見するだけでは正常なので，まじめに原因を調べなかったので，原因がどこにあったのか定かではない。ちゃんと原因を調べておけばよかった，という思いもあるが，まあ，よしとしよう。
この一月ほど，切断の現象も起こらないし，フレッツADSLも安定してきたというところだろうか。もし，そうなら，次の展開を考えるのも悪くないかもしれない。
2001年8月1日夜
只今，午後8時25分。1～2時間ほど前からだろうか，パケットロスが増え，急激に速度が低下する現象が断続的に発生している。PPPoEのコネクションが切断するところまではいかないが，数秒間通信が停止してしまうこともある。今までの例だと，調子が悪くなるとPPPoEが切断してしまい，再接続すると回復するという例が多かったが，こんなに長時間に渡って不安定な状態が続くことは少なかった。もうしばらく様子を見てみることにしよう。
2001年7月16日夜
只今，午後9時25分。DSLが切断した。接続操作を行うと，今朝と同じように認証でエラーとなる。PPPoEのCHAP認証で，サーバから送られてきたチャレンジに応答すると，次にサーバから何も返ってこない。朝はそこまで調べなかったけれど，同じだった可能性が高い。
接続操作を繰り返すと，PPPoEサーバから何の応答も返ってこないこともある。皆で再接続しているから，サーバが追いつかないのかもしれない。
NTTの障害窓口に電話したら，案の定，繋がらない。やっと繋がって，音声応答の指示に従って進んでいくと，最後に，混み合っているから掛け直せ，だってさ。ふぅ。それにしても，この日記を1日に2回も書くとは思わなかった。これが，3回にならないことを祈るのみ。
2001年7月16日朝
朝，マシンを立ち上げてDSLの接続操作を行うと，ユーザ認証がエラーとなる。NTTのテスト用ユーザだと認証および接続の動作は正常だが，ぷららのユーザだと認証がエラーとなり，接続できない。当然のごとく，原因はぷららにあるものと思い，ぷららの障害窓口に電話したら，ナント，営業時間は昼の12時からなので，それまで待てとのこと。うーむ，個人用のサービスとはそういうものか。仕方ないので，12時まで待って電話すると，案の定，全然繋がらない。これまた仕方がないので，メールで障害を報告し，至急対応を依頼した（我が家は，OCNエコノミーも使っているので，メール送受信などは問題ない）。そして，4時少し前，ぷららから返事のメールがきた。NTTの地域IP網に設備故障があり，神奈川県でぷららが利用不能状態に陥っていたが，午後1時30には回復したとのこと。NTTのサイトには，その障害報告が記載されていた。
これだけ立て続けにトラブルがあると，いやんなちゃうよねぇ。こっちは，その度に，モデムをリセットしたり，パケットモニタ動かしてPPPoEのパケット調べたり，なんてやってるんだから。おまけにこの日記も書かなくちゃいけないし。誰もそんなこと頼んでないって？ まあ，そうだけど。でも，疲れッちゃうよ。ホント。
2001年7月14日
午後2時30分頃，通信が断続的に止まる現象が発生。PPPoEを一度切断して再接続を試みるが，PPPoEサーバから応答が返ってこない。モデムのLINK LEDは点灯していたが，モデムを電源リセットし，再度PPPoEの接続操作を実行。しかし，相変わらずPPPoEサーバからの応答はない。NTTの障害窓口に電話するも，話中で繋がらず。再接続動作を繰り返していたら，40分頃，再接続に成功。通信は回復し，元の状態に戻った。おいおい，またかよー。
2001年7月13日
午後1時49分頃，またしても切断。今回は，モデムのLINK
LEDが点滅状態となった。つまり，回線のレベルで障害があったということ。しばらく待つと，モデムの点滅が終わり点灯状態（平常の状態）に戻ったので，接続ソフトで再接続を行うが，PPPoEサーバからActive
Discoveryパケットの応答が返ってこない。要するに，NTTのPPPoEサーバとの間で通信不能の状態のまま，ということ。数回繰り返すが回復の見込みがないので，モデムを電源OFF/ONによってリセットし，再度接続し直して，回復。
NTTに状況を聞くために電話するが，話中。10分待っても話中。うーむ。どうしたものか。
2001年7月4日
只今，午後8時を過ぎたところ。またもや通信不能となる。ぷららのDNSサーバにpingするが応答なし。もちろん，その他のIPアドレスにもアクセス不能。しばらく，インターネットにアクセスしていなかったので，いつから異常が起こっていたのかは不明。一度切断し，再度接続し直すことによって回復。DSLモデムのLINK
LEDは点灯したままだし，リセットもしていないので，モデムが原因ではなさそうだが，その先のどこに原因があるのかわからない。フレッツADSLはPPPoEによってトンネリングさせてプロバイダ（我が家の場合はぷらら）までパケットを運ぶので，その途中で障害が起こった場合は，pingやtracerouteといった，IPレベルのツールでは原因箇所を特定できないからだ。再接続すると回復するので，原因究明に熱心になれないが，今度トラブルがあったら，NTTに問い合わせてみよう。ちゃんと調べてくれるかどうか，そこが問題だから。
2001年6月24日
只今，日付が変わって0時19分。通信不能となる。一度切断し，再度接続を試みるが，PPPoEのサーバ（認証サーバとでもいうのだろうか）に接続できない。モデムのLINK
LEDは点灯した状態なので，回線上の問題ではなく，NTTのサーバに問題があるのだと思う。0時23分，正常な状態に回復。
今日は，夕方にも障害があった。突然『PPPoEの接続が切れた』という旨の警告ウインドウが画面に現れ，切断してしまった。このときは，モデムのLINK
LEDが点滅していたので，回線上で問題が起こったのだろう。モデムの電源を入れなおして，再度接続したら，復旧した。
正確に覚えていないが，2，3日前にも突然切断する事故があった。個人ユーザ向けのサービスというのは，この程度のものなのだろうか。導入から1ヶ月も経っていないので，その辺の判断を下すのは早いかもしれない。ただ，単に事故が起こるというだけでなく，回線上に問題が起こったときにモデムをリセットしないと復旧しないのが困る。サーバを設置した場合に，回線異常に気がつかないと，いつまでも死んだままになりかねないからだ。監視システムのようなものを使うという案もあるが，モデムは手動でしかリセットできないのだから，そこに人がいないと復旧できないので意味が無い（電源からリセットできる装置を使えば別だが）。DSL回線でサーバを繋ぐのは危ないかなぁ．．．．
2001年6月14日
我が家にADSLが開通した。利用したサービスは，NTT東日本の『フレッツADSL』と，ぷららの『フレッツADSLセット』だ。一般消費者向けのADSLサービスをそのまま導入した形といえる。我が家はISDNなので，ADSLを導入するには
(1)電話をアナログに変更してADSLと重畳させる
(2)電話とは別に新たにADSL用の線を引く
という二つの選択肢があったのだが，(2)を選んだ。(1)だと電話番号が変わってしまう，(2)だと月額料金が2000円程度高い，という難しい選択を迫られたのだが，結局，一時的な利用で終わるかもしれないADSLのために電話番号を変えるのは面倒だったので(2)にした。(2)だと新たに線を引くので，工事費も余計にかかる。我が家の場合は約1万円だ。
今日の午前中，その配線工事があり，それが終わって，パソコンに接続用ソフト（実体はPPPoEプロトコルのドライバ）をインストールして接続を確認し，そして，ぷららのWebサイトで申し込みを行って，使い始めたところだ。
ADSLで一番気になるのはスループットなので，開通後最初にそれを試した。NTTが用意している試験用ページでテストすると，ナント100kbps程度しか出ない。もう一度試すと，さらに数字は悪くなる。速度の変動も大きい。何度も試すうちに，どんどん数字は悪くなり，そのうち，パケットが流れなくなった。ありゃりゃ，どうしたことか。NTTの障害窓口に電話したら，モデムの電源をOFF/ONして一度リセットしてみろ，とのこと。試してみると，380～385kbpsのスピードで安定して通信できるようになった。ADSLモデムは，ノイズが混入すると，その周波数帯を避けて信号を流すため，速度が遅くなるのだが，回線状態が回復しても一度避けた周波数帯を回復させることはない。だから，スピードが遅くなったら，そのままにせず，リセットした方がよいとのことだった。そういえば，以前，そんな話を聞いた覚えがある。とにかく，380kbps近辺というのが，我が家でのADSLの実力なのだろう。今回の申し込みで分かったのだが，電話局から我が家に伸びる電話線の延長距離は約4.5キロメートルということだった。地図上の直線距離でみると2キロ程度なのに，電話線の長さはそれをはるかに超えている。申し込み時に，『速度は低い。通信できない可能性もある。それでもいいか』と丁寧に電話で確認してきたくらいだ。だから380kbps近辺という数字は仕方ないのかもしれない。調査統計を見ても，その程度だ。しかし，下り1.5Mbpsというカタログ値からすると，少し残念ではある。3年ほど前，ミクロな地域格差が近い将来発生する，といった記事を日経バイト誌に書いたが，それが現実になってきた。
それから，スループットに関しては，MTUの調整によって変動する可能性が高い。MTUを調整してパケット長をできるだけ長くした方がデータ転送の効率が高くなるからだ。普段使っているWindows
2000にはPath MTU Discoveryという機能があり，自動的にそれを調節してくれる。NTTの技術資料によれば，フレッツADSLのMTUは1454バイトであり，Windows
2000はちゃんとその値に設定してくれるのだ。また，ウインドウサイズも転送効率に影響する。こちらは，デフォルトで約17Kバイトに設定されていたが，最大値の64Kバイトに拡大した。NTTの試験用ページへのアクセスならエラーは起こらないだろうから，ウインドウサイズは大きい方が良かろう，という荒っぽい考えだ。380kbpsという値は，その条件で計測したものだ。なお，Windows
2000はMTUを自動調整してくれるが，そうしないOSもある。その場合はMTU値を変えて試してみるとよいだろう。ウインドウサイズも，本当は，値をいろいろ変えて試してみた方がよい。
この他には特筆すべきことはないのだが，一つだけ，疑問点がある。この日記には書いていないが，実は2000年秋にイーアクセスのADSLサービスが始まった際，それに申し込み，断られた，という出来事があった。NTTから線が空いていないという回答があった，という理由説明だった。しかし，線に空きはないはずなのに，フレッツADSLは開通した。どうしてか？
2000年9月5日
お昼前，NTTコムからメールが来た。午前2時5分頃から2時25分頃にかけて中継回線の故障があり，その通知とお詫びであった。決して迅速な対応とはいえないが，それを責めるつもりはない。以前（1998年1月28日）は大きな事故だったにも関わらず，何の連絡もなかったのだから，それに比べれば大きな進歩だと云いたいのだ。8月の回線増強工事といい，ようやくNTTコムは『まとも』になってきたようだ。
もっとも，そんな呑気なことが云えるのは，当方がインターネットで日々の糧を稼いでいないからだ。障害は困るが，過剰品質より低価格を求めているのだから，その辺は割り切って考えているのである。
NTTコムがまともになってきたのはありがたいが，この程度で満足してもらっては困る。CATVはダメだったが，近々，DSLのサービスが我家の周辺地域でも始まる。それに負けないよう，NTTコムにさらなる努力を願いたい。
2000年8月9日
今日は珍しく良い出来事のネタである。先週，我家の地域で回線の増強工事を行う旨のメールがNTTコムから届き，その工事が昨日実施された。そして，年明けからの一大懸案事項だったOCNエコノミーの速度低下が解消された。その辺の事情は具体的に説明した方がよいだろう。それ以前は，昼間の時間帯にファイルをダウンロードしようものなら，スループットが20kbps以下（つまり旧式のモデム以下ということ）に低下するのが日常だったのが，今日は100kbps近くまで回復しているのだ。OCNエコノミーに加入したのは3年前だが，その当初以来，昼間からこんなに高いスループットが出るのは初めてのことである。もちろん，夜間は利用者が少ないから，この程度のスループットが出ることは珍しくないのだが，昼間の時間帯は速度が低下するのが常だった。だから，画期的といってよい。いわゆる専用線接続と遜色ないレベルと言ったら言い過ぎだろうか。工事の連絡が1週間前というのは少し遅いという感もあるが，それでも，今までは何の連絡もなしにニュースサーバを止めたり，事故があっても何の説明もなかったのだから，これも画期的な進歩といえる。やればできるじゃないかー，その調子でがんばってくれよぉー，NTTコム。
2000年4月x日
CATVインターネットへの切り替えを検討していたが，取りやめにした。理由はいくつかある。一つは，プライベートアドレスを使う点だ。CATVインターネットはCATVの網が一つのLANとして動作する。そこにグローバルアドレスを割り当てるには，このLAN全体に接続するマシンの数だけグローバルアドレスを用意しなくてはならなくなる。個人ユーザのパソコンの台数を考えれば，それは難しい。当方は法人ユーザ向けのサービスを受ける予定だったが，CATVのLANにはプライベートアドレスを割り当ててしまうため，法人ユーザにだけグローバルアドレスを割り当てるにはいかないのだ。個人ユーザ用と法人ユーザ用でCATVのチャネルを分け，LANを分離すればよいのだが，LANを分離するほど，加入者数が多くはないのだろう。
プライベートアドレスに関連してDNSも問題となる。プライベートアドレスを割り当てると，DNSの設定もグローバルアドレスを使う場合とは違ったものになる。当方は，DNSを当サイトの中に置きたかったのだが，そうすると，少し設定が面倒になる。その辺を確認しようと思い，メールで問合せたのだが，返答が返ってこない。ISPがこちらの要望に応えられないのか，それとも，別の理由があって返答できないのかわからないが，いずれにしても，質問に対して何も返答しないISPと契約するつもりはないので，この話はこれで終わりである。多少の制約があっても，速度向上のメリットの方が大きいと考えていた。その程度にまでOCNエコノミーの品質は低下している。だから，残念な気持ちが残る。CATVもしっかりしろー。
東京23区内でxDSLのサービスが始まっているが，近いうちに，鶴見にもサービス地域が拡大されることを期待して，それを待つことにしよう。
2000年3月22日
朝，郵便受けにCATVインターネットのちらしが入っていた。そのちらし自身は，一般ユーザ向けに6,000円で繋ぎ放題というサービスの開始を知らせるものだったのだが，片隅に下り2Mbps，上り512Kbpsの常時接続が月額3万数千円という文字があった。もしや，と思ってCATV業者のWebサイトを覗くと，そこにはグローバルアドレス取得オプションというのがあった。6,000円のサービスではクライアントしか接続できないが，3万数千円のサービスにそのオプションをつければ，サーバを設置できるのだ。今，加入しているOCNエコノミーと同程度の価格で，単純な速度比較ではあるが下りが8倍，上りが4倍になるのである。
こうなることを望んでいたのだが，実は，あまり期待していなかった。CATVは一地域一事業者に規制されているので，自分の地域でサービスしている業者がサービスを提供してくれないことには，いくら他の地域で格安のCATVインターネットサービスが行われていても意味がない。我家の地域をカバーするCATV会社もインターネットサービスを提供しているのだが，それは企業向けの高額なサービス（確か月額98,000円程度）だけであり，一般向けの低価格サービスには消極的だと思っていたからだ。
Webサイトの内容では細かいところがわからないので電話で問合せると，実は，グローバルアドレスオプションには仕掛けがあり，NATによって固定的にプライベートアドレスに変換したものが割当てられるとのことだった。NATのアドレス変換があるとVPN，VoIPといった技術を使えなくなるが，それ以外の普通の機能であればサーバ設置も問題ない。当面，VPNやVoIPを使う予定はないし，試験的に試すだけなら，ダイヤルアップ接続でも何でも試すことはできる。また，バックボーン部分の状況を聞くと，3万数千円のサービスは一般向けの6,000円のサービスとはインターネット接続部分が分離されており，まだ回線の余裕がかなりあるとのことだった。それを聞き，ほぼ気持ちは決まった。OCNさんさようなら，CATVさんこんにわ，である。サービスが始まるのは来月だというが，我が家の工事はいつかなぁー。
2000年1月21日
いつからなのかはっきりと覚えていないが，年が明けてからネットワークの調子が悪い。少し混んでくると，断続的にパケットロスが発生しているようで，ブラウザを使っているとタイムアウトが起こる。一度それが発生すると，数秒から数分程度その状態が続き，その後復旧する。復旧するといっても，混雑状態が解消されるわけではなく，ブラウザのタイムアウトが起こらない程度に回復するだけだ。PingPlotterで計測すると，NTTのバックボーンが混雑している様子で，NTTのバックボーンから外に出て行く出口付近までのRTTが1000～5000ミリ秒程度となる。この数字は一般的に考えれば相当大きい数字だが，昨年までは8000ミリ秒程度にまで遅れが増大しても，パケットロスは少なく，ブラウザでタイムアウトを起こすことも少なかった。それが，今は1000ミリ秒程度でもパケットロスが発生している。
ネットワーク性能に関する話題では，RTTが短い方が性能は良いとされる。今回のケースでは，PingPlotterでの計測では5000ミリ秒を超える頻度が少なくなり，以前と比べてRTTの値は短くなった。しかし，RTTの長短と性能の相関関係はパケットロスが起こらない前提での話だ。今回のように，パケットロスが起こるようでは別の話になる。つまり，パケットロスが起こるとTCPプロトコルの再送動作が起こり，それによって転送速度は極端に低下する。その速度低下はRTTが云々というレベルではない。RTTよりもパケットロスの方が，性能に与える影響は何倍も大きいということだ。
推測に過ぎないが，ルータかフレームリレーなどの機器が変更され，バッファ容量が少なくなったのだろう。あるいは，バッファ容量を増やさずに，太束回線への収容数だけ増やすことにより，末端の回線当たりに換算したバッファの実質容量が減少したのかもしれない。加入者数の増加などを考えれば，こうしたネットワーク構成の変更は日常の行事だろうが，こうした事態を予測していたのだろうか。ただでさえ品質の低い低価格サービスが，より低品質化し，ユーザは困っているんだぞー！。
1999年9月28日
事故もなく時が過ぎたため日記のネタがなかったが，久しぶりにネタが出てきた。ここ1～2週間，ニュースサーバに接続できず，おかしいと思っていたら，ニュースサーバの構成が変わっていた。もちろん，事前の連絡も，停止していた間の事情説明も何もなかった。
問題なのは，これが事故ではない点だ。確認したわけではないが，今回の停止はサーバの移行作業に伴うものだろう。移行作業の実態は知らないが，普通なら止まっても数時間がいいところではないのだろうか。それが，1週間以上も停止するとはどういうことだろう。しかも，何の連絡もないのだ。メールでの通知がないばかりか，Webサイトにも何も掲載されていない。元々OCNは購読できるニュースグループの数が少なく，ネットニュースを軽視している印象を持っていたが，このような事態は軽視云々という以前の問題である。何考えてんだぁ！？
1998年1月28日
この日，大きなトラブルがあった。昼頃から速度の低下が目立ち始め，夕方6時頃にはインターネットとの通信が不能となった。午後8時近くに復旧したので，通信不能が2時間程度，速度低下が半日，という比較的大きな事故だった。
大きな事故だったのに，こちらには何も連絡がなかった。OCNスタンダードのユーザにはメールで通知が来たという噂も聞いたが，OCNエコノミーのユーザは軽く扱われているのだろうか。また，後でWebサーバのページを読むと，些細な事故が起こったという程度の説明しか載っていなかった。事故が起こるのはやむを得ないこともあり，一方的に非難できないが，その事後処置が悪いのは十分非難に値する。しっかりしろ！！
1997年11月11日
原稿を書いたのはいいが，打ち合わせで上がった話題を一通り盛り込んで原稿を書いたら，予定の2倍近くの分量になってしまった。そのままでははみ出してしまうので半分の量に削ったが，削った部分はもったいないから，その一部をここに載せておこう。その原稿の大筋はこの日記に書いてあるようなことだから，その部分だけ読んでも，意味はわかるだろう。
*****［削った部分］*****
OCNエコノミーは低価格なサービスではあるが，だからといって特殊なものではなく，インターネットの専用線接続の一つに過ぎない。フルサービスの専用線接続との違いはネットニュースの配信がない点くらいだ。
スループットを保証しないのは事実だが，スループットを保証してくれるインターネットなどは他にも存在しないのだから，それが根本的な違いとは言えないはずだ。要は程度の問題なのである。
しかし，冒頭に書いたようにpingでタイムアウトするような事態が頻発するのであれば，それはスループット保証とは別問題だと考えた方がよい。少なくとも私はそう考える。pingでタイムアウトするような状態は使用不能を意味するのであって，それが頻発するようであれば，スループットが云々という以前の問題だからだ。
ただ，そうした問題は解決可能だと楽観視している。OCNのバックボーン部分はOCNエコノミーだけでなく，OCNスタンダード（1.5Mbps）やOCNエンタープライズ（6Mbps）と共用しているのだから，その部分の容量はそれなりに確保しているはずであり，末端での混雑を避ければ，そこそこのスループットを出せるはずだからだ。私はそう考えてOCNエコノミーを導入した。
*****［削った部分終わり］*****
それから，その原稿ではスループットの問題はほぼ解決したように書いてある。原稿を書いたときはそうだったし，実際最初の頃よりはマシになったのだが，時として遅くなるという状況は今も続いている。末端部分でのトラフィック増減が大きく影響するのだろう。安いのだから仕方がない，という考え方もあるが，もう少し工夫の余地もあるように思う。一つの局での加入者数が増えれば，上位局への接続に用いているフレームリレーの速度を上げることもできるはずで，そうすれば末端が少し太くなり，統計的に１ユーザのトラフィック増減の影響が減るからだ。その辺は今後に期待しよう。
1997年10月x日
日経バイト編集のSさんから，連絡があった。OCN導入に関して話を聞きたいとのことだったが，会って話し始めると，どうも怪しい雰囲気になってきた。こちらの話を聞きたいというより，OCN導入の体験談を書け，ということらしい。このところ少し多忙だが，せっかくなので引き受けることにした。
1997年10月12日
このところ調子がよいようだ。何とかしてもらおうとデータをとって，さあ，これから交渉しようと思ったら，何のことはない，調子良く動くようになってしまっている。うーむ。しばらく様子を見ようか。
1997年10月7日
この1週間ほど思い立ったときにネットワークの状況をpingとtracert（NTのtraceroute）で計測していたが，これでは状況が把握しにくいので，毎日1時間おきに計測するようバッチコマンドを作成した。そのデータを基にNTTに交渉することにしよう。24ユーザでフレームリレーを共有するというOCNの仕組みから考えれば，ときどき少し遅くなるのはやむを得ないが，許容限度がある。tracertの結果を見るとわかるが，OCN内部での遅延が大きいことも多々ある。OCNサイト（下記URL）
http://www.ocn.ne.jp/ocn/in/eco/throughput.html
で公表されているスループットのデータとも隔たりがあるように感じる。
このデータは国内外のめぼしい（要するに頭に思い浮かんだもの）プロバイダのWebサーバに対してpingとtracertでパケット到達時間を計測したものだ。データを加工している時間がなかったので，生データのままだが，応答時間を眺めれば，どの程度のものかは察しがつくだろう。
1997年10月x日
国内外の主なISPのサーバへの到達時間をpingとtracertコマンドで調べるバッチファイルを作って，実行してみた。tracertの結果を見ると，OCN内部で込み合っている様子。インターネット側で遅ければ仕方がないが，その手前，OCN内部での遅延が結構大きそうなので，NTTになんとかしてもらいたいと思う。
1997年9月30日
応答が遅いのはサーバだけの原因ではなく，ネットワークにも原因がありそうだ。夜7時半頃，BTNISにダイアルアップ接続し，自分のサーバにアクセスしたが，誰もアクセスしていないにも関わらず，ページが出てくる前にタイムアウトしてしまった。他のサイトにはアクセスできるので，OCNの網に問題がある可能性が濃厚。再び，OCN側からあちこちのサイトにアクセスしてみるが，やはり遅い。アクセスするタイミングによっては，全然応答が返らない。pingやtracertで測定してみたが，そのときはほとんど問題なく動いているように見えた。OCNの仕組みから考えると，こういった現象が発生するのは十分考えられるが，それにしても，遅いときは全く使いものにならない。
1997年9月29日
夜12時頃，いろいろとアクセスしてみたが，ほとんどのサイトは全く，ホームページがでてこない。OCNのホームページも恐ろしく遅い。1分以上かかった。yahoo.co.jpはすぐにホームページが出てきたが，yahoo.comは遅かった。Netscapeはまあまあのスピード。ciscoはかなり遅い。どうも，サーバが込み合っている雰囲気。
1997年9月28日
マシンのセットアップも終わり，Webのコンテンツの仕込みに入った。途中，よそ様の様子を見ようと，インターネットにアクセスしたが，個人のサイトに行こうとすると，パタととまってしまう。会社関係のサイトはそれほど遅くはないのに，個人のサイトは全然。
1997年9月27日
マシンのセットアップをいじったり，カミさん用のマシンを用意したりと，あまり，インターネットにアクセスする時間がなかったが，速度はまあまあ，といったところ。やはり，突然遅くなることがあるような雰囲気。
1997年9月26日
午前中に工事予定だったが，工事担当者が到着したのが11時過ぎ，作業が完了したのが2時過ぎであったとのこと（家内が応対）。
同日，帰宅後，さっそく接続を試してみた。NetVehicleのWAN側の設定がわからなかったが，富士通のサイトのFAQにOCN接続時の設定方法が書いてあり，そのとおりに設定すると，いとも簡単に開通した。
NetVehicleはブラウザで設定するようになっており，その中に「かんたん設定」というページがある。そこにある，IPアドレス，サブネットマスク，回線速度，接続形態（端末型かネットワーク型か）という4項目に記入するだけで設定は終わる。あっけないほど簡単だ。
1997年9月25日
DNSサーバのアドレスの違いを放置しておいたが，工事日が明日に迫ったので，あわてて，DNSサーバのアドレスの違いをメールで通知した。メールの通知先は，DNS関連の連絡窓口（dns-desk@ocn.ad.jp）。何の返答もなかったが，当日無事開通したので，設定は変更してくれていたのだろう。
1997年9月20，21日
サーバの準備を行う。サーバはWindowsNT。その理由は，最初に書いたようにWebサーバのバックにRDBMSを置くために他ならない。手元にあるRDBMSはSQLServerだけなので，これを使うにはNTという選択肢しかないのだ。PC-UNIXでフリーのDBMSを使う方法もないではないが，データのメンテナンスにAccessを使ったり，バックエンドのアプリにIDCやASPを使ったり，といった手軽さを求めると，やはり，選択肢はNT+SQLServerなのかもしれない。Oracleでもかまわないのだが，自分ではOracleのライセンスは持っていない。
その他，DNSにはBind for NTを使用。最初，DHCP，WINS，MS-DNSを使おうかと思ったが，OCNのページによれば，WINSの使用は控えるようにとのことだった。MS-DNSにこだわる理由はなく，DHCPやWINSだって本気で使おうとしていたわけではないので，あっさりBind
for NTに鞍替えした。
メールサーバは同じくSoftware.comのPost.Office。10ユーザ版は無料だし。メーリングリスト機能もあるから，ま，いいか，という程度の考え。名前も良く聞くし。
他のマシンのセットアップもあり，週末を使いつぶしてしまった。Post.Officeのアンインストールには要注意。スタートメニューのアンインストールを実行すると，残骸が残り，再インストールができなくなる。
1997年9月18日
NTTからFAXが届いた。工事日が9月26日になるのこと。その他設定情報も合わせてFAXに記述されていた。ただし，プライマリDNSサーバのアドレスに誤りがあった。NTT側では，ホスト番号の1をルータに，2をDNSサーバに割り当てる方法をデフォルトとしているが，こちらはホスト番号1をDNSサーバに割り当てたためだった。担当営業にFAXでその旨通知していたにも関わらず，NTTのデフォルト設定で工事する旨，記述されていた。
1997年9月10日
InterNICのサーバでドメイン名取得の手続きを実行。.COMドメインの申請方法は申請用のメールを送るだけの簡単なものだ。メールはコンピュータで自動処理されるため，その書式が決められているが，それを理解する必要はない。申請用のメールを作ってくれるWebのページが用意されているからだ。
そのWebページを使って必要事項を数ページに渡って記入した。ページの記入項目には自分のメールアドレス記入欄があり，記入終了後しばらく待つと，Webサーバが作ってくれた申請用メールが送信されてきた。後は，その内容を確認して，InterNICにメールで送信するだけで申請作業は終わりだ。
10分ほどで受信確認のメールが到着。ただ，これは登録作業が終わったわけではなく，単に申請メールの受信確認だけなので，要注意。登録が終われば通知がくるとのこと。同時に，ハンドル番号が通知された。以後，問い合わせなどにはそのハンドル番号で照会することになっている。
その後10分ほどで，登録手続き完了のメールが到着。ただし，root
Serverのアップデートは1日1回だけらしい。夕方までの登録であればその日のうちにroot
Serverにアップデートされるが，それを過ぎると翌営業日の登録になるとのこと。一連の手続きの説明は，InterNICのWebサイトに記載されている。
http://rs.internic.net/domain-info/domflow.html
英語だがフロー図付きで丁寧に書かれている。
また，.COMドメイン取得費用は最初の2年間が100ドルで，Webによるクレジットカードでの支払いも可能だ。
その日の午後，InterNICのページでステータスを確認すると，close（作業完了）となっていた。この完了通知をNTTの営業担当にFAXで通知し，NTT側の作業を進めるよう依頼した。
1997年9月9日
NTTからFAXにてIPアドレスの割り当て，セカンダリDNSサーバのIPアドレスとホスト名の通知があった。
1997年9月1日
NTTから何の反応もないので，担当営業に電話してみた。IPアドレス申請中なので，アドレスが取れたら通知するとのこと。
1997年8月x日
NTTに加入申し込み書を発送。カミさんに発送を頼んだため少し遅れたが，大勢に影響はなし。
1997年8月24日
OCN接続用のルータとサーバPCをTwoTopのWeb通販で発注。富士通製ルータ（DSU内蔵のNetVehicle-EX3）にした理由は，TwoTopで特売をやっていたこともあり安かったこと，一応の機能がそろっていたこと，OCNでの実績があることなど。
1997年8月19日
.COMドメインを取得する場合のOCN申請手順について，サポートデスクにメールで問い合わせした。同日夜，返答があった。前回に続き，サポートデスクの対応は素早い。こちらが加入申し込み書を送ると，NTT側でIPアドレスを取得するので，セカンダリDNSのIPアドレスやホスト名と併せて通知するから，それをInterNICの申請項目に記入すればよい，とのことだった。サポートデスクの方が要約してくれたのだが，手順の概要は下記のとおり。なお，期間は大体の目安とのことなので，もっと時間が必要な場合もあるとのこと。
1）お申し込み書のご提出（お客様）
（仮ドメイン、ホスト名）
↓
2)申込書受領/設備検討実施（ＯＣＮ）
↓２～３週間
3)ＩＰアドレス事前割当（ＯＣＮ）
SecondaryDNS、Host名、IPアドレス通知
↓営業担当者より連絡
4)interNICドメイン名申請（お客様）
↓２～３日
InterNIC登録完了
↓
5)登録ドメイン名／Host名ご連絡（お客様）
↓メール
6)工事日調整（ＯＣＮ）
↓ご連絡後約３週間
7)開通工事（ＯＣＮ）
1997年8月x日
NTTの支店からNTT加入申込書が届く。記入項目はだいたいわかったが，ドメイン関連の項目の記入方法が不明。
1997年8月x日
InterNICのサイト（http://www.internic.net）で.COMドメイン名の取得方法を調べた。ドメイン名取得申請の前に，ISPと打ち合わせし，プライマリDNSのIPアドレスとホスト名，セカンダリDNSサーバのIPアドレスとホスト名を決めておく必要があることが判明した。
.COMドメイン名を取得する理由は，日本のドメイン名割り当てのルールにある。日本のJPNICが割当てているドメイン名はほとんどが法人や団体向けのものであって，個人向けのものではない。唯一の例外が地域型ドメイン名というもので，MIZUYOSHI.YOKOHAMA.KANAGAWA.JPというように，その住所を元にドメイン名を割当てる方法なのだが，これだとドメイン名がやたらと長くなって覚えにくいし，タイプするのも面倒だ。引っ越したらどうするのかという問題もある。だから，米国からCOMドメインを取得したのである。
1997年8月6日
いきなりOCNを申し込んでも良かったが，一応似たような低価格サービスの状況も調べてみた。OCNアクセスラインを使用して低価格インターネット専用線サービスを提供している各社に連絡し，サービス状況を問い合わせてみたのだ。しかし，自宅のある横浜市鶴見区（局番580地域）のサービス予定は決まっていない，との返事しか返ってこなかった。｢なんだ，OCNエコノミーしか選択肢はないんじゃない！調べるだけ時間が無駄じゃん。｣とガッカリ。
我が家は横浜の奥地で，町外れといった雰囲気の場所にあり，利用者が少ないためなのだろうか。インターネットによって地域間の格差が縮小されるというような話を聞くが，それは地方都市と東京の差が縮まるだけであって，都市部とそれ以外は逆に差が開くかもしれない，と予感させる結果でもあった。
ということで，OCNホームページに記載のメールアドレスにOCN加入手続き方法，費用などの詳細を問い合わせた。1時間ほどで，返答があり，加入手続きと費用が判明。NTT営業支店の担当営業から申込書を送ってくるとのこと。
1997年7月25日
NTTのOCNホームページを見て，オンラインサインアップが可能なOCNスタートパックの存在を発見。その場で，OCNスタートパック，送付希望メールを発進。後日わかったが，スタートパックはOCNダイヤルのユーザ向けであった。考えてみれば，OCNエコノミーをオンラインサインアップできるなんて虫が良すぎたかもしれない。
1997年6月23日
自宅の地域でOCNエコノミーサービスが始まった。OCNの発表があったときから，黙って見過ごすわけにはいかないと思っていたが，最初は自宅地域がカバー範囲に入っていないこともあって，業界人の一人としてウォッチするだけで，所詮は他人事だった。それが，いよいよ自宅もカバーされるようになったのだ。他人事で済ますわけにはいかない。なんとかしなくちゃ。
個人でインターネットと専用線接続できるわけだから画期的なことには違いないのだが，年額50万円近くの出費を覚悟せねばいけない。やはりそこが一番の問題だ。いくら業界人だからといって，自宅をインターネットに接続して収入が増えるわけじゃない。第一，自宅からは今使っているISDNで十分である。プロバイダのWebホスティングサービスを使えば，自分のWebサイトは持てるし，メーリングリストだって使える。普通に考えれば，自宅に専用線を引く理由などほとんどない。できないことといえば，Webのバックエンドにデータベースサーバをおくことや，自分達のバンドの演奏を流したり，といったことくらいのものだ。
でも，待てよ，普通じゃできない，そういったことをやってみるのも面白いかもしれない。年間50万円近くの出費と言ったって，車の維持費よりは安いだろう。ケチなことを言わず，この際やってみるべきなんじゃないかな。
と，妙な理屈をでっち上げ，自分を納得させた。
|
