通过在我的路由器上运行数据包捕获，我发现我的一些服务器正在为其networking外部的IP发送ARP请求。
例如，如果我的networking是：
Network: 8.8.8.0/24 Gateway: 8.8.8.1 (MAC: 00:21:9b:aa:aa:aa) Example Server: 8.8.8.20 (MAC: 00:21:9b:bb:bb:bb) 通过在具有8.8.8.1的接口上运行捕获，我看到如下请求：
Sender Mac: 00:21:9b:bb:bb:bb Sender IP: 8.8.8.20 Target MAC: 00:21:9b:aa:aa:aa Target IP: 69.63.181.58
任何人以前见过这种行为？ 我对ARP的理解是，请求只能在子网内的IP上进行……我对我对ARP的理解感到困惑吗？ 如果我不困惑，任何人看到这种行为？
此外，这些似乎发生在突发事件中，当我在networking外部进行ping ping IP时，这种情况不会发生。
更新：
回答伊恩的问题。 我没有像Hyper-V那样运行。 我有多个接口，但只有一个是活动的（使用BACS故障转移组合）。 子网掩码是255.255.255.0（即使它有些不同，它不能解释像69.63.181.58这样的IP）。
当我运行MSnetworking监视器或wireshark我没有看到这些ARP请求。 会发生什么事情呢，在路由器捕获，我看到从主机的networking外约10个IP请求突发。 在使用wireshark或NetMon的机器上，我看到了networking上所有机器的大量ARP响应 。 但是，我没有看到捕获的任何请求，要求这些答复。
所以看来也许是刷新arpcaching，但包括networking外的IP。 此外，当这个NetMon不显示ARP请求？
如果您在Wireshark / Netmon中看不到ARP请求，则可以使用Broadcom的组合驱动程序（BASP）和OEMnetworking可pipe理性（例如，Dell的DRAC和HP的iLo）来为ARP框架另外提供两个源。
Broadcom成组驱动程序包含一个名为“LiveLink”的function，该function使用ARP帧来validation到远程系统的networking连接（请参阅http://support.dell.com/support/edocs/network/p29352/english/teaming.htm ）。 如果用户为本地子网之外的IP地址设置LiveLink探测，那么BASP将高兴地为该地址生成一个ARP。 当然，如果地址是假的，那么团队应该指出在团队中使用的一个或多个NIC的故障。
企业服务器通常有一个专用的以太网端口用于pipe理。 成本较低的服务器可以搭载在LOM端口上，并通过与Windows相同的RJ-45连接器发送stream量。 如果服务器的pipe理function已启用，但configuration不正确，则可能会在主机使用的IP子网之外生成ARP。 这些ARP帧对Wireshark / Netmon也是不可见的。 大多数pipe理解决scheme也可以在系统closures的情况下工作，所以如果在系统closures的时候继续看到系统产生的ARP，那么pipe理function可能是源头。
你对ARP的理解是正确的。 主机不应该为不在本地子网中的IP地址进行ARP，因为它应该知道该IP地址不是本地的，因此应该知道数据需要发送到默认网关。 我见过的唯一一次是感染了恶意软件的主机。
显而易见的问题是：什么是你的networkingconfiguration？ 你有多个接口？ 您的服务器上是否安装了hyper-v或vmware？
无论如何，你对arp的理解确实是对的。 networkingconfiguration错误似乎是最有可能的解释。
尝试在您的服务器上安装MSNetmon并捕获ARPstream量。 它应该给你一个从哪里来的指示。 在所有可能的情况下，这将是系统，而不是一些恶意软件的过程。 如果它是上述的恶意软件，那么它应该快速识别它。