最近、MTUの問題を扱っています。そして、それはすべて、新しいコンピュータのイーサネットアダプタのデフォルトのフレームサイズが1504バイトであるという事実から生じているようです。
>netsh interface ipv4 show subinterfaces
MTU MediaSenseState Bytes In Bytes Out Interface
------ --------------- --------- --------- -------------
1504 1 3954161316 804790885 Local Area Connection
NetworkEngineering.stackexchange.comのランダムな人物によると、イーサネットパケットが大きすぎるため、大きすぎるパケットは受信側のネットワークインターフェイスカード（NIC）によってドロップされます。
... MTUが802.3の仕様である1500よりも大きいフレーム
最大設定よりも大きなフレームはなり NICによって落とされる-それは誤りだし、OSはそれについて知っていることはありません。（特大のフレームカウンターがクリックしますが、それだけです。）
これにより、コンピュータがゲートウェイマシンにパケットを送信しようとしたときに問題が発生します。理想的には、パスMTUディスカバリーに依存することになります。ただし、生成されるイーサネットパケットは他のどのマシンでも受信するには大きすぎるため、IP パケットが大きすぎる断片化メッセージを返す機会はありません。
「断片化」はまったくありません。「断片化が必要」を示す場合、レイヤー2（イーサネット）には意味がありません。これは、ネクストホップインターフェイスに適合しないためパケットをドロップする必要がある場合に、ICMPメッセージを送信するルーターによってレイヤー3（IP）で計算されます。
最初に2つ目の質問をさせていただきます。
- 無効なイーサネットフレームを意図的に作成する仕様があるのはなぜですか？ここで意図されている動作は何ですか？他のネットワークインターフェイスカードがこれらの新しいデフォルトサイズのパケットを受信できない場合、彼らは何を期待していたでしょうか。
次に、最初の質問に2番目に移動します。そして、これは以前に尋ねられたことです-多く。
- 4バイトのQinQタグはイーサネットフレームヘッダーの一部ですか、それともイーサネットペイロードの一部ですか？ヘッダーの一部である場合、ペイロードボディが4バイト増加したのはなぜですか？イーサネットペイロードの一部である場合、なぜペイロードMTUが4バイト増加するのですか（4バイト増加すると無効なパケットになることがわかっている場合）。
より大きな質問は...
少し前に戻ると、より大きな質問があります。
私たちは何をすべきか？
この標準を設計した人がいたに違いありません。これらの大きすぎるパケットを生成するデバイスで人々が何をすることを期待していたのでしょうか？
私は本当に尋ねています。すべてのハードウェアデバイスに移動してMTU 1504の増加を元に戻し、それを1500に戻すつもりはなかったと思います。
netsh interface ipv4>set subinterface "Local Area Connection" mtu=1500 store=persistent
Ok.
これは、設定の悪夢になる（そして今もそうです）
VLANタギングをオフにするという考えでしょうか？設定の悪夢は別として、それは単に機能しません：
ステップ1：VLANタギングを無効にする
ステップ2：機能しないことを確認します。
netsh interface ipv4 show subinterfaces
MTU MediaSenseState Bytes In Bytes Out Interface
1504 1 238125 245855 Local Area Connection
これに対する解決策が手動ですべてのネットワークカードを1500のMTUに強制的に戻すことである場合、そもそもなぜそれらが最大1504バイトにバンプし、無効なパケットを作成したのですか？
パズルのピースが欠けています。
ボーナスおしゃべり
Without 802.1Q tagging Without 802.1Q tagging
+------------------------+ +------------------------+
|Destination MAC: 6 bytes| |Destination MAC: 6 bytes|
|Source MAC: 6 bytes | |Source MAC: 6 bytes |
|Ethertype: 2 bytes | |802.1Q tag: 4 bytes |
+------------------------+ |Ethertype: 2 bytes |
| | +------------------------+
| | | |
/ Payload: 1500 bytes / / Payload: 1500 bytes /
| | | |
| | | |
+------------------------+ | |
| Frame Check Sequence: | +------------------------+
| 4 bytes| | Frame Check Sequence: |
+------------------------+ | 4 bytes|
+------------------------+
ネットワーク図
+------------------+ +----------------+ +------------------+
| Realtek PCIe GBe | | NetGear 10/100 | | Realtek 10/100 |
| (on-board) | | Switch | | (on-board) |
| | +----------------+ | |
| Windows 7 | ^ ^ | |
| | | | | |
| 192.168.1.98/24 |-----------+ +------------| 192.168.1.10/24 |
| MTU = 1504 bytes | | MTU = 1500 bytes |
+------------------+ +------------------+
最大許容1500バイト数よりも大きいパケットを生成して、好きな構成に置き換えることもできます。
+------------------+ +----------------+ +------------------+
| Realtek PCIe GBe | | NetGear 10/100 | | Realtek 10/100 |
| (on-board) | | Switch | | (on-board) |
| | +----------------+ | |
| Windows 7 | ^ ^ | MTU = 1500 bytes |
| MTU = 16384bytes | | | | |
| |-----------+ +------------| |
+------------------+ +------------------+
一部のデバイスが意図的に無効なパケットを生成した場合にイーサネットがどのように機能するかという、技術的、概念的、論理的、根本的、理論的な問題に対処できるサイトを見つけようとしています。
問題は、無効なイーサネットパケットを別のイーサネットデバイスに送信しようとしたときです。
コンピューターがイーサネットパケットを生成する
Source MAC: xx-xx-xx-xx-xx-xx Destination MAC: yy-yy-yy-yy-yy-yy Ethertype: 0x0800 Payload: ...1504 bytes... (or could be ...16384 bytes, anything larger than 1500...) CRC: 4 bytes
このパケットは、ターゲット802.3uデバイスが受信するには大きすぎるため、無効です。ターゲットのホストオペレーティングシステムはパケットを認識せず、イーサネットには無効なパケットを送信者に報告する機能がないため、「大きな」パケットは失われます。
ボーナスおしゃべり
Ciscoのスイッチ間リンクとIEEE 802.1Qのフレーム形式：
フレームサイズ
インターフェイスのデフォルトの最大転送単位（MTU）は1500バイトです。イーサネットフレームに外部VLANタグが接続されている場合、パケットサイズは4バイト増加します。したがって、プロバイダーネットワークの各インターフェイスのMTUを適切に増やすことをお勧めします。推奨される最小MTUは1504バイトです。
その間：
IEEE 802.3イーサネット規格では、1500バイトのMTUフレームのサポートのみが義務付けられています。