WANをまたいで拠点間を接続している場合,パケットのフラグメンテーションが原因でトラブルに陥ることがある。通信経路上でMTU(maximum transmission unit)サイズが小さい部分があるケースだ。具体的には,広域イーサネット・サービスを利用している場合や,暗号化技術を使ってVPN(仮想的な専用線)接続している場合である。
MTUサイズはデータ・パケットを送信する際に許容される最大パケット長で,イーサネットでは1518バイトというように物理媒体によってそれぞれ値が決まっている。問題はWANにデータを送出する際にカプセル化などによってパケット長がMTUサイズを超えてしまうケースがあることだ。パケット長がMTUサイズを超えている場合,ルーターなどが自動的にパケットを細分化(フラグメント)して送信することがある。この場合,フラグメント処理,受信側での再組み立て処理が発生し,パフォーマンスが劣化しやすい(図1)。
実際のところ,多くの場合は広域イーサネット・サービスや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)。
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に対応した機能が実装されデフォルトで機能が有効になっている)。フラグメントによってパフォーマンスが劣化しないようにするためだ。