北Ｑりそーす
最終更新: 2004/12/06
[北Ｑネットの接続環境]
- 北Ｑから公開されている情報
北Ｑ からはサービス内容や料金案内を始め、 Ｑ&Ａ なども公開されています。 でも、2000年12月1日からのサービス改定内容の反映が間に合っていない部分が目立つようです。FAQを更に充実させる事で、もっとサポートの負担を減らせると思うのですけど人手(予算) 不足なのでしょう。
でも、無駄かなー、読む人が居ないようだから(笑、
ここ「北Ｑりそーす」ではFAQやユーザー支援からは外れた話題を取り上げる事と致しませぅ。
- 使用されているケーブルモデムについて
FAQ にも記載されているのですが、 今、北Ｑでは多種のモデムが混在して利用されているようです。 実際に使われているとされているモデムは、 LANcity製 LCP(ゴツくて大きく重たいの、前に利用していましたが、 故障交換となり雄姿を拝めなくなりました。 このモデム交換に伴い、ここに書かれている情報にも一部、 新旧モデム間でネットワーク環境の食い違いが見られるように成りました。気付いたところは併記したり、 書き直していますが、追いついていません。2002/01/05)、 NortelNetworks CM-115 とフジクラ製 FCM-110R です。 以上の３機種は、北ＱのWeb上で公表されているモデムですが、 他に、ファミリー契約の古いユーザーでは、LANcity製のルータタイプのモデム(LCb) も利用されている(orいた)ようですし、他にも公表機種と互換性の在るモデムが利用されているかも知れません。因みに家では旧モデム(LANcity LCP)の故障交換により、フジクラ製 FCM-120U に切り替わりました。 で、取り合えず公表されている３種のモデムと手元の FCM-120U についてケーブル上の伝送形式、公称速度を調べてみると、 ・・・えー、速度実験への参加中にFCM-120Uから新たなモデムFCM-140Uへ切り替わりました(笑)。これで北Ｑのモデムは５種類と更に混迷の度合いを深めました。北Ｑでは、サービス改定も睨みならがら順次新型モデムへのリプレースを予定しているようです。で、現状を纏めると次の表の通り。
メーカと製品名 上り公称(最大)速度と変調方式 下り公称速度と変調方式 LANcity LCP(*1) 10Mbps QPSK 10Mbps QPSK NortelNetworks CM-115(*2) 5Mbps QPSK/10Mbps 16QAM(DOCSISとして推測) 30Mbps 64QAM/40Mbps 256QAM フジクラ FCM-110R(*4) 5Mbps QPSK/10Mbps 16QAM(*3) 30Mbps 64QAM/40Mbps 256QAM フジクラ FCM-120U(*4) 5Mbps QPSK/10Mbps 16QAM(*3) 30Mbps 64QAM/40Mbps 256QAM フジクラ FCM-140U
(SAMSUNG SCM-140U)5Mbps QPSK/10Mbps 16QAM(*3) 30Mbps 64QAM/40Mbps 256QAM テラヨン TJ 735(*5)
(TJ715の日本向け)30Mbps 64QAM(*5) 30Mbps 64QAM/40Mbps 256QAM 表を見ると、北Ｑは開設当初は対称型(LANcity)モデム。現在は非対称(業界標準規格のDOCSIS)モデルに切り替わっています。
- *1、最早、メーカーと製品情報を探し出せない。
- *2、製品情報は見つからない。
- *3、利用を許す帯域幅により変化、最大は3.2Mhzの帯域を利用した場合。
- *4、製品はSAMSUNGからのOEM。サポートページからマニュアルやUSBドライバ(FCM-120U/140Uでも使えるかもかも？、但し自己責任って事で願います)も入手可能。
- *5、DOCSIS2.0実証実験で利用された物、本番ではモデムが異なるかも？。
- *6、帯域幅、変調方式により変化、最大は 6MHzを利用しての64QAM(30Mbps)。
現在でも、LANcityの対称型モデムの利用は続けられています。が、北Ｑへの新規加入ユーザーや旧型モデムの故障交換などが行われると白くて小さくて軽い(消費電力も少なく熱くならない)フジクラ製の新型モデムが設置されるようです。
現在LANcityモデムを利用している人は貴重品だと思って下さい。重厚な作りで機械的にスゴク丈夫。たぶん乗っても壊れないし、少々消費電力が多いのと100Bast-TXやUSB接続への対応等で見劣りはしますが、最近のチャチなプラケースのモデムには見られない貫禄を持った意匠はリッパ、性能的にも今のサービスなら支障無い筈ですし、変調方式が双方向QPSKで少しノイズに強いかも知れないし、長期間運用されてきたセンターモデムは枯れてて安定しているし・・・、と、慰めの言葉を並べておきます。
DOCSISやCATVネットワークについての参考資料。(CQ出版Interface 2001年9月号への掲載記事で、 ネットワンシステムズ(株) からの公開資料) http://www.netone.co.jp/doc/kiji/if200109_iida.pdf
- ケーブルモデム関連のトラブルについて
- 落雷被害
落雷によるモデムの破損(焼損ですね)は、毎年発生しているようです。多い時には一度に何(十)台も、 しかも、運が悪いと繋いでいたパソコン諸共一緒に逝ってしまわれるようです(合掌)。 なので、一応、北Ｑからは「雷が近付いたらモデム、パソコンの電源を落とし電源ケーブル、 LANケーブルを引き抜いておけば安全です」なんて案内がされたりしています。 もし、心配で心配で仕方なければ、使う時だけ繋いで終わったら片付ける。なんて使い方も 「あり」かも知れませんが便利じゃないです。後は願掛けのつもりで最近沢山出ている怪しげな 避雷グッズで武装するとか(大丈夫、絶ー対、効果在りません。カミナリはツオイですぅ)、 凝り性な人はモデムとパソコン間を光カプラで繋ぐとか(笑)で精神的な雷対策は完璧でしょう。 でも、まぁ、宝くじに当たるような物(年末ジャンボより遥かに高確率ですけど)ですから 当たってから、事態の復旧に勤しみ、これを楽しむという付き合い方も良いと思います。
- MACアドレス
モデムへのパソコンを繋ぎ代えたり、NICを交換したりした時に、ネットワークへの接続が 出来なくなる事があります。これは、モデムが接続に利用されるNICのMACアドレスを記録する為 に起こるのですが、この時はモデムのリセット(電源のOn/Off)で大概は解決します。 でも、接続端末数を超えるネットワーク機器(特にネットワークプリンタとか)をハブを通して接続 していたりすると、操作手順が少し面倒な事に成るかもしれません。 また、北Ｑでは接続方式としてローカル固定IPとグローバルIP(DHCPで取得)をユーザーの裁量で選択 できるのですが、DHCPの利用には予め利用する端末のMACアドレスを北Ｑに提示し登録が必要とされます。 未確認なのですが、今は、まだ、未登録の状態でもDHCPを利用してグローバルIPを取得し利用する事が 出来るかも知れません。 ただ、この場合、ある日突然、接続できなく成るかも知れないので (一応北Ｑの定めた利用条件なので)注意(及び覚悟、笑)が必要です。
現状を確認する為テストしてみました。 私の所では、既に北ＱにMACアドレスの登録を済ませていますが、試しにモデムを別の 未登録(エコノミーの基本契約では一つしか登録できないからね、笑)のNICに繋ぎ代え DHCP接続の様子を見た処、正常に利用可能でした。ただし、短時間のテストなのでリース時間の 延長操作など全てのDHCP機能やサービスに渡る完全なテストは出来ていません。 けれど、特に問題は無い様です。北Ｑのアドレス登録は管理目的、中でもグローバルアドレスの 需要把握を目的としてるのでしょう。(2002/03/29)
- 流合雑音
CATVでのインターネット接続(ケーブルモデム)を利用していると「おまけ」として漏れなく 付いて来るのが、この「流合雑音により・・・」とか言われる通信不能状態です。 こいつは、時、場所(度重なる不運な所は在るようです)を選ばずに行き成りセンターモデムとの 通信状態を示すLED表示がプツリと消えたり、点滅を始め、短いと数秒から数分、長いと数時間後に 何事も無かったかのように復活を遂げる厄介な代物です。相手が雑音(ノイズ)と言う事で、 原因は無論、センター側では、その発生も確認できない事が多いようで厄介物の扱いをされています。 伝送路の不具合やCATV加入宅での工事による末端処理の不具合が原因となる他、無線や家庭内機器の ノイズまで、原因と思われる物には事欠かない状況です。 また、この流合雑音には地域格差があるようで、殆ど影響を受けた事が無い地域 (私の所も殆ど遭遇しない幸運な地域)がある一方、長期に渡って障害が繰り返し報告される不運な 所が存在します。最近では随分改善されたようですけど頻発する接続不能障害については、 こまめにサポートに報告し、伝送路の調査等を行ってもらう事で対策を講じてもらう必要が あるようです。
- ネットワーク設定関連のトラブルについて
- 接続工事時の設定について
北Ｑでは加入時にはローカル固定IPで接続が開始される事に成っています。この為に、 各ユーザ毎のローカルIPやメールアカウント情報とDNS,GateWayなどのTCP/IPネットワーク設定に 必要な一連の情報がパラメータシートとして配布されます。 同時にWindows/Macについては設定手順書も用意されているので普通は手順書に従い必要な設定を PCに行う事で無事接続できる筈です。また、工事業者にも御願いすれば初期設定を行っての接続 確認まで行ってくれるようです。ただし、今は無くなったかも知れませんが、工事後のPC接続を DHCPによる接続で済ませてしまう業者さんが存在していたようです。 このような場合、DHCPでのグローバルIPの利用自体が問題と成る事は余り無いと思うのですが、 MACアドレスの登録状況や利用者自身に状況の認識不足が在ると、PCやNICの交換、トラブル時の 対応などの際、問題を引き起こす事に成りそうです。
- ネットワーク設定の間違い
最近は聞かなくなりましたが以前には、ローカルIPアドレスの衝突によるトラブルの報告などが 沢山ありました。今は、使用しているモデムの変更やセンター機器の対策などにより衝突事故 への対策が計られているかも知れません。 でも、稀に他のネットワーク設定、例えば「デフォルトゲートウェイとしてDNSサーバのアドレスを 設定した」とかにより意図せずにDNSへDoS攻撃(笑)が成立して他の利用者に迷惑を掛けたり。とか、 他人のマシンに意図せずして同様の攻撃(笑)を仕掛ける事に成ったり。とかの事故が発生 しているようです。CATV接続では利用しているPCが大きなWANの構成要素の一台となる接続形態で ある為、ネットワークの設定ミスから発生した自損事故が、時にネットワークの大渋滞を引き起 こす可能性が在る事に留意する必要があります。
- 接続機器によるトラブル
幸いな事に現在の北Ｑでは、ユーザ宅でのネットワーク機器について特に接続制限を設けていません。 つまり、流行のブロードバンドルータの利用も可能です。但し、接続契約数までのPC以外の接続機器に ついては、北Ｑのサポートを受ける事はできません。つまり自己責任でやって下さいと言う事に 成っています。例外的に、極一部の機器(ダイヤルアップルータなど)では、以前に北Ｑ内のルータと喧嘩 をしてネットワークに多大な混乱を招いた罪により永久追放処分(笑)を受けています。 また、同様の混乱を引き起こす機器が発見された場合、北Ｑでは、その所有ユーザの接続を停止し排除 する事を明言しています。実際には名の通ったネットワーク機器メーカ(元国産機専属メーカ除く)の製品 であれば支障なく利用できる筈です。
[思いつくままに]
- 自分(NIC)に届くもの
良く誤解されている人が居る様なのですが、CATV==LAN接続なので他人の通信がパケットレベルで 覗ける(盗聴)出来るのではないか？との話がありますが、これは困難、不可能です。 北Ｑを含め殆どのCATVによるネットワーク接続で、そのような事は有りません。
これは、ケーブルモデムがブリッジとして機能し利用者宛てのパケットをのみを通過するように しているからです。(モデムを操作して全てを通過させる事が可能かもしれませんけど、 通常は起こり得ません) ただし、ここで注意が必要なのは、利用者宛てに何が含まれるかが恐らく各CATVにより 若干異なるかと思います。北Ｑの場合、
に該当するパケットが届きます。
- 利用者の端末のMACに合致する物
- MACでブロード(マルチ)キャストされた物
- 利用者のケーブルモデムから発信されたパケット
*これ、どうもモデムに依存しているようです。新型モデムでは見えないらしい。
(北Ｑではローカル固定アドレスとして 10. のクラスＡアドレスを使用しています。 ユーザーのローカル固定アドレスは 10.2.XXX.YYY、 ケーブルモデムも固有の 10.3.XXX.YYY のアドレスを持ちます。でもモデムを交換したりすると、この対応は崩れます)
- NBTは通らない(でもCIFSは通る)(2002/03/30 加筆)
CATV利用で良く問題として取り上げられるWindows系のディレクトリ共有ですが、幸い(？)北Ｑでは、 TCP Over NetBIOS (通称NBT) として利用している幾つかのポート向けパケットが遮断されています。
調べる為に作った CGI (北Ｑドメイン+DHCPユーザ以外からの利用は出来ません)でTCPでの接続テストをしてみると、
67 (LANcityの場合、FCM-120UではDHCP衝突回避が図られている筈？)への接続が制限されている事が解ります。 UDP 67(68)についてもDHCPサーバの衝突を避けるため適切に遮断されていると思います。 (NBT関連のUDPについては確認できていません。LANciteモデムの場合はフィルタされていたようです。
137 (FCM-120Uでは、UDPが通るらしい、コンピュータの一覧は取れる？)
138
139
新しいモデムでもNBT関連のブロードキャストを受信する事が無いので、 遮断されていると思います)
この事から、北Ｑを利用する限りでは他のCATVで取り上げられるディレクトリ共有を利用した 侵入などの心配は無い筈です。
あっ、でもWin2Kの445には、要警戒ですね、
Windows系のディレクトリ共有についての訂正と補足
Windows環境の 2000, XP への進化に伴う加筆訂正です。
私自身が確認した訳では無いのですが、#北Ｑに集う少数(笑)の利用者からの情報を纏めると、 利用しているモデムがフジクラ製の場合、NetBIOSでの(ワークグループと)コンピュータの一覧が 取得できるようです。
実際のNBTを用いた他のコンピュータへのアクセスはモデムで遮断されているので、 この点だけを挙げると Windows 95〜Me での利用については、 以前に書いて在ったとおり安全と表現できるのですが、Windows 2000, XP を利用している場合、 新設された ポート番号 445 を利用した CIFS(Common Internet File System) による通信が北Ｑで遮断されない為、ファイル他の共有リソースへのアクセスが可能と成ります。
このCIFSを用いたリソース共有では、NBTの機能は一切必要なく (北Ｑで設けているフィルタでは防げず、また、TCP/IP設定で NetBIOS over TCP/IP を無効にしていても)、 接続先のIPアドレスが解かれば、その接続先でのアクセス権限に従った共有リソースを利用できます。
北Ｑで Windows 2000, XP を利用しいて、次の事項に当てはまる場合、注意が必要です。これらの事項に当てはまり、共有されているディレクトリへのアクセス制限が無かったり、(組み込み) アカウントへのパスワードが無い(或いは安易に予測されたり、特に Guest アカウントが有効などの)場合、 及び、以前(或いは今)ウィルスやワームに感染し、ディレクトリの不正な共有設定が行われてしまった場合、 外部からの共有ディレクトリへのアクセスを許し、ファイルの読み書きを許してしまう可能性が在ります。
- モデムと直接接続していて、その接続するネットワークカードでファイル、プリンタ共有を有効に(バインド)している場合。
- LAN内でファイル、プリンタ共有を利用していて、北Ｑとの接続で外部からのTCP Port445へのトラフィックが遮断されていない場合。(ハブに接続された複数台のマシンでTCP/IPによるWindowsのファイル共有を利用できるLANを構成していて、ケーブルモデムをハブに接続し、北Ｑとの一台、ないしは複数台の契約で北Ｑネットワークを利用している場合)
固定ローカルIPの様子は解りませんけど、なんか北Ｑのフィルタポリシーが変わったらしい。 今は、UDP 137 遮断、TCP 139 が通過の状態、単純に見ると「見えないけど繋がる」妙な状態に成っているかも、BBSでは、Macのディレクトリ共有が出来るとの書込みも有ります。 Macの場合は、一覧をldap、共有をTCP 548なのでしょうか？、まぁ、何れにしろ見えて繋がる状態では有るようです。
なので、ディレクトリ共有等は、北Ｑのフィルタに頼らず自分で閉めましょう。って事で、 ハブ経由でPC複数台をオプション契約で接続していたりする場合は、PFWで固めるか素直にルータ導入 する等して対策講じた方が良いかもです。(2003/01/21)
- ローカルIPはNATを通過する
以前は、ローカルIP接続で外部にアクセスする場合、ファイアウォールでグローバルアドレスが アロケーションされて接続する形態だったので、セッションが在れば殆どのサービスで制限を 受ける事無く利用可能(FTPなどもパッシブモード不要)だったのですが、現在はNATルーティング をしての接続に改まっている為、従来利用可能で在ったサービスにも幾つか制限が生じているよ うです。代わりに、利用者は強固なファイアウォール機能と匿名性(過信しないでネ)による保護 を受けられるように成りました。
- ローカルIPはHttpキャッシュを通過する
2000年12月からモデム帯域制限緩和に伴い、ローカルIP利用者にHttpキャッシュが導入されました。
導入の目的は無論、上位回線(2000年末の状況は、ODNへ22Mbps)のトラフィック緩和です。 この結果、一部のWebコンテンツ利用にProxy利用時に生じる事がある利用制限と供にキャッシュ特有の 障害が発生しているようです。北Ｑでは、Proxyやキャッシュにより生じる障害を回避する為の手段 として、DHCPによるグローバルIPの利用を推奨しています。
他にも障害回避の方法として幾らかの手段を試みる事が出来ますが、どれもDHCP利用による利便性と 完全性には及ばないでしょう。北ＱではローカルIP利用によるファイアウォールの加護を受ける為の トレードオフとしてHttpキャッシュが存在する構成と成っています。 ローカルIPを利用する事でNATを通過することにより得られる匿名性(幻想ですけど)を重視する 極一部の懲りない利用者(笑)にとっては暫くジレンマが続く事になりそうです。
- Per通信は可能
CATV局によっては、ユーザ間のPer通信を制限して禁止している所も在るようですが、北Ｑでは 利用可能です。ただし、固定ローカルIPとDHCPグローバルIP利用者間の完全なPer通信は利用する 事が出来ません。これは、固定ローカルIPではNATを通過する為の制限です。また、一時DHCP利用者 間でも新旧モデム間でのPer通信が困難となる障害が在りましたが、現在は回復しているようです。
- サーバを立てられるか？
事故防止(ですよね？)の為にモデムで遮断(NBTやDHCP)されているポートを除き、 DHCPによるグローバルIPを用いれば外へのサービスが可能です。 また、ローカル固定IPでも域内へのサービスは可能な筈です。
幸いな事に北Ｑでは第一種通信事業者として利用者に良質なIP通信を提供するを サービススタンスとしているようです。お陰でルータ利用などに制限も無く、ネットワークと 他の利用者への迷惑を掛けない限り自己責任の元、快適なネットワーク環境が提供されています。 無論、これは今後、利用者数の増加によるグローバルIPの不足やネットワーク周辺状況の変化により 制限が生じる事もあるでしょう。
「さば」とか「くし」などで激しく誤ヒットしているので書き換えたです(笑。
も少し素直に検索すれば幾らでも有用な情報に辿り着けるのに・・・、考える力が無いのですね。
- 北Ｑの利用者数は？
正確な利用者数は北Ｑからの公表が行われないと解りません。が、ある程度の目安として、稼動し ているケーブルモデムの総数を換算する事が出来ます。これにはセンター機器から常時行われる ケーブルモデムへのスキャン、正確には生存テストに利用されているらしいARP要求をトレースし、 モデムの宛先IPをユニークに集計する事で得る事が出来ます。この方法で得られるモデム総数は、 センター機器でモニタ対象(アドレス範囲としてプログラムされる)となっているモデム数に該当 する為、実際の利用者数(契約数)より多くなりますが、おおよその利用者数の目安となります。 ただし、ネットワークセグメントの構成や状態により、このモデムスキャンを捕らえられない事 も有るので信憑性の薄いかなりテキトウな数字です。
この方法で捕らえた2000年末の北Ｑのモデム総数は、5600台程です。
2001年5月のモデム総数は、6500程をカウントしました。
2001年7月のモデム総数は、7300程をカウントしました。
2001年10月のモデム総数は、7900程をカウントしました。
2001年末のモデム総数は、8800程をカウントしました。
- 北Ｑの品質
ネットワークの品質を問うのは難しい事です。私が試験接続から使い続けてきた経過から判断 すれば、品質は優良と評価できます。これは、ネットワークの混雑による通信速度の低下などは 「やむを得ない」と理解した上で、ネットワークへの接続が維持され利用が可能である延べ時間 とメンテナンスや突発的事故を含め接続利用が困難であった延べ時間を勘案した場合の評価です。 私は、概ね1000日に渡る利用期間の内、全く利用が困難であった通信途絶時間は24時間に満たな いと記憶しています。これは、様々な規模の企業内のネットワークと比べて、遜色ない、むしろ 優秀と評せる運用成績だと思います。無論これは流合雑音等のトラブルに見舞われ難いなどの幸 運も重なっての結果です。
- ケーブルは大変なんです・・・(2000/12/27)
2000年12月26日、北Ｑの障害・工事情報に、 通信不能障害(一部エリア)として障害報告が載りました。障害その物は良くある(?)流合雑音による 通信障害なのですけど、その原因として述べられている内容が、何だかスゴイのです。
「弊社幹線伝送路不法接続の為に発生した流合雑音による、回線断」
「不法接続」ですって(笑)、若しかしてコレって、誰かさんが電柱攀じ登ってCATV幹線ケーブルから 勝手にブランチして、お家に引き込んだって事なんでしょうか・・・。まぁ、話の上ではそんな事も 出来るかもー、と冗談話には上がりますけど、まさか本当に起きたって事なのでしょうか？、 すると、繋いだ先は[素句乱部留]解除機能を売りにしているアッチ系のチューナなのでしょうね、 否、若しかするとスゴイモデムで全ての変調と暗号を解除して通信傍受してたのかも(笑)、 とか、ネタとして楽しめる物だったのです。
しかし、通信インフラって脆弱ですよね、以前にも何処かのCATVでケーブルをチョッキンしちゃう事件 が在ったし、そういや昔お勤めしていた会社でも悪戯に電話線チョッキンされて難儀した事在ったっけ、 高度な情報通信の世界も、その足元は紐(笑)ですからチョキン・テロには敵わないようです。 パケットの投げ合いするサイバーテロ対策より、丈夫な切れないゴム紐に張り替える方が急務かも。
- 良い物見つけたーSNMPモニタクライアントを探した(2001/02/12)
北Ｑ関連じゃないのだけどね、先程からSNMPのモニタクライアントを探していたのです(笑)。
実は、我が家のUP/DOWNリンク速度をチト見てみようと思ったのだけど、家のルータ代わりのマシンは、 NICにPCI製のアブナイ(と言うか、使ってるチップセット-MX713-がどうも？)奴で、 通常の通信には支障無いのだけどネットワークのパフォーマンスカウンタ(イーサのカウンタね) が動いてくれないのです(泣)。 なので、Win2Kのパフォーマンスカウンタで通信速度のモニタが出来ないの(困)。 で、仕方ないから代わりに、SNMPサービス入れて適当なモニタで色々見れるようにと思い モニタクライアントを探してました。
で、見つけたのが、GETIF とい言うやつ。SNMPモニタとして一通り見れてグラフも書いてくれるし、 ネットワーク系のツール機能も内蔵しているし、で便利みたい。
SNMP関連の情報が纏められている所 の Implementation(SNMP4W2K) で紹介され、配布されています。(2002/04/03)
- いゃーん、覗かないでー(2001/02/15)
北Ｑのサポートに問い合わせていたのですが、或るローカルIPアドレスが 「北Ｑの管理端末ではなく、北Ｑユーザの所有する端末である」 との回答を得たので書いちゃいます(笑。
この或るローカル固定アドレスを利用している人が、どうも私のケーブルモデムからSNMP で何か聞いていたようなのです。 以前から北Ｑの管理端末からはモデムへのSNMPアクセスが在る事をIDSのログから 知っていたのですが、先頃、モデムから見慣れないアドレスへのSNMP応答を記録したので 気になっていたのでした。 北Ｑのケーブルモデムで確認しいてないのですが、若しかするとコミュニティー public への接続IPの 制限が無いのかも知れません。出来れば、モデムの所有者と北Ｑの管理端末以外からのアクセスを拒否 するような設定が欲しいです。
で、10.X.XXX.XXX(自粛、笑) 利用の御方。私のモデム覗かないでー、お・ね・が・い・(ハート)
ローカルIP、逃げ場なし
- 今、そこに在るゴミ(2001/03/01)
最近、H.U.Cとかの中国方面からのクラック騒ぎが起きたのと、友人からの北Ｑでの接続トラブルの 相談を受けた事からネットワークのモニタを強化した(笑)事で偶然見つけたトラブルなのです。 書くべきか迷ったのだけど、CATV形式のLAN接続特有の問題として記録しておく方がいいかと思い・・・、 まぁ、極めて抽象的に書くけどね、
端的に書けば、「或る所からゴミパケットが流れ出ている」ってだけの事なのだけど、 この流れてくる物ってのがARPのアドレス要求パケットなのです。
北ＱのCATV接続って普通にイーサネットを使ってるけど、イーサネットの通信って 同じネットワークに居るホスト、「DNS」とか「ゲートウェイ」とか、 時に「お隣さん」とかへパケット打つ為に、ARPを使ってMACアドレスを解決して目的ホストへ向けて パケットを送出するんだよね、繰り返すけど同じネットワークに居るホストへの場合ね、 もし、別のネットワーク(北Ｑの外)のホストの場合は、MACアドレスでパケットを届ける事が 出来ないから、ゲートウェイ(ルーター)へ配達を委託するんですよね、で、「同じネットワーク」か 「別(外)のネットワーク」を識別する為に利用するのがNICのネットワーク設定でIPアドレスと供に 指定されるアドレスマスクであり、宛先IPアドレスを元に、何処にパケットを送り出せば良いのか 決めるのがIPルーティングな訳だけど、このアドレスマスクやルーティングの設定が不適切だと どんな事が起きるのだろう・・・。
例えば、或る会社さんが、北Ｑのサーバー接続コースを使ってWebサーバを動かしている。 処がネットワーク設定やルーター設定にチト不備があるようで自分のネットワークと外のネットワーク を上手に識別できていない。
そんな、或る会社さんのWebサーバーをお客さんが見に行く、 すると、お客さんの使うIEとかのHttpクライアントからの接続要求は、 チャント或る会社さんのサーバーに届く。
なので、或る会社さんのWebサーバーは、見に来てくれたお客さんへ返事しようとする。
この時、宛先(お客さん)は多くの場合、Webサーバーの置かれた自分のネットワークの外 に居る筈なのに、何故か北ＱのネットワークにクライアントのIPアドレスを解決してくれーと ARPが流れてくる・・・。なんて事が起きちゃう事が在ったりするかも知れなかったりする(笑)。
まぁ、普段、誰も(？)ARPなんて見ないしー、 ただ、或る会社さんのWebを見に来た人のIPアドレスが解るだけの ゴミパケットなんだけど、或る会社さんのWebを訪ねる「お客さん」は、まさか自分のIPアドレスが 北Ｑネット内に垂れ流されているとは思いも因らない・・・よね、たぶん。
タイポ直しのついでに加筆(2001/03/28)
これ書いてから暫くして回復していたみたいなのだけど、昨日 WinPcap のバージョンアップの際に 見てみたら、また変に成っているの、 これを最初に書いたときは調べなかったのだけど、試しに外のISPからWebを見に行ったら繋がらない。
どうやら以前のルーティングが変な状態の時も北Ｑ以外からは、この会社のWebを見る事が出来 ない状態だったらしい・・・。
まぁ、地域超密着型、北Ｑユーザー御用達の、こんなメーカーも在ると言う事で・・・(汗。
- 2001/04/01 増速されました(2001/04/02)
ADSL様様ですぅ(笑)。速度競争の煽りを受け北Ｑも遂にMbit通信時代に突入です。
パーソナル(端末接続)コースの下り速度が512Kbpsから2Mbpsへ、ファミリー(ルータ接続)コースは 768Kbpsから3Mbpsへ！。上り速度は512Kbpsと成りしまた。
ケーブル接続ではADSLのような局間距離による減衰やらISDNとの干渉やら無しに、 センターモデムとの速度が、ほぼ保証されているのでケーブル網と、同時に増強された上位回線 (ODNへ28Mbps)が空いてさえいれば、 今暫くは、かなり快適なネットワークを利用できそうです。
で、今回の増速工事で心配していた、
1. DHCPにもキャッシュサーバーが適用されるとか
2. この為、内向きのhttpポートが遮断されるとか
3. 他のポートもフィルタポリシーが変更されて住み難くなるとか
等のポリシー関連については、変更されなかったようです。
まぁ、めでたしめでたし。一安心・・・です。
# さて、次は光と競争ですね
- 2001/07/02 増速されました(2001/07/02)
大体三ヶ月毎に行われて来ているバックボーン増速工事です。普段と違うのはODNへの接続方式 が変更になるらしい事。
ODNのサービスメニューから眺めてみると、今までの接続はデジタル専用線(ATM)ファストを使って いたのだけど、今回どうやらスーパーのEther(100Base-TX)での接続に切り替るようです。
この結果、帯域はODNから北Ｑへの下りトラフィックのみ35Mbpsの制限、上り方向は無制限の100Mbps と言う事になるようです。北Ｑから外へのコンテンツ配信能力は一気に４倍近く増強される事に なります。このページにも巨大な背景ビットマップ置こうかしらん(笑。
で、下々のユーザーには・・・、
使い勝手や環境に変化は無いから、まぁ、普通のバックボーン増強ですな、
で、増速工事(07/02)後・・・、
良く解らん(笑)。たぶん混雑渋滞が少し解消されているのでしょうネ。
- 2001/07/24 ルータ交換だって(2001/07/24)
7月20日の夕方、23日夜中に起きたトラブル対策として北Ｑのルータが交換されました。
実は、20日のトラブルが発生する数日前から我が家の IDS(笑) は、幾つかの不信なパケットを記録し続けています。
記録されるログのパターンとしてはICMPの不到達通知とTCPパケットの残骸なのですが、その発信元 と成っているホストへの通信は記録(記憶)のない物なのです。 つまり、通信した覚えの無い経路上のルータやホストから不到達通知やTCPの ACK付き パケットが 飛んで来る(笑。単純に考えれば私のIPアドレスを詐称して悪さしている奴が居るような記録が ポツリポツリと続いていたのです。
さーて、これは北Ｑのルータの不具合により引き起こされていた物なのでしょうか？、 だとするとネットワークダウンを事前にキャッチした？(汗)、と言う事で片付けられるのですけど、 ルータへのクラックも心配ですし、全然関係無い遠くのネットワークトラブルが原因かも知れないし、 他にも原因は色々考えられますから何とも・・・、まぁ、暫く様子を見ればハッキリするでしょう。
続くようだと、気持ち悪いです(笑)。
2001/08/01 やっぱりルータの不調[とは限らない？(笑]が原因だったらしいです。 spoofingを示唆するログは、交換後ピタリ治まりました。
- CodeRed が凄いのー(2001/08/09)
2001/08/01 それは始まったのです(笑。
いんやー、凄いです。CodeRed に感染したホストからの 執拗なお誘い。
アタイの知らない奇抜な方法で誘われたら、転んじゃうかもー(家のIIS談)
中には、北Ｑユーザーからの誘いも在ったりして・・・(ゴメンね付き合い悪くて)。
・・・とかの冗談は置いといて・・・
・
・
でもさあ、IIS使ってWebサーバ立てるのは構わないけど、日頃のメンテナンス。 特にセキュリティー関連の情報には目を通して、チャント面倒ぐらい見ようよー。
んで、詳細は後で纏める事として、今は 緊急特別企画 開催中なのです。
チョット経過を時系列で纏めて置こうかな、
どうやら、この .ida exploit は、今後、末永くインターネット上を駆け巡る事に成りそうです。
- 8月1日
予想されていたとおり CodeRed(まだ、この時は初代V1と感染力がアップしたV2) からのお誘いを受け始める。
- 8月1日〜4日
お誘いが少しづつ増加傾向。
- 8月4日夜
CodeRedのリクエストに初めて "/default.ida XXXXXXXXXXXXX...." を見つけ、あれっ？となる。
IPアドレスを見て北ＱのDHCPユーザーの物からである事を知り驚愕する(笑。
- 8月4日深夜
幾つかのML上で新しいリクエスト "/default.ida XXXXXXXXXXXXX...." が話題に上る。
捕獲したコードのダンプを眺めて恐ろしげな呪文を見つけ、ビビる。
- 8月5日
CodeRed II と全世界的に認知される。
そのカラクリが明かされると共に被害規模が拡大。
- 8月6日〜
一向に沈静化するする様子無し。個人的には「おら知らん」と諦める。
- この先、心配な事
北Ｑの場合、ローカルIPでの発症が心配です。
CodeRed II は、感染すると自分の近くのIPアドレスに多くの攻撃を仕掛けます。 ネットワークのセグメントが大きいと(ローカルIP 10.x.x.x とかね)普段、トラフィックとして意識 する必要の無いようなARPのアドレス要求パケットでも、多量に発生すれば問題を起すかもしれません。
また、モデムへ影響しないかの不安もあります。北Ｑのモデムは全てローカルIPに置かれています。 LANCityのモデムはhttpによるGUI設定機能を持っていないと思うけど、他メーカの物は解りません。 これがCodeRedの異常なリクエストで誤動作する恐れもあります。 「東京めたりっく」や「インターリンク」の二の舞はご免です。
- 対策
一番期待できない最も理想的な対策は全てのIISに修正バッチが適用される事(笑。
一時凌ぎは、大きなトラフィックが過ぎ去るまで外からのhttp遮断でしょうね、でも、直ぐに次の 新しい、ワームが放たれるだろうけど、
個人的には、IISの修正プログラムを伝播するワームを解き放つのも現実的な手段だと思う。 できれば、ネットワーク負荷へ十分配慮して制御されたトラフィックを生成するように工夫された物ね、 現状を理解しているネットワーク管理者なら、この程度のトラフィックを許容し甘受できるでしょ？。
- ルーティング異常 (攻撃なのかな・・・、違うような気もする)(2001/09/02)
2001/09/02 それは北ＱBBS の書込みで発覚したのです。
掲載されたログを参考にチョット某ホスト(アドレスは北Ｑ所有)をつついて見ました。
Pingを打ってみたのだけど、北ＱのローカルIPの出入り口となる幾つものホスト(プロキシやルータ)から 猛烈なエコー応答を頂く事ができました(汗)。
どうやらルーティングに異常が有るみたいです。或は、問題のホストに特殊な仕様の増幅器(大汗) が仕掛けられているのかな・・・・？、増幅器のゲインは50db位あります(爆笑。
さって、事の真相は・・・、9月3日の障害報告によると「ルータの不具合」との事。
- はぁ〜、今度は Nimda だって・・・(2001/09/20)
2001/09/18 それは、またまた、行き成り、突然始まったのです(笑。
・・・(つまり、何時も通りと言う事ですね)
で、北Ｑ内からも、やはり猛烈なお誘いをお受けいたしました。 以前に CodeRed II への感染が記録されているIPアドレスが含まれていたりするので 適切な対処無しに放置されていたのでしょうか？、 まぁ、人のだからどうでも良いか・・・、すでに諦め(呆れ)モードに移行済みだし、
んでもって、お決まりの お誘いカウンタ を設置しました。
一日にして、既に我が家のIISへのリクエストは去年一年間の総リクエスト数に匹敵しているような、 そろそろIISのパフォーマンスを一日1万ヒット以上の設定に変更しないと不味いでしょうか？(笑、
- 増速準備中・・・(2001/10/12)
ADSL陣営の速度、価格攻撃に対抗すべく、北Ｑもサービス改定戦略の 第２シナリオが発動されました(笑。
いゃーホントに『ADSL』さまさまですぅー。でも個人的には、上り下り512Kbpsで2000円ポッキリ。 +800円で固定IP 1ケ なんてサービスが在ると嬉しいなー・・・。んでもって、北Ｑ内のネットワーク構成を増速に備えて再編成する作業が行われました。 httpキャッシュサーバやFW、センタモデムの増設と負荷バランスの調整などが行われたようです。
規模の大きい改修工事が行われると、暫く彼方此方でネットワーク障害が発生するのも、 毎度の事なのですが、どうやら一段落着いて落ち着きつつあるようです。
トラブルは固定IPやフジクラモデムの利用者に集中していたようですけど、家は全然、全く影響受ける 事無く安定した接続が提供されていました。延べ２日に渡る工事でも停止時間は20分にも満たなかった ような、わたし的には『たいへんよくできました』と花丸なんですけど、この調子で実際の増速工事も スンナリ行く事を願います。
それと、工事前後のARPモニタによるモデム数のカウントは、大凡 7900 と成っています。 このカウント数には足抜けして未使用と成っているIPアドレスも含まれているから、 北Ｑ全体では、7500ユーザ位？と言うところでしょうか・・・、 ここらで一度、北Ｑからの正式発表があればキャリブレートできるのですけど(笑、
- コンテンツフィルターが掛かってる？(2001/10/14)
アハハハ、何だか 面白い事 が起きているらしい。
先日、不具合が起きてローカルIPアドレス用のFWが交換されたのだけど、この交換後から 機器の不具合、或いは、設定不良なのか、JavaアプレットやActive X、Win実行形式(*.exe) 等のファイルダウンロードが不可能な状態に成っているらしい(笑。
生憎、北Ｑへの通報(?)が遅れていたのか、週末で技術者不在の為、調査にも掛かれないそうな、 週明けには迅速に回復することでしょう。
- もう直ぐ増速・・・(2001/10/28)
北Ｑの設定したXデーは、2001年11月1日。この為に9月25日から数度に渡り行われたいた 改修工事も、最後に予定されたいた10月26日のセンターモデムの増設で無事(?)完了したようです。
ODNとのバックボーンは、35Mbps から 40Mbps へ増速。その他の改修の様子は、サッパリ解りませんけど、 北Ｑの言う所の 「皆様に十分最大速度の上昇を体感していただけるよう・・・」への手筈は整ったのかな？、 既に、料金の方は10月から改定され、私の利用するパーソナルコース (家はCATVサービスはエコノミーとのセット)で 700円 の値下げが行われています。 後は、センターモデムの帯域制限を「ポチ」っとやれば、めでたくパーソナルで3Mbps(旧2Mbps)、 ファミリーで5Mbps(旧3Mbps)のサービスが開始されると言う事で・・・、
*共に下り速度、上りは512Kbpsへ据え置きです。 それにしてもサーバコースは、なんか可哀相。
まぁ、混雑時は無理としても通信速度が上がるのは良い事です。でも、何に使いましょうネ？、 今、Mbpsを必要とするコンテンツと言っても？？？、 暫くは速度測定のベンチマークが最も利用価値の高いサービスなのかな(笑。
- 増速したけど(X+6day)(2001/11/06)
やっぱり体感は無理みたい(笑。今思うに、256K->512Kへの増速が一番劇的だったかな〜、
計りゃ数字でキッチシ出るから解かるんだろうけど、 試しに北Ｑ専用(笑)の速度測定プログラムなど作ってみようかと・・・、
- Windows XP(2001/11/18)
試しにインストールしてみました。家の環境では一部のデバイスドライバが無い様で、 移行は暫くお預けです(笑。他に入れ替えるメリットも今は見つからないし・・・、
で、北Ｑに関わる事として、
正式販売以前から解かっていたことだけど、Windowsのネットワークの「お手軽ネットワーク」 だった NetBEUIプロトコルが無くなっているんですよね、 北ＱのローカルIPアドレスでの接続を利用している場合、自前のネットワークで 北Ｑに接続していない他のクライアントのIPアドレスは、どうするんでしょうね？、
勝手に北Ｑ固定のローカルアドレスクラスと同じセグメントでIP振っちゃうと不味いだろうし、 かと言ってクラスの異なるローカルアドレス振っても、手動でルーティングテーブル指定 しないと見えないと思うし、面倒だよね・・・、北Ｑでユーザが勝手に利用しても良い アドレス空間を割り当ててくれているのかな？、
まぁ、ルータ噛ませば問題ないのだけど、少し気になる。
書き上げてから調べてみたら、インストールCD-ROMには、NetBEUIプロトコルが入っているのネ、 インストールすれば使えるらしい、なので問題ないのかな・・・、
ここで、XPのドライバが無いって言っているの実は、SCSIドライバなんです(笑。そう、FlashPoint。思うにコレ幾ら待ってもサポートされる予定なんて無さそうだよね、そりゃー親方IBMに取っちゃ、BusLogic->Mylex->IBMと引き継いだ不良債権かも知れないけど・・・、こんな時代遅れのカード捨てちゃえば良いのですけどね、実際、無くても、一緒に動いている2940に有るSEの口に繋ぎなおせば良いだけなのに、低速デバイスと高速デバイスは完全分離主義(笑)が働いていて、踏ん切りが付かないのです。適当なカード買ってこなくちゃ、(2002/01/21)
- MXショック(笑(2001/11/29)
昨日、つまり 2001年11月28日、ファイル共有サービスの利用者(WinMXのユーザ)がお二人、 著作権法違反で逮捕されたそうな、ファイル共有では世界で初めての快挙(?)だと、 まぁ、やっちゃいかん事やって責任を追及されているだけの事だけど、 これが北Ｑにも大きな影響を与えたようなので記録しておかねば、
北Ｑでは、トップページのリンクからも解る通り、北Ｑ利用者に限定して 上位(ODN)バックボーンへのトラフィックを公開しています。で、これはMRTGの週単位グラフのような 物なのだけど、このグラフに異変が・・・、実使用でもハッキリ体感できるほど、
空いてます(喜
さって、何時まで続くかな？、若しかすると北Ｑの増速スケジュールを調整するほどの 威力が有ったりするかも(笑。
追記(12/1)
今回の逮捕劇の衝撃は思いのほか威力が大きいようだ(驚)。
事件の報道が28日午後、で、当日深夜の混雑タイム(北Ｑの場合、22時〜2時位、ピークは午前零時位にある) のトラフィック減少を確認できたのでトピックを書いたのだが、昨日に続き今日のトラフィックも減少傾向 を示している。最早、北Ｑ-ODNの下り帯域が飽和する状態は記録されないし、 相当(早計だが減速を検討できるほど)の余裕すらある。
普段、混雑で諦めていた時間帯でさえ、これほど快適な利用を続けられるなら、 関係機関には月に一度で良い今後も網を打って漁を続けてもらいたい(笑。
- 2001年の〆(2001/12/31)
本年のお家サーバの状況
・延べ停止時間、8時間位かなWebアクセス統計
・最大連続運転日数94日
・予定外のリブート一回(CPUファンの停止、もうリペアパーツが無いかも)
・予定外の停電3回位(雷被害なし、漏電一回、後は容量超過)
総ヒット数 10万位。内、7万位はIISへのExploit(笑他に、
内訳 CodeRed: 6500、Nimda: 63000まともなお客さんからのヒットは、1.8万位、ユニークホストは600程でした。
今年は作業マシンのディスクが相次いで2発逝きました。
SETI@homeの総出来高は6000に到達。今年も沢山の電気を使いました・・・。
北Ｑのモデムカウントは8800程(伸びは順調？)。
- モデムが壊れたかも〜(2002/01/05 02:00-)
年が明けて早々、今まで経験した事の無い長時間の通信途絶に見舞われています。
今これを書いている時点で既に10時間。
既にユーザサポートではモデム故障を疑って交換手配も済んでおり、数時間後には回復見込、 これで我が家のモデムも晴れて「黒くてゴツくて大きな」奴から「白くて小さな」奴に交換となります。
引退する黒いモデムの延べ稼働時間は、1344日と10時間、周辺で次々と故障して数を減らしていく中、 結構ガンバリました(笑。
14時頃モデム交換
接続障害は、やはりモデムの故障でした。あの「黒くて大きくてゴツくて重い」LANcity LCP がフジクラ FCM-120U に替わりました。色は白と青い半透明のプラケースによるツートン、 小さなケースで、家のTAや56Kモデムより小さくて軽いです。
半透明な青いカバーから内部基板がぼんやり見える処をみると、無性に分解したく成るのを堪えています(笑。
回復までは障害発生から12時間、サポートの始業時間を考慮すれば4時間程で交換修理の対応を行って頂けました。今回の対応状況を見る限りでは、正月明けの人員の手薄な中で北Ｑサポート、なかなか優秀！。
今回のモデム交換に伴い北Ｑ内でのネットワークセグメントも変わりました。前に居た所よりも遥かに多量のブロードキャストやマルチキャストによるゴミパケット(ローカルIP、しかもユーザのLAN内から漏れ出ていたり、笑)、UPnPやら経路情報寄こせだの・・・、もう多量に流れ着いています。チャンとSyslogを垂れ流してくれるホストも居るし、Nimda感染者も居るし・・・、酷く騒がしい所に来てしまったものです(笑。皆さん、自前のネットワークへの流れ込みを抑えるためのフィルタは、しっかり掛けてるのでしょうか？、
- またまた、モデムが壊れたかも〜(2002/01/07 08:10-)
一昨日、ケーブルモデムを交換して順調に動き始めた途端、またも接続が困難な状況と成っています(笑。
今回は、若しかすると伝送路上に問題が有るのかも知れませんので、本日午後、一応(笑)モデムの交換と信号状態の確認の為、サービスの方にご足労頂く事に成りました。なので、あと２時間ほどで回復することでしょう。(01/07 12:00)
今年は、年明けからINSが大活躍ですぅ(笑。
予定時刻にサービスの方に見て頂き、モデムが、またも交換されました。2台目のモデムは稼働時間42時間余りと、極めて短命でした(笑。初期不良なのでしょうか？、 良く在るようなら北Ｑでエージングして貸し出すようにしないとメンテナンスの手間ばかり掛かってしまいますよね、そんな製品使っちゃダメですぅ。 まぁ、何はともあれ正常復帰と言う事で、今度の3台目には是非ガンバッテ頂かないと・・・、
尚、通信速度ですが、下り5Mbps/上り512Kbps で動いているようです。パーソナルコースは下り3Mbpsの筈なのですが、若しかして新型モデムでは制限が緩和されているのでしょうか？、或いはセンター側での設定が間に合っていないか・・・、これも暫く様子を見る事とします。(01/07 15:25)
通信速度が下り3Mbps(正しいパーソナルコースの帯域制限)に設定されました。センター側の設定が遅れていたのか、或いはモデムに帯域制限が設定されるまでにタイムラグが在るようです。この設定の際、リモートでモデムのリブート操作等が行われたかは不明です。増速の際などには改定時刻以降にモデムをリブートするようアナウンスされますけど、モデムへの影響無しに操作が出来るように成っているのでしょうか？、それらしい時間帯にIRCサーバへのセッションが切れた記録は在りますが、これは通常でもIRCサーバとの間では度々ある事なのでモデム操作との関連は掴めません。(01/09 21:00)
それと、たぶん今回のトラブルで新型のモデムに成った事により解かったことが幾つかあります。
まだ十分確認した訳では無いですし、一寸見の状態なのですが、
マルチキャストについては勉強不足なので少し勉強してから北Ｑへの問い合わせ等も含めて調べてみたいと思うですぅ。
- 古いモデムはIPのICMP/TCP/UDP以外のプロトコルタイプを持ったパケットを通さないかも知れない。なので、特殊なプロトコルタイプを持ったパケットが必要だと同一セグメント内でも通らないかも、そう言えば、古いモデムの時は、特別なプロトコルタイプのIPパケットを見た事が無かった気がする。
- 古いモデムはMulticastが使えないかも、これは、先のプロトコルタイプの制限でIGMPが通らないらしいから、でも、マルチキャストされたパケットは届いていた気がする。
- 固定IPアドレスブロックにマルチキャストルータが在る？。
今回見えるように成った訳なのだけどIGMPのQueryが流れてくる。ユーザ設定のゴミかも知れないけど、それにしてはアドレスが「らしい」し、でもスゴク変、だって、ローカル固定IP、DHCPグローバルIPの両方、要はIGMPを通すモデム利用のホスト全部から見えているようなの、なので、かなり広いアドレス範囲からマルチキャストされたIGMP Responsが流れ着きます。単純に考えるとローカルIPもグローバルIPもぜーんぶ一つのマルチキャストグループに居るような感じ・・・、マルチキャストは全部がコリジョンドメイン？、これじゃ何のためのマルチキャストか解からなくなるような、
(此処での古いモデムとは LANcity LCP の事、新しいのはフジクラ FCM-120U の事です)
- またまたまた(笑、モデムが壊れたかも〜(2002/01/12 13:30-)
またも通信途絶です。ケーブルモデムを7日に起きた時と同じような症状が襲っています。今回は時折センターへの接続に成功し、数秒間の通信が可能な状態になる時も在るようで、モデムの故障とは断定できない症状に見えます。伝送路上の問題、例の流合雑音絡みかも知れません。他の近隣ユーザの状況などが解かると、もう少し、状況が掴めそうです。
接続がそんな状態なので、我が家は現在一時間当たり５秒位オンライン！(笑。御用の向きはタイミングを計って超高密度伝送を御利用ください。(1/12 15:25)
北Ｑのサポートさん達の努力のお陰で、一応、18:00には完全復旧しました。モデムは故障状態と断定できる状態では無かったのですが、信号レベルが少し落ちている(送信出力かな？、交換すると繋がるし)。との事で、またも、交換されました。モデムはこれで４台目！。同時にモデムへのケーブル接続点であるF栓の交換、それと我が家への引き込み部分の保安器、分配器(HPフィルタ付き)を交換しました。さらに明日、北Ｑ基幹へのタップボックス内の点検とコネクタ交換を予定されているとの事。立て続けに３台のモデムを葬り去った(笑)原因の特定が困難な状況の中、総当りでの試行を余儀なくされているようです。これだけメンテナンスのコストが掛かるようだと料金の劇的な値下げは、将来も難しいかな？、もっと明確な故障や不具合判定システムの整備が必要なのではないかと・・・、尚、今後、再発するような場合はケーブルをタップから全部引き直すとの事。障害回復への意気込みは頼もしい限りですぅ。でも、まだ再発するようなら旧型のLANcityモデムの設置を要望したりして(笑、(1/12 20:30)
- 探し物はみつかりましたか？(2002/01/21)
厳戒態勢(笑)の続いているモデムを含む通信障害については、今の処、快調。特に何の問題も起きていないようです。まぁ、まだ一週間の経過って言う事で、来週位までは気が抜けないかもしれませんね・・・、
で、今日は、BBSへの書き込みが在った「北Ｑユーザからウィルスメールが届く・・・」にでも触発されてのトロイ探しか、或いは悪戯目的に手近なプロキシ探しなのか、随分と中途半端(笑)なサービスを探されているポートスキャンを北Ｑユーザ(即、こんな風にネタに利用されます)から受けてしまいました(笑。
しかし、宛先ポート番号が何とも中途半端で・・・、幾つかの著名なトロイを探しているかのように見えて、プロキシ探しとも符合する物があるし、かと言って、今、まだまだ旬(笑)なNimda探しのhttpや、8080とかのプロキシスタンダードなポートへのスキャンが無いし、でもSOCKSは押さえているし、と、恐らく私などに理解できない崇高な知識、成果への深慮から余程慎重に爆撃目標を選定されているのでしょう。でも、nmap使った方が簡単で速いですぅ。で、MAC:00909932AB58 の方、探し物は見つけたのでしょうか？、それとも踏み台に使われましたか？、
それと、北Ｑの速度測定やODNへのトラフィック公開などに使われているサーバ(北Ｑ内ユーザにのみサービス)が20日の昼過ぎ辺りから止まっています。停止直前のトラフィックグラフは酷く乱れていたけど若しかして持ってかれたのでしょうか？、単純にディスククラッシュ等のハードトラブルなら心配ないのだけど・・・、
- すばらしい(或いは腐った)ルータ達(2002/02/03)(加筆 2002/02/18)
トラブルによるモデム交換で触れた事柄について少し観測してみたので纏めてみます。それに伴い、何とも妙なパケットの残骸をIDSが沢山沢山拾ったので、トピックタイトルの乗りで、その事について、
- 通過するプロトコルタイプについて
この点については、旧式モデム(私の場合の旧式とは、LANcity LCP を指します)との比較検証が最早出来ない状態(チョット協力者を募れば簡単だけど・・・サボリます)なので、脆弱な私の記憶と手元の新しいモデム(フジクラ FCM-120U)での経過観察からの情報。
新しいモデムではIPレベルのパケットは何でも通るみたいです。まぁ、全て無条件ではないでしょうけど、保安、管理上の制限に掛からなければ大丈夫なのではないかと・・・、試しにIPSecを使った北Ｑ外からの接続には成功しました。で、これはチト厄介な問題を提起することに成るのかも知れません。つまり、旧式モデムを使っている人も、IPSecや他のVPN接続を支障なく使えるのだろうか？、と言う疑問。旧モデム利用時の記憶は・・・消失(笑)。
- マルチキャストルータについて
これについては北Ｑに問い合わせて見たのだけど、回答は得られないようです。まさか、存在にも気付いていないのかな？、今度はログ付きで尋ねてみましょう。で、今もしっかり稼動(笑)しているので、一時の気の迷いではないようです。実際にIGMP動かして試してみるのも良いかも知れないですね、でも、若し動いていて、さらに送出も可能だったりすると、悪用すれば北Ｑ内へ簡単に強烈なDoSを仕掛けられるかも・・・とか、チト心配している素振りを見せたりして。
疑問なのは、ローカル固定IPの(たぶん全)アドレスとDHCPグローバルアドレスのホストから IGMP Respons が流れて来ている事。特にローカル固定アドレスは、全ユーザが単一のセグメントとして構成されている筈(アドレスマスクを見ると)なので、この状態でマルチキャストされたら全ユーザ宛てにパケットが送り届けられてしまいマルチキャストの意味が全然無いの、若しかするとイーサレベル(センタモデムからならユーザ単位かな)の見えないスイッチが隠されていて旨く必要としている宛先だけに届くように成っているのかな？、でも、それだと近隣(同一セグメント/スイッチ下)の IGMP Respons をモニタして応答を控えているホストはマルチキャストの受信先として登録されないから届けて貰えない筈だし・・・、そっか、IGMPが煩く垂れ流されるのを抑えるための囮なのかも、でも、Query貰わなければ黙っている筈だよね・・・、てな具合で、北Ｑネットワークの極一部を垣間見ての推測なんで、謎は深まるばかりなり(笑。
家のIDSが幾つかのマルチキャストアドレスへ向けられたTCP(汗)によるhttpへ向けた接続要求の存在を捉えています。ただー、若しー、テスト目的でー、送出されるのでしたらー、自分のルーティングテーブルにー、件のマルチキャストルータらしき奴へのルートを追加するかー、イーサパケットを直接打ち出せる砲台を用意してー、件のルータらしき奴へ向けてー、適当なマルチキャストアドレス宛のーUDPパケットをー、打ち込んでみないとー、テストは出来ないかなー、とか思います。(2002/02/10)
- すばらしい(或いは腐った)ルータ達
モデムが新しくなって、イーサブリッジとしての透過性(?)が高まった為か、妙なパケットも沢山沢山通過して来るように成りました。中でもぶっ壊れたパケットを良く見かけるように成っています。どんな物かと言うと、イーサヘッダの後ろに何故か2オクテッドのゴミ(00)が入っていてIPヘッダが正常に認識できない奴とか、IPヘッダは正常に見えるけどIPプロトコルタイプが不定でIPアドレスのインディアンがひっくり返っていたり16bit境界で入れ替わっていたりしている奴とか、これらは全部MACブロードキャストされているので流れ着いています。
発信元は大体決まっていて十数箇所、どれもWindowsのSMBパケットの片割れ(尻切れサイズなので深刻な情報漏洩には成っていない)みたいで、たぶん発信源はBRからなのでしょう。MACベンダを比較すると4社程に分類されるようで、中でも0090CCなるベンダIDを持つ某社さんが幅を利かせています。本来はフィルタ処理されて外には流れ出さない筈の物が何かの拍子かファームの不具合か、IPパケットの体裁としては不完全な状態でWAN側に漏れ出ているようです(笑。
まぁ、取り立てて害が在る訳では無いですけど、何が漏れ出るか解からん様なアホな機械は、個人的には絶〜対使いたくないと思うです。それに、チト厳しい監視装置なんかが動いているとビシバシ引っ掛かって在らぬ疑いを掛けられないかと人事ながら心配してます(笑。その点、家のIDSは作りが超手抜き仕様なので、時折、狂ったようにDNSの逆引きオペレーションを引き起こす(汗、無視させたいけど手抜きなもんで・・・)程度で静かに見守って居るようです。
- すばらしい(或いは腐った)ルータ達--その２
これは、家では普段フィルタしていて無視していたので気にも留めていなかった事なのですが、ルータ間で交換されるメッセージってのが有りますよね？、最近 BR の利用(或いは最近リリースされたOSのネットワーク機能に加えられたかな)が増えたので目立ってきているのだと思いますけど、RIPやICMPのルータ関連のメッセージ。
眺めていて少し心配に成ったのだけど、これって、信頼されているネットワーク内では良くても北Ｑ内ではマズイですよね、これらのメッセージで妙なルータ情報を取り込んでしまう事は無いのでしょうか？、例えば、お手軽(笑)なICMPルータ要請のメッセージに答えて、自分をルータと偽ってICMPルータ通知メッセージを送り返してやる(もちろん、チャントそれらしくルーティングしてやる手筈を整えてネ)。 これをルータ要請をしたホストが疑う事無く取り込んだら、そのホストのトラフィックを取得できることに成ると思うのですよね、ICMPでのルータメッセージは特に認証の機構も無いし、経路上到達できないルータを選択しても、不到達のトラフィックが発生した時点でルータリダイレクトのメッセージで経路を変更するカラクリなので通知メッセージを投げ込めなくでも詐称したリダイレクトをガンガン送れば、やっぱりトラフィックを横取りできてしまうかなと思うのです。
はて？、実際の処どうなんでしょう。こんな事が簡単に実現できるのでしょうか？、出来ちゃったら・・・怖いですよね(笑、また、この場合、そんなメッセージをリスンしていて騙されるホストやBRが悪いのか、その危険を知りながらトラフィックを制限しないネットワークが悪いのか、あっ、こんな事心配する奴が一番悪いのかな？(汗。思い違いならいいのですけど、(2002/02/18)
- バックボーン増速(2002/02/20 書いたのは22日だけど)
ODNへの速度が 40Mbps から 45Mbps へ増速されました〜(祝。
で、まぁ、やっぱり、あまり体感できないかな・・・、混雑時間帯が少し軽いような気がしない事も無いような、大体 512K超えたら1Mも3Mも解からんって(笑、接続は最後のトラブルでのモデム交換と一部機材交換後は至って快調、安定性(実効速度も誇れると思う)が売りの北Ｑらしさを取り戻した感が、
それと、センターからのARPスキャンを追いかけるモデムカウントは、大体 8900 位。
でも、数日前から(たぶん)旧モデム(LANcityシステム)のスキャンが拾えていないので、その分を適当に足し込んでの数字です(もともと当てにならんのだけど)。実際は 8500 ユーザ位かな〜と大胆予測しておこう。スキャンアドレス範囲の拡張ペースが以前は、月300増程度で推移していたと思うのだけど、最近は落ちているような気がしています。
やっぱり、ここらで、サービスもクラス分けして「スピード命」のユーザと「コスト優先」のユーザをも引き付けられるサービス体系の整備とか？、上りをドカンと行くとか？、何か一発・・・、
- CATV無線LANサービスの実証実験(2002/03/28)
北Ｑで無線LANの実験だそうです。http://www.kitanet.ne.jp/info/pr_wireless.html
(いっそ、「北区全域ホットスポット計画」なんてぶち上げたら面白そう)
基地局1台、1棟、15世帯への試験との事で、場所は公募しているらしいのだけど、 何処が選ばれるのかな？、
処で、北Ｑは実験後速やかに本サービスを予定してるようです。アクセスラインとしてCATV網を提供する だけなのか、それとも無線伝送手段を持ったISPとしてネットワークサービスをより強化するのかな？、 まぁ、折角用意されたインフラも集合住宅が双方向回線施設の障害になっているらしいので、 色々工夫して利用者を増やして貰って、コストに反映して頂けると嬉しい。 でも、それまでには光が御手頃価格に成っていてくれると、更に嬉しい(笑。
- まだ、こんなに在ったんかい(2002/04/11)
IISへの修正パッチ MS02-018 がリリースされています。
なかなか、強烈ですぅ。各々方、努々怠りなきよう(笑。
(マシンリブートせずに入るです)
- 北Ｑ[春の体力測定]始まる！(2002/04/24)
北Ｑも、ぼちぼち行くようです。ADSL対抗、広帯域ガチンコ勝負。
そのXデー(まだ先よ)に備え、一部のユーザを対象に、現在の帯域制限 (端末コースでは、down 3M/up 512K)を大幅に緩和し、CATV網の伝送能力を見極める実験が行われます。
で、今回、めでたく、その実験に参加する事となりました〜(祝)。
実験開始は、もう直ぐ。その実験速度は如何程かと言うと・・・、
下りは今も現役で使われているLANcityモデムの全速、上りはT1二本分、の表現で解かるかな？、 実験ではバックボーンに変化は無く、モデムの帯域制限が変わるだけなので、主にCATV網の伝送能力、 ユーザ宅での実効速度を探る事を目的としてとの事。正に体力測定！(笑)。
北区全域に枝葉の如く広がったネットワークと、その先々で新旧入り乱れて稼動しているユーザ宅の ケーブルモデムが実際に、どの程度の能力を発揮できるのか？、との具体的な情報を実際の運用状態で 集めて、サービスの改定、増速(帯域制限の緩和)の資料とするそうです。
他局の例では、帯域制限を外したサービスを開始したけど実効速度が得られないとか色々、 能力的な問題がサービス開始後に露呈し、トラブルに発展する事も在る様なので、その予防の為にも 今回の基礎情報の収集がサービス改定へ向けた作業の一つとして計画されたのでしょう。
んで、直ぐではないけど、そう遠くない日、そう・・・、高速で大喰らい、凄く熱くなるCPUを搭載した 高性能パソコンがオーバーヒートでヒーヒーしている頃、それに追い討ちを掛ける様にドカンと、 バックボーンもドカンと、そりゃもう大変！。ADSLへの乗換えを激しく後悔するような、 速度命のユーザは狂喜乱舞したりして(笑)、
・・・そんな、サービス改定(大幅な値下げも在ると更に嬉しいのだけど)が可能と成る様な結果が 得られるよう、この実験に期待を込めましょう。
試験全般についての情報は北Ｑからも公開されると思いますアナウンスの予定は無いようです。
家では、試験参加への案内を貰って直ぐ、北Ｑ内ホスト(www0とwww)とのFTPによる自動速度測定を 稼動させてしまいました(笑)。既に実験準備完了ですぅ。この速度測定の結果も経過をみて公開で きると思いますので、それまで暫くお待ちを・・・、(2002/04/24)
と、書き終えてから・・・、
うむむー、丁度今日、NTT西日本がBフレッツ(100Mサービス)の新メニュー開始を予告する発表が在ったようです。フレッツ利用料を従来のベーシック100Mの半額程度に、ISP料金を含めて6000円台も狙える価格設定とか、実施は9月頃との事、こりゃ、東も同じような新サービスで追従する事になるでしょうか。電力系の光サービスも開始され選択肢が増え続けています。今回の北Ｑの増速計画はADSLを追い打ちするには十分な物に成ると思うのですが、アクセスラインの能力的に別格、ついでに値段も別格だった光が続々主戦場に降りて来る事で、より厳しい相手が続々と・・・、北Ｑも大変ですぅ。(2002/04/25)
北Ｑからの正式な情報公開は無いのだけど、測定された速度データ等については網内に限り、 公表可との事なので、北Ｑ外からのアクセスを制限した上で、URLをリンクします。
速度測定の様子 注: 北Ｑ外からの参照はできません。 (北Ｑ利用なのに「見えない」って場合は、私宛 知らせて下さい)
ついでなんで、今回の実験の勘所を私なりに列挙しておこうかな、(2002/04/30)
- ケーブル伝送路
これって、どうなのだろう。ノイズ。結果的には通信エラーを引き起こす頻度は速度に表れるだろうけど、これは個々の通信帯域以前に、良好な安定した伝送路が確保されている事が前提の筈なんだし、流れるデータ量に依存するような事は無い筈だよね？、
- モデム(センターモデム含む)能力
これで思い当たるのは LANcity LCP、下り変調にQPSK(10M)を利用しているモデムの伝送能力ですね、当然、この場合は一台のセンターモデムにぶら下るユーザ数をDOCSISシステムの「それ」より少なくしてバランスを取るのだろうけど、そう言えば最近センターモデムの増設やらネットワーク分離やら色々やっていた様ですけど、サービス改定時の帯域は、この旧モデムの能力が大きく影響し決定する事になるのかも、尤もDOCSISシステムだって、どの程度の能力を発揮できるか謎だけど(笑、その見極めも実験には含まれるのね、
また、上りについては、逆に DOCSIS 系の帯域が不足する結果に成る事も考えないと、下り帯域が広い分、多くのユーザを収容できる能力を有するのだけど、結果的に上り帯域が不足して、なんて事が起きるかも、上りに複数のチャンネルを分割して割当てたり出来るなら解決は簡単なんだろうけど、
- 10Base-T NICの能力
これは、旧モデムとの兼ね合いもあり結構ユーザ宅での速度を左右する結果に成るかも知れません。NICの最大能力付近での利用となると、モデムの接続に10Base-Tのみ対応の物、併せて100Base-TXが利用できる物が混在している今の状況では、その能力差が顕著に現れる可能性があります。この場合、サービスの不均衡を是正する為に、先のモデム能力と同様、適度な帯域制限を設けたサービスを提供する必要に迫られるでしょう。
- ユーザ宅PCの能力
これはー、大丈夫だよね？、10Base-T NIC の操作に根を上げるような貧弱な奴は、無いでしょう？、- キャッシュ(Proxy)能力
不足するようなら、ひたすら分割、増強ですね(笑、今回の実験では、この部分の問題を露呈させる事は難しいのではないかと思います。まぁ、後々問題が起きても増強は容易いでしょうから・・・、
- ルータ、スイッチ能力
これは、カタログスペックから予測が立つから大丈夫かな？、まぁ、この部分も今回の実験では問題とは成らないでしょうし、過去の実績からも予測が立っていると思えます。
うーん、結果は思わしくないです。
まだ、実験が始まり情報が出始めの段階ではあるのだけど、課題として「下り速度が思いの他、伸びない」 ってのが第一、内、特に旧式のLANcityが苦戦。一方DOCSICもTCP転送では苦戦。中でも上りは全滅。 な状態です(笑。
誤解を恐れず、今の状況だけを、私の主観で手厳しく評価すれば、ADSL接続への対抗には成り得ても、
「ケーブル網(特に不憫なDOCSIS)を使ったネットワーク接続に、将来など無い」
と書けるでしょう。ADSLもそうですけど、地点間相互対称を崩すような伝送方法や工夫を凝らした システムには、あまり過大な期待を掛けてはいけないって事でしょうか？、 実験期間中に、なんとか光明を見出したいものです。(2002/05/05)
フジクラ FCM-120U モデムは、ファームの更新により、一応、北Ｑ外の速度測定サイトで 「らしい」下り速度が出る事が解かりました。どうも、モデムのファーム(或いは設定なのかも知れない) により上り能力(特性)が異なるらしく、それが結果に大きく影響しているようです。 家で観測できている特徴は、混雑時でも比較的上り帯域を維持できるけど、送信能力(※) が劣る物と、混雑による変動は大きいけど空いていれば上り帯域、送信能力共に優れている物に 分けられるようで、良好な下り速度は、後者のファームにより記録されています。 ただ、どちらのファームもネットワーク機器としては論外と一蹴されるような不具合を 抱えているので、早期改修と、更なる性能(特に上り)の向上に期待したいと思います(笑。(2002/05/25)※ここでの、送信能力とは、「単位時間当たりのパケット送出能力」です。 大きなパケットを単位時間当たり何個送れるかは、通常、上り速度(帯域)と表現されて 見当が付きます。逆にパケットのサイズが小さい場合、帯域に見合った能力を期待すると、 それなりの数のパケットを送出可能でなければ成らない筈なのですが、どうもDOCSIS(或いはFCM-120U)は、 それが酷く苦手なようです。結果、TCP通信での性能に影を落としているように思えます。
新しいケーブルモデムが併設されました(笑)。FCM-120Uの後継として北Ｑが利用を予定していた製品で FCM-140U(SAMSUNG SCM-140U)です。 今の感触では、性能的にはFCM-120U(新ファーム)と互角かなー。まぁ、止まったり勝手にリブートしなければ良いです・・・。(2002/06/19)
終わりー、本日(2002/07/05)、併設していたFCM-140Uモデムを撤去、同時に不具合の目立つ 新ファームに更新されていたFCM-120Uを交換して旧ファーム搭載の製品に戻してもらいました。 家で利用、試用したモデムについては、(但し、北Ｑでの実験時、環境違いや本番での結果は、謎)てな、状態でした。北Ｑでは、既に増速への予告広告も始まっていて、下り10Mbpsの数字も見えていますが、 その速度に対応できるモデムは、どうやらFCM-120U以降の製品と成るようです。 でも、困った事に、速度試験の経過からだとファームはバグ持ちでリブートするし/止まるしの最低の品質でした(笑)。まぁ、今、急ぎファームの改修が手配されているようですから、それらの完成度に期待です。
FCM-120U 新ファーム(実用には不具合対処の修正版が必須、直るか解からんけど、笑)を使えば下り10Mbps越えの最大速度は出る。上りは1.6Mbps程度が最速結果。ただし、下り速度については、上り送信能力が貧弱なのでTCP速度としては6-7Mbps位が上限速度になりそう(Webなどの下り偏重の転送なら定格速度可かな？)。 FCM-140U 性能は、大体FCM-120Uと同じ、だと思う(笑)。バグっていて半日程度利用しただけなので詳細な性能についてはデータ取りしなかった。実際の利用開始時にはファームの改修も終わって安定して動くように成るでしょう(たぶん)。
で、「まとめ」としては、速度競争の部では、ADSL 8M サービスには北Ｑも色々手を尽くすようなので十分対抗可能な感じ、実効速度では上回る結果を期待できると思う。ADSL 12M とも良い勝負するんじゃなかろうか・・・、ただし、上り帯域を消費する利用では、相当厳しい結果が待っているかも・・・、
普通に使う分には実効速度に期待が持てて安定してれば、本当の敵は、ヤッパリ「光？」。ってな事で、終わりです。(2002/07/15)
- MS-SQL狙われる！(2002/05/21)
またまたワームの大量発生が！。
CodeRed、Nimda に続き、今度は、MS-SQLサーバに食いつく虫らしいです。
http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q313418
これのトラフィック(TCP Port 1433)、家にも多量に来ています。しかし、SQLサーバのSAアカウント のパスワードが空でのインストールを許すなんて・・・、
んでもって、侵入を許すと何でも有りの運動場を提供する事に成るようです。 紹介されている "Voyager Alpha Force," だと、 ついでにIRCを通じて大開放のアナウンスまでしてくれるそうで、至れり尽くせり(爆。 今、急激に広まっている奴は、恐らく、これの亜種じゃないでしょうか？、暫くすれば、 実際に活動しているワームの詳細もアナウンスされる事でしょう。
これ、結構日本のサイトもやられているようです。中にはオークション構築(試験)中のサイトからも Exploitが来たりしていて、オイオイ(汗)だったりします。Nimda同様に何時までもこのトラフィックは 消えそうにないです(笑)。(2002/06/09)
またまた大発生、こんどは UDP 1434 を突いて来る奴。これ凄いかも、たった376バイトのペイロードを持つ身軽なパケットで一撃。感染爆発したか、一国のネットワークを音信途絶と評されるまでに叩きのめしたらしい(笑)。(2003/01/26)
- 網内にSmurf攻撃！(2002/05/27)
なんで今更？、の笑える記録。ICMPエコーによるSmurf攻撃(事故だろうけど)が網内で発生。 当事者間(笑)では有効に機能したようです。
本日(2002/05/27)、15:55〜16:13 にかけて間歇的に、発信源:00D0DD10011C、 IPアドレス(Src/Dst):0.0.0.0 とするICMPエコー要求を引き金にした 網内十数台のホストから宛先IPアドレス:0.0.0.0 へのICMPエコー応答の存在を IPLogが14000件余りのゴミとして記録しました(笑。
北Ｑ網内には、ブロードキャストされたパケットにも、律儀に不到達や経路変更を案内してくれる 親切な(困った)ブロードバンドなルータも沢山稼動しているので、お祭りに参加したホストさんや ルータさんは、さぞお疲れになった事と思います(汗。
で、この祭りに参加したホストをMACアドレスから分析すると、大多数はApple謹製(若しかしてAirMac?) みたいです。これ、発信アドレスが 0.0.0.0 だから答えたのでしょうか？、今回なら自分が被爆する 結果に成っただろうけど、ブロードキャスト(0.0.0.0)に答えるようだと、しっかりSmurf増幅器 として利用できてしまうのでダメですぅ。
- 最近ビシバシ落ちてますぅ(2002/06/09)
先週の土日、そして昨日今日と立て続けにルータトラブルとされる障害で北Ｑネットワークが外界と 遮断される事故が相次いでいますぅ。回復には長いと1時間を越える事も在るようで、 利用者のストレスは、そろそろ限界点へ・・・(笑)、 トラブルとの遭遇に備えて、そんな物ですよ、ネットワークなんて(笑)、 と構えられると精神的ダメージは軽微なのですが・・・、 北Ｑ公認BBS は公認愚痴BBSとして賑わいを見せ、有効に機能しているようです。
北Ｑではルータのインターフェイス交換やリブート、予備機への切り替え等で対処しているようですが 明確な原因の特定には至っていない様子。 (今後も続くようなら、更なる経験値のアップにより回復時間を15分位までなら短縮できそうです、笑)
さて、原因は何でしょう？、狙われているとか(いゃーん)、最近のメンテ時にドジを踏んだとか、 イベント的にはFFとか、速度実験の余波とか、暑くなって来たので運悪くハードトラブルが重なった とか、色々在るのでしょうネ(笑)、今後の様子に注目です。
いやいや、このトラブルこんなに引っ張るとは思いも因らなかったです。 一過性で程なく解決が計られると考えていたので、北Ｑ公認BBSを「愚痴BBS」 と称してリンク貼ったりしましたけど、 愚痴のレベルなど遥かに飛び越え、収集の付かない北Ｑ攻撃BBSに昇格して しまったようです。ネットワークが切れるってスゴク大変な事なんですね？、例え数分でも、 尤も今回はルータ停止の遮断が繰り返されているので、偶に起こる通信障害よりは遥かに深刻な物で しょうけど、それにしてもネットワークへの可用性への期待の大きさを再認識する事が出来ました。 同時に、そんな膨れ上がる期待に今のIPが耐えられるのかと、怖く成ります。(2002/07/12)
- 増速されました(2002/08/19)
本日、北Ｑからの「モデムの設定を変えたからリブートしてちょ」のメールに従いモデムリブート を行い。無事に、下り10Mbps/上り1.5Mbpsのサービスに切り替わりました。
北Ｑでは9月初めまで、今回の増速に関わるCMTS増設など作業予定が組まれているようなので、 4月末に開始された速度実験から数えると4ヶ月を要して、その評価が問われる時が来た。 と言う事でしょうか、速度実験中、トラブルの元凶と成っていたモデム(家のモデムはFCM-120U)の ファームウェアも今回の増速に伴い更新されている筈(?)なので、その改修結果が心配だったのですが、 実験中露見したトラブルを引き起こす幾つかの虐めにも耐え、安定して動き続けています(嬉)。
北Ｑの増速作業は、まだ途中ですし、暫く様子を見ようかと・・・、 さて、困ったかも(笑)、勝手にリブート再発かもかも・・・、
この増速関連の情報として、
UDPデータグラムによる速度測定
速度実験中の速度測定の様子(今も計っている、笑)
を再度リンクしておきます。(注:北Ｑ外からのアクセスは制限しています)
尚、増速に伴う体感の変化は、・・・無いです(笑)。唯一、上りが速くなった事は、 今、こんな風にリモート編集している時に、楽〜、と感じるのだけど・・・、
モデムの勝手にリブートは初日に数回、その後も今日(9/1)までに数度記録されていますけど、 何か弄っているのでしょうか？、予定されているCMTSの増設を終えた後、様子をみてみる 必要がありそうです。
それと、今回のネットワーク構成の変更で劇的に改善された事が一つ。なんと素晴らしい事に、 Nimda/CodeRed/MS-SQL のExploitが一つも来ていません!。新しく使われているアドレスブロックが 偶々ターゲットから外れていたり、周りで余り使われていなかったり、 大陸系のブロックから外れていたり、色々重なっての事だと思いますが静かで良いです。(2002/09/01)
今回の増速もCMTS増設や収容換えなど一通りの作業を終えて暫く経ったので経過など、
速度性能については、家では快適、大変良好のようです。混雑時でも5Mbpsを下回る事は無いですし、 そのような時間帯を除けば、網内外でも略定格速度に達しているようです。
網内での速度測定でも日平均7Mbps以上は維持できているようで実効速度は優秀かな？、 まぁ、収容先が空いていたり、p2p等のヘビーな利用者が少なくて恵まれているのかも(笑)。
北Ｑ速度試験から今日(10月22日)迄の網内HTTP(wwwとwww0)での速度測定結果、
測定間隔は一時間、グラフは日平均。
(2002/10/22)
その後の速度変化の様子。
北Ｑ速度試験から2003年4月4日迄の網内HTTP(wwwとwww0)での速度測定結果、
測定結果はByte/SecですBitではないので注意。
速度実験期間: 2002年4月末 〜 2002年7月初め - 劇的な速度向上は記録されなかったが問題点は把握された。
北Ｑの増速: 2002年8月中過ぎ - 増速直後は速度実験と同様、その後、何度か繰り返されたセンタ設備の増設、収容換えの作業を経て、 2002年10月頃にサービス最高速度に達する。が、その後、速度品質は低下傾向を示し下降を続ける。
(2003/03/05)
DOCSIS 2.0 実証実験: 2003年3月中〜 - この速度測定では、残念な事に評価不能。
両測定サーバの限界(経路上の限界、帯域制限、大負荷など)に達してしまっていて DOCSIS 2.0 の速度性能は反映できていない。 正しく測定できれば恒常的に 2800KByte/Sec を超える結果を得られる。
- もっと速く！、最後の一絞り(笑)(2002/11/02)
ネットワークの通信速度を追求すると利用者側で調整できて通信速度に影響を与えるパラメータとして良く挙げられる物に MTU、RWin(TCP Receive Window)と呼ばれるTCP/IPのパラメータが出てきます。
この２つのパラメータの場合、北ＱでWindowsを利用なら、MTUサイズはイーサネットの最大サイズである1500に、RWinについては、MSS(*1)×20 位に設定すれば、概ね網内(笑)では最大速度で通信可能な状況が整うようです。
特にWindows95/98/Me(*2)を利用している場合にはMTUサイズの大きさだけでも確認(*3)して調整する事で速度の低迷から抜け出せるかも知れません。
でも、RWinについては、本来なら通信相手との伝送遅延時間と伝送帯域から適切な容量が決定される物で、相手に因っては遅延が結構小さかったり、遅延に見合う大きさを用意しているのにCATV特有の伝送特性なのか一定の遅延時間が維持されなかったり、何より通信相手が用意した大きさを使わなかったり(通信時、相手方も同じ容量のウインドウバッファを確保する必要がある)、等から、苦労して調整したり、無闇に大きく設定しても余りご利益を得られないようです。
また、北Ｑ(CATV)ネットワークでは、下り通信速度低下は必ずしも下り帯域の不足や遅延だけが原因では無く、上り伝送路の特性としてTCP通信で必要なACK(肯定)パケットの滞りが速度低下の原因と成っている様子をUDPを利用した速度測定やTCPセッションの統計から得られます。そんな状況ではRWinの御利益に与れる筈も無く(笑)、なので、何か利用者側で弄れて、少しでも速度を搾り出す方法は無いものか？、が今回の本題だったりします(笑)。
以降は、Windows 2000 での事例で他の環境での適用については不明ですので注意してください。
これは、偶々ソケット通信プログラムを弄っていて発見した事なのですが、TCPソケットハンドルに設定できる送受信バッファのサイズを大きくすると通信中のACKパケット数が若干(10%程度？)減少するようなのです。恐らくTCPスタックとソケットドライバ間でのデータ転送単位が大きくなる事で引き起こされるのでしょう。LAN通信等では若干通信速度が改善される程度の変化なのですけど、ケーブルの下り速度では、情けない事に、上りACKパケットの減少が即、下り速度の改善に繋がったりします(笑)。通常、Windows 2000 では、ソケットハンドルには8KByteの送受信バッファが規定値として割り当てられ、オプション指定によりサイズを変更しない場合、そのバッファ容量でソケット通信が行われています。なので、この規定値を変更(大きく)できれば、もしかすると若しかするかも・・・なんて事に成ります(笑)。
で、この規定値ですが、レジストリにより設定可能なのです。で、当然コレを弄るのですけど・・・失敗すると何が起きるか解りません(笑)。また、このバッファサイズを規定より大きくする事で、ソケット通信に何か不具合が生じる可能性も有りますので、以降は、何が起きていも自己責任って事にて願いまする。
で、レジストリなのですが、
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AFD\Parameters
です。この Parameters キーが無ければ作成して、そのキーの下に次の名前で、
DefaultReceiveWindow
DefaultSendWindow
DWORD値として 0x4000〜0x8000(4Kページ単位？、RWinを超えない方が良い様な気がする)を設定します。
この後、リブートすればソケットの規定バッファサイズが変更されます。家では現在32Kの設定で試していてるので、暫く様子を見れば速度測定結果などに成果が表れるかも・・・です。さて、とうなるかな？
尚、このレジストリや2KのTCP/IPについての詳細は、 http://www.microsoft.com/windows2000/techinfo/howitworks/communications/networkbasics/tcpip_implement.aspのtcpip2000.docを参照の事。
上記の日本語版(2003/01/11)
(*1)MSSは、MTUサイズからIPとTCPヘッダの大きさ、通常40を引いたサイズ。
(*2)Meでも異常に小さく設定されている奴に出くわしたので、安心できない。
(*3)現在のMUTサイズの状態はPingで調べられます。ping -f -l [MTU-28] www.kitanet.ne.jp
MTUサイズ1500に設定されていれば、
ping -f -l 1472 www.kitanet.ne.jp
で応答が得られるはずです。若し "Packet needs to be fragmented but DF set." の様に表示されたら -l に続く値を小さくして行き、応答が得られた値+28が現在のMTUサイズと成ります。
- これも所謂一種のSmurf-DoS・・・なの？(2002/11/03)
利用中、何だか止まったみたいだからルータ機にTelnet接続して、徐にWindumpなんてしたら激しくスクロールアップして行く正体が、これだもの(笑)。
11:31:06.550693 0:1:0:e0:18:a8 0:1:8:0:6:4 dd43 906: 0a03 d202 0000 0000 0000 0a03 2eb6 0000 0000 0000 0000 0000 0000 0000 0000 0000 96e8 0dee 0002 0100 300e 300c 0608 2b06 0102 ffff ffff ffff 00e0 18a8 dd43 0806 0001 0800 0604 0001 00e0 18a8 dd43 0a03 d202 11:31:06.555017 0:1:0:e0:18:a8 0:1:8:0:6:4 dd43 906: 0a03 d202 0000 0000 0000 0a03 2eb6 0000 0000 0000 0000 0000 0000 0000 0000 0000 96e8 0dee 0002 0100 300e 300c 0608 2b06 0102 ffff ffff ffff 00e0 18a8 dd43 0806 0001 0800 0604 0001 00e0 18a8 dd43 0a03 d202 11:31:06.559325 0:1:0:e0:18:a8 0:1:8:0:6:4 dd43 906: 0a03 d202 0000 0000 0000 0a03 2eb6 0000 0000 0000 0000 0000 0000 0000 0000 0000 96e8 0dee 0002 0100 300e 300c 0608 2b06 0102 ffff ffff ffff 00e0 18a8 dd43 0806 0001 0800 0604 0001 00e0 18a8 dd43 0a03 d202 11:31:06.563695 0:1:0:e0:18:a8 0:1:8:0:6:4 dd43 906: 0a03 d202 0000 0000 0000 0a03 2eb6 0000 0000 0000 0000 0000 0000 0000 0000 0000 96e8 0dee 0002 0100 300e 300c 0608 2b06 0102 ffff ffff ffff 00e0 18a8 dd43 0806 0001 0800 0604 0001 00e0 18a8 dd43 0a03 d202 11:31:06.568021 0:1:0:e0:18:a8 0:1:8:0:6:4 dd43 906: 0a03 d202 0000 0000 0000 0a03 2eb6 0000 0000 0000 0000 0000 0000 0000 0000 0000 96e8 0dee 0002 0100 300e 300c 0608 2b06 0102 ffff ffff ffff 00e0 18a8 dd43 0806 0001 0800 0604 0001 00e0 18a8 dd43 0a03 d202 11:31:06.572348 0:1:0:e0:18:a8 0:1:8:0:6:4 dd43 906: 0a03 d202 0000 0000 0000 0a03 2eb6 0000 0000 0000 0000 0000 0000 0000 0000 0000 96e8 0dee 0002 0100 300e 300c 0608 2b06 0102 ffff ffff ffff 00e0 18a8 dd43 0806 0001 0800 0604 0001 00e0 18a8 dd43 0a03 d202 11:31:06.576682 0:1:0:e0:18:a8 0:1:8:0:6:4 dd43 906: 0a03 d202 0000 0000 0000 0a03 2eb6 0000 0000 0000 0000 0000 0000 0000 0000 0000
初めはネットワークで起きているかと思ったけど、どうやら、この妙なトラフィックはモデムの異常により引き起こされるようです。
利用中、時折(数日に一度〜日に数度、伝送路の状況にでも依存するのか？)、勝手にモデムがリブートされる症状が以前から在るのですが、この妙なトラフィックは、稀にモデムがハングアップする症状の際に確認される様です。モデムが暴走状態に在るのでしょうか？、モデムのリセットで復帰しますが、余り頻繁に起きるようでは困ります。って言うかハングアップなんて論外です(笑)。これも、ファームのバグですかねぇ？、或いは何か特別なトラフィックやデータパターンで起きるようだと凄く楽しいかもです。まぁ、SAMSUNG製はダメダメと言う事で・・・。(2002/12/15)
- モデムの不具合、今、調べてます(2003/03/13)
前に書いたモデムの不具合ですけど、最近に成り悪化傾向を示したのでサポートさんに相談したところ、この6日から予備のモデムを併設した状態での調査(発症待ち、笑)を行っています。 若しハングアップしたら、予備モデムに切り替える事でネットワークを利用出来る様にし、異常状態のモデムは、そのままの状態でメーカーさんの診察を受けさせる。 との計画らしいのだけど、このハングアップは時折発生するモデムが勝手にリブートの際にコケているのだと思うので状況を保全しても何か有意義なデータを取得できるか微妙な処だったりします。
また、これに併せてか普段センターからモデム生存を確認しているポーリング操作が(一時?)止まっています。
このポーリング(モデムスキャン)は接続されているDOCSISモデムへpingで生存を確認しているとの事で、全モデムを繰り返しスキャンしている為、ARP+ICMPでも相当量のトラフィックに成っていたようです。 止めたのは、このトラフィック削減も目的らしいのですが、困った事に、これが止ると同時にモデムの不具合(リブート)も起きなくなった様な気が・・・、 まぁ、暫くは様子見となるようで、早くハングアップ(リブートでも良い！)しないかと北Ｑさんが待っていたりする(笑)。
状況の変化だけから眺めると、
てな、具合でしょうか、んでもって、今の所、妙に安定してたりするので大丈夫だろうって事にして、このままDOCSIS 2.0モデムの実働テストに突入しちゃったりする事に成りました(祝)。 まだ、採用の可否は未定との事だけど、30Mbps級のサービスをDOCSIS 1系でやるほど北Ｑさんは無謀ではないって事かな、これでキッチリ性能が出るようなら、後は値段の勝負となるのでしょうか？、自動速度測定も前の速度実験の時から引き続いて動いているし、また、色々苛めてみる予定(笑)。近い内に網内には様子を上げられると思います。
- モデムへのポーリング操作が原因？
その程度でコケては堪らんのだけど、若しかすると恒常的に何か流れている所にノイズを受けたりするとエラー検出や修復処理がバグっていてダメダメだったり。
- RFの信号レベルが高すぎた？
今、予備機を接続する為に分配器を通しているので、最低でも3db(たぶん4-5db)普段より信号レベルが落ちている筈。 受信なら入力信号(一緒にノイズも)低減しているだろうし、上りは出力が少し大きい状態に成っているかな？、まぁ、殆ど誤差の範囲の様に思うけど、アッテネータ噛まして一挙に解決かも。
- 単なる接触不良とか
F栓嵌め直したら直るという有りがちな結論だったりして(笑)。
えと、DOCSIS 2.0の実験だけど、一応、モデム取り付けて始まった。
例の如く北Ｑ網内に制限した上で、実験記録へリンク。(2003/03/16)
えーと、このトピック本来の課題である「モデムが勝手にリブート」現象ですけど、 調査目的での予備機の接続と北Ｑのモデムへのポーリング停止で好転したかに見え、 その後、DOCSIS 2.0 実証実験に突入、と続き解決したかに見えましたが・・・実は再発、 そして、悪化しています(笑)。
リブート頻度は、以前の最盛期を軽く突破する勢い。新記録の樹立も略確定状態に有ります。 一応、北Ｑでは同一ケーブル(ノード？)上の他のモデムの挙動を観察したり、 モデムのファームを動作検証済みの最新の物へ更新したり、 と色々手を打ってくれているのですが改善の兆候は見えません。
さて〜、これって家のモデム特有の障害なのでしょうか？、
参考までに、家での発生状況は、 こんな感じ(北Ｑ外からのアクセスは制限) なのですが・・・、(2003/06/11)
つづき、
んでもって、まぁ、このモデムの勝手にリブートについて、 世の中(北Ｑ内)がどんな様子なのかと、6月12日零時より、約40時間に渡りモデムのリブートシグネチャを 補足して様子を見てみたのですが・・・どうやら、なかなか手強そうです(笑)。
尚、この方法で補足されるリブート記録には、利用者が電源の再投入を行った物も含まれる訳ですが、 その多くは「勝手にリブート」してるんじゃないの？、と疑わしいもの多数。 そして、流石に人間業では難しかろう。と思える奴が含まれています。 さて、その結果ですが、
先ず、補足されたモデムのリブート件数は総数 1156件、これを構成しているモデム総数は 463台、 最もリブート頻度高い奴は 107回(笑)、これを含め10回以上のリブートを記録しているモデムは 4台、 それに満たなくとも 5回以上のリブートを観測できたモデムは35台余りに達しています。 参考までに、この間、家のモデムのリブートは1回と低調に終わっています(笑)。
そして、何より面白いのは、このリブート発生時刻に余り偏重が見られない事です。 つまり、若しモデムのリブートが伝送路上のノイズ等による起因で発生しているなら、 その発生時刻に複数のモデムが一斉にリブートする様子などが観測されると思われるのですが、 その様な兆候が全く見られないのです。 なのでリブートの観測記録では、数分間隔で何処かしらでモデムがリブートしている様子が延々と続きます。 そして、個々のモデムのリブート間隔に周期性が有る様にも見えません。 これは一体どういう訳なのでしょう？。
以前に北Ｑからのモデムへのポーリング停止で一時改善が見れたように、 やはりネットワークを恒常的に流れる何かしらのトラフィックがモデムリブートの引き金を引いているのでしょうか？、以前にも予想される原因として挙げたように、モデムの作りがヨワヨワで直ぐにコケてしまう程ダメダメと言う事なのでしょうか？、 それと、若しかして家なんかはリブート症状としては軽症の部類に入るのでしょうか？、 流石に40時間で10回以上もリブートする体力は、今の所持ち合わせていないようです(笑)。(2003/06/13)
その後の経過とか、
数日安定してリブートせずに動く事も有る様なのですけど、 長続きはしないようで対策前と同様に日に1-5回のリブートが発生したりしています。 どうやらモデムのファーム入れ替えは、このリブート障害については大きな効果は無いようです。
また、これは副作用なのか？、今のファームは上り能力(速度じゃないです。小さいパケットの送出能力)が 以前利用していたファームより劣るようで下り速度が全般的に低下、 3-5Mbspで妙に(笑)安定する状態と成っています。 昔の速度実験のデータと比較すると実験開始当初の最も古いファームの特性に似ているかな？、 まぁ、今はサービスを開始したDOCSIS2.0システムの性能問題解決で忙しいでしょうから、 一段落したら再度の見直しと対策をお願いしたいものです。(2003/07/04)
- DOCSIS 2.0 (2003/04/03)
DOCSIS 2.0 の実証実験(北Ｑ外からのアクセス不可)ですけど、 そろそろ終わります。なので様子など書いておこうかと、
先ず、DOCSIS 1系とは、上りだけが別物で、下りは従来通りの64QAM(30M、正味27M)/256QAM(40M、正味35M)のまんま、で、肝心な上りだけど実験では、区内全域単一ノードなんていう厳しい状況だった為、 上り信号のS/N比が悪いらしく最高速30Mbpsを実現可能な64QAM変調は使えなかったらしい。それでも、変調速度を落とした状態で12Mbps程度の実測性能は安定して確保され、 DOCSIS 1系で問題に成っている上り帯域の不足。 正確には帯域じゃなくて上り送信契機の不足による下り速度の低下。の発生は確認できませんでした。
DOCSIS 1系では、TCP通信などの場合、上りの肯定パケットの滞りが発生して、下り帯域が余っているのに下り速度低下が発生する珍現象が発生し「ケーブルなんて駄目、駄目」の原因を作っています(笑、これ現状ネ)。これは、上り送信時に他のモデムとの衝突を回避する為にタイムスロットを予約する事で同一ノードのモデムでは或る瞬間に送信できるモデムが常に一台となる様に調停操作が行われるのですが、上り通信の帯域がが不足すると全ての利用者の送信契機が不足し、同一ノード利用者全てのモデムで下り速度の低下として表れるDOCSIS 1系の宿命に因ります。一応、実験中に測定できた下り最高速度は 網内で24Mbps 位。これはFTP転送なのでHTTPなら略理論速度に匹敵する速度を記録する事も可能ではないかと予想します。 何れにしろ 下り30Mbps/上り10-30Mbps 程度のサービスは、DOCSIS 2系のシステムを利用する事で提供可能と成る事でしょう。でも、採用可否は未定らしいけどネ。
DOCSIS 2系では、上り変調にS-CDMAを利用する事で同時に送信できるモデム数を一台から複数台に拡張する事により上り送信性能を改善し、高速(上り)通信に対応させたシステムと言えそうです。
なので、若し、この DOCSIS 2.0 が採用されたなら、
ファイル共有や交換とかに人生掛けちゃっている人は是非、この2.0を用いたサービスメニューを選択して利用されて下さい。充実した上り性能を体感できますよ！、だいたい、不憫な DOCSIS 1系で最先端を行くP2Pでのファイルの共有だの交換だの、そんな大胆な事しちゃいけません！(笑)。
設計が古くて、まさかこんな、下りが10Mbpsを超えるとか、併せてMbps単位で上り帯域が消費されるとは思いも因らぬ時代に作られた代物に無理させるとボロが出るんです(笑)。他の多くの利用者も迷惑被っていると思うし、なので、是非 2.0 へ移行を！。
で、当然な事に、現行サービスは劇的な値下げ・・・ですよね？(笑)。期待してます。
- 何故？、最近の流行なの？(HTTPパフォーマンス障害) (2003/04/28)
最近の「 お家サーバ 」へのHTTPリクエストについて 某監視装置(笑) のログを眺めていて気が付いたのだけど、 Web閲覧でパフォーマンスが低下していると思われるTCPセッションが増加しているようです。 コレ若しかして、対ウィルス製品やパーソナルFW等に因る物なのでしょうか？、 内容はHTTPプロトコルのTCPセッションにおけるパケットレベルの細かい話なのだけど・・・。
普通の問題無いHTTPのセッションでは、TCP通信なのでSYNから始まり３ウェイハンドシェイク を完了するとクライアントからHTTPリクエストが送られて来て、その応答(コンテンツ)をサーバーが返して、 セッションが不要なら(セッションキープしないなら)切断を行って完了しますよネ。 で、この場合、サーバの応答時間は、TCP接続の要求を受けた時点から、それに応えて接続を完了し、 リクエストを受け取って最初の応答の送信を始めるまでの時間、 通信速度も含めた性能評価(良くある通信速度の測定など)の場合なら、 コンテンツ全ての送信が完了するまでの時間が競われる訳です(笑)。
この時、TCPレベルでの動きを観測すると、普通なら接続完了後に送られてくるHTTPリクエストは、 大体300〜500バイト位、大きくても普通のGET要求なら1Kバイトに達する事は稀で 大概はTCPパケットのMSSサイズに十分収まる大きさな訳です。 なので、普通ならHTTPリクエストは一つのパケットに積まれて伝送されサーバに届くのですが、 最近観測される物には妙な奴が混じっていて(笑)、 HTTPリクエストが何故か三つのパケットに分割されるのです。
その妙な分割はIPフラグメントされる。とかの話じゃなくて、 送信時の動きが変と言うか妙と言うか・・・ それでいて器用な規則性を伴っている様なので不思議なのです。
この妙で変な奴がTCPセッションを確立してからのHTTPリクエストデータ転送の様子を眺めると、
表の様に成る訳です。まぁ、コレ単にパケットの分割だけなら性能問題は殆ど無いのですが、 何故か最初の164バイトのパケットが届いた後、2〜3秒遅れて２番目の１バイトのパケットが 届き、その後は特に妙な遅延無く残るデータを積んだパケットが届きます。 そして、この後のコンテンツ転送などは至って普通といった具合です。 この時、要求されたコンテンツが短いテキストや小さい画像なら、 応答時間を含め精々数十〜数百mSで完了できる筈なのに、 何故かHTTPリクエストで数秒詰まり、酷いパフォーマンスの低下を引き起こしています。 コレ、Webを軽快に快適に利用したい向きには、大きくて深刻なパフォーマンス障害でしょ？(笑)。
パケットの順番 ペイロードのサイズ メモ(内容) 1 164 HTTPリクエストメソッド(GET/PUT/etc)
を含むリクエストの開始文字列データ2 1 リクエストの続きデータ
(数秒遅れて何故か１文字)3 不定 リクエストの続きデータ全部
(2番目からの遅れは無し)
さて、この不具合(笑)の原因は何でしょう？・・・、ってな事なのでしょうか？(笑)、尚、これが観測され始めたのは4月8日辺りから、 自己申告に因るOS種別では、MS謹製が多数を占め。エージェントはIE5〜6、他と多岐に渡ります。 また、この中には北Ｑ利用者からの物が比較的目立ちます。 若し、興味が有って自分の通信状況を知りたいなら、 IPLogのデモページ が参考に成るかもです。
- 単なる流行(クライアント起因、固有の自己表現、腐った製品積むな)。
- 透過キャッシュがお仕事している(選択的に動くなら凄く器用)。
- やっぱり何か良からぬ怪しい奴が間に入っている(ネタとしては楽しい)。
- 実はサーバ起因(笑)、若しかするとTCPオプション(TimeStamp他)の副作用？。
- 若しかするとMS03-013のパフォーマンス障害。でも日付が合わない。
この不可思議な現象の原因が解りました・・・たぶん(笑)、 恐らく、AFDのリソース不足・・・つまり・・・サーバ起因(汗)、 Webサーバへの帯域制限を疑い様子を見てみたのですが、 TCPスタックの動き自体が変な事が解りました。 これが発生しているとSYN-ACKに時折RWinを164バイトとして応答し、その後、正常に復帰したり、 時にRWinが0を示して通信が一時停滞したりと不安定で妙な挙動を示すようです。
で、この原因として思い当たるのが アレかな？(笑)、 DOCSIS 2.0 の速度実験を機にバッファサイズを大きく設定したのが原因なのか、 家だけの固有現象かもしれないけど適度な所に調整して様子見する事にしました。
それにしてもメモリならまだ余っているのに・・・はて？・・・謎です。 尚、家では今の所、この不具合は、インバインドのTCPだけ？、で発生していて、 Webサービス程度なら放っておいても良いのだけどLAN内でのSMBで発症したりすると 耐え難い程に通信速度がストールしてしまいます。 でも、外へ繋ぐ限りでは何とも無いという妙な状況だったりして(笑)。(2003/05/18)
AFDリソース不足との原因推測は間違っていました・・・たぶん(笑)、
バッファサイズの調整で改善が見られる様では有ったのですけど、 本日SP4を入れた処、再発(笑)、SMBがどうにも重くて使えないので色々調べてみました。
・・・で、若しかすると、TCPスタックに設定していたSYNアタックプロテクトが原因かも〜、 まぁ、これを解除したら正常復帰しました。と言うだけの事なのですけど、 妙な時の動きも、インバインドだけで発生し、AFDへの接続が遅延する(Windowsサイズのアサーションが 遅れる。これがメモリ不足でアロケーションに時間を食っているように見える)、 スループットの低下(これは、プロテクトとは関係無いと思うが不明)、てな処を考えるに、 若しかするとSYNアタックプロテクションの発動か、それらの設定誤りや誤動作が原因なのではなかろうか、 との結論に至りました。また、暫く様子を見てみる事にします(笑)。(2003/07/03)
- DOCSIS 2.0 売れ行き好調らしい (2003/06/10)
7月1日よりサービス開始が予定されている DOCSIS 2.0 システムを利用した北Ｑの 30Mbps(上り5Mbps) サービスの売れ行きが好調なんだそうな・・・良きかな、
なので、更に売り上げを伸ばすべくモデムの交換費用を更に半額にするとか(笑)、 はてさて、好調なのか不調なのか、よう解らん状況な今日この頃だったりするのですが、 今のサービス(DOCSIS 1系)の次の様な処に不安を抱いている方々も、2系への乗換えで 少しは安心できるかも、かも〜、と言う話題を一つ。
前から、現行システムでは、L2(イーサネット)レベルで発生する様々な笑える(不思議な)状況 ってのを何度も観測する機会が有りました。でも、L2でMACアドレスがスプーフ出来るとか、 されたとか、の話題には触れずに居たのです。 けれど、最近、チョット気に成る事が有って不安が募り・・・(笑)、 北Ｑに問い掛けるも、どうも回答が引き出せないようです。
まぁ、北Ｑは、L3(IP) サービスを提供するのが仕事！、 L2 の事なんか知るか！、聞くな！。てな事なのかも知れませんけど、 バックドア埋め込むウィルス/ワームは蔓延してるし、 OSも進化してリブート不要でパケットドライバをダイナミックにローディングできる時代に、 何時までも仲良しLAN、利用者性善説に乗っ取って信頼を寄せ続ける訳にも行かないでしょう？。
それに、マルチキャストアドレス境界など無視して何でもかんでも WAN へ投げ返すような素敵な BR(smurf増幅器) も沢山動いていてるし(大体からしてマルチキャストなんか不要でしょうに)、 一度、事か起これば、そりゃもう無茶苦茶な状況に・・・。
なので、今パケットを打ち出した先のGWは、本当に北Ｑの物？、届いたパケットは寄り道してない？、 IPアドレスの解決に使ったDNSは本当に北Ｑの物？、 得られたIPアドレスは本当に正しいの？(おっと、これはL3でも同じか)、 なんて心配(笑)を少しは緩和するような L2 の見直し、調整を図ってくれると嬉しいなー、 とか思ったりする訳です。
んでもって話を戻して、DOCSIS 2系 だと、この L2 レベルも整理か付いていて今のシステムよりは 余程安心が得られるのではないかな？、と言うお話だったりします。
BBSへ寄せられる利用者からの情報では速度が出ないって？、
地域的な物なのか、30Mコースの一部(若しかして全般？)で性能問題が発生している模様、 「コース変更前より速度が低下した」なんて言う事態だけは何としても避けないとネ、
新しいシステムだし、多数のユーザぶら下げての本運用での実績はこれから、 と言う事なのでしょう。(2003/07/04)
- 祝？、Ｐ２Ｐ規制 (2003/08/09)
北ＱBBSへの書込みや北Ｑで公開しているトラフィックグラフなどを参考にすると、 北ＱでもP2Pへの帯域制限が実施されているらしい。
この影響を諸に受けるのは、この7月からサービスされた30Mコースのの利用者だろうか？、 どうやら、DOCSIS 2.0 で強化されたインフラでも上り帯域(提供速度5Mbps)の浪費に耐えられず(笑)、 速度性能が維持できない状況が続き帯域制限と相成ったようだ。
お陰で30Mコースは、それなりの下り速度が提供されるようで「普通」の利用者に取っては 有難い状況らしい。 一方、旧来の10Mコースの方は、特に速度性能に変化は見られないようで様子見の段階か？、 利用法に因っては10Mコースの方が上りは快適、なんて状況が生まれているかも知れない。
しかしまぁ、この通信速度のゴタゴタは、提供する側の迂闊な表現と、 それを真に受ける利用者側の誤解が招くインターフェイス上の問題なのだから、 双方、歩み寄っての相互理解による解決を図る努力を試みても良いのではないだろうか？
先ず一つ、提供側は「ベストエフォート」の慣用を避ける事、だいたいベストエフォートの起源は、 パケット通信の構造から速度性能を保証できない為に生み出された便利な表現に過ぎないのに、 帯域共有型サービスの最大能力(通信速度)を示してのベストエフォートでは、何も伝わらない(笑)。 なので、サービスの表記は、
「下り速度30Mbps(端末300台で共有)、上り速度5Mbps(端末100台で共有)、 通信速度はベストエフォートでの最大速度です」
なんて表現してくれた方が親切でしょ？、 これなら、利用者も占有の許される下り帯域は100Kbps/上りは50Kbpsしか無いと理解できる。
まぁ、コレだけでは問題の本質への解決能力を持っていないので、 併せて、青天井の「従量課金」を導入、これでP2P問題は綺麗サッパリ解決(笑)。
利用者も妙な帯域制限受ける使えないサービスより、コストさえ負担すれば楽しく使えるネットワーク の方が嬉しいでしょ？。
- 時間ですよ〜(笑) (2003/08/15)
凄いです。MS-Blaster。
北Ｑ内でも感染ホストは12,13両日だけで軽ーく200台突破。 今も新たな感染ホストを検出し続けています。
ユニークホストを正確に掴めるDHCPアロケーションの同一セグメント(22bit) での観測でも相当数に達していて、有効な利用アドレス数を8割り程度に見積もっても 1割程のホストが感染し、確り稼動中の様です(笑)。
んでもって、既に気の早い奴なんか始めている奴も居るらしいですけど、 一応、まともに動いている奴なんかは、御仕事(Windows UpdateへのDOS)始める時刻を 今か今かと待っている。まぁ、時計はローカルタイムなのかGMTなのか知りませんけど、 その時刻が刻々と迫っているわけです。ここで幸いなのは、NYの大停電ですかねぇ、 世界的規模で見積もると、今も(8/15 12:00 JST)続いている停電で2割り位は威力が削がれるでしょうか？、 DOSトラフィックでのネットワーク麻痺なんて事が起きずに不発に終わると良いですけど・・・、 でも、停電に比べれはBlasterなんて大した事じゃないですね、
さてー、Windows UpdateへのDOSは、MSさんの機転、と言うかDNSレコード抜いちゃうって言うインチキ(笑) で無事回避できたようで目出度し目出度しなのですが・・・、そのー、何時治まるのでしょうか？
何か治まったみたいなので集計停止。 2004年4月までの記録。
- ポート遮断の通知も出来ないらしい(笑) (2003/09/12)
Port:135,4444に続き新たに遮断されているポートが増えたらしい。
たぶん今月の4日辺りからPort:137,139,445が遮断されている。 で、今日に至るまで利用者への通知は無論、Web上での掲示さえ何も無い(笑)。
CIFSはIPSec通したりして使っている人も居るのではなかろうか？、 少なくとも利用者へ事後の通知位は有って欲しいものだ。
- 祝、Winnyショック (2003/11/29)
・・・、んなもんで、
ここ数日(〜数週間かな？)、トラフィックの需要を正確に(笑)把握できる絶好の機会が到来です。
本来無い筈の犯罪行為に利用されている不要で無駄なトラフィックに、 どれだけ無駄金を使っているか？、各所で観測できる事でしょう(笑)。
- 深刻なので・・・ (2004/04/28)
北Ｑネタという訳ではないのですが、
無線LANのセキュリティに関するガイドライン「安心して無線LANを利用するために」
p.s. 家では4局拾えて、3局オープンです(汗。
- ブレークするの？ (2004/05/01)
Gaobot (Symantecさん)、 Agobot(CAさん)
何か素敵ですよ、今までのワームの集大成って感じで、Windowsの穴端から突いてくるし、 パスワードクラックするし。ブレークされるとログが嵩んで大変なんで・・・一つ宜しく。
- 祝、第二次Winnyショック(笑 (2004/05/11)
さって、何処まで下げるでしょうか？、 30Mも光も売れたんだから、もう良いしょ？、
第３次ショックはもう来る事は無いと言う事で、終われますか？ >> 人生掛けちゃっている人達。
- マルチキャスト・駆ける！(笑 (2004/06/16)
何やら、とても素敵なBRが使われたのか？、複数繋ぐか魅力的な機能を使ってデュアルホームでも 作ってしまったのか？、RFCに従えばTTLが切れようが、送り先が無かろうが、扱いに困って 困惑しようが、黙って捨てて涼しい顔してなきゃいけないマルチキャストされたパケットへ 懇切丁寧に怒涛(自分でループしてやんの)のICMPメッセージ、しかも北Ｑ内のへはブロードキャスト！。 もう殆どDDOS(笑)、ICMPだから変則Smufr攻撃か？、 で応えて頂ける素敵なホストが数日前から出現しました。
まぁ、幸い持続時間は数秒、また、無節操なホストが少ないので発生も散発的だから大事には 至っていないけどチト危ない起爆寸前状態。
現状、こんな状態 (笑)なのですけど、被爆したときの被害はFW/BRの性能、特性に依存でしょうか？、 まぁ、ダメダメなBRは使うの止めましょうよ、って方向で、 尚、困ったBR(NIC)のメーカーさんを知りたいときは、 IEEEでMACのベンダIDを検索 できます。今の困ったさんは、NETGEAR製、BRへの設定不良ですかね？、(2004/09/29 修正加筆)
- SP2 (2004/09/14)
XP-SP2 調子よさげなのですけど・・・ね、IEがダメポ？(笑、
Version: 6.0.2900.2180.xpsp_sp2_rtm.040803-2158
これ、XBMが表示されないじゃん。
- Black OUT! (2004/12/06)
一応、記録しておくって事で、
北Ｑの停電事故は二度目(前のは点検中に・・・ポチ)だったと思うけど、 今回のは強烈だったようです。
放送で3時間余りの停波、9万世帯程が砂嵐を見る事に、 また、ネットワーク(IP電話も一緒かな？)の完全復旧には5時間余りを要したようです。
まぁ、今回の事故で解った事は、電源確保は大切(笑)って事と、 北Ｑの経営規模がTV約9万、ネットワーク約1.1万と初めて数字が得られた事。
[リンク集とか]
- Delegate http://wall.etl.go.jp/delegate/
とにかく何でも出来る汎用 Proxy。ネットワークの中継絡みで困ったら、先ずこれです。
- SOCKS (自分で作った奴)
ブロードバンドルータ全盛だってのに、家ではコレなんです(笑)。 正確に書くと、SOCKS と NATルータ を併用しているのです。httpとかnntpとかはルータ経由、 ftp等の逆張りの起きるプロトコルは全部SOCKS経由と言う割り振りをしています。
SOCKSを使うには専用のクライアントかプロトコル変換のカラクリが必要に成りますが、 次に紹介している hummingbird の SOCKS Client の利用が便利です。
- SOCKS Client V7 (http://www.hummingbird.com/)
SOCKS利用者、ご用達かな、Product(free)から探せます。
これを使うと、LANから外へ出るような通信を自動的に全部SOCKS利用に切り替えられます。 もちろんUDPも、おまけにBINDの設定もスゴク簡単。
現在(2002/02月)の上記Web上での配布は、Windows XPへの対応を計った SOCKS Client V7.1 と成っています。コレをWindows XP上で利用する分には問題ない様なのですが、Windows 2K で利用する際には、SOCKSを通過させない直接接続(socks.cfgのDirect指定など)などにパフォーマンス上の障害が発生する事が在るようです。若し、Windows 2K で問題が起きるようなら、以前の V7 をFTP(ftp://ftp.hcl.com/pub/bbs/socks/socks7/)から入手して利用できます。V7.1 にも、その内、修正が加えられるかと思います。それと、V7 と V7.1 では設定ファイルの拡張詞が .cnf から .cfg に変更に成っているのも忘れがちなので、注意です。(2002/02/03)
.cfgファイルに記述できる Direct 指定の不具合が修正された版(7.1.1)がリリースされました。でも、 やっぱり、直接接続が何か妙です(笑。接続には支障ないのですけど、Webブラウズ時の応答が何とも鈍いと言うか、スループットは出ているようなのですけど、停滞すると言うか、若しかして接続時のオーバーヘッドが大きいのか？、とも思ったのですがHTTP/1.1でセッションをキープしていても画像やバナーの多いページのロードに酷くもたつきます。Win2K、或いはIEコンポーネントのソケット周りの問題なのか詳細は調べていないけど、SOCKS通す場合は何も問題なく快適なので謎です。(2002/04/10)
それと、これ使うならhummingbirdが主催しているユーザコミュニティーのMLが有るんで横文字メールにアレルギーが無いなら入っておくと参考になる事が在ると思うです。(2002/02/22)
随分と時間が掛かりましたが、直接接続時のパフォーマンス問題への対策パッチ(dllの差し替え)が配布されました。ftp://ftp.hcl.com/pub/bbs/socks7101/ から入手できます。(2002/10/24)
- VPOP3 (http://www.pscs.co.uk/)
家のMailサーバ。
昔々、ダイヤルアップでの運用が便利なので使い始め、未だに利用を続けています。 一応、家では完全(?)なMTAとして機能しています。
内蔵するWebメール機能などが日本語へ完全対応すると、また、面白いのですけど
- Plum IRC常駐ボット ftp://ftp.madoka.org/pub/plum
IRCへの常駐(#北Ｑ他)に利用している中継/クライアントプログラム。
- Dynamic DNS
DHCPにより得られる非固定のIP(グローバルアドレス)でも、ドメイン名の利用は可能です。
と言っても逆引きまで備えたDNSサービスは利用できませんけど、IPアドレスの代わりに普通に名前 として利用するには十分機能的な物です。 私は、TZO (ココは有償)の基本サービスを使っています。 サブドメインのレンタルですが、オプションサービスを選べば、お名前.com の利用も可能です。 で、家のドメイン(笑)は、pine.mynetwork.org なのです。
それと、これは今更(笑)の補足なのですけど・・・、
最近 gTLD でのドメインを取得して設定しちゃう人とか居るみたいです。
そりゃドメイン名解決時のDNSの動きや普段使う分には違いは無いのですけど、 Dynamic DNS サービスの特徴であるA(MX)レコードの手軽な登録、更新機能を持つだけが Dynamic DNS サービスって事じゃ無い事も知っていて貰った方が良いみたいです。
例えば、TZOの場合だと、pine.mynetwork.org で引けるAレコードやMXレコードのTTLは大変短く30秒に設定されています。これは、仮にIPアドレスの変更が生じた場合、TZOへのアドレス更新を行えば、少なくとも30秒後には新しいIPアドレスが正しく引ける(筈、笑)事を意味しています。
Windowsの場合、Nslookup をデバッグモードで動かせば、このTTL値を知る事が出来るので何かしらのDNSサービスの利用を予定している人は、自分の接続環境や利用目的に照らして検討してみると良いです。 例えば、このTTLが短いサービスは頻繁にアドレスが変わっても登録、更新を確実に行えば間違ったアドレスを紹介するトラブルを防げますが、同時にDNSへの負荷も大きいので沢山の利用者を抱えていて対応能力が不十分だったりするとアドレス解決に時間が掛かる等の問題を起こす事に成ります。(2003/03/28)
ns4.tzo.com がコケたのー(笑)。
何だか他のNSと同期が取れていなくて、mynetwork.org のサブドメインの照会が出来ないみたい。 TZOでは他にも沢山貸し出せるドメインが在って全部を調べた訳じゃないのだけど、 ns4.tzo.comだけ全滅なんじゃないかと思う。 単純に止まっただけなら他に4台のDNSが稼動しているので別段支障ないのだけど 同期が取れずに正しいアドレスを紹介できない状態に成っている奴が混ざるのは非常に厄介(笑)。 北Ｑでは、dns100(210.146.3.25)の方が何故かns4.tzo.comと仲良しみたいで(笑)間違ったレコードを繰り返し引っ張ったまま困った事に成っている。dns101(210.146.3.26)の方は別のサーバから引くのか正常にアドレスを解決できている。TZOには打診したので明日までには直るじゃろう(笑)。 尚、結構長くTZO使って来て、この様なトラブルに気付いたのは今回初めてだったりする。(2003/04/07)
TZOオプションサービスレポート
このTZOのサービスですが一年間利用して来て契約の更新を迎えたので、今回、標準のサービスに 加えてオプション契約(この方が遥かに高い・・・$99.95)の Mail Store & Forward も結んで みました。
実は、TZOを使い出してからメールは自前のSMTPに転送して使っていたのです(笑。
標準機能だけでメール転送を利用する際のコツは、TZOのIPオプション設定でオフラインに成っても 自分の「IPアドレスをDNSに残す」を選んでおく事！です。無論、この設定では自分のIPアドレスが 何らかの理由(笑)で変わったりすると、アドレスの更新が行き渡るまで人の家のSMTPにメールが飛ん で行くなんて言う悲惨な事にも成るのですが、幸い私の所では固定IPの如く微動たりしない状況が続 いてくれたお陰で、心配するような事故は起きませんでした(汗。
逆に普通の設定のままで、TZOエージェントを止めたりリブートしたりすると、DNSのMXがTZO内部の SMTPを指すように書き換わります。これは普通に思えるけど、厄介なのは、このSMTPサーバが転送 されてきたメールを尽く跳ね返してくれる事です。確か・・・、「そんなユーザは知らん！」って 言って(笑。まぁ、お金払ってないのだから御尤もな話ではありますけどネ。
そんな具合で跳ね返されたメールが私のバヤイ2,3通・・・10通位かな・・・数十通かも(笑。 一部のpostmaster/ml管理者様には謹んでお詫び申し上げます(懲りない)。
と、まぁ、メール関連ではゴタゴタも在って、今一つ安心できないと言うか、一抹の不安を抱えていた 訳なのですが、今回、折角オプションとして用意されている機能なのだから試しに使ってみようかと 言う事で、Mail Store & Forward を試してみた次第です。でも、高いのよ $99.95。
まだ使い始めて数日(2001年7月某日)ですけど、契約時の問題とか、妙な所とか見え隠れしているので、 最近更新してないし、レポートでも上げておこうかと、
- 契約直後は超悲惨
オンラインで簡単に申し込めるのです。でも、直後に悲劇が(笑、
契約と同時に、DNSのMXレコードはTZOのメールゲートウェイを指すようになります。で、 このMXレコードはTZOのコントロールパネルからは書き換えができません。
一応、「全部のメールを一度TZOがインターセプトする」と説明に在るので、それに則した動きです。 MXの指すSMTPは、契約と同時に私のドメイン当てのメールを跳ね返す事無く受け取るように成りました (うんうん、良い事です)。
でも、でも、困った事に契約直後は、メールの転送設定が行われていないのです！。 無論、契約時点で転送先とか、転送先のSMTPポートとか、転送に必要な情報は与えてます。
当初は、TZOに溜まっていて、そのうち「転送されるだろう」と思っていたけど、この願いは叶いません でした。
普通、この手のサービスは「転送設定」->「MXレコード更新」の手順ですよねー？(笑。
- 一営業日で復活
実際の転送が開始されるまでに、私の場合一営業日でした。申し込み時の説明には1〜5営業日と 在りましたから、対応はまずまずなようです。
でも、MXレコードの更新が先行して、転送が後から付いて来る手順には困り者です。 契約後、数時間で気が付いて、私の場合、大元(笑)のメール転送を一時停止できたので被害は軽微 (数通・・・数十通かな)で済みましたけど、普通にドメインを運用している状態で、このサービスを 申し込むと、長いと5営業日間、メールがブラックアウトする事になります。
まぁ、メールなんて所詮、その程度ですから、と笑って過ごせないと厳しいかもネ、
- エンベロープの MAIL FORM: が何か変
メールの転送自体は遅延も無く順調で良いのですけど、一部のメールでエンベロープのアドレス MAIL FROM: が変な事に気付きました。まぁ、SMTPは、途中渡り歩くサーバ間で時折 変な奴に出くわす事が在る(そう言えば家のも変かも)のでTZOが変な奴なのか解らない のですけどね、どうも、転送時の MAIL FROM: への差出人アドレスをメール本文の From: から持って 来るみたいなのです。時折在る
From: hogehoge (漢字名) <hoge@ho.g.e>
なんて言うメールで From: 部分がフォールドされていると、何故かエンベロープの MAIL FROM: に、 宛先である RCPT TO: のメールアドレスが入って来るのです。メールの扱い上実害は無いのですけど、 我が家のSMTPは「ローカルメールがインターネットを通してやって来た」と言って統計情報を数え間違 えるのでした(笑。
- 容量制限は解らない
このサービスにはストア容量により5MByte/10MByteのサービスが在ります。この容量は自ホストが オフライン状態の時、TZOが一時保管してくれるメール容量の事なのですけど、この容量は自ホストが オンラインでの単純な転送時にも効いてくる物なのでしょうか？、
転送自体には別段容量制限など掛かっていないのではと思えるけど、若しかすると必ずストア、 アンド、フォワードされているのかもしれないし・・・、まぁ、私は2MByte超えるようなメールは、 届かなくても良いし、途中で消えて無くなってくれても結構な口なのですが、サービスの利用を考 えている方にとっては重要な仕様の一つかも知れませんね、
ならば、一つ協力しましょう(笑、TZOのこのサービスの利用を計画されていて事前調査をされたい方は、 3M/5M/7MByte の容量で我が家のAdmin宛てに試しにお送りください。運が良ければ届きます(笑。
- 止まる時もある(8/29 加筆)
日付忘れちまったけど、転送止まったトラブルが在りました。 正確にはTZOのメールサーバ(メールゲートウェイ)が落ちているようでした。
向うの深夜から業務開始時間辺りまで、延べ6時間位かな、 メールで問い合わせようとしたのだけど、送り先も同じサーバだったんだわ(笑、 なので、どうせ届かないし・・・、と思い回復するまで放って置いたので聞きそびれました。 何かのトラブルなのか計画されていたメンテナンスなのか解らないけど頻繁に起きるようだと 困ります。なんせ $99.95/年 もするメール転送サービスなんだからネ(笑。
- ポリシーが変わったの(2002/11/08 加筆)
TZOから「Mailサーバの(Mail Store & Forward サービスホスト)IPアドレスが変わるよー、フィルタしてたら注意してねん」とのメールが来ていたのだけど、どうやら、同時に転送ポリシーも変わったみたいです。
以前は、DNSのMXレコードを編集しても反映されずオンライン状態でも常にTZO経由でのメール転送が行われていたのですけど、今日、TZOホスト以外から沢山メールが到着するので調べてみたら、TZOのコントロールからMXレコードを設定していると、Preference 0(最優先、TZOのメールゲートウェイは100として入っている) として利用者の設定が反映されるように成っていました。これなら、このレポートで示した契約時の転送開始までのブラックアウト(実は、解約、失効時の挙動も心配だったのだけと、笑)も概ね防げるし、TZO側の転送負荷も減らせるし、遅延(普段は殆ど無し、良好だった)も無くせるし、で良いかもです。
一応、これでお終い。また気付いた事があれば加筆するです。
- H.323 Gateway (H.323の中継) Phone Patch
普通、VoIP(NetMeeting他ね)の利用にはグローバルIPが必須です。さらに、一つのアドレスを 複数の端末で共有して利用していたりすると音声通話に使えるマシンはグローバルIPを取得 している端末だけとなって不便な事になります。そんな不便を解消してくれます。
ハードウェアのNATルータなどを設置して使っていると利用が難しいかもしれないけど、 家みたいにTCP/IP中継をSOCKSや設定の柔軟なソフトウエアによるNATなどで行っている 場合は使えるのでは？、でも、有償よん(笑)、おまけに日本からはドル立てで割高・・・、 Open H323 Project から材料調達して自分で作るとか(笑)。
補足、以前見かけて、その後見失っていたintelで公開されているH.323のファイアウォール対策資料 のURLを見つけたのでリンクしておきます。でも、この資料を参考にして安価な最近のブロードバンド ルータでH.323を通そうとすると相当の大穴を空けないと難しそうです。
http://support.intel.com/support/videophone/trial21/h323_wpr.htm
↑これ、また消えたみたい(笑。なので、
http://support.intel.com/support/proshare/h323doc1.htm
ここを参考にリンクしときます。
- WinDump (http://netgroup-serv.polito.it/)
Unix系のマシンなら、TCPdump コマンドで簡単にネットワークパケットの様子を見れるのですが、 Windows系では、NT Serverを導入してネットワークモニターと大掛かりに成ってしまいます。 ここで配布しているキャプチャドライバとWinDumpを使うと、TCPdump と同じ事が Windows で 出来る様に成ります。
家では、ここで配布されるキャプチャドライバを使って、 こんな物 を作ってます。
こいつは C++Builder5 で作ってあります。最近はGUIが面倒に思えてきて、 aspで作ろうかな、とか思っていたりして(笑)、まぁ、完成する事のない当分先の話ですね
- 誤ヒットする検索キーワードを救済しましょ
ここを全面的に書き換えた結果、リンク先を消してしまって誤ヒットしているキーワードを少しばかり 救済する事にしました(笑)。
- BIND for NT (DNS Server)
NT4 利用時から北ＱネットのDNSが時折厳しくなるので、キャッシュ目的で named を動かしていました。 動かしていたのは BIND 4.9.7 のWin32版で、root cache を空にして北ＱとODNのDNSをforward先として ね、これからなら BIND 8.x系や 9.x系 を利用する事になると思います。
ISC(開発元)
http://www.isc.org/
ISCソースからビルドしたWin32版バイナリを配布している所
http://bind8nt.meiway.com/
ISCからもNT版バイナリが配布される事に成ったようです。
http://www.isc.org/products/BIND/bind8.html
- MRTG (Multi Router Traffic Grapher)
久しぶりに配布先を見てみたら日本のミラーサイトや日本語ページまで出来ていました。
http://ee-staff.ethz.ch/~oetiker/webtools/mrtg/ オリジナル
http://mirror.nucba.ac.jp/mrtgwww/ 日本のミラーサイト
http://www.ceres.dti.ne.jp/~riocat/webtools/mrtg/ 日本語
CPU冷却ファンの停止事故との遭遇を教訓に、システムの監視モニタを稼動させています。収集している情報の内、温度とSETI@homeの進捗を示すデータを公開！。(勿論、トラフィックも記録しているけどヒミチュ)
WindowsのSNMPから拾う事の出来ないCPU温度、ファン回転数等の情報は、MBM5 で利用されていたI/Oポートへの直接操作を可能にするドライバ(GIVEIO.SYS)を使って、独自のコマンドライン版プログラム MbmDump を作って収集しています(このプログラムを利用するには、MBM5をインストールして GIVEIO.SYS を利用可能な状態とし、MbmDump 付属の *.cfg を参考に、手持ちのシステムに合わせてデバイス情報を設定する必要があります。デバイスのI/OポートのアドレスやID、レジスタ情報は、MBM5 で出力される情報を参考にして、試行錯誤(笑)して下さい。また、現在対応しているチップセットはインテルのICHのみです。最新の板などでチップ互換が無い場合は、必要なコードを書くか、私に板を、乗っかるCPU付きで寄贈して頂ければ、対応できるかも知れません)。
このプログラムは、Windows利用時、MBM5 の様にデスクトップへの常駐が不要なので、サービスタスクからバックグランドでの利用など、普段ローカルログオンでのデスクトップユーザーが不在となるサーバ上での利用に便利です。
- [素句乱部留]解除
このページへの検索で一番誤ヒットしているキーワード(笑)。 誤ヒットに拍車を掛けていたようなので表記を・・・
でも、検索目的はどっちなのでしょうか、 使うため？、それとも、防ぐため？、気になるなー(笑)。
たぶん、年末に書き足した内容が原因なのでしょうね・・・、
ぐぅぁんばって他探してチョ！。
[その他、事件、事故、他局情報とか](今後、一番充実したりして、笑)
- スゴイこと、シンプルに宣伝しているチラシ(2002/03/20)
新カテゴリ[その他、事件、他局情報とか]作成の契機となったのは、スバラしいスキャナイメージ(笑。 まぁ、外注仕事の検収事故でしょうけど、
某掲示板には、「J-COMでは利用料金で著作権料を徴収済み」なんて書かれる楽しい事に成っています。 フラッシュで宣言されている通りに「スゴイこと、シンプルに」 やり遂げられた様で、・・・さて、公式な訂正や謝罪は行われるのかな？、
タイトル変えたです。(03/28)
- 今、修羅場です(2002/04/10)
どつぼにハマるとは、正にこの事でしょうね、「みずほ」。
今日はトランザクションが沢山沢山期待できる10日てすぅ。成果を祈って合掌。
NHKの例のドキュメンタリー、コピーは「史上最大のIT事故」、タイトルナレーションは、
金融業界に吹き荒れる不況、リストラ、処理の進まない不良債権、追い打ちする自由化、そして再編の嵐。 そんな中、生き残りを掛け、３行合併による巨大銀行が誕生した。
が、その裏では、各行で独自に開発、運用されてきたオンラインシステムを統合する 大仕事が待ち構えていた。余りにも短い時間での調査、分析。金融業としての信頼を担うシステムを、 営業を休止する事無く、顧客へのサービスを維持したまま、統合する。
そんな、前代未聞の困難な仕事に身を投じた者達がいた。挑戦者達。
「時間は無くオーダーは厳しい・・・、誰もが旨い方法だと思っていた・・・、そして、コケた」
ってな具合で如何でしょうか、偶には失敗を題材にするのも良いかと、
- 禁じ手−１ISPが勝手にメール削除(2002/07/29)
ニュースにも取り上げられ話題と成ったISPによるウィルス配布事故(7月16日発生かな？)。
そこは、CATVでのネットワークサービスを提供していて、この北区からも 直ぐ近く(笑)、事業の規模、利用者数も北Ｑと同じ位の、まぁ、地域密着の小規模ISPなのですけど、 事の発端は、ネットワーク利用者への同報メール発信に使われるアカウント(alluserだったかな) の管理に不備が有って、これをウィルスが宛先に使ってメール発信してしまった。って事なのです。 過去に使われた経緯があれば、残っていたメールやアドレス帳から、それをウィルスが勝手に引っ 張り出して利用するのは予想される事、制限を設けずに利用を許す設定で放置してしていたのが原因 な訳です。実際の発信がISP事業者内から行われたのか、或いは、外部(利用者)から行われたのかは 定かではないですが、実際の所、発信元なんか如何でも良くて、「ISPからウィルス配布」なんて事で 騒ぎに成ったのです。ところが、この後の顛末の方が私には重大問題に思えるので記録せねばと(笑)、
この騒ぎを起こしたISP、なんと、なんと、利用者のメールボックスに配信され保存されていた 件のウィルスメールを利用者への通知も無しに勝手に削除したらしいのです。 思うに、最低でも利用者各々の承諾、私的には利用者からの要請と明確な委任 が在って初めてISPが手を下せる領域(実際は、それでも手を出さない所が大半だと思う)で在って 欲しいと思うのですが、余程の「緊急事態」として処置されたのでしょうか？。 地域密着で小回りが効き顔が見えるISPのディープなサービスの一環だとしても、私は要らないです(笑)。
- 禁じ手−２発呼フラッド(2002/07/29)
大阪で、7月15日に続き、また、規模の大きい電話の通話障害が発生したそうです。 何でも、先の障害原因とされる同じ「ワン切り」業者からの多量の発呼が原因とか、 いゃー、電話網もIPネットワークに負けず脆弱ですねー(汗)、
ワン切りにより多量に発生する未完了呼が交換機への負荷となり障害を引き起こす 様は、不完了のプロトコルでリソースを圧迫するSYNフラッドに通じるような、 でも、途中の交換機(ネットワーク)を落とすんだから帯域消費型のDoSかな？、
NTTも対策するようですけど、さて、どんな事に成るのでしょうか、 閾値を超える発呼が在ったら「全部課金」なんて事にすれば迷惑なワン切り無くなるかな？(笑)。
- J-COMがP2P規制なの(2002/11/03)
勢い良く食べまくり、業界リーダ最大手MSOのJ-COMさん。 一時、北Ｑがトラブル続きの際には、J-COM傘下への参入を願う声まで飛び出す人気だったのですが、不具合の収束、その後の増速で北Ｑが示した成果(笑)なのか、その様な声も消えて久しい頃、当のJ-COMさんでは、どうも速度低下が大きく騒がれ元気が削がれていた様子。伝え聞く所では速度低下の原因は「P2Pのファイル交換だ」との噂が流れていたのだけれど、この度、正式に速度低下、サービス品質改善に向けての方針が表明されたようです。で、やっぱり、
調査の結果、わたくしどもはこの原因を、ある特定のお客様が、大量且つ長時間に渡るデータ送受信を行っておられる為、他のお客様の通信環境を圧迫しているものと考察しております。まぁ、P2Pファイル交換の名指しでの表現は無いのだけど、他の利用者の迷惑と成る様な著しく(常軌を逸する？、笑)大きなトラフィックは、帯域を制限しますよー、との事の様です。これは、モデムの先が即共有回線で同一ノード内の帯域需要が即、他の同一ノード利用者の品質に影響してしまうCATVの抱えるハンデを埋める苦肉の策なのでしょうか？、当然、幾つかの掲示板では、この姿勢の是非を巡ってヒステリックな論争に成ったりしています。実際に影響を受けるのは、全体から見れば極々僅か(笑)な利用者に留まり、引き換えに大多数の利用者が快適な環境を取り戻せれば良いのですけど、果たして期待される結果が待っているかな？、試行、調整して年内には結果が出るかも〜、と言った具合の様です。
この様な大量且つ長時間に渡るデータ送受信は弊社約款中の（利用に係る契約者の義務）中の項、
「契約者は、インターネット接続サービスを直接又は間接に利用する者 の当該利用に対し重大な支障を与える行為を行わないこととします。」
という禁止事項に反するものと考え、より多くのお客様に快適なインターネット接続環境をご提供する為に、本速度低下現象に対する対策案を実サービス環境において試行させていただくことにいたしました。
つづく(たぶん)
