光衰过大导致丢包不会出现在tcpdump中，因包在物理层即被丢弃；需直接查光模块DDM的RX Power是否低于接收灵敏度阈值，并结合rx_crc_errors、rx_frame_errors等硬件计数器及光功率计实测交叉验证。
光衰过大导致的丢包，不会在tcpdump里出现，也不会进协议栈——包根本没被网卡正确接收，就已在物理层被丢弃。必须绕过“抓包找包”的惯性思维，直接从光模块诊断信息和硬件级计数器入手。
查光模块DDM参数：RX Power是否逼近接收灵敏度阈值
光衰问题的核心指标是接收光功率（RX Power）。它不是越强越好，而是必须落在模块标称的接收灵敏度（Receiver Sensitivity）与过载光功率（Overload）之间。一旦RX Power低于灵敏度下限（比如GPON常见为-28 dBm），误码率会指数上升，表现为间歇性丢包、注册失败或LOS告警。
- 用
ethtool -m eth0读取数字诊断监控（DDM）数据；若不支持，改用厂商专用工具（如华为display transceiver diagnosis） - 重点关注
RX Power字段，单位是dBm；对比模块规格书里的Min（灵敏度）和Max（过载）值 - 典型异常：
RX Power: -31.2 dBm（而标称灵敏度为-28 dBm），说明光衰已超限，需立即清洁光纤或测线路损耗 - 注意：某些老旧驱动或SFP+模块可能不支持DDM，此时
ethtool -m返回空或报错，不能因此排除光衰问题
盯rx_crc_errors和rx_frame_errors：链路层错误飙升是光衰的强信号
rx_crc_errors和rx_frame_errors不是“丢包”，但它们是光衰引发物理层失真的直接证据。CRC校验失败意味着帧内容已被噪声污染，内核会直接丢弃这些包，且不计入Rx-DRP——你看到的/proc/net/dev里Rx-OK下降、Rx-ERR上升，就是这个原因。
- 运行
ethtool -S eth0 | grep -E "(crc|frame)_errors"，观察数值是否随流量增长而持续上升 - 若
rx_crc_errors> 0 且与丢包时间点高度同步，基本锁定光路质量问题（端面污染、弯折、劣质跳线） - 注意：
rx_crc_errors升高时，rx_over_errors和rx_dropped通常不变——这说明问题不在Ring Buffer或内核处理，而在更底层 - 清洁SC/APC接口必须用专用光纤清洁笔，酒精棉片易残留纤维，反而加剧误码
结合ethtool物理状态与光功率计实测：避免被软件诊断误导
设备上报的RX Power值依赖模块内部ADC精度和驱动解析逻辑，部分廉价模块或固件bug会导致读数严重偏移（例如显示-25 dBm，实测仅-33 dBm）。单靠软件诊断不可靠，必须交叉验证。
- 先用
ethtool eth0确认Link detected: yes且Speed协商正常（如1000BaseX），排除双工/速率不匹配干扰 - 再用专业光功率计（如EXFO FTB-1/FTB-2）在设备收光口实测，波长设为对应PON标准（1490 nm下行 / 1310 nm上行）
- 实测值比模块DDM低2 dBm以上？说明模块校准失效，应更换模块而非调线路
- 实测光衰＞25 dB（GPON典型上限）？检查分光比是否超配（如1:64实际接了80台ONT）、是否存在隐形微弯（线缆被扎带勒紧处）
别跳过环境与累积效应：高温+光衰=偶发掉线的典型组合
光模块性能随温度敏感变化。常温下RX Power勉强达标，但机柜散热不良导致模块升温后，接收灵敏度可能劣化2~3 dB，瞬间越过临界点——这就是为什么丢包总在午后或业务高峰时发生，且重启无效，但降温后暂时恢复。
- 用
ethtool -m eth0同时查看Temperature字段，超过70°C即属高风险区 - 检查设备通风口是否被遮挡，风扇转速是否异常（
ipmitool sdr type fan可查BMC传感器） - 若
Temperature和RX Power存在负相关（温度升10°C，RX Power读数降1.5 dBm），优先解决散热，再处理光路 - 注意：光衰问题极少单点爆发，往往伴随其他设备同类告警。查同一OLT下其他端口是否也出现
rx_crc_errors上升，能快速判断是单模块故障还是整条光链路劣化
