来源 https://juejin.im/post/6844904166545080334

Linux内核网络协议栈中自动维护着一堆网络协议，这堆网络协议在内核中也是不同的存在，对于arp，Linux内核就提供了一种缓存机制来维护这张表。

实际的使用场景是，网络设备维护的arp表与内核维护的arp表相同步，一旦有变化，便通过钩子通知到上层的arp模块。但对于网络设备的arp模块来说，还需要实现一个arp老化时间的功能，这个功能的实现便也依靠了linux内核的arp表老化。

首先来看内核是如何维护arp表的：

可以看到一个完整的arp条目变化的流程。其中有三个计时器，第一个表示到达delay之后的计时，第二个表示到达reachable的计时，第三个表示条目状态变成stale之后的计时。 对于delay和reachable我们不做多解释，重要的状态在于stale。 当条目处于stale状态时，可能会发现几个问题，为什么没有变成delay状态？为什么过了stale_time，条目还不老化？ 先一个一个问题解决。

为什么没有变成delay状态？

之所以使用stale状态，是因为要减少网络中arp交互的开销，也就是尽量减少arp交互，但当条目变为stale之后，就说明，使用这个条目是不安全的不确定的。但是如果有应用用到这个条目发包，linux内核仍不进行arp交互，而是设立了一个delay的状态，在这个状态的持续过程中，收到了来自邻居的包，那么说明，此条目可用，则转为reachable的状态，如果没有，那么则会真正的进行arp交互，如果还没有，那么说明在这个网络中，此ip已经不对应任何一个mac地址，也没有必要存在了，置为failed。

所以可见，linux设计这个缓存机制的目的主要有二，一减少arp交互，二减少条目的增加和删除操作造成的开销。 第二个问题，为什么过了这个时间还不老化，这也是这一次的主要bug。

首先我们先知道几个参数的设置：

这个时候，表项将被置为invalid状态，等待下一个gc时间的到来，回收删除。

所以问题，看定出在gc的时间。同时我们也得知了，设定老化时间的存在，必然不会非常准确，而是一个大概的值，所需要配置的项就是gc_stale_time。 这时我们留意到：

存在于ARP高速缓存中的最少个数，如果少于这个数，垃圾收集器将不会运行 问题似乎就是在此，默认设置为128条，也就是说当条目大于128时，gc才会工作，只要将此项配置成0，便可以正常的实现arp老化。

当然，其实还是有简单粗暴的方法，比如当已经过了stale_time状态时，调用一下

就好了。 其实还是有一个疑问，这个bug在linux4.4中出现，本人使用linux host也是一样的表现，而其他的使用linux3.6或者更低版本的linux中，只需要配置gc_stale_time便可以实现老化，其他的参数配置完全一致，却没有出现不能老化的问题，或许内核版本差异，表项和gc的关系之间存在着不同，或是其他原因，尚未解决。

还记得在在查找资料的过程中，看到的，内核其实已经对维护arp表的存在进行了很多的努力，但是你却对着这些优化绞尽脑汁，这就有点。。。。。

https://www.cnblogs.com/yorkwoo/p/4664535.html

cat /proc/sys/net/ipv4/neigh/eth0/base_reachable_time同目录下还有一个文件gc_stale_time，官方解释如下：Determines how often to check for stale neighbour entries.When a neighbour entry is considered stale it is resolved again before sending data to it.Defaults to 60 seconds.

arp -a    #代码对应于ioctl(s, SIOCGARP, &arpreq)，没法看到每条缓存的状态是REACHABLE还是STALE

/isam/slot_1101/run # arp -a? (135.251.197.136) at 00:19:8f:5f:bd:87 [ether] on eth0? (135.251.196.1) at 00:e0:b1:ca:5a:48 [ether] on eth0

ip neigh show    #实现上是通过另一种系统调用netlink来获取的

/proc/sys/net/ipv4/neigh/eth0 # ip neigh135.251.197.136 dev eth0 lladdr 00:19:8f:5f:bd:87 REACHABLE135.251.196.1 dev eth0 lladdr 00:e0:b1:ca:5a:48 STALE

经过一系列测试，结论如下：

执行arping命令，无法添加新的arp缓存。但是可以把STALE的缓存刷新为REACHABLE状态。

arping有如下选项，是不是我少加了什么选项呢？注释符#后面的解释是man命令里面摘过来的。

arping -I eth0 135.251.196.1 -c 10

/isam/slot_default/run # arping -harping: invalid option -- 'h'BusyBox v1.22.1 (2015-07-11 21:41:15 CEST) multi-call binary.

Usage: arping [-fqbDUA] [-c CNT] [-w TIMEOUT] [-I IFACE] [-s SRC_IP] DST_IP

Send ARP requests/replies

-f Quit on first ARP reply    #Finish after the first reply confirming that target is alive.-q Quiet    #Quiet output. Nothing is displayed.-b Keep broadcasting, don't go unicast    #Send only MAC level broadcasts. Normally arping starts from sending broadcast, and switch to unicast after reply received.-D Duplicated address detection mode    #Duplicate address detection mode (DAD). See RFC2131, 4.4.1.  Returns 0, if DAD succeeded i.e. no replies are received    #如果是DAD模式，则原源主机地址一直没有设置，那么就意味着源地址为0.0.0.0。这样当目的主机接到之后，就会向0.0.0.0发送回复，就相当于广播给以太网中所有的主机。因为进行D重复地址检测模式的原因很可能是由于源主机的IP地址没有设置，从而想设置自身的IP地址。在IP地址没有设置的时候，主机只能接受到地址为0.0.0.0的广播信号。-U Unsolicited ARP mode, update your neighbors    #Unsolicited ARP mode to update neighbours ARP caches.  No replies are expected.    #为了更新以太网邻居的ARP快速缓存而主动进行的ARP。也就是免费ARP（gratuitous ARP），即请求自己的ip地址的mac地址。-A ARP answer mode, update your neighbors    #与-U选项类似，但是发送的是ARP 回复报文，而不是ARP请求报文。-c N Stop after sending N ARP requests-w TIMEOUT Time to wait for ARP reply, seconds-I IFACE Interface to use (default eth0)-s SRC_IP Sender IP addressDST_IP Target IP address

从以上选项可以看出，我们并没有漏掉什么选项，所以内核就是这么设计的。

还进行过如下测试，Linux shell ping竟然只能添加arp缓存，但是并不能把STALE的缓存刷新为REACHABLE状态。而且ping是通的，这也说明了STALE还在被引用。

============== End