做 VCF 9.0 交付的兄弟应该都遇过这种场面Bringup 预检卡在一项叫 “ESX TEP MTU” 的检查上报错要求 TEP 链路 MTU 为 1600但现场 ToR 交换机没开 jumbo frame网络组又不愿意为了装系统去动业务链路。第一次碰到的人会慌因为 VCF 的 pre-check 不放行后续部署流程全部卡死。这篇文章就把我处理这个问题的完整思路整理出来TEP 为什么非得是 1600VCF 预检到底在查什么以及当物理网络暂时满足不了时怎么安全地让安装流程继续走下去。1. TEP 与 1600 MTU 的关系VCF 预检到底在检查什么1.1 TEP 是个什么角色TEPTunneling End Point隧道端点是 NSX overlay 网络里的核心组件。在 VCF 9.0 的架构里NSX 负责提供覆盖网络overlay也就是我们常说的 Geneve 隧道。每台 ESXi 主机上会有一个或多个 vmkernel 接口来承担隧道端点这个接口就是 TEP。它的职责很纯粹把虚拟机发出来的二层帧封装成 Geneve 报文通过物理网络送到对端主机的 TEP再由对端解封装后交给目标 VM。打个比方物理网络是高速公路Geneve 隧道是运输货车VM 的二层帧是货箱里的货物TEP 是发货站和收货站而 MTU 是这条路上的限高杆。货车本身有高度Geneve 封装头货物也有高度原始 VM 帧限高杆不够高车就过不去或者只能强行压扁货物——对应到网络里就是分片和丢包。理解了这层关系你就会明白TEP 的 MTU 不是“能通就行”的参数它直接决定了 overlay 流量在物理网络上能不能完整通过。1.2 为什么偏偏是 1600标准以太网帧的 MTU 是 1500 字节几乎所有交换机默认都是这个值。但问题在于当 VM 发出一个 1500 字节的帧时NSX 需要给它加上 Geneve 封装头。Geneve 固定头 8 字节外层 UDP 头 8 字节外层 IP 头 20 字节再加上可能存在的选项字段总开销大约在 100 字节左右。如果物理链路 MTU 是 1500封装后的帧就是 1600 字节超过物理链路的上限结果只有两个丢包或者分片。VCF 9.0 要求 TEP 链路 MTU 为 1600本质上就是为“标准 1500 字节的应用净荷 100 字节 Geneve 封装开销”留下余量。1500 100 1600这个数字不是拍脑袋定出来的而是 overlay 网络的最低推荐值。你也可以配 9000 甚至 9216 的巨型帧但 1600 是 VCF/NSX 部署预检的默认检查阈值也是生产环境中最低配要求。为什么不直接要求 1500因为 1500 根本装不下封装后的报文。如果强制把 TEP MTU 设成 1500NSX 只能把超过限制的报文进行分片处理这会导致性能断崖式下跌部分数据库、存储类应用还会直接报错。所以 1600 是一个“保证应用帧完整同时不需要全网开 9000 巨型帧”的折中值。1.3 VCF 预检的检查视角一个关键洞察VCF 的部署没有大家想象的那么“智能”它本质上是一个自动化编排工具能检查的还是 ESXi 侧能暴露出来的信息。对 TEP MTU 这一项预检逻辑大致是找到每台 ESXi 上 TEP 所在的 vmkernel 接口读取该 vmkernel 所属 vSwitch / 分布式交换机 / 端口组的 MTU 配置如果低于 1600判定为 FAILED。关键在于VCF 无法直接探测物理交换机的 MTU 配置。它看不到物理交换机是 1500 还是 1600也看不到中间防火墙、IPS 设备上的 MTU 策略。它只能验证 ESXi 侧“声明”出来的 MTU 是否满足要求。这就是为什么后面所有绕过方案能够成立的根源——预检检查的是配置视角不是物理视角。2. 什么场景下你会卡在 TEP MTU 预检失败现场与日志定位2.1 三种典型的失败现场不是所有环境都会卡在这一项但你一旦遇到大概率是下面三种情况之一。第一种物理交换机没开 jumbo frame。很多企业的 ToR 交换机默认 MTU 就是 1500网络组出于“稳定压倒一切”的考虑不愿意开大的 MTU。这种环境下就算你把 ESXi 的 vSwitch 改成 1600物理链路也承载不了大包但这个事实 VCF 是不知道的它只会看到 ESXi 侧配置。第二种管理网络和 TEP 网络共用同一组物理链路的 VLAN。比如管理 VLAN、vMotion VLAN、存储 VLAN、TEP VLAN 都打在同一组物理网卡上。管理流量 1500 就够TEP 要 1600如果整条链路改成 1600会连带影响所有 VLAN 上的流量。网络组一听到“要动全局 MTU”就紧张项目就容易僵在那里。第三种网卡驱动或固件对 MTU 1600 支持不完整。有几次我遇到的情况是ESXi 侧配置已经改成 1600 了预检仍然报实际值 1500。排查下来是几年前的旧网卡驱动在驱动层就把帧大小钳制在 1500配置在 vSwitch 层面看起来改了实际收发包仍然走 1500。这种隐蔽问题最耗时间。2.2 失败到底长什么样VCF Bringup 的预检界面上检查结果会分组展示。TEP MTU 这一项通常在 “Host Validation” 或 “Physical Network Validation” 分组里报错内容大致是ESX TEP MTU check: FAILED Expected: 1600, Actual: 1500不同版本、不同补丁级别下措辞会有差异但关键词逃不出那几个MTU、TEP、1600、1500。如果界面上没有直接给出可以去翻预检日志。VCF 9.0 里预检日志通常在部署环境的/opt/vmware/vcf/orchestration-appliance/logs/目录下文件名类似bringup-precheck.log用grep -i mtu过滤就能定位到具体报错。2.3 动手绕之前先分清两个问题遇到这个报错我的习惯是先问自己两件事而不是急着找绕过办法。这个环境以后真的要跑 NSX overlay 的东西向和南北向流量吗如果是生产环境物理网络必须支持 1600 或更高绕过的意义只是“先把安装流程走完后续集中整改”。如果只是 PoC 或者 Lab物理网络是否真的无法调整很多主流交换机开启 jumbo frame 只是几行命令的事改完再跑一次预检是最干净、最没有历史包袱的路径。这里我放一个小对照表方便你初步判断网络组的工作量厂商开启 jumbo 的大致命令位置说明Ciscosystem mtu/mtu 1600不同 IOS 版本命令差异较大华为jumboframe enable/jumboframe enable 1600接口视图下配置H3Cjumboframe enable 1600以太网接口下配置Aristamtu 1600接口下直接配置即可具体命令以现场型号手册为准这里只是让你知道——开了 jumbo问题大概率瞬间消失。3. 绕过 ESX TEP 1600 预检限制的三种操作路径3.1 路径一在 ESXi 侧把 TEP 链路的 MTU 抬到 1600这是最“说出去也有理”的做法适合物理交换机已经支持 jumbo、只是 ESXi 侧沿用旧配置的情况。比如新加进 VCF 的主机是从旧 vSphere 环境迁移过来的原来跑的是 1500 的网络。通过 ESXi 的 SSH 执行# 查看标准交换机及其 MTU esxcli network vswitch standard list # 把某个标准交换机比如 vSwitch0的 MTU 改为 1600 esxcli network vswitch standard set -m 1600 -v vSwitch0 # 如果 TEP 使用的是独立端口组单独指定端口组 esxcli network vswitch standard portgroup set -m 1600 -p TEP-PortGroup如果 TEP 在分布式交换机上注意 DVS 的 MTU 是整台交换机级的属性不是端口组级esxcli network vswitch dvs vmware set -m 1600 -v dvSwitchName改完 vSwitch 还不够TEP 对应的 vmkernel 接口本身也有 MTU 属性需要一起对齐esxcli network ip interface set -i vmkX -m 1600然后确认一下esxcli network ip interface list看到 vmkX 的 MTU 为 1600再回到 VCF 预检重新跑。提示修改标准交换机的 MTU 会影响该交换机上所有端口组和 VM 网络。如果管理流量也在同一个 vSwitch 上建议先确认带外管理通道可用或者把操作安排在维护窗口内。3.2 路径二修改部署参数文件跳过 MTU 校验如果物理网络确实锁死 1500比如中间有云互联专线、跨数据中心链路路径一相当于“骗过了 VCF但没骗过物理网”。针对这种环境更直接的做法是改 VCF Bringup 的部署参数文件把 TEP MTU 校验从“必须 1600”改成“允许 1500”或者干脆跳过这一项。VCF 9.0 部署向导会生成一个 JSON 格式的部署参数文件通常叫deploymentParameter.json里面 TEP 相关的字段大致长这样{ nsx: { tepVlan: 100, tepMtu: 1600, skipTepMtuCheck: false } }绕过验证有两个改法把tepMtu改成1500让后续检查看到的预期值和实际一致。这种做法不算严格意义上的“绕过”而是修改了检查的预期值预检会按 1500 去校验 ESXi 侧配置是否匹配。把skipTepMtuCheck改成true让预检直接跳过这个检查项。这种做法更彻底也更有“绕过”的味道。不同版本字段名有差异tepMtu也可能是overlayMtuskipTepMtuCheck也可能是allowNonDefaultMtu但你在 UI 生成的 JSON 里按mtu关键字搜索基本都能找到对应项。我要补一句非常实在的话如果你真的把tepMtu改成 1500NSX Manager 会把 1500 作为 TEP 配置下发到 ESXi。后续 Geneve 封装后的报文只要超过物理链路的 MTU同样会分片或丢弃问题并没有消失只是安装流程能走完了。所以这个路径只适合 PoC 环境、纯功能验证或者你有充分理由确定业务流量不依赖大帧。3.3 路径三预检执行期间手工干预这条路径我不推荐但既然总有人问我简单说下思路。VCF 的预检过程最终会把每台主机的检查结果写入到编排服务的一个状态库中。前两次预检都因为同一项失败后理论上可以手动操作这个状态库把对应检查项的结果标记为 PASS。具体手法和命令在不同版本里差异很大而且这种操作属于典型的 hack 行为后续某个任务如果读取了错误的状态会在更隐蔽的阶段爆出问题。个人建议尽量不要走路径三。路径一至少对齐了 ESXi 侧配置路径二对齐了部署预期值它们的操作都是在“配置/声明”层面做的调整结果可预期。路径三则是把“失败”硬改成“成功”一旦中间某个环节没考虑到Bringup 真正开始配置 TEP 时还是会失败而且日志指向网络层错误排查范围反而更大。3.4 三条路径怎么选场景推荐路径理由物理交换机支持 jumbo只是 ESXi 没配路径一补上真实配置后续无隐患物理交换机不支持 1600但项目必须先装路径二跳过检查装完再集中整改物理网络只是 PoC/Lab能接受分片风险路径二tepMtu1500最快的放行方式任何情况下都坚决不动物理网络、不改参数路径三下下策不建议用于生产4. 绕过之后不等于万事大吉数据面验收与整改路径4.1 怎么确认 TEP 之间真的能通部署完成只是第一步第一时间要验证隧道数据面是真的通。别只看 UI 里所有主机显示 UP 就认为没问题实际流量能不能跑才是关键。一个快速验证办法从一台 ESXi 上 ping 另一台 ESXi 的 TEP IP并带上接近 1600 MTU 边界的包大小。ICMP 报文由 IP 头20 字节和 ICMP 头8 字节组成为了在 MTU 1600 的链路上恰好不超限payload 用 1572这样 20 8 1572 1600ping -d -s 1572 -c 3 对端TEP IP如果 1500 载荷能通、1572 载荷不通说明链路大包被掐了物理网络或中间设备上仍有 MTU 问题需要继续排查交换机接口 MTU、VLAN 接口 MTU、安全设备 MTU 策略等。4.2 物理网络整改的标准动作如果当初用了路径二放行那么物理网络整改是绕不开的后半场。大致按这个顺序做在交换机全局或 trunk 接口上开启 jumbo frame。Cisco 一般是system mtu华为是jumboframe enableH3C 类似jumboframe enable 1600具体按型号查手册。逐跳检查所有中间设备。很多环境里核心交换机开了 jumbo但串接的防火墙、IPS、负载均衡还是 1500这些设备在 trunk 链路上没有同步放大的话就会出现“接口全 up 但大包不通”的黑洞。从物理层向 ESXi 层逐跳验证ping -d -s 1572打一遍哪一跳不通就整改哪一跳。全部验证通过后再决定是否把部署参数里的tepMtu从 1500 改回 1600并让 NSX 重新下发 TEP 配置。4.3 从 1500 过渡到 1600 的平滑切换如果你的 VCF 环境已经在 1500 下跑了一段时间现在物理网络终于整改到支持 1600 了怎么切换才能不中断业务我的建议是按“先物理、再虚拟、后隧道”的顺序物理网络先全部完成 1600 MTU 改造用 ESXCLI 把每台 ESXi 的 TEP 链路 MTU 从 1500 抬到 1600观察 10 到 30 分钟确认没有主机告警、vSphere HA 没有触发迁移、隧道没有中断最后确认 NSX 管理面没有报 MTU 不匹配的告警。实际操作中很多人在第 2 步会发现 VM 网络闪断原因多半是改动了承载 VM 流量的 vSwitch MTU。如果 TEP 链路和 VM 流量物理隔离TEP 走独立网卡影响会小很多如果混在同一张网卡上就需要走维护窗口逐台迁移 VM 后处理。5. 几个容易爆雷的细节与最终建议5.1 DVS MTU 是全局的这是个经典坑路径一里我提过标准交换机 vSwitch 的 MTU 是按端口组配置的不同端口组可以不同但分布式交换机 vDS 的 MTU 是整台交换机级的改一个等于改全部。有次我在现场改 DVS MTU忘了这个特性顺手把整个 DVS 的 MTU 从 1500 改成 1600结果该 DVS 上所有 VM 的流量全部闪断了几秒。操作之前先确认 TEP 用的是 vSS 还是 vDS再决定执行哪条命令、影响范围多大。5.2 MTU 过大导致的 TLS 超时和这个是同一个物理本质很多人在网上搜“MTU 过大导致 TLS 超时”多半是业务侧报了“登录卡顿、文件传输失败、连接超时”。这种问题的根源就是 MTU 黑洞小包SYN/ACK、TLS 握手的前几个控制帧能过大一点的帧证书交换后的第一个大响应、应用层数据块在中间某个 1500 的链路里被静默丢弃。TCP 依赖重传表现就是忽快忽慢最终超时。这和 VCF TEP MTU 预检是同一个物理本质报文大于链路 MTU 时设备不是告诉你“我丢了”而是直接沉默。所以排查这类问题优先检查“链路里有没有一段 1500 的瓶颈”而不是一开始就抓应用层的 TLS 参数调优。这条经验是我从好几场头痛故障里换来的写出来供你参考。5.3 给后来人的最小检查清单如果你下次在 VCF 9.0 安装现场又卡在 TEP MTU 这一项按这个顺序过一遍先确认物理交换机有没有开启 jumbo frame再确认 ESXi 侧 TEP 链路vSwitch/DVS vmk的 MTU 值是否一致检查中间是否有防火墙、IPS 等串接设备它们的 MTU 策略也要确认以上都确认后仍然希望放行安装再考虑修改部署参数文件跳过该项目放行安装后记得把整改事项列入交付计划别把它丢在一边。真实交付里“绕过”两个字听起来有点野但它本质上是在复杂环境约束下让安装流程继续往前走的一种调度方式。我在 VCF 项目里既用过路径一也用过路径二。我的原则很简单能改物理网络就改物理网络改不了就用部署参数放行但一定要同步做好整改计划和时限。问题不会因为你看不见它就不存在。等你真正理解了 TEP 为什么需要 1600这个预检限制就不再是吓人的拦路虎而只是一个待对齐的配置项。