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に対応した機能が実装されデフォルトで機能が有効になっている）。フラグメントによってパフォーマンスが劣化しないようにするためだ。
