网络编程之网络丢包故障如何定位？如何解决？( 四 ) _网络丢包

文章插图

解决方案：

根据实际场景设置对应的值，一般默认是关掉此过滤规则，特殊情况可以打开；0：默认值，表示回应arp请求的时候不检查接口情况；1：表示回应arp请求时会检查接口是否和接收请求接口一致，不一致就不回应；

arp表满导致丢包
比如下面这种情况，由于突发arp表项很多超过协议栈默认配置，发送报文的时候部分arp创建失败，导致发送失败，从而丢包：

文章插图

查看：

查看arp状态：cat /proc/net/stat/arp_cache ，table_fulls统计：
查看dmesg消息（内核打印）：

文章插图

dmesg|grep neighbourneighbour: arp_cache: neighbor table overflow!

查看当前arp表大小：ip n|wc -l

查看系统配额：

sysctl -a |grep net.ipv4.neigh.default.gc_threshgc_thresh1：存在于ARP高速缓存中的最少层数，如果少于这个数，垃圾收集器将不会运行 。缺省值是128 。gc_thresh2 ：保存在 ARP 高速缓存中的最多的记录软限制 。垃圾收集器在开始收集前，允许记录数超过这个数字 5 秒 。缺省值是 512 。gc_thresh3 ：保存在 ARP 高速缓存中的最多记录的硬限制，一旦高速缓存中的数目高于此，垃圾收集器将马上运行 。缺省值是1024 。

一般在内存足够情况下，可以认为gc_thresh3 值是arp 表总大小；

文章插图

解决方案：根据实际arp最大值情况（比如访问其他子机最大个数），调整arp表大小

$ sudo sysctl -w net.ipv4.neigh.default.gc_thresh1=1024$ sudo sysctl -w net.ipv4.neigh.default.gc_thresh2=2048$ sudo sysctl -w net.ipv4.neigh.default.gc_thresh3=4096$ sudo sysctl-p

arp请求缓存队列溢出丢包
查看：
cat /proc/net/stat/arp_cache ，unresolved_discards是否有新增计数解决方案：根据客户需求调整缓存队列大小unres_qlen_bytes：

文章插图

网络IP层丢包接口ip地址配置丢包1. 本机服务不通，检查lo接口有没有配置地址是127.0.0.1；
2 .本机接收失败，查看local路由表：ip r show table local|grep 子机ip地址；这种丢包一般会出现在多IP场景，子机底层配置多ip失败，导致对应ip收不到包而丢包；

文章插图

解决方案：
1.配置正确接口ip地址；比如ip a add 1.1.1.1 dev eth0
2.如果发现接口有地址还丢包，可能是local路由表没有对应条目，紧急情况下，可以用手工补上：
比如ip r add local 本机ip地址 dev eth0 table local ；
路由丢包路由配置丢包
查看：
1.查看配置路由是否设置正确（是否可达），是否配置策略路由（在弹性网卡场景会出现此配置）ip rule：

文章插图

然后找到对应路由表。查看路由表：

文章插图

或者直接用 ip r get x.x.x.x，让系统帮你查找是否存在可达路由，接口是否符合预期；
2.查看系统统计信息：
netstat -s|grep "dropped because of missing route"解决方案：重新配置正确的路由；
反向路由过滤丢包
反向路由过滤机制是Linux通过反向路由查询，检查收到的数据包源IP是否可路由（Loose mode）、是否最佳路由（Strict mode），如果没有通过验证，则丢弃数据包，设计的目的是防范IP地址欺骗攻击。
查看：
rp_filter提供三种模式供配置：
0 - 不验证
1 - RFC3704定义的严格模式：对每个收到的数据包，查询反向路由，如果数据包入口和反向路由出口不一致，则不通过
2 - RFC3704定义的松散模式：对每个收到的数据包，查询反向路由，如果任何接口都不可达，则不通过
查看当前rp_filter策略配置：
$cat /proc/sys/net/ipv4/conf/eth0/rp_filter
如果这里设置为1，就需要查看主机的网络环境和路由策略是否可能会导致客户端的入包无法通过反向路由验证了。
从原理来看这个机制工作在网络层，因此，如果客户端能够Ping通服务器，就能够排除这个因素了。