ARP 超时.为什么是固定周期? [英] ARP Timeouts. Why fixed periodic?

问题描述

这个问题困扰了我多年.

This one's been bugging me for years.

基本问题:是否有某种原因 ARP 必须在 ARP 缓存条目上实施固定超时?

Basic question: Is there some reason ARP has to be implemented with fixed timeouts on ARP cache entries?

我在实时圈子方面做了很多工作.这些天我们在专用的 UDP/IP 链接上进行大部分系统间通信.这在大多数情况下实时可靠地工作，但有一点:ARP 条目超时.

I do a lot of work in Real Time ciricles. We do most of our inter-system communications these days on dedicated UDP/IP links. This for the most part works reliably in Real Time, but for one nit: ARP entry timeouts.

典型的 ARP 实现方式如下:

The way typical implementations do ARP is the following:

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

显而易见的解决方案(我们虔诚地使用)是将所有 ARP 条目设为静态.然而，这是一个非常重要的 PITA(尤其是在 RTOS 上，找到接口的 MAC 地址并不总是只需点击几次简单的 GUI 即可).

The obvious solution (which we use religously) is to make all the ARP entries static. However, that's a royal PITA (particularly on RTOS's where finding an interface's MAC address is not always a matter of a couple of easy GUI clicks).

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

Back when we wrote our own IP stack, I solved this problem by never (ever) timing out ARP table entries. That has obvious drawbacks. A more robust and perfectly reasonable solution might be to refresh the entry timeout whenever a packet from the same MAC/IP combo is seen. That way an entry would only get timed-out if it hadn't communicated with the stack in that amount of time.

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

But now we're using our vendor's IP stack, and we're back to the stupid ARP timeouts. We have enough leverage with this vendor that I could perhaps get them to use a less inconvienient scheme. However, the universality of this brain-dead timeout algorithm leads me to believe it might be a required part of the implementation.

这就是问题所在.是否需要这种行为?

So that's the question. Is this behavior somehow required?

推荐答案

互联网主机的 RFC1122 要求 讨论这个.

     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.

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

Networks can be very dynamic; DHCP servers can assign the same IP address to different computers when old lease times expire (making current ARP data invalid), there can be IP conflicts that will never be noticed unless ARP requests are periodically made, etc.

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

It also provides a mechanism for checking if a host is still on the network. Imagine you're streaming a video over UDP to some IP address 192.168.0.5. If you cache the MAC address of that machine forever, you'll just keep spamming out UDP packets even if the host goes down. Doing an ARP request every now and then will stop the stream with a destination unreachable error because no one responded with a MAC for that IP.

这篇关于ARP 超时.为什么是固定周期?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！