网口Link Up后仍然掉线，先看故障时Link是否真的变成Down，再沿收发方向找数据停在哪里。Link Up只说明PHY与对端建立了链路，不能证明MAC、驱动和上层通信都正常。只看网口灯，容易查错方向。
1. 先把链路断开和通信中断分清
复现时同时保存内核日志和ethtool eth0的结果，记录速率、双工、Link状态；接口名按实际替换。如果日志反复出现Link Down和Link Up，优先查网线、对端端口、PHY供电与复位，以及两端协商设置。驱动主动复位也可能造成重连，别直接判定器件损坏。
如果Link持续为Up，只是ping超时或业务断开，就转向数据通路。此时仍可能存在物理误码，不能仅凭Link稳定排除线缆和板级问题。
2. 用故障前后的计数增量判断
在复现前后分别执行ip -s -s link show dev eth0和ethtool -S eth0，比较收发包、CRC错误及丢弃计数。具体可用项取决于驱动。看增量。历史累计值不能说明这次故障发生在哪一刻；驱动重启后计数还可能清零。
不要把所有drop都解释成信号差。缓冲不足、过滤和软件处理也可能丢包，各驱动字段含义要查对应说明。尤其是普通TX packets增加，只能说明主机已把包交给设备，不能据此认定帧已到达网线另一端。
3. 沿发送和接收方向分别追一遍
先在可控的同网段环境发送少量测试流量，再对照本端硬件发送计数、对端接收计数和抓包结果。若本端软件计数增加，硬件发送计数不动，优先查队列、DMA及驱动；若对端已收到本端帧，就继续查返回路径。
接收方向同理：对端确有发送，而本端好帧计数不增，检查中间链路及MAC与PHY接口；好帧已进入硬件，主机却收不到，再看过滤、DMA和接收处理。抓不到包不等于线上没包，错误帧可能在进入抓包位置前就被丢弃。
4. 千兆异常时核对数字接口时序
若千兆丢包、降到百兆后改善，且Link一直稳定，RGMII时序值得优先检查。核对设备树接口模式、MAC与PHY实际配置和板上走线，确认收发时钟延时由哪一侧提供，避免漏加或重复添加。
这只是线索。降速会同时改变多个工作条件，不能单凭百兆正常就认定RGMII有错，也不能据此认定网络变压器不合适。每次只改一个条件，并保留前后记录。
5. 常见问题
5.1 CRC错误增加，就能定位到网线吗？
不能。CRC错误说明接收到的帧校验有问题，故障可能在线缆、模拟链路或MAC与PHY数字接口。先换已知正常的线缆和对端做对照，再结合错误出现的方向、速率及接口时序缩小范围，不要只凭一个计数更换器件。
5.2 Link正常、收发计数也增加，为何仍ping不通？
计数可能来自其他流量，不能证明目标请求和响应已完成。先核对目标IP、子网、路由及VLAN，再观察ARP请求有没有响应、ICMP请求到了哪一端，并核对防火墙策略。能收到广播，也不代表单播路径已经正常。
5.3 排障记录最少要保留什么？
保留故障时间、连接拓扑、两端配置、链路日志，以及复现前后同一组计数。补充流量方向和包长、驱动版本及每次改动。这样才能区分链路重连、帧错误和主机接收处理异常，也便于下一轮测试沿着已经确认的边界继续。