サーバー2012、ジャンボフレーム-問題が発生する可能性がありますか？
わかりました、この音はばかげているかもしれません-しかし、実際にジャンボフレームを有効にするだけでネガティブなことはありますか？
私が理解していることから：
- 処理できないジャンボフレームを検出したスイッチまたはイーサネットアダプタは、それをドロップするだけです。
- 最大フレームサイズはsetinuoフェーズでネゴシエートされるため、TCPは問題ではありません。
- サーバーが途中でドロップされる大きなUDPパケットを送信する可能性があるため、UCPは理論上の問題です。
ただし、実際には、UDPはパケットベースであるため、アプリレベルの構成を変更せずに1500バイトを超えるUDPパケットを送信するソフトウェアはないと思います。少なくとも、これがプログラミングの方法です。取得するのは非常に難しいためです。自分でテストしなくても、そのための適切なMTUサイズなので、プログラミングを最大1500パケットにフォールバックします。
問題のネットワークは標準的なスモールビジネスネットワークです。管理されていない24ポートスイッチから4つの10gポートを備えた52ポートスイッチにアップグレードし（netgear-非常に安価）、ISCSIサービス用にファイルサーバーを10gに移動します。イーサネットレベルのすべての機器は最小9000バイトを処理でき、ローカルファイアウォールがあるため、パケットを大きくしたい（ファイアウォール処理を少なくしたい）が、ネットワークもインターネットにNAT変換されている。その上、さまざまなマシンが処理のために大きなファイル（数ギガバイトの領域）を頻繁に移動（ダウンロード）します。
問題は、ジャンボフレームを有効にしただけで問題が発生する可能性があるかどうかです。
繰り返しますが、これは完全に無知ではありません-プログラムが1500バイトを超えるUDPパケットを送信しているのを見ていません（それが実際的な問題である場合は教えてください）そしてTCP MTUはとにかく交渉されます。
問題がある場合は専用VLANに移動できますが、基本的にほとんどのワークステーションは両方のVLAN上にある必要があるため、これには独自の問題があります。
実際にジャンボフレームを有効にするだけでネガティブなことはありますか？
いいえ、JFをオンに切り替えたときに、サーバーが適切なNICを使用できることをすぐに確認する限り、いいえ、実際の欠点はまったくありません。
1つの落とし穴は、タグ付きフレームに追加される14バイトです。一部のハードウェアでは、「床に落とす」アクションをトリガーするのに十分です。私は自分でそれに遭遇しましたが、問題のスイッチのMTUを9014に設定し、その他すべてを9000に設定することで修正されました。