ネットワークは，あらゆるITリソースの共通インフラである。にもかかわらず，そのネットワークの管理は基幹業務サーバーなどに比べてあまり重視されていないケースが多い。実は，この管理不足がネットワーク停止を招くことが少なくない。そこで今回は，ネットワーク管理情報の共有不備が引き起こすトラブルの影響範囲を最小限に抑えるために，共有すべきネットワーク管理情報（ルール，設計情報など）がどのようなものなのかについて考えていきたい。
勝手なスイッチ増設がネットワーク・ダウンを招いた
A社は稼働中のデータセンター内のLANで，スイッチを増設した。業務サーバーのテスト機を接続する際にサーバー集約スイッチのポート数が不足したためだ。この際，不用意に余剰品のスイッチを接続したところ，ネットワークが停止してしまった（図1）。
追加したスイッチは誰がいつどのような設定で利用していたかがわからないものだった。このため当然の措置として，ホスト名，IPアドレス，デフォルト・ゲートウエイなどの基本的な設定を修正し，ネットワークに接続した。ところが，予期せずネットワークがダウン。調べてみると，原因はスパニング・ツリー・プロトコルの設定だった。
追加したスイッチのブリッジ・プライオリティが，このSTPドメインのルート・ブリッジよりも高く，STPのトポロジー変更を誘発した。トポロジー変更が収束するまでの間，1分程度のネットワーク停止が発生。たった1分と思うかもしれないが，1分の停止時間があると，一般的なレガシー・システムの通信はもとよりWebベースのシステムもタイムアウトが発生する。
A社の場合，基幹業務端末（レガシー・システム）の一部が，システムがタイムアウトすると端末自体が停止し，再起動を必要とする仕組みになっていた。このことが，業務に大きな影響をもたらした。端末を1台ずつ再起動しなければならず，すべての業務が復旧するまでに1時間以上を要したのである。
影響範囲が大きかったためネットワーク・エンジニアが後から切り分けを行ない，スイッチのログを確認したところ，STPトポロジー変更が起きていたことが分かった。状況ヒアリングの結果，STPトポロジー変更が起きた時間帯にスイッチを追加していたことが判明。当該スイッチのSTP状態を調べるとルート・ブリッジになっていたため，原因がはっきりした。
このトラブルは，スイッチをサーバーと同じ感覚で既存環境に増設したために起きたトラブルと言える。サーバーなら1台増設しただけでは周囲のシステムへの影響は少ないが，ネットワーク機器は事情が違う。特にSTPを使用している環境では，スイッチを安易に接続するのは危険である。このトラブル事例のようにブリッジ・プライオリティが同一STPドメイン内の既設スイッチよりも高い場合には，トポロジー変更が発生し，トポロジーが収束するまで当該STPドメイン内全体の通信が停止してしまう可能性があるからである。RSTPを使えば収束するまでの時間を短縮できるが，ネットワークの安定運用を考えるとルート・ブリッジが切り替わってしまう事態は避けたい。
このようなトラブルを未然に防ぐには，スイッチを追加接続する前にSTPにかかわる最も重要なパラメータであるプライオリティ値についてのルールをあらかじめ決めて文書化し，それを関係者に周知することが少なくとも必要である。例えば，
・優先的にルート・ブリッジにしたいスイッチにはあらかじめ最も高い優先度となる値“0”を割り当てる
・第二にルート・ブリッジにしたいスイッチには4096を割り当てる
・スイッチを接続する前には，デフォルト値から設定変更したか否かにかかわらず，必ずブリッジ・プライオリティ値を確認する
というような標準ルールを設けておくと，人為ミスを含め，このようなトラブルの多くは未然に防げるはずである（IEEE 802.1D-2004ではブリッジ・プライオリティのデフォルト値または推奨値として「32768」という値が規定されている）。
なお，A社のケースでは正常なSTPトポロジー変更が発生しても大きな業務影響が出る。これを防ぐにはネットワーク側の冗長化機能の切り替わりタイマー値とシステム側のタイマー値の整合性を取ることが重要である。具体的に言うと，
“レイヤー1の経路切り替わり時間”（バックアップ・ポート機能）
“レイヤー2の経路切り替わり時間”（STP/RSTP）
“レイヤー3の経路切り替わり時間”（OSPF）
・
・
・
“サーバー・クラスタリングの現待装置切り替わり時間”
“アプリケーションのタイムアウト・タイマー値”
という具合に，低いレイヤーの系切り替わり時間が高いレイヤーの動作に悪影響を与えないように設計しておく。システム全体の信頼性・運用性を最適化していくためには，ネットワーク側だけで考えても，サーバー/アプリケーション側だけで考えても十分とは言えない。
