Nicholas Qin先讲一个我半夜被叫起来的经历。客户机房两台S5560-54S做了IRF堆叠，跑了大半年一直很稳，结果某天晚上一台设备的光模块闪断，堆叠链路断了几秒。按理说堆叠链路短暂中断，等它自动恢复也就过去了，但偏偏那次恢复失败，两台设备各自为政，都认为自己是Master，同时转发流量。紧接着网络里开始广播风暴、MAC地址疯狂漂移，核心业务全断。我赶到现场一看，执行display irf，两台设备的成员编号都显示为一，瞬间就明白了——这套堆叠压根没配MAD检测。今天这篇文章就以这个教训开头，完整讲透华三盒式交换机IRF堆叠中BFD MAD检测的配置方法、验证手段和我在大量现场积累的避坑经验，正好作为华三盒式交换机IRF堆叠配置系列的第一篇。如果你是刚接触IRF的网工，或者堆叠已经上线但没配MAD，这篇文章值得看完。
1. 为什么IRF堆叠必须搭配MAD：先聊聊那段“半夜拔线”的教训
1.1 堆叠分裂后，为什么会全网瘫痪
IRF把两台物理设备虚拟成一台逻辑设备，听着很美，但它有一个天然弱点：一旦堆叠链路中断，两台设备之间的协商机制就失效了。如果没有MAD（Multi-Active Detection，多Active检测）机制兜底，两台设备都会认为自己是唯一的主设备，继续转发流量。问题在于，整个网络里网管、网关、下联设备看到的是两台“都想当家做主”的交换机，它们同时响应ARP、同时发送协议报文，最终结果就是MAC地址在两个端口之间反复横跳，广播报文成倍扩散，形成广播风暴。
我处理过不止一起这类故障，特征非常明显：设备CPU飙升、生成树反复震荡、业务时通时不通。很多人以为是交换机硬件坏了，其实原因只有一个——堆叠分裂后没有触发MAD降级。说得直白一点，IRF堆叠就像两个人搭伙过日子，平时协同挺好，但一旦闹掰了，必须有一套规则决定谁继续用这个家，另一个人闭嘴退出。MAD就是这套规则。
1.2 MAD检测的三种流派，为什么盒式交换机首选BFD
华三在Comware平台提供了三类MAD检测方式，分别是BFD MAD、LACP MAD和VRRP MAD。我做了个对比表格，方便你选型：
| 检测方式 | 依赖资源 | 检测速度 | 配置复杂度 | 盒式交换机适用性 |
|---|---|---|---|---|
| BFD MAD | 一个专用VLAN + 三层接口 + 独立检测链路 | 毫秒级 | 中等 | 最推荐，主流方案 |
| LACP MAD | 跨设备二层聚合链路 | 依赖聚合链路状态 | 较低 | 有跨设备聚合时可以顺带配 |
| VRRP MAD | 三层接口 + VRRP组 | 较慢，依赖VRRP状态 | 较高 | 老款设备或特殊场景才用 |
对于S5560、S5130、S6520这类盒式交换机，我几乎全部使用BFD MAD。原因很简单：检测速度快，不依赖已有的业务聚合链路，配置直观，资源开销也不大。LACP MAD的问题在于它必须依托跨设备聚合链路，如果聚合链路本身断了，检测也就失效了，而盒式交换机不一定每一台都天然具备这种条件。VRRP MAD需要额外维护VRRP状态，在接入/汇聚场景引入不必要的复杂度。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. BFD MAD的检测原理：它怎么知道“对面还活着”
2.1 BFD本来是用来干什么的
BFD（Bidirectional Forwarding Detection，双向转发检测）是一个标准的快速故障检测协议，最初就是为了给OSPF、BGP这些路由协议提供毫秒级的链路状态感知。传统路由协议靠Hello报文发现邻居故障，速度慢且依赖路由协议本身，BFD则可以独立运行，在任意两层或三层链路上快速检测双向转发路径是否可用。MAD借用了BFD的这套机制，只是它检测的不是路由邻居，而是IRF成员设备之间的“健康状况”。
你只需要记住一个关键点：BFD MAD的BFD会话建立在各成员设备的MAD IP之间，链路状况通过BFD周期性发送的检测报文反馈。一旦BFD会话断开，就说明成员之间失去了正常通信能力，此时就需要触发MAD竞选机制。
2.2 MAD IP与VLAN接口的关系
这里有一个比较容易绕晕的概念，我单独拎出来讲。BFD MAD配置时，你会看到vlan-interface下面有一个普通IP地址，后面还跟着两条mad ip address命令。普通IP是该VLAN接口的主IP，是所有成员设备共享的逻辑地址。而mad ip address才是真正属于每个成员设备的“身份证”，格式通常是mad ip address X.X.X.X 24 member 1、mad ip address X.X.X.X 24 member 2，每个成员各配一个。
进入IRF正常状态后，外部访问这个VLAN接口的IP走的是主IP，成员之间的BFD会话则走各自的MAD IP。这个过程有一点点像办公室的总机和分机，外面打总机电话有人接，内部同事之间用分机号互相拨打。配置时必须保证主IP和MAD IP在同一网段，同时MAD IP不能与主IP冲突，更不能两个成员配同一个MAD IP，否则BFD会话根本无法建立。
2.3 分裂后的收敛过程：谁进Recovery，谁继续干活
当堆叠正常时，BFD会话保持Up状态，两台设备相安无事。一旦堆叠链路断开，成员之间失去通过堆叠口协商的能力，同时BFD MAD检测链路如果还能通，那么MAD IP之间的BFD会话会先维持一段时间；如果检测链路也断了，BFD会话立即Down，MAD机制随即启动竞选。
竞选的规则其实很简单：IRF优先级高的成员胜出，优先级一样则成员编号小的胜出。胜出的成员继续担任Master，维持所有业务转发；失败的成员进入Recovery状态，自动关闭除MAD检测VLAN端口以外的所有业务端口，让它们不再转发任何业务数据。这个动作很关键，等于给“失败方”直接按下了静音键，彻底避免双主同时转发引发的广播风暴。
链路恢复后，进入Recovery状态的成员不会自动重新加入堆叠，需要人工干预。最常用的做法是在它身上执行mad restore命令，让它重新以成员身份加入现有堆叠。如果你想让它彻底归队，也可以直接重启这台设备。我个人的建议是优先用mad restore，毕竟重启会造成整台设备的业务中断。
3. 部署前的物理与逻辑规划：连线怎么走，VLAN怎么设计
3.1 硬件选型与物理连线规划
以S5560-54S为例，这款产品默认最后几个万兆口是预留的IRF物理口。规划物理连线时，我强烈建议每台设备至少使用两根万兆光纤做堆叠口，采用交叉连接方式：设备A的49口对设备B的50口，设备A的50口对设备B的49口。这样做的好处是哪怕其中一根光纤或一个光模块出问题，堆叠仍然能维持运行，不至于动不动就全断。
MAD检测链路则独立于堆叠链路。你可以从每台设备上各挑一个千兆电口或者万兆口直连，也可以让两台设备分别接入同一台二层接入交换机，只要保证MAD检测VLAN在两端二层互通就行。我更推荐直连方式，减少中间节点故障的干扰。这里要特别强调：MAD检测链路和堆叠链路必须走不同路径，否则堆叠链路断的时候，MAD链路大概率也断了，MAD根本来不及检测，等于白配。
3.2 IRF参数规划表
动手敲命令之前，先把规划表做好。我一般会在交付文档里放这样一张表，后续维护和排障都方便：
| 项目 | 设备A | 设备B |
|---|---|---|
| 设备型号 | S5560-54S | S5560-54S |
| IRF成员编号 | 1 | 2 |
| IRF优先级 | 32 | 1 |
| IRF堆叠口 | Ten-GigabitEthernet1/0/49、1/0/50 | Ten-GigabitEthernet2/0/49、2/0/50 |
| MAD检测口 | GigabitEthernet1/0/26 | GigabitEthernet2/0/26 |
| MAD检测VLAN | VLAN 4092 | VLAN 4092 |
| VLAN接口主IP | 172.16.0.1/24 | 172.16.0.1/24 |
| MAD IP | 172.16.0.2/24（member 1） | 172.16.0.3/24（member 2） |
| IRF域编号 | 10 | 10 |
这里提一句，IRF域编号很多人忽略。如果你的网络里只有一套IRF，默认domain 0也能跑，但为了防止未来扩容时两套堆叠的MAD报文互相干扰，我习惯在开局阶段就显式配置irf domain 10。
3.3 MAD检测VLAN与检测链路设计
MAD检测VLAN必须是专用VLAN，这个原则我在现场强调过无数遍。它不能承载任何业务流量，不能配置DHCP、不能接终端，甚至连管理流量都尽量避免。原因在于，BFD MAD依赖这个VLAN内的BFD会话状态，如果里面混入广播报文、环路流量，很容易干扰检测结果。我通常选4092这种VLAN号，一是默认不会有业务用到，二是在显示上容易辨认。
端口层面，MAD检测端口必须配置为access口，不能是trunk或hybrid。如果你当前端口是trunk模式，记得先改成access再划入VLAN。另外，MAD检测VLAN需要所有成员设备上都存在，并且每个成员对应的检测端口都要加入，少了任何一台都不行，否则BFD会话就建立不起来。
4. 完整配置实操：两台S5560从零到堆叠
4.1 设备A：成员编号与IRF端口配置
以下配置基于Comware V7，S5560、S5130、S6520等盒式系列基本通用。先用console线分别连接两台设备，确保在独立状态下操作。
先配置设备A。新设备默认成员编号就是1，不需要改动，直接设置优先级并绑定IRF端口：
code复制system-view
[H3C] irf member 1 priority 32
[H3C] irf domain 10
[H3C] interface ten-gigabitethernet 1/0/49
[H3C-Ten-GigabitEthernet1/0/49] shutdown
[H3C-Ten-GigabitEthernet1/0/49] quit
[H3C] interface ten-gigabitethernet 1/0/50
[H3C-Ten-GigabitEthernet1/0/50] shutdown
[H3C-Ten-GigabitEthernet1/0/50] quit
[H3C] irf-port 1/1
[H3C-irf-port1/1] port group interface ten-gigabitethernet 1/0/49
[H3C-irf-port1/1] port group interface ten-gigabitethernet 1/0/50
[H3C-irf-port1/1] quit
[H3C] irf-port-configuration active
这里有两步操作值得解释。第一步，把即将用于IRF的物理口shutdown，是Comware V7的安全机制，避免在配置过程中接口意外产生流量；第二步，irf-port 1/1中的“1/1”表示成员1的IRF端口1，它和后面设备B的irf-port 2/2形成逻辑配对。激活后，如果物理口还处于shutdown状态，手动执行undo shutdown把它打开。
4.2 设备B：改编号、配IRF端口、激活堆叠
设备B的配置分两个阶段。第一阶段先把默认的成员编号1改成2，否则两台设备都是member 1，堆叠根本合不拢：
code复制system-view
[H3C] irf member 1 renumber 2
系统会提示确认，输入Y。这个操作必须重启后才会真正生效，所以先保存配置再reboot：
code复制<H3C> save force
<H3C> reboot
设备B重启完成后，你会发现所有接口编号都变成了2/0/x，比如原来的GigabitEthernet1/0/1现在叫GigabitEthernet2/0/1。这个变化非常关键，意味着你在设备B上原有的端口配置几乎全部失效。所以如果设备B不是全新设备，而是已经承载业务的，改成员编号前一定要导出配置，评估影响。
重启完成后，继续配置设备B：
code复制system-view
[H3C] irf member 2 priority 1
[H3C] irf domain 10
[H3C] interface ten-gigabitethernet 2/0/49
[H3C-Ten-GigabitEthernet2/0/49] shutdown
[H3C-Ten-GigabitEthernet2/0/49] quit
[H3C] interface ten-gigabitethernet 2/0/50
[H3C-Ten-GigabitEthernet2/0/50] shutdown
[H3C-Ten-GigabitEthernet2/0/50] quit
[H3C] irf-port 2/2
[H3C-irf-port2/2] port group interface ten-gigabitethernet 2/0/49
[H3C-irf-port2/2] port group interface ten-gigabitethernet 2/0/50
[H3C-irf-port2/2] quit
[H3C] irf-port-configuration active
这里设备B的IRF端口为什么是2/2而不是2/1？因为设备A用的是IRF端口1，设备B必须用IRF端口2与之形成一对，这是固定配合关系，不能随便改。
4.3 保存配置与重启合并的细节
两台设备都配置完成后，建议先别急着插光纤，先把配置保存好，再做一次完整重启让它们合并。我的标准操作顺序是：先重启设备B，等它起来后，再重启设备A。为什么要这个顺序？因为设备A优先级高、成员编号小，让它作为后启动的一方在IRF协商中更稳地成为Master，避免双方同时抢主导致合并异常。
设备A重启前，把两根堆叠光纤按照交叉方式连接好。设备A启动过程中，两台设备会通过IRF端口互相发现、协商，最终合并成一台逻辑设备。你可以在任意一台的console口看到提示，也可以通过display irf确认两台设备的成员编号是否同时出现。合并完成后，用save force保存一次，务必确保IRF状态和配置一起固化下来。
4.4 在堆叠系统上配置BFD MAD检测
IRF堆叠形成后，接下来的BFD MAD配置都在堆叠系统上进行，不需要再区分物理设备A还是设备B。先创建MAD检测VLAN：
code复制system-view
[H3C] vlan 4092
[H3C-vlan4092] quit
然后把两台成员设备上的MAD检测口都划入这个VLAN。这里注意接口编号前带了成员号1和2，表示这是不同成员设备上的物理口：
code复制[H3C] interface gigabitethernet 1/0/26
[H3C-GigabitEthernet1/0/26] port link-type access
[H3C-GigabitEthernet1/0/26] port access vlan 4092
[H3C-GigabitEthernet1/0/26] quit
[H3C] interface gigabitethernet 2/0/26
[H3C-GigabitEthernet2/0/26] port link-type access
[H3C-GigabitEthernet2/0/26] port access vlan 4092
[H3C-GigabitEthernet2/0/26] quit
接下来配置VLAN接口和BFD MAD：
code复制[H3C] interface vlan-interface 4092
[H3C-Vlan-interface4092] ip address 172.16.0.1 24
[H3C-Vlan-interface4092] mad bfd enable
[H3C-Vlan-interface4092] mad ip address 172.16.0.2 24 member 1
[H3C-Vlan-interface4092] mad ip address 172.16.0.3 24 member 2
[H3C-Vlan-interface4092] quit
[H3C] save force
如果你执行mad bfd enable后系统提示需要先配置MAD IP，那就调整顺序，先配置两条mad ip address，再执行mad bfd enable。不同版本行为略有差异，但最终效果一样。配置完成后，可以用display this查看VLAN接口下是否同时存在主IP和两条MAD IP。
5. 验证与模拟故障：配完了不验证等于没配
5.1 display命令如何看状态
配置完成后，我会按顺序执行下面几条命令确认状态。第一条是display irf，查看成员设备和主备角色：
code复制<H3C> display irf
MemberID Role Priority CPU-Mac Description
*+1 Master 32 xxxx-xxxx-xxxx ---
2 Standby 1 xxxx-xxxx-xxxx ---
带*号的是当前设备，带+号的是Master。如果只有一台设备显示出来，说明堆叠没有合拢，赶紧查堆叠线和端口配置。第二条是display mad verbose：
code复制<H3C> display mad verbose
MAD BFD enabled.
Vlan-interface: 4092
MAD IP address: 172.16.0.2
Member 1: 172.16.0.2
Member 2: 172.16.0.3
MAD status: Normal
MAD status显示Normal，说明当前MAD状态正常，两台设备协同工作。如果显示Recovery，说明某台设备已经被降级，业务端口被自动关闭。我还习惯再看一眼BFD会话：
code复制<H3C> display bfd session
Total Session Num: 1
正常情况下应该能看到一条状态为Up的BFD会话，说明MAD链路是通的。如果这里没有任何会话，查MAD检测VLAN的端口是否都正确加入，以及两台设备之间的检测链路是否连通。
5.2 拔线测试：观察MAD收敛与恢复
我有一个工作习惯，凡是交付IRF项目，只要客户同意，我都要在维护窗口内做一次实际的拔线演练。步骤很简单：预先在一台设备上开两个终端窗口，一个持续ping核心网关地址，另一个盯着display mad verbose。然后拔掉一根堆叠光纤，观察现象。
正常情况下，由于还有另一根堆叠光纤在工作，堆叠链路不会完全断开，BFD会话不会Down，ping也不会中断。如果这时MAD误报了，说明配置有问题，需要排查。接下来把所有堆叠光纤都拔掉，模拟彻底分裂。此时你会看到存活的那台设备MAD状态保持Normal，业务正常；被隔离的设备MAD状态变成Recovery，业务端口全部被shutdown。这意味着MAD正确发挥了作用，两台设备没有同时抢主。
验证完毕后重新接回堆叠光纤，在Recovery状态的设备上执行mad restore，让它重新加入堆叠，然后再次确认display irf和display mad verbose都恢复正常。这个过程虽然简单，但你亲手做一次，对MAD的理解会完全不一样。
5.3 MAD生效后的自动化运维检查清单
堆叠和MAD上线后，我建议把状态巡检加入日常运维脚本或监控平台。至少每季度检查一次以下内容：
- display irf中成员设备是否全部在列，角色是否稳定
- display mad verbose中的MAD状态是否为Normal
- 堆叠口的光模块收发光功率是否在正常范围
- MAD检测VLAN内是否存在业务流量，端口是否仍为access模式
- 各成员设备的配置是否一致，特别是VLAN接口下的MAD IP
这些指标最好接入告警系统，比如MAD状态一旦变成Recovery就要立刻告警，因为那意味着业务已经受到影响了。
6. 实战中的坑与经验：几百台设备换来的教训
6.1 MAD检测VLAN被业务流量污染
这个坑我见过不止一次。有些同事图省事，把MAD检测VLAN选成了VLAN 1，或者把业务口也划进了MAD检测VLAN，结果这个VLAN里既跑检测流量又跑业务广播，BFD报文发送间隔和检测结果都被干扰，严重时会误判堆叠分裂。MAD检测VLAN一定要留成专用VLAN，VLAN 4092这类地址又靠后又不常用，再好不过。所有成员设备上除了那两三个检测口，其他任何端口都不能属于这个VLAN。
6.2 MAD检测链路与堆叠链路同路径失效
如果你把MAD检测链路和堆叠链路接在同一台接入交换机、甚至同一根光纤里，那这个MAD基本等于白配。物理路径完全重复，堆叠断了MAD也断了，BFD会话收不到对端报文，设备根本无法区分“堆叠故障”和“MAD链路故障”。规划时务必让检测链路走独立的物理路径。如果你有两台接入交换机做冗余，MAD检测口可以分别接到不同接入交换机上，同时确保VLAN 4092在中继链路上是放行的。
6.3 成员编号规划影响接口编号
成员编号一旦定了，就影响这台设备上所有物理接口的编号。比如设备B如果一开始用member 2，那它的1口就是GigabitEthernet2/0/1，等堆叠上线后再想调整成员编号，几乎等于把设备B的接口全部重命名一遍，原有配置全部要重写。所以规划成员编号时一定要考虑未来扩容，给新设备预留足够的编号空间。我一般在两框堆叠时习惯用1和2，未来如果扩到四框，再用3和4。改编号最好的窗口是开局阶段，设备还没承载业务的时候。
6.4 配置保存与重启顺序的连锁问题
还有一次故障让我印象很深：某现场改了IRF优先级后没有保存配置，后来设备异常重启，优先级自动回到默认值，原本该当Master的设备变成了备机，导致下游网关地址漂移了几分钟。从那以后我给自己定了一个规矩，任何涉及IRF的变更，改完立刻save force。重启顺序也一样重要，两台上电时如果恰好同时进入协商，可能出现短暂的分裂现象，虽然最终会收敛，但过程中会产生不必要的告警。规范的做法是确定一个明确的Master设备，让它最后起来，其它成员先起来等待。
6.5 不同型号盒式交换机的命令差异
最后提醒一点，S5560、S5130、S6520这些盒式交换机虽然都跑Comware V7，但不同型号的IRF物理口位置和支持的堆叠数量可能不同。有的型号支持最多4台堆叠，有的只支持2台；有的型号IRF口是专门的万兆口，有的则要求用前几个SFP+口。配置前务必翻一下对应设备的版本说明书，确认IRF物理口范围和命令格式。如果你用的是HCL模拟器做实验，IRF配置逻辑和真实设备一致，但模拟器偶尔会因为虚拟网卡或内存问题导致堆叠合并失败，这属于环境问题，不是你配置写错了，换个版本或者重新启动拓扑通常能解决。
做网络这行，我一直认为可靠性不是靠堆功能堆出来的，而是靠对边界情况的预判和验证。IRF与BFD MAD最大的价值不是让你在分裂时“赢”，而是让系统在异常情况下自动选择一台继续工作，另一台果断退出。如果你现在机房里有已经上线但没配MAD的堆叠设备，我建议你尽早找一个维护窗口，把MAD检测补上，并顺手做一次拔线演练。等真出了事故再补，代价就是业务中断和半夜出差的疲惫。