前几天在同一套网络里折腾了几乎一整天的PXE启动问题处理好之后我把整个过程完整记录了下来越想越觉得值得单独写一篇。现场环境很典型两台H3C S6880作为服务器接入Leaf设备之间用M-LAG做跨设备链路聚合服务器通过两个物理网口分别接入两台S6880批量部署操作系统时走PXE引导。故障现象是部分服务器获取不到IP或者拿到了IP却在加载引导文件时超时时好时坏毫无规律。把单条链路拆开、只接一台交换机时PXE又一切正常——这个对比几乎等于直接告诉我是M-LAG转发模型和PXE引导流程之间出了问题。这篇文章把这些坑从头到尾拆一遍从PXE引导链路的工作原理、M-LAG的转发行为到具体排查命令、抓包位置和修复方案尽量写成一个可复现的处理笔记。如果你也在用S6880或者其他型号做M-LAG双活接入并且日常有PXE批量装机、自动交付的需求这篇文章应该能帮你省不少时间。1. 故障现场与表象1.1 环境拓扑与配置背景先说网络环境。两台H3C S6880设备分别命名为Leaf1和Leaf2它们之间通过专门的peer-link链路互联另外用独立的三层链路做keepalive组成标准的M-LAG双活系统。服务器侧全部双网卡bond4方式接入一张网卡连Leaf1的M-LAG成员口另一张网卡连Leaf2的M-LAG成员口对外表现为一个跨设备聚合组。业务VLAN是VLAN 100网关在S6880上用M-LAG双活网关方式对外提供两台设备上VLAN接口的IP地址保持一致。DHCP服务器和TFTP服务器当时部署在同一台服务器上单点接入在Leaf1侧的三层网络里通过路由可达。这套设计在网络连通性上没有任何问题服务器起来之后流量转发、南北向通信都正常。问题出在服务器还没有进入操作系统、处于PXE引导这个“非常规”阶段时。1.2 故障现象与复现规律现场反馈的核心现象是批量安装系统的某批次服务器中大约有三分之一左右PXE启动失败。失败的表现分成两类一类是网卡固件反复轮询最终报PXE-E51意思是没有收到任何DHCP或者代理DHCP服务的回应另一类是DHCP阶段其实已经完成IP和引导文件路径都拿到了但下载引导文件时超时报PXE-E32。最关键的线索是复现规律。同样的服务器如果把网卡顺序改一下让PXE只从接在Leaf1的那张网卡启动成功率明显上升反过来只从接Leaf2的网卡启动时失败率又会变高。更直接的实验是拔掉一根网线让服务器仅仅通过单台交换机的端口接入PXE网络这样几乎每次都成功。这一组对比实验做完基本可以确定故障源就在M-LAG系统本身而不是DHCP配置或者服务器网卡固件。在交换机和DHCP服务器上也做了检查物理端口全部up光模块收发正常DHCP服务进程正常地址池剩余充足没有资源耗尽的问题。问题越是这样“看不出毛病”越说明需要从协议交互层面分析。2. 为什么M-LAG会给PXE添乱2.1 PXE引导链路里最容易被网络忽略的几步PXE启动本质上是一个多层协议的串联过程第一步是网卡固件通过DHCP获取IP地址以及引导服务器信息。客户端发送的是广播类型的DHCPDISCOVER如果在同一个二层域内有DHCP服务器它会直接回应如果DHCP服务器在远端则需要三层交换机做DHCP中继把广播报文转换成单播发往服务器。第二步是拿到DHCPOFFER或DHCPACK之后网卡固件根据其中的bootfile和next-server字段去TFTP服务器下载引导文件。麻烦在这儿TFTP是一个基于UDP的无状态协议客户端向服务器69端口发起读请求服务器会从一个新的UDP端口向客户端源端口回数据。这个过程中没有任何连接状态本质上就是发包-回包。如果网络中存在不对称转发或者某个中间设备没有转发某个方向的UDP包TFTP就会直接超时。PXE固件的超时窗口又很短通常是十几秒内收不到就退出引导流程。这和流畅的双向通信网络不同PXE链路非常依赖路径的对称性。2.2 M-LAG的转发模型决定了哪些报文会“翻车”M-LAG虽然让两台交换机从控制面看起来像一台设备但它不是堆叠数据面的转发行为和单台设备有明显区别。堆叠IRF把两台设备变成一台逻辑设备控制平面由主设备统一处理数据流量不管从哪个成员进来转发路径都是完全统一的。M-LAG则不一样两台设备各自保留独立的控制平面只是通过peer-link和keepalive同步部分状态数据面在绝大多数情况下遵循本地优先转发原则——哪个成员收到的流量尽量就从哪个成员直接转发出去减少peer-link上的穿越。问题来了对于广播帧、未知单播帧、组播帧这些“没有明确唯一目的地”的流量M-LAG系统通常会在两台设备之间做角色分工避免同一个报文被两台设备重复转发。不同厂商、不同型号的软件实现还不完全一样有的按主备角色处理有的按目的地MAC哈希分工。PXE引导阶段恰好充满了广播和未知单播DHCPDISCOVER是广播ARP请求是广播TFTP下行数据是单播但可能在没有MAC表项的情况下变成未知单播。只要其中一个被“分工”到了错误的那台设备上整个引导链就断了。2.3 容易在M-LAG环境下翻车的几类流量结合现场情况我把常见故障分成四类。第一类是最常见的DHCP广播处理问题。PXE客户端的DHCPDISCOVER广播报文会被两台Leaf同时收到但实际转发给DHCP服务器的角色可能只有其中一台。如果收到广播的那台设备没有配置DHCP中继或者它到DHCP服务器的路径不通那么这台设备进的请求就不会被转发客户端永远得不到回应。第二类是DHCP中继回程问题。客户端发出的请求到Leaf1Leaf1中继给远程DHCP服务器DHCP服务器的应答单播回给Leaf1的中继接口IP。但Leaf1在向客户端所在M-LAG接口转发时可能会因为MAC表项同步的问题把应答从Leaf2对应的M-LAG成员口发出去或者在peer-link上绕了一圈后被丢弃。第三类是TFTP/HTTP引导文件下载阶段的非对称路径问题。PXE客户端获取到TFTP服务器地址后直接向TFTP服务器发起UDP请求。如果TFTP服务器是单归的它回包给客户端时流量在某台设备上不缺转发路径但另一台设备上可能缺少对应的MAC表项或者路由信息造成回包黑洞。第四类是ARP与网关角色问题。M-LAG双活网关由两台设备共同对外提供服务但PXE客户端在裸机阶段只依赖很有限的ARP交互。如果配置或者状态同步有偏差客户端发出的ARP请求得不到回应或者回应的MAC地址和后续数据报文走的路径不一致都会让PXE异常。2.4 从PXE报错反向定位协议阶段PXE的报错码虽然简单但定位阶段非常有效。我习惯先把报错和排查方向对应起来。PXE报错/表现含义优先排查方向PXE-E51: No DHCP or proxyDHCP offers received客户端未收到任何DHCP OfferDHCP中继配置、广播处理、VLAN放通、SnoopingPXE-E32: TFTP open timeoutDHCP阶段正常但TFTP文件下载超时TFTP路径对称性、跨peer-link回程、服务器接入方式反复重启网络引导固件在多个尝试之间切换没有稳定路径覆盖上述两方面同时检查服务器网卡顺序UEFI HTTP Boot卡住走HTTP引导时无法拉取引导文件DHCP option配置、TCP路径连通性、服务端URL可达性这张表可以作为处理M-LAG场景PXE问题的起点但不能只靠报错猜测下一步必须通过命令和抓包把断点精确找出来。3. 排查流程一锤定音的五个检查点3.1 第一件事给M-LAG邻居“验身”排障第一步永远是确认M-LAG系统本身是健康的而不是一上来就去抓包。命令上可以这样查不同Comware版本输出略有差异但核心字段基本一致。display m-lag summary display m-lag verbose display m-lag keepalive重点关注这么几个状态M-LAG接口是否处于up状态peer-link是否正常工作keepalive链路是否双向可ping通系统MAC是否唯一两台设备的M-LAG成员口各自状态是不是selected。很多PXE问题表面上是协议交互失败实际上根源是peer-link故障导致的跨设备转发异常。M-LAG系统在这种状态下还能维持主机之间的普通通信因为绝大多数单播是本地转发的但PXE这种需要跨设备协作的协议会第一时间暴露问题。如果发现M-LAG系统存在邻居状态不稳定、peer-link频繁抖动不要犹豫先修完基础问题再继续排PXE否则后续所有排查都建立在沙滩上。3.2 第二件事确认DHCP报文走到了断的哪一步确认M-LAG健康之后要看DHCP交互到底进行到哪一步。常见做法是在三个点同时抓包PXE客户端接入的交换机接口侧、DHCP服务器侧、如果交换机上有中继则在中继接口上查看转发状态。在Leaf1和Leaf2的服务器接入口上抓包正常情况下应该能看到客户端的DHCPDISCOVER广播。在DHCP服务器侧抓包则能看到中继转过来的DHCPDISCOVER报文源地址为中继接口IP并携带option 82信息。如果服务器侧能收到DISCOVER但客户端侧收不到OFFER/ACK问题大概率在中继回程路径上。如果服务器侧也收不到DISCOVER那问题就出在广播处置或者中继配置上。生产环境慎用debug命令尤其是debugging dhcp relay packet这类会刷屏的命令最好在维护窗口使用或者结合抓包完成定位。3.3 第三件事配置差异对比M-LAG环境排障特别容易漏掉的一点是两台设备配置不一致。现场遇到过这样的情况只在Leaf1的VLAN接口下配了ip helper-addressLeaf2上完全没配。结果客户端广播被Leaf2接收时Leaf2根本不知道要把请求中继给谁直接丢弃。表面看起来网络完全正常因为单播流量不影响但PXE就是时好时坏。所以排查时一定要把两台设备的相关配置逐行对比。interface Vlan-interface100 ip address 192.168.100.1 255.255.255.0 ip helper-address 10.10.10.5两台设备上这个接口的IP、辅助地址、以及是否开启dhcp relay信息option插入必须完全一致。同时检查M-LAG成员口两端的链路类型、PVID、允许通过的VLAN这些一旦有偏差同样会导致广播或未知单播被丢弃。3.4 第四件事peer-link与STP状态peer-link承担着M-LAG系统内部的控制面交互和跨设备流量转发如果peer-link上放通的VLAN不完整或者存在ACL、QoS策略丢包PXE一样会出问题。检查peer-link统计计数重点看有没有持续增长的丢包计数。同时确认peer-link接口的trunk允许列表覆盖业务VLANMTU设置和成员口保持一致。STP也是容易被忽略的坑。M-LAG双归接入的服务器端口在STP视角下是跨设备聚合的成员口正常情况应该处于FORWARDING状态。如果因为STP优先级、BPDU配置等原因导致某个M-LAG成员口变成了BLOCKING或者DISCARDING状态PXE广播在那个口上是不会正常收发报文的。用display stp brief看一下M-LAG接口对应的端口状态是个很快的检查项。3.5 第五件事抓包怎么定点抓包不能瞎抓要根据故障阶段选择抓包点。如果报PXE-E51重点在DHCP Server侧抓确认DISCOVER有没有到、ACK有没有回。如果报PXE-E32重点在客户端接入侧和TFTP服务器侧双点抓包。我习惯用这样的伪抓包记录来整理思路。下面是一个典型的“配置不对称”现场看到的报文走向Leaf1 服务器接入口抓包 DHCPDISCOVER 0.0.0.0:68 - 255.255.255.255:67 正常收到 Leaf1 出口/中继转发点抓包 DHCPDISCOVER 192.168.100.1:67 - 10.10.10.5:67 正常转发 Leaf2 服务器接入口抓包 DHCPDISCOVER 0.0.0.0:68 - 255.255.255.255:67 正常收到 Leaf2 出口/中继转发点抓包 无任何转发记录这个结果一出来根因就非常清晰了客户端广播被两台Leaf都收到但Leaf2没有把请求中继出去因为中继配置在Leaf2上缺失。这种定向抓包比在交换机上反复看counters效率高得多。4. 现场处理三种典型根因和对应修复4.1 根因一DHCP中继配置不对称第一个案例的根因就是上面抓包展示的问题。Leaf1和Leaf2的VLAN 100接口配置不一致Leaf1上配了ip helper-addressLeaf2上没配置。PXE客户端双归接入时广播报文在两台设备上都会出现Leaf2收到的DISCOVER只能就地丢弃。客户端在几个周期内可能等不到DHCP响应最终报E51。修复方式很简单把两台设备的VLAN接口和中继配置改成完全一致。也可以在配置里加上中继的option 82插入能力让DHCP服务器能识别客户端具体从哪个M-LAG成员口接入便于后续基于端口做策略。interface Vlan-interface100 ip address 192.168.100.1 255.255.255.0 ip helper-address 10.10.10.5 ip dhcp relay information option enable改完配置后再做PXE复测成功率立刻恢复。这个案例给后续M-LAG规划提了个醒所有和DHCP/广播相关的配置在双活设备上必须同步下发不能只改一台。4.2 根因二广播报文被“角色分工”带偏第二个案例比较隐蔽。两台设备的配置完全一致但PXE依然间歇性失败。抓包发现客户端DISCOVER确实被中继到了DHCP服务器DHCP服务器的OFFER也回到了Leaf但部分OFFER没有从正确的M-LAG成员口发给客户端。这背后是M-LAG对广播和未知单播的角色分工逻辑在起作用。PXE客户端的广播到达两台Leaf时系统会让其中一个成员负责向接入侧转发应答另一个成员丢弃或者暂时不处理。如果DHCP服务器回应包的到达时间和客户端MAC表项同步的时机对不上应答就可能被某台设备当未知单播处理又因为本地优先转发策略没有从对端M-LAG口送出去最终客户端收不到。这个场景下更稳妥的修复是让DHCP服务器和TFTP服务器也双归接入到M-LAG系统。也就是说把部署服务器做成双网卡bond一张网卡接Leaf1另一张接Leaf2和PXE客户端一样形成一个跨设备聚合组。这样无论客户端请求从哪台Leaf进来服务端都处于同一个M-LAG系统的接入侧回程流量几乎不需要跨peer-link缓存同步和MAC学习的窗口大幅缩小。实际验证下来这种拓扑对PXE引导的稳定性提升非常明显。4.3 根因三跨peer-link访问TFTP/HTTP引导失败还有一种故障DHCP阶段完全正常客户端拿到了IP和引导文件名但下载pxelinux.0时超时。这类问题通常出在TFTP回程的非对称路径上。客户端通过Leaf1中继获取到DHCP应答而后它直接向TFTP服务器发起TFTP读请求。如果TFTP服务器单归在Leaf2侧或者它回包时路由选路走到了Leaf2但Leaf2到客户端M-LAG口的方向上没有准确的学习到客户端的MAC表项回包就会被丢弃。TFTP对这类路径不对称极其敏感因为它是无状态的UDP协议不会有TCP那样的握手、重传机制来弥补路径问题。修复建议首先是确认TFTP/HTTP服务端到客户端之间的三层路由和ARP表项是否完整在两台Leaf上分别查看客户端的MAC地址是否都有正确的出接口映射。如果表项总是在Leaf1和Leaf2之间来回迁移可以考虑在接入侧配置静态MAC或者打开M-LAG场景下的ARP/表项快速同步特性。更进一步如果部署环境支持建议优先切换到UEFI的HTTP Boot。HTTP基于TCP连接建立和状态维护远比TFTP健壮对路径有没有轻微不对称没那么敏感。互联网上很多公共云环境里的裸机自动部署也是用HTTP方式加载引导镜像原因就在这里。4.4 遇到PXE-E51/PXE-E32时我常做的三个动作处理过几轮这类问题之后我沉淀了一套最高效的现场动作顺序。第一步确认M-LAG健康状态排除基础故障第二步在两台Leaf上同步检查DHCP中继配置和DHCP Snooping信任口配置顺手把STP状态也扫一眼第三步用抓包实验锁定具体丢包点不要凭感觉猜测。如果现场没有抓包条件就直接做服务端双归接入这种“顺应M-LAG转发模型”的改造很多时候能直接治愈症状。这几个动作不一定每一步都能解决问题但能最快帮你把范围缩小。遇到紧急恢复的场景甚至可以考虑临时把服务器在接入侧改成单归接入先把业务发布出去再在维护窗口内做M-LAG的专项调整。5. 规避问题的设计建议5.1 部署层面让关键服务也双归到M-LAG棋盘上的关键棋子一定不能只踩在一个格子上。PXE链路里的DHCP服务器、TFTP/HTTP服务器就是最关键的棋子。把这些服务端全部双网卡接入M-LAG和客户端处于同一个“跨设备聚合体系”里是投入最小、收益最大的一种规避手段。服务端双归改成M-LAG接入后Leaf1和Leaf2各自都有直达服务端的链路客户端无论从哪个Leaf发起PXE请求数据面本地优先转发都能大概率做到直接到达服务端不用绕peer-link。这个拓扑能让M-LAG的各种广播处理逻辑对PXE的负面影响降到最低。5.2 安全层面DHCP Snooping与Option 82的正确姿势如果网络里因为安全要求必须开启DHCP Snooping那么在M-LAG场景下要特别注意信任口配置。正常情况下DHCP服务器上联对应的交换机口必须配置为信任口包括peer-link互联接口对端的DHCP报文交互通道也要保证不被snooping过滤。否则客户端已经发出的DHCPREQUEST会被交换机当非法报文直接丢弃DHCPACK永远回不到客户端。dhcp snooping enable interface Ten-GigabitEthernet1/0/20 dhcp snooping trust另外建议开启option 82插入便于DHCP服务器识别客户端具体接在哪台Leaf的哪个成员口上。但要注意两台Leaf对同一个双归客户端的circuit-id如果不一致DHCP服务器基于端口做策略时可能产生误判。配置的时候要在两台设备上统一规划端口标识规则避免同一客户端从Leaf1和Leaf2看到的接入标识不同。5.3 演进层面UEFI HTTP Boot更适配双活网络如果网络环境允许我把话放在这儿新的PXE部署方案里优先使用UEFI的HTTP Boot不要再用传统TFTP那一套。TFTP对UDP路径对称性要求极高M-LAG本身就是引入不对称因素的设计两者结合就是埋雷。HTTP Boot只需要DHCP阶段正确下发HTTP URL和引导服务器地址后续文件下载走TCPTCP连接建立的过程天然解决了不对称路径问题。在M-LAG双活接入场景里HTTP Boot的实际故障率比TFTP低很多。当然HTTP Boot也需要DHCP阶段不出问题所以上面所有关于DHCP中继、广播处理的排查经验依然有效。5.4 运维层面把PXE验证写进变更检查表最后一条建议比较偏运维。任何涉及M-LAG系统的变更——软件升级、M-LAG主备倒换、peer-link扩容、新增M-LAG成员口——都应该在变更验证清单里加一条“PXE启动验证”。不要等到大批服务器上线装机时才暴露问题。我的习惯是准备一台专门的测试服务器接到M-LAG系统的典型接入口上每次变更后跑一遍完整的PXE引导流程包括DHCP获取、引导文件下载、进入安装器三个阶段。这样即使M-LAG的某种转发行为在变更后发生了变化也能第一时间发现而不是在批量交付时被几十台上线任务一起压垮。处理过好几轮这类问题后我最大的感受是M-LAG虽然好用但不是堆叠它解决的问题和带来的转发行为都不一样。PXE这类引导协议恰好是最吃广播转发和路径对称性的协议所以在设计M-LAG接入方案时不能只盯着主机起来之后的连通性还要想清楚广播、DHCP、TFTP这些“非主流”流量会在两台设备之间怎么走。如果能在设计阶段就把服务端双归、Option 82和HTTP Boot这些问题考虑进去现场就能少熬几个通宵。这次H3C 6880 M-LAG场景下的PXE问题处理笔记就写到这里希望对遇到类似背景的朋友有实际帮助。