前阵子在某个数据中心的服务器交付项目里我们遇到了一个特别折磨人的问题新上架的几十台服务器都做了双网卡接入网络侧是 H3C 6880 用 M-LAG 做了跨设备链路聚合然后通过 PXE 方式批量安装操作系统。结果开工当天就翻了车——十台机器里七八台卡在 PXE 启动阶段偶尔有那么几台能过去但只要重新装机、重启一次又是随机失败毫无规律。这个现象用一句话形容就是“薛定谔的 PXE”。如果说故障是彻底不通那还好定位偏偏它时好时坏反复重试又能成功这就让现场交付的同学非常崩溃。我自己在处理这类问题上有段时间了M-LAG 本身不是新东西PXE 装机也不复杂但两者放到一起踩坑点往往就藏在广播转发、ARP 同步、DHCP 报文处理这些容易被忽视的细节里。这篇文章就把这次“H3C 6880 M-LAG 场景下 PXE 启动问题”完整复盘一遍从组网背景、故障现象到根因分析、配置调整、排查命令再到后期规范一条线讲清楚。适合正在做数据中心网络交付的网络工程师、搞自动化装机的系统运维、以及被双活组网里“随机失败”问题困扰的朋友参考。内容偏实战不会有太多理论空谈尽量让你看完能直接照着手动排查。1. 场景还原与问题现象1.1 M-LAG 组网到底长什么样先说背景。这次的网络拓扑并不复杂两台 H3C 6880 作为机架顶部TOR交换机下联服务器上联核心交换机。两台 6880 之间跑 M-LAG对外表现为一台逻辑设备服务器两个网口分别接到两台 6880 上组成跨设备链路聚合。M-LAG 这个技术通俗点理解就是两台独立的交换机通过一条 peer-link 链路和一条 keepalive 心跳链路“搭伙过日子”。两台设备各自保留独立控制平面但在二层和三层的转发行为上保持同步把同一个聚合组拆到两台设备上从而实现链路冗余和负载分担。相比传统堆叠M-LAG 最大的优势是升级、割接时对业务影响小单台设备故障也不会导致整个聚合组失效。但代价是两台设备之间必须通过协议机制同步 MAC 表、ARP 表同时对广播、组播、未知单播的转发要有一套跨设备的协作机制。这个机制如果配合得不好就会出现一些“看起来哪里都通实际上关键时刻掉链子”的问题。本次组网里服务器的 PXE 网卡分别接到两台 6880 的物理口上两台 6880 通过 peer-link 互联VLAN 配置和网关配置都在 M-LAG 双活模式下运行。拓扑上完全是标准做法看不出任何问题。1.2 故障现象PXE 启动卡死在 DHCP 阶段故障现象非常典型PXE 启动过程卡住的位置不一样大部分时候卡在 DHCP 阶段客户端反复发 DHCP Discover一直拿不到 IP最终报PXE-E51: No DHCP or proxyDHCP offers were received。少部分情况能拿到 IP但随后下载引导文件的时候超时报PXE-E32: TFTP open timeout。偶尔能正常引导但成功率很低而且没有规律同一台服务器这次能过、下次就挂。一开始我们还怀疑是 DHCP 服务器或者 TFTP 服务器的问题因为 PXE 依赖的 DHCP Offer 里会携带 next-server 和 bootfile 等信息只要这几个参数有问题下载引导文件阶段就必然失败。但单独用一台服务器直连核心交换机测试 PXE 装机一切正常成功率 100%。后来又把服务器改成单网卡只接一台 6880 测试PXE 也是正常的。但只要恢复双网卡同时接入两台 6880也就是走 M-LAG 聚合链路问题立刻复现。这就基本把问题范围锁定到了 M-LAG 跨设备转发这个环节。1.3 为什么这类问题特别难排查这里要插一句。M-LAG 场景下的 PXE 问题难就难在“随机”两个字。如果我们直接双网卡接入一台普通交换机那广播域、DHCP 流程、ARP 流程都在单台设备内完成逻辑链路短哪里断了很容易看出来。但有了 M-LAG 之后客户端发出的广播报文有可能被两台设备同时收到也有可能只被一台设备收到而 DHCP 服务器的回应报文又可能从另一台设备回来。报文去和回走的不是同一台设备这种非对称路径在 M-LAG 里很常见但一旦中间某一环没有同步好报文就悄悄丢了。另一个难点是交换机上很多特性默认是开启或者半开启状态的比如 DHCP Snooping、ARP 抑制、未知单播抑制、组播风暴抑制。这些特性在普通场景下可能一辈子都不会触发问题但在 PXE 这种高频广播、高频单播交互的场景里任何一层过滤都可能把关键报文干掉。而设备日志又不会给出明显提示只会默默丢包表面上看起来一切正常。所以我们当时的排查思路就是先把“看起来正常”表象打碎沿着 PXE 报文的生命周期一台设备一台设备地查一个阶段一个阶段地确认。2. 为什么 M-LAG 会让 PXE“时灵时不灵”2.1 先回顾 PXE 启动的四个关键阶段要理解 M-LAG 在 PXE 问题里扮演什么角色必须先捋一遍 PXE 启动对网络的要求。这里不展开讲协议细节只挑四个最容易出问题的环节第一阶段客户端广播 DHCP Discover寻找 DHCP 服务器。这个报文是二层广播目标 MAC 是 FF:FF:FF:FF:FF:FF。第二阶段DHCP 服务器回应 DHCP Offer。这个报文可能是广播也可能因为客户端已经知道了服务器地址而采用单播取决于客户端和服务器之间的协商。第三阶段客户端发送 DHCP Request确认使用某个 Offer。同样可能是广播或单播。第四阶段DHCP 服务器发送 DHCP Ack携带 IP 地址、网关、DNS、next-server、bootfile 等参数。这个报文大概率是广播。拿到 IP 之后客户端会根据 DHCP Ack 里的 next-server 和 bootfile去发起 TFTP 或 HTTP 请求拿引导文件。这一步是单播通信依赖客户端的 ARP 能正常解析到 TFTP 服务器的 MAC。这看似简单的流程里广播报文和单播报文交替出现。M-LAG 只要对广播转发、ARP 响应、DHCP 报文的收发任何一处处理得不一致都可能让 PXE 卡住。2.2 M-LAG 跨设备转发的“隐藏规则”M-LAG 组网下两台成员设备通过 peer-link 互联。为了让跨设备聚合链路正常工作正常情况下客户端发的广播报文会在两台设备上都被处理。但这也就意味着如果交换机上某些广播抑制、组播抑制策略生效报文就会在对端设备上被拦掉。更关键的是 ARP 表。M-LAG 设备之间会同步 ARP 表项目的是让目标服务器发出的单播报文无论从哪台交换机进来都能查找到正确的出接口。但同步是有时序的如果客户端刚获取到 IP、MAC 表项还没有完全同步到两台设备那么 DHCP Offer 这类单播报文到达另一台设备时设备查询不到对应 ARP 表项就只能向 peer-link 泛洪或者直接丢弃。还有一条容易被忽略的规则M-LAG 组网中某些报文的“处理权”是分角色和分工的。比如广播报文如果到达了非网关角色的一台设备它可能需要把报文通过 peer-link 转发给另一台设备处理。这个转发过程一旦遇到 peer-link 拥塞、VLAN 不一致、策略过滤报文就消失得无影无踪。2.3 本案例里最可疑的根因配置一致性在我们这个案例里经过对比两台 6880 的配置发现了一个非常隐蔽的问题两台设备上关于 DHCP Snooping 的信任端口配置不一致。第一台 6880 的上联口配置了dhcp snooping trustDHCP Offer 可以正常进入但第二台 6880 的上联口没有配置这个信任标记默认状态下是 untrusted结果从 DHCP 服务器方向过来的 Offer 报文会被 DHCP Snooping 特性当作非法报文直接丢弃。这就完美解释了随机失败服务器双网卡同时接入两台 6880但 PXE 客户端在发送广播 DHCP Discover 的时候广播报文会同时到达两台设备。理论上两台设备都有可能收到 DHCP 服务器的回应。如果回应报文从第一台设备进来一切正常如果从第二台设备进来就被丢弃了。而哪台设备最终收到服务器回应取决于服务器侧、网络侧、客户端侧的哈希结果不同时刻、不同报文可能选不同的路径所以现象就是随机失败。2.4 为什么“看起来哪里都通”还有人会问既然第二台设备把 Offer 丢了为什么客户端不等待一下重试呢PXE 客户端确实会重试很多次但如果每一次 DHCP Discover 之后服务器回应的路径都恰好哈希到第二台设备那重试多少次都是失败。偶尔哈希结果变了走第一台设备就成功了于是就有了“重试几次能成功”的错觉。另外DHCP 协议本身有超时和重传机制正常广播域内一个 DHCP Discover 可能收到多个 Offer。但因为两台 M-LAG 设备相当于同一个二层广播域而真正能转发 Offer 的只有一台设备所以客户端完全没有替代方案只能干等超时。这种问题用“抓包视角”看特别容易误判在客户端侧抓包可以看到 DHCP Discover 一直在发但收不到 Offer在 DHCP 服务器侧抓包可以看到服务器已经回了 Offer。报文出了服务器进了交换机然后没了下文。很多人到这里就懵了因为 TCP/IP 协议栈和 PXE 都没错问题出在交换机内部的处理逻辑上。3. 处理方案与关键配置调整3.1 快速确认故障点三步验证法如果你也遇到了类似问题我建议先做三步验证别急着改配置。第一步把服务器双网卡中的一根网线拔掉只保留一台设备的链路测试 PXE 是否正常。这个步骤用于确认单台设备本身没有问题。第二步换成只保留另一台设备的链路再测试。这一步用于确认第二台设备也没有硬性问题。第三步恢复双网卡接入复现问题。如果前两步都正常、第三步随机失败那就可以确定问题出在 M-LAG 跨设备协作机制上而不是单台设备或者物理链路。这三步操作成本很低却能把排查范围缩小一大半。我们当时就是靠这个方法快速排除了物理线路、服务器网卡、交换机端口、DHCP 服务器配置等因素。3.2 抓包要抓三个点少一个都不行PXE 排障抓包是必须的但抓包位置很有讲究。我强烈建议在三个位置同时抓包客户端网卡侧用 tcpdump 或者 Wireshark 抓客户端收发的所有报文确认客户端发了什么、收到了什么。两台交换机侧用镜像口把 PXE 业务 VLAN 的报文镜像出来确认交换机是否收到广播、是否转发了单播、是否有报文被丢弃。DHCP 服务器侧确认服务器到底收到了多少个 DHCP Discover、回了多少个 Offer。三个点对照起来看报文丢失的位置基本一目了然。如果客户端发了 Discover服务器回了 Offer但交换机侧抓不到 Offer那就证明交换机内部有丢弃行为接下来查交换机的过滤策略、信任口配置、Snooping 表项方向就非常明确了。H3C 设备上做镜像的基本配置通常是这样mirroring-group 1 local mirroring-group 1 mirroring-port GigabitEthernet1/0/1 to GigabitEthernet1/0/4 both mirroring-group 1 monitor-port GigabitEthernet1/0/24把抓包电脑接在 monitor 口上用 Wireshark 抓包即可。注意两台设备都要抓因为 M-LAG 是非对称转发的只看一台会漏掉关键线索。3.3 核心配置调整统一两台设备的 DHCP Snooping 信任口回到我们这次的根因。定位到 DHCP Snooping 信任口不一致之后处理方式其实非常简单把两台 6880 上连接 DHCP 服务器方向的所有上联口都配置为 DHCP Snooping 信任口即可。H3C 交换机上典型的配置命令如下dhcp snooping enable # interface Bridge-Aggregation1 port link-type trunk port trunk permit vlan 10 20 30 100 dhcp snooping trust # interface Bridge-Aggregation2 port link-type trunk port trunk permit vlan 10 20 30 100 dhcp snooping trust这里有个细节如果 DHCP 服务器不在本交换机直连的接口下而是在上层核心交换机后面那连接核心交换机的上联口必须配置为dhcp snooping trust。否则 DHCP Offer 下来的时候会被 Snooping 特性当成仿冒报文丢弃。同理如果 DHCP 服务器是旁挂方式旁挂口也必须配置为信任口。而连接服务器的下联口保持默认的 untrusted 状态即可这样还能利用 DHCP Snooping 建立绑定表项防止终端私接 DHCP 服务器。如果业务上完全不需要 DHCP Snooping也可以直接全局关闭undo dhcp snooping enable关闭之后交换机不再做 DHCP 报文合法性检查PXE 流程里的 DHCP 报文就能原样透传。但代价是失去 DHCP 报文防护能力。我的建议是能精确配信任口就精确配别一刀切关闭毕竟大型数据中心里 DHCP 防护还是有价值的。3.4 检查并统一两份关键配置表除了 DHCP Snooping还有两份配置必须重点核查而且一定要两台设备对比着看。第一份是 M-LAG 的 VLAN 放通列表。peer-link 和业务聚合口上必须放通所有需要跨设备转发的 VLAN尤其是 PXE 装机 VLAN。如果 peer-link 上没放通这个 VLAN那么从一台设备过来的 ARP 请求、DHCP 广播、单播响应都无法跨到另一台设备M-LAG 形同虚设。第二份是 VLAN 接口的配置也就是网关配置。双活网关模式下两台 6880 上同一个 VLAN 的三层接口必须配置相同的 IP 地址和相同的 M-LAG 虚拟网关参数。最简单的检查方式就是比对两台设备的display current-configuration interface Vlan-interface输出确保配置一致。H3C 设备查看 M-LAG 状态的命令如下display mlag summary display mlag verbose display mlag keepalivedisplay mlag summary会显示 M-LAG 组是否建立、系统 MAC 是否一致、成员端口状态是否正常。display mlag verbose可以查看两台设备上 M-LAG 组的角色DR/SR、同步状态。display mlag keepalive用于确认心跳链路是否正常如果心跳断了两台设备会分裂成两个独立的系统转发行为会变得不可预测。还有一个容易被忽略的地方M-LAG 要求两台设备的系统 MAC 配置一致。如果系统 MAC 不一致对端设备学习到的 MAC 表会产生混乱ARP 响应也可能会出现错误PXE 过程就会出现“能收到 DHCP Offer但后续单播流量找不到出口”的现象。3.5 如果问题依然存在尝试划分独立装机 VLAN如果经过上述调整PXE 问题依然断断续续那我的建议是不要在一个业务复杂的 VLAN 里硬扛干脆给 PXE 装机单独划一个 VLAN。操作思路很简单把服务器 PXE 引导阶段的网络单独划到 VLAN 100装机专用 VLAN这个 VLAN 只用于 PXE 和系统安装不用承载业务流量。两台 M-LAG 设备上这个 VLAN 的配置保持完全一致DHCP Relay 指向专门的 PXE DHCP 服务器网关直接用 VLAN 接口。这样做的好处是显而易见的VLAN 内的流量类型非常单一只有 DHCP 广播和 TFTP/HTTP 单播特权策略、过滤规则可以做到最简化M-LAG 协作机制对这个 VLAN 的转发行为也更容易验证。典型配置示意vlan 100 description PXE-BOOT # interface Vlan-interface100 ip address 192.0.2.1 255.255.255.0 dhcp select relay dhcp relay server-address 203.0.113.10注意这里是 DHCP Relay 方式前提是 DHCP 服务器和 PXE 客户端不在同一个二层广播域。如果 DHCP 服务器就在本 VLAN 内则不需要配置dhcp select relay直接让广播自然转发即可。3.6 长期建议用 HTTP Boot 替代传统 TFTP 引导这次问题解决之后我们做了一次更彻底的改造建议把服务器引导模式从传统 BIOS PXE TFTP 升级为 UEFI HTTP Boot。传统 PXE 依赖 TFTP 下载引导文件TFTP 基于 UDP没有拥塞控制在批量装机时经常出现超时而 HTTP Boot 基于 TCP传输可靠性强很多对网络环境的容忍度也更高。不过需要明确一点HTTP Boot 依然依赖 DHCP 获取 IP 地址和引导文件路径所以 DHCP 这一步的问题依然是基础绕不开。换句话说HTTP Boot 解决的是“拿到参数之后下载引导文件超时”这类问题但解决不了“DHCP Offer 被交换机丢掉”的根本问题。所以基础配置的排查和统一依然是重中之重。4. 常见问题与排查经验整理4.1 M-LAG 与 PXE 场景的高频故障速查把这类问题整理成速查表方便大家直接对照排查。现象可能原因排查方向PXE 卡在 DHCP客户端收不到 OfferDHCP Snooping 信任口未配置或配置不一致对比两台设备上联口信任配置重点查 DHCP 服务器方向接口PXE 卡在 DHCP偶发能获取 IPM-LAG 非对称转发导致部分 Offer 被丢弃两台设备同时抓包确认 Offer 在哪台设备丢失能获取 IP但 TFTP 下载超时next-server 参数错误或 ARP 表跨设备未同步检查 DHCP 服务器 next-server 配置查看两台设备 ARP 表能获取 IP部分机器报错peer-link 未放通装机 VLAN检查 peer-link 及业务聚合口 VLAN 放通列表PXE 完全不通直连单台交换机正常M-LAG 系统 MAC 不一致或 keepalive 中断执行 display mlag summary、display mlag keepalive批量装机时大量超时广播抑制或组播抑制误伤 PXE 广播临时关闭相关抑制策略验证4.2 千万别只盯着一台设备查这是我要重点强调的实操教训。M-LAG 排障最忌讳的就是“只看一台设备的日志和计数器觉得另一台肯定一样”。两台设备虽然配置上应该一致但实际运行中的状态可能天差地别。比如这次案例里第一台设备的上联口是信任口第二台设备不是从第一台设备看所有报文处理都正常甚至抓包也看不出问题因为报文根本没走到它那里。你如果只查第一台设备查一天都查不出结果。正确姿势是把两台设备都拉出来逐项对比配置逐项对比状态。最简单粗暴的方法是用脚本把两台设备的配置、ARP 表、MAC 表、M-LAG 状态全部 dump 出来做一次文本 diff所有差异点一目了然。4.3 先做减法再做加法遇到这种“随机失败”的问题我的习惯是先做减法把可能影响报文转发的特性先临时关掉比如 DHCP Snooping、ARP 抑制、组播风暴抑制、未知单播抑制以及端口下的各种过滤策略。关闭之后如果 PXE 恢复正常说明问题就出在这些特性里如果依然失败再考虑转发路径本身的问题。然后做加法一项一项把特性重新打开每开一项就做一轮 PXE 测试直到复现问题就找到了元凶。这个方法虽然原始但在复杂的 M-LAG 环境里非常高效能帮你避开“配置看着都对但就是找不到问题”的泥潭。4.4 DHCP 服务器侧也要查别忽略 option 参数PXE 能否最终引导起来不只是看交换机DHCP 服务器侧的几个关键参数也很容易出问题。常见的错误有next-server 配置成了不存在的 IP或者 TFTP 服务器 IP 写错。bootfile 路径写错比如没有写绝对路径或者文件名大小写不对。多个 DHCP 作用域冲突导致客户端获取到错误网段的 IP。没有配置 option 66/67 相关参数客户端拿到了 IP 却不知道去哪个服务器下载引导文件。这类问题常在批量装机时集中爆发因为模板参数往往只测过一次换网络环境后就忘了调整。建议在排查交换机之前先从 DHCP 服务器抓包确认 Offer 内容是正确的再花精力在网络上找原因顺序不要搞反。4.5 一个典型的 M-LAG 问题处理现场记录为了让大家更直观地理解我虚构一个常见的处理过程如有雷同纯属巧合。某次模拟项目中现场反馈服务器 PXE 报错我们按三步验证法测试后发现直连正常、单臂正常、双上联失败于是抓到根因方向。在两台交换机上同时抓包后发现客户端发出的 DHCP Discover 两台设备都收到了也都被正常处理。但 DHCP 服务器只回了其中一个 Offer而且这个 Offer 恰好走到了第二台设备的接口上。第二台设备的接口由于上联口未配置 DHCP Snooping 信任Offer 被静默丢弃。客户端侧完全看不到任何回应不断重试直到哈希路径变化、Offer 走到第一台设备才偶尔成功。处理方式就是在第二台设备上补齐信任口配置并将两台配置纳入统一的版本管理流程。最后再跑一轮批量装机几十台服务器连续测试全部通过问题关闭。这个案例我拿出来说的原因是现场排查时大家最容易纠结于“为什么 DHCP 服务器只回一个 Offer”而不是去关注“收到的那个 Offer 为什么被交换机扔了”。顺着报文路径查永远是最快的。5. 收尾这套问题背后的通用方法论M-LAG 和 PXE 的组合看起来是个垂直场景但排查逻辑其实可以迁移到很多双活组网故障里。核心就四句话先缩小范围再梳理路径然后对比配置最后验证特性。我在实际处理中的体会是M-LAG 的问题几乎都不是“大故障”而是“小细节”。两台设备之间的配置一致性、表项同步状态、角色划分任何一环出了偏差报文就会在某个隐蔽的角落消失。而 PXE 因为广播和单播交互密集恰恰是暴露这些小细节的放大器。最后再分享一个小技巧这一类问题排查时可以在两台设备上各自配置一个端口镜像把装机 VLAN 的所有报文镜像到同一台抓包电脑的两个网口上同时抓包。这样能非常直观地看到同一份广播报文在两台设备上的处理差异基本半个小时之内就能锁定问题方向。希望这篇整理能帮到正在被类似问题折磨的人。