1 IPアドレスのバッティング→旧機器のIPアドレスと新機器のIPアドレスを設定しますが、
IPアドレスがバッティングした状態でインターフェイスを開放すると、通信ができなくなります。
対策→IPアドレス管理表などで、IPアドレスの管理を徹底する。
2 対象機器の間違い
事故の件数としては、1番多いケースと言われています。
機器にtelnetやSSHでアクセスする時や、物理作業で、機器Aの作業をしないといけないのに、機器Bの作業をしてしまい事故に繋がるケースです。当方も作業手順書で、telnetのIPアドレスの第4オクテットを１つ間違えて記載し、大事故に繋がりかけた事があります。また物理作業では、機器Aのケーブルを抜かないといけないのに、機器Bのケーブルを抜くってケースが多いです。また、電源ケーブルを挿したつもりが、しっかり挿さっていなかったケースもあります。
対策→ホスト名や機器にアクセスする時のIPアドレスを徹底。指差し呼称の徹底(昔の現場では指差し呼称を必ずしなければならないルールがありました。)
3 ループ
RSTPを有効にしても、ネットワーク構成やケーブル配線ミス、設定ミスで簡単にループします。
対策→ネットワーク構成やケーブル配線表などの確認を徹底。
4 ACLの設定ミス
実際にあったケースですが、東京と大阪でリモート作業を実施していましたが、ACLの設定ミスで、機器にアクセスできなくなりました。2号機からアクセスできたので、事なきを得ましたが、2号機からもアクセスできなかった場合、東京から大阪へダッシュする必要がありました。
対策→ACLの確認や通信要件の確認など。
5 設定の投入ミス(省略コマンドの禁止、右クリックの禁止)
昔の現場で、show run をsh run って省略するのは禁止されていました。実際にshって打って、shutdownコマンドが入ってしまったケースがあるそうです。
また、tera termで右クリックで設定投入する人を、今まで何人も見たことありますが、コマンドが暴発する可能性があるので、右クリック禁止の設定をいれる。
6 既存管理資料に誤植が含まれている可能性
既存管理資料を信じて新機器コンフィグを作成したが、資料に誤植が多数含まれてるケース。当方も、顧客作成した資料の構成図が間違っていたことや、
最近では、検証構成図が間違っており、それが業務の遅延に繋がりました。
対策→既存の資料ではなく、必ずステータス確認を徹底する。
7 移行の途中段階で旧・新機器が混在する状況がある場合のルーティング不具合
→意図しない再帰ルートの発生など
