问

s6520日志丢包

VLAN

2天前提问

0关注
0收藏，96浏览

zhiliao_SP5umU

zhiliao_SP5umU 二段

粉丝：0人关注：0人

问题描述：

PktType=DHCP_CLIENT, SrcMAC=1451-7eac-0d70, Dropped from interface=Ten-GigabitEthernet1/0/24 at Stage=63, StageCnt=77, TotalCnt=202563, MaxRateInterface=Ten-GigabitEthernet1/0/24.

PktType=ARP, SrcMAC=7cde-787a-3aa9, Dropped from interface=Ten-GigabitEthernet1/0/24 at Stage=15, StageCnt=18460, TotalCnt=281385, MaxRateInterface=Ten-GigabitEthernet1/0/24.

PktType=DHCP_SERVER, SrcMAC=64d6-9a9e-b09c, Dropped from interface=Ten-GigabitEthernet1/0/24 at Stage=0, StageCnt=4, TotalCnt=5, MaxRateInterface=Ten-GigabitEthernet1/0/24.

3 个回答

按时间按赞数

已采纳

zhiliao_GeOM0O

zhiliao_GeOM0O 七段

粉丝：9人关注：2人

你这台 S6520 日志里的丢包，不是故障，是交换机在正常防攻击、抑制风暴 **，重点是 DHCP、ARP 被限速 / 丢弃，根源都在 Ten‑GigabitEthernet1/0/24 这个口下面。
一、日志每条到底啥意思？
1. DHCP_CLIENT 丢包
plaintext
PktType=DHCP_CLIENT
Dropped from interface=Ten-GigabitEthernet1/0/24
Stage=63
Stage=63 对应：端口 DHCP 报文限速 / 防 DHCP 攻击
说明：24 口下面大量 DHCP 请求广播，超出交换机安全阈值，被丢弃
2. ARP 丢包（量最大）
plaintext
PktType=ARP
Stage=15
StageCnt=18460，TotalCnt=281385
Stage=15 对应：ARP 限速 / ARP 风暴抑制 / 防 ARP 攻击
24 口下面 ARP 广播风暴严重，交换机主动丢弃保护整机
3. DHCP_SERVER 丢包
plaintext
PktType=DHCP_SERVER
Stage=0
Stage=0 一般是早期校验 / ACL / 端口策略丢弃
量很少（TotalCnt=5），可以忽略
二、为什么会这样？
100% 是 1/0/24 下联设备 / 环境问题：
24 口下联了傻瓜交换机 / HUB / 大量终端终端乱发 ARP、重复发 DHCP 请求 → 形成广播风暴
下联有病毒主机、镜像端口、环路疯狂发送 ARP/DHCP 广播
下联 AP 密集、摄像头密集、IP 话机密集大量设备同时上线，广播瞬间打满
端口没有开风暴抑制 / 安全策略太敏感S6520 默认对 ARP/DHCP 有攻击防范阈值，一超就丢
三、怎么定位 24 口下联是谁？
看 MAC 表
plaintext
display mac-address interface Ten-GigabitEthernet1/0/24
看 1451-7eac-0d70、7cde-787a-3aa9 是哪个设备
看 24 口下有没有环路
plaintext
display loopback-detection
display interface Ten-GigabitEthernet1/0/24
看风暴抑制统计
plaintext
display storm-constraint
display cpu-defend statistics
四、怎么解决？（3 套方案直接用）
方案 1：给 24 口加大 ARP/DHCP 限速（推荐）
cli
system-view
interface Ten-GigabitEthernet1/0/24

# 放大ARP限速
arp rate-limit 500

# 放大DHCP限速
dhcp snooping rate-limit 200

# 开启广播/组播风暴抑制
storm-constrict broadcast unicast multicast
storm-constrict rate 1000

# 如果开了DHCP Snooping
dhcp snooping deny-rate 200

quit
save
方案 2：如果下联是核心 / AC / 服务器，信任该口
cli
interface Ten-GigabitEthernet1/0/24
dhcp snooping trust
arp trust
quit
save
方案 3：彻底关闭攻击丢弃（不推荐，仅临时定位）
cli
undo cpu-defend policy auto
undo arp anti-attack check enable
undo dhcp snooping check enable
五、最简单判断
只丢 ARP、DHCP → 下联广播风暴 / 终端乱报
只在 24 口 → 问题就在 24 口下面
总量很大但业务正常 → 交换机正常防护，不是故障

刘浩存

刘浩存八段

粉丝：13人关注：1人

看日志，问题的本质是交换机上联口Ten-GigabitEthernet1/0/24在短时间内接收了海量DHCP和ARP广播报文，触发了CPU保护机制（CPCAR）而被丢弃，但这通常只是表象。

结合你提供的日志，可以这样理解：

总丢包数异常高：TotalCnt=202563和TotalCnt=281385这类数值，说明端口在半分钟内可能接收了数万甚至数十万的报文，这远超正常网络流量水平。
Stage值：这是设备内部处理阶段标识，不必深究。关键在于它和StageCnt一起，帮你确认大量报文都是因超过CPCAR的速率限制而被丢弃的。
MaxRateInterface：日志明确指出，Ten-GigabitEthernet1/0/24是丢包最严重的端口，这也是你的核心排查点。

排查与解决步骤

请按照以下步骤，定位根源并彻底解决问题：

第一步：查环路 (最可能的原因)
- 查看STP状态：执行 display stp brief 检查端口状态。正常情况下，应存在一个被阻塞的端口，其状态为 DISCARDING 或 ALTERNATE。如果所有端口都是 FORWARDING 状态，则极有可能存在环路。
- 检查MAC地址漂移：执行 display mac-address mac-move。若有大量漂移记录，或日志中出现 MAC address moved 提示，是二层环路的铁证。
第二步：检查CPU和协议丢包
- 检查CPU：执行 display cpu-usage。如果 bcmRX、FTS 等任务占用持续高于80%甚至95%，说明CPU正忙于处理海量报文。
- 检查CPCAR丢包：执行 display cpu-defend statistics all。观察你日志中的DHCP_CLIENT、ARP、DHCP_SERVER等协议的 Drop 计数是否在快速增长。
第三步：风暴控制与端口安全
- 启用风暴抑制：这是解决广播风暴的有效手段，在接口视图下配置广播抑制阈值，通常设为端口带宽的5%-10%：
  interface Ten-GigabitEthernet1/0/24
  broadcast-suppression pps 2000
- 配置端口隔离：在接入交换机上启用端口隔离，可以隔离同一VLAN下不同端口间的广播流量，有效减少广播域范围。