ギガビットネットワークへのアップグレード-ジャンボフレームの有効化
SOHOネットワークをギガビット（10/100から）にアップグレードし始め、ジャンボフレームで少し聞こえてきました。
ジャンボフレームをネットワークに実装する最良の方法は何ですか？それが適切に機能するために私が言うことができることから、ネットワーク上のすべてのネットワークギアはジャンボフレームをサポートする必要があります。これは本当ですか？
GBイーサネットに更新できない特定のギア（ネットワークプリンターなど）がある場合、ジャンボフレームを有効にできませんか？
ジャンボフレームを有効にする際の注意点は何ですか？
最初に、ジャンボフレームイーサネットとは何かを説明するのが最善です。イーサネットはレイヤ2ネットワーキングテクノロジーであり、そのプロトコルデータユニット（PDU）はフレームです。参考までに、L3PDU（IP層）はパケットで、L4PDU（tcp/udp）はセグメントです。
イーサネットフレーム（いくつかのタイプのイーサネットがありますが、ここで一般化できます）は、ヘッダー（特に、送信元MAC、宛先MAC、802.1q VLANタグ、 etc）フレームのデータまたはペイロード、およびフレームの正常な送信を検証するために使用されるCRCチェックサム。
元のイーサネットは、フレームサイズ（ヘッダーとチェックサムを含むフレーム全体のデータの評価）を1500バイト（または、おそらく1518で、ルックアップする必要がある）と指定していました。この数は、一度に送信するデータの量と、送信が失敗または衝突して再送信する必要がある可能性とのバランスをとったものです。高速の全二重LANの登場により、人々はイーサネットフレームサイズを大きくすることでパフォーマンスを向上できることに気づきました。ジャンボフレームの従来のサイズは、フレームあたり9000バイトですが、これはほとんどの場合慣例です。
すべての要素がジャンボフレームイーサネットを受信することを期待している堅実な全二重LAN（またはVLAN）では、実際にはパフォーマンスが向上します。このシナリオの問題は、予期しないネットワーク要素またはエンドデバイスを導入した場合です。最良のケースでは、受信デバイスがフレームに1518バイトしか期待していないため、パケットが失われるため、パフォーマンスが低下します。
さて、あなたの特定の質問に：
ジャンボフレームをネットワークに実装する最良の方法は何でしょうか？
これは主観的な質問です。私の事業所では、すべての変数が制御されていることがわかっていて、それが役立つことがわかっている場合にのみ実装することにしました。これを行うために、特定のデバイスのみが2番目のNICを介してアクセスできる特別な「プライベート」VLANに実装しました。具体的には、ファイルサーバーとアプリケーションサーバーの2番目のNIC=をこの新しいVLANに追加し、このVLANで使用されるIPスキームへのすべての参照を変更しました。これにより、私たちが最も恩恵を受けることがわかっている特定の領域（インフラストラクチャでの使用率データリンクが最も高い）を特定して（誰もデスクトップマシンをこのVLANに接続することはありません）を絞り込むことができます。これにより、リスクを最小限に抑えながら利益を最大化します。
具体的には、ネットワーク側（IOSを使用）で、ジャンボフレームデバイス専用のVLANを構築し、それらのVLAN定義に「mtu 9000」を追加しました。このネットワークを使用するスイッチ上のすべてのインターフェースは、「switchport access vlan 11」のようなものを使用してこのVLANに配置されました。 Linuxマシン（eth0が標準ネットワークに接続され、eth1がジャンボフレームネットワークに接続されている）では、/ etc/sysconfig/network-scripts/ifcfg-eth1に「MTU = 9000」を追加しました。これらのパケットはルーティングしないため（ジャンボフレームに直接接続されていないものはVLANジャンボフレームVLANでNICと話すことは不可能））、ルータの設定について心配する必要がありました。
それが適切に機能するために私が言うことができることから、ネットワーク上のすべてのネットワークギアはジャンボフレームをサポートする必要があります。これは本当ですか？
ええ、ほとんど。すべてのネットワーク「クライアント」（つまり、サーバー/デスクトップ/ IPKVMs/IP環境モニターなど）はそれも話す必要があります。または、前述のように、多数の半到達可能なマシン（pingを実行し、 1500バイト未満のL3またはL4PDUは成功します。つまり、例として、メールサーバーはpingを実行し、小さなテストメッセージである可能性のあるものを手動で配信できます。しかし、実際のメール（フレームサイズ> 1500バイトがプッシュされたExcel添付ファイル付きのメール）は不思議なことに失敗します）。
GBイーサネットに更新できない特定のギア（ネットワークプリンターなど）がある場合、ジャンボフレームを有効にできませんか？
その場合は、次のようにします（これを処理できるネットワークギアを想定しています）。
- 2つのVLANを構築します。1つはジャンボフレームあり、もう1つはなし
- すべてのネットワークデバイスをいずれかのVLANに割り当てる
- ルータとスイッチで、ジャンボフレームVLANを実装し、ネットワーククライアントのフレームサイズを変更します。
これは、ネットワーク上でフラットなL2トポロジがなくなることを意味します。たとえば、ジャンボフレーム対応サーバーから非ジャンボフレームプリンターに印刷する場合、パケットをルーティングする必要があります（ルーターを経由し、フレームを従来のサイズに書き換えてから、他のVLAN上のプリンター）。これは、ジャンボフレームと非ジャンボフレームマシン間の通信が以前よりも少し劣ることを意味しますが、ジャンブロフレーム上のすべてのデバイス間のデータ転送速度VLANはより良いでしょう。それは本当に裁判の呼びかけです。
ジャンボフレームを有効にする際の注意点は何ですか？
うまくいけば、上記でカバーしました。幸運を！
ジャンボフレームで Jeff Atwoodの投稿 を見つけることができます。
投稿のハイライト：
- 20％のパフォーマンス向上
- 大きなフレームをそのまま維持するには、通過するすべてのデバイスがそのフレームサイズをサポートしている必要があります。
- ジャンボフレームをサポートしないスイッチはそれらをドロップします
Ping.exeを使用してパケットの最大サイズを確認し、それをジャンボフレーム設定と比較できます。
ping -l 4096 -f server
-lで使用されるパケットサイズを調整し、-fを使用してDO_ NOT_FRAGMENTフラグを設定します。最大パケットサイズに達すると、「パケットはフラグメント化する必要がありますが、DFセット」と表示されます。
これにより、ジャンボフレームが機能するかどうかがわかります。
はい、すべてがジャンボフレームをサポートする必要があります-トークンリングとイーサネットの切り替えのように扱います。唯一の違いは、一部のデバイスが短時間または断続的に動作するように見える可能性があることです。大規模なネットワークで再構成したwhichデバイスを追跡しないと、これも大きな頭痛の種になる可能性があります（つまり、2週間後、キュービクルの奥に「今すぐ」機能しなくなったプリンターが詰め込まれたユーザーからトラブルチケットが届きます。新しいものにも同じことが当てはまります。ジャンボフレームを備えた新しいデバイスとコンピューターを再構成する手順をセットアップし、初期起動以降にサポートコールが機能しない場合にそれを回避する必要があります。
Linuxでは、次のことが機能することがわかりました。タグ付きのVLANを使用している場合は、ベースデバイス（eth1など）のmtuをジャンボフレームサイズに設定します。ジャンボフレームをサポートするすべてのVLANは同じMTUを取得します。これらのVLANは元のVLANにとどまらず、ほとんどの場合1500です。
実際、ジャンボトーカーとスイッチングが有効になっているVLANは、そのVLAN上のMTUがベースインターフェイスのMTUより小さい場合でも、ローカルVLANインターフェイスに送信できます。
また、Linuxでは、テストするコマンドは次のとおりです。ping-s 4096 -M do
-sはサイズ、-Mは「断片化しない」と言います。ローカルmtuを超えると、エラーが発生します。リモートmtuを超えると、何も返されません。