VLAN Tag 为什么要算进帧长
802.1Q 在以太帧的源 MAC 之后插入 4 字节 Tag，帧因此变长：同样是 1500 字节的 IP 载荷，无 Tag 时帧长 1518 字节，带一层 Tag 就是 1522 字节。路径上任何一跳按 1518 判上限，带 Tag 的大帧就会被丢弃——典型表现是『小包通、大包不通』，ping 默认小包时完全看不出来。
基本信息
| Tag 长度 | 4 字节（802.1Q） |
|---|---|
| 常见上限 | 无 Tag 1518 字节 / 单层 Tag 1522 字节（含 4 字节 FCS） |
| 设备差异 | 部分平台默认按 1522 计算，部分需显式放行带 Tag 大帧 |
| 巨型帧 | 常见 9000 字节载荷，加 Tag 后上限同步增加 |
| 排查工具 | ping 指定报文长度逐步试探路径可承载的最大尺寸 |
典型使用场景
- 新建带 Tag 链路：确认沿途设备都放行 1522 字节帧
- 存储与备份网络启用巨型帧：端到端核对每一跳的 MTU 设置
- 跨 WAN 或隧道场景：扣除封装开销后重新核算可用 MTU
- 业务报『大文件传不过、小文件正常』时的取证与定位
- 设备替换或版本升级后复查 MTU 相关默认值是否变化
帧长与验证
帧长与验证
无 Tag：14（头）+1500（载荷）+4（FCS）=1518
单层 Tag：1518+4=1522
无 Tag 巨型帧：14+9000+4=9018
单层 Tag 巨型帧：9018+4=9022
# 验证思路（数值按平台调整）
ping -M do -s 1472 <目标> # Linux：载荷 1472 对应 1500 字节 IP 包
ping -l 1472 -f <目标> # Windows：-l 指定载荷，-f 禁止分片帧长计算对照
| 场景 | IP 载荷 | 帧长 |
|---|---|---|
| 无 Tag | 1500 | 1518 |
| 单层 Tag | 1500 | 1522 |
| 无 Tag 巨型帧 | 9000 | 9018 |
| 单层 Tag 巨型帧 | 9000 | 9022 |
路径 MTU 不一致是隐蔽故障：中间一跳的上限小于帧长时，大帧被丢弃而小帧正常，协议控制报文照常收发，导致接口、邻居、路由状态全都正常，只有业务大包失败。
改 MTU 是链路级变更，必须两端与沿途设备同步调整；只在一侧放大巨型帧会让大包在下一跳被丢，反而从『部分可用』恶化成『完全不通』。
核对清单
- 逐跳确认设备放行的最大帧长（部分平台需显式配置带 Tag 大帧）
- 核对聚合口、隧道口、虚拟接口的 MTU 是否一致
- 存储与备份网络启用巨型帧时，从服务器网卡到交换机逐段核实
- 跨 WAN 场景按封装后的可用 MTU 重新核算，不留理论值
- 验收用逐步放大的报文尺寸探测，记录每跳的临界值
怎么快速判断
业务报大文件传输失败而登录、路由、邻居一切正常时，先在两端用逐步放大的报文做连通性探测：能通的最大尺寸如果停在 1472 附近，说明路径按 1500 字节 IP 包计算而带 Tag 的帧已被丢弃；若临界值更小，通常意味着中间还有隧道或更低 MTU 的一段。