实验案例：华为 S6730H 三机 iStack 堆叠-EVE-NG亚太代理中文区独家合作伙伴

hbugs001 发表于 6 天前

实验案例：华为 S6730H 三机 iStack 堆叠

<h1>实验案例：华为 S6730H 三机 iStack 堆叠（环形堆叠 / 跨框 Eth-Trunk / LACP MAD）</h1>
<blockquote>
<p><strong>活样本</strong>：<a href="../IaC/s6700-istack/">IaC/s6700-istack/</a> —— 6 节点 / 7 链路 / 7 filter，<code>topology.yml</code> 与启动配置都在 Git 里，随时可重新 deploy。<br />
<strong>一键复验</strong>：常规 <code>node tools/s6700-istack-verify.js</code>；链路故障 <code>--links-only</code>（F1/F4，<strong>F4 恢复链路后不保证自动合并，可能要把整个 lab stop/start</strong>）；完整 <code>--fault</code> 含两次整机重启，受本环境控制台/agent 假死影响，不保证单次全绿。<br />
<strong>平台</strong>：EVE-NG + eve-iac agent 0.9.1，<strong>create 模式</strong>；镜像是华为 S6730H-V2 V600R025C10SPC500（<code>huaweis6700-V600R025C10SPC500-EmulatedLab-v1.2</code>，QEMU）。</p>
</blockquote>
<blockquote>
<p>完整预配与 IaC 文件见 §10 附件包；第 5 节只列核心行。</p>
</blockquote>
<h2><a href="forum.php?mod=attachment&aid=3640" title="attachment"><img src="/source/plugin/zhanmishu_markdown/template/editor/images/upload.svg" alt="upload" /> 附件：s6700-istack.zip</a></h2>
<p><img src="data/attachment/forum/202611/04/083256pzb6pcchez60hf60.png" alt="641cd60e08b57ca50592978213a6bcc2.png" title="641cd60e08b57ca50592978213a6bcc2.png" /></p>
<h2>0. 实测结果</h2>
<table>
<thead>
<tr>
<th>项</th>
<th>实测结果</th>
</tr>
</thead>
<tbody>
<tr>
<td>堆叠成员</td>
<td>3 成员，domain 10；member 4 <code>Master</code>（priority 150）、member 3 <code>Standby</code>（100）、member 2 <code>Slave</code>（120）</td>
</tr>
<tr>
<td>堆叠拓扑</td>
<td><code>Stack Topology Type: Ring</code>，6 个堆叠口全部 up，每个成员的邻居正好是另外两台</td>
</tr>
<tr>
<td>堆叠协议</td>
<td>每个堆叠口 Hello / Detect 收发均 > 0，收发计数基本对称（<code>display stack-port statistics</code>，diagnose 视图）</td>
</tr>
<tr>
<td>跨框 Eth-Trunk</td>
<td>堆叠侧 2/2 <code>Selected</code>（<code>GE2/0/1</code> + <code>GE4/0/3</code>，分属 member 2 与 4）；ACC1 侧 2/2 <code>Selected</code></td>
</tr>
<tr>
<td>LACP 对端</td>
<td>ACC1 两个成员口看到的 Partner System ID 都是堆叠系统 MAC</td>
</tr>
<tr>
<td>数据面</td>
<td>PC1↔PC2 双向 5/5；PC→ACC1 Vlanif 5/5；PC→堆叠 Vlanif 5/5</td>
</tr>
<tr>
<td>双主检测</td>
<td>堆叠侧 Eth-Trunk1 用 <code>dual-active detect mode relay</code> 登记 relay 检测口，ACC1 用 <code>dual-active proxy</code> 使能代理；<code>display dual-active</code> 为 <strong>Normal</strong>，两个成员口 <code>up (Physical) / up (Protocol)</code>，PeerDomain 10</td>
</tr>
<tr>
<td>验收脚本</td>
<td>常规<strong>42 项：40 PASS / 0 FAIL / 2 SKIP</strong>（2 个 SKIP 都是当时 Slave（SW2）的控制台不可用、改用 Standby（SW3）视图核对；2026-11-04 恢复后复跑仍为 40/0/2）；链路故障 <code>--links-only</code>（F1+F4）<strong>60 项：53 PASS / 3 FAIL / 4 SKIP</strong>——这轮故障是在 ACC1 的 MAD 命令配错、relay 未生效时跑的，改成 <code>dual-active proxy</code> 后未重跑整套 <code>--links-only</code>（F4 已按 §7.1 手工复测），3 个 FAIL 的原始数据见 §7.1 下方说明；完整 <code>--fault</code>（含 F2/F3 两次整机重启）受模拟器控制台假死/agent 假死影响，未拿到单次全绿汇总，实测证据按场景分列</td>
</tr>
</tbody>
</table>
<h2>1. 这个实验解决什么</h2>
<p>iStack 把多台物理交换机变成一台逻辑设备。文档里最容易混淆的三件事：</p>
<ol>
<li><strong>链路 up ≠ 入栈</strong>——堆叠口物理 up，协议 Hello 也未必能互通；</li>
<li><strong>堆叠口 up ≠ 环形成</strong>——只有每台的两个堆叠口都看到邻居，拓扑才是 Ring，否则是链形（<code>Link</code>）；</li>
<li><strong>堆叠形成 ≠ 配置同步完成</strong>——刚合栈时 master 会向 slave 同步配置，这期间写命令会被拒绝。</li>
</ol>
<p>这个实验把这几层拆开验证，并额外加了两件真实组网里必做的事：</p>
<ul>
<li><strong>跨框链路聚合</strong>：接入交换机 ACC1 的两条上行分别落在堆叠的 member 2 和 member 4 上，逻辑上是一条 Eth-Trunk；</li>
<li><strong>LACP MAD</strong>：ACC1 作为中间代理设备（<code>dual-active proxy</code>），在堆叠分裂时把 MAD 信息转给两个分区。</li>
</ul>
<p>适用读者：准备用华为交换机做堆叠实验、或者在 EVE 里评估 <code>huaweis6700</code> 镜像堆叠能力的人。</p>
<h2>2. 镜像与规格</h2>
<table>
<thead>
<tr>
<th>节点</th>
<th>角色</th>
<th>EVE 模板</th>
<th>镜像</th>
<th>vCPU / RAM</th>
<th>网口</th>
</tr>
</thead>
<tbody>
<tr>
<td>SW1</td>
<td>堆叠成员 4（Master）</td>
<td><code>huaweis6700</code></td>
<td><code>huaweis6700-V600R025C10SPC500-EmulatedLab-v1.2</code></td>
<td>2 / 4096 MB</td>
<td><code>GE1/0/1</code>–<code>GE1/0/10</code></td>
</tr>
<tr>
<td>SW2</td>
<td>堆叠成员 2（Slave）</td>
<td>同上</td>
<td>同上</td>
<td>2 / 4096 MB</td>
<td>同上</td>
</tr>
<tr>
<td>SW3</td>
<td>堆叠成员 3（Standby）</td>
<td>同上</td>
<td>同上</td>
<td>2 / 4096 MB</td>
<td>同上</td>
</tr>
<tr>
<td>ACC1</td>
<td>接入交换机</td>
<td><code>huaweis6700</code></td>
<td>同上</td>
<td>2 / 4096 MB</td>
<td>同上</td>
</tr>
<tr>
<td>PC1 / PC2</td>
<td>主机</td>
<td><code>vpcs</code></td>
<td>EVE 自带</td>
<td>—</td>
<td><code>eth0</code></td>
</tr>
</tbody>
</table>
<p>注意事项：</p>
<ul>
<li><code>attributes.ethernet: 11</code> = <code>MEth0/0/0</code> + <code>GE1/0/1</code>–<code>GE1/0/10</code>，<strong>不是 11 个业务口</strong>。</li>
<li>节点名必须纯 ASCII。中文名会让部署报 <code>invalid_native_format</code> 并静默删库。</li>
<li>控制台密码 <code>Test@123</code>；空闲几分钟会退回 <code>Password:</code>。</li>
</ul>
<h2>3. 拓扑与地址</h2>
<p>链路表：</p>
<table>
<thead>
<tr>
<th>#</th>
<th>设备 A</th>
<th>接口</th>
<th>设备 B</th>
<th>接口</th>
<th>用途</th>
</tr>
</thead>
<tbody>
<tr>
<td>1</td>
<td>SW1</td>
<td><code>GE1/0/9</code></td>
<td>SW2</td>
<td><code>GE1/0/8</code></td>
<td>堆叠链路</td>
</tr>
<tr>
<td>2</td>
<td>SW2</td>
<td><code>GE1/0/10</code></td>
<td>SW3</td>
<td><code>GE1/0/9</code></td>
<td>堆叠链路</td>
</tr>
<tr>
<td>3</td>
<td>SW3</td>
<td><code>GE1/0/8</code></td>
<td>SW1</td>
<td><code>GE1/0/10</code></td>
<td>堆叠链路</td>
</tr>
<tr>
<td>4</td>
<td>ACC1</td>
<td><code>GE1/0/1</code></td>
<td>SW1</td>
<td><code>GE1/0/3</code></td>
<td>Eth-Trunk1 成员</td>
</tr>
<tr>
<td>5</td>
<td>ACC1</td>
<td><code>GE1/0/2</code></td>
<td>SW2</td>
<td><code>GE1/0/1</code></td>
<td>Eth-Trunk1 成员</td>
</tr>
<tr>
<td>6</td>
<td>PC1</td>
<td><code>eth0</code></td>
<td>SW1</td>
<td><code>GE1/0/2</code></td>
<td>接入 VLAN 10</td>
</tr>
<tr>
<td>7</td>
<td>PC2</td>
<td><code>eth0</code></td>
<td>SW2</td>
<td><code>GE1/0/2</code></td>
<td>接入 VLAN 10</td>
</tr>
</tbody>
</table>
<p><img src="data/attachment/forum/202611/04/083210eumznvvn4ez99uvv.png" alt="s6700-istack-topology.png" title="s6700-istack-topology.png" /></p>
<blockquote>
<p><code>topology.yml</code> / EVE 画布里的接口名恒为 <code>GE1/0/x</code>；设备成栈后按 member ID 变成 <code>GE4/0/x</code>、<code>GE2/0/x</code>、<code>GE3/0/x</code>。上图标的是设备侧实际编号，配置时以 <code>display stack</code> 后的接口名为准。</p>
</blockquote>
<p>堆叠编号与优先级：</p>
<table>
<thead>
<tr>
<th>设备</th>
<th>member ID</th>
<th>优先级</th>
<th>域 ID</th>
<th>首次成栈实测角色</th>
</tr>
</thead>
<tbody>
<tr>
<td>SW1</td>
<td>4</td>
<td>150</td>
<td>10</td>
<td>Master</td>
</tr>
<tr>
<td>SW2</td>
<td>2</td>
<td>120</td>
<td>10</td>
<td>Slave</td>
</tr>
<tr>
<td>SW3</td>
<td>3</td>
<td>100</td>
<td>10</td>
<td>Standby</td>
</tr>
</tbody>
</table>
<blockquote>
<p>Master 选举依次看：<strong>启动状态（最先完成启动并进入单机运行的设备优先）→ 优先级 → 系统 MAC →（部分版本再看堆叠 ID）</strong>；本实验三台一起拉起，实测 master 是 priority 150 的 member 4（与优先级一致）。已经运行的堆叠不会被后来加入的更高优先级设备抢占。Standby <strong>优先选与 Master 的 Stack-Port n/1 相连的设备</strong>（受启动时间和堆叠口 up 时间影响，也可能选 n/2 方向），所以优先级第二高不一定是 Standby。本实验 member 3 正接在 member 4 的 Stack-Port 4/1 方向（<code>GE4/0/10 ↔ GE3/0/8</code>），因此 100 的 member 3 成为 Standby，而 120 的 member 2 是 Slave。</p>
</blockquote>
<p>地址：</p>
<table>
<thead>
<tr>
<th>设备</th>
<th>接口</th>
<th>地址</th>
<th>说明</th>
</tr>
</thead>
<tbody>
<tr>
<td>堆叠</td>
<td><code>Vlanif10</code></td>
<td><code>192.168.10.254/24</code></td>
<td>堆叠管理地址</td>
</tr>
<tr>
<td>ACC1</td>
<td><code>Vlanif10</code></td>
<td><code>192.168.10.253/24</code></td>
<td>接入网关</td>
</tr>
<tr>
<td>PC1</td>
<td><code>eth0</code></td>
<td><code>192.168.10.10/24</code>，网关 <code>.254</code></td>
<td></td>
</tr>
<tr>
<td>PC2</td>
<td><code>eth0</code></td>
<td><code>192.168.10.20/24</code>，网关 <code>.254</code></td>
<td></td>
</tr>
</tbody>
</table>
<blockquote>
<p>注意：<strong>ACC1↔SW1 的链路特意接成 <code>GE1/0/1↔GE1/0/3</code></strong>，两端端口号不同。模拟器会把两端同一物理口号的堆叠链路当自环（见 §8），业务链路也按同样规则错开。</p>
</blockquote>
<h2>4. 关键设计</h2>
<p><strong>为什么是环形</strong>：三台两两相连，任意一条堆叠链路断开，拓扑降级为链形（<code>Link</code>），成员不分裂、转发不中断。链形堆叠断中间一条就会分裂成两个栈。</p>
<p><strong>为什么 ACC1 双上行跨成员</strong>：跨框 Eth-Trunk 是堆叠最直接的价值——两条上行在逻辑上是一条链路，任意一台成员故障，LACP 把流量切到另一条，接入侧无感知。</p>
<p><strong>为什么 LACP MAD 要中间设备</strong>：堆叠分裂成两个分区后，两个分区都认为自己是 master。LACP MAD 让两个分区通过中间交换机交换扩展 LACP 报文；优先级低的一侧输掉竞争，业务口被置为 Error-Down。ACC1 正好同时连着两个分区，是天然的 relay 设备。注意 Huawei 的 <code>display dual-active</code> 状态只有 <code>Normal / Conflict / Initial</code>：分裂时<strong>两侧都显示 <code>Conflict</code></strong>，没有 H3C IRF 那种“一侧 Recovery、一侧 Normal”的字段。</p>
<p><strong>为什么堆叠口分组是 1/2 而不是同一组</strong>：每台两个堆叠口分属 <code>Stack-PortX/1</code> 和 <code>Stack-PortX/2</code>，对应环的两个方向；同一组只能有一个成员口。</p>
<h2>5. 核心配置</h2>
<h3>5.1 堆叠引导（每台一次，必须重启才生效）</h3>
<p>以 SW1 为例（SW2/SW3 把 <code>renumber</code> 目标 ID 换成 2/3、<code>priority</code> 换成 120/100、端口换成各自的）：</p>
<pre><code class="language-text">system-view
stack member 1 priority 150
stack member 1 domain 10
stack member 1 renumber 4
quit
save
</code></pre>
<blockquote>
<p><strong>三条命令里的 <code>1</code> 都是设备当前的 member ID</strong>（新设备出厂都是 1），不是目标 ID。<code>renumber</code> 只是登记新 ID，<strong>save 后整机重启才生效</strong>；重启后设备变成 member 4，接口名跟着变成 <code>GE4/0/x</code>。实际执行时 <code>renumber</code> 会弹一次 <code></code> 确认。</p>
</blockquote>
<p>重启后再配堆叠口：</p>
<pre><code class="language-text">system-view
interface Stack-Port4/1
port member-group interface GE4/0/10
interface Stack-Port4/2
port member-group interface GE4/0/9
quit
save
</code></pre>
<p><code>port member-group</code> 每条会弹<strong>两次</strong> <code></code>；<code>undo port member-group</code> 不弹确认、立即完成。三台都配完 <code>save</code> 后，<strong>三台一起整机重启</strong>，环才形成。</p>
<h3>5.2 堆叠侧业务配置（在 master 上做）</h3>
<pre><code class="language-text">vlan 10
interface Vlanif10
ip address 192.168.10.254 24
interface Eth-Trunk1
port link-type trunk
port trunk allow-pass vlan 10
mode lacp-static
dual-active detect mode relay
trunkport GE2/0/1
trunkport GE4/0/3
interface GE2/0/2
port link-type access
port default vlan 10
interface GE4/0/2
port link-type access
port default vlan 10
return
save
</code></pre>
<h3>5.3 ACC1</h3>
<pre><code class="language-text">vlan 10
interface Vlanif10
ip address 192.168.10.253 24
interface Eth-Trunk1
trunkport GE1/0/1
trunkport GE1/0/2
mode lacp-static
port link-type trunk
port trunk allow-pass vlan 10
dual-active proxy
return
save
</code></pre>
<p>关键点：两侧 Eth-Trunk 都要 <code>mode lacp-static</code>，但 <strong>MAD 命令不同</strong>——堆叠侧用 <code>dual-active detect mode relay</code> 指定 relay 检测口；中间设备 ACC1 用 <code>dual-active proxy</code>（部分版本为 <code>mad relay</code>）使能 DAD relay 代理功能。不能把堆叠侧的命令照搬到代理设备上。</p>
<h2>6. 复现步骤</h2>
<ol>
<li>用 IaC 部署 lab（6 节点、7 链路），等所有节点 running。</li>
<li>按 §5.1 给三台交换机配 member/priority/domain，<code>save</code>，三台一起重启。</li>
<li>重启后配 <code>Stack-PortX/1</code>、<code>Stack-PortX/2</code>，<code>save</code>，三台再一起重启。</li>
<li>在 master 上确认 <code>display stack</code> 三成员齐全、<code>display stack topology</code> 是 <code>Ring</code>。</li>
<li>按 §5.2 配堆叠侧业务，按 §5.3 配 ACC1，两边 <code>save</code>。</li>
<li>跑 <code>node tools/s6700-istack-verify.js</code>（常规 42 项），再跑 <code>--fault</code>（含两次整机重启，约 35~45 分钟）；时间紧时用 <code>--links-only</code> 只跑 F1/F4（约 10 分钟，但 F4 之后可能要把整个 lab stop/start 才能恢复三成员）。</li>
<li><strong>wipe 会清掉设备的堆叠配置</strong>，之后要重新走第 2~5 步。</li>
</ol>
<blockquote>
<p>堆叠配置不在 <code>running-config</code> 里，<code>display current-configuration</code> 只显示 <code>stack</code> 一行；要看真实堆叠配置用 <code>display stack configuration</code>。</p>
</blockquote>
<h2>7. 验收判据</h2>
<p>脚本 <code>tools/s6700-istack-verify.js</code> 的判定分五组：</p>
<table>
<thead>
<tr>
<th>组</th>
<th>判据</th>
<th>反证 / 说明</th>
</tr>
</thead>
<tbody>
<tr>
<td>STACK</td>
<td>三台看到同一组成员（2/3/4），优先级固定 150/120/100；角色分布是<strong>一主一备一从</strong>（具体谁当 Master 会随故障演练变化）</td>
<td>只看一台的 <code>display stack</code> 不成立；各可读成员的说法必须一致，且看到同一个 Master MAC</td>
</tr>
<tr>
<td>TOPO</td>
<td><code>Ring</code>；每个成员两个堆叠口 up 且邻居正好是另外两台</td>
<td>断一条链后应变成 <code>Link</code>（链形拓扑）而成员数仍是 3（F1）；脚本同时接受 <code>Link</code>/<code>Chain</code></td>
</tr>
<tr>
<td>PROTO</td>
<td>每个堆叠口 Hello/Detect 收发 > 0</td>
<td>接口计数不算堆叠报文，必须进 diagnose 视图看</td>
</tr>
<tr>
<td>LACP</td>
<td>堆叠侧 2/2 Selected 且成员分属两个 slot；ACC1 2/2 Selected；Partner System ID = 堆叠 MAC</td>
<td>单成员 Selected 不能证明跨框</td>
</tr>
<tr>
<td>DATA</td>
<td>PC1↔PC2、PC→ACC1、PC→堆叠 Vlanif 全部 5/5</td>
<td>用唯一 <code>-l</code> 载荷计数，避免 VPCS 输出串台</td>
</tr>
</tbody>
</table>
<h3>7.1 故障场景（<code>--fault</code>）</h3>
<table>
<thead>
<tr>
<th>场景</th>
<th>注入</th>
<th>判据</th>
</tr>
</thead>
<tbody>
<tr>
<td>F1 断环</td>
<td>suspend SW2↔SW3 堆叠链路</td>
<td>拓扑 <code>Ring</code>→<code>Link</code>（华为对单路径的显示值，不是 <code>Chain</code>），成员数仍为 3；PC1→PC2、PC1→ACC1 仍 5/5；resume 后回到 <code>Ring</code></td>
</tr>
<tr>
<td>F2 成员下线</td>
<td>stop SW2（非主成员）</td>
<td>master 看到成员数降到 2；Eth-Trunk1 剩 1 个 Selected 仍转发；start 后重新入栈（成员数回 3）</td>
</tr>
<tr>
<td>F3 主备切换</td>
<td>先读真实 Master，再 stop 它</td>
<td>剩余成员中产生新 Master（由原<strong>Standby</strong> 接管，不是优先级第二的成员）；PC2→ACC1 仍 5/5；start 后重新入栈</td>
</tr>
<tr>
<td>F4 堆叠分裂</td>
<td>同时断开 SW1 的两个堆叠口</td>
<td>对侧分区只剩 member 2/3 且有 Master；SW1 分区独立运行；两侧 <code>display dual-active</code> 均为 <code>Conflict</code>（Huawei 语义）；按 stack priority 判胜负：SW1（150）胜，PC1→自己分区 Vlanif 5/5；对侧 master（100）败，PC2 输出 <code>not reachable</code>（业务口被 Error-Down）；恢复链路后<strong>不保证自动合并</strong>——本次败方分区重载后 15 分钟仍未重新入栈，需整 lab stop/start</td>
</tr>
</tbody>
</table>
<blockquote>
<p><strong>F4 的实测要点（2026-11-04 工作 MAD 下复测）</strong>：分裂期间不能用 ACC1 探数据面——ACC1 的 Eth-Trunk 两个成员分别落在两个分区，LACP 看到两个不同的系统 ID，整条 trunk 会停转发；两个分区本身是活的（实测 <code>2:Standby 3:Master</code> 与 <code>4:Master</code>），所以改打各自分区的堆叠 Vlanif。Huawei 的 <code>display dual-active</code> 在分裂时<strong>两侧都显示 <code>Conflict</code></strong>（不是一侧 <code>Recovery</code>），胜负只能从数据面看：SW1（priority 150）胜，PC1→.254 为 5/5；对侧 master（100）败，PC2 输出 <code>host (192.168.10.254) not reachable</code>。胜方的 relay 检测口先显示 <code>up (Physical) / up (Protocol) / PeerDomain 10</code>，约一个 LACP 超时后变成 <code>up (Physical) / down (Protocol) / PeerDomain --</code>——因为 ACC1 的 Eth-Trunk 同时看到两个系统 ID，这是 relay 代理在真实分裂下的副作用，不是 MAD 没生效。恢复链路后不会立刻合并：败方分区一侧会整机重载（串口出现 <code>Set the next startup package successfully</code> / <code>syspkg_verify process end</code>），<strong>但本次恢复链路后 15 分钟仍未重新入栈</strong>（PC2 始终 <code>host not reachable</code>，SW1 的 <code>display stack</code> 只剩 member 4），最后对整 lab 做 stop/start 才重新拉起。<strong>在这台模拟器上别把“接回链路”当成恢复手段</strong>：F4 之后要预留整 lab 重启的时间。</p>
<p>脚本不绑定固定读表源：每轮从当前存活成员里挑控制台可用的一台读成员表；F3 先读真实 Master 再停它（角色可能已被前面的演练改过），F4 分裂后两侧选举最多等 90 秒。断一条链后华为显示 <code>Stack Topology Type: Link</code>，本脚本同时接受 <code>Link</code>/<code>Chain</code>。</p>
<p><strong>工作 MAD 下的分裂结论（2026-11-04）</strong>：早期“MAD 下应有一侧进入 <code>Recovery</code>”的说法来自 H3C IRF，Huawei 命令参考没有这个取值，已作废。ACC1 改正为 <code>dual-active proxy</code> 后重新注入 F4：两侧 <code>display dual-active</code> 均为 <code>Conflict</code>，SW1 侧 PC1 5/5、对侧 PC2 <code>not reachable</code>；恢复链路后败方分区重载但 15 分钟内没有重新入栈，最终用整 lab stop/start 恢复。</p>
<p><strong>F2/F3 的实测限制（如实记录）</strong>：<code>--fault</code> 把 F1 放在最前，<code>link_suspend</code> 恢复后 agent 会假死 1~2 分钟，紧接着的 <code>eve_iac_stop/start</code> 连续失败（原始错误 <code>Command failed</code>，成员数一直 3），所以 F2 的“成员数降到 2”没有拿到单次成功记录；F3 的 stop 成功（<code>stop n_1 requested</code>）、剩余成员继续转发 5/5、start 后 count 回到 3，但“新 Master 在 120 秒内可读”受成员控制台假死影响没抓到；<strong>下一次运行开头的 <code>display stack</code> 显示 <code>3:Master</code>（原 Standby 接管）</strong>，与预期一致。需要单次全绿时建议先跑 <code>--links-only</code>（F1/F4），再单独手工做 F3 的 stop/start，或把 F1 挪到最后。</p>
</blockquote>
<h3>7.2 Traffic Filters 面板该看到什么</h3>
<table>
<thead>
<tr>
<th>Filter</th>
<th>表达式要点</th>
<th>预期</th>
</tr>
</thead>
<tbody>
<tr>
<td>ARP-Request（红）</td>
<td><code>arp = 1</code></td>
<td>PC 首次 ping 前会亮，ARP 老化后再次 ping 会重新亮</td>
</tr>
<tr>
<td>ARP-Reply（绿）</td>
<td><code>arp = 2</code></td>
<td>与 Request 成对出现</td>
</tr>
<tr>
<td>ICMP-Request（蓝）</td>
<td><code>icmp == 8</code></td>
<td>每次 ping 亮 5 个</td>
</tr>
<tr>
<td>ICMP-Reply（黄）</td>
<td><code>icmp == 0</code></td>
<td>与 Request 成对</td>
</tr>
<tr>
<td>LACP（紫）</td>
<td><code>ether proto 0x8809</code></td>
<td>持续低速闪烁（30s 一次，Slow 模式）</td>
</tr>
<tr>
<td>STP-BPDU（蓝灰）</td>
<td><code>ether dst 01:80:c2:00:00:00</code></td>
<td>持续闪烁</td>
</tr>
<tr>
<td>ICMPv6-Neg（粉）</td>
<td><code>icmp6</code></td>
<td><strong>故意不亮</strong>：本实验没有 IPv6 流量，用来反证过滤器不是“见包就亮”</td>
</tr>
</tbody>
</table>
<p>截图时如果想让 ARP 明显亮，先把 timeout 临时调到 2000ms，截完改回 500ms——注意改参数会清零面板计数。</p>
<h2>8. 踩坑清单（按“会骗到你”的程度排序）</h2>
<ol>
<li><strong>堆叠链路两端同一物理口号 = 自环</strong>。模拟器在 <code>display stack troubleshooting current</code> 里报：<br />
<code>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)</code>。<br />
症状是 SW1 的堆叠口 up、Hello 也在发，但永远入不了栈。<strong>把三条链路改成两端端口号都不同</strong>（9↔8、10↔9、8↔10）后一次成型。换 <code>Stack-Port1/2</code> 分组没用。</li>
<li><strong>堆叠刚形成时写配置报 <code>The system is busy in synchronizing configurations to the slave board</code></strong>。此时 <code>system-view</code> 能进，但 <code>vlan</code> / <code>interface</code> 全部被拒。<strong>在 master 上 <code>save</code> 一次</strong>（会依次写所有 slot）之后恢复。别在这段时间反复重试，也别以为命令不存在。</li>
<li><strong>热插拔链路会让上行假死</strong>。运行中用 <code>eve_iac_edit</code> 改链路端点 + reconcile，ACC1 两条上行在交换机侧都变 down（对端还显示 up），LACP 收发都是 0。<strong>拓扑改了就走整机 stop/start</strong>，让链路在开机时重新接线；重启后 2/2 立刻 Selected。</li>
<li><strong>Master 按“启动状态 → 优先级 → MAC”选，Standby 按连接关系选</strong>：3 成员是 <code>Master / Standby / Slave</code>。Master 选举依次看<strong>启动状态（最先完成启动并进入单机运行的设备优先）→ 优先级 → 系统 MAC →（部分版本再看堆叠 ID）</strong>；只有同时启动才比较优先级。已经运行的堆叠不会被后来加入的更高优先级设备抢占。本实验三台一起拉起，实测 150 的 member 4 当选（与优先级一致）。Master 选完后，<strong>优先选与 Master 的 Stack-Port n/1 相连的设备为 Standby</strong>（受启动时间和堆叠口 up 时间影响，也可能选 n/2 方向的设备），其余为 Slave。所以<strong>优先级第二高不一定是 Standby</strong>：首次成栈实测 member 4（150）= Master、member 3（100）= Standby、member 2（120）= Slave——member 3 正接在 member 4 的 Stack-Port 4/1 方向（<code>GE4/0/10 ↔ GE3/0/8</code>），符合规则。<code>display stack</code> 的 <code>Priority</code> 列只是配置值，角色直接读 <code>Role</code> 列。<strong>主设备下线后由 Standby 接管，原 Master 重新入栈也不会抢回</strong>：停掉 member 4 后实际是 member 3（原 Standby，100）成为 Master、member 2（120）仍是 Slave；故障演练后角色分布会与首次成栈不同，脚本只校验「一主一备一从 + 各视图一致」，不写死谁当 Master。</li>
<li><strong>全栈 sysname 统一成 master 的</strong>，三台控制台提示符都是 <code><SW1></code>。验收脚本不能按节点名匹配提示符。</li>
<li><strong><code>display stack-port statistics</code> 只在 diagnose 视图</strong>（<code>system-view</code> → <code>diagnose</code> → 命令 → <code>quit</code> ×2）。普通视图没有这条命令。</li>
<li><strong><code>port member-group</code> 两次 Y/N，<code>undo</code> 零确认</strong>。批量脚本里给错步数会卡在确认问句。</li>
<li><strong><code>console_run</code> 的 expect 只匹配本步新收到的字节</strong>；控制台空闲退回 <code>Password:</code> 后，先发空行诱出提示符，落在 <code>Password:</code> 就用 <code>send_secret</code> 重登。expect 是正则，<code></code> 要转义成 <code>\</code>。</li>
<li><strong>Slave 成员的控制台在本镜像里完全无输出</strong>（停在 <code>Devma ... The board is registered</code> 或 <code>syspkg_verify process end.</code>，回车无回显），但设备在栈里一切正常。遇到控制台“死”<strong>先看 <code>display stack</code> 确认角色</strong>——如果它是 Slave，这是本镜像的已知限制，不是配置；同一设备换成 Master/Standby 后控制台立刻可用，重启治不好（见 §9）。</li>
<li><strong>把堆叠侧 MAD 命令配到代理设备上，会伪装成“模拟器不支持”</strong>：ACC1 配 <code>dual-active detect mode relay</code> 时命令被接受，但 <code>display dual-active</code> 一直 <code>Initial</code>、成员口 <code>down(Protocol)</code>、<code>PeerDomain --</code>；改成 <code>dual-active proxy</code>（部分版本 <code>mad relay</code>）后，同样两台设备立刻变成 <code>Dual-active status: Normal</code>、成员口 <code>up (Physical) / up (Protocol)</code>、<code>PeerDomain 10</code>。命令分工：<strong>堆叠侧 <code>dual-active detect mode relay</code>，代理设备 <code>dual-active proxy</code></strong>。</li>
</ol>
<h2>9. 已知限制</h2>
<ul>
<li><strong>LACP MAD relay 在分裂时的状态是 <code>Conflict</code>，不是 <code>Recovery</code></strong>：早期把 ACC1 配成堆叠侧的 <code>dual-active detect mode relay</code>，<code>display dual-active</code> 停在 <code>Initial</code>，很容易误判为模拟器不支持；改成 <code>dual-active proxy</code> 后正常态为 <code>Normal</code>（成员口 <code>up (Physical) / up (Protocol)</code>、<code>PeerDomain 10</code>）。工作 MAD 下重新注入分裂，两侧都显示 <code>Conflict</code>；Huawei 命令参考的取值只有 <code>Normal / Conflict / Initial</code>，没有 H3C IRF 的 <code>Recovery</code>。</li>
<li><strong>分裂期间 ACC1 的 Eth-Trunk 会整体停转发</strong>：两个成员口分别落在两个独立栈上，LACP 对端变成两个不同的系统 ID，整条 trunk 会停转发；胜方的 relay 口也会在一个 LACP 超时后从 <code>up/up</code> 变成 <code>down(Protocol)</code>。这不是分区死了：胜方分区（本实验 SW1）的 PC1 打自己的堆叠 Vlanif 仍是 5/5，败方分区的 PC2 才是 <code>not reachable</code>（业务口被 MAD 置 Error-Down）。验证分区存活要打各自分区的堆叠 Vlanif。</li>
<li><strong>恢复分裂后不保证自动合并</strong>：两个独立栈重新接线后，败方分区会整机重载（串口出现 <code>Set the next startup package successfully</code> / <code>syspkg_verify process end</code>），但<strong>2026-11-04 这次 15 分钟仍未重新入栈</strong>（SW1 只剩 member 4、PC2 一直 <code>not reachable</code>）；最终只能对整 lab 做 stop/start。别用“接回链路”当恢复手段，也别用几分钟判失败——直接预留整 lab 重启的时间。</li>
<li>堆叠配置不随 <code>running-config</code> 保存；wipe 后必须重新引导（§6 第 7 步）。</li>
<li><strong>这台模拟器的 Slave 成员控制台不可用（跟着角色走，不是设备坏了）</strong>：堆叠稳定后，Slave 的串口停在 <code>Devma ... The board is registered</code>（有时是 <code>syspkg_verify process end.</code>），敲回车没有 <code>Password:</code>；同一块设备换成 Master/Standby 后控制台立刻可读。四次角色互换的验收里，卡住的设备依次是 SW2、SW1、SW3、SW2——<strong>每次都正好是当时的 Slave</strong>，Master 和 Standby 都能读。本实验只把它作为<strong>该镜像的实测限制</strong>记录，不推断真机行为——真机上从 Slave 的 Console 能否登录，本环境无法验证。重启修不好：重新入栈后只要还是 Slave 就仍然卡。验收脚本因此不绑定固定读表源：Slave 的角色/优先级用 Master 或 Standby 的 <code>display stack</code> 视图交叉核对，读不到记 <code>SKIP</code>，不当配置故障。</li>
</ul>
<h2>10. 附录</h2>
<h3>10.1 附件</h3>
<p>附件包 <code>附件/s6700-istack.zip</code>（265,293 字节，SHA-256 <code>03a1786736f39f5a321a1886cb3c7813abdeacbd790b725353f2fdac72dc59f0</code>）内含 <code>topology.yml</code>、<code>.eve-iac.yml</code>、逐台启动配置（<code>configs/default/</code>）、<br />
手工堆叠引导步骤（<code>stack-bootstrap.md</code>）、拓扑图（<code>topology.png</code>）、文件说明与 SHA-256 表（<code>README.md</code>）。<br />
验收脚本 <code>tools/s6700-istack-verify.js</code> 依赖本仓库的 <code>tools/eve-mcp.js</code>，随仓库提供，不放进压缩包。</p>
<h3>10.2 关键命令速查</h3>
<pre><code class="language-text">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 收发计数
</code></pre>
<h3>10.3 版本记录</h3>
<ul>
<li>2026-11-03：首次实测；3 成员环形堆叠 + 跨框 Eth-Trunk 通过。当时把堆叠侧命令配到了 ACC1 上，<code>display dual-active</code> 停在 <code>Initial</code>，误判为 relay 协议不协商。</li>
<li>2026-11-04：修正 LACP MAD 命令分工（堆叠侧 <code>dual-active detect mode relay</code>，代理设备 ACC1 用 <code>dual-active proxy</code>/<code>mad relay</code>）——改正后 <code>display dual-active</code> 实测为 <code>Normal</code>，早前停在 <code>Initial</code> 是 ACC1 命令配错造成的误判；按官方规则重写 Standby 选举说明，统一 <code>Link</code> 写法；附件包补 README 与 SHA-256 表。</li>
<li>2026-11-04（补测）：工作 MAD 下重跑 F4 分裂——两侧 <code>display dual-active</code> 均为 <code>Conflict</code>（Huawei 取值只有 <code>Normal/Conflict/Initial</code>，没有 <code>Recovery</code>），SW1（priority 150）胜、PC1 5/5，对侧（priority 100）败、PC2 <code>not reachable</code>；胜方 relay 口在 LACP 超时后变成 <code>down(Protocol)</code>。旧稿“一侧 Recovery”结论作废。</li>
<li>2026-11-04（恢复复测）：F4 后仅接回两条堆叠链路，败方分区重载但 15 分钟仍未重新入栈（SW1 只剩 member 4、PC2 <code>not reachable</code>），最终整 lab stop/start 才恢复三成员（2 Slave / 3 Standby / 4 Master）。恢复后常规验收复跑 <strong>40 PASS / 0 FAIL / 2 SKIP</strong>；附件包按 MCP 回读重建，zip 265,293 字节、SHA-256 <code>03a1786736f39f5a321a1886cb3c7813abdeacbd790b725353f2fdac72dc59f0</code>。</li>
<li>2026-11-04（更正）：控制台不可用是 <strong>Slave 角色</strong>相关，不是“哪个成员重启就坏”。历史验收里卡住的设备依次是 SW2、SW1、SW3、SW2，每次都正好是当时的 Slave；同一设备换成 Master/Standby 后控制台立刻可读。这条只作为该镜像的实测限制记录，不推断真机行为（真机上从 Slave 的 Console 能否登录，本环境无法验证）。</li>
</ul>

mmc2000 发表于 6 天前

zblff123 发表于前天 13:25

页: [1]

EmulatedLab's Archiver

实验案例：华为 S6730H 三机 iStack 堆叠