假设网络拓扑结构如下：
>网络192.168.106.0,网络掩码255.255.255.0
>路由器在192.168.106.1
>“问题服务器”,电话：192.168.106.2
>另一台服务器位于192.168.106.3
现在,假设“问题服务器”可能在网络上保持静默足够长的时间,以使其在路由器上的arp条目到期.
当来自此网络外部的某人尝试连接到“问题服务器”时,所有尝试都会超时.从网络内部到“问题服务器”的连接成功.
如果“问题服务器”本身试图连接到网络外的某个其他地址,则连接成功 – 此后,从网络外部到“问题服务器”的连接也会成功一段时间.此外,从“问题服务器”到“另一台服务器”的连接也可以.
在“问题服务器”已经沉默了很长时间的情况下查看arp流量,我可以在网络上看到“问题服务器”地址的arp请求,但这些上的“tell”地址是网络地址( 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不会响应arp请求,其中“tell”地址是网络地址,而Windows(至少是Vista)的地址.这个我无法在实际的问题环境中进行测试,而是在家中使用自己的玩具.
而且,看起来我并不完全孤单于这个问题;类似的经历可以在这里找到：alpacapowered.wordpress.com
解决方法
最终,事情归结为两件事：
Juniper路由器或实际上是集群防火墙系统在某种程度上失去了集群方之间的配置同步.因此,并非FW群集的所有部分都具有最新配置,这导致arp请求错误(是的,坏的arp请求确实来自路由器/防火墙).
防火墙的管理应用程序也行为不端,试图将当前正确的配置以外的其他配置推送到防火墙集群的至少一部分.
我没有关于防火墙本身或管理应用程序的详细信息,但最终结果是现在arp请求上的“tell”地址是路由器IP地址(原始描述中的.1) ),而不是网络地址(.0).
对于这些(“who-have … tell … .1”)arp请求Linux服务器响应它应该是这样,并且入站连接只是花花公子,即使在服务器地址的任何跟踪丢失很久之后从路由器arp缓存.
