1. 先搞清楚三个名字背后的真实含义
干网络这一行，链路聚合、堆叠、集群这三个词你肯定绕不开。但很多人刚接触时容易混，觉得它们不都是“把多个东西合在一起用”吗？还真不是一回事。我的理解是这样的：这三者解决的根本问题各不相同，链路聚合解决的是“链路带宽不够用”，堆叠解决的是“单台设备能力不够用”，集群解决的是“两台设备想要协同工作但又不能互相拖累”。
先说链路聚合。它做的事情很朴素：把交换机上多个物理端口绑成一个逻辑端口，比如把两个千兆口绑成一个逻辑上的2000M口。这就像把两根水管并在一起，流量可以同时从两根管子里走，带宽翻倍。但它的核心价值不只是带宽，更重要的是冗余——如果其中一根管子裂了，另一根还能顶上，业务不断。
再说堆叠。堆叠是把几台物理交换机通过专用的堆叠口或普通光口连起来，形成一个逻辑上的单一设备。对外看，它就是一台交换机，管理地址只有一个，配置文件共享，转发面也统一。这对中小型网络特别友好，因为可以用几台便宜的盒式交换机拼出一台“高配框式交换机”的效果。
集群技术则更高一层。它通常指两台框式交换机（或者两台能力很强的设备）通过交换网板之间互连，把控制平面和转发平面都协同起来。但和堆叠不太一样的是，集群往往强调跨设备的链路捆绑、跨设备的统一管理，同时在设备间做故障隔离，避免一台设备坏了把另一台也带崩。
所以简单粗暴地记：链路聚合是“多链路合一”，堆叠是“多设备合一”，集群是“多控制引擎合一但也有分离”，它们的共同点是都能提升带宽和可靠性，但应用场景和配置方法完全不同。
2. 为什么需要这些技术？场景驱动选型
2.1 带宽瓶颈从哪来
很多刚接触组网的朋友有个疑惑：我现在交换机上联口用了一个千兆，感觉也够用啊，为什么要做链路聚合？这个问题得分业务看。如果你只是带几十台电脑跑跑网页，千兆上联大概率够。但一旦有监控视频流量、虚拟机迁移、跨交换机的大规模备份，或者多个终端同时向内网服务器发起大流量访问，单条物理链路的带宽马上会被打满。
我给你一个实际计算例子。一台24口千兆交换机，每个接入端口都跑满100M，向下汇聚的流量就有2.4G，而它的上联口如果只有1G，那就会丢包。即便真实场景不会全部同时跑满，但只要监控流量加办公流量一起涌上来，1G上联经常超过80%就很危险了。这时最便宜的方案就是加一根网线，把两个千兆口做链路聚合，上联变成2G，成本就是一根线而已。
带宽需求是动态的，不是一个固定值。做链路聚合之前我习惯先看端口流量曲线，如果单个上联口在高峰时段利用率超过60%，就提前考虑聚合。别等到CPU告警、丢包率飙升再动手，那时候排查问题很被动。
2.2 可靠性要求：链路冗余与设备冗余
链路聚合解决的是链路冗余。一条物理链路断了，流量自动切换到另一条，用户几乎无感知。但链路冗余解决不了“交换机整个挂了”的问题。你下联的几十台电脑，上联口再多，只要交换机本身宕机，业务就全断了。这时候需要设备级冗余，也就是堆叠或者集群。
这里有个常见误区：有人觉得堆叠之后，如果其中一台成员设备挂了，整个堆叠应该还能正常工作，对吧？这话只对了一半。现代堆叠技术确实支持跨设备转发，成员设备掉线后，它的接入端口上的流量可以由其他成员帮忙转发，前提是你的接入设备本身要能通过堆叠链路与别的成员通信。但如果你把接入设备单独挂在掉线的那台交换机上，而它又没有连接堆叠中的另一台，那么这台接入设备还是断的。所以做堆叠时，服务器或关键接入设备尽量双归到堆叠的不同成员上，这样才能享受设备冗余的红利。
集群技术同样为了可靠性，但它比堆叠更强的地方在于，它可以隔离故障域。比如两台框式交换机做集群，一台的主控板挂了，另一台还能接管所有业务。集群设备之间通过专门的集群口连接，数据面和控制面都做了冗余，真正做到无缝故障切换。
2.3 管理简化与运维效率
除了性能和可靠性，还有一个容易被忽略的价值点：管理成本。如果你有20台接入交换机，每台单独管理，意味着要维护20个IP地址、20份配置、20套日志。如果两两堆叠，就变成10台逻辑设备，管理面规模减半。集群也一样，两台核心变成一台逻辑核心，配置统一，升级时也能整机处理。
从运维角度看，堆叠还能简化链路聚合的配置。比如你原来需要在两台核心交换机上分别配两个上行口，然后靠STP来防环，切换还慢。做成堆叠后，两个上联口可以直接做一个跨设备链路聚合，接入交换机上联一根线就同时连通了堆叠里的两台设备，既增加带宽又防单点故障，还不需要跑STP。这在实际项目中非常有用。
3. 链路聚合核心技术细节与配置实践
3.1 链路聚合的报文交互与协商模式
链路聚合按是否协商分为静态和动态两种。静态聚合就是手工把几个端口绑在一起，不跑任何协议。动态聚合跑LACP（Link Aggregation Control Protocol），标准协议，谁家设备都支持，通过交换LACPDU报文来协商端口是否加入聚合组。
LACP协商的核心内容是什么？其实就是双方告诉对方“我能聚合多少端口”“我的系统优先级是多少”“我的端口优先级是多少”。协商通过后，端口就会进入Selected状态，开始转发业务。如果端口配置不匹配，或者对端不响应，端口会一直处于Standby状态，这时候业务流量是不会走的。
PAgP是Cisco私有协议，现在已经很少用了。现在新部署基本都用LACP，因为它开放标准，不同厂商设备之间也能互通。我个人的建议是，只要两端设备都支持LACP，就用LACP，别用静态聚合。原因很简单：LACP能在端口故障或链路异常时自动调整，静态聚合少了一个协商确认的过程，出了问题排查也更困难。
配置LACP时，有个重要参数叫“系统LACP优先级”。这个优先级决定了谁是主动发起方，两端的优先级不同时，高优先级一方会主动发送LACPDU。很多人忽略这个参数，默认两边优先级一样，这时就靠MAC地址大小来决出主动方，也能正常工作。但如果你的网络里有多个设备对接，最好手动设置一下，避免歧义。
另一个细节是“端口优先级”。它决定了在聚合组中，如果达到最大活跃端口数限制，哪些端口优先保持活跃。举个例子，你做了8口聚合，但设备最大只支持4口活跃（某些框式设备有限制），那么端口优先级小的4个口会转发流量，其余为备份。这四根备份链路平时不转发数据，一旦活跃链路断了，备份口立即顶上来。这个机制非常有用，但很多人不知道，配置时全部默认，结果带宽没达到预期，其实是因为最大活跃端口数被限制了。
3.2 负载均衡算法：为什么不是简单“轮询”
链路聚合的带宽提升，依赖负载均衡把流量分散到多条物理链路上。最简单的想法是“轮流来”，但网络流量不是排队按顺序打饭，无法按“第1个包走1口，第2个包走2口”这种方式做。原因在于TCP/IP要求单个连接的数据包按顺序到达，如果同一个TCP连接的不同包走不同链路，路径不同会引入时延差，接收端可能乱序，甚至导致重传风暴。
所以实际负载均衡是基于“流”的，不让同一个流拆散到不同链路。交换机通过提取报文字段，比如源MAC、目的MAC、源IP、目的IP、端口号中的若干字段，做一个哈希计算，根据哈希值映射到具体物理口。只要这些字段相同的报文，哈希值就一样，走的口也就固定，保证流的完整性。
配置负载均衡策略时，一般有这几个模式可选：源MAC、目的MAC、源+目的MAC、源IP、目的IP、源+目的IP、源+目的MAC+IP等。选哪个模式要看业务的流量特征。如果主要是路由流量，推荐用“源+目的IP”，因为IP字段随机性更好；如果主要是二层交换流量，推荐用“源+目的MAC”。如果你不确定，就用默认的“源+目的MAC”或者“源+目的IP”，问题一般不大。
这里有个坑：哈希不均。比如8条链路聚合，但实际流量都偏向某几条，往往是因为流数量少且某些字段相同，导致哈希结果集中。这种情况我见过很多次，特别是几十个用户使用同一个网关，目的IP都一样，只哈希目的IP就全部集中到一条链路上，带宽还是上不去。解决办法是换用包含源IP的哈希因子，或者查看设备是否支持更高级的“动态负载均衡”算法。记住一点：负载均衡是按流分布，不是按字节分布，永远做不到绝对均衡。
3.3 实际配置案例（以华为/H3C为例）
不管华为还是H3C，链路聚合配置逻辑很相似，只是命令稍有不同。我以常见的华为S5700系列为例，写一个典型配置：
interface Eth-Trunk 1 mode lacp-static load-balance src-dst-ip interface GigabitEthernet 0/0/1 eth-trunk 1 interface GigabitEthernet 0/0/2 eth-trunk 1这里的关键点：
mode lacp-static表示LACP动态聚合，有些老版本叫lacp，实际上就是LACP。load-balance src-dst-ip设置负载均衡方式，华为设备默认是src-dst-mac。- 加入聚合组的成员口，不能配置其他业务属性，比如不能单独配VLAN、端口类型，必须统一在Eth-Trunk接口上配置。
如果你遇到的是两台交换机之间的聚合，例如核心和接入之间，两端的Eth-Trunk编号可以不一样，但成员口的速率、双工方式必须一致，否则LACP协商会出问题。我建议习惯性把两端成员口的数量、速率、VLAN配置都保持一致，这样排查起来方便很多。
如果你用的是H3C设备，配置思路一样，命令略有不同：
interface Bridge-Aggregation 1 link-aggregation mode dynamic link-aggregation global load-sharing algorithm destination-ip interface Ten-GigabitEthernet 1/0/1 port link-aggregation group 1 interface Ten-GigabitEthernet 1/0/2 port link-aggregation group 1H3C的聚合口叫Bridge-Aggregation，动态模式也是LACP。而Cisco的配置是用Port-channel：
interface Port-channel1 switchport mode trunk channel-group 1 mode active interface GigabitEthernet0/1 channel-group 1 mode activeCisco的模式有active/passive/on三种，active表示主动发送LACP报文，passive表示被动等待，on表示强制启用，相当于静态聚合。两端都配active或一端active一端passive都能协商成功。
3.4 链路聚合与STP的纠葛
链路聚合和STP的关系经常让新手困惑。默认情况下，交换机的STP会检测到环路，然后block掉冗余链路。如果你手工把两个端口加入聚合组，STP看到的是一个逻辑口，不是两个口，所以不会阻塞。但如果聚合协商失败，比如只有一根线协商成功，另一根线没加入聚合，这时STP就会把没加入聚合的那根线当作二层环路阻塞掉，导致你的冗余链路消失。
所以做完聚合后第一件事，就是确认所有成员口是否都处于“Selected”状态。华为设备用display eth-trunk 1查看，Cisco用show etherchannel summary，H3C用display link-aggregation verbose。这里我习惯用三个维度确认：端口状态是否为Selected、对端端口是否有LACP协商信息、流量负载是否均衡散列到多口上。
如果是不同型号的交换机对接，注意两端端口模式要一致，比如都是access或者都是trunk，并且trunk的放通VLAN列表要完全一致。很多LACP协商不成功是因为两端Trunk放通VLAN不一致导致的，报文交互虽然成功，但业务不通。这算是一个比较隐蔽的问题。
4. 交换机堆叠技术原理与实操要点
4.1 堆叠的硬件形态与堆叠线缆
堆叠常见有两种形态：一种是用专门的堆叠口，比如华为的堆叠口通常是前面板最后两个光口，H3C一些型号也有专门的堆叠插槽；另一种是用普通的万兆口甚至千兆口做堆叠。专门堆叠口一般速率高、时延低，推荐优先使用。
堆叠线缆也有讲究。最常见的是堆叠专用电缆，像H3C的SFP堆叠线缆，两个头直接插在相邻设备上，长度很短，只适合机架内堆叠。如果设备在不同机柜，就需要通过光模块加光纤连接堆叠口。这时候务必确认你使用的光模块和光纤模式能匹配，多模模块搭配短距离传输没问题，但距离超过几百米就要改用单模模块和光纤。堆叠链路是设备间通信的核心，一旦中断，可能导致堆叠分裂，所以有条件的话，尽量做两条堆叠链接，形成堆叠环，增加冗余。
有些设备支持“逻辑堆叠口”，比如把两个物理口手动加入一个逻辑堆叠口，再用两个逻辑堆叠口互联，这样可以形成环状拓扑。这种设计更稳，因为物理链路和逻辑链路的对应关系完全由你控制。配置时要注意两台设备的堆叠口编号一一对应对齐，比如对端是堆叠口1/1，本端就是1/2，不能接反。
4.2 堆叠的选举、成员编号与优先级
堆叠系统启动后，会经历一个成员选举过程。选举的关键参数是成员优先级和MAC地址。优先级高的设备会成为主交换机（master），负责运行控制协议、管理整个堆叠系统。默认优先级是1，你可以在配置里调高优先级，比如配置为200，让它优先成为主设备。
成员编号（Member ID）也很重要，因为堆叠后端口编号会带上成员号，比如GigabitEthernet 1/0/1和GigabitEthernet 2/0/1，分别代表成员1和成员2的1号口。如果一台设备从堆叠里脱离后重新加入，它的成员号如果不固定，可能导致配置错乱。所以配置堆叠时，我会手动固定每台设备的成员号，而不是让它自动分配。
堆叠优先级的设置，华为的命令是：
stack member 1 priority 200H3C类似：
irf member 1 priority 32手动固定成员ID和优先级后，堆叠系统重启也能保持稳定，不会因为随机选举导致端口号变化，影响业务连续性。
4.3 堆叠的流量转发行为与跨设备链路聚合
堆叠系统内部，数据转发有两种模式。第一种是本地转发：如果流量源和目的都在同一个成员设备上，数据直接在该设备内部处理，不经过堆叠口。第二种是跨设备转发：如果目的设备在另一个成员上，数据通过堆叠口送到那边处理。跨设备转发有带宽开销，所以堆叠口带宽要高，否则会成为瓶颈。
做堆叠最大的好处之一就是支持“跨设备链路聚合”，也叫跨设备Link Aggregation。比如两台接入交换机堆叠后，上联到核心的两条万兆链路可以绑成一个聚合组。在核心看来，它只是对接了一台设备，不会丢任何一条链路。这个方法替代了传统的“双归+STP”方案，极大了提升了链路利用率和切换速度。
但要注意，跨设备链路聚合依赖堆叠口传递LACP协商信息。如果堆叠口出现拥塞或瞬时丢包，可能导致LACP报文丢失，聚合组震荡。所以堆叠口带宽预留很重要，一般建议堆叠带宽至少是上联带宽的1.5到2倍。比如上联做了4条10GE聚合，堆叠至少用两条40GE或8条10GE。
4.4 堆叠升级、替换成员等运维注意事项
堆叠系统的运维，最怕升级和替换。很多第一次接触堆叠的人，升级时直接给所有成员设备上传新版本并执行升级命令，结果版本不兼容导致整个堆叠起不来。正确做法是：先确认新版本支持当前堆叠拓扑，然后一台一台升级，先升级备设备，再主备倒换升级原主设备。
具体操作上，华为设备可以先在堆叠系统里用display stack查看成员状态，然后通过stack upgrade或load software的方式加载版本。H3C设备用irf upgrade。无论哪种，都要先备份当前配置，并且确保所有成员设备能通过堆叠口互相访问。
替换成员设备时有个细节：新设备插上去后，堆叠系统会自动发现并拷贝配置。但如果你插入的是一台旧设备，里面有旧的配置或堆叠残留信息，可能会出现成员ID冲突或配置不一致。稳妥做法是先清空新设备配置，最好恢复出厂设置，再上架。我吃过这个亏：曾有一台旧设备带了一个旧的成员ID，插入堆叠后被自动赋予了新角色，结果端口配置错乱，花了好长时间才理清。
另外，堆叠分裂问题一定要提前预防。所谓堆叠分裂，就是两台设备之间的堆叠链路全断了，但设备本身还正常运行。这时它们都会以“主设备”的身份运行，同时使用同一个IP和MAC地址，接入层会学到漂移的MAC，导致网络瘫痪，这就是脑裂。解决脑裂的机制是堆叠代理或多主检测，后面在集群部分详聊。
5. 集群技术：从堆叠到虚拟化
5.1 集群与堆叠的异同
集群和堆叠在最终效果上很相似，都是把多台设备变成一台逻辑设备，但在实现架构上有明显区别。堆叠主要用在盒式交换机上，通过数据平面的转发芯片配合完成统一转发，控制平面通常由一台主设备统一管理。集群则更多用在框式交换机上，通过交换网板互连，把两台设备的控制引擎和转发网板相互拉通，形成一套完整的高端虚拟化系统。
从用户视角看，集群也是一个管理IP，一个配置文件，端口编号类似1/1/1和2/1/1。但集群内部的控制平面冗余做得更彻底，支持双主控热备，一台主控故障时另一台能在毫秒级切换。框式设备做集群，业务板卡在两边可以交替插，可靠性更高。
从运维角度看，集群的配置和堆叠有很多相似操作，比如成员编号、集群优先级、集群口配置。区别在于集群的配置更复杂，涉及交换网板、业务板的资源规划。以我接触过的华为集群系统为例，两台S9700之间通过专用的集群业务口连接，每台设备至少需要两块集群业务板和对应的集群线缆。配置集群前要先规划好集群域编号、设备编号、集群优先级，然后分别启动集群相关特性。
5.2 集群的两种实现：框式设备集群与盒式设备堆叠
前面提到，严格意义上有区别：堆叠多用在盒式设备，集群多用在框式设备。但在厂商的宣传里，这两个词经常混着用。比如H3C把盒式设备的横向虚拟化技术叫IRF，本质是堆叠；华为把框式设备的横向虚拟化叫集群，把盒式的叫堆叠。思科则是堆叠技术叫StackWise，集群叫VSS或vPC。
所以你在选型时，不用太纠结名称，而是看设备形态和需求。中大型企业核心层，用两台框式交换机做集群是标配，保障核心汇聚层的高可靠。中小网络接入层或汇聚层，用几台盒式交换机做堆叠就足够，性价比高。
集群里还有一个重要方向，叫多活网关，或者在数据中心叫“分布式网关”。常见于VXLAN数据中心网络。两台或更多台框式交换机组成集群后，通过控制平面的协同，可以同时作为同一个网段的网关，三层的网关MAC在两个设备上同时生效。流量到达任意一台都能经由网关三层转发，避免了单一网关瓶颈。这比传统的VRRP双机热备更先进，因为VRRP是主备模式，备机闲置，集群支持双活。如果你规划数据中心，想用VXLAN和EVPN，一定要注意集群必须支持多活网关功能，否则还是得依赖VRRP。
5.3 集群分裂与脑裂场景处理
无论是堆叠还是集群，都会面临“分裂”这个坎。所谓分裂，就是两台设备之间的物理链路断了，但它们之间没有其他通信通道，它们各自都认为自己还是主设备，继续运行业务。结果一台交换机对外广播同一套MAC和IP，交换机学习表震荡，业务大面积丢包。
针对脑裂，业界标准方案是多主检测机制。基本原理是：集群系统通过一条独立的检测链路，周期性发送心跳消息，确认对端设备还在线。一旦检测链路断了，集群系统会认为对端失联，于是自动采取保护动作。常见保护动作包括：
- 关闭备设备的全部业务端口或部分端口，确保只有主设备在转发业务；
- 或者从堆叠系统中移除备设备，让它进入独立模式，但不再抢占原主设备的IP。
华为有DAD（Dual Active Detection）机制，H3C有MAD（Multi-Active Detection）。MAD还有一种实现是利用聚合口发送检测报文，不需要额外物理线缆，更省资源。不管用哪种，都建议在任何堆叠或集群系统中开启多主检测，否则脑裂就是定时炸弹。
我处理过一个真实案例：客户两台接入交换机做了堆叠，但堆叠口只用了单线，某天一根堆叠线被老鼠咬断，两台设备同时变主，接入终端疯狂掉线。当时没开多主检测，排查了很久才发现是脑裂。所以做堆叠时，除了把堆叠口做冗余，一定要记得开启多主检测。堆叠口不能省，保护机制更不能省。
5.4 集群在数据中心的应用：多活网关、SVF等
数据中心里，集群技术用得远比传统园区广。除了前面提到的多活网关，还有SVF（Super Virtual Fabric）这种超级虚拟化方案。SVF可以把核心、汇聚、接入多台设备虚拟成一台，盒式交换机通过纵向虚拟化接入到核心交换机上，变成核心交换机的一块“远端板卡”，实现接入统一管理。这种技术在大型园区网络和数据中心接入层非常常见。
SVF的好处是运维简单，配置像在一台设备上完成，坏处是接入设备的独立性丢失，核心挂了接入全断。所以SVF通常用在非核心的接入层，或者对可靠性要求不高的场景。
另外，数据中心还有一个强需求是“跨设备链路聚合”的广泛使用。集群形成后，上联或下联的ECN、服务器网卡都可以做跨设备绑定。服务器侧常配合Mellanox或Intel的网卡驱动，做LACP或VLAN负载均衡。这时候不仅交换机侧要配好聚合，服务器网卡侧的绑定模式也要一致。你交换机上配的是动态LACP，服务器网卡却用的是静态绑定，协商必然失败。这类问题出现的频率非常高，我在工作里起码碰到过十几次。
6. 常见问题与排障实录
6.1 家用电脑显示“以太网连接”速度只有100Mbps，是不是网线或协商问题？
这个问题虽然是家用场景，但原理和交换机链路聚合的协商完全一致。电脑网卡和路由器/交换机之间通过自动协商确定速度，如果协商结果是100Mbps，最可能的原因是网线只接了4根线，或是网线材质太差达到不了千兆。因为千兆网速需要8根线全部工作，100M网速只需要其中4根。
排障顺序我一般这样走：先换一根成品六类网线直接连接，看是否变成1Gbps；如果还不行，检查网卡驱动设置，确认“速度和双工”是否设置了强制百兆而不是自动协商；再看网线两端水晶头是否都按586B线序压好。很多老房子装修预埋的网线只有四芯，这就只能跑百兆，和链路聚合无关。
如果是交换机端口协商，也类似。不管聚合不聚合，每个成员口必须和对端协商成功，且速度和双工一致。如果有成员口协商成百兆，这个口的流量带宽就会受限，进而影响整个聚合负载均衡效果。检查聚合口状态时，一定要看每个成员口的实际协商速率。
6.2 交换机光口做链路聚合还是主备？如何选？
这是一个非常现实的选择题。比如你有一台核心交换机，接入交换机通过两个光口上联，问这两个光口是做链路聚合还是主备？答案取决于接入交换机是否支持跨设备链路聚合，以及上联设备的形态。
如果上联端是同一个交换机，或者上联端是一个堆叠/集群系统，那么优先做跨设备链路聚合。因为聚合同时获得带宽提升和链路冗余，主备则浪费了一半带宽。如果上联端是两台独立的核心交换机，这台接入交换机本身不支持跨设备链路聚合，那只能做双归主备，比如用STP阻塞一个口，两个口分别接到两台核心上。
很多方案设计里，把两个光口分别接到两台核心交换机上，然后在接入交换机上把两个光口做成静态聚合，这是完全错误的。因为两台核心交换机之间没有做堆叠，它们之间只有普通互联口，接入交换机把两个光口聚成一个逻辑口，流量会被哈希到其中一台核心，但另一台核心并不知情，会把某些流量从互联口踢回去，产生环路。所以做聚合前，必须先确认对端设备是否属于同一个虚拟化系统。
6.3 链路聚合协商不成功排查
LACP协商不成功，通常是以下几类原因。
- 端口物理层down，比如光纤断了、光模块不匹配。先查物理状态。
- 两端聚合模式不匹配。一端动态，一端静态，或者一端active，一端passive，虽然passive能被动接收，但如果双方都不主动，就无法协商。很多设备默认是passive，容易出问题。
- 成员端口配置不一致。有的端口是trunk，有的端口是access，或者VLAN列表不同，都可能让LACP报文被丢弃。
- 对端设备不支持LACP或聚合功能。老设备建议检查固件版本。
排查时我通常分三步走。第一步，在任意一台交换机上看display eth-trunk，确认聚合口是否存在，成员口状态。第二步，查看LACP报文计数，确认是否收到了对端的协议报文。第三步，如果条件允许，临时把动态聚合改为静态聚合试试，看看能不能通信。如果能通信，说明物理链路正常，问题出在LACP协商参数上，再把参数逐项对齐。
6.4 堆叠成员设备离线后如何恢复
堆叠中一台成员设备掉线，可能原因包括堆叠口中断、设备断电、板卡故障等。恢复操作要视情况而定。
如果设备只是断电，重新加电后一般会自动加入堆叠，并同步配置。如果设备长期离线后重新上线，最好先清空它的配置和堆叠历史信息，再让它加入。因为旧配置可能包含过期的MAC地址表项，容易引起短期震荡。
如果堆叠口物理断开导致设备脱堆叠，先恢复堆叠链路，然后在主设备上检查是否能看到成员在线。如果成员卡在“离线”状态，可能需要执行stack renumber重新指定成员号，或者重启该成员设备。我遇到过一次情况：堆叠口恢复后，成员设备一直显示Candidate状态，重启成员设备后正常。所以“重启解决80%”在堆叠场景同样适用，但要注意不要在业务高峰期重启主设备。
6.5 集群分裂后如何保证业务连续性
集群分裂后的第一原则：不要同时抢占同一个IP和MAC。如果你提前配置了多主检测，分裂后备设备会主动关闭自己业务口，主设备继续运行，这是最理想的情况。如果没配多主检测，网络已经乱成一团，恢复步骤是先人工断开其中一台集群设备的业务口，保住另一台正常转发业务，然后再恢复集群链路，再将设备重新加入集群。
恢复集群时，建议先在主设备上执行display cluster或类似命令，查看集群状态，再对备设备执行集群成员恢复操作。如果集群配置丢失，可能需要重新初始化集群口，这就要花更多时间。所以平时运维要保持配置备份，并且定期演练分裂场景。网络可靠性不是靠设备自动完成，而是靠预案和演练。
我个人在实际项目中最受益的一个习惯是：不管堆叠还是集群，配置完成后必做“断链测试”。把堆叠线拔掉，观察业务是否中断，再插回去看是否自动恢复。这个测试能提前暴露很多隐藏问题，比如没有开多主检测、聚合组没有跨设备绑定等。测试完再恢复堆叠口，网络状态一目了然。这个习惯真的能帮你少背很多锅。
