ARP超时.为什么固定周期？

Question

这个人多年来一直困扰着我.

基本的问题:是有一些原因ARP 具有与在ARP缓存条目固定超时来实现？

我在Real Time中做了很多工作.如今,我们在专用的UDP/IP链路上进行大部分的系统间通信.这在大多数情况下可以在实时中可靠地工作,但是对于一个nit:ARP输入超时.

典型实现ARP的方式如下:

• 当客户端要求将IP数据包发送到具有未知MAC地址的IP地址时,堆栈不会发送该IP数据包,而是发出ARP请求.如果上层(TCP)确实重新发送,则没有问题.但由于我们使用UDP,原始邮件将丢失.在启动时,这是可以的,但在操作过程中,这是一件坏事 ™.
• (动态)ARP表条目会定期从ARP表中删除,即使我们只是在几毫秒之前从该系统获得了一个数据包.这意味着Bad Thing™定期发生在我们的系统中.

显而易见的解决方案(我们使用宗教)是使所有ARP条目保持静态.然而,这是一个皇家PITA(特别是在RTOS上,找到一个接口的MAC地址并不总是一些简单的GUI点击).

当我们编写自己的IP堆栈时,我通过永远(永远)超时ARP表条目解决了这个问题.这有明显的缺点.一个更健壮且完全合理的解决方案可能是每当看到来自相同MAC/IP组合的数据包时刷新进入超时.这样一个条目只有在这段时间内没有与堆栈通信时才会超时.

但现在我们正在使用我们供应商的IP堆栈,我们又回到了愚蠢的ARP超时.我们对这家供应商有足够的影响力,我或许可以让他们使用不那么不方便的方案.然而,这种脑死亡超时算法的普遍性使我相信它可能是实现的必要部分.

这就是问题所在.这种行为是否需要某种程度？

Answer 1

RFC1122 Internet 主机要求对此进行了讨论。

     2.3.2.1  ARP Cache Validation

        An implementation of the Address Resolution Protocol (ARP)
        [LINK:2] MUST provide a mechanism to flush out-of-date cache
        entries.  If this mechanism involves a timeout, it SHOULD be
        possible to configure the timeout value.

      ...

       DISCUSSION:
             The ARP specification [LINK:2] suggests but does not
             require a timeout mechanism to invalidate cache entries
             when hosts change their Ethernet addresses.  The
             prevalence of proxy ARP (see Section 2.4 of [INTRO:2])
             has significantly increased the likelihood that cache
             entries in hosts will become invalid, and therefore
             some ARP-cache invalidation mechanism is now required
             for hosts.  Even in the absence of proxy ARP, a long-
             period cache timeout is useful in order to
             automatically correct any bad ARP data that might have
             been cached.

网络可以非常动态；当旧的租用时间到期时（使当前的 ARP 数据无效），DHCP 服务器可以将相同的 IP 地址分配给不同的计算机，可能会出现 IP 冲突，除非定期发出 ARP 请求，否则永远不会注意到这些冲突。

它还提供了一种检查主机是否仍在网络上的机制。想象一下，您正在通过 UDP 将视频流式传输到某个 IP 地址 192.168.0.5。如果您永远缓存该机器的 MAC 地址，即使主机出现故障，您也只会继续发送 UDP 数据包。时不时地发出 ARP 请求会因目标无法到达错误而停止流，因为没有人响应该 IP 的 MAC。