|
142| 2
|
实验案例：华为 S6730H 三机 iStack 堆叠 |
1. 这个实验解决什么iStack 把多台物理交换机变成一台逻辑设备。文档里最容易混淆的三件事：
这个实验把这几层拆开验证，并额外加了两件真实组网里必做的事：
适用读者：准备用华为交换机做堆叠实验、或者在 EVE 里评估 2. 镜像与规格
注意事项：
3. 拓扑与地址链路表：
堆叠编号与优先级：
地址：
4. 关键设计为什么是环形：三台两两相连，任意一条堆叠链路断开，拓扑降级为链形（ 为什么 ACC1 双上行跨成员：跨框 Eth-Trunk 是堆叠最直接的价值——两条上行在逻辑上是一条链路，任意一台成员故障，LACP 把流量切到另一条，接入侧无感知。 为什么 LACP MAD 要中间设备：堆叠分裂成两个分区后，两个分区都认为自己是 master。LACP MAD 让两个分区通过中间交换机交换扩展 LACP 报文；优先级低的一侧输掉竞争，业务口被置为 Error-Down。ACC1 正好同时连着两个分区，是天然的 relay 设备。注意 Huawei 的 为什么堆叠口分组是 1/2 而不是同一组：每台两个堆叠口分属 5. 核心配置5.1 堆叠引导（每台一次，必须重启才生效）以 SW1 为例（SW2/SW3 把
重启后再配堆叠口：
5.2 堆叠侧业务配置（在 master 上做）5.3 ACC1关键点：两侧 Eth-Trunk 都要 6. 复现步骤
7. 验收判据脚本
7.1 故障场景（
|
| 场景 | 注入 | 判据 |
|---|---|---|
| F1 断环 | suspend SW2↔SW3 堆叠链路 | 拓扑 Ring→Link（华为对单路径的显示值，不是 Chain），成员数仍为 3；PC1→PC2、PC1→ACC1 仍 5/5；resume 后回到 Ring |
| F2 成员下线 | stop SW2（非主成员） | master 看到成员数降到 2；Eth-Trunk1 剩 1 个 Selected 仍转发；start 后重新入栈（成员数回 3） |
| F3 主备切换 | 先读真实 Master，再 stop 它 | 剩余成员中产生新 Master（由原Standby 接管，不是优先级第二的成员）；PC2→ACC1 仍 5/5；start 后重新入栈 |
| F4 堆叠分裂 | 同时断开 SW1 的两个堆叠口 | 对侧分区只剩 member 2/3 且有 Master；SW1 分区独立运行；两侧 display dual-active 均为 Conflict（Huawei 语义）；按 stack priority 判胜负：SW1（150）胜，PC1→自己分区 Vlanif 5/5；对侧 master（100）败，PC2 输出 not reachable（业务口被 Error-Down）；恢复链路后不保证自动合并——本次败方分区重载后 15 分钟仍未重新入栈，需整 lab stop/start |
F4 的实测要点（2026-11-04 工作 MAD 下复测）：分裂期间不能用 ACC1 探数据面——ACC1 的 Eth-Trunk 两个成员分别落在两个分区，LACP 看到两个不同的系统 ID，整条 trunk 会停转发；两个分区本身是活的（实测
2:Standby 3:Master与4:Master），所以改打各自分区的堆叠 Vlanif。Huawei 的display dual-active在分裂时两侧都显示Conflict（不是一侧Recovery），胜负只能从数据面看：SW1（priority 150）胜，PC1→.254 为 5/5；对侧 master（100）败，PC2 输出host (192.168.10.254) not reachable。胜方的 relay 检测口先显示up (Physical) / up (Protocol) / PeerDomain 10，约一个 LACP 超时后变成up (Physical) / down (Protocol) / PeerDomain --——因为 ACC1 的 Eth-Trunk 同时看到两个系统 ID，这是 relay 代理在真实分裂下的副作用，不是 MAD 没生效。恢复链路后不会立刻合并：败方分区一侧会整机重载（串口出现Set the next startup package successfully/[PKGM]syspkg_verify process end），但本次恢复链路后 15 分钟仍未重新入栈（PC2 始终host not reachable，SW1 的display stack只剩 member 4），最后对整 lab 做 stop/start 才重新拉起。在这台模拟器上别把“接回链路”当成恢复手段：F4 之后要预留整 lab 重启的时间。脚本不绑定固定读表源：每轮从当前存活成员里挑控制台可用的一台读成员表；F3 先读真实 Master 再停它（角色可能已被前面的演练改过），F4 分裂后两侧选举最多等 90 秒。断一条链后华为显示
Stack Topology Type: Link，本脚本同时接受Link/Chain。工作 MAD 下的分裂结论（2026-11-04）：早期“MAD 下应有一侧进入
Recovery”的说法来自 H3C IRF，Huawei 命令参考没有这个取值，已作废。ACC1 改正为dual-active proxy后重新注入 F4：两侧display dual-active均为Conflict，SW1 侧 PC1 5/5、对侧 PC2not reachable；恢复链路后败方分区重载但 15 分钟内没有重新入栈，最终用整 lab stop/start 恢复。F2/F3 的实测限制（如实记录）：
--fault把 F1 放在最前，link_suspend恢复后 agent 会假死 1~2 分钟，紧接着的eve_iac_stop/start连续失败（原始错误Command failed，成员数一直 3），所以 F2 的“成员数降到 2”没有拿到单次成功记录；F3 的 stop 成功（stop n_1 requested）、剩余成员继续转发 5/5、start 后 count 回到 3，但“新 Master 在 120 秒内可读”受成员控制台假死影响没抓到；下一次运行开头的display stack显示3:Master（原 Standby 接管），与预期一致。需要单次全绿时建议先跑--links-only（F1/F4），再单独手工做 F3 的 stop/start，或把 F1 挪到最后。
| Filter | 表达式要点 | 预期 |
|---|---|---|
| ARP-Request（红） | arp[6:2] = 1 |
PC 首次 ping 前会亮，ARP 老化后再次 ping 会重新亮 |
| ARP-Reply（绿） | arp[6:2] = 2 |
与 Request 成对出现 |
| ICMP-Request（蓝） | icmp[0] == 8 |
每次 ping 亮 5 个 |
| ICMP-Reply（黄） | icmp[0] == 0 |
与 Request 成对 |
| LACP（紫） | ether proto 0x8809 |
持续低速闪烁（30s 一次，Slow 模式） |
| STP-BPDU（蓝灰） | ether dst 01:80:c2:00:00:00 |
持续闪烁 |
| ICMPv6-Neg（粉） | icmp6 |
故意不亮：本实验没有 IPv6 流量，用来反证过滤器不是“见包就亮” |
截图时如果想让 ARP 明显亮，先把 timeout 临时调到 2000ms，截完改回 500ms——注意改参数会清零面板计数。
附件：s6700-istack.zip
display stack troubleshooting current 里报：Stack-Port link invalid: The member ports of Stack-Port are connected to same Stack-Ports of the same device (PortName = GE4/0/10, PeerPortName = GE3/0/10)。Stack-Port1/2 分组没用。The system is busy in synchronizing configurations to the slave board。此时 system-view 能进，但 vlan / interface 全部被拒。在 master 上 save 一次（会依次写所有 slot）之后恢复。别在这段时间反复重试，也别以为命令不存在。eve_iac_edit 改链路端点 + reconcile，ACC1 两条上行在交换机侧都变 down（对端还显示 up），LACP 收发都是 0。拓扑改了就走整机 stop/start，让链路在开机时重新接线；重启后 2/2 立刻 Selected。Master / Standby / Slave。Master 选举依次看启动状态（最先完成启动并进入单机运行的设备优先）→ 优先级 → 系统 MAC →（部分版本再看堆叠 ID）；只有同时启动才比较优先级。已经运行的堆叠不会被后来加入的更高优先级设备抢占。本实验三台一起拉起，实测 150 的 member 4 当选（与优先级一致）。Master 选完后，优先选与 Master 的 Stack-Port n/1 相连的设备为 Standby（受启动时间和堆叠口 up 时间影响，也可能选 n/2 方向的设备），其余为 Slave。所以优先级第二高不一定是 Standby：首次成栈实测 member 4（150）= Master、member 3（100）= Standby、member 2（120）= Slave——member 3 正接在 member 4 的 Stack-Port 4/1 方向（GE4/0/10 ↔ GE3/0/8），符合规则。display stack 的 Priority 列只是配置值，角色直接读 Role 列。主设备下线后由 Standby 接管，原 Master 重新入栈也不会抢回：停掉 member 4 后实际是 member 3（原 Standby，100）成为 Master、member 2（120）仍是 Slave；故障演练后角色分布会与首次成栈不同，脚本只校验「一主一备一从 + 各视图一致」，不写死谁当 Master。<SW1>。验收脚本不能按节点名匹配提示符。display stack-port statistics 只在 diagnose 视图（system-view → diagnose → 命令 → quit ×2）。普通视图没有这条命令。port member-group 两次 Y/N，undo 零确认。批量脚本里给错步数会卡在确认问句。console_run 的 expect 只匹配本步新收到的字节；控制台空闲退回 Password: 后，先发空行诱出提示符，落在 Password: 就用 send_secret 重登。expect 是正则，[SW1] 要转义成 \[SW1\]。Devma ... The board is registered 或 [PKGM]syspkg_verify process end.，回车无回显），但设备在栈里一切正常。遇到控制台“死”先看 display stack 确认角色——如果它是 Slave，这是本镜像的已知限制，不是配置；同一设备换成 Master/Standby 后控制台立刻可用，重启治不好（见 §9）。dual-active detect mode relay 时命令被接受，但 display dual-active 一直 Initial、成员口 down(Protocol)、PeerDomain --；改成 dual-active proxy（部分版本 mad relay）后，同样两台设备立刻变成 Dual-active status: Normal、成员口 up (Physical) / up (Protocol)、PeerDomain 10。命令分工：堆叠侧 dual-active detect mode relay，代理设备 dual-active proxy。Conflict，不是 Recovery：早期把 ACC1 配成堆叠侧的 dual-active detect mode relay，display dual-active 停在 Initial，很容易误判为模拟器不支持；改成 dual-active proxy 后正常态为 Normal（成员口 up (Physical) / up (Protocol)、PeerDomain 10）。工作 MAD 下重新注入分裂，两侧都显示 Conflict；Huawei 命令参考的取值只有 Normal / Conflict / Initial，没有 H3C IRF 的 Recovery。up/up 变成 down(Protocol)。这不是分区死了：胜方分区（本实验 SW1）的 PC1 打自己的堆叠 Vlanif 仍是 5/5，败方分区的 PC2 才是 not reachable（业务口被 MAD 置 Error-Down）。验证分区存活要打各自分区的堆叠 Vlanif。Set the next startup package successfully / [PKGM]syspkg_verify process end），但2026-11-04 这次 15 分钟仍未重新入栈（SW1 只剩 member 4、PC2 一直 not reachable）；最终只能对整 lab 做 stop/start。别用“接回链路”当恢复手段，也别用几分钟判失败——直接预留整 lab 重启的时间。running-config 保存；wipe 后必须重新引导（§6 第 7 步）。Devma ... The board is registered（有时是 [PKGM]syspkg_verify process end.），敲回车没有 Password:；同一块设备换成 Master/Standby 后控制台立刻可读。四次角色互换的验收里，卡住的设备依次是 SW2、SW1、SW3、SW2——每次都正好是当时的 Slave，Master 和 Standby 都能读。本实验只把它作为该镜像的实测限制记录，不推断真机行为——真机上从 Slave 的 Console 能否登录，本环境无法验证。重启修不好：重新入栈后只要还是 Slave 就仍然卡。验收脚本因此不绑定固定读表源：Slave 的角色/优先级用 Master 或 Standby 的 display stack 视图交叉核对，读不到记 SKIP，不当配置故障。附件包 附件/s6700-istack.zip（265,293 字节，SHA-256 03a1786736f39f5a321a1886cb3c7813abdeacbd790b725353f2fdac72dc59f0）内含 topology.yml、.eve-iac.yml、逐台启动配置（configs/default/）、
手工堆叠引导步骤（stack-bootstrap.md）、拓扑图（topology.png）、文件说明与 SHA-256 表（README.md）。
验收脚本 tools/s6700-istack-verify.js 依赖本仓库的 tools/eve-mcp.js，随仓库提供，不放进压缩包。
display stack # 成员、角色、优先级、MAC
display stack topology # Ring / Link（链形），每个堆叠口的邻居
display stack configuration # 堆叠专用配置（不在 running-config）
display stack troubleshooting current # 堆叠告警
system-view -> diagnose -> display stack-port statistics # 堆叠报文收发
display eth-trunk 1 # 成员口状态 + Partner System ID
display dual-active # MAD 模式、检测口、状态
display lacp statistics eth-trunk 1 # LACP 收发计数
display dual-active 停在 Initial，误判为 relay 协议不协商。dual-active detect mode relay，代理设备 ACC1 用 dual-active proxy/mad relay）——改正后 display dual-active 实测为 Normal，早前停在 Initial 是 ACC1 命令配错造成的误判；按官方规则重写 Standby 选举说明，统一 Link 写法；附件包补 README 与 SHA-256 表。display dual-active 均为 Conflict（Huawei 取值只有 Normal/Conflict/Initial，没有 Recovery），SW1（priority 150）胜、PC1 5/5，对侧（priority 100）败、PC2 not reachable；胜方 relay 口在 LACP 超时后变成 down(Protocol)。旧稿“一侧 Recovery”结论作废。not reachable），最终整 lab stop/start 才恢复三成员（2 Slave / 3 Standby / 4 Master）。恢复后常规验收复跑 40 PASS / 0 FAIL / 2 SKIP；附件包按 MCP 回读重建，zip 265,293 字节、SHA-256 03a1786736f39f5a321a1886cb3c7813abdeacbd790b725353f2fdac72dc59f0。
发表于 
