配置ARP年龄超时 [英] Configuring ARP age timeout

问题描述

我正在尝试配置 ARP 年龄超时.我想我应该将 /proc/sys/net/ipv4/neigh/default/base_reachable_time_ms 设置为所需的超时时间.但是，尽管我将其设置为 30000 毫秒(30 秒)，但仍需要将近 10 分钟的时间才能将条目从 ARP 缓存中删除.在阅读了几篇文章后，我发现还有一些影响超时的设置:

I am trying to configure the ARP age timeout. I think I should set /proc/sys/net/ipv4/neigh/default/base_reachable_time_ms to the desired timeout. But although I set this to 30000ms (30sec) it still takes close to 10mins for an entry to get removed from the ARP cache. After reading few articles I see there are few more settings that affect the timeout:

/proc/sys/net/ipv4/neigh/default/gc_interval
/proc/sys/net/ipv4/neigh/default/gc_stale_time
/proc/sys/net/ipv4/route/gc_interval
/proc/sys/net/ipv4/route/gc_timeout

我不确定要为这些编程什么.gc_timeout 在 Linux 中默认为 5 分钟.我将其更改为 30 秒，但仍然没有看到条目在 base_reachable_time/2 或 3*base_reachable_time/2 内被删除.

I am not sure what to program for these. The gc_timeout defaults to 5 minutes in Linux. I changed that to 30 seconds but still I don't see the entry getting removed within base_reachable_time/2 or 3*base_reachable_time/2.

如何设置 ARP 缓存的过期时间?

How can I set the expiration time for the ARP cache?

推荐答案

Linux 内核中的邻居缓存并不像人们想象的那么简单.我会试着用它来解释一些怪癖.

The neighbor cache in the Linux kernel isn't as simple as one would think. I'll try to explain some of the quirks with it.

邻居缓存条目实际上完全脱离缓存或只是被标记为陈旧/无效之间存在细微差别.在 base_reachable_time/2 和 3*base_reachable_time/2 之间的某个时间点，该条目仍将在缓存中，但会被标记为 STALE 状态.您应该可以通过ip -s neighbor show"查看状态，

There are subtle differences between an neighbor cache entry actually falling out of the cache entirely or just being marked as stale/invalid. At some point between base_reachable_time/2 and 3*base_reachable_time/2, the entry will still be in the cache, but it will be marked with a state of STALE. You should be able to view the state with "ip -s neighbor show",

pherricoxide@midigaurd:~$ ip -s neighbor list
192.168.42.1 dev eth0 lladdr 00:25:90:7d:7e:cd ref 2 used 184/184/139 probes 4 STALE
192.168.10.2 dev eth0 lladdr 00:1c:23:cf:0b:6a ref 3 used 33/28/0 probes 1 REACHABLE
192.168.10.1 dev eth0 lladdr 00:17:c5:d8:90:a4 ref 219 used 275/4/121 probes 1 REACHABLE

当处于上图所示的 STALE 状态时，如果我 ping 192.168.42.1，它将立即将数据包发送到 00:25:90:7d:7e:cd.大约一秒钟后，它通常会向拥有 192.168.42.1 的用户发送 ARP 请求，以便将其缓存更新回 REACHABLE 状态.但是，更令人困惑的是，内核有时会根据来自更高级别协议的积极反馈来更改超时值.这意味着如果我 ping 192.168.42.1 并且它回复，那么内核可能不会打扰发送 ARP 请求，因为它假定 pong 意味着它的 ARP 缓存条目是有效的.如果条目处于 STALE 状态，它也会被它碰巧看到的主动 ARP 回复更新.

When in the STALE state like show above, if I ping 192.168.42.1, it will send the packet to 00:25:90:7d:7e:cd right away. A second or so later it will usually send an ARP request for who has 192.168.42.1 in order to update it's cache back to a REACHABLE state. BUT, to make matters more confusing, the kernel will sometimes change timeout values based on positive feedback from higher level protocols. What this means is that if I ping 192.168.42.1 and it replies, then the kernel might not bother sending an ARP request because it assumes that the pong meant that it's ARP cache entry is valid. If the entry is in the STALE state, it will also be updated by unsolicited ARP replies that it happens to see.

现在，在大多数情况下，您只需要担心处于 STALE 状态的条目. 为什么需要从缓存中完全删除条目?内核付出了很多努力，通过改变缓存条目的状态而不是一直将它们实际删除和添加到缓存中来不抖动内存.

Now, for the majority of cases, the entry being in the STALE state is all you need to worry about. Why do you need the entry to be removed from the cache entirely? The kernel goes to a lot of effort to not thrash memory by just changing the state of cache entries instead of actually removing and adding them to the cache all the time.

如果你真的坚持它不仅会被标记为 STALE，而且还会从邻居缓存使用的哈希图中删除，你必须注意一些事情.首先，如果条目未被使用并且在 gc_stale_time 秒内已经过时，它应该有资格被删除.如果 gc_stale_time 通过并将条目标记为可以删除，它将在垃圾收集器运行时(通常在 gc_interval 秒后)删除.

If you really really insist that it not only will be marked as STALE, but will actually be removed from the hashmap used by the neighbor cache, you have to beware of a few things. First, if the entry hasn't been used and is stale for gc_stale_time seconds, it should be eligible to be removed. If gc_stale_time passed and marked the entry as okay to be removed, it will be removed when the garbage collector runs (usually after gc_interval seconds).

现在的问题是邻居条目如果被引用将不会被删除.您将遇到的主要问题是来自 ipv4 的参考路由表.有很多复杂的垃圾收集东西，但需要注意的重要一点是路由缓存的垃圾收集器每 5 分钟才使条目过期一次 (/proc/sys/net/ipv4/route/gc_timeout秒)在很多内核上.这意味着必须将邻居条目标记为过时(可能是 30 秒，取决于 base_reachable_time)，然后必须经过 5 分钟，路由缓存才会停止引用该条目(如果您是幸运)，然后是 gc_stale_time 和 gc_interval 的某种组合，然后才真正被清理干净(因此，总体而言，会在 5-10 分钟之间过去).

Now the problem is that the neighbor entry will not be deleted if it's being referenced. The main thing that you're going to have problems with is the reference from the ipv4 routing table. There's a lot of complicated garbage collection stuff, but the important thing to note is that the garbage collector for the route cache only expires entries every 5 minutes (/proc/sys/net/ipv4/route/gc_timeout seconds) on a lot of kernels. This means the neighbor entry will have to be marked as stale (maybe 30 seconds, depending on base_reachable_time), then 5 minutes will have to go by before the route cache stops referencing the entry (if you're lucky), followed by some combination of gc_stale_time and gc_interval passing before it actually gets cleaned up (so, overall, somewhere between 5-10 minutes will pass).

总结:您可以尝试将 /proc/sys/net/ipv4/route/gc_timeout 减小到更短的值，但是变量很多，很难全部控制.通过不要过早删除缓存中的条目(而是将它们标记为 STALE 甚至 FAILED)，我们付出了很多努力来使事情表现良好.

Summary: you can try decreasing /proc/sys/net/ipv4/route/gc_timeout to a shorter value, but there are a lot of variables and it's difficult to control them all. There's a lot of effort put in to making things perform well by not removing entries in the cache too early (but instead just marking them as STALE or even FAILED).

这篇关于配置ARP年龄超时的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！