我的服务器出现了网络连接问题，我推测这是由于 arp 协议处理问题引起的。
假设网络拓扑如下：
- 网络 192.168.106.0，网络掩码 255.255.255.0
- 路由器 192.168.106.1
- 192.168.106.2 上的“问题服务器”
- 另一台服务器位于 192.168.106.3
现在，假设“问题服务器”在网络上处于静默状态的时间足够长，以致其在路由器上的 arp 条目过期。
当网络外部的某人尝试连接“问题服务器”时，所有尝试都会超时。网络内部到“问题服务器”的连接会成功。
如果“问题服务器”本身尝试连接到网络外的其他地址，则连接会成功 —— 此后，网络外到“问题服务器”的连接也会在一段时间内成功。此外，“问题服务器”到“另一台服务器”的连接也正常。
在“问题服务器”长时间处于静默状态的情况下查看 arp 流量，我可以看到网络上针对“问题服务器”地址的 arp 请求，但这些请求上的“告诉”地址是网络地址（192.168.106.0）而不是路由器地址（192.168.106.1） - 这就是我认为该问题的原因：由于某种原因，路由器在其 arp 请求中回复地址错误。
“另一台服务器”仍然可以访问，但我认为原因是它频繁与本地网络外部建立连接，从而使路由器上的 arp 条目不会过期。
有什么意见或建议吗？
有问题的服务器运行的是 Linux（CentOS 5.x？），并且作为 VMWare ESXi（5.0？）中的虚拟机运行（我将在周一上班后检查/填写版本详细信息）。我不知道路由器的品牌/型号。
问题的答复和进一步的调查结果
抱歉回复得这么慢。
不幸的是，我对网络端（VMWare 平台本身之外的任何内容）的可见性受到严重限制。
根据来自路由器的 arp 请求数据包，它是 Juniper 产品（通过请求者的 MAC 地址猜测）。
这是一个小型网络，因此请考虑将拓扑结构作为路由器、交换机和托管多个虚拟机的单个 VMWare 服务器。
至于奇怪的 arp 请求的发起者，它几乎必须是网络网关：它们只在我尝试从网络外部连接到“问题”计算机时出现 - 并在尝试超时或取消时停止。一个小的奇怪之处是这些请求中的 MAC 地址与建立出站连接后服务器 arp 表中的路由器的 MAC 地址不同。但是，这些“奇怪”请求中存在的 MAC 地址以及服务器 arp 表中显示的 MAC 地址都具有 Juniper 分配器 OUI。
然后有一个可能相关的发现；Linux 似乎不会响应“tell”地址为网络地址的 arp 请求，而 Windows（至少 Vista）会响应。我无法在实际的问题环境中测试这一点，只能在家里用我自己的玩具进行测试。
此外，看起来我并不是唯一一个遇到这个问题的人；在这里也可以找到类似的经历：alpacapowered.wordpress.com
答案1
今天的情况发生了一个有趣的变化。
最终，事情归结为两件事：
Juniper 路由器（或者说集群防火墙系统）不知何故丢失了集群各方之间的配置同步。因此，FW 集群并非所有部分都具有最新配置，这导致 arp 请求错误（是的，错误的 arp 请求确实来自路由器/防火墙）。
防火墙的管理应用程序也存在错误行为，试图将一些非当前、正确的配置推送到防火墙集群的至少一部分。
我不知道防火墙本身和管理应用程序做了什么，但最终结果是现在 arp 请求上的“tell”地址是路由器 IP 地址（原始描述的 .1），而不是网络地址（.0）。
对于这些（“谁有...告诉....1”）arp 请求，Linux 服务器会做出应有的响应，并且入站连接可以正常工作，即使在路由器 arp 缓存中丢失服务器地址的任何痕迹之后很长时间也是如此。
答案2
我遇到了完全相同的问题。原来有人将 manage-ip 值设置为子网地址：
Cluster:name(M)-> get config | inc aggregate10.200 set interface aggregate10.200 ip x.x.x.x.225/28 ... set interface aggregate10.200 manage-ip x.x.x.224 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
修理：
unset interface aggregate10.200 manage-ip
就我们的情况而言，这是一个错误配置。