北陌大叔1. 数据中心接入场景下，为什么我选了堆叠而不是VRRP
先说一个我最近刚做完的项目背景。客户数据中心接入层原来用的是两台CE6800独立运行，服务器双网卡分别接到两台交换机上，靠VRRP做网关冗余。表面上看高可用是有了，但实际运维中问题不少：两台设备要分别维护配置、VLAN要两边同步、双归服务器的流量转发路径也不对称，排障的时候经常要在一台设备上看半天，再去另一台设备上对半天。后来客户干脆说，能不能把两台设备“变成一台”来管。这就是这次CE6800堆叠配置案例的起因。
1.1 堆叠到底解决了什么问题
堆叠，华为这边叫iStack，本质上是把多台支持堆叠的交换机通过专用的堆叠口互联，在逻辑上合并成一台交换机。对CE6800这种数据中心接入交换机来说，堆叠带来的收益非常直接。
管理面收敛是最直观的好处。两台CE6800堆叠后，你只需要登录一个IP，看到的是一台设备，VLAN、接口、路由配置都在同一份配置里，改一处自动同步到所有成员。这比VRRP方案里两台设备各配各的，省掉的不是一点半点。
控制面冗余是另一个关键点。堆叠系统内有主交换机、备交换机、从交换机的角色划分，主设备故障时备设备能快速接管控制面，业务转发不中断。这个切换速度比VRRP的主备倒换要快，因为堆叠成员之间的状态同步是实时的，不需要像VRRP那样靠Hello报文超时去感知故障。
转发面能力翻倍。两台CE6800堆叠后，所有成员设备的物理端口都属于同一台逻辑设备，配合跨设备Eth-Trunk，服务器的双网卡可以同时工作，一条链路故障后流量自动走另一条，链路利用率从VRRP的“一主一备”变成了真正的负载分担。这一点对数据中心接入场景特别重要，因为服务器流量大，只让一条链路干活另一条闲着，太浪费。
1.2 和VRRP的对比：一张表说明白
很多刚接触堆叠的同事都会问，既然有了VRRP，为什么还要用堆叠？我通常直接用下面这张表来解释：
| 对比项 | VRRP | 堆叠（iStack） |
|---|---|---|
| 管理逻辑 | 多台独立设备，分别管理 | 多台设备虚拟成一台，统一管理 |
| 配置维护 | 需要逐台配置，同步靠人工或脚本 | 主设备配置自动同步到所有成员 |
| 转发模式 | 主备转发，备设备平时不转发业务流量 | 跨设备链路聚合，成员设备同时转发 |
| 故障切换 | 依赖检测报文，秒级或毫秒级 | 控制面实时同步，切换更快 |
| 链路利用率 | 上行链路通常一主一备，利用率低 | 跨设备Eth-Trunk负载分担，利用率高 |
| 部署复杂度 | 需要规划虚拟IP、优先级、抢占等 | 需要规划堆叠ID、优先级、堆叠口 |
| 典型场景 | 传统三层网关冗余 | 数据中心接入/汇聚，服务器双归 |
当然VRRP并没有被淘汰，在核心层、跨机框、跨地域的场景里依然广泛使用，因为它对设备型号和链路的要求更低。但在数据中心接入层，尤其是TOR（Top of Rack）这种场景下，堆叠是更主流的做法。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 动手前必须想清楚的三件事：堆叠ID、优先级与堆叠口规划
CE6800堆叠配置本身不复杂，真正翻车的基本都是前期规划没做好。我总结下来，动手之前必须把三件事定下来：堆叠ID怎么分配、主设备怎么选、堆叠口怎么连。
2.1 堆叠ID决定了配置归属
堆叠ID是每台成员设备的唯一标识，范围是1到9。这里有个容易忽略的点：CE6800出厂时所有设备的堆叠ID默认都是1，如果不改，两台设备一启动就会发现ID冲突，堆叠根本建立不起来，或者建立后配置归属混乱。
堆叠ID还直接影响接口编号。假设你给一台设备改了堆叠ID为2，那这台设备的所有接口编号就会从原来的1/0/1变成2/0/1。这个变化非常关键，因为你在配置里写的所有接口都得跟着变。实际操作中，我习惯用机柜位置来规划堆叠ID，比如机柜底部的设备用ID 1，上面的用ID 2，这样看到接口编号就能猜到是哪台设备，排障时省不少事。
修改堆叠ID的命令是stack member 1 renumber 2，这条命令执行后需要保存并重启才能生效，而且会清除该设备上的原有配置。这个“清除配置”的特性特别坑，后面踩坑部分我会详细说。