10GbEでは「Jumbo Frame」が効果的、1Gとの混在環境ではMTUサイズに注意

10GBASE-Tは1000BASE-Tとの混在が可能だが……

　10GBASE-Tは、既存の10/100/1000BASE-Tとの後方互換性があるので、例えば、以下のようなネットワークを構築した場合、10GBASE-T搭載クライアントはサーバーと10Gbpsで通信できる一方で、1000BASE-T搭載クライアントとサーバーとの間は1Gbpsでの通信となる。これは同時に利用できるので、とりあえずスイッチさえ10GBASE-T対応のものに差し替えれば、既存のネットワークはほとんどそのままで、10GBASE-Tへの移行準備が整うことになる（もちろん10GBASE-Tを搭載するサーバーやクライアントへ接続する配線はCAT6以上にする必要はある）。

異なる速度のネットワークが混在した環境の例

　ただ、この状況だと、環境やスイッチの性能にも依存するが、10GBASE-T回線の性能が6～7Gbps程度で頭打ちになることが多い。その理由はMTU（Maximum Transmission Unit）である。MTUは、要するに最大フレーム長で、この数字を超えるデータを転送する場合はフレームが分割される。Ethernetでは最大フレーム長が1500ということになっているので、デフォルトでは1500Bytesを超えるデータは、複数フレームに分割して転送が行われる形になる。

　そもそも、このMTUが1500に設定されたのはIEEE 802.3、つまり10BASE-2/5の時代の話である。正確に言えば、IEEE 802.3ではMTUは64～1518Bytesと定められている。ただ、このうち18Bytesはヘッダ領域用なので、データとしての最大値は1500となるわけだ。その後、IEEE 802.1ad（Provider Bridge）用に8Bytes増やしたり、あるいはIEEE 802.1Q（VLAN）用に4Bytes増やしたり、と細かく増えた規格は存在するが、やはり一般には、1500Bytesのままで現在に至っている。なので、このフレームサイズのまま速度を上げてゆくと、フレーム数が非常に増えてしまい、オーバーヘッドの増加に繋がる点が問題になる。

　実は、このMTUサイズの小ささは、光ケーブル向けのGbE規格である1000BASE-SXなどで最初に問題となった。以下のグラフは2009年のものだが、MTUを1500Bytesのままにしたときには、スループットが400Mbps止まりでCPUの負荷率が100％に達してしまうという結果になっている。理由は扱うべきデータ量が増えたことで、CPUのフレーム処理が間に合わなくなってしまうためだった。

画像の出典はEthernet Allianceのホワイトペーパー"Ethernet Jumbo Frames"

MTUのサイズ変更とCPU性能の向上

　解決策は、MTUのサイズをもっと大きくして、処理すべきフレームの数を減らせばよい。グラフの"9K Frames"は、MTUのサイズを9000Bytesにしたもの。フレームサイズを6倍に増やしたことで、スループットは600Mbps超となり、CPU負荷も55％まで減ったことが示されている。

　ところが、これがあまり問題になっていないのは、急速なCPU性能の向上のおかげである。上の測定環境が、CPUのクロックが300MHz、OSがSolaris 2.5.1、カードはSBusベースとされているので、CPUに「UltraSPARC IIi」を搭載したSunの「Ultra 5/Ultra 10」あたりではないかと思うのだが、300MHzのUltra 10では、「SPECint95」が12.1とされている。似たような結果を探すと、IntelのPentium II 300MHzのものが大体同程度だ。

　ラフに言えば、現在のCPUは当時の10倍程度は高速であり、もはや1Gbpsのフレーム処理程度でCPU負荷が100％になることはない。また、高機能なLANカードの中には、TCPオフロード（フレーム処理を含むTCP処理の一部をハードウェア側で肩代わりする）機能を持つものもあり、これを利用すれば、さらにCPUの負荷が減る。

10GBASE-T環境で効果的な「Jumbo Frame」

　ただし、10GBASE-Tになると話はまた別だ。転送速度が10倍ということは、フレーム数も10倍になる。結果、フレーム処理が追い付かないか、追いついてもCPU利用率が非常に高くなってしまう問題が再び出現することになった。高価なサーバー用の10GBASE-Tチップでは、TCPオフロードを使って処理負荷を減らせるが、ASUS XG-C100Cのようなカードでは、これも望み薄だ。このため、MTUを1500を超えるサイズに設定するのが効果的だ。

　この1500を超えるMTUは、「Jumbo Frame」と呼ばれる。実際にはこのJumbo Frameにもいくつか呼び方や分類があるが、ここではおいておく。これを最初に提唱したのはAlteon Networks（2000年にNortel Networksに買収され、2009年にはRadwareに売却される）で、要するにMTUのサイズを1500以上に設定できるようにしようという「だけ」である。これは広く普及し、最大だと14000～16000程度の値を設定できるものもあるが、9000くらいが一般的である（ほかに筆者が見た中では、7000や4000、2500などもあった）。なぜこのように値がまちまちかというと、標準規格がないためだ。

　標準化されなかったのは、互換性の問題が出るためだ。もし、Ethernetのフレームに、フレームサイズを格納するフィールドがあれば、それほど問題なかったのかもしれないが、実際にはフレームサイズを格納するフィールドはないため、従来のEthernet機器は、フレームを受け取ったら頭から順に読んでいき、1500バイトを越えた先にFCS（Frame Check Sequence:32bitのCRCコード）が格納されていなかった場合、それは破損したフレームと見なして破棄して終了する。つまりJumbo Frameに対応していない機器では、Jumbo Frameをそもそも受け取ることができないわけだ。

　この問題は対処のしようがなく、IEEE 802.3では、Jumbo Frameは標準化の対象にならなかった。だから、混在環境でサーバーと10GBASE-T搭載クライアントにJumbo Frameを設定してしまうと、1000BASE-T搭載クライアントから10GBASE-Tサーバーが見えなくなる。

　もっと正確に言えば、見える場合もある。フレームが1500Bytes以下であれば通信できるからだ。例えば、Windowsのネットワークの機器一覧ではサーバーが見えるし、ひょっとすると認証も通るかもしれない。だが、いざデータを転送しようとするとタイムアウトが発生して繋がらなくなる、という感じになるだろう。そして、エラーを起こすとしばらく見えなくなるという次第だ。

「Jumbo Frame」設定の10GBASE-Tと1000BASE-Tのセグメントを分割

　異なる速度のネットワークが混在した環境の例には、サーバーとクライアントだけを記しているが、実際はルーターやプリンターなど、さまざまな機器が繋がっており、これらのほとんどは1500までのMTUにしか対応していない。あるいはWi-Fiなどで繋がる機器も同様だ。これらが全部繋げなくなる、というのも困ったものである。

　ではどうするか？　一番簡単なのはネットワークを分割することだ。以下の図のように、通常のMTUとJumbo Frameでセグメントを分割してしまえばいい。従来のネットワークには引き続きMTUを1500に設定した1000BASE-Tで接続し、これとは別に新たに10GBASE-Tのネットワークを追加する、という形になる。この10GBASE-Tの方では、MTUに9000程度の値を設定すればいい。

　この場合、サーバーと10GBASE-T搭載クライアントはIPアドレスを2つ持つ形になるので、Windowsのネットワークを使っていると、名前解決にちょっと面倒な場合がある（ブラウズマスターホストがどこに置かれるか次第ではあるのだが、無条件で1000BASE-TのIPアドレスが指定されてしまい、10GBASE-Tが利用されないことが考えられる。というか、昔やったときにそうなった）のだが、これはルーティングテーブルの設定やhostsファイルの追加など、いくつかのテクニックを使えば解決できる。逆に言えば、このあたりがまだちょっと面倒、ということだ。

ネットワークを10GBASE-Tと1000BASE-Tの2つに分割した例