第4章 丢包现象分类
做网络排障这么多年，我碰到的丢包问题五花八门。但说到底，丢包原因就那么几类。你想想看，数据包从PC发出去，经过交换机，再到对端，每个环节都可能出问题。我个人习惯先把丢包按位置分成三大类：物理层丢包、交换机丢包、PC端丢包。这样分层排查，效率最高。
物理层丢包：最容易被忽略的源头
我刚开始做网络运维时，有次客户报丢包，我查了两天交换机配置，最后发现是机柜角落里一根网线被老鼠咬断了。嗯，物理层的问题往往最基础，但排查顺序却经常被放在最后。说白了，网线没插好、光模块光衰过大、接口松动，这些都能导致丢包。
- 线缆故障：双绞线断芯、水晶头接触不良、光纤弯折过大。我在项目中遇到过一根光缆被施工队铲断，丢包率直接飙到30%。
- 接口协商失败：两端速率/双工模式不匹配。比如一边是100M全双工，另一边是100M半双工，冲突不断，丢包随之而来。
- 光功率异常：光模块发光功率太低或接收光功率超出阈值。可以用光功率计测一下，或者通过交换机命令行查看光模块信息。
交换机丢包：最需要深挖的环节
交换机是网络的枢纽，丢包原因也最复杂。我个人习惯把它拆成三个子类：
1. 缓存溢出丢包
交换机的端口都有一定大小的缓冲队列。当入向流量瞬间超过出向带宽，数据包就被暂存在缓存里。如果持续拥塞，缓存满了，后面的包直接丢弃。这就是所谓的“尾部丢弃”。
举个例子：你PC接在千兆口上，但上联口只有百兆。你从PC发一个500M的文件，上联口出口带宽只有100M，缓存很快被填满，丢包率直线上升。
show interface queue 或 show buffers 查看端口丢弃计数。如果 Output drops 持续增长，八成是缓存溢出。
2. MAC表满丢包
每台交换机都有一个MAC地址表，记录哪个MAC对应哪个端口。当网络中存在大量新MAC（比如广播风暴攻击、虚拟机迁移），MAC表被撑满，交换机对于未知单播帧就只能广播，或者直接丢弃。我见过一个客户内网有2000多台终端，交换机MAC表上限只有1024，结果丢包严重。
show mac address-table count 查看当前MAC条目数，对比设备规格。如果接近上限，就需要考虑升级或配置MAC表老化时间。
3. ACL/策略丢包
访问控制列表（ACL）配置错误或流量整形策略也可能导致丢包。很多运维在排查时只盯着物理层和拥堵，忘了检查ACL。我曾经在一个项目中，安全团队在核心交换机上加了一条deny规则，结果把正常的业务流量全丢了，排查了整整一个下午。
| 丢包子类 | 典型现象 | 快速定位命令 |
|---|---|---|
| 缓存溢出 | 端口Output drops持续增加 | show int | in drops |
| MAC表满 | 未知单播广播增多，CPU利用率上升 | show mac address-table count |
| ACL丢包 | 特定源/目的之间通信中断 | show access-list 加抓包验证 |
PC端丢包：有时问题就在你自己手里
你想想看，PC网卡驱动版本不对、接收缓冲区太小、防火墙拦截，都可能造成丢包。而且PC端丢包有个特点——丢包率通常不高，但极不稳定。
- 网卡驱动异常：驱动太旧或兼容性差，会导致大量校验和错误。可以在设备管理器中查看网卡属性里的“数据包被丢弃”计数。
- 接收缓冲区不足：Windows默认的接收缓冲区只有256KB，如果大流量场景下缓冲区满了，内核直接丢包。我建议在网卡高级设置里把“接收缓冲区”调到最大（比如4096）。
- 防火墙/安全软件：某些安全策略会随机丢弃异常流量，尤其是非标准端口的UDP包。
netstat -s 查看IP统计信息，看“接收的数据包丢弃”计数。如果这个数字持续增长，那PC端就是元凶。
好了，丢包现象分类就讲到这里。记住这张分类图，后面每一类我们都会展开讲具体的抓包定位方法。说白了，丢包不可怕，可怕的是不知道丢在哪个环节。而你现在已经有了全局地图。