第5回 イーサネットを高速化するジャンボ・フレーム技術：PCハードウェア強化ラボ（2/3 ページ）
イーサネットのフレームを拡張して、数Kbytesのデータを1回で送信できるようにするジャンボフレーム。その仕組みや注意点について解説。
さてそれでは、ジャンボ・フレームを使って通信してみよう。
ジャンボ・フレームで通信可能な環境とは
ジャンボ・フレームを使って通信するために必要な条件としては、通信経路の途中にあるすべてのハブやネットワーク機器、デバイス・ドライバなどがジャンボ・フレームに対応している必要がある。さらにジャンボ・フレームで通信できるように、あらかじめOSやシステムに指示を与えておく必要もある。具体的には、次の図のような環境を用意する。
ジャンボ・フレームの通信環境
ジャンボ・フレームでデータを送信するには、経路の途中にあるすべてのコンポーネント（ネットワーク・インターフェイス・カードやハブ、ルータなど）がジャンボ・フレームに対応している必要がある。そうでない場合、ジャンボ・フレームは非対応機器では受信できず、無視される。
■必要条件1――ジャンボ・フレーム対応機器をまとめてハブで接続する
この図は、通常のハブを使ったネットワークと何も違いはないように見えるが、実際その通りである。ただ、図の左側半分のPCやサーバ（実際にはネットワーク・カード）、ハブは、すべて「ジャンボ・フレーム対応」となっている製品で構成する必要がある。従来のジャンボ・フレーム非対応のハブやPCをジャンボ・フレーム対応ハブに接続してもよいが、当然ジャンボ・フレームを使った通信には参加できない。従来の非ジャンボ・フレームの通信のみが可能である。また、通信ペアの片方だけがジャンボ・フレーム通信に対応している場合は、やはり従来どおりの通信が行われる。ジャンボ・フレームで通信するには、通信する双方のコンピュータやそれを中継するハブがすべてジャンボ・フレームに対応している必要がある。
■必要条件2――複数のハブを経由する場合は、すべてジャンボ・フレーム対応ハブにすること
2台のコンピュータ間に2つもしくはそれ以上のハブが存在する場合、その経路の途中にあるハブはすべてジャンボ・フレーム対応ハブにすること。経路の途中に非対応のハブがあると、そこでジャンボ・フレームが破棄されてしまい、通信できなくなる（通常の通信は当然可能）。
ジャンボ・フレーム対応のL2／L3スイッチの例
ジャンボ・フレームを利用するためには、途中にあるハブやルータなどがすべてジャンボ・フレームに対応している必要がある。これはNetGear社のL3スイッチの例。
（1）ジャンボ・フレームの送受信を行うには、このフレーム・サイズをデフォルトの1518bytesから、より大きなサイズに変更する。
この条件を考慮すると、ジャンボ・フレーム対応のネットワーク・セグメントを作る場合は、必ず1カ所にまとめてジャンボ・フレーム対応のセグメントにする必要がある。同じIPアドレスのネットワーク・セグメント内に複数のジャンボ・フレーム対応ハブを導入し、それぞれをジャンボ・フレーム非対応のハブで相互に接続しても、通信相手によってはジャンボ・フレームが通らず、非常に面倒なことになる。
なおハブを購入する場合は、サポートされているジャンボ・フレームのMTUサイズにも注意する。サポートされているMTUが異なるジャンボ・フレーム対応ハブを接続すると、一番小さいMTU以上のサイズのフレームが通らなくなり、そこで通信が途絶する。もちろんこのMTUサイズは、接続するすべてのコンピュータのジャンボ・フレームのMTUサイズと同じか、それよりも大きくなっていることも必要である。例えばPC間で9Kbytesのジャンボ・フレームを送受信しようとしているのに、ハブのMTUサイズが5Kbytesしかなければ、5Kbytesのジャンボ・フレームまでしか使えない。
【コラム】ジャンボ・フレームのMTUサイズ表記
ベンダのサイトにあるネットワーク・カードやハブなどの製品仕様を見ると、「ジャンボフレームサイズ 9Kbytes」などと記述されていることがあるが、製品を導入する場合は1の位まで仕様を確認すること。単に「9Kbytes」と書いてあるけれども、実際には「9216（＝1024×9）」のほか、「9000」や「9014」など、さまざまな製品が存在している（9000は9014からイーサネットのヘッダ14bytesを引いたものと同じかもしれないが、もし本当に9000しかないとすると、MTUが9000のフレームが通らないので、問題となる可能性がある）。ハブやスイッチ、ルータでは余裕を持って9.5Kbytes程度まで扱える製品もあるが、実際には「9600」や「9578」「9500」など、やはりいろいろあるようだ。可能なら接続するどのPCよりも大きな値のものにしたいが、それが不可能な場合は接続するPC側でMTUサイズを抑えるなどの対策が必要になる。
■必要条件3――ネットワーク・インターフェイスでジャンボ・フレームを有効にしておくこと
デフォルトではジャンボ・フレームは無効になっているので、必要に応じて各コンピュータのインターフェイスでジャンボ・フレームを有効にしておく。Windows OSの場合は、ネットワーク・インターフェイスのプロパティ画面で設定できる。
ジャンボ・フレームを有効にする
それでは実際にジャンボ・フレームを有効にしてみよう。この設定はOSやシステムごとに異なるが、例えばWindows 7なら［コントロール パネル］の［ネットワークと共有センター］の画面左側にある［アダプターの設定の変更］でネットワーク・インターフェイスの一覧を表示させ（デバイス・マネージャから選択してもよい）、ジャンボ・フレームを設定させたいインターフェイスの［プロパティ］を表示させる。
ジャンボ・フレームの設定（1）
ジャンボ・フレームは、ネットワーク・インターフェイスごとに利用するかどうかを設定する。コントロール・パネルのネットワークやデバイス・マネージャでネットワーク・インターフェイスのプロパティ画面を表示させる。これはWindows 7の設定画面の例。
（1）ジャンボ・フレームを設定したいネットワーク・インターフェイス。
（2）これをクリックする。
次に［詳細設定］画面を表示させる。
ジャンボ・フレームの設定（2）
この画面でアダプタのMTU値を変更する。
（1）これを選択する。
（2）この画面ではメッセージは日本語化されているが、システムによっては英語のまま（「Jumbo Frame」など）の場合もある。この項目がない場合は、そのインターフェイスではジャンボ・フレームはサポートされていない。
（3）設定したいジャンボ・フレームのMTUサイズを選択する。相手のコンピュータ側のMTU値と同じである必要はないが（TCPの場合は最初にネゴシエーションが行われるため）、経路の途中にあるハブのMTU値よりも大きくしていると、相手によっては通信できないことがある。システムによっては、「5KB」「6KB」「7KB」という選択肢があるのに、実際のMTUは4Kbytesまでしかないという製品もあった。何が利用できるのか、実際のMTUはいくつか、などを後で確認すること。
ところでシステムによっては、MTUを変更するとWindows OSが障害を起こして停止し、いわゆるブルースクリーン表示になってしまうことがある。これはほとんどの場合デバイス・ドライバの不具合なので、デバイス・ドライバを更新するか、設定を［無効］に戻してジャンボ・フレームの使用を停止すること。なおシステムがすぐにまたブルースクリーン→再起動を繰り返してしまう場合は、Windows OSを再起動する前にネットワーク・ケーブルを抜いておくと障害の発生を抑制できる。
以上の操作を行うと、一度ネットワーク・インターフェイスが無効になって、すぐに有効になる。これで準備はできているはずなので、どこか適当なサイトやいつも使っているサーバなどに接続してみよう。pingコマンドなどでほかのホストへ到達するかどうかをチェックするのもよい。TCP/IP通信を使っている限り、ジャンボ・フレームを有効にしても、通常の通信はほとんどそのまま何の変わりもなく使えるはずである。だがもし大きなファイルの転送などで失敗することがあるようなら、例えば途中のハブなどでジャンボ・パケットが破棄されている可能性もあるので、構成をチェックしよう。
ジャンボ・フレームのMTUサイズを調査する
ジャンボ・フレームのMTUサイズが実際にいくつになっているのかは、例えば通信させてみてネットワーク・モニタなどで確認すればよいが（関連記事参照）、もっと簡単にはnetshコマンドでも確認できる。
C:\>netsh interface ipv4 show interfaces……ipv4のMTUの表示
Idx Met MTU 状態 名前
--- ------ ---------- --------- ---------------------------
1 50 4294967295 connected Loopback Pseudo-Interface 1
23 30 1500 connected ローカル エリア接続 2
10 10 9202 connected ローカル エリア接続 ……これが目的のインターフェイス
24 20 1500 connected VMware Network Adapter VMnet1
25 20 1500 connected VMware Network Adapter VMnet8
この画面には、現在登録されているネットワーク・インターフェイスと、そのMTUサイズが表示されている。今回設定したインターフェイスでは「9202」となっているが、これはイーサネットのヘッダ部分（14bytes）を除いた、MTU部分だけのサイズである。ヘッダのサイズを加えると「9202＋14＝9216（＝1024×9）」となり、先ほど設定した「9KB」になっていることが分かる。
ちなみにこのインターフェイスでは常にMTUサイズは9202となるが、通信相手のMTUサイズはこのサイズでなくても構わない。もっと小さいMTUサイズでもよいし、標準の1500でも構わない。MTUサイズが異なるのにどうして（TCPで）接続できるのかについては、後述する。
ジャンボ・フレームで通信してみる―ping編
このインターフェイスではMTUサイズが9202となっているため、理屈の上では、このサイズのIPパケットまではフラグメント化（断片化）せずに通信できるはずである。pingコマンドを使ってこれを確認してみよう。
次の例は、pingコマンドで通信相手（192.168.0.185）にフラグメント化を禁止したpingのジャンボ・フレームを送信しているところである。MTUサイズは、ローカル側（自分の側）は9202だが、相手側は9000である。そのため、相手側で受信可能な最大pingパケットのサイズは8972bytesまでである。このサイズは「MTU−28＝9000−28＝8972」で求められる。28はIPヘッダのサイズ20bytes＋ICMPのサイズ8bytesである（詳細は関連記事参照）。3番目の例の9175は、自分の側のMTUサイズを1byte超えるサイズである。これは送信もせずにエラーになるはずだ。
C:\>ping 192.168.0.185 -f -n 2 -l 8972……相手側MTU内に収まるpingパケットを送信
192.168.0.185 に ping を送信しています 8972 バイトのデータ:
192.168.0.185 からの応答: バイト数 =8972 時間 <1ms TTL=128 ……応答あり
192.168.0.185 からの応答: バイト数 =8972 時間 <1ms TTL=128 ……応答あり
192.168.0.185 の ping 統計:
パケット数: 送信 = 2、受信 = 2、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
最小 = 0ms、最大 = 0ms、平均 = 0ms
C:\>ping 192.168.0.185 -f -n 2 -l 8973……相手側MTUを1byte超えるpingパケットを送信
192.168.0.185 に ping を送信しています 8973 バイトのデータ:
要求がタイムアウトしました。 ……応答なし
要求がタイムアウトしました。 ……応答なし
192.168.0.185 の ping 統計:
パケット数: 送信 = 2、受信 = 0、損失 = 2 (100% の損失)、
C:\>ping 192.168.0.185 -f -n 2 -l 9175……ローカル側MTUを1byte超えるpingパケットを送信
192.168.0.185 に ping を送信しています 9175 バイトのデータ:
パケットの断片化が必要ですが、DF が設定されています。 ……送信できない
パケットの断片化が必要ですが、DF が設定されています。 ……送信できない
192.168.0.185 の ping 統計:
パケット数: 送信 = 2、受信 = 0、損失 = 2 (100% の損失)、
C:\>
この例では、相手のMTU内にちょうど入るpingには応答があるが、MTUサイズを1byte超えるpingには応答がない。相手のネットワーク・バッファに入る前に、破棄されているからだ。3番目のものは自分の側のMTUサイズすら超えているので、そもそも送信されない。この様子をネットワーク・モニタで見ると次のようになっている。
ジャンボ・フレームに対するping応答
通常のイーサネット・フレーム・サイズを大きく超える、9Kbytes程度のpingパケットを、フラグメント化することなく送受信している様子が分かる。これはネットワーク・モニタ3.4での観測例。
（1）イーサネットのフレーム長が9014byteあることに注意。通常のイーサネットでは1514bytesまでしか一度に送信できない。pingパケットを2回送っているので、応答も2回ある。それぞれ1つのパケットで収まっている。
（2）相手側のMTUサイズを1byte超えるpingパケットの送信。相手からの応答はない。相手に届く前に破棄されている。
（3）イーサネットのフレーム・サイズが9015bytesもある。
Copyright© Digital Advantage Corp. All Rights Reserved.