VCF 9.0 TEP MTU 1600 验证失败原因与配置指南

1. VCF 9.0 与 TEP MTU 验证：先理清这条检查到底在查什么

1.1 项目背景

VCF 9.0（VMware Cloud Foundation 9.0）是 VMware 把 vSphere、vSAN、NSX 和 SDDC Manager 打包在一起的超融合与管理平台，主打的是“从裸金属到工作负载”的全栈自动化交付。装过的人都知道，VCF 部署远不止把几个 OVA 导进去这么简单，SDDC Manager 在 bring-up 阶段会做一大堆预检查，任何一项不通过都会直接卡住安装流程。

我这次遇到的，就是 ESX 主机上的 TEP 验证失败，报错指向 MTU 不足 1600。这类报错在企业内网环境中非常典型：底层物理网络是标准的 1500 MTU 接入，ESX 主机上所有 VMkernel 和端口组也都是默认 1500，结果 SDDC Manager 一检查就红了。报错信息本身不会告诉你“该去哪里改”，只会抛出一个抽象的网络路径问题，第一次见的人基本都会懵。

这篇文章适合正在部署 VCF 9.0 或者准备做 VCF 评估的运维工程师，尤其是负责底层网络和 ESX 主机配置的兄弟。文章会把这条验证的逻辑讲透，再给出一套从“查”到“改”再到“验证”的完整流程，保证你照着操作能顺利把这一步跨过去。

1.2 TEP 到底是什么

TEP 的全称是 Tunnel Endpoint，翻译过来就是隧道端点。在 NSX-T 的架构里，Geneve 隧道是承载 overlay 流量的核心机制，而 TEP 就是每台传输节点（也就是 ESX 主机）上负责收发 Geneve 封装包的那个逻辑接口。

你可以把 TEP 理解成快递收发点：所有虚机之间的东西向流量，都会被封装成 Geneve 格式，然后通过 TEP 发送到物理网络上。TEP 在 ESX 主机上通常表现为一个专用 VMkernel 网口，它的 IP 地址来自独立的 TEP 网段，这个网段专门用于 NSX overlay 流量。

既然 TEP 是隧道端点，它就必须考虑封装开销。Geneve 头部标准是 8 字节，加上 UDP 头部 8 字节、IP 头部 20 字节，再算上外层以太网帧头，封装后整包会比原始虚机数据包大出不少。如果两端协商的 MTU 不够，大包就会被丢弃，或者被迫分片，而分片对于隧道流量来说是大忌，会直接导致性能下降甚至通信中断。

1.3 为什么偏偏卡在 1600

VCF 9.0 的检查要求 TEP 接口 MTU 不低于 1600，而不是很多人习惯的 1500 或者 9000，这里面的数字是有讲究的。

虚拟机的标准 MTU 是 1500。当流量从虚拟机发出，经过 vSwitch 进入 TEP 时，NSX 会加上 Geneve 封装，整体长度就从 1500 涨到了大约 1600 以内。为了保证封装后不需要分片，物理链路的 MTU 必须至少覆盖整个封装包的长度。1600 这个数值就是在标准 1500 基础上，预留了 Geneve 封装的最大开销空间。

注意：这里有一个容易踩坑的点。很多人一看到“MTU 要大”，就直接往 9000 上设，觉得越大越好。但 VCF 检查逻辑和实际物理网络往往不支持 9000 的端到端透明传输，盲目设 9000 反而会引发其它一连串问题，比如 TLS 超时、vMotion 故障、存储性能异常。正确的目标值就是 1600，不多不少。

这套逻辑和餐桌铺桌布很像：菜盘直径算的是数据帧长度，桌布尺寸得按盘子加摆盘预留量来定，你按“盘子本身大小”去铺桌布，最后端上来盘子一放就把桌布撑破了。

2. ESX 主机默认 1500 的 MTU 为什么会触发失败

2.1 默认网络配置与检查逻辑的差异

VCF 9.0 安装时，SDDC Manager 会通过 vCenter 读取指定 ESX 主机的网络配置，然后对每个候选主机做 TEP 验证。检查逻辑并不复杂：它会遍历主机上所有标记为 TEP 用途的 VMkernel 网口，读取其 MTU 值，只要发现任何一个低于 1600，就直接判定为失败。

问题在于，绝大多数企业的 ESX 主机，默认网络规划是这样的：

你会发现，TEP 网络不一定是新建的。很多工程师在规划 VCF 环境时，知道需要单独划一个 TEP 网段，也建了对应的 VMkernel 网口，但往往会忘记把该网口的 MTU 从 1500 改成 1600。这个细节在 vCenter 界面上非常隐蔽，因为 VMkernel 网口的 MTU 默认就是跟随 vSwitch 的，而 vSwitch 默认也是 1500，你不到“编辑设置”那一层根本看不出来。

2.2 验证失败之后的连锁反应

当 TEP MTU 检查失败后，SDDC Manager 会停止整个 bring-up 流程，表现为界面上一直停留在某个 pre-check 阶段，无法继续下一步。很多人这时候会反复重试部署，或者怀疑是 DNS、NTP、凭据的问题，结果排查了一圈，回来发现还是卡在同一个点上。

实际上这个检查的设计意图就是要提醒你：你的底层物理网络没有为 overlay 流量预留封装余量。如果强行跳过这个检查继续部署，等 NSX 启动后，TEP 之间只要出现大包通信，就会产生巨大的丢包率，表现为 vCenter 管理面访问卡顿、虚机之间互通超时、甚至 SDDC Manager 自身与分布式交换机之间的 TLS 握手超时。

最近社区里热门的“mtu过大导致 tls 超时”案例，其实和这个检查是同一个链条上的两个极端：一端是 MTU 不够（1500 导致大包被丢弃），另一端是 MTU 过大（9000 但中间链路不通透，分片后重传导致 TLS 握手超时）。核心结论只有一个：MTU 必须端到端一致且贯通，1600 就是一个适合 VCF 环境的折中值。

3. 实操：让 ESX 主机满足 1600 MTU 验证要求

3.1 检查当前配置：先摸清楚主机实际状态

在动手修改之前，我们先确认一下 ESX 主机当前的 MTU 配置。这里我推荐直接用 esxcli 命令，比图形界面快得多，也更容易把信息一次性打全。

bash复制# 查看所有 vmnic 的物理链路状态和 MTU
esxcli network nic list

# 查看所有 vSwitch 的 MTU 设置
esxcli network vswitch standard list

# 查看所有 VMkernel 网口的 MTU 和所属 vSwitch
esxcfg-vmknic -l

命令输出里重点看 MTU 列。如果你发现 vSwitch 是 1500，那下面挂着的 VMkernel 口基本也都是 1500。另外要用 esxcli network ip interface list 看一下 TEP 网口到底挂在哪个 vSwitch 上，这样才能确定改动范围。

提示：VCF 环境中最常见的 TEP 配置是“独立 vSwitch、独立网段、单独 VMkernel”。如果你的环境中 TEP 是复用现有 vSwitch，那么改 MTU 的时候要格外小心，因为同一 vSwitch 下所有端口组的 MTU 都会联动受影响，管理网络流量也会跟着变成 1600。稳妥起见，建议 TEP 使用独立 vSwitch。

3.2 修改 vSwitch 与 VMkernel 网口的 MTU

确认现状后，进入修改阶段。我习惯先在 ESX 主机上通过命令行完成修改，再用 vCenter 界面复核，双重保险。

第一步，修改 vSwitch 的 MTU。假设 TEP 所在的 vSwitch 叫 vSwitch-TEP，执行：

bash复制esxcli network vswitch standard set -m 1600 -v vSwitch-TEP

-m 参数就是 MTU 值，单位是字节。这条命令会把整个 vSwitch 的 MTU 改为 1600，所有挂在这个 vSwitch 上的端口组和 VMkernel 口如果没有单独设置，会自动继承。

第二步，确认 VMkernel 网口的 MTU 是否跟随生效：

bash复制esxcfg-vmknic -l

如果 vmknic 的 MTU 显示 1600，说明已经生效。但有一种特殊情况：VMkernel 网口可以单独覆盖 vSwitch 的 MTU。如果你之前手动配过 1500，这里可能还是 1500，需要单独调整：

bash复制# 假设 TEP 网口是 vmk2，先删除再重建并指定 MTU
esxcfg-vmknic -d -v vSwitch-TEP -V vmk2
esxcfg-vmknic -a -i 192.168.100.10 -n 255.255.255.0 -m 1600 -v vSwitch-TEP -V vmk2

注意：esxcfg-vmknic -d 删除网口会同时移除该网口上的 IP 配置，操作前务必备份 IP 和 VLAN 信息。如果是生产环境，建议把命令写成脚本，减少人为失误。另外删除 VMkernel 网口期间，该网口承载的服务会短暂中断，TEP 网口在 NSX 尚未部署时没有实际业务流量，影响不大，但若涉及 vMotion 或者管理作用的一定要避开业务窗口。

如果你不想用命令行，vCenter UI 的操作路径是：选中 ESX 主机 → 网络 → VMkernel 网卡 → 选择 TEP 网口 → 编辑设置 → 在“NIC 设置”里把 MTU 改为 1600。注意这里要同时检查所属 vSwitch 的 MTU，因为 VMkernel 网口列表页能改的只是网口级 MTU，vSwitch 级 MTU 要去“虚拟交换机”页面改。

第三步，也是最容易被忽略的一步：确认物理交换机端口允许 1600 的帧通过。

3.3 物理交换机和直连网卡的配合

ESX 主机改完 MTU 只是主机一侧的配置，真正的考验在物理网络。如果接入 ESX 的物理交换机端口 MTU 还是 1500，那么从 TEP 发出的 1600 字节帧到达交换机时会被直接丢弃，表现为“主机配置看起来没问题，但 VCF 检查依然失败”。

这里需要你登录物理交换机，对连接 ESX 主机 uplink 的端口做如下配置（不同品牌命令不同，以华为为例）：

code复制interface GigabitEthernet0/0/1
  mtu 1600

如果是堆叠或者链路聚合环境，还要注意 trunk 口和 access 口的 MTU 设置是否一致。更严谨的做法是让网络团队确认整个 TEP 网段的二层链路都支持 MTU 1600，包括中间所有的汇聚交换机、堆叠链路和上行口。

实操心得：我遇到过客户只在接入交换机上改了 MTU，但汇聚交换机没改，结果 TEP 检查依然报错。排查到最后才发现汇聚交换机默认 mtu 1500。建议在动手前先找网络团队出一份“TEP 网段端到端 MTU 支持 1600”的确认邮件，白纸黑字，避免背锅。

直连网卡这一侧，一般不需要额外设置。ESX 主流的 vmnic 驱动（ixgbe、i40e、bnx2x 等）都支持 1600 MTU 的帧，只要没有驱动级强制限制就行。如果你用的是比较冷门的网卡，建议先确认驱动版本是否支持 jumbo frame，否则即使 vSwitch 配了 1600，底层网卡也可能在收包时直接丢弃超长帧。

4. 常见问题与排查技巧实录

4.1 改了 MTU 还是验证失败，问题出在哪

这是最高频的问题。很多工程师按上文步骤改完 ESX 主机 MTU，回到 VCF 界面重新执行验证，发现依然失败。这时候不要急着重复修改，先按以下顺序排查：

第一步，确认改动确实生效。不要只看 vCenter 界面，因为 vCenter 有缓存延迟。直接 SSH 到 ESX 主机上执行：

bash复制esxcfg-vmknic -l | grep -i tep

如果这里显示的 MTU 不是 1600，说明你的修改根本没保存成功，或者改错了网口。

第二步，确认物理链路可以承载 1600 字节帧。ESX 主机和物理交换机之间如果有中间设备（比如防火墙、负载均衡器透传、IPS 旁路），它们可能默认丢弃超长帧。最直接的验证方法是抓包或打大包，但更快的办法是看交换机端口上的丢包计数。

bash复制# 华为交换机查看丢包错误计数
display interface GigabitEthernet0/0/1

如果发现 discard、error 计数在增长，基本可以断定物理链路没放行大帧。

第三步，检查 vSwitch 上其它端口组是否意外继承了 1600。如果你把 TEP vSwitch 的 MTU 改了 1600，但该 vSwitch 上还挂着管理网络的 VMkernel，那么这台 ESX 主机的管理流量也会以 1600 的 MTU 发包，而接入交换机的管理 VLAN 口可能还是 1500，这就导致管理网络间歇性中断，SDDC Manager 反而连不上主机了。这类问题表面看是“验证失败”，实际是“管理网络快挂了”。

4.2 验证流程需要重新触发

VCF 9.0 的预检查结果是有缓存的。你改完 ESX 配置后，如果直接回到原来的部署向导页面，可能还是会看到旧的失败记录。这种情况下不需要把整个部署流程删掉重来，通常重新运行主机的“验证”或“重新检查”即可。

在 SDDC Manager 界面里，找到对应的 workload domain 或 bring-up 任务，点击“重新验证主机”之类的按钮。有些版本需要先移除主机再从列表重新添加，触发重新检查。如果按钮一直置灰，建议等 5 到 10 分钟再刷新，因为 SDDC Manager 和 vCenter 之间是异步通信，配置同步需要时间。

注意：部分升级场景中，VCF 9.0 的验证会读取 ESX 主机上 NSX 的“传输节点状态”，而不是直接读取 vmknic 的 MTU。这种情况下，你可能需要手动触发 NSX 传输节点的同步或重新准备，才能让 TEP 验证通过。如果实在找不到入口，可以考虑重启 hostd 服务：

bash复制/etc/init.d/hostd restart

不过这条命令会短暂中断 ESX 主机的管理服务，生产环境要谨慎使用。

4.3 网卡、驱动与固件的隐性影响

还有一种比较少见的坑：网卡驱动对 MTU 的支持有上限。虽然 vSphere 界面上允许你把 vSwitch MTU 配到 9000，但某些老型号的网卡（比如部分千兆网卡）驱动对巨型帧支持不完整，表现为单独打流没问题，一旦流量增大，网卡报错、丢包、甚至 reset。

在 VCF 9.0 这种重负载环境下，TEP 网口承担的是所有 NSX overlay 流量，网卡驱动不稳定会直接影响部署和后续运行。建议在改动 MTU 前，先把 ESX 主机的网卡固件和驱动升级到 VMware 兼容性列表里的推荐版本。

卸掉影响之后，TEP 流量实际上是一个高吞吐场景。虽然 400G/100G 网卡已经是主流，但仍有大量存量环境是 10G 甚至 1G。对于 1G 网卡，建议优先确认流控、队列数量和中断合并的设置，避免 1600 MTU 包在高流量下触发软中断瓶颈。

5. 个人实操体会与避坑建议

VCF 9.0 的 TEP MTU 验证，本质上是在替你把关底层网络的质量。它不是故意找茬，而是用一条硬性规则提前拦截掉那些“当时能装、事后必炸”的环境。

我实际部署过几次 VCF 环境，第一次遇到这个检查失败时，第一反应也是“能不能绕过”。但踩过坑之后我明白了，这条路是走不通的。即使你通过某种手段强行跳过检查，NSX 起来之后 TEP 之间的通信也会因为 MTU 不匹配而频繁报错，到时候排查起来比现在麻烦十倍。所以正确做法，就是把网络按照 VCF 要求的规范修好，一步到位。

最后分享一个小技巧：在规划 VCF 网络的阶段，就把 TEP 的 MTU 要求写进网络设计文档里，并且和物理网络团队在开工前对齐。不要等到 SDDC Manager 报红了再去协调网络团队，那种状态下你不仅要在技术上反复验证，还要承受跨团队沟通的压力。你只需要在接入层把所有相关端口统一配成 1600，汇聚层保持一致，TEP 网段用独立 vSwitch，基本上这个检查就是一次通过的。