PR

大規模L2ネットワークでVRRPグループ(VRID)のバッティングによりネットワークがダウン

 次に,ビル全体を1セグメントとする大規模L2ネットワークを運用しているB社の例を挙げよう。あるとき同社では,システム運用のベンダーを社内に常駐させることにした。常駐用の部屋を設け,そこからシステムを監視・遠隔操作できるように,新たなLANセグメントを構築。B社のLANとは2重化したファイアウォールを介して接続した。

 ところが,ファイアウォールを追加した直後から,エンドユーザーがWANの先にあるデータセンターの共有ディスクに全くアクセスできなくなった(図2)。原因は,VRRPのグループを規定するVRIDが,ファイアウォールと既存ルーターとでバッティングしたこと。これにより通信が阻害された。

図2●大規模L2ネットワークでVRRPグループ(VRID)のバッティングによりネットワークがダウン
図2●大規模L2ネットワークでVRRPグループ(VRID)のバッティングによりネットワークがダウン
[画像のクリックで拡大表示]

 ユーザーから「共有ディスクにアクセスできない」という申告があったときは,最初にWAN障害を疑った。ネットワーク・エンジニアが回線とルーターを調査したところ,2台のルーターのVRRPステータスがともにマスターではなくバックアップになっていた。さらに,ルーター以外のIPアドレスを持っている装置がマスターになっていることが分かった。

 調べてみると,問題の装置は新規に導入したファイアウォールだった。ファイアウォールの設定情報を確認すると,VRIDがルーターのものと重複していることが判明。このため,ルーター経由でデータセンターへ向かうべきパケットが,VRRPマスターになったファイアウォールに吸い込まれたのだと分かった。最終的には,ルーターとファイアウォールとでVRIDを異なる値にすることで対処した。

 このトラブルの根本原因は,ルーターを導入したシステム管理者とファイアウォールを導入するシステム管理者が異なっていたために,VRRPのVRIDやプライオリティといった,VRRPに関する設計ルールがうまく共有されなかったことである。

 VRRPの仕様が記されているRFC 3768には,プライオリティのデフォルト値は100と規定されているものの,VRIDのデフォルト値は特に規定されていない。導入時に管理者が値を決めて設定する必要があるが,B社の場合は,意図なく設定すると割り当ててしまいそうな値(1)が設定されていた。そもそもL2ドメインが広大すぎて,多種多用な機器が同一LANセグメントに接続され,VRIDがバッティングしやすい環境にあったことも原因の一つと言える。

 VRRPでは,バーチャル・ルーターのIPアドレスが異なっていてもVRIDが同一であれば相互にネゴシエーションする。2重化のために設置した装置の両方がバックアップ・ルーターになってしまう可能性がある。このほか,ベンダー独自の機器冗長化プロトコルの中にはVRRPをベースとして作られているものがあり,標準のVRRPを動作させている機器とネゴシエーションしてしまうことがあるので,注意が必要である。

 このようなトラブルを未然に防ぐには,

・ルーター相互に影響を与えるVRIDとVRRPプライオリティの値をLANセグメントごとに管理すること
・VRIDのバッティングが起こらないようVRIDの割り当て方を決めておくこと
・VRRPプライオリティの割り当てルールを決めておくこと

といったルールを標準化し,上記のSTPの場合と同様にこれらの内容を文書化し,関係者に周知する必要がある。

 ネットワーク・トラブル発生の可能性や影響範囲を限定するためには,LANセグメントをあまり広大にはせず,たとえば少なくともフロア単位ではサブネット分割しておくことを推奨したい。B社はパソコンのIPアドレス/ゲートウエイ設定・管理を簡略化するためにビル全体を一つのLANセグメントにした。ただ,それならDHCP(dynamic host confguration protocol)とMACアドレス認証を併用するなど別の手段を使うことが望ましい。