5560-54c-ei

这是个非常经典的 H3C 交换机排障场景，业务通但管理不通，说明二层转发面基本正常（聚合组剩下那条链路在工作），但管理面（CPU 上送的 ICMP）出了问题。下面把原因分析和排查路径给你梳理清楚。
现象本质：聚合组"半活着"
两条光纤做静态聚合，一条因光模块高温无收光 down 掉，只要聚合模式配置正确，剩下那条链路应该自动接管所有 VLAN 的流量——这一点你的业务终端能通已经验证了：H3C 官方文档明确说明"两台设备间一条链路故障后，Host A 仍然能够 Ping 通 Host B"。
但管理流量特殊：ping 交换机自身的 VLAN 接口 IP，报文是上送 CPU 处理的；而业务终端间通信是由 ASIC 硬件转发的，两者走的是不同的处理路径。这就是为什么会出现"业务通、管理不通"的分裂现象。
高概率原因（按可能性排序）
🎯 原因 1：CPU 保护机制 / ICMP 限速触发（可能性最高）
光模块高温告警 + 链路 down + 聚合组重新选路，这一连串事件会让交换机 CPU 短时间内繁忙。H3C 交换机对发往 CPU 的 ICMP 报文有默认限速，CPU 繁忙时会优先丢弃 ping 包来保障业务转发——这是一种保护行为，不是故障。
💡 这正好解释了为什么"业务终端通、管理地址不通"：业务走硬件转发不经过 CPU，ping 管理地址要 CPU 处理，被限速丢弃了。
验证方法：
# 在接入交换机上查看
display cpu-usage # CPU 利用率是否 > 70%
display cpu-usage task # 哪个进程占 CPU
display current-configuration | include icmp # 查看 ICMP 限速配置
临时缓解：
system-view
ip icmp rate-limit echo 1000
ip icmp rate-limit echo-reply 1000
🎯 原因 2：管理 VLAN 的 ARP / MAC 表项还指向 down 的那条链路
聚合组成员口 down 后，管理 VLAN 接口（VLAN-interface）的 MAC 地址表项和 ARP 表项可能不会立即刷新，导致回程流量仍然 hash 到那条已经 down 的链路 → 报文丢弃。
验证方法（在汇聚交换机上）：
display arp | include 接入管理IP # 看 ARP 表项
display mac-address vlan 管理VLANID # 看 MAC 表项学习在哪个端口
如果 MAC 表项指向的是 down 掉的那个物理口（而不是 Bridge-Aggregation 逻辑口），说明表项没刷新干净。
处理方式：
reset arp all # 清空 ARP（业务不中断，会自动重新学习）
reset mac-address # 清空 MAC 表
🎯 原因 3：静态聚合模式两端不一致（隐藏雷区）
H3C 官方排障手册明确指出：如果一端是静态聚合、另一端是动态聚合，会导致动态聚合侧只有一个口默认选中，其他成员口都无法选中。这种情况下极易引发报文从静态聚合的选中口 hash 发出，但对端动态聚合是非选中状态，导致报文丢弃。
虽然你说是"静态聚合"，但建议核实对端（接入交换机）的实际配置：
display link-aggregation verbose bridge-aggregation X
重点看 Aggregation Mode 字段，两端必须都是 Static。
🎯 原因 4：管理 VLAN 未在聚合口上正确放行
成员口加入聚合组后，实际生效的是聚合端口（Bridge-Aggregation）的配置，成员物理端口上的 VLAN 配置无效。检查：
interface Bridge-Aggregation X
port link-type trunk
port trunk permit vlan 管理VLANID 业务VLANID # 管理 VLAN 必须放行
推荐的标准排查顺序
按这个顺序执行，第一步往往就能定位问题：
Step 1：在接入交换机上看聚合组状态
display link-aggregation verbose bridge-aggregation X
重点关注：
Aggregation Mode：两端是否都是 Static
剩下的那条链路 Port Status 是否是 S（Selected）
Management VLANs 字段
Step 2：查看成员口物理状态
display interface 剩下那条链路
确认 Current state: UP、Line protocol state: UP，且没有大量 CRC 错包（光模块高温可能伴随误码）。
Step 3：检查管理 VLAN 接口状态
display interface Vlan-interface 管理VLANID
确认 Current state: UP。
Step 4：检查 CPU 和 ICMP 限速
display cpu-usage
display current-configuration | include icmp
Step 5：在汇聚侧清 ARP 重学
reset arp ip 接入管理IP
然后在汇聚上重新 ping 接入管理地址，观察是否恢复。
类似案例参考
H3C 知了社区有一个几乎一模一样的案例："S5560X 丢包：终端 ping 交换机管理地址丢包严重，但业务正常"。最佳答案明确指出：
对交换机来说，转发业务数据是第一优先级的任务，而响应 ping 命令是次要任务，当 CPU 繁忙时会优先丢弃 ping 包来保障业务，这本身是一种保护行为。
另一个相关案例是 5560X 双链路聚合接收发器，"都接上能通，拔掉一路就不通"——根因是聚合状态下本端成员口虽是 Selected，但对端状态异常导致报文丢弃。这与你"一条链路 down 后管理不通"的现象机理相通。
还有一个 5560 聚合链路切换的案例：当一条成员口 down 后，流量自动切换到另一条接口转发——这证明了正常情况下管理流量也应该跟着切换，如果你的没切换，大概率是 CPU 限速或表项未刷新。
给你的处置建议
立即可做（不改配置）：
在接入交换机执行 display cpu-usage，看是否 CPU 飙高
在汇聚交换机执行 reset arp all，清掉可能指向死链路的 ARP 表项
重新 ping 接入管理地址，观察是否恢复
短期修复：
如果确认是 ICMP 限速导致，临时调高 ip icmp rate-limit 阈值
更换高温故障的光模块（根本问题，光模块持续高温会反复触发 down）
长期优化：
管理流量与业务流量建议逻辑隔离：虽然复用物理链路，但通过不同 VLAN 区分，管理 VLAN 和业务 VLAN 分开
考虑将静态聚合改为 LACP 动态聚合，LACP 有更完善的成员口健康检测和快速切换机制
关注光模块温度，H3C 设备光模块高温通常是散热不良或光模块本身老化，建议更换原厂或兼容认证的光模块
⚠️ 重要提醒：管理地址不通但业务通，表面上"不影响业务"，但实际上你失去了对接入交换机的带外管理能力——一旦剩下那条链路也出问题，你将无法远程处置。建议尽快更换故障光模块，恢复双链路冗余。

需要带源地址ping才能通

您好，这是缺少路由了吧

故障原因
汇聚与接入之间为静态链路聚合，分担模式默认源目 MAC 哈希。
业务流量（网关转发终端流量）、汇聚访问接入管理 IP 的CPU 始发流量根据哈希算法被分配至不同成员链路；
当其中一条成员链路故障 Down 后，交换机硬件分流表项不会主动刷新。管理流量固定调度至故障链路，报文直接丢弃；业务流量哈希在正常链路，终端通信不受影响，形成 “终端通、交换机管理 IP 不通” 现象。
该问题属于静态聚合经典哈希黑洞场景，行业内同类案例较多。
解决方案
1、长期优化：建议将静态聚合改为LACP 动态聚合，故障链路下线后哈希重新计算更及时；
2、调整负载分担策略，推荐全局配置：link-aggregation load-sharing mode source-dest-ip，细化三层流量哈希粒度；
3、升级交换机固件至新版本，优化聚合成员故障时表项刷新机制；
4、临时恢复手段：shutdown/undo shutdown 聚合接口，强制重新生成分流表。
排查命令
plaintext
display mac-address 【接入管理VLANIF MAC】
display link-aggregation summary
display link-aggregation member-port

你遇到的这个现象确实比较经典，它通常指向静态链路聚合配置中，管理VLAN的配置在聚合组成员端口上不一致。

简单来说，业务流量通而管理流量不通，说明二层转发是正常的（聚合组剩余的链路在工作），但发往交换机CPU进行处理的管理报文（如Ping）出了问题。

🔍 问题原因分析

结合你“一条链路故障，一条正常”的情况，最可能的原因是：

1. 管理VLAN未在所有聚合成员端口上统一放行：这是最常见的原因。管理VLAN（假设为VLAN 100）可能只在故障的那条链路上配置了允许通过，而当前正常工作的链路上没有配置。当故障链路Down掉后，管理流量无法通过正常链路到达接入交换机。

2. 聚合组VLAN透传配置不一致：汇聚侧或接入侧的聚合组（Bridge-Aggregation接口）与其成员端口的VLAN配置可能不一致。例如，聚合组透传了所有VLAN，但某个成员端口只允许了业务VLAN。

3. 静态聚合的固有缺陷：静态聚合无法自动检测到物理链路的单通故障。当一条链路“有光无收”时，只要端口物理状态是UP，交换机仍会认为它在聚合组中是可用（Selected）状态，并尝试向其分发流量，从而导致部分流量（包括管理报文）丢失。

🛠️ 排查步骤

可以按照以下步骤来定位问题：

1. 检查聚合组状态
   在两台交换机上分别执行 display link-aggregation summary，确认聚合组状态是否一致，以及是否只有一条链路处于 Up 或 Selected 状态。

2. 检查管理VLAN配置（关键步骤）

   • 查看聚合组配置：在汇聚交换机上执行 display interface Bridge-Aggregation X（X为聚合组号），查看是否透传了管理VLAN。

   • 对比成员端口配置：在接入交换机上，分别查看当前正常工作的端口和已经故障的端口的配置。

     bash

     display interface GigabitEthernet X/Y/Z

     重点对比两个端口下关于管理VLAN的配置（如 port access vlan 100 或 port trunk permit vlan 100）是否一致。

3. 检查管理流量转发路径

   • 在汇聚交换机上 tracert 接入交换机的管理地址，看报文在哪一跳中断。

   • 在接入交换机上 display ip routing-table，确认管理流量的下一跳是否指向汇聚交换机，且出接口为聚合组。

✅ 解决方案

根据排查结果，采取以下措施：

1. 统一VLAN配置（根本解决）
   如果发现管理VLAN在正常工作的端口上缺失，立即在接入交换机的该成员端口下，添加管理VLAN的配置。

   • 如果是Access端口：port access vlan 100

   • 如果是Trunk端口：port trunk permit vlan 100
     确保两台交换机所有聚合成员端口的VLAN配置完全一致。

2. 考虑更换为动态链路聚合（LACP）
   如果条件允许，建议将静态聚合改为动态LACP聚合。动态聚合可以通过LACPDU报文检测链路状态，避免向故障链路转发流量，从而规避单通故障。

3. 物理链路修复
   更换温度过高、无收光的故障光模块和光纤，恢复链路冗余。