ネットワークの切り分け時は装置の設定を再確認することが肝要である。基本設定のまま運用すると思わぬトラブルが発生する。切り分け時に通信断となった事例を紹介する。

 通信の継続性やセキュリティー強化のためネットワークを切り分けるケースがある。切り分けの際、ネットワーク装置の設定を熟考しなければ予期せぬトラブルが発生してしまう。今回はネットワークの切り分け時に発生した2つのトラブル事例を取り上げ、解決に至るまでの過程を紹介する。

事例1
切れないはずが通信断に

 A社は通信の継続性を考え、基幹系通信と情報系通信の2網でWANを組んだ。両方の回線をアクティブで運用し、片方に障害が発生した場合はもう一方でバックアップする計画を立てた。2網がアクティブな状態で業務ごとに通信経路を変える場合は、パケットのルーティングに注意しなければならない。送信先だけでなく送信元のアドレスを参照することがあるためだ。

 A社は基幹サーバーとファイルサーバーを同じデータセンターに配置し、各拠点の端末で受発注業務をしていた。各拠点からデータセンターへの通信は、サーバーのアドレスごとにWAN1とWAN2のどちらかに経路を分けられる。

 一方、基幹サーバーから拠点宛に通信する際は、宛先端末のIPアドレスが同一なのでWAN1またはWAN2のどちらかに通信が偏ってしまうことがある。これを回避するには、送信元のIPアドレスを参照してルーティングしなければならない。

 そこでA社はエンド・ツー・エンドの通信要件を洗い出し、送信元アドレスやプロトコル、ポート番号、パケットサイズなどを基にルーターで経路を分ける「ポリシーベースルーティング」によって、データセンターから拠点までの通信を基幹系と情報系に分類した。障害発生時にバックアップするため、監視パケットで回線やルーターの死活状況を監視するセッション監視機能を使用した。

図 A社のネットワーク構成
通信の継続性を考えて2網でWANを構成した
[画像のクリックで拡大表示]

 ある日、拠点Aの情報系回線が数分間切れる障害が発生した。設計通りであれば、セッション監視機能によってWAN2の障害を検知。経路をWAN1に切り替え、全社の通信に影響が及ばないはずであった。

 しかし、情報系と基幹系の両方の通信が一時切断してしまった。調査すると、WAN2の回線障害が発生した同時刻にWAN1のセッション監視機能がダウンしていた。担当者が真っ先に疑ったのは、WAN1の回線障害だった。2つの回線で同時に障害が発生しても不思議ではない。しかし、回線を調査しても問題は見つからなかった。

戻りパケットの経路を考慮する

 調査を進めるうちに原因が判明した。データセンターの基幹系ルーターで実施しているポリシーベースルーティングの設定が問題だった。拠点Aの基幹系ルーターが送信したセッション監視パケットへの応答が情報系ルーターに流れていたのである。

 監視パケットの応答がないので、拠点Aの基幹系ルーターはWAN1に障害が発生したと判断し、パケットを情報系ルーターに迂回。結局、情報系回線のWAN2で発生した障害によって基幹系通信も切断していた。

図 A社で発生したトラブルの概要
戻りパケットの経路に対する配慮が欠け、通信断が発生した
[画像のクリックで拡大表示]

 担当者はトラブルが発生するまで監視パケットが迂回していると考えていなかった。調べると通常時も監視パケットが情報系回線に迂回していた。通信可能だったため、担当者は正常に動作していると思い込んでいた。

 トラブルはデータセンターにある基幹系ルーターのポリシーベースルーティングの設定を変更し解決した。宛先のネットワークだけを参照する通常のルーティングとは異なる方式を利用する場合は、戻りパケットの経路まで考慮しなければならない。正常に通信できていたとしても、行きと戻りで別経路を通っていることがあるからだ。

この先は有料会員の登録が必要です。「日経コンピュータ」定期購読者もログインしてお読みいただけます。今なら有料会員(月額プラン)が12月末まで無料!

日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら