企业官网建设流程全解析

前几天在同一套网络里折腾了几乎一整天的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中继回程问题。客户端发出的请求到Leaf1，Leaf1中继给远程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的报错码虽然简单，但定位阶段非常有效。我习惯先把报错和排查方向对应起来。

这张表可以作为处理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-address，Leaf2上完全没配。结果客户端广播被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允许列表覆盖业务VLAN，MTU设置和成员口保持一致。

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-address，Leaf2上没配置。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和引导服务器地址，后续文件下载走TCP，TCP连接建立的过程天然解决了不对称路径问题。

在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问题处理笔记就写到这里，希望对遇到类似背景的朋友有实际帮助。