乐悠厨房很多做网络的朋友在配置IRF堆叠时，对LACP MAD检测总是有点绕，尤其是华三框式交换机这种高端设备上。大家通常熟悉BFD MAD，但对LACP MAD的原理和适用场景往往是半懂不懂，配置起来容易踩坑。这篇文章我就专门把LACP MAD检测这件事讲透，从原理到框式交换机上的完整配置，再到验证和排障，一次性说清楚。
1. 为什么在框式交换机上要特别重视MAD检测机制
IRF堆叠有个很经典的问题，叫做"分裂"。简单说就是两台成员设备之间的IRF物理链路断了，但设备本身还在正常运行，这时候堆叠系统就变成了两个独立的、配置完全相同的系统。如果交接机端口还处在原来配置的双活状态，就会出现两台设备抢同一批IP地址、MAC地址的情况，数据转发直接乱套，整个网络瞬间瘫痪。
为了解决这个问题，必须引入一种机制让分裂后的设备能够互相感知对方的存在，并且让其中一方主动把业务口全部关掉，只留一个管理通道。这个过程就叫MAD检测，MAD的全称是Multi-Active Detection，多active检测。
华三框式交换机支持三种MAD检测方式，BFD MAD、LACP MAD和传统ARP MAD。日常项目里BFD MAD用得最多，但LACP MAD在框式设备上有它不可替代的位置。原因在于，框式交换机往往承担着大规模汇聚或核心的角色，端口资源非常宝贵，而且经常要跟下游设备做跨设备链路聚合。这时候如果两端都启用了IRF，在跨设备聚合的链路上顺便做LACP MAD，等于把检测功能复用在了业务链路上，不用再额外占用物理端口，也不用单独跑BFD协议，逻辑上更干净。
另外，LACP MAD在框式设备上还有一个隐性的好处。框式交换机单台设备的处理能力强，板卡多、业务口多，如果分裂后靠BFD MAD的机制去down掉整机业务口，切换动作会比较剧烈。而LACP MAD是跟聚合链路联动的，分裂后聚合口协商失败，端口自然就不转发数据了，整个过程更加平滑，对下游设备的影响相对可控。
我遇到过不少项目，客户死活不想为BFD MAD单独空出两个口，尤其是框式设备上每个板卡的口都有明确规划。这种场景下LACP MAD几乎是唯一合理的选择。还有一个场景是在跨机房堆叠的架构里，IRF链路走的是长距离光纤，分裂概率比同机房堆叠高得多，这种情况下MAD检测的可靠性和快速性要求非常高，LACP MAD通过LACP报文走跨设备聚合链路检测，不依赖额外的物理链路质量，反而更稳。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. LACP MAD的工作原理与Keepalive机制拆解
2.1 LACP协议是怎么被拿来当"心跳线"用的
先理顺一个基础概念。LACP是链路聚合控制协议，标准定义在802.3ad里，它的核心作用是在两台直连设备之间协商聚合链路，把多条物理链路捆绑成一个逻辑接口。LACP报文周期性发送，默认快速率模式下是1秒发一次，这个报文叫做LACPDU。
LACP MAD的思路很巧妙，它没有在标准LACP协议里新开什么内容，而是借用LACPDU报文中的保留字段来承载IRF的Domain ID和Active ID。当两台IRF成员设备通过跨设备聚合口互联时，它们在LACPDU里携带自己的IRF编号信息。正常情况下整套IRF系统对外表现为一个整体，Active ID只有一个，对端聚合设备看到的协商结果是一致的。
一旦IRF分裂，两台设备都认为自己是Active设备，都在各自的聚合口上发送携带不同Active ID的LACPDU。对端设备原本通过聚合口跟IRF系统建立了一个聚合组，现在突然收到了来自两个不同Active ID的LACPDU，这在聚合逻辑上属于同一个系统ID出现冲突，LACP协商就失败了，聚合链路会进入异常状态。而华三的MAD机制会在此时把处于Recovery状态的那台IRF成员设备上的这个聚合口关掉，从而避免双活冲突。
2.2 MAD Down与Recovery状态的状态机切换
LACP MAD检测到分裂后，并不是简单粗暴地把所有端口都shutdown，而是由IRF系统自己判断哪台设备继续工作、哪台设备进入Recovery状态。选举规则跟BFD MAD一致，成员编号小的设备胜出，继续维持Active状态正常转发，成员编号大的那台设备进入Recovery状态，外部业务口全部处于MAD Down状态。
这里有个很关键的细节：MAD Down并不是直接把端口shutdown，而是端口处于一种特殊状态，既不是up也不是administratively down，而是被MAD机制抑制住了。你可以理解为端口物理上是通的，但报文转发路径被切断了。这样做的好处是，一旦IRF链路恢复，两台设备重新完成堆叠合并，Recovery设备上的端口会迅速恢复转发，不需要手动undo shutdown，整个收敛过程是自动的。
从检测到动作完成，整个状态机切换的链路是：IRF物理链路断开，两台设备各自发送LACPDU，对端交换设备感知到双Active ID冲突，触发LACP协商失败，IRF系统内部收到MAD检测结果，成员编号大的设备执行MAD Down，所有业务口被抑制，此时全网只有一台设备在转发数据，冲突消除。
2.3 LACP MAD在框式设备上的实现差异
盒式交换机上LACP MAD的配置比较简单，只是在一组跨设备聚合口上开启MAD检测功能。但框式交换机上有几个差异点需要特别注意。
第一个差异是跨板聚合的问题。框式交换机的聚合口可以分布在不同的业务板上，甚至IRF链路本身也可以跨板。在做LACP MAD时，建议把检测用的聚合链路分散在不同板卡上，这样即使某块板卡故障也不至于让LACP MAD完全失效。当然，这只是一种冗余设计思路，实际部署还要看端口资源和业务规划。
第二个差异是IRF物理口和逻辑口的关系。在框式设备上，IRF端口绑定的是物理接口，比如Ten-GigabitEthernet1/0/1这种，而LACP MAD检测使用的是逻辑聚合口。两者在配置上没有直接冲突，但要注意在IRF分裂场景下，如果IRF物理口所在的板卡也挂了，那LACP MAD检测同样会失效。所以严格来说，LACP MAD只负责检测IRF链路异常，不负责处理板卡级别的故障。
第三个差异是版本兼容性。华三框式交换机不同型号、不同软件版本对LACP MAD的支持情况略有区别，老版本上有些聚合口不支持开启MAD检测。配置前一定要确认设备的软件版本，并且确认跨设备聚合功能已经正常配置。
3. 框式交换机LACP MAD的完整配置实例
3.1 配置前的组网规划与设备情况
假设现在的组网场景是两台华三框式交换机做IRF堆叠，型号是S10500系列（这系列在园区核心和数据中心汇聚用得非常普遍），两台设备分别命名为SW1和SW2，通过IRF物理链路组成一个堆叠系统。下游接了一台汇聚交换机或服务器接入设备，通过跨设备聚合跟IRF系统互联。
规划如下：
- IRF成员编号：SW1为成员1，SW2为成员2
- IRF物理链路：SW1的Ten-GigabitEthernet1/0/1和Ten-GigabitEthernet2/0/1分别对接
- 跨设备聚合链路：SW1的Ten-GigabitEthernet1/0/2和SW2的Ten-GigabitEthernet2/0/2聚合成一个聚合口，连接下游设备
- 在这个聚合口上开启LACP MAD检测
这个组网的核心是，跨设备聚合口同时承担两类任务：一是承载业务流量，二是作为MAD检测的载体。
3.2 逐步配置命令详解
第一步，配置IRF成员编号和优先级。在框式设备上这个配置建议在初始化阶段完成，避免后期改动IRF编号造成不必要的麻烦。
code复制[SW1] irf member 1 priority 32
[SW2] irf member 2 priority 1
优先级高的设备在IRF合并时更有机会成为Master，这里把SW1设为32，SW2保持默认1，确保正常情况下SW1是主设备。
第二步，创建跨设备聚合口。在华三框式设备上，跨设备聚合需要先把聚合接口的跨设备属性打开。V7版本上有专门的命令。
code复制[SW1] interface Bridge-Aggregation 10
[SW1-Bridge-Aggregation10] link-aggregation mode dynamic
[SW1-Bridge-Aggregation10] mad enable
注意，这里的mad enable是整个LACP MAD配置的核心，就是在这条聚合口上开启MAD检测功能。
第三步，把物理口加入聚合组。SW1侧加入成员口：
code复制[SW1] interface Ten-GigabitEthernet1/0/2
[SW1-Ten-GigabitEthernet1/0/2] port link-aggregation group 10
SW2侧加入成员口：
code复制[SW2] interface Ten-GigabitEthernet2/0/2
[SW2-Ten-GigabitEthernet2/0/2] port link-aggregation group 10
完成之后，跨设备聚合就建立起来了。同时MAD检测也在这个聚合组内生效。
第四步，配置IRF Domain ID。IRF Domain ID是用来隔离不同IRF系统的，防止多个堆叠系统之间的LACP报文互相串扰。这个ID必须在两台成员设备上配置一致。
code复制[SW1] irf domain 10
[SW2] irf domain 10
第五步，进入聚合口视图，把MAD检测真正挂上去。前面在Bridge-Aggregation10视图下的mad enable其实已经生效了，但有些项目为了更稳妥，还会在物理口上也做一次确认。这一步主要是检查配置，不是必须的操作。
第六步，如果下游设备也支持LACP MAD检测，那么下游设备上也需要配置相应的MAD检测功能。以华三设备作为下游为例，同样是在跨设备聚合口上开启mad enable。如果下游不是华三设备，也没关系，LACP MAD的检测本身就是基于标准LACP报文实现的，只要对端支持LACP协商，检测机制就能正常工作。
3.3 配置完成后必须做的检查项
配置完成后，不要急着收工，先做几个必要的检查。
第一，检查IRF堆叠状态是否正常：
code复制display irf
确认两台设备已经形成堆叠，成员编号、优先级、Role都符合规划。
第二，检查聚合口状态：
code复制display link-aggregation verbose
确认Bridge-Aggregation10下的成员口都处于Selected状态，聚合口状态是UP。
第三，检查MAD检测配置是否生效：
code复制display mad verbose
这个命令会显示MAD检测的方式、状态、检测到的冲突情况等信息。状态为Normal说明MAD检测一切正常。如果这里显示的状态不是Normal，就说明配置有问题，需要排查。
4. 配置过程中的难点与易踩的坑
4.1 IRF物理链路必须是独立的直连链路
这是做IRF配置时最容易忽略的点。IRF链路必须是两台设备之间独立的物理直连链路，不能经过其他交换机中转，而且这条链路不能跟业务聚合链路混在一起。原因非常简单，IRF链路承载的是堆叠控制报文和数据转发报文，如果它跟业务流量共享链路，一旦出现拥塞或中断，堆叠系统自身就不稳定，MAD检测的可靠性也大打折扣。
从MAD检测的角度来看，LACP MAD的检测报文是走业务聚合口的，IRF链路走的是独立的堆叠口。如果IRF链路本身跟LACP MAD检测链路有交叉依赖，分裂时可能出现检测报文找不到出口的情况，导致MAD机制失效。我在项目里见过有人为了省光纤，把IRF链路和跨设备聚合链路走同一根光纤，结果割接演练时一拔光纤，两台设备直接分裂而且MAD没触发，全网故障。这种低级错误一定要避免。
4.2 跨设备聚合必须使用动态LACP模式
LACP MAD检测依赖LACP协议报文，所以聚合口必须配置为动态聚合模式，也就是mode dynamic。如果配成了静态聚合，LACP报文不会正常协商，MAD检测完全无法工作。
这是配置中非常容易踩的坑。很多人习惯在服务器接入场景用静态聚合，觉得简单稳定，但在做LACP MAD时这行不通。静态聚合模式下，聚合链路不发送LACPDU报文，MAD检测机制无从感知对端状态，检测功能形同虚设。
4.3 MAD检测报文对 VLAN 的依赖
华三的LACP MAD检测在框式设备上有个细节，就是检测报文需要在一个指定的VLAN中转发。默认情况下，LACP报文在聚合口所属的VLAN中传输。如果聚合口配了Trunk口，并且trunk的PVID跟预期不一致，就可能出现LACP报文被丢的情况。
我在配置时习惯在聚合口上把PVID固定到一个专门的VLAN，并在该VLAN内不跑任何业务流量，这样能有效避免LACP报文被业务VLAN里的广播风暴影响。虽然LACP报文是组播报文，正常情况下不会被丢弃，但带宽压力大的时候延迟增加也会影响检测速度。测过一次，在核心设备CPU利用率超过60%的情况下，LACP MAD的检测延时可以拉到秒级，这是不可接受的。
4.4 IRF Domain ID必须全局唯一
IRF Domain ID的作用前面提过，是隔离不同的IRF系统。如果网络里有多个华三IRF堆叠系统，它们的IRF Domain ID必须配置为不同值，否则LACP MAD的报文会在多个堆叠系统之间互相干扰。
更严重的情况是，如果两个IRF系统的Domain ID相同，且它们的跨设备聚合链路通过某种方式相连，系统会误判为同一个IRF发生了分裂，从而错误触发MAD检测，导致业务口被误down。这个坑在大型园区网里并不少见，尤其是多个堆叠系统改造时，配置人员直接套用模板，忘了改Domain ID。
4.5 框式设备上MAD检测口和业务口要合理规划
框式设备端口多、板卡多，在设计LACP MAD时建议把MAD检测口分布在不同板卡上，避免单板故障导致检测功能失效。同时，跨设备聚合链路最好用高带宽的口，比如40GE或100GE，这样既能承载业务流量，又能保证LACP报文的转发优先级。
我在设计规范里一般会加一条硬性要求：跨设备聚合链路的总带宽建议是单台设备上行业务带宽的1.5倍以上。原因很简单，IRF分裂后的Recovery设备端口被MAD Down，所有流量都会压到Active设备的下行链路上，如果下行链路带宽不够，业务直接拥塞，MAD检测做得再好也没用。
5. 验证LACP MAD检测功能的实操方法与常见故障排查
5.1 如何在不影响业务的情况下做MAD检测演练
配置完成不代表万事大吉，一定要实际验证MAD检测在分裂时能正确动作。最直接的方式是拔出IRF链路的光纤或网线。这个操作会瞬间切断两台设备的堆叠连接，触发分裂。
操作步骤如下：
- 拔掉IRF物理链路
- 等待几秒钟，观察两台设备的IRF状态，确认已经分裂为两个独立的IRF系统
- 在成员编号大的设备上执行
display mad verbose，确认状态变为Recovery - 执行
display interface brief，查看业务口状态，确认状态为MAD Down - 在成员编号小的设备上执行
display interface brief，确认业务口仍然正常转发 - 重新插回IRF链路，等待堆叠合并
- 再次执行
display mad verbose，确认状态恢复为Normal - 确认Recovery设备端口自动恢复转发状态
这套验证流程是割接前的必做项目。如果演练过程中MAD没有生效，千万不能上线，必须排查修复后再做一次演练。
5.2 分裂后对端设备聚合口的状态怎么判断
当IRF分裂后，Active设备上的跨设备聚合口仍然是正常工作状态，对端设备感知到的是一个正常的聚合链路。Recovery设备上的跨设备聚合口由于MAD Down机制被抑制，对端设备感知到这条链路已经Down掉，聚合组里这个成员口会变成Unselected状态。
通过对端设备执行display link-aggregation verbose可以清楚看到这个变化。如果对端设备是华三的，会看到成员口的状态从Selected变为Unselected，聚合组可用成员口减少。这个过程验证了LACP MAD不仅抑制了Recovery设备本身，还通过LACP协商让对端感知到了链路异常。
5.3 常见故障排查与修复方法
故障现象一：配置完成后MAD检测一直不生效。首先检查IRF Domain ID是否一致，不一致就改。然后检查聚合口是否动态模式，确认无误后查看display mad verbose的输出，看是否有报错信息。如果输出显示MAD检测方式为None，说明mad enable没有正确配置，重新配置一次再验证。
故障现象二：分裂后两台设备都在转发数据，MAD没有触发。这种是最危险的故障。检查思路是先确认IRF有没有真正分裂，执行display irf看成员状态。如果确实分裂了但MAD没触发，多半是LACP报文协商异常，在聚合口上抓包看看LACPDU报文中是否携带了正确的IRF信息。重点检查聚合口是否被配置了静态聚合模式。
故障现象三：IRF链路恢复后，Recovery设备端口不自动恢复。执行display mad verbose确认状态是否从Recovery变回Normal。如果状态已经恢复但端口没起来，手动执行undo shutdown临时恢复端口，同时检查是否有其他配置因素导致端口被hold住。华三的MAD机制在状态恢复后会自动释放端口，但有时候板卡异常会导致端口状态卡住，重启板卡或者重插板卡可以解决。
故障现象四：聚合口反复震荡。这通常是因为IRF链路质量不稳定，MAD检测频繁触发又快速恢复。先查IRF链路的物理层状态，重点是光功率和误码率。如果光模块老化导致光功率处于临界值，IRF链路会间歇性中断，MAD检测必然频繁动作。这种问题换光模块和尾纤即可解决，不需要动配置。
5.4 从实战角度看LACP MAD与其他MAD检测的取舍
很多网络工程师在项目初始设计时喜欢把BFD MAD和LACP MAD都配上，觉得双保险更可靠。但我不建议这么做。两种机制同时配置虽然华三设备支持，但复杂的联动逻辑会带来不必要的运维成本，而且一旦发生分裂，两套MAD机制可能同时动作，对端口状态的切换控制容易出现竞争。
一般情况下，推荐按以下原则选择：如果核心设备之间有专门的互联物理口，用BFD MAD，检测速度快、逻辑简单；如果核心设备与下游设备之间本身就有跨设备聚合的需求，优先考虑LACP MAD，省端口省配置；如果对可靠性要求极高，可以一组用LACP MAD做检测，同时保留BFD MAD做冗余，但必须在实施前做完整的验证测试。
我个人在框式交换机项目里用得最多的是LACP MAD，因为框式设备的核心场景就是大二层汇聚，跨设备聚合几乎必然存在。在跨设备聚合上顺势开MAD检测，整个组网逻辑非常顺，运维排障也直观。BFD MAD虽然好用，但为它专门预留物理口在框式设备上往往需要额外的板卡投资，成本上不划算。
最后分享一个经验，MAD检测不管用哪种方式，都需要在验收时做一次真正的分裂演练，不要只停留在配置层面。演练能发现的问题往往比理论分析多得多。光模块老化、板卡隐性故障、IRF链路单点瓶颈，这些都是实战中真实遇到的坑，只有切掉链路做演练才能暴露出来。交付给客户之前多做几次演练，运维阶段的故障就少很多。