企业官网建设流程全解析

前阵子在一个机房做接入层改造，客户那边两台 CE 交换机分别跑业务，管理面分散、上联带宽又瓶颈，还老担心单点故障。方案翻来覆去比了一圈，最后还是落到华为 CloudEngine 的 iStack 堆叠上——把两台设备从逻辑上拧成一台，统一管理、统一转发，跨设备链路聚合一上，带宽和冗余都解决了。这个方案在网络工程师圈子里不算新鲜，但真正动手配置的时候，坑还是不少。这篇就把整个堆叠配置从头到尾捋一遍，从设计思路到命令行实操，再到故障排查，都是实际干过的经验，供参考。

1. 为什么要把两台交换机"拼"成一台

1.1 堆叠解决的三个核心问题

先说堆叠到底解决了什么。华为 CloudEngine 交换机的堆叠技术叫 iStack，全称 Intelligent Stack，原理不复杂：多台交换机通过专用的堆叠口互联，在系统层面虚拟成一台逻辑交换机。对外表现为一个 IP 地址、一套配置文件、一张转发表，对内则共享控制平面和数据平面。

实际落地时，堆叠主要解决三个问题：

第一个是管理面的收敛。一台设备一套配置、一个管理 IP、一条登录链路，这在设备少的时候还好说，设备一多，逐个登录调整配置就是灾难。堆叠之后只管理一台逻辑设备，接口资源按“框号+槽位+端口”的规则统一编号，省掉的运维时间非常可观。

第二个是带宽的弹性扩展。设备转发能力不够的时候，堆叠可以直接扩展端口密度和交换容量。比如机房服务器数量涨了，接入端口不够，用堆叠把两台 48 口设备变成一台 96 口的逻辑设备，成本比重买一台高配框式交换机低得多。

第三个是高可用性。堆叠系统内有主交换机、备交换机、从交换机的角色分工，主设备故障时备设备能秒级接管配置和协议状态。配合跨设备链路聚合，任何一台设备故障、任何一条堆叠链路故障，业务都能在用户无感知的情况下切换。

1.2 iStack 与独立组网的对比

堆叠不是唯一的高可用方案，传统做法有 VRRP 双机热备、MC-LAG 跨设备链路聚合，再往上还有框式交换机做集群。但接入层和汇聚层的最佳实践，堆叠往往是性价比最高的选择。

对比一下几类方案就能看出区别。VRRP 是网关冗余的典型方案，但它只冗余三层网关，二层链路还是得靠生成树阻塞，链路利用率上不去。MC-LAG 能解决链路利用率问题，但配置复杂度高，跨设备状态同步依赖专门的 peer-link 链路，对链路质量和软件版本要求也高。框式交换机本身硬件可靠性高，但成本高、灵活性差，小规模的机房用起来不划算。

iStack 介于两者之间，配置相对简单，效果又非常直观：跨设备链路聚合之后，所有链路都能转发数据，不再有阻塞链路，带宽利用率翻倍；设备故障自动切换，不需要依赖额外的协议协商。

1.3 拓扑选择：链形与环形的取舍

堆叠拓扑有链形和环形两种。链形是每台设备通过堆叠口依次串联，像一串糖葫芦；环形是首尾相连，形成闭环。

华为官方推荐的是环形拓扑。原因很简单：堆叠链路要有冗余。链形拓扑里面，如果中间某条堆叠链路断了，整个堆叠就会分裂成两个独立的系统，业务大概率中断。环形拓扑断一条链路，堆叠还能通过另一条路径继续通信，除非同时断两条才会分裂。

环形拓扑在配置上也不复杂，本质就是每台设备上配置两个堆叠口，分别和两台邻居互连。以两台设备为例——两台设备的堆叠是环形拓扑的特殊形态，两台设备之间用两条链路互连，逻辑上就形成了一个环。我用得最多的是两台设备做堆叠的场景，一是接入层点位不会太夸张，二是两台设备的环形堆叠配置最简单，故障面也最小。

2. 配置前必须做好的四件事

2.1 硬件兼容性与版本确认

堆叠配置第一步不是敲命令，是确认硬件和版本能不能堆。不同型号的 CloudEngine 交换机，堆叠能力天差地别。比如某 CE 系列中低端盒式交换机支持 iStack，高端框式则用另外的集群技术。即便是同系列设备，不同子型号的堆叠口规格、堆叠带宽限制也可能不一样。

版本是另一个重点。华为官方要求堆叠内所有成员设备的软件版本必须一致，版本不一致轻则堆叠起不来，重则起来之后转发行为异常。实际操作中我吃过亏，两台设备一台是补丁版本，另一台差了一个小版本，堆叠建了一会儿就自动分裂，查了半天才发现是版本差异。

所以配置前的第一步是执行display version对比两台设备的大版本、小版本和补丁版本，不一致的先升级到同一版本再往下走。还要确认设备的软件版本是否支持 iStack 功能，有些早期版本对堆叠功能有 license 限制，这个也需要提前确认。

2.2 堆叠ID、域ID与优先级规划

堆叠参数里最核心的三个是堆叠 ID、域 ID 和优先级。这三个参数直接影响设备角色和后续管理，规划错了改起来很费劲。

堆叠 ID（Slot ID）是成员设备在堆叠系统里的编号，对应了接口编号的第一位。比如设备的堆叠 ID 是 1，那它的接口编号就是 10GE1/0/x；堆叠 ID 是 2，接口就是 10GE2/0/x。规划原则是固定分配，别让系统自动分配，否则设备重启顺序一变，接口编号就乱套了，下游配置全得跟着改。

域 ID（Domain ID）用来隔离不同的堆叠系统。同一堆叠系统内所有设备的域 ID 必须一致，不同堆叠系统之间一般建议配不同的域 ID，防止误连导致设备被并入错误的堆叠。就好比一个班组一个编号，不同班组之间的人误进错队就会出问题。

优先级直接决定谁是主设备。华为的选举机制里，优先级高的当主，优先级相同则 MAC 地址小的当选。规划时建议给核心设备或性能较强的设备配高优先级，比如 200 或者 150，确保它永远是主。角色一稳定，设备重启之后堆叠的收敛速度会快不少。

2.3 堆叠口分配与连线设计

堆叠口是物理端口经过配置后变成的专用堆叠链路成员，CES 系列通常用高速业务口来承担。哪个口适合做堆叠口，不是随便选的。

首先要确认端口速率。堆叠链路速率越高，堆叠系统的转发性能越好。其次要确认端口数量，环形拓扑最少需要每台设备两个口。最后是端口位置的规划，建议堆叠口选在靠近设备背板的端口，方便走线，也避免后期插拔业务网线时误碰。

连线设计上，两台设备的环形堆叠就是 A 的堆叠口 1 连 B 的堆叠口 1，A 的堆叠口 2 连 B 的堆叠口 2，两条线交叉互连。注意堆叠口 1 和堆叠口 2 必须是两组不同链路（各用一根光纤或堆叠线），不能用同一根线分叉。曾经见过施工时图省事把两个堆叠口接到同一个对端设备上，结果堆叠总是反复震荡。

2.4 配置前的数据备份

这一步看着不起眼，出事的时候能救命。堆叠配置过程中，设备必然要重启，重启前不备份配置，配置出错就是灾难。

备份分三层：一是设备当前的配置文件，执行display current-configuration或者通过网管软件导出；二是设备的版本文件和 License 文件，确认在本地有留存；三是接口的 VLAN、VLANIF、路由、端口聚合等业务配置，逐条记录，方便堆叠完成后恢复业务。

有一招比较实用：把两台设备的配置导出后在文本对比工具里先看一下差异，尤其在接口配置、业务 VLAN 划分这些地方。很多堆叠之后出现的业务异常，根因其实在堆叠前就埋下了，只是没暴露而已。

3. 两台CE交换机环形堆叠完整配置

3.1 主设备的堆叠参数配置

设备规划好之后就可以动手了。我用的场景是两台 CE 交换机，设备 A 规划为堆叠 ID 1、优先级 200，设备 B 规划为堆叠 ID 2、优先级 100。

设备 A 的堆叠参数配置如下（以常见版本为例，具体命令以设备实际版本为准）：

system-view stack member 1 domain 10 stack member 1 priority 200 stack member 1 stack-port 1 port-member interface 10GE1/0/1 stack member 1 stack-port 2 port-member interface 10GE1/0/2

第一行stack member 1 domain 10设置该成员设备的堆叠域 ID 为 10。第二行设置优先级为 200，确保这台设备在堆叠建立后成为主交换机。第三、四行把 10GE1/0/1 和 10GE1/0/2 两个物理口分别加入堆叠口 1 和堆叠口 2。

这里的逻辑要理解一下：堆叠口是逻辑概念，物理口是实际承载。一个堆叠口下可以加入多个物理口，但每块设备一个堆叠口中加入的物理口号和速率应该一致，否则堆叠带宽会受限于低速端口。环形拓扑要求每台设备至少两个堆叠口，分别接到两台邻居（对两台设备堆叠来说就是互连的两条链路）。

配置完成后执行display stack configuration检查配置是否生效，确认无误后再继续。

3.2 备设备的堆叠参数配置

设备 B 的配置逻辑一样，但堆叠 ID 和优先级不同：

system-view stack member 2 domain 10 stack member 2 priority 100 stack member 2 stack-port 1 port-member interface 10GE1/0/3 stack member 2 stack-port 2 port-member interface 10GE1/0/4

这里有两个容易错的地方。

第一个是堆叠 ID 和物理口编号的关系。我在设备 B 上用的接口编号是 10GE1/0/3 和 10GE1/0/4，这表示这两个物理口在设备独立运行时叫 10GE1/0/3 和 10GE1/0/4；堆叠之后，设备 B 的堆叠 ID 是 2，这些口会变成 10GE2/0/3 和 10GE2/0/4。但配置堆叠口时，因为堆叠还没建立，命令里写的还是设备当前运行的接口编号。

第二个是域 ID 的一致性。设备 B 的域 ID 必须和设备 A 一样是 10，不一致会导致堆叠建立失败。前面规划的时候我特意把两台设备的域 ID 定为同一个值。

配置完成后同样执行display stack configuration确认。此时先不要急着重启，我已经踩过这个坑：只配置一台设备就重启，系统不会等另一台，起来后还是单机状态，业务等于白断一次。

3.3 保存配置与重启生效

两台设备都配置完成后，按顺序保存配置并重启：

save y reboot

重启前一定把两根堆叠连线都接好，保证两台设备在启动过程中能互相发现对方。如果堆叠连线没接好，设备起来后各自为政，堆叠就建不起来。

设备重启后，堆叠建立是自动完成的。经过一段时间的协商，两台设备会选出一个主设备，然后同步系统配置和业务配置。观察设备面板上的堆叠指示灯和串口回显信息可以看到堆叠建立的过程。

堆叠建立后执行display stack检查成员状态，正常应该看到两台成员设备，角色分别是 Master 和 Standby：

display stack

显示信息里重点看成员总数、每台设备的角色、堆叠 ID、软件版本是否一致。如果看到两台设备的角色都是 Master，说明堆叠分裂了，需要排查堆叠链路和配置。

3.4 堆叠建立后的业务配置调整

堆叠系统正常后，接口编号变了，业务配置也要跟着调整。

比如设备 B 上原来的业务口是 10GE1/0/10，堆叠之后变成了 10GE2/0/10。原来配在 10GE1/0/10 下的 VLAN、port 配置全部要迁移到新的接口编号下。如果担心遗漏，可以用display current-configuration | include 10GE过滤出所有接口配置逐条检查。

调整完业务配置后，建议把堆叠系统作为一个整体重新导出配置文件，做一次全量备份。这个时候的配置才是真正可用的基线配置，后续如果在上面调整了 VLAN、路由或策略，都基于这个基线来做变更。

有一个配置调整的技巧：堆叠完成后先配置跨设备的 Eth-Trunk 链路，再做业务割接。跨设备链路聚合是把两台设备上的物理口绑定到一个 Eth-Trunk 里，是堆叠的核心价值之一。配置方法和单台设备的链路聚合一样：

interface Eth-Trunk 10 port link-type trunk port trunk allow-pass vlan 10 20 trunkport interface 10GE1/0/20 trunkport interface 10GE2/0/20

这里的重点在trunkport命令，它能把堆叠系统中不同成员设备的物理口加入同一个 Eth-Trunk。下游交换机或服务器侧也做同样的链路聚合配置，整条链路从物理冗余变成了真正的负载均衡，而且任何单点故障都有冗余路径兜底。

4. 双主检测机制与可靠性加固

4.1 什么是双主故障

堆叠最怕的不是某台设备坏了，而是堆叠链路故障导致系统分裂成两个独立设备，两边同时以为是主设备，各自处理转发和协议状态。这种状态叫双主故障，在华为体系里靠 MAD（Multi-Active Detection）机制来检测和处理。

双主故障的危害是很大的。原本堆叠对外是一个二层域、一个三层网关，分裂后两边各自为政，二层出现环路，三层网关地址冲突，下游设备学到的 MAC 表、ARP 表不停抖动，业务要么丢包要么直接断连。最麻烦的是，两侧堆叠成员可能还会抢占同一个管理 IP，导致运维人员根本不知道该连哪台。

所以堆叠系统必须配双主检测，这是高可用方案的最后一道保险。

4.2 MAD/DAD检测的配置思路

华为 CE 设备上，较新的系统版本默认使能了堆叠分裂检测功能，设备从堆叠分裂后会自动关闭非堆叠端口，阻断业务转发，从而避免双主故障。同时也可以手动配置检测机制，常见的有直连检测和代理检测两种。

直连检测的思路是在两台成员设备之间用一条专门的链路互连，这条链路上跑 MAD 协商报文。如果堆叠分裂，两台设备仍然能通过这条链路感知到对端的存在，从而判断出自己是不是唯一的主设备。配置上大致是：

stack mad enable

具体到不同的 CE 型号，直连检测有的占用一个业务口，有的需要专用检测口。建议配置前先用display stack configuration或者参考设备版本对应的配置指南，确认当前版本支持的功能和命令格式。

我实际配置时，一般依赖系统默认的 MAD 能力，再额外做一道直连检测加固。分裂之后被判定为备侧的设备会自动把业务口置为 DOWN 状态，避免对现有网络造成冲击。

4.3 堆叠场景下的链路聚合配置

链路聚合是堆叠场景里绕不开的一个环节，它分上行和下行两个方向。

下行方向，接入层交换机堆叠后，下联服务器或终端一般做汇聚。服务器侧配置网卡绑定，交换机侧配置 Eth-Trunk，把两台成员设备上的端口加入同一个聚合组。这个前面已经说过了，做法就是trunkport命令把跨设备的物理口绑定到一起。

上行方向，接入层堆叠系统上行连接到汇聚层交换机，一般也做成链路聚合。两个堆叠系统之间建立跨设备的 Eth-Trunk，带宽叠加、链路相互备份，整条上联路径就变得很健壮。

链路聚合的负载均衡策略也要考虑。华为设备默认按源 IP 和目的 IP 做哈希，对一般的 IP 业务够用。如果业务里有大量大流量的单流（比如存储备份流量），单流哈希到同一条链路会导致负载不均衡，这时要考虑改哈希因子，或者在业务侧做调整。

5. 验证清单与排障实录

5.1 堆叠状态的验证方法

堆叠配置完，不是看指示灯变了就算完，必须把状态验证做完整。我一般按下面的顺序来：

display stack

查看成员数量、角色、堆叠 ID、优先级、软件版本等信息。重点确认没有设备处于离线状态。

display stack configuration

查看每台成员的堆叠参数，确认域 ID、优先级、堆叠口配置都符合预期。

display device

查看设备状态。堆叠后每台成员设备会以单独一行显示，状态应为 Normal，如果显示 Fault 就需要查具体原因。

display interface

抽查堆叠口的物理状态和流量统计，确认堆叠链路正常转发数据。

除此之外，还要做一次业务验证：在堆叠系统上创建一个测试 VLAN，接一台测试终端，跨堆叠成员设备 ping 一下网关或远端地址，确认业务转发正常。

5.2 常见故障的快速定位

堆叠启不来、堆叠分裂、业务中断，这几个是排障最常遇到的问题。整理成一张速查表方便现场用：

有两条排障经验可以多说一句。

一是光模块和光纤的可靠性。堆叠链路对光模块的质量非常敏感，建议优先选用原厂模块。在现网见过因为用了兼容模块导致堆叠口持续翻转，换回原厂模块后问题消失。

二是查看堆叠分裂的日志。设备日志里会记录堆叠分裂和恢复事件的详细信息，执行display logbuffer搜关键词stack或MAD，能快速定位分裂发生的时间点和原因。

5.3 几个容易踩的坑

配置时最容易犯的错误是漏看接口编号。设备 B 上配置堆叠口时，我用的还是它的物理口原编号 10GE1/0/3，但堆叠建立后它变成了 10GE2/0/3，后续想再次修改堆叠配置或新增堆叠口时，容易把实际接口编号写错。建议在设备上贴标签，明确标注每台设备的堆叠 ID。

其次是保存配置的问题。堆叠配置完成后一定先 save 再 reboot，而且两台设备都要保存。如果只保存了主设备，从设备重启后配置丢失，堆叠会直接建立失败。这个错误看着低级，现场忙乱时特别容易犯。

还有一个是在堆叠建立后马上配置业务接口。设备刚完成堆叠协商时就大范围改动配置，可能会导致配置同步异常。我建议的做法是：堆叠建立后先做状态验证，稳定运行一段时间，再批量下发业务配置，每改完一块配置就观察一下设备状态。

最后提一下维护窗口的选择。堆叠配置本身很快，但涉及到设备重启和业务割接，建议安排在业务低峰期操作。特别是生产环境，一定要有回退方案，脚本化备份配置、保留每一台设备的独立配置文件，这样即使堆叠失败也能快速恢复到原组网。

配置堆叠这个事，说穿了就是一个道理：参数规划比敲命令更重要。把堆叠 ID、域 ID、优先级、堆叠口分配这些事在配置前全部想清楚，配置过程只要按部就班执行就行。踩过几次坑之后，我现在每到一个新现场，第一步永远是拿着拓扑图和数据表把参数全部确认一遍，再开命令行。这么做前期看着慢，但后期省的事远不止这些。