最近我一直在处理 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 丢弃——这是一个错误，操作系统永远不会知道它。（超大的帧计数器会向上点击，但仅此而已。）
当计算机尝试将数据包发送到网关机器时，这会导致问题。理想情况下，我将依赖路径 MTU发现。但是由于生成的以太网数据包太大，其他任何机器都无法接收，因此没有机会返回IP数据包太大的碎片消息：
根本不会有“碎片化”。如果指示“需要分段”，则第 2 层（以太网）没有任何意义。这是在第 3 层 (IP) 上通过路由器在必须丢弃数据包时发送 ICMP 消息来解决的，因为它不适合下一跳接口。
这让我首先想到我的第二个问题：
- 为什么有一个规范故意创建无效的以太网帧？这里的预期行为是什么？鉴于其他网络接口卡无法接收这些新的默认大小的数据包，他们期望发生什么。
然后这让我想到了我的第一个问题。这是以前被问过的问题 - 很多。
- 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 接口 ipv4 显示子接口
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 帧。