板块4 · 链路聚合 LACP 与 Trunk
板块4 · 链路聚合 LACP 与 Trunk
目标与定位：吃透 LACP 协议原理、状态机、两套命令体系（盒式体系A / 机架式体系B）配置写法、负载分担哈希策略、跨厂商对接与验收测试，形成从原理到现网交付的完整能力链。
权重提醒：链路聚合在 ZCIA 大纲仅占 5%，但在 ZCIP / ZCIE 工程项目里是必配项——核心节点几乎不存在不跑聚合的场景。答辩时"聚合 + STP + VLAN"的组合设计是专家高频追问区，属于"分少但必会"的知识模块。
学习路径：原理 → 命令 → 配置实例 → 验证测试 → 故障排查 → 考点速记，六段式展开。
4_1 链路聚合基础
本节要解决什么问题：先回答一个问题：为什么有了 STP 还要聚合？因为 STP 会闲置一半带宽，而聚合能把冗余链路全部用起来。
4_1_1 为什么需要聚合：从单链路痛点说起
单条物理链路存在三个硬伤：带宽天花板（一条 10G 就是 10G，无法突破）、单点故障（链路断了业务全断）、STP 浪费（多条链路靠 STP 阻塞冗余链路，利用率 50%）。链路聚合（Link Aggregation）将多条物理链路捆绑成一条逻辑链路，在二层对外呈现为单个端口，从根本上解决这三个问题。
不聚合（两条链路靠 STP 阻塞一条）：
SW-A ═══ 10G ═══ SW-B 实际可用带宽 10G
SW-A ┈┈┈ 10G ┈┈┈ SW-B 备份链路，被 STP 阻塞
→ 带宽浪费 50%，切换靠 STP 收敛（秒级甚至 30 秒级）
聚合（两条链路绑成一条逻辑链路）：
SW-A ═══ 10G ═══ SW-B ┐
SW-A ═══ 10G ═══ SW-B ┴─► 逻辑链路 Trunk 1，可用带宽 20G
→ 两条同时转发（负载分担），一条断了流量秒级切到另一条
→ STP 看到的是"一条链路"，不会阻塞任何成员
关键理解：聚合不是简单的"两条 10G 叠加"，而是在流（Flow）级别进行负载分担。同一条 TCP 连接的全部报文必须走同一条成员链路（否则会乱序），不同流则分散到不同链路。因此聚合的带宽叠加效果取决于流的数量——单条大流永远只能占用一条成员链路的带宽。
三大价值：
| 价值 | 具体表现 | 工程意义 |
|---|---|---|
| 带宽倍增 | N 条成员链路逻辑上合并为 N×带宽 | 无需升级单端口速率即可扩展 |
| 链路冗余 | 一条成员故障，其余继续转发 | 毫秒级收敛，业务几乎无感知 |
| 负载分担 | 多条流分散到不同成员链路 | 提高链路利用率，避免单链路拥塞 |
4_1_2 两种聚合方式：静态聚合 vs 动态 LACP
| 方式 | 协议 | 特点 | 风险 | 适用场景 |
|---|---|---|---|---|
| 静态聚合 | 无协议 | 手工将端口捆绑为一组 | 不检测对端状态；单纤/错连可能导致"黑洞" | 对端不支持 LACP 的老设备 |
| 动态聚合（LACP） | IEEE 802.3ad | 通过 LACPDU 协商，自动检测成员有效性 | 需要两端模式匹配 | 生产环境首选 |
静态聚合的致命缺陷：静态模式下，设备不会和对端交换协议报文。如果对端端口实际上已经 down、或者对端根本没配聚合，本端仍然认为聚合组成立，继续往那条链路转发——结果是黑洞丢包，且极难排查。LACP 通过周期性的 LACPDU 握手彻底解决了这个问题。
生产环境原则：能用 LACP 就用 LACP。静态聚合只在对接不支持 LACP 的设备（如部分老服务器、专用设备、某些存储设备）时使用。ZCIE 答辩时如果考生选择静态聚合而没有给出充分理由，会被追问"为什么不跑 LACP"。
4_1_3 术语对照（本库统一叫法）
| 通用术语 | 中兴体系 A（盒式） | 中兴体系 B（机架式） | 华为 | H3C |
|---|---|---|---|---|
| 聚合组 | trunk（trunkid） | smartgroup | Eth-Trunk | Bridge-Aggregation |
| 聚合模式 | dynamic / static / mixed | 802.3ad / static | lacp-static / manual | dynamic / static |
| 成员端口 | port | interface | 成员接口 | 成员端口 |
| 负载分担 | 芯片默认策略 | smartgroup load-balance |
load-balance |
link-aggregation load-sharing |
| 加入聚合组 | set lacp aggregator X add port Y |
物理口下 smartgroup X mode active |
trunkport |
port link-aggregation group |
【重要】中兴体系 A 里 "trunk" 指的是聚合组，不是"VLAN Trunk（干道）"。这两个概念在华为、H3C 等设备里是分开的（
trunk= 允许多 VLAN 通过的干道口，Eth-Trunk= 聚合组），但在中兴盒式设备里trunk就是聚合组。看到set vlan 2 add trunk 3 tag时，这里的trunk 3是聚合组 3，不是 VLAN 干道。这个混淆是 ZCIA 判断题的高频陷阱。
4_1_4 聚合组的工作边界
┌─────────────────────────────────────────────────────────────────┐
│ 聚合组对外表现为一个"逻辑端口" │
│ │
│ SW-A SW-B │
│ ┌─────────┐ member1 ┌─────────┐ │
│ │ port15 ├───────────────┤ port23 │ │
│ │ │ member2 │ │ │
│ │ port16 ├───────────────┤ port24 │ │
│ │ │ │ │ │
│ │ trunk 3 │ │ trunk 1 │ │
│ └────┬────┘ └────┬────┘ │
│ │ │ │
│ └─── 逻辑上 = 一条链路 ───┘ │
│ │
│ STP 视角：只有 1 条链路（不会阻塞任何成员） │
│ MAC 表视角：MAC 地址绑定到 trunk 3（不是 port15/16） │
│ VLAN 视角：把 trunk 3 当作普通端口加入 VLAN │
└─────────────────────────────────────────────────────────────────┘
核心原则：聚合组成立后，所有二层操作（VLAN 成员关系、PVID、STP、MAC 学习、广播风暴抑制）都以逻辑聚合口为对象，不再对成员物理口做单独配置。这是后续所有配置的铁律。
4_2 LACP 原理与状态机
本节要解决什么问题：聚合配置的核心不在命令，而在「两端凭什么认为彼此可以绑在一起」。本节把 LACPDU、匹配要素、模式与超时讲透。
4_2_1 LACPDU 报文结构与关键字段
LACPDU（Link Aggregation Control Protocol Data Unit）是 LACP 的协议报文，封装在 Ethernet II 帧中，目的 MAC 为 01-80-C2-00-00-02（IEEE 慢速协议组播地址），EtherType 为 0x8809。交换机每 1 秒（短超时）或每 30 秒（长超时）发送一次。
┌──────────────────────────────────────────────────────────────────────┐
│ LACPDU 报文结构 │
├──────────────────────────────────────────────────────────────────────┤
│ Destination MAC: 01-80-C2-00-00-02 (Slow Protocols Multicast) │
│ Source MAC: 本端口 MAC │
│ EtherType: 0x8809 │
├──────────────────────────────────────────────────────────────────────┤
│ Subtype: 0x01 (LACP) │
│ Version: 0x01 │
│ TLV Type: Actor Information (0x01) │
│ ├─ Actor System Priority (2 bytes) → 系统优先级（默认 32768） │
│ ├─ Actor System MAC (6 bytes) → 系统 MAC（通常是桥 MAC） │
│ ├─ Actor Port Priority (2 bytes) → 端口优先级（默认 32768） │
│ ├─ Actor Port Number (2 bytes) → 端口编号 │
│ ├─ Actor Key (2 bytes) → 操作 Key（标识可聚合组） │
│ ├─ Actor State (1 byte) → 状态位（见下方） │
│ TLV Type: Partner Information (0x02) │
│ └─ 对端信息（格式同上） │
│ TLV Type: Collector Information (0x03) │
│ └─ 收集器信息（Max Delay） │
│ TLV Type: Terminator (0x00) │
└──────────────────────────────────────────────────────────────────────┘
Actor State 状态位（1 byte，bit0 ~ bit7）：
bit0: LACP_Activity (1=Active, 0=Passive)
bit1: LACP_Timeout (1=Short, 0=Long)
bit2: Aggregation (1=可聚合, 0=不可聚合)
bit3: Synchronization (1=已同步, 0=未同步)
bit4: Collecting (1=可收集, 0=不可收集)
bit5: Distributing (1=可分发, 0=不可分发)
bit6: Defaulted (1=默认配置, 0=已收到对端信息)
bit7: Expired (1=已过期, 0=未过期)
关键字段解读：
- 系统优先级 + 系统 MAC：用于在两端之间选举出唯一的"主设备（Actor）"，主设备决定哪些端口被选为活动成员。优先级数值越小越优先；优先级相同时比较 MAC 地址，小者优先。
- 端口优先级 + 端口编号：当活动端口数量受限（如 active-max 限制）时，用于决定哪些端口入选。数值越小越优先。
- 操作 Key（Operational Key）：标识"可以聚合在一起"的一组端口。同一聚合组的成员端口必须具有相同的 Key。Key 由系统根据端口的物理参数（速率、双工）自动生成。
- 状态位：反映端口当前的协商状态。特别是
Synchronization、Collecting、Distributing三个位，直接对应 Mux State Machine 的状态。
4_2_2 形成聚合必须匹配的六要素
以下是 LACP 协商成功的必要条件，缺一不可。这是 ZCIA 判断题和 ZCIP 排障的高频考点，必须背熟：
| # | 要素 | 说明 | 不匹配的后果 |
|---|---|---|---|
| 1 | 端口速率一致 | 所有成员端口速率必须相同（如全 10G） | 速率不同的端口无法加入同一聚合组 |
| 2 | 双工模式一致 | LACP 要求全双工，半双工不能聚合 | 半双工端口被排除，报配置错误 |
| 3 | VLAN 配置一致 | 成员端口的 VLAN 成员关系、PVID 必须一致 | 部分 VLAN 丢包、聚合组无法建立 |
| 4 | 链路类型一致 | Access / Trunk / Hybrid 属性一致 | 报文转发异常 |
| 5 | Key 一致 | 同组端口物理参数相同，自动生成相同 Key | Key 不同的端口无法聚合 |
| 6 | 至少一端为 Active | 两端不能都是 Passive | 双方都不发 LACPDU，协商永远不成功 |
【踩坑】要素 3 和 4 是最容易被忽略的：很多工程师先把 VLAN 配置在物理口上，然后再建聚合组，结果物理口的 VLAN 配置和聚合组冲突。正确做法是先建聚合组，再对逻辑口做 VLAN 配置（详见 4_3_5 配置顺序铁律）。
4_2_3 主动/被动模式组合矩阵
| 本端 | 对端 | 结果 | 说明 |
|---|---|---|---|
| Active | Active | ✅ 聚合成功 | 推荐配置，双方都主动发 LACPDU |
| Active | Passive | ✅ 聚合成功 | 可用，Active 端发起协商 |
| Passive | Active | ✅ 聚合成功 | 可用，对端发起协商 |
| Passive | Passive | ❌ 不聚合 | 双方都不主动发 LACPDU，永远等不到对方 |
LACP 模式矩阵（ASCII 状态图）：
┌──────────┐ LACPDU ┌──────────┐
│ Active │ ──────────────────────► │ Active │ ✅ 成功
│ (发起) │ ◄────────────────────── │ (发起) │
└──────────┘ └──────────┘
┌──────────┐ LACPDU ┌──────────┐
│ Active │ ──────────────────────► │ Passive │ ✅ 成功
│ (发起) │ ◄────────────────────── │ (回应) │
└──────────┘ └──────────┘
┌──────────┐ 等 ... 等 ... 等 ┌──────────┐
│ Passive │ │ Passive │ ❌ 失败
│ (沉默) │ 永远不发 LACPDU │ (沉默) │
└──────────┘ └──────────┘
【ZCIA 高频考点】判据明确：本端为
passive时，对端必须配置为active。 这句话是判断题的标准表述，记住"Passive 永远不会主动发起协商，必须有人先开口"。工程建议：两端都配 Active 是最稳妥的选择。只在对接第三方设备且对方明确要求 Passive 时才用 Passive。
4_2_4 超时机制：短超时 3 秒 vs 长超时 90 秒
| 模式 | LACPDU 发送周期 | 超时判定时间 | 收敛速度 | 适用场景 | CPU 开销 |
|---|---|---|---|---|---|
短超时 short |
1 秒 | 3 秒 | 快（3 秒内检测故障） | 核心链路、要求快速收敛 | 略高 |
长超时 long |
30 秒 | 90 秒 | 慢（最长 90 秒才判定） | 普通接入链路、默认 | 低 |
超时机制时序：
短超时（short）：
时刻 0s ──► 发送 LACPDU #1
时刻 1s ──► 发送 LACPDU #2
时刻 2s ──► 发送 LACPDU #3
时刻 3s ──► 未收到对端 LACPDU → 判定超时 → 端口状态变更
长超时（long）：
时刻 0s ──► 发送 LACPDU #1
时刻 30s ──► 发送 LACPDU #2
时刻 60s ──► 发送 LACPDU #3
时刻 90s ──► 未收到对端 LACPDU → 判定超时 → 端口状态变更
配置命令（体系 A）：
zte(cfg)#set lacp port 23-24 timeout short
【ZCIP 设计要点】短超时的代价与收益：短超时能加快故障检测（3 秒内完成收敛），但 LACPDU 报文频率高（每秒一次），CPU 负担略增。在大规模聚合组场景下（如一台设备有 20+ 聚合组），全部使用短超时可能累积可观的协议开销。工程经验：核心互联链路用短超时，接入链路用长超时（默认），实现收敛速度与资源消耗的平衡。具体阈值依型号/软件版本不同，现场用
?帮助确认。
4_2_5 LACP 状态机（Selection Logic & Mux State Machine）
LACP 协议内部有两套关键状态机：选择逻辑（Selection Logic） 决定哪些端口被选为活动成员，Mux 状态机 决定端口是否开始收发数据。
选择逻辑（Selection Logic）：
┌──────────────────────────────────────────────────────────────────┐
│ Step 1: 端口是否启用？物理链路是否 UP？ │
│ ├─ NO → 排除（Not Selected） │
│ └─ YES ↓ │
│ Step 2: LACP 参数是否匹配？（速率/双工/Key/VLAN/链路类型） │
│ ├─ NO → 排除（Not Selected） │
│ └─ YES ↓ │
│ Step 3: 是否满足 Active 条件？（至少一端 Active） │
│ ├─ NO → 排除（Not Selected） │
│ └─ YES ↓ │
│ Step 4: 比较系统优先级，选举 Actor │
│ └─ Actor 决定哪些端口进入 Selected 状态 │
│ Step 5: 如有 active-max 限制，按端口优先级选前 N 个 │
│ └─ 未被选中的端口 → Standby（热备） │
└──────────────────────────────────────────────────────────────────┘
Mux 状态机（Mux State Machine）：
| 状态 | 含义 | 是否转发数据 |
|---|---|---|
| Detached | 端口未附加到聚合组，独立工作 | ❌ |
| Waiting | 等待对端响应（过渡状态） | ❌ |
| Attached | 已附加到聚合组，但尚未同步 | ❌ |
| Collecting | 开始收集对端报文（Inbound OK） | 部分 |
| Distributing | 开始分发本地报文（Outbound OK） | ✅ |
| Collecting & Distributing | 完全正常工作状态 | ✅ |
Mux State Machine 状态迁移：
┌─────────┐ attach ┌──────────┐
│ Detached │ ──────────► │ Waiting │
└─────────┘ └────┬─────┘
│ partner sync
▼
┌──────────┐ sync ok ┌──────────────┐
│ Attached │ ────────────► │ Collecting │
└──────────┘ └──────┬───────┘
│ collecting ok
▼
┌──────────────┐
│ Distributing │
└──────┬───────┘
│ both ok
▼
┌──────────────────┐
│ Collecting & │
│ Distributing │
│ (= 正常工作) │
└──────────────────┘
【验证】
show lacp internal输出中的关键状态：
Selected：端口被选择为活动成员Unselected：端口未被选择（参数不匹配 / 优先级不够）Standby：端口参数匹配但处于热备（active-max 限制下未被选中的端口）- Mux State 长期处于
Waiting或Detached→ 协商未成功，按 4_7 决策树排查
4_2_6 【案例故事】两端都配成 Passive，业务只跑单条 10G
这是我自己踩过的坑，至今记忆犹新。
那天凌晨两点，客户投诉核心链路带宽不够。拓扑是两台 5960 通过两条 10G 互联，按理说应该 20G。我登上去一看：
ZXR10#show lacp 1 internal Smartgroup: 1 Port Agg State Oper Key Port Priority RX Machine Mux State gei-0/5/0/23 Unselected 0x0001 32768 Waiting Detached gei-0/5/0/24 Unselected 0x0001 32768 Waiting Detached两个端口全是
Unselected，Mux 状态Waiting/Detached——聚合根本没起来！两条 10G 中只有一条在转发（STP 没阻塞是因为根本没形成聚合，实际上只有物理链路在工作）。第一反应是检查物理层：
show interface gei-0/5/0/23UP，show interface gei-0/5/0/24UP。物理没问题。然后看 LACPDU 计数：
show lacp 1 counters——收发都是 0！说明协议报文根本没在交换。检查配置才发现问题：
ZXR10(config-if)#smartgroup 1 mode passive ← 本端 passive对端也是 passive。两个人都沉默，永远等不到对方的 LACPDU。
根因：前一天变更时，工程师从模板复制配置，模板里写的是
passive（因为对接某品牌服务器时对方要求 passive），但忘了改回active。修复（30 秒搞定）：
ZXR10(config)#interface gei-0/5/0/23 ZXR10(config-if)#smartgroup 1 mode active ZXR10(config-if)#exit ZXR10(config)#interface gei-0/5/0/24 ZXR10(config-if)#smartgroup 1 mode active ZXR10(config-if)#exit改完 3 秒后
show lacp 1 internal显示两个端口都变成Selected，Mux 状态Collecting & Distributing。用 iperf 多线程测试，吞吐从 9.8G 直接飙到 18.5G。教训：从那以后我养成了习惯——每次配聚合，两端都显式写
mode active，不做任何假设。这个坑也写进了团队的配置模板。
4_3 体系 A（盒式）LACP 配置
本节要解决什么问题：盒式设备用 set lacp 体系。本节给出命令全表、三种模式与两个实例，并给出必须遵守的配置顺序。
4_3_1 LACP 命令全表（10 条）
以下是体系 A 的全部 10 条 LACP 命令，每条都补充了"现场怎么用 / 配错什么现象 / 怎么验证"：
| # | 功能 | 命令 | 缺省值 | 现场用法 | 配错现象 | 验证方法 |
|---|---|---|---|---|---|---|
| 1 | 使能/关闭 LACP | set lacp {enable|disable} |
disable（关闭） | 全局开启，必须在所有聚合配置之前执行 | 后面所有聚合配置都无效 | show lacp |
| 2 | 聚合组添加端口 | set lacp aggregator [trunkid] add port [portlist] |
— | 建组时一次性加入所有成员口 | 漏加端口则少一条链路 | show lacp aggregator |
| 3 | 聚合组删除端口 | set lacp aggregator [trunkid] delete port [portlist] |
— | 变更时移除故障成员口 | 删不掉检查是否正在转发 | show lacp aggregator |
| 4 | 设置聚合组模式 | set lacp aggregator [trunkid] mode {dynamic|static|mixed} |
dynamic | 对接 LACP 设备用 dynamic | 两端模式不匹配则不聚合 | show lacp aggregator |
| 5 | 端口聚合超时 | set lacp port [portlist] timeout {long|short} |
long（90s） | 核心链路设 short（3s） | 长超时下故障检测慢 | show lacp port |
| 6 | 端口协商模式 | set lacp port [portlist] mode {active|passive} |
active | 两端至少一端 active | 两端 passive 则不聚合 | show lacp port |
| 7 | LACP 优先级 | set lacp priority [1-65535] |
32768 | 控制 Actor 选举 / 活动端口选择 | 优先级设计不合理导致非预期端口被选 | show lacp |
| 8 | 显示 LACP 配置 | show lacp |
— | 全局状态检查第一步 | — | 看全局 enable/disable |
| 9 | 显示聚合组信息 | show lacp aggregator [[trunkid]] |
— | 检查组成员、模式、状态 | — | 看 Selected/Unselected 数 |
| 10 | 显示参与聚合的端口 | show lacp port [[portlist]] |
— | 检查每个成员口的协商参数 | — | 看模式、超时、状态位 |
【踩坑】第 1 条是最高频原因：
set lacp enable缺省关闭，如果忘记执行，后面所有聚合配置虽然不会报错，但完全不生效。这是"配置看起来都对，但聚合就是不起来"的头号原因。
4_3_2 三种聚合组模式详解
| 模式 | 含义 | 行为 | 对接对象 |
|---|---|---|---|
dynamic |
运行 LACP 协议 | 发送/接收 LACPDU，动态协商成员端口 | 对端也运行 LACP（推荐） |
static |
静态 Trunk | 不发送 LACPDU，手工绑定成员端口 | 对端是静态聚合 / 不支持 LACP 的设备 |
mixed |
混合模式 | 优先尝试 LACP 聚合，协商失败则退化为静态 | 对端模式不确定时的兼容选择 |
三种模式的行为对比（ASCII）：
dynamic： SW-A ◄──LACPDU──► SW-B ← 协议协商，自动检测
static： SW-A ──(无协议)── SW-B ← 手工绑定，不检测对端
mixed： SW-A 先尝试 LACPDU，失败则 fallback 到 static
【ZCIP 选型建议】：
- 两端都是中兴设备 / 支持 LACP 的设备 →
dynamic- 对接老服务器、存储阵列、专用硬件 → 先看对方支持什么，通常
static或mixedmixed虽然兼容性好，但失去了 LACP 的故障检测能力（协商失败后变成静态），不建议在生产核心链路使用
4_3_3 配置实例一：两台盒式交换机双链路聚合（经典工程案例）
拓扑：
┌──────────────────┐ ┌──────────────────┐
│ 交换机 A │ │ 交换机 B │
│ │ │ │
│ port1: VLAN2 │ port15 ════════════│ port2: VLAN2 │
│ port3: VLAN3 │ port16 ════════════│ port4: VLAN3 │
│ │ (聚合组 trunk 3) │ │
└──────────────────┘ └──────────────────┘
要求：VLAN2 内 A-port1 与 B-port2 互通
VLAN3 内 A-port3 与 B-port3 互通
两条物理链路捆绑为 trunk 3，负载分担
交换机 A 配置：
zte(cfg)#set lacp enable
zte(cfg)#set lacp aggregator 3 add port 15-16
zte(cfg)#set lacp aggregator 3 mode dynamic
zte(cfg)#set vlan 2 add trunk 3 tag
zte(cfg)#set vlan 2 add port 1 untag
zte(cfg)#set vlan 3 add trunk 3 tag
zte(cfg)#set vlan 3 add port 3 untag
zte(cfg)#set port 1 pvid 2
zte(cfg)#set port 3 pvid 3
zte(cfg)#set vlan 2-3 enable
交换机 B 配置：
zte(cfg)#set lacp enable
zte(cfg)#set lacp aggregator 3 add port 15-16
zte(cfg)#set lacp aggregator 3 mode dynamic
zte(cfg)#set vlan 2 add trunk 3 tag
zte(cfg)#set vlan 2 add port 2 untag
zte(cfg)#set vlan 3 add trunk 3 tag
zte(cfg)#set vlan 3 add port 4 untag
zte(cfg)#set port 2 pvid 2
zte(cfg)#set port 4 pvid 3
zte(cfg)#set vlan 2-3 enable
逐条解读：
set lacp enable— 全局开启 LACP（缺省关闭，必须先做）set lacp aggregator 3 add port 15-16— 将 port15、port16 加入聚合组 3set lacp aggregator 3 mode dynamic— 设置为动态 LACP 模式set vlan 2 add trunk 3 tag— 关键理解：把聚合组 trunk 3 作为 tag 成员加入 VLAN 2。这里的trunk 3是聚合组编号，不是 VLAN Trunk 干道。tag表示该聚合口在 VLAN 2 中带标签转发。set vlan 2 add port 1 untag— 将 port1 作为 VLAN 2 的 untag 成员（接入端口）set port 1 pvid 2— 设置 port1 的 PVID 为 2（untag 报文进入时归入 VLAN 2）set vlan 2-3 enable— 激活 VLAN 2 和 VLAN 3
【重要】
set vlan 2 add trunk 3 tag的含义拆解：
set vlan 2→ 操作对象：VLAN 2add trunk 3→ 把聚合组（trunk 3）加入该 VLANtag→ 该端口在此 VLAN 中带 802.1Q 标签转发整句意思：将聚合组 trunk 3 以 tagged 方式加入 VLAN 2。VLAN 2 的报文经过 trunk 3 时携带 802.1Q Tag。
4_3_4 配置实例二：核心-汇聚双链路聚合（工程写法）
这是 ZCIP 级别的工程配置，涵盖短超时、优先级、多 VLAN 透传：
! ===== 核心侧（Core）=====
zte(cfg)#set lacp enable
zte(cfg)#set lacp aggregator 1 add port 23-24
zte(cfg)#set lacp aggregator 1 mode dynamic
zte(cfg)#set lacp port 23-24 mode active
zte(cfg)#set lacp port 23-24 timeout short ! 核心链路用短超时，3s 收敛
zte(cfg)#set lacp priority 100 ! 核心优先级更低=更优先（视型号定义）
! 业务 VLAN 全量透传
zte(cfg)#set vlan 10 add trunk 1 tag
zte(cfg)#set vlan 20 add trunk 1 tag
zte(cfg)#set vlan 100 add trunk 1 tag
! 聚合组的 PVID（有 untag 业务时才设）
zte(cfg)#set trunk 1 pvid 1
! ===== 汇聚侧（Aggregation），对称配置 =====
zte(cfg)#set lacp enable
zte(cfg)#set lacp aggregator 1 add port 27-28
zte(cfg)#set lacp aggregator 1 mode dynamic
zte(cfg)#set lacp port 27-28 mode active
zte(cfg)#set lacp port 27-28 timeout short
两端对称性检查：
| 参数 | 核心侧 | 汇聚侧 | 是否一致 |
|---|---|---|---|
| LACP 全局使能 | enable | enable | ✅ |
| 聚合组模式 | dynamic | dynamic | ✅ |
| 协商模式 | active | active | ✅ |
| 超时设置 | short | short | ✅ |
| 成员端口速率 | 10G | 10G | ✅ |
| 成员端口双工 | full | full | ✅ |
| VLAN 成员关系 | 10/20/100 tagged | 10/20/100 tagged | ✅ |
这张表就是"配置说明书"：把两端实际取值填进同一行比对，任何一列出现不一致，聚合就有可能失败或降级为单链路。割接前填一次、割接后再填一次，比事后
show反复排查高效得多。
【ZCIP 设计要点】：核心-汇聚的聚合链路通常承载多个业务 VLAN，因此需要在聚合口上透传所有业务 VLAN（每条
set vlan X add trunk Y tag）。如果后续新增业务 VLAN，记得同时加到聚合口上，否则新 VLAN 的报文不会经过聚合链路。
4_3_5 配置顺序铁律（【踩坑】顺序错了要返工）
正确顺序（六步）：
① set lacp enable 全局开启 LACP（缺省关闭！）
② set lacp aggregator <id> add port <list> 把端口加入聚合组
③ set lacp aggregator <id> mode dynamic 设置聚合模式
④ set lacp port <list> mode active/timeout 设置成员端口协商参数
⑤ VLAN 操作针对聚合组（trunk <id>），不再针对物理口
⑥ show lacp aggregator / show lacp port 验证
错误顺序（常见）：
① set vlan X add port 15-16 tag ← 先在物理口上配了 VLAN
② set lacp enable
③ set lacp aggregator 3 add port 15-16 ← 报错：端口已有 VLAN 配置
→ 需要先 delete 物理口 VLAN 成员关系再重配，返工！
为什么顺序这么重要？ 因为成员端口一旦加入聚合组，其二层属性（VLAN 成员关系、PVID、链路类型）会被同步为聚合组的属性。如果先对物理口做了 VLAN 配置，再把它加入聚合组，可能出现：
- 物理口的 VLAN 配置与聚合组冲突 → 加不进去，报
port already in use - 物理口的 VLAN 配置被聚合组覆盖 → 配置丢失，但
running-config里还留着旧配置，造成混乱 - 两端 VLAN 配置不一致 → 聚合组建立了但部分 VLAN 不通
铁律：聚合组成立后，VLAN、PVID、STP 等操作一律针对逻辑聚合口，不要再对成员物理口做二层配置。
4_4 体系 B（机架式）smartgroup 配置
体系 A 的
set lacp aggregator是盒式设备的写法。当你面对的是 8900E / 5960 / 9900 这类核心或汇聚设备时，命令体系完全不同：聚合组改叫 smartgroup，配置从"全局 set"变成"接口下配置"。两者概念一一对应，但写法必须分开记，现场混用会直接报错。
4_4_1 两套体系聚合概念对照表
| 概念 | 体系 A（盒式） | 体系 B（机架式） | 说明 |
|---|---|---|---|
| 聚合组名称 | trunk <id> |
smartgroup <n> |
命名方式不同 |
| 创建与进入 | 无需创建，直接 set lacp aggregator <id> |
interface smartgroup<n> 进入 |
体系 B 需要先创建接口 |
| 聚合模式 | set lacp aggregator <id> mode dynamic |
smartgroup mode 802.3ad |
语义相同，写法不同 |
| 加入成员 | set lacp aggregator <id> add port <list> |
物理口下 smartgroup <n> mode active |
体系 B 是在成员口上指定所属聚合组 |
| 负载分担 | 芯片默认策略 | smartgroup load-balance <策略> |
体系 B 可显式配置 |
| 二层属性 | set vlan <id> add trunk <id> tag |
switchport mode trunk + switchport trunk vlan <list> |
体系 B 更接近华为风格 |
| 超时设置 | set lacp port <list> timeout short |
成员口下 lacp timeout short |
位置不同 |
两套体系配置对比（同一业务意图：两条 10G 组 LACP 动态聚合）
| 步骤 | 体系 A（盒式） | 体系 B（机架式） |
|---|---|---|
| ① 全局启用 LACP | zte(cfg)#set lacp enable |
ZXR10(config)#lacp |
| ② 创建聚合组 | zte(cfg)#set lacp aggregator 1 add port 15-16 |
ZXR10(config-lacp)#interface smartgroup1 |
| ③ 指定聚合模式 | zte(cfg)#set lacp aggregator 1 mode dynamic |
ZXR10(config-lacp-sg-if)#smartgroup mode 802.3ad |
| ④ 成员口加入聚合组 | 已在步骤 ② 中一并完成 | ZXR10(config-if)#smartgroup 1 mode active（每个成员口各配一次） |
| ⑤ 成员口协商模式 | zte(cfg)#set lacp port 15-16 mode active |
ZXR10(config-if)#smartgroup 1 mode active |
| ⑥ 超时设置 | zte(cfg)#set lacp port 15-16 timeout short |
ZXR10(config-if)#lacp timeout short |
注意步骤 ②④ 的思维差异：体系A 是"先建组、再把端口拉进组"；体系B 是"先建逻辑口、再到每个物理口上声明自己属于哪个组"。想清楚这个方向差异，就不会把
smartgroup命令敲错位置。
4_4_2 标准写法（smartgroup）
! ---------- 步骤一：创建聚合组并配置模式 ----------
ZXR10(config)#interface smartgroup1
ZXR10(config-smartgroup1)#smartgroup mode 802.3ad
ZXR10(config-smartgroup1)#smartgroup load-balance src-dst-mac
ZXR10(config-smartgroup1)#exit
! ---------- 步骤二：将物理口加入聚合组 ----------
ZXR10(config)#interface gei-0/5/0/23
ZXR10(config-if)#smartgroup 1 mode active
ZXR10(config-if)#lacp timeout short
ZXR10(config-if)#exit
ZXR10(config)#interface gei-0/5/0/24
ZXR10(config-if)#smartgroup 1 mode active
ZXR10(config-if)#lacp timeout short
ZXR10(config-if)#exit
! ---------- 步骤三：聚合口的二层属性 ----------
ZXR10(config)#interface smartgroup1
ZXR10(config-smartgroup1)#switchport mode hybrid
ZXR10(config-smartgroup1)#switchport hybrid vlan 10,20,100 tagged
ZXR10(config-smartgroup1)#exit
逐条解读：
interface smartgroup1— 创建并进入聚合组接口（类似创建一个逻辑端口）smartgroup mode 802.3ad— 设置为 LACP 动态模式（等价体系 A 的mode dynamic）smartgroup load-balance src-dst-mac— 设置哈希策略为源/目的 MACinterface gei-0/5/0/23— 进入物理成员口smartgroup 1 mode active— 将该物理口加入 smartgroup 1，并设置 LACP 模式为 activelacp timeout short— 设置短超时（3 秒）switchport mode hybrid— 聚合口设为 hybrid 模式switchport hybrid vlan 10,20,100 tagged— 在聚合口上透传 VLAN 10/20/100（全部带标签）
【踩坑】加入聚合组之前先清配置：成员口如果已存在 VLAN / 速率 / 双工等独立配置，加入聚合组时可能被拒绝或导致配置冲突。工程做法是：先在物理口下清除配置 → 加入聚合组 → 在聚合口下统一配置。
! 安全做法：先清理物理口 ZXR10(config)#interface gei-0/5/0/23 ZXR10(config-if)#no switchport mode ! 清除二层模式配置 ZXR10(config-if)#no switchport access vlan ! 清除 access VLAN ZXR10(config-if)#no switchport trunk allowed vlan ! 清除 trunk VLAN ZXR10(config-if)#smartgroup 1 mode active ! 再加入聚合组
4_4_3 完整工程案例（ZXR10 5960，四成员口 + 五元组哈希）
这是 ZCIE 级别的工程案例：四成员口（25G）、五元组哈希、跨板卡部署：
ZXR10#configure terminal
ZXR10(config)#lacp
ZXR10(config-lacp)#interface smartgroup41
ZXR10(config-lacp-sg-if-smartgroup41)#lacp mode 802.3ad
ZXR10(config-lacp-sg-if-smartgroup41)#lacp load-balance src-dst-ip-src-dst-port-protocol
ZXR10(config-lacp-sg-if-smartgroup41)#exit
ZXR10(config-lacp)#interface xxvgei-0/1/1/23
ZXR10(config-lacp-member-if-xxvgei-0/1/1/23)#smartgroup 41 mode active
ZXR10(config-lacp-member-if-xxvgei-0/1/1/23)#lacp timeout short
ZXR10(config-lacp-member-if-xxvgei-0/1/1/23)#exit
ZXR10(config-lacp)#interface xxvgei-0/1/1/24
ZXR10(config-lacp-member-if-xxvgei-0/1/1/24)#smartgroup 41 mode active
ZXR10(config-lacp-member-if-xxvgei-0/1/1/24)#lacp timeout short
ZXR10(config-lacp-member-if-xxvgei-0/1/1/24)#exit
ZXR10(config-lacp)#interface xxvgei-0/1/2/41
ZXR10(config-lacp-member-if-xxvgei-0/1/2/41)#smartgroup 41 mode active
ZXR10(config-lacp-member-if-xxvgei-0/1/2/41)#lacp timeout short
ZXR10(config-lacp-member-if-xxvgei-0/1/2/41)#exit
ZXR10(config-lacp)#interface xxvgei-0/1/2/39
ZXR10(config-lacp-member-if-xxvgei-0/1/2/39)#smartgroup 41 mode active
ZXR10(config-lacp-member-if-xxvgei-0/1/2/39)#lacp timeout short
ZXR10(config-lacp-member-if-xxvgei-0/1/2/39)#exit
ZXR10(config-lacp)#exit
! 配置聚合口二层属性
ZXR10(config)#interface smartgroup41
ZXR10(config-smartgroup41)#switchport mode hybrid
ZXR10(config-smartgroup41)#switchport hybrid vlan 100,200,300 tagged
ZXR10(config-smartgroup41)#exit
案例要点分析：
- 四成员口（xxvgei = 25G 接口）：4 × 25G = 100G 逻辑带宽
- 五元组哈希：
src-dst-ip-src-dst-port-protocol确保数据中心场景下最均匀的流量分布 - 跨板卡部署：端口分布在
0/1/1/和0/1/2/两个不同板卡/芯片上，提高冗余性（一块板卡故障不会丢失全部成员链路） - 聚合组编号 41：工程习惯上，编号与业务/区域关联（如 41 = 机房4 的第 1 条聚合链路），便于运维
【ZCIE 设计要点】跨板卡 vs 同板卡：
- 同板卡：同一芯片转发，哈希效率高，但板卡故障 = 全部成员丢失
- 跨板卡：冗余性好，但跨芯片哈希可能略有性能损失
- 推荐：核心链路尽量跨板卡/跨芯片部署成员口
4_4_4 查看命令（体系 B 特有）
ZXR10#show lacp 1 internal ! 成员端口聚合状态（最常用）
ZXR10#show lacp 1 neighbors ! 对端成员端口信息（排障神器）
ZXR10#show lacp 1 counters ! LACPDU 收发计数（判断协议是否通）
ZXR10#show lacp 1 summary ! 聚合组概要信息
show lacp 1 internal 输出解读：
ZXR10#show lacp 1 internal
Smartgroup: 1
Port Agg State Oper Key Port Priority RX Machine Mux State
────────────────────────────────────────────────────────────────────────────
gei-0/5/0/23 Selected 0x0001 32768 Current Collecting
gei-0/5/0/24 Selected 0x0001 32768 Current Distributing
────────────────────────────────────────────────────────────────────────────
关键字段解读：
· Port State：
- Selected → 已选中，参与转发 ✅
- Unselected → 未选中（参数不匹配/优先级不够）❌
- Standby → 热备（参数OK但未激活，active-max限制时常见）
· RX Machine（接收状态机）：
- Attached → 已附加到聚合组
- Collecting → 开始收集对端报文
· Mux Machine（复用状态机）：
- Attached → 已附加
- Collecting → 收方向OK
- Distributing→ 发方向OK（完全正常工作 = Collecting + Distributing）
⚠ 长期 Waiting / Detached → 协商未成功，按 4_7 排查
show lacp 1 neighbors 输出解读：
ZXR10#show lacp 1 neighbors
Smartgroup 1 neighbors:
Partner Port Partner Port Partner Partner
Port Priority Number System ID Key
─────────────────────────────────────────
gei-0/5/0/23 32768 23 0015.EB7A.3C01 0x0001
gei-0/5/0/24 32768 24 0015.EB7A.3C01 0x0001
─────────────────────────────────────────
关键看：
· Partner System ID → 对端的桥 MAC（确认对端身份）
· Partner Key → 对端操作 Key（应本端一致）
· Partner Port Number → 对端的端口编号（确认端口映射是否正确）
【ZCIP 排障技巧】：
show lacp neighbors看不到对端信息 = 物理层不通或对端未启用 LACP。看到对端但端口映射不对 = 本端/对端的物理连线接错了（如本端 port23 连到对端 port24），需要核对光纤/网线连接。
show lacp 1 counters 输出解读：
ZXR10#show lacp 1 counters
Port LACPDUs RX LACPDUs TX Marker RX Marker TX Illegal RX
─────────────────────────────────────────────────────────────────
sg1/23 15432 15430 0 0 0
sg1/24 15428 15431 0 0 0
─────────────────────────────────────────────────────────────────
关键看：
· LACPDUs RX = 0 → 对端没发 LACPDU（对端未配 LACP / 物理层不通 / 单纤）
· LACPDUs TX = 0 → 本端没发 LACPDU（忘记 lacp enable / 端口被 shutdown）
· Illegal RX > 0 → 收到非法 LACPDU（对端配置异常 / 中间有交换机透传）
4_5 负载分担（哈希）策略
本节要解决什么问题：聚合跑通只是开始，流量怎么分到各条成员链路才是关键。哈希选得不对，四条链路可能只跑满一条。
4_5_1 哈希原理
聚合的核心机制是基于流的负载分担。交换机用哈希算法把每条数据流映射到某个成员链路上：
哈希映射原理：
流特征（可选字段） 哈希结果 → 成员链路
┌──────────────────────┐
│ 源MAC / 目的MAC │
│ 源IP / 目的IP │──hash──► hash % N ──► 链路1/2/3/4
│ 源端口/目的端口 │
│ 协议号 │
└──────────────────────┘
│
▼
hash("10.1.1.1:5000 → 10.1.1.2:80 TCP") = 0x3A7B
0x3A7B % 4 = 3 → 选择链路 3（第 4 条成员链路）
同一条流永远映射到同一条链路（保证不乱序）
不同的流尽量分散到不同链路（最大化带宽利用率）
为什么必须同一条流走同一条链路？ 如果一条 TCP 连接的数据包走了不同链路，由于网络延迟的微小差异，后发送的数据包可能先到达，导致报文乱序。TCP 对乱序极其敏感，会触发重传、降低吞吐量。因此哈希的结果必须对同一流确定性（相同输入永远得到相同输出）。
4_5_2 常见哈希策略与适用场景
| 策略 | 哈希字段 | 适用场景 | 风险 / 局限 |
|---|---|---|---|
src-dst-mac（默认，常见） |
SMAC + DMAC | 二层环境、单网关场景 | 经过三层网关后 MAC 固定 → 所有流量哈希到同一条链路（极化问题） |
src-dst-ip |
SIP + DIP | 三层环境、多终端多服务器 | 同一对主机间的多条连接仍走同一链路 |
src-dst-ip-src-dst-port-protocol（五元组） |
SIP + DIP + SPort + DPort + Proto | 数据中心、服务器多连接 | 最优均衡，计算开销略高 |
src-mac / dst-mac |
单字段 | 特殊规范要求的运营商场景 | 均衡效果差 |
配置命令：
! 体系 A：芯片默认策略（通常不可显式修改，依型号而定）
! 体系 B：显式配置
ZXR10(config-smartgroup1)#smartgroup load-balance src-dst-mac
ZXR10(config-smartgroup1)#smartgroup load-balance src-dst-ip
ZXR10(config-smartgroup1)#smartgroup load-balance src-dst-ip-src-dst-port-protocol
4_5_3 【ZCIP/ZCIE】哈希极化问题（Hash Polarization）
哈希极化是聚合链路设计中最隐蔽的性能问题，也是 ZCIE 答辩的高频追问。
两级组网下的经典极化问题：
服务器群(S1~S8) ──► SW-A(聚合组1, 4链路) ──► SW-B(聚合组2, 4链路) ──► 用户群(U1~U8)
哈希: src-dst-mac 哈希: src-dst-mac
理想情况：8条流均匀分散到4条链路，每条25%负载
实际情况：
假设 SW-A 哈希结果（src-dst-mac）：
S1→U1 → 链路1 S2→U2 → 链路2 S3→U3 → 链路3 S4→U4 → 链路4
S5→U5 → 链路1 S6→U6 → 链路2 S7→U7 → 链路3 S8→U8 → 链路4
到达 SW-B 时，经过网关后源MAC变成了网关MAC(GW)：
GW→U1 → 链路? GW→U2 → 链路? GW→U3 → 链路? GW→U4 → 链路?
GW→U5 → 链路? GW→U6 → 链路? GW→U7 → 链路? GW→U8 → 链路?
如果 SW-B 也用 src-dst-mac 哈希：
→ 所有流的源MAC都是GW，目的MAC是U1~U8
→ 哈希结果取决于 GW 的 MAC + Ux 的 MAC
→ 如果哈希函数对 MAC 地址的分布不均匀 → 部分链路拥塞！
为什么大象流会打满一条成员链路？
"大象流"（Elephant Flow）指单条大带宽数据流（如备份流量、视频流、大数据传输）。由于哈希的确定性，一条流永远只走一条成员链路，无论该链路是否已经拥塞。如果恰好有一条 10G 的大象流被哈希到某条 10G 成员链路上，那条链路就满载，而其他链路即使空闲也无法分担——聚合的带宽倍增效果在这条流面前完全失效。
哈希极化的流量分布示意：
链路1: ████████████████████████████ 100% ← 大象流 + 其他流
链路2: ██████████ 40%
链路3: ████ 15%
链路4: ████████████████ 60%
聚合组总带宽 = 40G，但实际可用 = 只跑了约 21G
链路利用率极不均匀 → 部分业务丢包，部分链路空闲
解决方案：
| 方案 | 原理 | 适用场景 |
|---|---|---|
| 上下级使用不同哈希因子 | 一级哈希 MAC，二级哈希 IP | 经典两层架构 |
| 统一使用五元组哈希 | 五元组组合空间大，均衡性最好 | 数据中心、服务器多连接场景 |
| 链路数取 2 的幂 | 哈希取模在 2/4/8 链路下更均匀 | 设计阶段规划 |
| 避免奇数条链路 | 3 条/5 条链路时取模不均匀 | 设计阶段规划 |
【ZCIE 答辩要点】：被问到"你的聚合链路为什么用 4 条而不是 3 条"时，回答应该包含：①哈希取模均匀性（4 = 2²，取模分布更均匀）；②冗余度（4 条允许同时坏 1 条还有 3 条工作，3 条坏了 1 条只剩 2 条）；③标准化（业界惯例为 2/4/8）。
4_5_4 哈希策略选型决策表
| 场景特征 | 推荐哈希策略 | 理由 |
|---|---|---|
| 纯二层接入（无三层网关） | src-dst-mac |
MAC 地址多样性足够，默认即可 |
| 三层核心（经过 SVI 转发） | src-dst-ip 或更高级 |
经过网关后 MAC 固定，必须靠 IP 区分 |
| 数据中心（服务器多端口） | 五元组 | 同一 IP 对之间有多条连接（不同端口），只有五元组能区分 |
| 运营商（大量小流） | src-dst-ip |
IP 对数量巨大，均衡性足够 |
| 存在两级聚合 | 上下级不同策略 | 防止极化，一级 MAC、二级 IP |
| 存在大象流风险 | 五元组 + ECMP 大流分裂 | 依型号支持情况 |
4_6 聚合与 STP、VLAN 的配合
本节要解决什么问题：聚合不是孤立技术，它与 STP、VLAN 有明确的职责边界。搞清楚谁针对逻辑口、谁针对物理口，能省掉大量返工。
4_6_1 聚合后 STP 看到什么
物理上：4 条链路
逻辑上：STP 只看到 1 条链路（聚合组）
→ 4 条链路不会出现环路被阻塞，全部参与转发
→ 链路故障时在聚合组内部完成切换，不触发 STP 重算（收敛快得多）
STP 视角对比：
不使用聚合： 使用聚合：
┌─────┐ ┌─────┐
│ SW-A│═╗ │ SW-A│
│ │ ║ 4条链路 │ │──┐
│ │ ║ STP看到4条 │ │ │ ← STP只看到1条
└─────┘ ║ → 阻塞其中3条！ └─────┘ │ 全部转发！
║ ┌─────┐ │
╚════════════════════│ SW-B│──┘
└─────┘
关键结论：
- 聚合组内不存在 STP 阻塞：4 条链路逻辑上是 1 条，STP 不会在成员链路之间做选举
- 成员故障不触发 STP 重算：一条成员口 down 时，LACP 内部将其从转发集合中移除，STP 感知不到变化，收敛在毫秒级
- 聚合口才是 STP 的操作对象：所有 STP 配置（优先级、链路类型、保护特性）都作用于聚合口
配置要点（体系 A）：
zte(cfg)#set stp trunk 1 enable ! 对聚合组开启 STP
zte(cfg)#set stp instance 1 trunk 1 priority 32 ! 实例内聚合组优先级
zte(cfg)#set stp trunk 1 linktype point-point ! 聚合链路是点到点
【ZCIP 注意】：如果聚合口两端的 STP 配置不一致（如一端开启、一端关闭），可能导致 BPDU 被丢弃，形成临时环路。工程规范：聚合口两端的 STP 配置必须完全一致。
4_6_2 聚合 + VLAN 的标准组合
完整的聚合 + VLAN 配置流程（六步）：
① 建聚合组、加成员、设模式
set lacp enable
set lacp aggregator <id> add port <list>
set lacp aggregator <id> mode dynamic
② 设聚合口 PVID（有 untag 需求时）
set trunk <id> pvid <vid>
③ 对每个业务 VLAN：将聚合口以 tag 方式加入
set vlan <id> add trunk <trunkid> tag
④ 不要在成员物理口上做 VLAN 配置
! 成员口加入聚合组后，VLAN 属性由聚合组同步
⑤ 激活 VLAN
set vlan <id> enable
⑥ 验证
show vlan <id> ! 确认聚合口在 VLAN 成员列表中
show lacp aggregator <id> ! 确认聚合组成立
4_6_3 【案例故事】先配 VLAN 再加聚合组，半夜返工
这事发生在一次割接窗口。客户要求把原来单链路的汇聚上行改成双链路聚合，割接时间只有 30 分钟。
我先在核心侧操作，习惯性地先把 VLAN 配好了：
! 错误的操作顺序 zte(cfg)#set vlan 10 add port 23-24 tag ! ← 先在物理口上配了 VLAN zte(cfg)#set vlan 20 add port 23-24 tag zte(cfg)#set vlan 100 add port 23-24 tag zte(cfg)#set lacp enable zte(cfg)#set lacp aggregator 1 add port 23-24结果报错：
Error: port 23 is already configured with VLAN membership. Please remove VLAN configuration on port 23 before adding to aggregator.原来物理口 23、24 上已经有 VLAN 配置，无法直接加入聚合组。割接窗口只剩 15 分钟，我赶紧：
! 先清除物理口 VLAN 配置 zte(cfg)#set vlan 10 delete port 23-24 zte(cfg)#set vlan 20 delete port 23-24 zte(cfg)#set vlan 100 delete port 23-24 ! 重新加入聚合组 zte(cfg)#set lacp aggregator 1 add port 23-24 zte(cfg)#set lacp aggregator 1 mode dynamic ! 在聚合口上重新配 VLAN zte(cfg)#set vlan 10 add trunk 1 tag zte(cfg)#set vlan 20 add trunk 1 tag zte(cfg)#set vlan 100 add trunk 1 tag折腾了 10 分钟才搞定，差点超时。如果一开始就按正确顺序来，根本不会有这个问题。
从那以后，我的聚合配置模板永远是这样的顺序：
set lacp enable（第一件事）- 建聚合组、加成员
- 设模式、超时、协商参数
- 最后才配 VLAN（针对聚合口）
show验证教训：顺序错了不只是多敲几行命令的问题——在割接窗口里，每一分钟都是压力。把配置顺序固化成肌肉记忆，才能在高压环境下不出错。
4_7 跨厂商对接与验收测试矩阵
本节要解决什么问题：对接现场最常出问题的不是协议，而是两端参数不一致。本节给出逐项打勾的核对表与可执行的验收测试。
4_7_1 跨厂商对接参数映射
实际工程中，中兴设备经常需要和华为、H3C、Cisco、服务器网卡（Bonding/Teaming）对接。虽然 LACP 是 IEEE 标准，但各厂商的命令语法、缺省值、哈希策略不同，需要逐项对齐：
| 参数 | 中兴体系 A | 中兴体系 B | 华为 | H3C | Cisco |
|---|---|---|---|---|---|
| 聚合组概念 | trunk | smartgroup | Eth-Trunk | Bridge-Aggregation | Port-Channel |
| 动态模式 | dynamic | 802.3ad | lacp-static | dynamic | active |
| 静态模式 | static | static | manual | static | on |
| 混合模式 | mixed | — | — | — | — |
| Active | active | active | active | active | active |
| Passive | passive | passive | passive | passive | passive |
| 短超时 | 3s | 3s | fast (3s) | short (3s) | fast (1s) |
| 长超时 | 90s | 90s | slow (30s) | long (30s) | slow (30s) |
| 缺省协商模式 | active | active | active | active | active |
| 缺省超时 | long | long | slow | long | slow |
【ZCIP 对接经验】：
- 华为对接：华为的
lacp-static对应中兴的dynamic，两端都发 LACPDU，直接对接即可- Cisco 对接：Cisco 的
channel-group X mode active= LACP Active，与中兴 Active 对接没问题；注意 Cisco 缺省short超时是 1 秒（中兴是 3 秒），但不影响协商- 服务器网卡对接（如 Broadcom BACS / Intel ANS / Linux Bonding）：通常只支持 Active/Passive 或 Static，需要在交换机端设
mixed或static- 哈希策略不需要一致：两端的哈希算法相互独立，不需要匹配。但两端的VLAN / 速率 / 双工必须一致
4_7_2 验收测试矩阵（可执行）
以下是完整的验收测试矩阵，每一步都给出具体命令、操作、预期结果、通过标准：
| # | 测试项 | 操作步骤 | 预期结果 | 通过标准 |
|---|---|---|---|---|
| 1 | 聚合建立验证 | show lacp aggregator <id> |
聚合组状态为 UP，所有成员端口为 Selected | 100% 成员 Selected |
| 2 | 协议报文验证 | show lacp <id> counters |
LACPDU RX/TX 持续增长 | RX/TX > 0 且递增 |
| 3 | 对端识别验证 | show lacp <id> neighbors |
能看到对端系统 MAC 和端口信息 | 对端信息完整 |
| 4 | 带宽叠加测试 | iperf3 多线程（≥8 流）打流 | 总吞吐 ≈ N × 单链路带宽 × 90% | ≥ 90% 理论带宽 |
| 5 | 冗余切换 - 拔线 | 拔掉一条成员链路，同时 ping -t | 短暂丢包后恢复 | 丢包 ≤ 1~3 个（短超时更快） |
| 6 | 冗余切换 - 恢复 | 插回链路，观察 show lacp |
成员重新加入 Selected | 无业务中断，自动恢复 |
| 7 | 单向故障测试 | 只拔一根光纤（TX 或 RX） | 该成员被剔除，业务不中断 | 丢包 ≤ 3 个 |
| 8 | VLAN 连通性 | 各 VLAN 内互 ping | 所有 VLAN 通 | 100% 通 |
| 9 | 配置一致性 | 两端 show lacp、show vlan 比对 |
参数完全对称 | 全部一致 |
| 10 | 长稳测试 | 持续打流 24 小时 | 无丢包、无成员漂移 | 丢包率 < 0.001% |
拔线/加线测试详细步骤：
【拔线测试】
时间线（短超时配置下）：
T+0.0s 拔掉一条成员链路（如 port23）
T+0.0s LACPDU 中断
T+0.0s 对端立即感知物理 DOWN（电信号消失）
T+0.0s 本端端口状态变为 DOWN
T+1.0s 对端停止收到该端口的 LACPDU
T+3.0s 短超时判定（3 秒超时）
T+3.0s Mux 状态从 Distributing → Detached
T+3.0s 流量切换到剩余成员链路
T+3.0s ~ T+5.0s ping 恢复（丢 1~3 个包）
【加线测试】
T+0.0s 插回链路
T+0.0s 物理层 UP（电信号恢复）
T+0.0s LACPDU 开始交换
T+1.0s ~ T+3.0s LACP 协商完成
T+3.0s 端口状态变为 Selected
T+3.0s Mux 状态 → Collecting → Distributing
T+3.0s 流量重新分布到全部成员链路
预期中断：0（恢复过程不丢包）
【ZCIP 验收要点】：
- 必须用多线程打流：单线程 iperf 永远只能测到单条链路的带宽（一条流只能走一条成员链路）。用
iperf3 -P 8或更高。- 拔线测试要数丢包数：
ping -t（Windows）或ping -i 0.2（Linux）缩短间隔，精确统计丢包。短超时下应 ≤ 3 个包。- 恢复测试同样重要：插回链路后，确认成员重新 Selected，且流量重新均匀分布。曾遇到过对端 LACP 状态卡住不恢复的情况。
4_7_3 故障排查决策树
现象：聚合组起不来 / 聚合后丢包 / 带宽没翻倍
│
├─ ① set lacp enable 执行了吗？（缺省关闭！最高频原因）
│ └─ show lacp 看全局状态
│ └─ 若 disable → set lacp enable
│
├─ ② show lacp aggregator <id> 聚合组是否建立？成员是否都在？
│ └─ 聚合组不存在 → 检查 add port 命令
│ └─ 成员缺失 → 检查物理口是否 up、是否被其他组占用
│
├─ ③ show lacp port <list> 成员端口协商模式/超时
│ └─ 两端都是 passive → 必改一端 active
│ └─ 速率/双工不一致 → 统一（半双工不能聚合！）
│ └─ Key 不一致 → 检查端口物理参数
│
├─ ④ show lacp <id> counters（体系B） LACPDU 收发是否为 0？
│ └─ RX=0 → 对端未发 LACPDU（对端未配 / 物理不通 / 单纤）
│ └─ TX=0 → 本端未发（忘记 enable / 端口 shutdown）
│
├─ ⑤ show lacp <id> neighbors（体系B） 能看到对端吗？
│ └─ 看不到 → 物理层或协议未起
│ └─ 看到但对端端口不在同一组 → 本端/对端口序接错
│
├─ ⑥ VLAN 一致性 两端成员口 VLAN 配置是否一致？
│ └─ 不一致 → 部分 VLAN 丢包
│ └─ 检查：show vlan <id> 两端比对
│
├─ ⑦ 六要素逐项核对
│ └─ 速率、双工、VLAN、链路类型、Key、Active 模式
│ └─ 用 4_7_4 核对表逐项打勾
│
└─ ⑧ 负载分担 流量是否只跑一条链路？
└─ 检查哈希策略 + 是否存在极化
└─ 测试流量是否"流"太少（单条流只会走一条链路）
└─ 用 iperf -P 8+ 多线程测试
4_7_4 高频故障速查表
| 现象 | 原因 | 判据 | 处理 |
|---|---|---|---|
| 聚合完全起不来 | 全局未 set lacp enable |
show lacp 状态 disable |
开启 LACP |
| 聚合起不来 | 两端都 passive | show lacp port |
至少一端改 active |
| 成员口 Unselected | 速率/双工/Key 不一致 | show lacp aggregator |
统一端口参数 |
| 半双工口加不进聚合 | LACP 要求全双工 | show port |
改为全双工/自协商 |
| 聚合起来了但只有一条链路在跑 | 流量特征单一（只有一条流） | 观察端口统计 | 用多流测试（iperf 多线程） |
| 聚合起来了但丢包 | 两端 VLAN 配置不一致 | show vlan 两端比对 |
对齐 VLAN |
| 聚合起来了但丢包 | 成员口跨板/跨芯片配置差异 | 检查成员口位置 | 尽量同芯片/同板卡成员 |
| 拔线后收敛慢 | 长超时 90s | show lacp port |
改 timeout short（3s） |
| 带宽没翻倍 | 哈希极化 | 观察各成员链路流量 | 换哈希因子、改链路数为 2 的幂 |
| 聚合组建立了但部分 VLAN 不通 | 聚合口未加入该 VLAN | show vlan <id> |
set vlan X add trunk Y tag |
| 对端频繁 up/down | 光纤质量差 / 光模块不匹配 | show interface 错误计数 |
更换光纤/光模块 |
| 一端 Selected 另一端 Unselected | 六要素不匹配 | 逐项比对 | 逐项修正 |
4_8 笔记方法与验证清单
本节要解决什么问题：聚合故障多半是「少了哪一步」。本节给出笔记模板与验证清单，把配置、核对、验收三段串成闭环。
4_8_1 【笔记方法】聚合组成员登记表
每次配置聚合时填写，确保不遗漏：
# 聚合组成员登记表（Aggregation Member Registry）
- 聚合组 ID：__________ 设备：__________ 日期：__________
- 对端设备：__________ 对端聚合组 ID：__________
| 成员端口 | 速率 | 双工 | VLAN | 状态 | 备注 |
| --- | --- | --- | --- | --- | --- |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
- 聚合模式：□ dynamic □ static □ mixed
- LACP 协商：本端 ______ 对端 ______
- 超时设置：□ short(3s) □ long(90s)
- 哈希策略：__________
- 负载分担验证：□ 已完成多线程打流测试
- 冗余测试：□ 拔线测试通过 □ 加线恢复通过
为什么"成员端口"这一栏必须逐个登记：聚合建立失败的绝大多数原因不是协议原理，而是某个成员口速率/双工/VLAN 与其他成员不一致。写成表格后，一眼就能看出哪个口"不合群"，比逐条
show快得多。
4_8_2 【笔记方法】对接参数核对表（两端逐项打勾）
# LACP 对接参数核对表（两端逐项确认）
| # | 参数 | 本端（设备A） | 对端（设备B） | 是否一致 |
| --- | --- | --- | --- | --- |
| 1 | LACP 全局使能 | □ enable | □ enable | □ 是 □ 否 |
| 2 | 聚合组模式 | □ dynamic / □ static / □ mixed | □ dynamic / □ static / □ mixed | □ 是 □ 否 |
| 3 | 本端协商模式 ⚠ 至少一端 active | □ active / □ passive | □ active / □ passive | □ 是 □ 否 |
| 4 | 对端协商模式 | □ active / □ passive | □ active / □ passive | □ 是 □ 否 |
| 5 | 成员端口速率 | □ 10G / □ 25G / □ 其他____ | □ 10G / □ 25G / □ 其他____ | □ 是 □ 否 |
| 6 | 双工模式 ⚠ 必须为全双工 | □ full | □ full | □ 是 □ 否 |
| 7 | 成员端口 Key | __________ | __________ | □ 是 □ 否 |
| 8 | VLAN 成员关系 | __________ | __________ | □ 是 □ 否 |
| 9 | PVID | __________ | __________ | □ 是 □ 否 |
| 10 | 链路类型 | □ access / □ trunk / □ hybrid | □ access / □ trunk / □ hybrid | □ 是 □ 否 |
| 11 | 超时设置 | □ short(3s) / □ long(90s) | □ short(3s) / □ long(90s) | □ 是 □ 否 |
| 12 | STP 配置 | __________ | __________ | □ 是 □ 否 |
> 以上 12 项全部勾选"是" = 聚合必成；任何一项为"否" = 必须先修正再聚合。
这张表要在敲命令"之前"填。 聚合协商失败往往要等 90 秒（长超时）才暴露，靠
show反复试错很慢；而逐项打勾只需两分钟，且能直接定位是"漏开 LACP"还是"两端都 passive"。
4_8_3 【笔记方法】验收测试记录模板
# 链路聚合验收测试记录（Acceptance Test Record）
- 测试对象：设备A ______ ↔ 设备B ______ 聚合组：______
- 测试人员：______ 测试日期：______ 测试窗口：______
| # | 测试项 | 命令/操作 | 预期结果 | 实际结果 / 结论 |
| --- | --- | --- | --- | --- |
| 1 | 聚合建立 | | 聚合组 UP，成员数正确 | □ Pass □ Fail |
| 2 | LACPDU 收发 | | 本端/对端收发计数均增长 | □ Pass □ Fail |
| 3 | 对端识别 | | Partner 信息完整且一致 | □ Pass □ Fail |
| 4 | 带宽叠加（≥8 流 iperf） | | 总吞吐接近成员链路之和 | □ Pass □ Fail |
| 5 | 拔线切换（短超时） | | 丢包 ≤ 3 个 | 实际丢包：____ □ Pass □ Fail |
| 6 | 加线恢复 | | 自动重新加入聚合组 | □ Pass □ Fail |
| 7 | 单向故障（收或发单断） | | 业务不中断 | □ Pass □ Fail |
| 8 | VLAN 连通 | | 规划 VLAN 100% 可达 | □ Pass □ Fail |
| 9 | 配置一致性 | | 两端参数完全对称 | □ Pass □ Fail |
| 10 | 长稳（24h） | | 无丢包、无成员口抖动 | 丢包率：____ □ Pass □ Fail |
- 结论：□ 验收通过 □ 验收不通过（说明：____________）
- 签名：____________
第 4 项最容易"假通过"。 用单条流测带宽，无论多少条成员链路都只会跑一条（哈希决定），必须至少 8 条不同五元组的流才能验证带宽真的叠加。
4_8_4 【验证】验证命令清单（至少 8 行）
| 验证命令 | 预期结果 / 关键字段 | 不符时的排查方向 |
|---|---|---|
show lacp |
全局状态为 enable |
若 disable → 执行 set lacp enable |
show lacp aggregator <id> |
聚合组状态 UP，所有成员端口 Selected 数 = 实际成员数 | 成员数不符 → 检查 add port 是否完整 |
show lacp port <list> |
每个成员口模式（active/passive）、超时、状态位正常 | 模式不对 → 检查两端 active/passive 组合 |
show lacp <id> internal（体系B） |
Port State = Selected，Mux = Collecting & Distributing | Waiting/Detached 长期不变 → 协商未成功 |
show lacp <id> neighbors（体系B） |
能看到对端 System ID、端口号、Key | 看不到对端 → 物理层/协议未起 |
show lacp <id> counters（体系B） |
LACPDU RX/TX 持续增长，不为 0 | RX=0 → 对端未发；TX=0 → 本端未发 |
show vlan <id> |
聚合口（trunk/smartgroup）在各业务 VLAN 的成员列表中 | 缺失 → set vlan X add trunk Y tag |
show interface <member> |
所有成员口物理状态 UP、速率一致、全双工 | 有端口 down → 检查物理层/光模块 |
show running-config |
聚合配置完整：enable → aggregator → mode → VLAN | 缺失步骤 → 按六步顺序补齐 |
ping -t + 拔线 |
丢包 ≤ 1~3 个（短超时） | 丢包过多 → 检查超时设置、检查是否有 STP 介入 |
iperf3 -P 8 |
总吞吐 ≥ 90% × N × 单链路带宽 | 带宽不叠加 → 检查哈希策略、流数量是否足够 |
show lacp aggregator <id>（拔线后） |
成员数减 1，剩余成员仍 Selected | 剩余成员也 Unselected → 检查 VLAN 一致性 |
4_9 考点速记与自检清单
本节要解决什么问题：最后是考点速记与自检清单。
4_9_1 考点速记（【ZCIA】5% 但必会）
- LACP = IEEE 802.3ad；中兴体系 A 中聚合组叫 trunk，体系 B 叫 smartgroup。
- LACP 缺省关闭，必须先
set lacp enable。这是最高频的配置遗漏。 - 三种模式：
dynamic（对端跑 LACP）/static（对端静态）/mixed（优先 LACP，失败退化为静态）。 - passive ↔ passive 不聚合；本端 passive 时对端必须 active。
- 短超时 = 3 秒，长超时 = 90 秒。短超时收敛快但 CPU 开销略增。
- 端口处于自协商或全双工模式时允许聚合，半双工不允许。
- 六要素必须匹配：速率、双工、VLAN 配置、链路类型、Key、至少一端 Active。
- 聚合组成立后，二层配置针对聚合组而非成员物理口（VLAN、PVID、STP）。
- 聚合组对 STP 表现为一条逻辑链路，成员故障不触发 STP 重算。
- 哈希极化：上下级聚合使用不同哈希因子，链路数取 2 的幂（2/4/8）。
- 测试聚合带宽必须用多线程，单流只能跑一条链路的带宽。
- 体系 A 的
trunk= 聚合组，不是 VLAN Trunk 干道。 - 配置顺序铁律：enable → 建组加成员 → 设模式 → 设端口参数 → 最后配 VLAN。
- 成员口加入聚合组前先清配置，否则冲突报错。
show lacp internal中 Selected = 正常，Unselected = 异常，Standby = 热备。
浙公网安备 33010602011771号