交换机对接M-LAG

现象结论
聚合组整体 UP、成员端口 UP，但跨聚合无法互通；拆掉聚合、单端口直配三层 IP 就能正常互通，根源是 M-LAG / 静态聚合两端的二层机制、VLAN、STP、聚合模式、哈希策略、MAC 同步异常，并非三层 IP 故障。
双方一台 H3C、一台锐捷做二层聚合对接，异构厂商极易出现该问题。
一、最高概率原因（按排查优先级排序）
1. 两端聚合模式不匹配（最常见）
聚合分为两种模式，两端必须严格一致：
静态聚合（static）：双方均配置静态聚合
动态 LACP 聚合：两端均开启 LACP
错误场景：
H3C 配置link-aggregation mode static静态聚合
锐捷配置active动态 LACP
模式混搭，聚合逻辑看似 UP，但收发报文机制错乱，二层转发异常。
现象：聚合显示 S (选中状态)，流量转发异常，拆成单口就正常。
修正要求
统一全部改成 LACP 动态聚合（异构厂商兼容性最好）：
plaintext
# H3C侧
interface Bridge-Aggregation 1
link-aggregation mode dynamic
plaintext
# 锐捷侧
interface AggregatePort 1
aggregateport mode active
2. 聚合接口下配置不一致（VLAN/PVID 不一致）
二层聚合接口必须保证：
允许通过的 VLAN 列表完全一致
缺省 PVID（原生 VLAN）完全一致
举例故障：
H3C 聚合口 PVID=VLAN 1，只允许 VLAN10、20
锐捷聚合口 PVID=VLAN 99，放行 VLAN1、10
同一份二层报文，两端剥离 / 打上 VLAN 标签不同，对端收到带错标签的帧直接丢弃。
单端口直连时你大概率统一了 PVID，所以可以通。
3. STP 生成树冲突、聚合端口被 STP 阻塞
异构厂商对接极易出现 STP 计算紊乱：
两边都开启全局 STP，根桥争夺混乱，聚合链路某一端被置为 Discarding 丢弃状态；
聚合成员端口被 STP 阻塞，看似物理 UP，实际不转发流量。
排查命令：
plaintext
# H3C查看聚合端口STP状态
display stp interface Bridge-Aggregation 1
解决方案：
对接互联的聚合两端接口配置 边缘端口 + 关闭 STP：
plaintext
# H3C
interface Bridge-Aggregation 1
stp disable
# 或者配置边缘端口
stp edged-port enable
锐捷对应接口同样关闭 STP。
4. M-LAG 特殊场景：M-LAG peer-link 与对接聚合产生环路
如果你这边 H3C 是 M-LAG 双机架构，下联聚合对接锐捷单交换机：
M-LAG 的 peer-link 心跳链路 + 对外聚合链路形成二层环路；
STP 自动阻塞聚合链路，导致流量不通；
表现：聚合 UP，但是流量被阻断，单链路无环路就能通。
处理：
M-LAG 对接第三方设备时，在对接聚合接口配置 stp root protected，或者严格规划 VLAN，避免跨 peer-link 环路。
5. LACP 哈希调度策略不一致，流量黑洞
H3C 与锐捷默认聚合负载分担算法不一样：
H3C 默认基于源 MAC + 目的 MAC
部分锐捷固件默认基于源 IP + 目的 IP
二层环境无 IP 头部，锐捷聚合转发逻辑失效，部分流量丢弃。
统一为基于 MAC 分担：
plaintext
# H3C聚合口配置
link-aggregation load-sharing mode source-mac destination-mac
plaintext
# 锐捷聚合口
aggregateport load-balance src-dst-mac
6. 两端接口速率 / 双工协商异常
聚合成员端口出现半双工、速率不一致：
聚合组内成员端口速率不同时，LACP 会剔除低速端口，但容易出现状态显示 UP、实际转发异常。
强制两端所有成员端口统一速率双工：
plaintext
interface GigabitEthernet 1/0/1
speed 1000
duplex full
undo auto-speed
二、快速定位故障手段
在两端聚合接口同时开启报文统计，持续查看报文收发计数：
plaintext
display interface Bridge-Aggregation 1
只有发包、没有收包：STP 阻塞、VLAN 标签错乱；
收发都有，但无法 ping 通：哈希策略问题、ACL 拦截。
在 H3C 上抓聚合接口二层报文，查看入帧的 VLAN 标签，对比锐捷发送标签是否一致。
临时全局关闭两端交换机 STP，测试能否互通，能通则确定是 STP 阻塞导致。
三、完整标准化正确配置模板
H3C 侧
plaintext
# 创建聚合
interface Bridge-Aggregation 1
port link-type trunk
port trunk permit vlan all
link-aggregation mode dynamic
link-aggregation load-sharing mode source-mac destination-mac
stp disable

# 成员端口加入聚合
interface range GigabitEthernet 1/0/1 to GigabitEthernet 1/0/2
port link-aggregation group 1
speed 1000
duplex full
undo shutdown
锐捷侧
plaintext
interface AggregatePort 1
switchport mode trunk
switchport trunk allowed vlan all
aggregateport mode active
aggregateport load-balance src-dst-mac
no spanning-tree

interface range GigabitEthernet 0/1-2
aggregateport 1
speed 1000
duplex full
no shutdown
四、补充：为什么单端口直连就能通？
单链路不存在聚合协商、LACP 哈希分担的问题；
单链路不会触发 STP 环路阻塞；
单端口对接时你配置的 Trunk/PVID 天然匹配，没有标签错乱；
以上三点就是拆聚合就正常、聚合不通的核心区别。
五、M-LAG 额外注意点（如果你 H3C 是 M-LAG 双机组网）
对接锐捷的聚合只能单边接入一台 M-LAG 设备，禁止跨两台 M-LAG 节点做聚合；
M-LAG 对接第三方交换机时，不要将对接链路放进 peer-link 所属 VLAN，防止环路；
务必开启 M-LAG 本地优先转发。

这个问题很典型，端口和聚合组状态都显示正常，但数据却传不通，而拆成单个物理口直连就通，这说明问题很可能出在跨厂商的链路聚合（Link Aggregation）参数不匹配上。

根据H3C的官方故障排查经验，这种现象的根源通常在于二层机制上的差异。你的问题描述虽然没提到“M-LAG”，但这个排查逻辑同样适用于普通的跨厂商二层聚合对接。

为了帮你精准定位，建议按以下优先级逐一排查：

🎯 1. 聚合模式不匹配（可能性最高）

这是最常见的原因。两台设备使用的链路聚合模式必须完全一致。

• 问题现象：一端配置了静态聚合（H3C默认），另一端配置了动态LACP聚合（锐捷默认可能是active模式）。虽然管理状态显示为S（Selected），但实际的报文收发机制已经错乱，导致二层转发异常。

• 解决方案：强烈建议两端都统一改为动态LACP模式，这是异构厂商对接时兼容性最好的方案。

  • H3C侧：在聚合接口下配置 link-aggregation mode dynamic。

  • 锐捷侧：在聚合接口下配置 aggregateport mode active。

🏷️ 2. VLAN与PVID配置不一致

这是另一个非常隐蔽的“陷阱”。

• 问题现象：两台交换机聚合接口下允许通过的VLAN列表，或端口的缺省VLAN（PVID）不一致。

  • 例如：H3C侧PVID是VLAN 1，只允许VLAN 10通过；而锐捷侧PVID是VLAN 99，允许VLAN 1和10通过。

  • 这样会导致数据帧在两侧被打上不同的VLAN标签，对端设备收到后会因为标签不匹配而直接丢弃。你在拆开单口直连时，可能恰好统一了PVID和VLAN配置，所以能通。

• 解决方案：仔细核对并确保两台交换机聚合接口的PVID和允许通过的VLAN列表完全一致。

🌲 3. STP（生成树）协议阻塞

跨厂商对接时，STP计算很容易出现紊乱。

• 问题现象：STP可能错误地将聚合链路或某个成员端口置为Discarding（丢弃）状态，导致看似物理UP，实际不转发任何流量。

• 排查命令：在H3C交换机上使用 display stp interface Bridge-Aggregation 1 查看聚合端口的STP状态。

• 解决方案：如果确认是STP导致，可以在对接的聚合接口上关闭STP或将其配置为边缘端口。

  • H3C侧：interface Bridge-Aggregation 1 下配置 stp disable 或 stp edged-port enable。

  • 锐捷侧：在对应的聚合接口上执行类似关闭STP的操作。

🧮 4. 负载分担哈希算法不一致

• 问题现象：H3C与锐捷的默认负载分担算法可能不同。例如，H3C默认基于源MAC+目的MAC，而锐捷可能默认基于源IP+目的IP。在纯二层环境中，如果锐捷的算法依赖IP头部，而报文是二层帧，就可能导致其转发逻辑失效，丢弃部分流量。

• 解决方案：为了在二层环境中有最好的兼容性，建议将两端的负载分担模式都统一为基于MAC地址进行哈希计算。

  • H3C侧：在聚合接口下配置 link-aggregation load-sharing mode source-mac destination-mac。