配置ARP超时时间 [英] Configuring ARP age timeout

问题描述

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

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屋！