前回、年金の記事で入力ミスや操作ミスの話をしましたが、ネットワークやサーバの設定の際もこのような人為的ミスはつきものです。
時には些細なミスが大きなトラブルに繋がる事も。
実は私も設定ミスで大きな障害を起こしてしまった事が過去にあります。
しかもそれが経験した中で一番大きなトラブルとなりました。
間違った設定をしてしまったのはＦＷ（ファイアウォール）のルール設定。
とある通信を遮断する設定をしていたのですが、指示書の読み間違いで遮断する必要の無い正常な通信を遮断してしまいました。
それが運悪く業務への影響が大きい通信で、素早く復旧はさせたものの始末書を書く事に・・・orz
（実際に設定ミスをしたのは私ではなく設定をお願いしていた派遣社員さんだったのですが、結果責任はありますので＾＾；）
その時にミスの原因と対策を色々と考えた訳ですが、最も効果がありすぐに導入できた対策がダブルチェック。
設定後、最後の設定反映前に必ず私がチェックするようにしました。
今考えればして当たり前の事なんですが、私が入社する前から日常的にに行なわれていた作業だった事もあり、トラブルが起きる前はこの作業でダブルチェックをしようと思った事はありませんでした。
私自身、気の緩みと責任意識の欠如があったのでしょう。
なお、ダブルチェックを導入した大きな理由に現状の把握という目的もありました。
実際に現場に触れてみないと分からない事も沢山ありますからね。
特に運用のようにルーチン化された業務は外からでは実態が分からないものです。
最近しばしば耳にする不祥事や事故のニュース。
決して他人事ではありません。
時には些細なミスが大きなトラブルに繋がる事も。
実は私も設定ミスで大きな障害を起こしてしまった事が過去にあります。
しかもそれが経験した中で一番大きなトラブルとなりました。
間違った設定をしてしまったのはＦＷ（ファイアウォール）のルール設定。
とある通信を遮断する設定をしていたのですが、指示書の読み間違いで遮断する必要の無い正常な通信を遮断してしまいました。
それが運悪く業務への影響が大きい通信で、素早く復旧はさせたものの始末書を書く事に・・・orz
（実際に設定ミスをしたのは私ではなく設定をお願いしていた派遣社員さんだったのですが、結果責任はありますので＾＾；）
その時にミスの原因と対策を色々と考えた訳ですが、最も効果がありすぐに導入できた対策がダブルチェック。
設定後、最後の設定反映前に必ず私がチェックするようにしました。
今考えればして当たり前の事なんですが、私が入社する前から日常的にに行なわれていた作業だった事もあり、トラブルが起きる前はこの作業でダブルチェックをしようと思った事はありませんでした。
私自身、気の緩みと責任意識の欠如があったのでしょう。
なお、ダブルチェックを導入した大きな理由に現状の把握という目的もありました。
実際に現場に触れてみないと分からない事も沢山ありますからね。
特に運用のようにルーチン化された業務は外からでは実態が分からないものです。
最近しばしば耳にする不祥事や事故のニュース。
決して他人事ではありません。
前回の続き。
バグがあったのは１台ウン十万もするＬ２ＳＷ。
どんなバグかというと、
”ポートに一定以上のトラフィックが流れ込むとスパーニングツリーが動作しなくなる”
というもの。
スパツリーが動作しなくなるわけですので、二重化をしているとループが発生します。
ループが発生すれば、、当然大トラブルです。
私が管理していたネットワークでそのバグが発動したのは、丁度有給を取った日＾＾；
朝起きてぼけーっとしてたら電話で突然呼び出されたのを覚えています。
バグを発動したトラフィックの送信元は皮肉にもウィルス感染したＰＣ。
世界的にもウィルスが大量発生した時期だったので、呼び出しの電話では、ウィルスの大量発生によるネットワークのダウンという話でした。
しかし、いざ会社に来てみてＭＲＴＧやログを確認すると、なぜかバックアップのポートにも
トラフィックが大量に流れているしスパツリーのエラーが吐かれまくっている状態。
そこで試しにバックアップ系のポートを閉塞してみると、、見る見るうちにトラブルは収束するじゃありませんか＾＾；
大変だったのはこの後。
上への説明から関係各所への謝罪。
一方では、ベンダーを呼んでなぜループが発生したのかの解明。
バグが分かったら分かったで、問題のあるＳＷのＯＳを全て入れ替え。
ＯＳの入れ替えといっても対象ＳＷが数十台もありましたから、休日を２日使ってやっとの状況でした。
もう二度とあんな経験はしたくありませんね。
以上長くなってしまいましたが、これが私が実際に経験したバグが原因のネットワークトラブルの話です。
このようなトラブルを回避するいい方法があればいいのですが、導入前のリサーチと導入時のテストをしっかりする、
といった基本的な事しか思い浮かびません。
一方でこれだけ技術の進歩が早く且つ低価格化している現状を考えると、、ネットワークエンジニアや管理者の苦悩は増すばかりです・・・orz
バグがあったのは１台ウン十万もするＬ２ＳＷ。
どんなバグかというと、
”ポートに一定以上のトラフィックが流れ込むとスパーニングツリーが動作しなくなる”
というもの。
スパツリーが動作しなくなるわけですので、二重化をしているとループが発生します。
ループが発生すれば、、当然大トラブルです。
私が管理していたネットワークでそのバグが発動したのは、丁度有給を取った日＾＾；
朝起きてぼけーっとしてたら電話で突然呼び出されたのを覚えています。
バグを発動したトラフィックの送信元は皮肉にもウィルス感染したＰＣ。
世界的にもウィルスが大量発生した時期だったので、呼び出しの電話では、ウィルスの大量発生によるネットワークのダウンという話でした。
しかし、いざ会社に来てみてＭＲＴＧやログを確認すると、なぜかバックアップのポートにも
トラフィックが大量に流れているしスパツリーのエラーが吐かれまくっている状態。
そこで試しにバックアップ系のポートを閉塞してみると、、見る見るうちにトラブルは収束するじゃありませんか＾＾；
大変だったのはこの後。
上への説明から関係各所への謝罪。
一方では、ベンダーを呼んでなぜループが発生したのかの解明。
バグが分かったら分かったで、問題のあるＳＷのＯＳを全て入れ替え。
ＯＳの入れ替えといっても対象ＳＷが数十台もありましたから、休日を２日使ってやっとの状況でした。
もう二度とあんな経験はしたくありませんね。
以上長くなってしまいましたが、これが私が実際に経験したバグが原因のネットワークトラブルの話です。
このようなトラブルを回避するいい方法があればいいのですが、導入前のリサーチと導入時のテストをしっかりする、
といった基本的な事しか思い浮かびません。
一方でこれだけ技術の進歩が早く且つ低価格化している現状を考えると、、ネットワークエンジニアや管理者の苦悩は増すばかりです・・・orz
ネットワークトラブルの中でも被害が大きくなりやすいのが、ネットワークの経路を決めている
ルーティングプロトコル関連のトラブルです。
今日は実際に経験したＯＳＰＦ関連のトラブルをいくつか書きます。
ルーティングプロトコルにＯＳＰＦを利用されている管理者の方は、ぜひご参考に＾＾
１：DR(Designated Router)の設計に伴うトラブル
一部セグメントの撤収に伴いルータをシャットダウンしたところ、関係の無いセグメント
の通信が出来なくなるというトラブル。
原因はシャットダウンしたルータを繋いでいたインターフェースがＤＲになっており
DRの切替が発生、一部テーブルが消えた為。
恥ずかしい話ですが、このトラブルが発生するまで私も外部のネットワークベンダー
の担当者(CCIE保有）もDRを意識する事がありませんでした^^;
以降、DRの確認は怠らないようにし、DRはプライオリティ設定で最も信頼できる
ルータ(L3SW)とI/F(VLAN)になるよう設定するようにしました。
２．テーブルの肥大化に伴うトラブル
日々のサブネット追加によりルーティングテーブルが肥大化。
ルータのメモリリソースを食い潰しルータが停止（Cisco2514がリブートを繰り返す
ような状況になりました＾＾；）したというトラブル。
結局、サマライズやデフォルトルートの活用などで対応。
これは、サブネットやエリアの設計がきちんと出来ておらず、テーブルが
肥大化してしまった事が要因。リソース管理も甘かった。
基本設計は前任者ですが、問題を認識していながら対処を遅らせていたしていなかった
自分のミスですね＾＾；
３．導入段階のトラブル
設定の間違えでルーティングが流れない。サブネットが重なっていた。。などなど
とりあえず、思い出に残っているトラブルは以上。
その他、実際に経験したトラブルではありませんが、
「過去の設定が残った遊休機を繋いでルーティングを乱してしまった」
と言ったトラブルもあるんじゃないでしょうか。
gatedを動していたサーバがあってもおかしくありませんからね＾＾；
ルーティングプロトコル関連のトラブルです。
今日は実際に経験したＯＳＰＦ関連のトラブルをいくつか書きます。
ルーティングプロトコルにＯＳＰＦを利用されている管理者の方は、ぜひご参考に＾＾
１：DR(Designated Router)の設計に伴うトラブル
一部セグメントの撤収に伴いルータをシャットダウンしたところ、関係の無いセグメント
の通信が出来なくなるというトラブル。
原因はシャットダウンしたルータを繋いでいたインターフェースがＤＲになっており
DRの切替が発生、一部テーブルが消えた為。
恥ずかしい話ですが、このトラブルが発生するまで私も外部のネットワークベンダー
の担当者(CCIE保有）もDRを意識する事がありませんでした^^;
以降、DRの確認は怠らないようにし、DRはプライオリティ設定で最も信頼できる
ルータ(L3SW)とI/F(VLAN)になるよう設定するようにしました。
２．テーブルの肥大化に伴うトラブル
日々のサブネット追加によりルーティングテーブルが肥大化。
ルータのメモリリソースを食い潰しルータが停止（Cisco2514がリブートを繰り返す
ような状況になりました＾＾；）したというトラブル。
結局、サマライズやデフォルトルートの活用などで対応。
これは、サブネットやエリアの設計がきちんと出来ておらず、テーブルが
肥大化してしまった事が要因。リソース管理も甘かった。
基本設計は前任者ですが、問題を認識していながら対処を遅らせていたしていなかった
自分のミスですね＾＾；
３．導入段階のトラブル
設定の間違えでルーティングが流れない。サブネットが重なっていた。。などなど
とりあえず、思い出に残っているトラブルは以上。
その他、実際に経験したトラブルではありませんが、
「過去の設定が残った遊休機を繋いでルーティングを乱してしまった」
と言ったトラブルもあるんじゃないでしょうか。
gatedを動していたサーバがあってもおかしくありませんからね＾＾；
