久々に面白い動画を見つけました。シリーズものなので直接YouTubeから検索したほうが早いのですが、ファミコン時代のゲームを嫁にやらせてみた(コメント音声つき)な感じのシリーズです。しかも選ぶゲームがスペランカーとかまたマニアックな…。
コメント音声つきといえばちょっと前にバイオハザードでわざと大げさに騒ぐものがあったがあれは最初バカだなぁと楽しみましたが2個目以降は飽きてしまった。でもこっちはゲーム素人にいきなりやらせる感覚で素でコメントしているので面白かった。ゲームもそこそこバリエーションが多く楽しめます。(これだけ古いゲーム集めている旦那もスゲーと思う)
NTTより15日に発生したネットワーク障害の最終報告がありました。多分今回のようなケースはNTTでも初めてなんじゃないかな。というか実際に再現するテスト環境なんてコスト的に無理だから机上のリスク計算しかできないと思う。
私のような末端はVPNやプライベートLANのルーティング設定してそれ以外は精々数本のグローバル回線にルーティング情報を張るぐらいだから手作業で済みますが、主要回線はピアtoピアで沢山のルーターが相互に物理的な接続をしているし、常にルーティング情報は変わるから自動じゃないとやってられないと思います。
DNSと違ってルーティング情報は直ぐに書き換えを行う仕様みたいなので、タイミング悪くトラフィックの多いときにやってしまったようですね。(DNSのキャッシュもサーバの増減時に強制的に消し去りたいと思うこともありますが…)
NTTでは障害の連鎖に対しどのようなソフトウェア対策を行われていたか記事からは分かりませんが、実際に障害を起こしたのは古いソフトウェアで動作しているルータということでルーティング情報の書き換え連鎖を防ぐ処理が無かった為のようです。
通信事業者としての現在の立場を考えると今回の障害は多くから非難も発生すると思いますが、ネットワーク障害について速やかに技術的な報告をする姿勢は評価したいです。
このニュース記事見た一部ISPがルータ総点検するきっかけになれば、他社による同じ過ちの再発を未然に防止できるのではないかなっと思います。
3秒で2000ルータがダウン、NTT東フレッツ障害の原因は － ＠IT
http://www.atmarkit.co.jp/news/200705/16/ntt.html
BGPの仕組みと役割を理解する
http://www.atmarkit.co.jp/fnetwork/rensai/iprt02/iprt01.html
「フレッツサービス」および「ひかり電話」をご利用できない状況について（最終報）
http://www.ntt-east.co.jp/release/0705/070516b.html
別紙１ 時系列
http://www.ntt-east.co.jp/release/0705/070516b_1.html
別紙２ 発生のメカニズム
http://www.ntt-east.co.jp/release/0705/070516b_2.html
設計や実装を行うに当たって１人プロジェクトだとついつい省略しまいがちなドキュメント。今後開発が大きくなったときや外部に委託する可能性を考えたらドキュメントはしっかりつくって置いたほうがいい。
それで設計内容を書き出すくらいであれば白紙に好きなように書いて終わりだが、やっぱり体裁よくしたい。しかもその体裁の為に結構時間を割いたり、体裁自体が更新しているようじゃ管理が増えるばかり…。なにかいいテンプレないかなーとググってたらエクセル形式のテンプレを配布しているページを発見！ 以外にも開発ドキュメントってWordやPDFではなくエクセルで方眼紙のような使い方(多分日本独自の文化かもしれん)をしている事が多くて、エクセル形式であれば外部に電子ドキュメントのまま渡すにもトラブルは少ないかな。(私個人的にはエクセルで書くと更新に手間がかかるのがイヤなのですが業界標準に合わせるしかないですよね)
[ThinkIT] 第1回：開発ドキュメント体系と業務フロー (1-4)
http://www.thinkit.co.jp/free/project/4/1/1.html
とりあえず、ログの公開。
> grep 07/05/2007 ipf.log | grep -c ",25"
1
> grep 08/05/2007 ipf.log | grep -c ",25"
2385
> grep 09/05/2007 ipf.log | grep -c ",25"
4479
> grep 10/05/2007 ipf.log | grep -c ",25"
3268
> grep 11/05/2007 ipf.log | grep -c ",25"
1257
> grep 12/05/2007 ipf.log | grep -c ",25"
1605
> grep 13/05/2007 ipf.log | grep -c ",25"
1565
ちなみに8日は途中からFW入れたのでアタックされた数字はもっと上。発生は8日の8時台だからというのもあるかな。先週に比べ少し減ったけどこれじゃまだまだヤバいかなー。
作戦として一旦FWをpassにして相手側のキューを消化してみようかな。その後まだ来ていれば新たに発生しているということで…。
あらあら踏み台にされちゃったのね。踏み台の上にエラーが戻ってくるということはドメイン詐称無しなのかな。
http://headlines.yahoo.co.jp/hl?a=20070511-00000124-mai-soci
こっちに来るDDosは一向に収まらない。SPFが聞いてないのかなー。25番止めたままなのでFWログ増大中。
