パケットが大きすぎる場合、IEEE 802.1ad（別名VLAN Tagging、QinQ）はどのように有効ですか？
最近、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" …