PR

 WANをまたいで拠点間を接続している場合,パケットのフラグメンテーションが原因でトラブルに陥ることがある。通信経路上でMTU(maximum transmission unit)サイズが小さい部分があるケースだ。具体的には,広域イーサネット・サービスを利用している場合や,暗号化技術を使ってVPN(仮想的な専用線)接続している場合である。

 MTUサイズはデータ・パケットを送信する際に許容される最大パケット長で,イーサネットでは1518バイトというように物理媒体によってそれぞれ値が決まっている。問題はWANにデータを送出する際にカプセル化などによってパケット長がMTUサイズを超えてしまうケースがあることだ。パケット長がMTUサイズを超えている場合,ルーターなどが自動的にパケットを細分化(フラグメント)して送信することがある。この場合,フラグメント処理,受信側での再組み立て処理が発生し,パフォーマンスが劣化しやすい(図1)。

図1●送信パケットがMTUサイズを超えると性能劣化を招きやすい<br>送信側でのフラグメント処理,受信側でのパケット再構成処理が頻発し,ルーターの処理遅延が大きくなる。
図1●送信パケットがMTUサイズを超えると性能劣化を招きやすい
送信側でのフラグメント処理,受信側でのパケット再構成処理が頻発し,ルーターの処理遅延が大きくなる。
[画像のクリックで拡大表示]

 実際のところ,多くの場合は広域イーサネット・サービスやVPNを使っていても問題は生じない。Windowsをはじめ,OSのTCP/IPスタックには「PMTU検出」(Path MTU discovery)と呼ぶ機能が実装されていて,ユーザーが意識しなくても,MTUサイズを自動的に最適化するようになっているからだ。PMTU検出は経路全体で許されるMTUサイズをICMP(internet control message protocol)を使って調べる機能で,RFC(request for comments)1191に仕様が記述されている。

 ただ何らかの理由で,PMTU検出に使うICMPをブロックしていると,MTUサイズを最適化できず,通信できない状況に陥ることがある。A社は,外部組織である出先機関の10拠点との間でVPNを構築した際に,MTUサイズに起因するトラブルに遭遇した(図2)。

図2●MTUサイズが原因でトラブルに陥ったA社のネットワーク<br>出先機関(10拠点)との間でインターネットVPNを構築した際に,2拠点との間で一部の通信の性能が極端に劣化した。
図2●MTUサイズが原因でトラブルに陥ったA社のネットワーク
出先機関(10拠点)との間でインターネットVPNを構築した際に,2拠点との間で一部の通信の性能が極端に劣化した。
[画像のクリックで拡大表示]

10拠点中2拠点だけ性能が出ない

 A社は,出先機関側からブラウザ(Internet Explorer)を使ってA社のWebアプリケーション・システムにアクセスさせ,データ入力(オンライン入力またはCSVファイルのアップロード)や処理結果(PDFファイル)のダウンロードを実行できる環境を構築しようとした。ところが,単体テスト(疎通確認)は順調に終えたものの,実際のアプリケーションを使用した結合テストの段階で2カ所の拠点で問題が発生した。サーバーにファイルをアップロードする際に,十分な性能が得られなかったのである。ダウンロードやWebページ表示など,A拠点から出先機関の向きの通信には問題はなかった。

 通信速度を測定してみると,ダウンロードが数Mビット/秒だったのに対し,アップロードは数百kビット/秒程度しか出ていなかった。ほかの拠点(出先機関)では問題なく数Mビット/秒の速度が確認されたため,問題は出先機関側のシステムにあると判断した。

 判断理由には,問題が発生した2拠点だけが,クライアントとファイアウォールの間にプロキシ・サーバーを設置していたこともあった。ただ,具体的な原因が分からない。ファイアウォールの外側(回線側)で,暗号化されていない状態のデータ・パケットをキャプチャしたが,再送など性能劣化を引き起こすような特別なエラーは発見できなかった。

 次に取り組んだのはファイアウォールのポリシー解析である。すると,出先機関側のファイアウォールが網側からのICMPを拒否していることが判明。試してみると,確かにpingは通らない。キャプチャ・データを再度確認したところ,本来ならあるはずのICMPパケットが一切見当たらなかった。

 ここで疑ったのが,MTUサイズを原因とするトラブルである。インターネットVPNではこうした例がしばしば見られる。

 もちろん,ルーターがフラグメント処理を実行すればパケットは分割して転送され,ICMPが通らなくても問題は起こらない。ただ最近のTCPアプリケーションの多くは,デフォルトでヘッダー中のDF(don't fragment)ビットがオンになっている(少なくともWindowsNT3.51以降やLinux kernel2.2以降ではRFC1191に対応した機能が実装されデフォルトで機能が有効になっている)。フラグメントによってパフォーマンスが劣化しないようにするためだ。

この記事は会員登録で続きをご覧いただけます

日経クロステック登録会員になると…

新着が分かるメールマガジンが届く
キーワード登録、連載フォローが便利

さらに、有料会員に申し込むとすべての記事が読み放題に!
日経電子版セット今なら2カ月無料