S6520X-54QC-HI 端口异常down告警信息问题咨询
- 0关注
- 0收藏，127浏览
问题描述：
%Aug 7 08:40:23:260 2026 ITC-C15-U16-Border-Leaf-1 DRVPLAT/4/DRVPLAT_SOFTCAR_DROP:
PktType=ROOT, SrcMAC=001c-54ff-080b, Dropped from interface=Ten-GigabitEthernet1/0/1 at Stage=1, StageCnt=31, TotalCnt=181953, MaxRateInterface=Ten-GigabitEthernet1/0/1.
%Aug 7 08:46:45:696 2026 ITC-C15-U16-Border-Leaf-1 SNMP/6/SNMP_SET: -seqNO=1406-srcIP=10.20.51.33-op=SET-errorIndex=0-errorStatus=noError-node=sysName(1.3.6.1.2.1.1.5.0)-value=ITC-C15-U16-Border-Leaf-1; The agent received a message.
%Aug 7 08:53:19:169 2026 ITC-C15-U16-Border-Leaf-1 CFGMAN/5/CFGMAN_CFGCHANGED: -EventIndex=2579-CommandSource=snmp-COnfigSource=startup-COnfigDestination=running; Configuration changed.
%Aug 7 09:40:33:369 2026 ITC-C15-U16-Border-Leaf-1 DRVPLAT/4/DRVPLAT_SOFTCAR_DROP:
PktType=ROOT, SrcMAC=001c-54ff-080b, Dropped from interface=Ten-GigabitEthernet1/0/1 at Stage=63, StageCnt=6292, TotalCnt=188245, MaxRateInterface=Ten-GigabitEthernet1/0/1.
%Aug 7 10:32:19:928 2026 ITC-C15-U16-Border-Leaf-1 SYSLOG/5/LOGFILE_USAGEHIGH: The usage of log-file flash:/logfile/logfile.log reaches 80%.
%Aug 7 10:40:42:247 2026 ITC-C15-U16-Border-Leaf-1 DRVPLAT/4/DRVPLAT_SOFTCAR_DROP:
PktType=ROOT, SrcMAC=001c-54ff-080b, Dropped from interface=Ten-GigabitEthernet1/0/1 at Stage=63, StageCnt=2965, TotalCnt=191210, MaxRateInterface=Ten-GigabitEthernet1/0/1.
%Aug 7 10:46:46:923 2026 ITC-C15-U16-Border-Leaf-1 SNMP/6/SNMP_SET: -seqNO=1407-srcIP=10.20.51.33-op=SET-errorIndex=0-errorStatus=noError-node=sysName(1.3.6.1.2.1.1.5.0)-value=ITC-C15-U16-Border-Leaf-1; The agent received a message.
%Aug 7 10:53:19:169 2026 ITC-C15-U16-Border-Leaf-1 CFGMAN/5/CFGMAN_CFGCHANGED: -EventIndex=2581-CommandSource=snmp-COnfigSource=startup-COnfigDestination=running; Configuration changed.
%Aug 7 11:00:12:445 2026 ITC-C15-U16-Border-Leaf-1 IFNET/4/IF_LOCAL_FAULT: A local fault alarm occurs on Ten-GigabitEthernet1/0/48.
%Aug 7 11:00:12:458 2026 ITC-C15-U16-Border-Leaf-1 IFNET/3/PHY_UPDOWN: Physical state on the interface Ten-GigabitEthernet1/0/48 changed to down.
%Aug 7 11:00:12:474 2026 ITC-C15-U16-Border-Leaf-1 IFNET/5/LINK_UPDOWN: Line protocol state on the interface Ten-GigabitEthernet1/0/48 changed to down.
%Aug 7 11:00:12:475 2026 ITC-C15-U16-Border-Leaf-1 LAGG/6/LAGG_PORT_DISCARDING_STATE: Member port XGE1/0/48 of RAGG1023 changed to the discarding state.
%Aug 7 11:00:12:486 2026 ITC-C15-U16-Border-Leaf-1 LAGG/6/LAGG_INACTIVE_PHYSTATE: Member port XGE1/0/48 of aggregation group RAGG1023 changed to the inactive state, because the physical or line protocol state of the port was down.
%Aug 7 11:00:31:118 2026 ITC-C15-U16-Border-Leaf-1 IFNET/4/IF_LOS: A LOS alarm occurs on Ten-GigabitEthernet1/0/48.
%Aug 7 11:01:44:723 2026 ITC-C15-U16-Border-Leaf-1 LLDP/5/LLDP_NEIGHBOR_AGE_OUT: Nearest bridge agent neighbor aged out on port Ten-GigabitEthernet1/0/48 (IfIndex 48), neighbor's chassis ID is 8061-6c7a-9723, port ID is Ten-GigabitEthernet1/0/48.
上面是日志，这48口是mlag的keepalive口，更换光模块恢复正常，但是过几个小时又down了
这个1/0/1口的丢包跟1/0/48会有关系吗
最佳答案
- XGE1/0/1 的 DRVPLAT_SOFTCAR_DROP 软件队列丢包，和 XGE1/0/48 M-LAG 保活口反复 Down 属于两类独立故障，不存在因果关系，但环境压力叠加会互相放大恶化问题；
- XGE1/0/48 反复本地故障 LOS 掉线，本质是光路 / 光模块 / 尾纤故障、光功率劣化，更换模块临时修复、几小时复发是典型光纤衰减、端面脏污、光模体质不良特征；
- XGE1/0/1 上报
DRVPLAT_SOFTCAR_DROP ROOT类型报文软丢弃，是上联流量拥塞、队列超限造成的 CPU 上行队列丢包，不会直接导致 M-LAG 保活端口物理断连。
一、分开拆解两条告警含义
1）XGE1/0/48（M-LAG Keepalive 保活端口）故障日志分析
IFNET/4/IF_LOCAL_FAULT: 本地故障告警
IFNET/4/IF_LOS: LOS信号丢失
PHY_UPDOWN physical down → 聚合组成员被置为discarding/inactive
- LOS = 光模块收不到对端光信号，纯物理层故障；
- 该端口专门用作 M-LAG 两台 Leaf 之间的 Keepalive 保活链路，只传输 M-LAG 协商报文，流量极小，不存在拥塞挤断链路的可能；
- 现象：换光模块立刻恢复、数小时后再次 Down，典型诱因排序：
- 光纤端面脏、弯折挤压、尾纤老化衰减，光功率缓慢下跌触发 LOS；
- 更换的光模块本身品质差、工作温升后光功率漂移劣化（运行升温几小时后灵敏度下降收光失败）；
- 对接对端交换机 48 口光口插槽故障、背板金手指氧化；
- 光模块 DDM 收光功率临界阈值，温度升高后收光低于接收灵敏度下限。
M-LAG 保活链路几乎无流量，不可能因为 1/0/1 口拥塞丢包导致 48 口物理 DOWN。
2）XGE1/0/1 DRVPLAT/4/DRVPLAT_SOFTCAR_DROP 软丢弃日志
PktType=ROOT 内核上送CPU的协议报文被软件队列丢弃
Dropped from interface=Ten-GigabitEthernet1/0/1
- ROOT 报文特指：STP、LLDP、M-LAG 协商、OSPF/BGP、ARP 等需要上送主控 CPU 处理的控制协议报文；
- 成因：XGE1/0/1 上联流量过大、突发流量冲击，芯片送往 CPU 的上送队列拥塞溢出，交换机为保护主控 CPU 主动丢弃控制报文；
- 影响：只会造成协议报文丢包（邻居震荡、STP 计算缓慢、LLDP 老化变快），不会触发光口 LOS 物理断电下线。
二、二者会不会间接互相影响？
- XGE1/0/1 持续丢弃控制报文 → 整机 CPU 协议处理压力异常、整机协议运行不稳定；
- 此时 M-LAG 保活链路（1/0/48）刚好光功率劣化，原本轻微收光不稳不会断网，叠加整机协议处理卡顿后，微小的 LOS 抖动就会直接判定端口 Down；
- 简单讲：48 口掉线根源是光路 / 光模块物理劣化，1 口 CPU 队列丢包属于环境压力，只会让故障更容易爆发、故障表现更严重，但并不是掉线的病因。
三、分步排查解决手段
第一阶段：彻底根治 M-LAG Keepalive 口 XGE1/0/48 反复 LOS Down
- 查看实时 DDM 光功率（核心判断依据）
display transceiver diagnosis interface Ten-GigabitEthernet 1/0/48
- 正常万兆多模光模块：收光 -6~-18dBm；单模 10km：-5~-20dBm；
- 收光持续走低、运行几小时后逐步低于模块接收灵敏度（比如 <-22dBm）= 光纤衰减 / 端面脏；
- 换全新原厂同型号光模块、更换整条尾纤，清洁两端光口端面，不要只换模块复用旧光纤。
- 优化 M-LAG 保活链路部署方案（规避单点光链路故障影响 M-LAG 稳定性） 当前只用单条 XGE1/0/48 作为 Keepalive 链路，一旦链路中断，M-LAG 分裂风险极高，建议：
- 改用管理口（MGMT 电口）做 M-LAG Keepalive 保活链路，彻底脱离光链路故障；
m-lag keepalive interface M-GigabitEthernet 0/0
- 保留 XGE1/0/48 作为普通 peer-link 成员，不再承担保活功能。
- 规避端口震荡带来的 M-LAG 抖动
interface Ten-GigabitEthernet 1/0/48
link-flap protection disable
port link-delay 3000
第二阶段：解决 XGE1/0/1 ROOT 控制报文软丢包 DRVPLAT_SOFTCAR_DROP
- 查看上联接口流量、CPU 占用，确认是否存在流量突刺：
display interface Ten-GigabitEthernet 1/0/1
display cpu usage task
display qos queue statistics interface Ten-GigabitEthernet 1/0/1
- 限制不必要报文上送 CPU，缓解 CPU 队列拥塞：
system-view
# 关闭不需要上送CPU的报文
undo stp bpdu tunnel enable
# 针对上联口做ACL限流，抑制广播、未知单播泛洪上送CPU
interface Ten-GigabitEthernet 1/0/1
port storm-control broadcast kbps 50000
port storm-control multicast kbps 80000
port storm-control unknown-unicast kbps 30000
- 升级 S6520X-HI 固件至正式稳定版本（5489P02 版本存在部分场景 CPU 队列调度 BUG，容易出现 ROOT 报文无故丢弃）。
四、补充重要说明
- IF_LOCAL_FAULT + LOS 是物理层信号丢失，由光模块、光纤、硬件插槽决定； DRVPLAT_SOFTCAR_DROP 是二层转发完成后送往 CPU 的软件队列溢出丢包，属于数据层面拥塞； 二者属于不同层级故障，无直接因果；
- 如果你不迁移 Keepalive 到管理电口，后续光纤一旦彻底断裂，两台 M-LAG 设备会分裂双活，极易引发全网二层环路、广播风暴。
- 日志内同时出现
LOGFILE_USAGEHIGH 日志占用80%，顺带清理交换机日志释放 Flash 空间：
delete flash:/logfile/logfile.log
最简处置顺序
- 把 M-LAG keepalive 迁移至 MGMT 管理电口，彻底规避光链路故障；
- 更换 48 口全套光纤 + 原厂全新光模块，监测 DDM 收光功率是否稳定；
- 上联 XGE1/0/1 配置风暴抑制，解决 CPU 控制报文软丢包；
- 交换机固件升级至最新正式版本。
排查步骤及命令：
1. 确认端口状态：
display interface Ten-GigabitEthernet 1/0/1
display interface brief
查看端口是否真的Down，以及入方向报文统计是否存在异常增长。
2. 溯源攻击源：
告警中SrcMAC=001c-54ff-080b为源MAC，通过MAC地址表定位接入位置：
display mac-address 001c-54ff-080b
display arp | include 001c-54ff-080b
3. 检查软CAR配置：
查看当前ROOT类型报文的软CAR限速值：
display cpu-protect type 2 // 2对应STP/ROOT类报文，不同版本索引可能有差异，可通过display cpu-protect ?查看
4. 临时缓解：
若确认是合法报文但阈值偏低，可调整软CAR限速（需谨慎，避免冲击CPU）：
system-view
cpu-protect type 2 cir 64 // 单位为kbps，根据实际业务调整
若为非法攻击，可在接入端口配置ACL过滤或配置端口安全、BPDU保护等功能。
5. 收集信息反馈：
若需进一步定位，收集display diagnostic-information日志，联系H3C技术支持分析。
暂无评论
从日志来看，Ten-GigabitEthernet1/0/1 的丢包与 Ten-GigabitEthernet1/0/48 的端口down，两者之间没有直接因果关系，它们是两件独立的事件。
简单来说，1/0/1口的问题是收到了过量的特定协议报文，被交换机的CPU保护机制丢弃了；而1/0/48口的问题则是物理链路不稳定。虽然互不影响，但两者都需要排查解决。
📊 问题一：1/0/1端口丢包（DRVPLAT_SOFTCAR_DROP）
这是一个由交换机 CPU保护机制 触发的警告，并非硬件故障。
根本原因：端口
Ten-GigabitEthernet1/0/1收到了来自源MAC001c-54ff-080b的大量ROOT类型报文。从现有信息推测，ROOT很可能代表 ARP（地址解析协议） 报文。触发机制：当上送CPU处理的报文速率超过设定阈值时，交换机会随机丢弃超限部分，并打印此日志，这是一种正常的自我保护。
可能原因：
🔌 问题二：1/0/48端口频繁Down（M-LAG Keepalive链路）
这是典型的物理链路不稳定问题。你提到“更换光模块恢复正常，但是过几个小时又down了”，这强烈指向硬件或兼容性问题。
直接原因：端口产生了本地故障（
IF_LOCAL_FAULT），导致物理状态（PHY_UPDOWN）和协议状态（LINK_UPDOWN）变为down。随后，其所属的聚合组RAGG1023也感知到成员端口失效。可能原因：
对M-LAG的影响：
1/0/48作为Keepalive链路，其频繁抖动是M-LAG系统的大忌。虽然Keepalive链路down不会立刻导致业务中断，但会严重影响系统对“双主”冲突的检测能力，增加网络环路的风险。
🔗 两者有关联吗？
结论是：基本没有直接关联。
1/0/1口的丢包是 “报文太多被丢弃”，是交换机对CPU的保护行为。1/0/48口的down是 “物理层信号丢失”，是硬件链路问题。
它们的故障点不同，一个是数据平面问题，一个是物理层问题。除非1/0/48口down后触发了路由收敛，导致大量报文被重新路由到1/0/1口，但从日志的时间间隔看，这种可能性很小。
🛠️ 排查与解决建议
建议你按照“先物理后逻辑”的顺序进行排查。
针对 1/0/48 端口频繁Down（优先级最高）
确认光模块兼容性：执行
display transceiver interface Ten-GigabitEthernet 1/0/48，确认光模块是否为H3C认证的型号。非原厂模块是首要怀疑对象。检查物理链路：
清洁光纤接头和模块端口。
检查光纤是否有弯折、破损。
尝试更换一根已知良好的光纤。
检查光功率：执行
display transceiver diagnosis interface Ten-GigabitEthernet 1/0/48，查看接收光功率（Rx Power） 是否在正常范围内且稳定。功率过低或剧烈波动都说明链路有问题。交叉测试：将
1/0/48口的光模块换到其他正常端口，或将其他正常端口的光模块换到1/0/48，观察故障是否跟随模块或端口转移。
针对 1/0/1 端口丢包
暂无评论
编辑答案
亲~登录后才可以操作哦!
确定你的邮箱还未认证，请认证邮箱或绑定手机后进行当前操作
举报
×
侵犯我的权益
×
侵犯了我企业的权益
×
- 1. 您举报的内容是什么？（请在邮件中列出您举报的内容和链接地址）
- 2. 您是谁？（身份证明材料，可以是身份证或护照等证件）
- 3. 是哪家企业？（营业执照，单位登记证明等证件）
- 4. 您与该企业的关系是？（您是企业法人或被授权人，需提供企业委托授权书）
抄袭了我的内容
×
原文链接或出处
诽谤我
×
- 1. 您举报的内容以及侵犯了您什么权益？（请在邮件中列出您举报的内容、链接地址，并给出简短的说明）
- 2. 您是谁？（身份证明材料，可以是身份证或护照等证件）
对根叔社区有害的内容
×
不规范转载
×
举报说明
暂无评论