接到保障,说某来机器服务没法访问,于是,准备连接到机器上去看个究竟.

尼玛居然连不上,连ping都ping不通,无奈只能求助机房. 机房人员检查, 发现报 neighbour table overflow 错误. 无奈让机房的人员重启了服务器.

查找原因,搜索得到如下说法:

第一种说法：

内核维护的arp表过于庞大, 发生抖动, 因此导致了这种情况,几个内核ARP参数:
=================================
gc_stale_time
决定检查一次相邻层记录的有效性的周期。当相邻层记录失效时，将在给它发送数据前，再解析一次。缺省值是60秒。
gc_thresh1
存在于ARP高速缓存中的最少层数，如果少于这个数，垃圾收集器将不会运行。缺省值是128。
gc_thresh2
保存在 ARP 高速缓存中的最多的记录软限制。垃圾收集器在开始收集前，允许记录数超过这个数字 5 秒。缺省值是 512。
gc_thresh3
保存在 ARP 高速缓存中的最多记录的硬限制，一旦高速缓存中的数目高于此，垃圾收集器将马上运行。缺省值是1024。
=================================
比如arp -an|wc -l的结果是300左右, 那么应当调高gc_thresh各项数值,防止抖动的发生:
echo "net.ipv4.neigh.default.gc_thresh1 = 512" >> sysctl.conf
echo "net.ipv4.neigh.default.gc_thresh2 = 2048" >> sysctl.conf
echo "net.ipv4.neigh.default.gc_thresh3 = 4096" >> sysctl.conf

或者

echo 120 > /proc/sys/net/ipv4/neigh/default/gc_stale_time
echo 512 > /proc/sys/net/ipv4/neigh/default/gc_thresh1
echo 2048 > /proc/sys/net/ipv4/neigh/default/gc_thresh2
echo 4096 > /proc/sys/net/ipv4/neigh/default/gc_thresh3

第二种说法：
默认路由或者子网掩码设置错误,检查

第三种说法：
内核编译错误

第四种说法：
原来那台机器的iptables没有开，不知道开了以后会不会好了，等等看吧。

于是查看了下 ARP 表,发现ARP表不断的在增长.一度增长到730多条记录.理论上来说,机器应该只会保存一条ARP记录,就是网关的.而现在保存了很多条记录,都是公网IP对应网关MAC地址的记录.以为是机器被人入侵了,种下了ARP欺骗神马的程序. 通过 tcpdump 抓包发现,确实是本机不断的在发送ARP请求包. 找了一个多小时,硬是没找到原因.

后来通过访问本机上的某个服务,ARP表中立即就增加了一条ARP记录. 是我的出口的IP,对应的服务器网关的MAC.

于是,理了一下思绪,为什么ARP表中的记录不是网关的MAC,而是直接对应我用户的公网IP和服务器网关的MAC地址.看一下网络通信的流程:

1. 用户请求服务器的服务到达服务器

2. 服务器响应请求,首先查找本机的路由表,如果有路由,直接通过该接口将数据丢过去.如果没有路由,则将数据丢给默认网关.

3. 丢数据出去,得解析ARP,将IP转换为MAC地址. 二层都是通过MAC地址通信的嘛

4. 于是查找本地的MAC地址表,有记录则发送过去.没记录,则广播ARP. 问谁是 x.x.x.x .

5. 现在的问题很显然是服务器在不断的广播ARP,而响应的则是服务器网关.而服务器网关是交换机.顺便查了下,交换机的代理ARP功能. 而这个功能交换机一般默认都是开启的.

6. 于是不断的添加ARP记录到ARP表中,都是用户的访问IP和网关的MAC地址

6. 尼玛去查了一下路由表,震惊了. 网关居然配置的自己本身的接口IP地址,而不是网关的IP. 怪不得.

7. 默认路由是自己的接口IP,为嘛还能与外界通信? 因为服务器是跟网关直连的呀! 我勒个擦

所以, 我这个问题,验证了第二种方法,默认路由或者子网掩码设置错误!

而这个错误,导致了ARP记录过于庞大,最终服务器挂了.