stp 提示discarding

这条日志本身是 MSTP 的正常保护动作——端口被置 Discarding 是为了防环/防根漂移，不是故障本体。"频繁报警"才是关键，说明触发源在反复作用，得往下挖根因。
先把日志语义拆开
hwPortMstiStateDiscarding: Instance 0's Port 0.9437223 → GigabitEthernet1/0/3 discarding
Instance 0= MSTP 域里的 CIST（公共实例），也就是你没做多实例时的默认实例
Gi1/0/3从 forwarding/learning → discarding，触发了 PDISC 告警（级别 Warning）
端口号 0.9437223是内部 ifIndex 映射，后面已经帮你解析到物理口了，不用管
Discarding 本身只说明三件事之一：端口角色算成了 Alternate/Backup、或者被某条保护机制（根保护/环路保护/dispute）拦了。要定位为什么，得看 display stp brief里这个口的 Role + Protection​ 字段。
接入交换机"频繁" discarding，高频根因按概率排
① 下联形成环路 / 边缘端口没配（最高频）
结合你上轮在问 AP，Gi1/0/3 如果是下联 AP 或下挂个小交换机：
AP 本身如果跑了桥接模式（或者 AP 下又接了傻 Hub、桌面小交换机），AP 侧把 BPDU 传回来​ → 本端收到自己的 BPDU → 触发 STP LOOPBACK PROTECTION，端口被强制 discarding
接入端口没配 stp edged-port（原 stp port edge），终端/AP 偶尔发 BPDU 就会把端口踢一下，收敛完又恢复，于是"频繁报警"
💡 判断线索：同时间段有没有伴随 %STP/4/STP_LOOPBACK_PROTECTION或 %STP/6/STP_DETECTED_TC日志，有就是这条。
② 根桥没固化，对端发了"更优"BPDU → 根保护触发
如果 Gi1/0/3 不是下联终端而是下联另一台交换机，且那头桥优先级比你的根还小：
本端若配了 stp root-protection→ 收到更优 BPDU 直接 discarding
没固化根优先级时，新设备上架/重启都可能抢根，全网重算，接入层口反复翻
③ Dispute 保护（V7 平台特有）—— BPDU 单通
H3C V7 默认开 stp dispute-protection。场景：
链路拥塞 / 单向不通 / trunk 把 VLAN 1 禁了​ → BPDU 是高优先级走 Instance 0，但下游收不到上游的高优 BPDU，上游反而收到下游低优 BPDU → 认为可能环路，端口置 discarding
这种特别容易出现在 H3C 对接华为/其他厂商，两边路径开销标准不一样（dot1t vs legacy）也会叠加
④ 链路本身在抖
光模块、网线、对端端口频繁 up/down → STP 反复重算 → TC 不断产生 → 端口状态跟着跳。看下 Gi1/0/3 有没有 CRC 错、up/down 日志一起刷。
自检三步走（5 分钟能定位）
# 1. 看 Gi1/0/3 的角色 + 保护类型（最关键）
display stp interface GigabitEthernet1/0/3 brief
# 关注 Role(ROOT/DESI/ALTE/BACK) 、 STP State 、 Protection 、 Edged

# 2. 看异常端口的阻塞原因
display stp abnormal-port
# BlockReason 会直接写 ROOT_PROTECTION / LOOP_PROTECTION / DISPUTE / AGING...

# 3. 看 TC 是谁在刷
display stp topology-change
# 哪个端口不停发 TC，基本就锁定下联哪台设备在搞事
把 display stp brief里 Gi1/0/3 那行的 Role / Protection​ 贴出来，根因就能直接锁。
接入层收敛建议（治本）
不管这次根因是哪条，接入交换机这套组合拳建议都配上，能灭掉 90% 的类似告警：
# 连终端/AP 的口（下联不再接交换机）
interface GigabitEthernet1/0/3
stp edged-port enable # 不再等 30s 直接转发，且不参与根计算
stp bpdu-protection # 真收到 BPDU 直接 shutdown 而不是抖

# 全局
stp tc-protection # 防 TC 风暴把 MAC/ARP 刷爆
stp instance 0 priority 4096 # 核心/汇聚固化根优先级，别让接入抢
如果 Gi1/0/3 是 uplink 往上连汇聚，那 edged-port千万别配，那条口应该走 root-protection或者干脆靠根优先级压制。

一、日志含义解读
plaintext
Instance 0's GigabitEthernet1/0/3 has been set to discarding state!
实例 0（CST 总树）G1/0/3 端口被 STP 置为Discarding 丢弃状态，代表 STP 判定这条链路存在二层环路，主动阻断该端口防止广播风暴。
端口进入 Discarding 后：不转发业务流量、不学习 MAC，仅收发 BPDU 报文。
二、端口被 Discarding 的几类核心原因（按现场高频排序）
1. 真实二层环路（最常见）
G1/0/3 这条链路和其他链路形成物理环路：
两根网线同时互联两台交换机；
下联傻瓜交换机、AP、监控 POE 交换机存在自环 / 双线上联；
AP 有线口级联、摄像头交换机两根线回传接入交换机。
STP 计算后选出最优链路转发，多余链路端口阻塞 discarding。
2. 收到劣等 BPDU，触发 DISPUTE 争议保护震荡
上联 / 下联设备发送 BPDU 优先级更低，本地端口同时收到优、劣两种 BPDU，STP 判定潜在环路，临时 discarding，几秒后恢复转发，反复循环、持续打日志。
典型特征：日志交替出现discarding+forwarding来回切换。
3. 链路协商故障、报文丢包导致 BPDU 超时
网线损坏、水晶头氧化、光模块故障、双工不匹配、CRC 报错：
BPDU 报文间歇性丢失；
交换机收不到对端 BPDU，认为链路失效→端口放开转发；
后续又收到 BPDU，立刻重新 discarding 阻断；
表现为端口状态频繁来回震荡，持续弹窗告警。
4. 边缘端口收到 BPDU 自动退出 edge-port，参与 STP 计算
端口配置stp edged-port（AP / 摄像头口），下方设备产生环路发送 BPDU：
Edge-port 收到 BPDU，取消边缘端口身份；
参与 STP 运算，若该端口为冗余链路，直接被 discarding；
同时伴随日志STP_EDGEPORT_INACTIVE。
5. MSTP 域配置不一致（多设备场景）
多台交换机 MST 域参数不统一：域名、修订级别、实例 - VLAN 映射表不一致，导致域边界端口逻辑环路，端口持续 discarding。
三、快速定位排查步骤
查看端口当前 STP 角色、状态
plaintext
display stp interface GigabitEthernet 1/0/3
重点看：端口角色（Alternate/Backup/Designated/Root），Alternate/Backup 端口正常就是 discarding。
检查端口是否有大量错误报文，判断链路质量
plaintext
display interface GigabitEthernet 1/0/3
查看 CRC、error、冲突包，有大量报错 = 网线 / 硬件故障。
检查端口是否配置边缘端口
plaintext
display current-interface GigabitEthernet 1/0/3 | include stp
存在stp edged-port就是下联设备发 BPDU 触发。
追踪环路来源
拔掉 G1/0/3 下联所有设备，观察日志是否停止：
日志消失：下联 AP / 傻瓜交换机存在环路；
日志依旧：上联汇聚交换机冗余链路导致正常阻塞。
四、两种场景区分处理
场景 A：正常冗余链路阻塞（无故障，无需处理）
组网做了双上行冗余，STP 自动阻塞备用链路，端口长期 discarding 属于正常设计，告警可屏蔽：
plaintext
undo info-center source MSTP channel logbuffer filter PDISC
场景 B：端口频繁震荡、反复 discarding<->forwarding（故障，必须处理）
边缘端口增加 BPDU 保护，收到 BPDU 直接 shutdown，不再震荡：
plaintext
interface GigabitEthernet 1/0/3
stp bpdu-protection
排查下联环路，移除自环 / 双线级联网线；
更换故障网线、光模块，修复端口 CRC 错误；
统一全网 MST 域配置，保证域参数完全一致。
简短总结
G1/0/3 被置 Discarding 本质：STP 识别出这条链路会形成二层环路，主动阻断流量。
要么是双上行冗余备用链路正常阻塞；要么下联存在环路、链路质量差、边缘端口收到 BPDU 导致端口频繁震荡告警。

检查下有没有环路