linux - 广播消息中的 ARP 超时

Question

假设我有源主机 H1(10.1.1.2/24) 想要与主机 H2(10.1.1.3/24) 通信。由于两台主机在同一个子网中，H1 发送 ARP 广播。 H2 回复这个广播，最后 H1 得到 H2 的 MAC 地址。因此建立了通信。

现在如果 H2 关闭，H1 将不会收到来自 H2 的 ARP 回复。那么 H1 将等待 ARP 回复多长时间？ RFC 826 没有讨论任何此类计时器。

我在一些论坛上发现它是 5 到 30 秒。是否正确？

问候，素丹素

Answer 1

在您的描述中，您至少漏掉了一件事。 ARP 回复作为 ARP 条目缓存了一段时间。所以H1会在H2宕机后发送一些流量到blackhole。这段时间被选择为 base_reachable_time/2 和 3*base_reachable_time/2 之间的随机数。 (随机用于及时分发来自不同设备的请求)。默认 base_reachable_time 为 30 秒。

经过这段随机时间后，H1 会尝试更新 ARP 条目。更新是通过单播消息(直接发送到 H1，而不向网络广播)通过发送间隔为 retrans_time_ms(默认为 1 秒)的 ARP 请求来执行的。如果 ucast_solicit(默认 3 次)尝试失败，则执行广播探测。

如果广播探测也失败(mcast_solicit 尝试间隔 retrans_time_ms)，则 ARP 条目被认为是不完整的。在此检查期间，内核可以保留发送到 ARP 队列中的 H2 的数据包。

总结:

• ARP 条目重新生效前经过 15-45 秒
• (3+3)*1000 毫秒，从探测开始到 ARP 条目被视为无效之前。