邻居子系统的一些个人总结neighboursubsystem.docVIP

邻居子系统的一些个人总结neighbour subsystem作为多个网络的转发器（网关设备），该网关设备可能是成千上万台主机的网关，这样就需要一个好的ARP管理机制。一个好的ARP缓存体现在1、查找速度 2、计时机制 3、缓存空间的管理（例如当缓存空间不够时，又是如何处理） linux在neighbour management对于上述的几方面的处理方式：1、查找速度采用哈希表，来加快查找。 2、计时机制计时机制比较复杂，里面涉及很多的计时器。采用IPV6的state transition 机制，IPv6 defines an NUD mechanism that can help determine quickly whether the neighbour is disconnected or gone down.linux内核就是以这种nud state transition scheme为基础来设计neighbour infrastructure。现在就讨论一下这个NUD机制为什么如此设计？（可参见figure 26-13）哪些状态NUD_NONE、NUD_INCOMPLETE、NUD_REACHABLE、NUD_STALE、NUD_DELAY、NUD_PROBE、NUD_PERMANENT、NUD_NOARP。NUD scheme多了一个reachable detection scheme，这主要是借鉴了IPV6 NUD scheme的精髓。一般的ARP处理方式是时间超时，NUD_REACHABLE状态马上进入FAILED。而这里多了个可达性的检测。因为造成arp entry很长没有被使用的原因有（1）本身就没有主机要引用到它，也就是说主机没有发送相关的数据报。（2）主机想发送相关的数据包，但是由于接收方或网络传输路径中间的网络设备出现故障而不能传送成功，遇到这种情况高层协议像TCP需要重传，而中间就有一段延迟，这段延迟时间会使得相关的arp entry没有被引用。reachable detection引入到三个state:NUD_DELAY、NUD_PROBE、NUD_STALE。处于NUD_STALE状态的entry一旦被引用时，就进入NUD_DELAY,说明第（1）种情况排除，可能是目的主机的问题。同时start the reachable verification。进入NUD_DELAY状态，这个状态是一个优化，在该状态下并没有启动ARP请求，而是进一步等待反方向的确认数据报。本来可以马上进NUD_PROBE，但是并没有马上进入而是先进入NUD_DELAY，这样做是有原因的，如果在大的网络中，arp entry很多，而每个arp entry都启动一个arp请求，这样开销太大了，所以引入了这样一个过渡状态。进入NUD_PROBE就启动arp请求进程，发送arp请求。 在NUD_INCOMPLETE、NUD_DELAY、NUD_PROBE这三个state都设置了计时器，其计时器的处理方式都为neigh_timer_handler。在neighbour中设置了confirmed，这是可达性检验时高层协议用来更新neighbour的最新确认信息，例如TCP协议每收到反方向发过来的确认数据包，就会调用dst-confirm(dst-confirm又会再调用neigh_confirm)来更新confirm。这样计时器超时之后就可以利用confirmed来进行比较从而确认是否超时，例如当nowconfirmed+delay_probe_time,NUD_DELAY转换到NUD_REACHABLE，否则NUD_DELAY进入NUD_PROBE（neigh_timer_handler）。所以没必要在dst-confirm来判断是否应将neighbour state从NUD_DELAY转变到NUD_PROBE，而直接将检验的工作交给neighbour subsystem，实现了模块的独立性。 NUD_STALE超过gc_staletime，内核是如何检测到的？是通过异步回收机制neigh_periodic_timer回收资源来实现的，没必要为NUD_STALE单独分配一个计时器，这样做减少了因为增加一个计时器而引起的开销，再说NUD_STALE超过gc_staletime也要被回收，这同neigh_periodic_timer目的是一样的，所以有异曲同工之妙。 NUD_INCOMPLETE、NUD_PROBE都会发送solicitation request，但是发送的request次数不同，NUD_PROBE只要发送ucast_probes，而NUD_INCOMPLETE要发送ucast_probes +