我有一个服务器与networking连接问题，我认为是来自arp协议处理的问题。
假设networking拓扑结构如下所示：
现在，假设“问题服务器”可能在networking上静默了足够长的时间，以使其路由器上的arp条目到期。
当这个networking以外的人试图连接到“问题服务器”时，所有的尝试都会超时。 从networking到“问题服务器”的连接成功。
如果“问题服务器”本身试图连接到networking外的其他地址，则连接成功 – 此后，从networking外部到“问题服务器”的连接也会成功一段时间。 此外，从“问题服务器”到“另一台服务器”的连接都可以。
在“问题服务器”沉默了很长一段时间的情况下，我可以看到ARP请求在networking上的“问题服务器”地址，但“告诉”地址就是networking地址（ 192.168.106.0）而不是路由器地址（192.168.106.1） – 这是我认为是这个问题的原因：出于某种原因，路由器在其ARP请求中有错误的回复地址。
“另一台服务器”保持可达状态，但我认为这是因为它频繁地连接到本地networking之外，从而保持其在路由器上的arp条目不会到期。
任何意见/build议？
有问题的服务器正在运行Linux（CentOS 5.x？），并且在VMWare ESXi（5.0？）内作为虚拟机运行（我将在周一重新开始工作后检查/填写版本详细信息）。 路由器的型号对于我来说是未知的。
回答问题，进一步发现
抱歉，要慢回来这个。
不幸的是，我对networking方面（除VMWare平台本身以外的任何东西）的可见性受到严重限制。
基于来自路由器的ARP请求数据包，它是瞻博networking产品（按请求者MAC地址猜测）。
这是一个小型networking，因此可以将拓扑视为路由器，交换机和托pipe多个虚拟机的单个VMWare服务器。
至于奇数ARP请求的发起者，它几乎必须是networking网关：它们只在我尝试从networking外部连接到“问题”计算机时出现，并在尝试超时或取消时停止。 这些请求中的MAC地址与build立出站连接后服务器arp表中的路由器的MAC地址不一样。 但是，这些“奇数”请求中的MAC地址以及服务器arp表中显示的MAC地址都有一个Juniper分配器OUI。
那么一个可能相关的发现; 看来，Linux不会响应的ARP请求“告诉”地址是networking地址，而Windows（至lessVista）呢。 我不能在实际的问题环境中进行testing，而是在家中使用自己的玩具。
而且，这个问题看起来并不完全孤单， 可以在这里find类似的经验： alpacapowered.wordpress.com
今天带来了一个有趣的情况变化。
最终，事情归结为两件事情：
Juniper路由器，或者实际上是一个集群防火墙系统，在集群之间失去了configuration同步。 因此，并不是FW集群的所有部分都进行了最新的configuration，导致arp请求错误（是的，坏的arp请求源自路由器/防火墙）。
防火墙的pipe理应用程序也做了不好的事情，试图将一些不同于当前正确的configuration推向至less部分防火墙集群。
我没有关于防火墙本身以及pipe理应用程序的详细信息，但是最终的结果是现在arp请求上的“tell”地址是路由器IP地址（原始描述中的.1 ），而不是networking地址（.0）。
对于这些（“who-has … tell … .1”），arp请求Linux服务器响应正常，并且入站连接工作正常，即使在服务器地址的任何跟踪丢失之后从路由器的ARPcaching。
我遇到了完全相同的问题。 原来有人把manage-ip的值设置为子网地址：
Cluster:name(M)-> get config | inc aggregate10.200 set interface aggregate10.200 ip xxxx225/28 ... set interface aggregate10.200 manage-ip xxx224 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
修理：
unset interface aggregate10.200 manage-ip
在我们的例子中，这是一个错误的configuration。