《华为交换机端口频繁up/down排查全过程》一、故障现象二、排查过程第一步先看端口状态别上来就动手第二步查历史日志看是单次事件还是持续故障第三步查对端设备第四步关键命令 —— 查链路协商状态第五步手动固定速率和双工第六步怀疑网线第七步更换网线验证三、根因分析四、解决方案附加配置开启网管告警下次第一时间知道五、排障思维总结六、写在最后一、故障现象某天下午客户报修“财务部网络时断时续ERP软件老是掉线。”我登录核心交换机S5720一看日志好家伙——Jun 28 14:23:15 S5720 %%01PHY/1/PHY(l)[1]: GigabitEthernet0/0/12: change status to down Jun 28 14:23:18 S5720 %%01PHY/1/PHY(l)[2]: GigabitEthernet0/0/12: change status to up Jun 28 14:23:45 S5720 %%01PHY/1/PHY(l)[3]: GigabitEthernet0/0/12: change status to down Jun 28 14:23:48 S5720 %%01PHY/1/PHY(l)[4]: GigabitEthernet0/0/12: change status to upG0/0/12口每十几秒就up一次、down一次频率跟心跳似的。这就是经典的口子抽搐。【配图1交换机日志截图红框标注重复的up/down告警】端口反复up/down意味着物理链路在不断重建上面的MAC地址表、ARP表会被反复清空刷新——上面的业务根本没法用。如果你是网工新手看到这个日志第一反应可能是重启端口试试。别急往下看你会发现重启端口屁用没有。二、排查过程第一步先看端口状态别上来就动手display interface GigabitEthernet0/0/12输出如下关键行GigabitEthernet0/0/12 current state : UP Line protocol current state : UP Last physical up time : 2025-06-28 14:23:48 Last physical down time : 2025-06-28 14:23:45 Input: 28547 packets, 3847291 bytes Unicast: 28102, Multicast: 421, Broadcast: 24 CRC: 0, Giants: 0, Jabbers: 0 Output: 18234 packets, 2210483 bytes Unicast: 18011, Multicast: 212, Broadcast: 11 CRC: 0, Giants: 0分析端口状态在UP但last up/down时间只差3秒确认频繁翻动CRC错误为0 →初步判断不是物理层信号质量问题但还不能完全排除收发包都正常没有异常流量第二步查历史日志看是单次事件还是持续故障display logbuffer|include0/0/12输出发现该端口从今天上午10点开始抽搐累计up/down超过200次且没有停止的迹象。排除项如果是有人拔插网线只会有一次up/down200次反复翻动 → 不是人为操作是物理或配置问题第三步查对端设备G0/0/12连的是一台接入交换机S2730在财务部弱电间。我远程登录过去display interface GigabitEthernet0/0/1对端接口G0/0/1的日志显示也在同步up/down两边一致【配图2两端交换机日志对比显示同步up/down】这说明问题不在某一台设备而在两台设备之间的链路。第四步关键命令 —— 查链路协商状态display interface GigabitEthernet0/0/12|include Negotiation|Speed|Duplex输出Negotiation: ENABLE Speed: 1000, Duplex: FULL协商正常自协商开启千兆全双工——配置没问题。第五步手动固定速率和双工虽然协商正常但自协商在某些情况下会误判。我把两端都强制固定核心交换机interface GigabitEthernet0/0/12 undo negotiation auto speed1000duplex full接入交换机interface GigabitEthernet0/0/1 undo negotiation auto speed1000duplex full观察5分钟故障依旧。端口仍然抽搐。排除了自协商问题。第六步怀疑网线财会部到弱电间距离约40米用的是一根放了3年的成品六类线。这种环境放这么久老鼠咬、墙角压、水晶头氧化什么都有可能。我没法立刻去现场驻场不在那栋楼于是让客户那边的信息科同事去看了下——同事拍了张照片网线从一个铁皮柜子底下穿过去被压了三年外皮都裂了。【配图3现场被铁皮柜压住的网线示意图】到这步基本确定了但我还是让他们做了验证第七步更换网线验证信息科同事换了一根备用的六类线重新走线这次不走柜子底下了。再查日志display logbuffer|include0/0/12|last10换线后30分钟零次up/down。故障消失。【配图4换线后日志截图显示再无up/down告警】三、根因分析故障根因网线物理损伤导致间歇性断路。具体来说时间轴发生了什么3年前布线时把网线压在了铁皮柜下近半年柜子轻微晃动网线外皮磨损近期内部铜芯开始出现裂纹故障当天铜芯在接触/断开间反复跳变接触时链路UP正常通信断开时链路DOWN业务中断为什么CRC错误为零因为铜芯断裂时信号完全中断不是信号衰减交换机检测到的是链路丢失link loss而不是数据错误CRC error。这恰恰说明故障在物理介质而非信号质量。为什么自协商正常自协商信号只需要极短时间就能完成。铜芯短暂接触的瞬间足够完成协商所以始终显示Negotiation: ENABLE, Speed: 1000, Duplex: FULL——这是最容易误导人的地方。四、解决方案立即措施更换网线重新走线路径避开物理压迫点长期预防布线走桥架或线槽禁止直接从家具/设备下方穿过重要链路用成品跳线配线架避免自制水晶头关键端口开启端口事件监控告警附加配置开启网管告警下次第一时间知道snmp-agenttrapenablefeature-name ifnet snmp-agent target-hosttrapaddress192.168.1.100 udp-port162把端口up/down的SNMP告警推到你的网管平台下次不用等客户打电话你比客户先知道。五、排障思维总结遇到端口频繁up/down按这个顺序查① 看日志确认频率 → 排除人为操作 ② 查两端设备状态 → 确认双边同步 ③ 查CRC/错包 → 区分链路丢失还是信号质量差 ④ 查自协商 → 尝试固定速率双工 ⑤ 排查物理介质 → 网线/光模块/光纤 ⑥ 更换验证 → 唯一确认手段一个容易被忽略的经验CRC为0不代表物理层没问题。链路彻底断开的时候根本没有数据包通过自然不会产生CRC错误。CRC统计只能告诉你有数据通过时的质量不能告诉你链路有没有断。六、写在最后这根网线让我跑了整整两小时的排查。回头看看问题其实很简单——但网工的日常不就是这样吗99%的故障根因都是最朴素的东西。如果这篇文章帮你少走了一次弯路那就值了。有问题欢迎在评论区交流我最喜欢干的事就是让网络不再抽搐。【配图5排障思维导图】